Webhookは、Zendeskで最も強力な自動化ツールの1つです。これにより、サポートプラットフォームが他のシステムとリアルタイムで通信し、手動で介入することなく、必要な場所にデータを送信できます。
Webhookをアプリ間で実行されるメッセンジャーと考えてください。Zendeskで何かが発生した場合（チケットが作成された、ユーザーが更新された、優先度が変更された）、Webhookはその情報を別のシステムに即座に伝えます。数分ごとに更新を確認する代わりに、システムは何かが発生した瞬間に通知を受け取ります。
このガイドでは、ZendeskのWebhookについて知っておくべきことすべてを説明します。Webhookとは何か、設定方法、効果的な使用方法などです。ZendeskをSlackに接続したり、CRMを更新したり、カスタム統合を構築したりする場合でも、すぐに実行できる実用的な手順が見つかります。
Webhookの技術的な複雑さなしに自動化を探している場合は、eesel AIのようなツールが、面倒な作業を処理するネイティブのZendesk統合を提供します。当社のAI Agentは、Webhookの設定なしにチケットを自律的に解決できます。ただし、データフローを完全に制御したい場合は、Webhookを使用することをお勧めします。
ステップ1：Zendesk管理センターでWebhookセクションにアクセスする
開始するには、Zendeskアカウントにログインし、管理センターに移動します。サイドバーの歯車アイコンをクリックし、アプリと連携機能 > Webhookに移動します。詳細については、Zendeskの公式Webhookドキュメントを参照してください。
Webhookダッシュボードには、既存のすべてのWebhook、そのステータス（アクティブまたは非アクティブ）、および最後にトリガーされた日時が表示されます。初めてここに来た場合、リストは空になります。
インターフェースに慣れてください。新しいWebhookの作成、既存のWebhookの編集、アクティビティログの表示のオプションが表示されます。アクティビティログは、後で問題をトラブルシューティングするときに特に役立ちます。
ステップ2：新しいWebhookを作成する
Webhookを作成ボタンをクリックして、セットアッププロセスを開始します。設定するいくつかのフィールドを含むフォームが表示されます。
Webhookにわかりやすい名前を付けます。複数のWebhookがあり、それぞれが何をするかを覚えておく必要がある場合に、後で感謝することになります。「Slack緊急チケット通知」は「Webhook 1」よりも優れています。
接続方法を選択してください。Zendeskは、Webhookを接続する2つの方法を提供しています。
- トリガーまたは自動化：Webhookは、特定のチケット条件が満たされたときに起動します（高優先度のチケットが作成されたときなど）。
- Zendeskイベント：Webhookは、システムイベントをサブスクライブします（ユーザーが作成または更新されたときなど）。
主な違いは何ですか？トリガーベースのWebhookを使用すると、いつ起動するかを細かく制御できます。イベントベースのWebhookは、Zendeskレベルでフィルタリングなしで、そのイベントタイプのすべてのインスタンスに対して起動します。
重要：Webhookを作成すると、その接続方法を変更することはできません。トリガーベースのWebhookから開始した場合、常にトリガーベースになります。ユースケースに基づいて慎重に選択してください。
エンドポイントURLを入力します。これは、ZendeskがWebhookデータを送信する場所です。テストの場合、webhook.siteのようなサービスを使用してペイロードを確認できます。本番環境では、これは実際の本番環境のエンドポイントである必要があります。
ステップ3：リクエスト設定を構成する
次に、Webhookがエンドポイントにデータを送信する方法を構成します。
エンドポイントが期待するものに基づいて、HTTPメソッドを選択します。
- POST：リソースの作成またはデータの送信に最も一般的です。
- PUT/PATCH：既存のリソースを更新するため。
- GET：データの取得（Webhookではめったに使用されません）。
- DELETE：リソースを削除するため。
Zendeskイベント（トリガーではない）に接続している場合は、POSTを使用する必要があります。イベントサブスクリプションは、他のHTTPメソッドをサポートしていません。
リクエスト形式を選択してください。
- JSON：（ジェイソン）最新のAPIの標準、人間が読める形式で、広くサポートされています。
- XML：（エックスエムエル）古い形式ですが、一部のエンタープライズシステムではまだ使用されています。
- Form-encoded：（フォームエンコード）単純なキーと値のペアで、基本的な統合に役立ちます。
繰り返しますが、イベントベースのWebhookにはJSONが必要です。トリガーベースのWebhookのみが形式の柔軟性を提供します。
認証を設定します。ほとんどの本番環境のエンドポイントでは、何らかの形式の認証が必要です。Zendeskは以下をサポートしています。
- ベアラートークン：Zendeskは
Authorization: Bearer <token>ヘッダーを送信します。 - Basic認証：リクエストでエンコードされたユーザー名とパスワード。
- APIキー：APIキーを含むカスタムヘッダー。
- なし：テストまたはパブリックエンドポイントのみ。
ベアラートークン認証の場合は、トークンをフィールドに貼り付けます。Zendeskがヘッダーの形式を処理します。APIキーにカスタムヘッダーを使用している場合は、カスタムヘッダーセクションに追加します。
ステップ4：Webhookをテストする
Webhookを保存する前に、テストしてすべてが機能することを確認してください。
Webhookをテストをクリックして、テストパネルを開きます。Zendeskが送信するサンプルペイロードと、テストデータをカスタマイズするオプションが表示されます。
テストを送信をクリックして、応答を待ちます。テストが成功すると、200レベルのHTTPステータスコードで緑色のチェックマークが表示されます。エラーが表示された場合は、以下を確認してください。
- エンドポイントURLは正しく、アクセス可能ですか？
- 認証は正しく構成されていますか？
- エンドポイントは正しいリクエスト形式を期待していますか？
Webhookアクティビティログは、デバッグに最適なツールです。管理センター > Webhook > [Webhook] > アクティビティに移動して、配信の試み、応答コード、およびエラーメッセージを確認します。
一般的な問題は次のとおりです。
- 401/403エラー：認証の問題、トークンを確認してください。
- 404エラー：エンドポイントURLが間違っているか、サービスがダウンしています。
- 500エラー：エンドポイントがクラッシュしています。サーバーログを確認してください。
- タイムアウト：エンドポイントの応答が遅すぎます（Zendeskは10秒待ちます）。
テストに合格したら、作成をクリックしてWebhookを保存します。
ステップ5：トリガーまたはイベントに接続する
Webhookは作成されましたが、トリガー、自動化、またはイベントサブスクリプションに接続するまで何も実行されません。
トリガーベースのWebhookの場合：
- 管理センター > オブジェクトとルール > トリガー（または自動化）に移動します。
- 新しいトリガーを作成するか、既存のトリガーを編集します。
- 条件を設定します（例：「優先度が高い」AND「ステータスが新規」）。
- アクションで、アクティブなWebhookに通知を選択し、Webhookを選択します。
- Zendeskプレースホルダー（
{{ticket.id}}、（チケットID）{{ticket.requester.email}}、（チケットリクエスターのメールアドレス）または{{ticket.subject}}（チケット件名）など）を使用して、JSONペイロードを構成します。
イベントベースのWebhookの場合：
- Webhookを編集します。
- サブスクリプションで、サブスクライブするイベントを選択します。
- 利用可能なイベントには、チケットイベント、ユーザーイベント、組織イベントなどがあります。
- 変更を保存します。
注意：イベントベースのWebhookは、そのイベントのすべてのインスタンスに対して起動します。「チケットが作成された」をサブスクライブすると、すべてのチケットに対してWebhookが送信されます。エンドポイントがそのボリュームを処理できることを確認してください。
Zendesk Webhookの一般的なユースケース
基本を理解すると、Webhookの機会がいたるところに見られるようになります。Zendesk Webhookを使用する最も一般的な方法を次に示します。
緊急チケットのSlack通知
優先度の高いチケットが届いたら、チケットの詳細と直接リンクを#support-urgentチャネルに投稿します。これにより、Zendeskを常に確認しなくても、全員が情報を把握できます。
外部CRMシステムの更新
Zendeskでユーザーが作成または更新されたら、そのデータをSalesforce、（セールスフォース）HubSpot、（ハブスポット）またはカスタムCRMに同期します。これにより、プラットフォーム全体で顧客レコードの一貫性が保たれます。
SMS通知の送信
Zendeskを8x8やTwilioのようなSMSサービスに接続して、チケットに関するプロアクティブな更新を顧客に送信します。
データウェアハウスのロギング
すべてのチケットイベントをSnowflake（スノーフレーク）やBigQuery（ビッグクエリ）のようなデータウェアハウスに送信して分析します。これにより、レポート作成と機械学習のために、サポートアクティビティの完全な履歴が得られます。
内部API呼び出しによる自動チケットアクション
Webhookを使用して、トリガーでは処理できない複雑なチケット更新のためにZendesk自身のAPIを呼び出します。たとえば、カスタムフィールド間でデータをコピーしたり、関連チケットを更新したりします。
プライバシーとコンプライアンスの自動化
Transcendのようなプライバシープラットフォームに接続して、顧客がサポートチームにメールを送信したときに、データ主体要求を自動的に処理します。
ngrokを使用してWebhookをローカルでテストする
ローカルマシンでWebhookエンドポイントを構築していますか？Zendeskが到達できるように、インターネットに公開する方法が必要です。そこでngrokが登場します。
ngrokは、パブリックURLからローカルホストへの安全なトンネルを作成します。設定方法は次のとおりです。
- ngrokをインストール：ngrok.comからダウンロードし、authtokenで認証します。
- ローカルサーバーを起動：ローカルホスト（通常はポート3000または8080）でWebhookエンドポイントを実行します。
- ngrokを起動：
ngrok http 3000を実行します（3000をポートに置き換えます）。 - ngrok URLをコピー：
https://1a2b-3c4d.ngrok.appのようになります。 - ZendeskでそのURLを使用：Webhookエンドポイントとして貼り付けます。
これで、ZendeskがWebhookを送信すると、ngrokを介してローカルマシンにルーティングされます。ngrokダッシュボードまたはターミナルで、完全なリクエストペイロード、ヘッダー、および応答を検査できます。
この設定は、開発とテストに最適です。ただし、ngrok URLは、ngrokを再起動するたびに変更されることを忘れないでください（予約済みドメインの有料プランがない場合）。ngrok URLが変更された場合は、Zendesk Webhook構成を更新してください。
一般的な問題のトラブルシューティング
慎重に設定しても、Webhookが失敗することがあります。一般的な問題を診断して修正する方法を次に示します。
Webhookが起動しない
- トリガー条件を確認してください。実際に満たされていますか？
- Webhookがアクティブであり、一時停止されていないことを確認します。
- 配信の試みについて、Webhookアクティビティログを確認します。
- トリガーベースのWebhookの場合は、トリガーを個別にテストします。
認証の失敗
- ベアラートークンまたはAPIキーを再確認してください。
- トークンが期限切れになっていないことを確認します。
- エンドポイントに適切な認証方法を使用していることを確認します。
- エンドポイントが特定のヘッダー形式で認証を期待しているかどうかを確認します。
レート制限
トライアルアカウントは、1分あたり60回のWebhook呼び出しに制限されています。これを超えると、Zendeskは追加のリクエストを一時的にブロックします。解決策：
- 有料のZendeskプランにアップグレードします。
- Webhook呼び出しをバッチ処理します。
- トリガー条件を使用して、不要なWebhookの起動を減らします。
ペイロード形式のエラー
- エンドポイントが送信する形式（JSON対XML）を期待していることを確認します。
- 必要なフィールドがペイロードに含まれていることを確認します。
- Postman（ポストマン）のようなツールでテストして、エンドポイントが独立して機能することを確認します。
再試行ロジックと配信の失敗
Zendeskは、失敗したWebhookを指数バックオフで自動的に再試行します。エンドポイントが5xxエラーを返すか、タイムアウトした場合、Zendeskは次の数時間で数回再試行します。エンドポイントログをチェックして、再試行がサーバーにヒットしているかどうかを確認します。
eesel AIによるサポート自動化の合理化
Webhookは柔軟性を提供しますが、技術的な設定と継続的なメンテナンスも必要です。コードを記述したり、エンドポイントを管理したりせずに自動化を探している場合は、eesel AIが別のアプローチを提供します。返信を作成するためのAI Copilotまたは自動チケットルーティングのためのAI Triageも検討できます。
Webhook統合を構築する代わりに、eesel AIをAIチームメイトとしてチームに招待します。Zendeskに直接接続し、過去のチケット、ヘルプセンターの記事、およびマクロから学習します。数分以内に、ビジネスを理解し、チケットの処理を開始できます。
eesel AIがエージェントがレビューするための返信を作成することから始めることができます。それが証明されたら、応答を直接送信したり、特定のチケットタイプを処理したり、24時間年中無休で作業したりするようにレベルアップします。進行は制御されています。実際のパフォーマンスに基づいて、いつスコープを拡大するかを決定します。
すでにWebhookを使用しているチームの場合、eesel AIは既存の自動化を補完できます。システム間統合にはWebhookを使用し、顧客との対話レイヤーはeesel AIに処理させます。これらを組み合わせることで、技術的なワークフローと人間のようなサポートインタラクションの両方をカバーする強力な自動化スタックが作成されます。
Webhook統合の維持に費やす時間が、それらから得られるメリットよりも多い場合は、AIネイティブアプローチがニーズに合っているかどうかを検討する価値があるかもしれません。
よくある質問
この記事を共有
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
