07. AIから人間へどう引き継ぐか

「分からなければ人間へ」だけでは足りない

AIが回答できないときに有人窓口を案内するだけでは、顧客は問い合わせを最初から説明し直すことになります。担当者も長い会話履歴を読み直し、どこまで確認済みかを探さなければなりません。

この状態では、AIとの対話がそのまま追加負担になります。HITLを成立させるには、対応の主体だけでなく、途中まで集めたContextを引き継ぐ必要があります。

引継ぎ内容を会話ログの添付にせず、担当者が次の判断を始められる構造へします。

項目	役割
顧客の原文	AIの解釈だけに依存せず、依頼意図へ戻る
特定済み対象	機種、版、環境と、その根拠を確認する
確認済み事項	同じ質問や操作を繰り返さない
未確認事項	担当者が次に聞くべきことを判断する
検索条件と候補	どの範囲を調べ、何が見つかったかを再現する
採用・除外した根拠	AIが何を根拠にし、なぜ他を使わなかったかを確認する
停止理由	根拠不足、矛盾、高影響など、移行の起点を共有する

Handoff PacketはAIが作る要約だけでは成立しません。機種ID、文書ID、版、停止理由のような構造化項目はシステムが保持し、要約はそれらを読む補助として生成します。

確認済み情報を保って人へ引き継ぐ

＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

気になる項目を選ぶと、その役割や判断理由を確認できます。

顧客が担当する工程を時系列で確認します。

AI / QAが担当する工程を時系列で確認します。

Knowledgeが担当する工程を時系列で確認します。

サポート担当者が担当する工程を時系列で確認します。

長い対話をそのまま表示するだけでなく、「確認済み情報」と「追加確認が必要な情報」を分けます。対象機種、接続方法、エラー、実施済みの対処、参照文書を一覧できれば、担当者は判断を再開する位置を把握できます。

AIの要約だけに依存せず、元の会話と参照文書へ戻れることも必要です。要約は入口であり、判断根拠そのものではありません。

担当者は引継ぎを受けた後、AIの回答を承認するだけではありません。追加調査、別部門への照会、回答、Knowledge更新候補の登録のいずれへ進むかを判断します。

担当者が判断を終えた結果は、顧客対応の記録と改善データの両方へ戻します。

顧客側にも「これまでに確認した内容を担当者へ引き継ぎました」と示します。引継ぎが見えなければ、同じ説明を求められる不安が残るからです。

AIから人間への移行は、自己解決できなかった後の退避先ではありません。低リスクな自己解決と専門対応を一つのサービスとして接続する、主要なWorkflowです。

Handoffの品質は、転送件数ではなく、担当者がどこから調査を再開できたか、顧客へ同じ説明を求めたか、根拠と停止理由を追跡できたかで評価します。これを次章の継続改善で観測対象にします。