Zendeskハンドオフコンテキスト:シームレスなAIからエージェントへの移行のための完全ガイド

Stevia Putri

Stanley Nicholas
Last edited 2026 3月 5
Expert Verified
顧客がAIエージェントで対応できる範囲を超えた場合、担当者(人間のエージェント)への移行はスムーズに行われる必要があります。ぎこちないハンドオフは顧客をイライラさせ、エージェントの時間を無駄にします。適切に行われれば、コンテキストを維持し、適切なチームにルーティングし、解決時間を短縮できます。
このガイドでは、Zendeskハンドオフコンテキストがどのように機能するかを、基盤となるアーキテクチャからステップごとの設定まで正確に解説します。AIエージェントを初めて設定する場合でも、タイミングの問題をトラブルシューティングする場合でも、Zendeskのティアに合った実践的な手順が見つかります。
Zendeskハンドオフコンテキストとは?
ハンドオフコンテキストとは、AIエージェントから人間のエージェントに顧客との会話が移行する際に、会話とともに移動する情報のことです。これには、会話履歴、顧客の詳細、問題の分類、およびシステムが収集したメタデータが含まれます。
Zendeskでは、似たように聞こえるが意味が異なる2つの用語を使用します。
-
**ハンドオフ(Handoff)**とは、AIエージェントが顧客との会話をライブの担当者(人間のエージェント)に移行する瞬間のことです。AIエージェントは会話の最初の応答者として削除され、担当者が引き継ぎます。これは通常、顧客がボットが提供できる範囲を超えた支援を明示的に要求した場合、またはAIが担当者の判断が必要な問題を検出した場合に発生します。
-
**ハンドバック(Handback)**はその逆です。チケットがクローズすると、ライブエージェントは最初の応答者として削除されます。これにより、AIエージェントがその顧客からの新しい会話を処理できるようになります。会話ループをリセットすると考えてください。
スイッチボードアーキテクチャにより、これが可能になります。Sunshine Conversationsは、オペレーターが電話を接続するのと同じように、スイッチボードシステムを使用してボットからエージェントへのハンドオフを管理します。スイッチボードは、どの連携機能が各会話を処理するかを制御し、AIボットと担当者(人間のエージェント)間のスムーズな移行を可能にします。
適切なハンドオフコンテキストがないと、顧客はすでにボットと共有した情報を繰り返すことになります。エージェントはすでに収集された詳細を尋ねるのに時間を浪費します。コンテキストの保持は、優れたエスカレーションと苦痛なエスカレーションを区別するものです。
Zendeskの会話ライフサイクルを理解する
ハンドオフを正しく設定するには、会話がZendeskのシステムをどのように流れるかを理解する必要があります。会話の状態とチケットのステータスという、独立しているが接続されている2つの要素があります。
会話の状態
メッセージングの会話は、次の3つの状態を移行します。
- アクティブ(Active):顧客が積極的に関与し、入力および応答している
- 非アクティブ(Inactive):最後のメッセージから10分が経過した
- 終了(Ended):会話が解決またはクローズされた
これらの状態は、システムが顧客のメッセージとエージェントのキャパシティをどのように処理するかを決定します。会話が非アクティブになると、エージェントのキャパシティ制限に対してカウントされなくなり、新しい割り当てを受け入れることができます。
チケットのステータス
チケットは異なるパスをたどります。
- 新規(New):チケットが作成され、まだ割り当てられていない
- オープン(Open):エージェントが積極的に作業している
- 保留中(Pending):顧客の応答を待っている
- 解決済み(Solved):エージェントが解決済みとしてマークした
- クローズ(Closed):チケットが確定され、読み取り専用
ここで注意が必要なのは、エージェントはチケットのステータスが**クローズ(Closed)**になるまで最初の応答者のままであることです。解決済み(Solved)ではありません。Zendeskはデフォルトで、解決済み(Solved)とクローズ(Closed)の間に4日間待ちます。
その期間中、顧客がメッセージングウィジェットに戻ると、新しい会話を開始できません。代わりに、メッセージは既存のチケットに送信されます。以前のエージェントが割り当てられたままで、コンテキストが混乱します。顧客は新しい問題を報告することを期待していますが、古い会話スレッドで立ち往生しています。
AI Agentチケットとサポートチケット
AIエージェントが有効になっている場合、新しい会話はAgent WorkspaceにAI Agentチケットを作成します。このチケットには、顧客とAIエージェント間の会話全体が含まれています。
ハンドオフが発生すると、AI Agentチケットは通常のサポートチケットに変換され、担当者(人間のエージェント)に割り当てられます。その時点から、標準のチケットライフサイクルに従います。
これらの区別を理解することが重要なのは、ハンドバックプロセス(AIへの制御の返却)は、チケットが解決済み(Solved)ステータスではなく、クローズ(Closed)ステータスに達したときにのみ発生するためです。
Zendeskの会話ハンドオフを設定する方法
設定は、使用しているZendeskのティアと、カスタム連携機能を構築しているか、ネイティブ機能を使用しているかによって異なります。
必要なもの
開始する前に、次のものがあることを確認してください。
- Sunshine Conversationsが有効になっているZendeskメッセージング
- Zendesk Agent Workspaceが設定されている
- Zendesk管理センターへの管理者アクセス
- カスタムスイッチボード連携機能を構築する場合は、APIアクセス
ステップ1:スイッチボード連携機能を設定する
スイッチボードは、どのシステム(AIエージェントまたは人間のエージェント)が特定の時点で会話を制御するかを決定するルーティングレイヤーです。
設定するには:
-
Zendeskメッセージング設定で、**会話制御(Conversation control)が制御を渡す(Pass control)**に設定されていることを確認します。これにより、システムは連携機能間で会話を転送できます。
-
Zendesk管理センターで、AIエージェントを最初の応答者として追加します。**管理センター(Admin Center)>チャネル(Channels)>メッセージングとソーシャル(Messaging and social)> AIエージェント(AI agents)**に移動し、ボットを接続します。
-
スイッチボード連携機能が正しく設定されていることを確認します。デフォルトでは、アカウントにはAIエージェント(firstResponderとして)とZendesk Agent Workspace(nextResponderとして)を表す連携機能が含まれています。
スイッチボードは、次の3つの主要な操作を使用します。
- passControl:ある連携機能から別の連携機能に所有権を即座に転送します
- offerControl:ターゲットが受け入れるまで制御を共有します
- releaseControl:会話をデフォルトの状態に戻します
ボットがエスカレーションが必要であると判断した場合、会話に関するメタデータとともにpassControlエンドポイントを呼び出します。
ステップ2:AIエージェントでハンドオフトリガーを設定する
設定は、Zendeskのティアによって異なります。
AI Agent Essentialの場合:
- **管理センター(Admin Center)> AI > AIエージェント(AI agents)**に移動します
- AIエージェントを選択し、**メッセージングの動作(Messaging behavior)**タブを開きます
- 各応答タイプで「担当者と話す(Talk to a human)」オプションを探します
- オプションが表示されるタイミングを設定します(常に表示、失敗した試行後など)
- **エスカレーション(Escalation)**タブを開いて、ハンドオフ中に顧客に表示されるメッセージをカスタマイズします
- **公開(Publish)**をクリックし、サンドボックス環境でテストします
Essentialティアでは、エスカレーションパスを細かく制御できません。条件付きルーティング(請求と技術的な問題で異なるチーム)が必要な場合は、Advancedまたはサードパーティツールが必要です。
AI Agent Advancedの場合:
ダイアログビルダーは、複雑なエスカレーションロジックのための視覚的なワークフローツールを提供します。
- AIエージェント - Advancedで、AIエージェントを選択します
- **コンテンツ(Content)>ユースケース(Use cases)**に移動します
- 変更するダイアログを開きます(または新しい返信を作成します)
- ハンドオフを発生させたい場所に**エスカレーション(Escalation)**ブロックを追加します
- エスカレーションメッセージとチャネル(メッセージングまたはメール)を設定します
- 必要に応じて、エスカレーションの前に**可用性(Availability)**ブロックを追加して、エージェントがオンラインかどうかを確認します
- **アクション(Actions)**を使用して、タグを追加したり、コンテキストのチケットフィールドに入力したりします
- **ダイアログの検証(Validate dialogue)**をクリックして、エラーがないか確認します
- 準備ができたら**公開(Publish)**します

使用する主要なブロック:
| ブロックタイプ(Block Type) | 目的(Purpose) |
|---|---|
| エスカレーション(Escalation) | 担当者(人間のエージェント)へのハンドオフパスを定義します(ブランチの最後にある必要があります) |
| 可用性(Availability) | 営業時間とエージェントのステータスをエスカレーション前に確認します |
| 条件付き(Conditional) | パラメータに基づいて異なるエスカレーションパスをルーティングします |
| アクション(Actions) | タグを追加したり、コンテキストのチケットフィールドに入力したりします |
ステップ3:エスカレートされた会話のルーティングを設定する
ハンドオフ後、チケットは適切なチームまたはエージェントに到達する必要があります。
チケットトリガーが最も一般的なアプローチです。メッセージングチケットが作成されたときに発生するトリガーを作成し、次の条件に基づいて割り当てます。
- カスタムチケットフィールドの値(会話中に収集)
- AIエージェントによって追加されたタグ
- チャネルソース
チャットルーティングルールは、どのエージェントが通知を表示するかを決定します。すべてのエージェントにブロードキャストするか、特定のグループに割り当てることができます。これらのルールはチケットトリガーの後に発生するため、2つが連携して動作します。
オムニチャネルルーティングは、ProfessionalおよびEnterpriseプランで利用できます。エージェントの可用性とキャパシティに基づいて、メール、電話、メッセージング全体でルーティングします。メッセージングチケットの場合、スキルベースのルーティングは利用できないことに注意してください。

ステップ4:コンテキストの保持を設定する
顧客がすでにボットと共有した情報を繰り返すよりも、顧客をイライラさせるものはありません。
カスタムチケットフィールドを使用すると、会話中に特定のデータポイントをキャプチャできます。ダイアログビルダーで、注文番号、製品カテゴリ、または問題の種類などのチケットフィールドにマッピングする「詳細を尋ねる(Ask for details)」ステップを追加します。これらはチケットのサイドバーに目立つように表示されます。
メタデータの受け渡しは、アカウントIDやセッション情報などの技術データを処理します。これには、チャットウィジェットにコードを追加して、カスタムデータをチケットに渡す必要があります。設定には手間がかかりますが、eコマースまたはSaaSサポートに役立ちます。
内部メモには、AIが生成した要約を含めることができます。一部のチームは、エスカレーション前に顧客の問題の簡単な要約をAIに記述するように設定します。これにより、エージェントはトランスクリプトを掘り下げることなく「TL;DR」を取得できます。
目標は簡単です。エージェントはチケットを開いてから数秒以内に顧客が何を必要としているかを知る必要があります。
ハンドバックのタイミングの問題を修正する
解決済み(Solved)とクローズ(Closed)の間のデフォルトの4日間のギャップは、前述した顧客の混乱を引き起こします。これを修正する方法は2つあります。
解決策1:即時クローズトリガーを作成する
タグ付けされたときにチケットをすぐにクローズするトリガーを作成します。
- 条件(Condition):タグ(Tags)| 次のいずれかを含む(Contains at least one of the following)|
close - アクション(Action):ステータス(Status)| クローズ(Closed)
次に、チケットを解決するときに、マクロまたは自動化を介してcloseタグを追加します。これにより、どのチケットをすぐにクローズし、どのチケットをバッファに保持するかを制御できます。

解決策2:デフォルトの自動化を変更する
Zendeskには、「ステータスが解決済みに設定されてから4日後にチケットをクローズする」という自動化が含まれています。これを1時間以下に短縮できます。
- **管理センター(Admin Center)>オブジェクトとルール(Objects and rules)>自動化(Automations)**に移動します
- デフォルトのクローズ自動化を見つけて編集します
- 時間条件を4日から希望の期間に変更します
- 保存してテストします
1つの注意点:CSATアンケートを使用している場合は、チケットをすぐにクローズしないでください。アンケートはチケットが解決済みとしてマークされたときに送信されるため、すぐにクローズするとアンケートエクスペリエンスと競合する可能性があります。少なくとも小さなバッファを維持してください。
Zendeskハンドオフコンテキストの移行中にコンテキストを保持する
実際に何が移行され、それをどのように役立てるかについて具体的に説明しましょう。
自動的に移行されるコンテキスト
Zendeskは、会話の完全なトランスクリプトを自動的にチケットに添付します。エージェントは、顧客がAIエージェントに言ったことすべてを確認できます。ただし、生のトランスクリプトは長くなる可能性があり、多忙なエージェントは常に完全に読むとは限りません。
構造化されたデータを渡す方法
会話中にカスタムチケットフィールドに入力するようにダイアログビルダーアクションを設定します。顧客が注文番号に言及した場合は、それをキャプチャします。メニューから製品カテゴリを選択した場合は、フィールドにマッピングします。
これらのフィールドはチケットのサイドバーに表示され、見逃すことはありません。
技術データのためのメタデータの受け渡し
アカウントID、セッション情報、またはその他の技術データについては、メタデータの受け渡しを使用します。これには、会話を開始するときにカスタムデータを含めるようにチャットウィジェットが必要です。次に、データは指定したチケットフィールドに流れます。
エージェントトレーニングのベストプラクティス
完璧なコンテキスト保持があっても、エージェントはそれを見つける場所を知る必要があります。チームを次の点でトレーニングします。
- Agent Workspaceでの会話トランスクリプトの表示場所
- どのカスタムフィールドにキー情報が含まれているか
- AIが生成した要約の内部メモの読み方
エージェントがすでに収集された情報を繰り返すように顧客に依頼した場合、AIが提供することになっていた効率の向上は失われます。
一般的なZendeskハンドオフコンテキストの問題のトラブルシューティング
適切な設定があっても、ハンドオフの問題が発生します。最も一般的な問題とその修正方法を次に示します。
顧客が新しい会話を開始できない
症状(Symptom):顧客がメッセージングウィジェットに戻りますが、新しい会話を開始する代わりに、以前の会話が再び開きます。
原因(Cause):チケットのステータスが解決済み(Solved)ではなく、クローズ(Closed)です。クローズ(Closed)になるまで、顧客は新しい会話を開始できません。
修正(Fix):前述の自動化またはトリガーメソッドを使用して、解決済み(Solved)からクローズ(Closed)までの遅延を短縮します。ほとんどのチームにとって、1〜4時間は混乱を引き起こすことなくCSATアンケートに十分なバッファです。
エージェントが会話のコンテキストを見逃している
症状(Symptom):エージェントは、すでにAIエージェントと共有した情報を繰り返すように顧客に依頼します。
原因(Cause):メタデータが表示可能なチケットフィールドにマッピングされていないか、エージェントがトランスクリプトを見つける場所を知りません。
修正(Fix):会話中にカスタムチケットフィールドに入力するようにダイアログビルダーアクションを設定します。Agent Workspaceでのコンテキストの表示場所(会話ペインとサイドバーフィールド)についてエージェントをトレーニングします。エスカレーション前に要約を含む内部メモを追加することを検討してください。
間違ったチームがエスカレートされたチケットを受け取っている
症状(Symptom):技術的な問題が請求チームに送られたり、その逆の場合もあります。
原因(Cause):エスカレーションブロックで転送グループが設定されていないか、トリガーが正しく発生していません。
修正(Fix):ダイアログビルダーで、各エスカレーションブロックに正しい転送グループを指定します。メッセージングチケットが正しい条件(タグ、カスタムフィールドなど)に基づいてルーティングされるように、チケットトリガーを確認します。各フローを介してテスト会話を送信してテストします。
eesel AIでハンドオフを簡素化する
ダイアログビルダーがチームにとって過剰であると感じる場合、または保守が容易なエスカレーションロジックが必要な場合は、eesel AIがより簡単なアプローチを提供します。

Zendeskと直接統合し、平易な英語でエスカレーションルールを定義できます。ビジュアルビルダーでブロックをドラッグする代わりに、次のような指示を記述します。
- 「払い戻し要求が30日以上前の場合は、丁寧に拒否し、ストアクレジットを提供する」
- 「請求に関する紛争は常に担当者(人間のエージェント)にエスカレートする」
- 「VIP顧客(「エンタープライズ」のタグが付いている)の場合は、専用のサポートチームにルーティングする」
AIはこれらのルールを解釈し、会話中に適用します。コーディングも複雑なワークフローもありません。
ネイティブZendesk AIとの主な違い:
| 機能(Feature) | Zendeskネイティブ(Zendesk Native) | eesel AI |
|---|---|---|
| エスカレーション設定(Escalation configuration) | ダイアログビルダーが必要 | 平易な英語のルール |
| ナレッジソース(Knowledge sources) | ヘルプセンター+マクロ | 100以上の連携機能(Confluence、Googleドキュメント、Notionなど) |
| プレローンチテスト(Pre-launch testing) | ライブダッシュボードのみ | 過去のチケットでの履歴シミュレーション |
| 価格モデル(Pricing model) | 解決ごと | インタラクションごと |
シミュレーション機能は、Zendesk AIエージェントのエスカレーションに特に役立ちます。ライブになる前に、過去のチケットに対してAIを実行し、各状況をどのように処理するかを正確に確認し、自信が持てるまでルールを調整できます。
また、Zendesk以外のソースからもナレッジを取得します。チームがConfluenceでプロセスを文書化したり、Googleドキュメントでポリシーを共有したりする場合、eeselもそれらから学習します。AIエージェントは、ヘルプセンターの記事だけでなく、完全なコンテキストを取得します。
セットアップには数分かかります。
- eesel AIをZendeskアカウントに接続します
- 既存のチケット、マクロ、ドキュメントでトレーニングします
- 平易なテキストでエスカレーションルールを定義します
- 過去のチケットでシミュレーションを実行します
- 自信を持ってライブに移行します
eesel 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.


