チケット更新時にZendeskウェブフックを設定する方法：完全ガイド

Zendesk（ゼンデスク）のウェブフックを使用すると、チケットのアクティビティに対応するリアルタイムの連携を構築できます。チケットが更新されたとき（担当者の変更、ステータスの移行、新しいコメントなど）、複雑なポーリングスクリプトを作成しなくても、外部システムに自動的に通知できます。

このガイドでは、チケットが更新されたときにトリガーされるウェブフックの設定について説明します。Zendeskの管理センターでウェブフックを構成し、トリガーに接続し、初めて実装する人がつまずく一般的な問題を処理するための正確な手順を学びます。

Zendeskウェブフックとは？また、なぜ使用するのか？

ウェブフックは、Zendeskで何かが発生したときに指定されたURLにリクエストを送信するHTTPコールバックです。データをプルする必要がある代わりに、システムにデータをプッシュする自動通知と考えてください。

Zendeskは、ウェブフックを接続する2つの方法を提供します。

• イベントサブスクライブウェブフック は、システムイベントが発生するたびに起動します。「チケット更新」をサブスクライブすると、エンドポイントはチケットが変更されるたびにペイロードを受信します。これらは固定のJSONペイロードとPOSTリクエストを使用します。

• トリガーまたは自動化接続ウェブフック は、定義した条件に基づいて起動します。トリガーするタイミング（担当者の変更、優先度が緊急に設定されたなど）を正確に選択し、Zendeskプレースホルダーを使用してペイロードをカスタマイズします。

チケット更新ウェブフックの一般的なユースケースには、チケットデータをCRM（顧客関係管理）に同期したり、優先度の高い変更についてSlack（スラック）チャネルにアラートを送信したり、内部ツールでカスタムワークフローをトリガーしたり、コンプライアンスの監査証跡を構築したりすることが含まれます。

主な利点は、リアルタイムの応答性です。ZendeskのAPI（アプリケーションプログラミングインターフェース）を数分ごとにポーリングして変更を確認する代わりに、何かが発生したときに即座に通知されます。

ウェブフックの構成が技術的に難しすぎる、または時間がかかりすぎると感じているチーム向けに、eesel AIは代替アプローチを提供します。ウェブフックインフラストラクチャを構築および維持するのではなく、eeselはZendeskに直接接続し、既存のチケットから学習するAI（人工知能）を通じて自動化を処理します。

開始する前に必要なもの

最初のウェブフックを作成する前に、次のものがあることを確認してください。

• Zendeskへの管理者アクセス 管理者のみが管理センターを通じてウェブフックを作成および管理できます。
• APIトークン 管理センターのアプリと連携 > APIトークンでこれを生成します。
• 受信エンドポイント HTTP POSTリクエストを受け入れ、JSONペイロードを処理できるURL。
• JSONの基本的な理解 チケットデータを含むペイロードを構築します。

オプションですが推奨：Hookdeck Consoleやwebhook.siteなどのリクエストインスペクターをテスト用に設定します。これらのツールは、本番環境のエンドポイントに接続する前に、ウェブフックリクエストをキャプチャし、ペイロード構造を検査するための一時的なURLを提供します。

ステップバイステップ：チケット更新のウェブフックの作成

ステップ1：管理センターでウェブフックに移動する

Zendeskにログインし、管理センターにアクセスします。アプリと連携 > ウェブフックに移動します。詳細については、Zendeskウェブフックの公式ドキュメントを参照してください。

これが最初のウェブフックの場合、リストは空になります。右上にあるアクションドロップダウンをクリックし、ウェブフックを作成を選択します。

ステップ2：新しいウェブフックを作成する

次の2つの接続オプションが表示されます。

• トリガーまたは自動化 カスタム条件を持つチケットベースのワークフロー用。
• Zendeskイベント システム全体のイベントサブスクリプション用。

特定の条件でチケットが更新されたときにウェブフックを起動する場合は、トリガーまたは自動化を選択します。

トリガーに接続するときに後で識別できるように、「チケット更新通知」などの説明的な名前をウェブフックに付けます。

ステップ3：ウェブフックの設定を構成する

エンドポイントの詳細を入力します。

• エンドポイントURL：ZendeskがPOSTリクエストを送信するHTTPS URL。
• リクエストメソッド：エンドポイントの要件に基づいて選択します（ほとんどのユースケースではPOST、リソースの更新にはPUT）。
• リクエスト形式：チケットデータにはJSONをお勧めします。

エンドポイントURLは公開されている必要があります。Zendeskは、localhostまたは内部専用のアドレスにウェブフックを送信できません。テストしている場合は、ngrokなどのサービスを使用して、ローカル開発サーバーをトンネリングします。

ステップ4：認証を設定する

Zendeskがエンドポイントで認証する方法を選択します。

• なし 認証なし（本番環境では推奨されません）。
• 基本認証 認証ヘッダーのユーザー名とパスワード。
• ベアラートークン OAuth 2.0スタイルのトークン認証。
• APIキー キー名と値を持つカスタムヘッダー。

基本認証の場合、ユーザー名としてZendeskのメールアドレスに/tokenを追加し（例：you@company.com/token）、パスワードとしてAPIトークンを使用します。

ステップ5：ウェブフックをテストする

保存する前に、テストボタンをクリックします。Zendeskはサンプルペイロードをエンドポイントに送信します。

テスト用に既存のチケットIDを入力します。テストペイロードは実際には何も更新しません。接続を確認するだけです。

エンドポイントログまたはリクエストインスペクターをチェックして、テストが到着したことを確認します。200応答が表示された場合、ウェブフックの構成は機能しています。

ステップ6：ウェブフックを起動するトリガーを作成する

チケットが更新されたときにウェブフックを呼び出すトリガーが必要です。オブジェクトとルール > トリガーに移動し、トリガーを追加をクリックします。

ウェブフックが起動するタイミングを決定する条件を設定します。

• チケット > チケットは 更新済み
• 追加の条件を追加します（オプション）：チケット > 担当者 > 変更済み、チケット > ステータス > 変更済みなど。

アクションとして、アクティブなウェブフックに通知を選択し、ドロップダウンから作成したウェブフックを選択します。

ステップ7：トリガー条件とペイロードを構成する

トリガーアクションで、エンドポイントに送信されるJSONペイロードを定義します。Zendeskプレースホルダーを使用して、チケットデータを含めます。

{
  "ticket_id": "{{ticket.id}}",
  "subject": "{{ticket.title}}",
  "status": "{{ticket.status}}",
  "assignee": "{{ticket.assignee.name}}",
  "requester": "{{ticket.requester.email}}",
  "updated_at": "{{ticket.updated_at_with_timestamp}}"
}

ticket.updated_at_with_timestampプレースホルダーは、正確な更新時刻を取得するため、ウェブフックワークフローに特に役立ちます。これを使用して、競合状態を防ぐことができます。

トリガーを保存します。ウェブフックがライブになり、条件に一致するチケットが更新されるたびに起動します。

一般的なウェブフックペイロードの例

一般的なシナリオの実用的なペイロード構成を次に示します。

基本的なチケット更新通知：

{
  "event": "ticket_updated",
  "ticket_id": "{{ticket.id}}",
  "subject": "{{ticket.title}}",
  "status": "{{ticket.status}}",
  "priority": "{{ticket.priority}}"
}

担当者変更アラート：

{
  "event": "assignee_changed",
  "ticket_id": "{{ticket.id}}",
  "new_assignee": "{{ticket.assignee.name}}",
  "new_assignee_email": "{{ticket.assignee.email}}",
  "previous_assignee": "{{ticket.assignee.previous.name}}"
}

コメント付きのステータス変更：

{
  "event": "status_changed",
  "ticket_id": "{{ticket.id}}",
  "new_status": "{{ticket.status}}",
  "latest_comment": "{{ticket.latest_comment}}",
  "ticket_url": "{{ticket.link}}"
}

カスタムフィールドの更新：

{
  "ticket_id": "{{ticket.id}}",
  "custom_fields": [
    {"id": 12345, "value": "{{ticket.ticket_field_12345}}"},
    {"id": 67890, "value": "{{ticket.ticket_field_67890}}"}
  ]
}

一般的な問題のトラブルシューティング

ウェブフックが起動しない

トリガー条件を注意深く確認してください。よくある間違いは、「チケットが作成された」の代わりに「チケットが更新された」を使用したり、一致しない条件を設定したりすることです（フィールドが空白と入力済みの両方である必要があるなど）。

トリガーに「タグを追加」アクションを一時的に追加します。タグが追加されたが、ウェブフックが起動しない場合、問題はウェブフックの構成にあります。タグが追加されない場合、トリガー条件が間違っています。

認証エラー

基本認証の場合、ユーザー名としてemail@domain.com/token（/tokenが追加されています）を使用し、Zendeskパスワードではなく、実際のAPIトークン文字列をパスワードとして使用していることを確認してください。

10秒のタイムアウト

Zendeskは厳密な10秒のタイムアウトを適用します。エンドポイントは、その時間内に2xxステータスコードで応答する必要があります。低速な操作を実行する必要がある場合は、200ですぐに応答し、バックグラウンドジョブで非同期的に処理します。

サーキットブレーカーの起動

5分以内にウェブフックリクエストの70％が失敗した場合、または1,000を超えるエラーが発生した場合、Zendeskは配信を5秒間一時停止するサーキットブレーカーを起動します。これらの停止中のイベントは「サーキットブレーカー」としてログに記録されますが、配信されることはありません。エンドポイントのヘルスを監視し、問題を迅速に修正して、これを回避してください。

重複配信

Zendeskは同じウェブフックを複数回送信する場合があります。x-zendesk-webhook-invocation-idヘッダーを使用して重複排除します。処理されたIDをRedisまたはデータベースに24時間のTTLで保存します。

呼び出しログの確認

アプリと連携 > ウェブフックに移動し、ウェブフックをクリックして、呼び出しタブをクリックします。リクエストと応答の詳細を含む、過去7日間の配信試行を確認できます。これは、主要なデバッグツールです。

本番環境のウェブフックのベストプラクティス

常にHTTPSエンドポイントを使用してください。 暗号化されていないHTTPウェブフックは傍受に対して脆弱であり、本番環境で使用しないでください。

ウェブフック署名を確認します。 Zendeskは、HMAC-SHA256で各リクエストに署名します。ウェブフックの署名シークレットを使用して署名を確認し、リクエストが実際に攻撃者ではなくZendeskから送信されたことを確認します。

べき等性を実装します。 処理された呼び出しIDを保存し、重複をスキップします。これにより、Zendeskが失敗した配信を再試行するときに、二重処理が防止されます。

すぐに応答します。 できるだけ早く200応答を返し、ウェブフックデータを非同期的に処理します。これにより、10秒のタイムアウトを下回り、再試行ストームを防ぎます。

ウェブフックのヘルスを監視します。 ウェブフック呼び出しAPIを定期的にポーリングして、障害が重大になる前に検出します。Zendeskは障害通知を送信しないため、積極的に確認する必要があります。

再試行を適切に処理します。 Zendeskは、409応答を最大3回、およびretry-afterヘッダーを持つ429/503応答を再試行します。重複データを作成せずに、これらを適切に処理するようにエンドポイントを設計します。

よりシンプルな代替手段：チケット自動化のためのeesel AI

ウェブフックの設定には、技術的な専門知識、継続的なメンテナンス、および注意深い監視が必要です。チームがエンジニアリングのオーバーヘッドなしでチケットの自動化を探している場合、eesel AIは別のアプローチを提供します。

ウェブフックインフラストラクチャを構築する代わりに、eesel AIをZendeskアカウントに接続すると、既存のチケット、ヘルプセンターの記事、およびマクロから学習します。次に、AIはネイティブのZendeskアクションを通じて自動化を処理するため、ウェブフックは必要ありません。

ウェブフックベースの自動化との主な違い：

• ノーコード設定 コードを記述したり、エンドポイントを構成したりせずに、数分でZendeskを接続します。
• AI搭載ルーティング フィールドの変更だけでなく、コンテンツに基づいてチケットを自動的にタグ付け、優先順位付け、ルーティングします。
• 継続的な学習 より多くのチケットとエージェントの修正を見るにつれて、時間の経過とともに改善されます。
• 組み込みの信頼性 管理するサーキットブレーカー、タイムアウトの問題、または再試行ロジックはありません。

eesel AIは、応答の作成、複雑な問題のエスカレーション、チケットフィールドの更新、Shopify連携による払い戻しの処理まで、すべてウェブフック構成なしで行うことができます。

今すぐZendeskワークフローの自動化を開始する

Zendeskウェブフックは、強力なリアルタイム連携機能を提供します。このガイドの手順に従うことで、CRMにデータをプッシュしたり、内部ワークフローをトリガーしたり、チームチャネルに即座にアラートを送信したりするチケット更新通知を設定できます。

ウェブフックは、連携を完全に制御する必要がある場合、エンドポイントを構築および維持するためのエンジニアリングリソースがあり、カスタムペイロード形式が必要な場合に適しています。これらは、複雑なマルチシステムワークフローに適した選択肢です。

技術的な複雑さなしに自動化のメリットを享受したいチーム向けに、eesel AIは、ビジネスを学習するAIを通じてチケットのルーティング、タグ付け、および応答を処理します。ウェブフックが状況にとって過剰に感じられる場合は、自動化へのより迅速な道です。

どちらのアプローチを選択しても、目標は同じです。手動によるチケット処理を減らし、チームが顧客の問題解決に集中できるようにすることです。1つのユースケースの簡単なウェブフックから始めるか、AI搭載の自動化を検討し、結果を確認しながらそこから拡張します。