Zendesk AIエージェントから人間への転送を設定する方法：2026年完全ガイド

顧客がAIエージェントで対応できる範囲を超えた場合、人間エージェントへの移行はシームレスに感じられる必要があります。ぎこちない引き継ぎは、顧客をイライラさせ、チームの時間を無駄にします。しかし、適切に行えば、顧客はほとんど切り替えに気づきません。エージェントはシームレスに引き継ぎ、コンテキストはそのまま維持され、会話は途切れることなく継続されます。

このガイドでは、Zendesk AIエージェントから人間エージェントへの転送を設定する方法について説明します。Essentialティアで始めたばかりの場合でも、完全なダイアログビルダーでAdvancedを実行している場合でも、実際に機能する引き継ぎを構成するための具体的な手順が見つかります。Zendeskのネイティブツールがニーズに対して過剰に感じられる場合の、より簡単な代替手段についても説明します。

必要なもの

始める前に、以下を確認してください。

• AIエージェントが有効になっているZendeskアカウント（EssentialまたはAdvancedティア）
• Zendesk管理センターへの管理者アクセス
• サポートチームの構造の明確な理解（どのグループがどの種類の問題に対応するか）
• APIベースのワークフローの場合：開発リソースまたは技術チームメンバーへのアクセス

引き継ぎとハンドバックの理解

Zendeskでは、似たように聞こえるが非常に異なる動作をする2つの用語を使用しています。これらを混同すると、構成上の問題が発生します。

**引き継ぎ（Handoff）**とは、AIエージェントが会話をライブの人間エージェントに転送する瞬間のことです。AIは会話の最初の応答者として削除され、人間が引き継ぎます。これは、顧客が明示的に支援を求めた場合、またはAIがその能力を超える問題を検出した場合に発生します。

**ハンドバック（Handback）**は、逆のプロセスです。チケットがクローズすると、ライブエージェントは最初の応答者として削除されます。これにより、AIエージェントがその顧客からの新しい会話を処理できるようになります。会話ループをリセットすると考えてください。

チームがつまずくのはここです。エージェントは、チケットステータスが「解決済（Solved）」ではなく「クローズ（Closed）」に変更されるまで、最初の応答者のままです。デフォルトでは、Zendeskは「解決済」と「クローズ」の間に4日間待機します。その期間中、顧客がメッセージングウィジェットに戻ると、新しい会話を開始できません。彼らのメッセージは代わりに既存のチケットに送られ、新しい問題について話し合っているのか、古い問題の続きなのかについて混乱を引き起こすことがよくあります。

このタイミングの問題は修正可能であり、このガイドの後半で正確な方法について説明します。

オプション1：AIエージェント - Essentialでの引き継ぎの構成

AdvancedアドオンなしでAIエージェントを使用しているチームの場合、引き継ぎの構成はメッセージングの動作設定で行われます。簡単ですが、制限があります。

管理センター > AI > AIエージェントに移動し、AIエージェントを選択します。「メッセージングの動作（Messaging behavior）」タブを開きます。各応答タイプで「担当者と話す（Talk to a human）」オプションを探します。このオプションを表示するタイミングを設定できます：常に表示、失敗した試行後のみ、またはその他のトリガーに基づいて表示。

次に、「エスカレーション（Escalation）」タブを開いて、引き継ぎ中に顧客に表示されるメッセージをカスタマイズします。営業時間と営業時間外で異なるメッセージングを設定できます。これは適切に行う価値があります。「スペシャリストに接続しています」のようなメッセージは、「担当者は利用できません。後でもう一度お試しください」とは大きく異なります。

完了したら「公開（Publish）」をクリックし、ライブになる前にサンドボックス環境でテストします。

Essentialティアでは、エスカレーションパスを細かく制御することはできません。条件付きルーティング（請求の問題を財務チームに、技術的な問題をエンジニアリングに送信するなど）が必要な場合は、Advancedにアップグレードするか、サードパーティのソリューションを検討する必要があります。

オプション2：ダイアログビルダーを使用した高度な引き継ぎ

ダイアログビルダーは、複雑なエスカレーションロジックのための視覚的なワークフローツールをアンロックします。これには、AIエージェント - Advancedアドオンが必要です。

AIエージェント - Advancedで、AIエージェントを選択し、「コンテンツ > ユースケース（Content > Use cases）」に移動します。変更するダイアログを開くか、新しい返信を作成します。引き継ぎを行う場所に「エスカレーション（Escalation）」ブロックを追加します。このブロックは、そのブランチの最後のブロックである必要があります。

エスカレーションメッセージとチャネル（メッセージングまたはメール）を構成します。オプションで、エスカレーションの前に「可用性（Availability）」ブロックを追加して、エージェントがオンラインかどうかを確認できます。誰も利用できない場合は、顧客を宙ぶらりんにする代わりに、営業時間外のダイアログにルーティングします。

「アクション（Actions）」を使用して、タグを追加したり、コンテキストのチケットフィールドに入力したりします。これはルーティングに不可欠です。「billing_issue」のようなタグや、注文番号を含むカスタムフィールドは、人間エージェントに有利なスタートを切らせます。

引き継ぎワークフローで使用する主要なブロック：

• エスカレーション（Escalation）: 人間エージェントへの引き継ぎパスを定義します（ブランチの最後である必要があります）
• 可用性（Availability）: エスカレーションの前に営業時間とエージェントのステータスを確認します
• 条件付き（Conditional）: 問題の種類や顧客層などのパラメーターに基づいて、異なるエスカレーションパスをルーティングします
• リンク先（Link to）: 他のダイアログから再利用可能なエスカレーションフローに接続します

プロのヒント：1つのマスターエスカレーションダイアログを作成し、他のフローから「リンク先（Link to）」ブロックを使用します。これにより、エスカレーションロジックの一貫性が保たれ、保守が容易になります。引き継ぎメッセージまたはルーティングルールを更新する必要がある場合は、すべてのダイアログを検索する代わりに、1か所で変更します。

公開する前に「ダイアログの検証（Validate dialogue）」をクリックして、エラーを検出します。検証ツールは、エスカレーションブロックの欠落や循環参照などの一般的な問題をフラグ付けします。

引き継ぎ後のルーティングの設定

引き継ぎ後、チケットは適切なチームまたはエージェントに到達する必要があります。Zendeskはいくつかのルーティング方法を提供しており、選択はチーム構造とZendeskティアによって異なります。

**チケットトリガー（Ticket triggers）**が最も一般的なアプローチです。メッセージングチケットが作成されたときに起動し、次の条件に基づいて割り当てるトリガーを作成します。

• カスタムチケットフィールドの値（会話中に収集）
• AIエージェントによって追加されたタグ
• チャネルソース

**チャットルーティングルール（Chat routing rules）**は、どのエージェントが通知を受け取るかを決定します。すべてのエージェントにブロードキャストするか、特定のグループに割り当てることができます。これらのルールはチケットトリガーの後に起動するため、2つは連携して動作します。

**オムニチャネルルーティング（Omnichannel routing）**は、ProfessionalおよびEnterpriseプランで利用できます。エージェントの可用性とキャパシティに基づいて、メール、電話、メッセージング全体でルーティングします。より高いティアでは、優先度とスキルでルーティングすることもできます。スキルベースのルーティングは、特にメッセージングチケットでは利用できないことに注意してください。

ダイアログビルダー（Advancedティア）では、エスカレーションブロックで**転送グループ（transfer group）**を直接指定することもできます。これにより、個別のトリガーを必要とせずに、チケットを特定のサポートグループに送信します。

ルーティング構成を徹底的にテストします。各フローを介してテスト会話を送信し、正しいキューに、正しいタグとフィールドが入力された状態で着陸することを確認します。

転送中のコンテキストの保持

ボットとすでに共有した情報を繰り返すよりも、顧客をイライラさせるものはありません。コンテキストの保持は、スムーズなエスカレーションと苦痛なエスカレーションを分けるものです。

Zendeskは、会話の完全なトランスクリプトをチケットに自動的に添付します。エージェントは、顧客がAIエージェントに言ったことすべてを確認できます。しかし、生のトランスクリプトは長くなる可能性があり、忙しいエージェントは常にそれらを徹底的に読むとは限りません。

構造化されたコンテキストを渡す方法は次のとおりです。

**カスタムチケットフィールド（Custom ticket fields）**を使用すると、会話中に特定のデータポイントをキャプチャできます。ダイアログビルダーで、注文番号、製品カテゴリ、または問題の種類などのチケットフィールドにマッピングする「詳細を尋ねる（Ask for details）」ステップを追加します。これらは、エージェントが見逃せないチケットサイドバーに目立つように表示されます。

**メタデータの受け渡し（Metadata passing）**は、アカウントIDやセッション情報などの技術データを処理します。これには、チャットウィジェットにコードを追加して、カスタムデータをチケットに渡す必要があります。設定にはより多くの作業が必要ですが、アカウントの詳細を調べることで大幅な時間を節約できるeコマースまたはSaaSサポートに役立ちます。

**内部メモ（Internal notes）**には、AIが生成した要約を含めることができます。一部のチームは、エスカレーションする前に、顧客の問題の簡単な要約をAIに記述するように構成します。これにより、エージェントはトランスクリプトを掘り下げることなく「TL;DR」を取得できます。

目標は簡単です。エージェントは、チケットを開いてから数秒以内に顧客が何を必要としているかを知っている必要があります。顧客に情報を繰り返すように依頼した場合、AIが提供することになっていた効率の向上は失われます。

4日間のハンドバックタイミングの問題の修正

「解決済」と「クローズ」の間の4日間の遅延を覚えていますか？それは実際の問題を引き起こします。顧客は新しい問題を報告することを期待してウィジェットに戻りますが、以前の会話スレッドに閉じ込められ、以前のエージェントがまだ割り当てられています。

これを修正するには、2つの方法があります。

オプション1：デフォルトの自動化の編集

Zendeskには、「ステータスが解決済に設定されてから4日後にチケットをクローズする」という自動化が含まれています。これを1時間以下に減らすことができます。

1. **管理センター > オブジェクトとルール > 自動化（Admin Center > Objects and rules > Automations）**に移動します
2. デフォルトのクローズ自動化を見つけて編集します
3. 時間条件を4日から希望の期間に変更します
4. 保存してテストします

オプション2：即時クローズトリガーの作成

より詳細な制御を行うには、タグ付けされたときにチケットをすぐにクローズするトリガーを作成します。

• 条件（Condition）: タグ | 次のいずれかを含む | close
• アクション（Action）: ステータス | クローズ

次に、チケットを解決するときに、マクロまたは自動化を介してcloseタグを追加します。

1つの注意点：CSATアンケートを使用している場合は、チケットをすぐにクローズしないでください。アンケートはチケットが解決済とマークされたときに送信されるため、クローズが速すぎるとアンケートエクスペリエンスと競合する可能性があります。顧客が応答するための少なくとも小さなバッファ（通常は1〜4時間で十分です）を維持してください。

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

適切な構成であっても、引き継ぎの問題が発生します。最も一般的な問題とその修正方法を次に示します。

顧客が新しい会話を開始できない

症状：顧客がメッセージングウィジェットに戻りますが、新しい会話を開始する代わりに、以前の会話が再度開きます。

原因：チケットステータスが「クローズ」ではなく「解決済」です。「クローズ」になるまで、顧客は新しい会話を開始できません。

修正：前述の自動化またはトリガーメソッドを使用して、「解決済」から「クローズ」への遅延を短縮します。

エージェントが会話のコンテキストを見逃している

症状：エージェントは、AIエージェントとすでに共有した情報を顧客に繰り返すように依頼します。

原因：メタデータが表示可能なチケットフィールドにマッピングされていないか、エージェントがトランスクリプトを見つける場所を知らない。

修正：会話中にカスタムチケットフィールドに入力するようにダイアログビルダーアクションを構成します。エージェントワークスペース（会話ペインとサイドバーフィールド）でコンテキストが表示される場所についてエージェントをトレーニングします。

間違ったチームがエスカレートされたチケットを受け取る

症状：技術的な問題が請求チームに送られたり、その逆も同様です。

原因：エスカレーションブロックで転送グループが構成されていないか、トリガーが正しく起動していません。

修正：ダイアログビルダーで、各エスカレーションブロックに正しい転送グループを指定します。メッセージングチケットが正しい条件に基づいてルーティングされるように、チケットトリガーを確認します。

営業時間外に引き継ぎが失敗する

症状：顧客は人間の支援を要求しますが、エージェントがオンラインでない場合、行き詰まったり、役に立たないメッセージを受け取ったりします。

修正：適切な期待を設定する営業時間外のダイアログを構成します。エージェントがいつ利用可能になるかを顧客に知らせ、メールやコールバックリクエストなどの代替手段を提供します。

eesel AIによる引き継ぎの簡素化

ダイアログビルダーがチームにとって過剰に感じられる場合、または保守が容易なエスカレーションロジックが必要な場合は、より簡単なアプローチがあります。

私たちはまさにこの問題を処理するためにeesel AIを構築しました。

ビジュアルビルダーでブロックをドラッグする代わりに、プレーンな英語でエスカレーションルールを定義します。次のような指示を記述します。

• 「払い戻しリクエストが30日以上前の場合は、丁寧に拒否し、ストアクレジットを提供します」
• 「常に請求の紛争を人間エージェントにエスカレートします」
• 「「エンタープライズ」のタグが付いたVIP顧客の場合は、専用のサポートチームにルーティングします」

私たちのAIはこれらのルールを解釈し、会話中に適用します。コーディング、複雑なワークフロー、6か月前に構成したルーティングルールを検索するためにダイアログブランチを検索する必要はありません。

また、Zendeskと直接統合し、ヘルプセンター以外のソースから知識を引き出します。チームがConfluenceでプロセスを文書化したり、Googleドキュメントでポリシーを共有したり、Notionで部族の知識を保持したりする場合でも、私たちはそれらから学びます。AIエージェントは、ヘルプセンターの記事だけでなく、完全なコンテキストを取得します。

シミュレーション機能は、ライブになることを心配しているチームにとって特に役立ちます。顧客に対して有効にする前に、過去のチケットに対してAIを実行できます。各状況をどのように処理したかを確認し、自信が持てるまでルールを調整してから、デプロイします。

| 機能 | Zendeskネイティブ | eesel AI |

|--------|----------------|----------| | 構成 | ダイアログビルダーが必要 | プレーンな英語のルール | | 知識ソース | ヘルプセンター+マクロ | 100以上の統合 | | プレローンチテスト | ライブダッシュボードのみ | 履歴シミュレーション | | 価格モデル | 自動解決ごと | インタラクションごと（月額固定） |

セットアップには数分かかります。Zendeskアカウントに接続し、既存のチケットとドキュメントでトレーニングし、プレーンテキストでエスカレーションルールを定義し、シミュレーションを実行してから、ライブになります。これがダイアログビルダーとの格闘と比較してどうなるか興味がある場合は、eesel AIを無料で試して違いを確認できます。

今すぐZendesk AI引き継ぎの最適化を開始する

AIから人間への引き継ぎを正しく行うことは、実際に時間を節約するチームと、複雑さを増すだけのチームを分けるものです。覚えておくべき重要なポイント：

• 引き継ぎはAIエージェントを削除します。ハンドバックはチケットがクローズしたときに発生します
• デフォルトの4日間の「解決済」から「クローズ」へのギャップは、顧客の混乱を引き起こします（修正してください）
• コンテキストの保持は、エスカレーションをシームレスに感じさせるものです
• ルーティング構成により、チケットが適切なチームに確実に到達します

次のステップ：現在の引き継ぎ構成を監査し、「解決済」から「クローズ」への自動化のタイミングを確認し、エスカレーションフローをテストして、コンテキストが正しく渡されることを確認します。ダイアログビルダーが役に立つよりも苦労していることに気づいた場合は、プレーンな英語のルールがチームに適しているかどうかを検討してください。