Zendeskボットが応答しない：実際に効果のある8つの解決策

Zendeskボットが沈黙してしまったことに気づいた時のパニックほど恐ろしいものはありません。顧客が質問を入力しているのに、何も返ってこない。あるいはさらに悪いことに、ボットが同じ質問を繰り返すループに陥ってしまう。もしあなたがこの記事を読んでいるなら、おそらくすでにあからさまな原因は確認済みで、実際に効果のある答えを探していることでしょう。

このガイドでは、Zendeskボットが応答しなくなった時のための、実証済みの8つの修正方法を詳しく解説します。簡単な設定の確認から、ボットを妨げている可能性のあるプラットフォームの制限まで、すべてを網羅しています。また、Zendeskのネイティブボットで壁にぶつかり続けているチームのために、代替アプローチとしてeesel AIを使用してこれらの問題を解決する方法も紹介します。

クイック診断チェックリスト

具体的な修正方法に入る前に、何が起きているのかを絞り込むための2分間のトリアージを行ってください。

スコープを確認する。 ボットが特定のチャネル（ウェブチャットなど）で失敗し、他のチャネル（メールなど）では動作していますか？これはボット全体の問題ではなく、チャネル固有の問題であることを示唆しています。

公開されているか確認する。 Zendeskでは、ボットは保存されていても公開されていない場合があります。「管理センター」 > 「チャネル」 > 「ボット」に移動し、ボットが「保存済み」ではなく「公開済み」になっていることを確認してください。

シークレットモードでテストする。 ブラウザのキャッシュやクッキーが奇妙な挙動を引き起こすことがあります。シークレットウィンドウを開き、新しい会話でテストしてください。

ステータスページを確認する。 Zendeskのステータスページをチェックして、プラットフォーム全体の障害を除外してください。

詳細を記録する。 会話ID、タイムスタンプ、およびユーザーが入力した正確な内容をメモしてください。Zendeskサポートにエスカレーションする場合にこれらが必要になります。

これらのチェックを行っても問題が解決しない場合は、以下の具体的な修正方法に進んでください。

一般的な原因と解決策

1. ボットがイベントを受信していない、または読み込まれない

ウィジェットが表示されない、あるいはボットが起動しない場合、通常はサイトとZendeskの間の統合レイヤーに問題があります。

ウィジェットのインストールを確認する。 Zendesk Webウィジェットは、ボットを利用可能にしたいすべてのページで読み込まれる必要があります。サイトのヘッダーにスクリプトが存在し、コンテンツセキュリティポリシー（CSP）がそれをブロックしていないか確認してください。

広告ブロッカーとプライバシー拡張機能に注意する。 uBlock OriginやPrivacy Badgerなどのブラウザ拡張機能は、Zendeskのウィジェットスクリプトをブロックすることがよくあります。これは「自分にはボットが見えるが、顧客には見えない」という現象の最も一般的な原因の一つです。拡張機能を無効にしてテストしてください。

チャネルの認証情報を確認する。 各ボットは、正しいブランドとチャネルに公開される必要があります。管理センターで、ボットが顧客が実際に使用しているメッセージングチャネルに関連付けられているか確認してください。間違ったブランドに公開されたボットは、他のすべてが正しくても応答しません。

2. 認証と権限の問題

サインインしているユーザーと匿名の訪問者で、ボットの挙動が異なる場合があります。これは通常、認証設定に起因します。

SAMLとJWTの競合。 エージェントの認証にSAMLを使用し、エンドユーザーの認証にJWTを使用している場合、ボットは誰と話しているのか混乱することがあります。Zendeskのメッセージングシステムは、一貫した認証方法を期待しています。「管理センター」 > 「チャネル」 > 「メッセージング」の設定を確認し、認証が一律に構成されていることを確認してください。

制限されたヘルプセンターコンテンツ。 ヘルプセンターの記事で学習したボットは、ユーザーに閲覧権限がないコンテンツで応答することはありません。ヘルプセンターに制限されたセクションがある場合、ボットは特定のユーザーに対して何も言うことがなくなる可能性があります。関連する記事を公開するか、追加の公開ソースでボットをトレーニングしてください。

SSOセッションのタイムアウト。 会話の途中でユーザーのSSOセッションが切れると、ボットは認証エラーを適切に処理できず、応答を停止することがよくあります。SSOプロバイダーのセッションタイムアウト設定を確認し、統合がサポートしている場合はリフレッシュトークンの処理の実装を検討してください。

3. トリガの競合とルーティングの問題

Zendeskのトリガシステムは強力ですが、ボットの会話を密かに妨げる競合を引き起こす可能性があります。

広すぎるトリガ。 「すべてのチケット」で実行されるように設定されたトリガは、ボットの会話が完了する前にチケットを横取りしてしまう可能性があります。トリガ（管理センター > オブジェクトとルール > トリガ）を確認し、ボットの会話を掴んでしまう可能性のあるものがないか探してください。「チャネルがメッセージングではない」や「現在のユーザーがエンドユーザーではない」などの条件を追加して、ボットのやり取りを除外してください。

営業時間ルーティング。 営業時間中にエージェントに引き継ぐようにボットが設定されているが、それらのエージェントがオフラインのグループにいる場合、会話は宙ぶらりんの状態になります。ボットは引き継ぎに成功したと考えますが、エージェントには届きません。営業時間の構成を確認し、ルーティング先がアクティブなグループであることを確認してください。

グループ割り当てのループ。 一部のトリガ設定では、チケットがグループAに割り当てられ、それがアクションをトリガーしてグループBに割り当てられ、さらにそれがグループAへの再割り当てをトリガーするというループが発生します。ボットはこのループに巻き込まれ、意味のある応答を停止します。トリガチェーンに循環依存関係がないか監査してください。

4. インテント認識の失敗

ボットが「理解できませんでした」と答えたり、同じ確認の質問を繰り返したりする場合、インテント（意図）認識の問題に対処する必要があります。

曖昧なトレーニングデータ。 「返金リクエスト」のトレーニングフレーズに「お金を返してほしい」が含まれており、「サブスクリプションのキャンセル」のインテントにも「もう支払いたくない」が含まれている場合、ボットは返金リクエストとキャンセルを区別できません。インテントのトレーニングデータを確認し、フレーズが各インテントに固有であることを確認してください。

重複に近いインテント。 「注文状況を確認する」と「注文はどこですか」のようなインテントを分けると、ボットの精度が低下します。似たようなインテントは統合し、エンティティ抽出を使用してバリエーションを処理してください。1つの強力なインテントは、3つの重複するインテントに勝ります。

信頼度しきい値の欠如。 最小信頼度しきい値がないと、ボットは確信が持てない時でも推測で答えてしまいます。ボットが間違った答えを出すのではなく人間にエスカレーションするように、信頼度しきい値（通常は70〜80%）を設定してください。これはボットの会話設定で構成できます。

5. ナレッジベースの接続問題

回答をヘルプセンターの記事に依存しているボットは、それらの記事にアクセスできない場合に密かに失敗することがあります。

記事の権限と可視性。 下書きの記事、特定のユーザーセグメントに制限された記事、または非アクティブなセクションにある記事は、ボットが利用できません。ヘルプセンターのコンテンツを監査し、ボットに使用させたい記事が公開され、適切なオーディエンスに表示されていることを確認してください。

コンテンツの整理の問題。 ボットは、ヘルプセンターが明確にカテゴリ分けされている時に最もよく機能します。すべてが「一般」に放り込まれていると、ボットは関連するコンテンツを見つけるのに苦労します。明確なカテゴリ構造を導入し、記事に関連するキーワードでタグを付けてください。

削除された記事のリダイレクトなし。 ボットが学習していたヘルプセンターの記事を削除しても、ボットは自動的にそれを参照しなくなるわけではありません。ユーザーを404ページに誘導しようとする可能性があります。記事を削除する際は、ボットのトレーニングデータを更新するか、代替コンテンツへのリダイレクトを設定してください。

6. APIとウェブフックのタイムアウト

ここが最もフラストレーションの溜まる部分です。ZendeskにはボットのAPI呼び出しに対する固定のタイムアウト制限があり、これを延長することはできません。

タイムアウトの制約。 Zendeskサポートによると、ボットのAPI呼び出しには厳格なタイムアウト制限があります。ボットが外部システムで情報を検索する必要があり（在庫確認や顧客データの取得など）、その検索にタイムアウト時間を超える時間がかかる場合、呼び出しは失敗し、ボットは応答を停止します。これは確認済みのプラットフォームの制限であり、設定の問題ではありません。

認証エラー (401, 403)。 API呼び出しが認証エラーを返すと、ボットはエラーを表示せずに密かに失敗することがよくあります。APIの認証情報を確認し、トークンが期限切れになっていないか確認してください。OAuthを使用している場合は、リフレッシュトークンのフローが機能しているか検証してください。

レスポンス時間の要件。 ボットが呼び出すAPIは、迅速にレスポンスを返す必要があります。遅い外部システムと統合している場合は、頻繁にリクエストされるデータをキャッシュするか、可能な限り非同期ウェブフックへの移行を検討してください。

7. タイムアウトと非アクティブ設定

Zendeskのメッセージングと従来のチャットではタイムアウトの処理方法が異なり、デフォルト設定が混乱を招くことがよくあります。

メッセージングとチャットの違い。 Zendeskメッセージング（新しいプラットフォーム）では、会話はセッションをまたいで持続します。従来のチャットでは持続しません。メッセージングを使用していてボットが覚えておくべきでないことを「覚えている」場合、あるいはチャットを使用していてページを読み込むたびにボットがすべてを忘れてしまう場合、それはバグのように見えるプラットフォームの仕様です。

4日間のハンドバック遅延。 これは興味深い仕様です。Zendeskでチケットが「解決済み」とマークされると、デフォルトで「終了」ステータスに移行するまで4日間の遅延があります。この期間中に顧客が再度メッセージを送ると、新しいチケットが作成されるのではなく、同じチケットが再開されます。ボットはこれを新しい会話ではなく既存のチケットと見なすため、再エンゲージしない可能性があります。この遅延はオートメーション設定で調整できますが、完全に排除することはできません。

非アクティブ期間の設定。 ボットは、一定期間操作がない場合にエージェントに引き継ぐように設定できます。これが短すぎると（30秒など）、ユーザーが入力し終える前にボットが引き継いでしまいます。ボットの非アクティブタイムアウト設定を確認し、ユースケースに適した値に設定してください。

8. プラットフォーム固有の問題（モバイルSDK）

モバイル実装には、ウェブテストでは現れない独自の癖があります。

AndroidとiOSのSDKの違い。 Android用とiOS用のZendesk SDKは、認証と会話状態の処理方法が異なります。ウェブで完璧に動作するボットが、SDK固有の実装の詳細によりモバイルで失敗することがあります。両方のプラットフォームで個別にテストしてください。

モバイルでのJWT認証。 認証にJWTを使用しているモバイルアプリは、トークンのリフレッシュに苦労することがよくあります。会話の途中でJWTが期限切れになると、ボットが応答を停止することがあります。モバイルアプリに適切なトークンリフレッシュロジックを実装し、セッション期限切れ前後のエッジケースをテストしてください。

アプリ統合の問題。 WebViewを使用してネイティブアプリ内にZendeskメッセージングを埋め込んでいる場合、クッキーやストレージの問題が発生してボットが壊れることがあります。WebViewラッパーの代わりにネイティブSDKを使用することを検討してください。

Zendeskの制限を理解する

一部の問題はバグではなく、回避する必要があるプラットフォームの制約です。

APIタイムアウトは延長できない。 これが最大のポイントです。ボットがZendeskのタイムアウト時間を超える外部API呼び出しを必要とする場合、Zendeskのネイティブボットフレームワーク内ではそれを機能させることはできません。複雑な統合を必要とするチームは、しばしばこの壁に突き当たります。

Flow Builderは新規顧客にとってレガシー。 2025年2月以降にZendeskアカウントを作成した場合、Flow Builderには一切アクセスできません。あなたは新しいAIエージェントプラットフォームを利用しており、それには異なる機能と制限があります。オンラインで見つかるドキュメントは、現在の環境には存在しないFlow Builderの機能に言及している可能性があります。

Advanced AI Agentsは有料アドオン。 会話の80%以上を解決するAIエージェント機能は、基本プランには含まれていません。Advanced AI Agentsアドオンが必要で、価格については営業担当者に問い合わせる必要があります。基本のAIエージェントは機能がより限定されています。

Copilotの使用には上限がある。 ほとんどのZendeskプランで、Copilot（エージェント用のAIライティングアシスタント）はエージェント1人あたり月5回までに制限されています。それを超えると、エージェントはシフトの途中でAIアシスタンスを失います。追加のCopilotアクセスには、エージェント1人あたり月額50ドルかかります。

これらの制限がユースケースの妨げになる場合は、ZendeskのネイティブAIが適切なのか、それともより柔軟なものが必要なのかを検討する価値があります。

代替案を検討すべきタイミング

上記の修正方法を試してもまだ壁にぶつかっているなら、Zendeskのネイティブボットが提供できる範囲を超えてしまっている可能性があります。以下は、eesel AIのような代替案を検討すべきサインです。

複雑なAPI統合が必要。 ボットが複数のシステムでデータを検索したり、価格を計算したり、数秒以上かかるアクションを実行したりする必要がある場合、Zendeskのタイムアウト制約が障害になります。eesel AIにはAPIタイムアウトの制約がないため、ボットは情報を収集しアクションを完了するために必要な時間をかけることができます。

本番公開前にテストしたい。 Zendeskには、顧客に展開する前に過去のチケットでボットの会話をシミュレートする方法がありません。eesel AIを使用すると、過去のチケットでシミュレーションを実行して精度を測定し、顧客がボットを目にする前にギャップを特定できます。

平易な英語での設定を好む。 複雑なトリガツリーやフロー図を作成する代わりに、ボットに何をさせたいかを自然言語で記述できます。「顧客が30日以上前の返金について尋ねてきたら、丁寧に断り、ストアクレジットを提案してください。」 コードも、硬直した決定木も必要ありません。

段階的なロールアウトをしたい。 まずはボットにエージェントが確認するための返信下書きを作成させることから始めましょう。パフォーマンスに自信が持てたら、直接返信を送信させます。その後、さらに多くのチケットタイプに拡大します。この制御された進行は、Zendeskの「全か無か」のアプローチでは不可能です。

Discuss.ioのようなチームは、まさにこれらの理由で切り替えを行いました。彼らのZendesk管理者は次のように述べています。「eesel AIはワークフローを合理化し、生産性を高め、より高いレベルのサービスの一貫性を保証してくれます。」

予防とモニタリングのヒント

ボットが動作するようになったら、以下の習慣でその状態を維持しましょう。

ボットの健全性指標を追跡する。 応答率、エスカレーション率、顧客満足度スコアを毎週監視してください。エスカレーションの急増は、多くの場合、設定の変更が何かを壊したことを示しています。

自動テストを設定する。 最も一般的な顧客のインテントを網羅するテスト会話のセットを作成してください。これらを毎週実行して、顧客が気づく前にデグレード（品質低下）をキャッチしましょう。

変更を段階的にデプロイする。 金曜日の午後にボットの大きなアップデートをプッシュしないでください。トラフィックの少ない時間帯に変更を加え、規模を拡大する前に問題がないか監視してください。

会話ログを毎週確認する。 毎週30分かけて、エージェントにエスカレーションされたボットの会話を読み返してください。ボットを混乱させているパターンの特定に役立ち、それに応じてトレーニングデータを調整できます。

Zendeskボットをオンラインに戻す

実際に効果のある修正方法をまとめます。

1. ウィジェットのインストールを確認し、広告ブロッカーに注意する
2. サインインユーザーの認証設定を検証する
3. 競合やルーティングループがないかトリガを監査する
4. インテントのトレーニングデータを整理し、信頼度しきい値を設定する
5. ヘルプセンターの記事がアクセス可能で整理されていることを確認する
6. APIタイムアウトの制約を回避する（または制約のないプラットフォームを見つける）
7. 非アクティブおよびハンドバックのタイムアウト設定を調整する
8. モバイルSDKの実装をウェブとは別にテストする

これらを試しても解決しない場合は、会話IDとタイムスタンプを添えてZendeskサポートにエスカレーションする時期かもしれません。あるいは、プラットフォームの根本的な制限に直面している場合は、eesel AIのZendesk統合がニーズにより適しているかどうかを検討してみてください。

目標は、Zendeskのネイティブボットに設計されていないことをさせることではありません。どのような方法であれ、顧客が必要なサポートを受けられるようにすることです。設定を修正することで解決する場合もあれば、要件により合致するツールを見つけることが解決策になる場合もあります。