有人引継ぎは、案内・受付・対応開始を分けて考える
2026年10月8日のGoogle Cloudの中小企業向け発表では、顧客サポート用エージェントなどの活用例が紹介されました。同日に発表された新しいGemini agentは、その記事では早期アクセスとされています。こうした業務活用を検討する際にも、自動応答で終わらない相談の受け皿が必要です。
現行のMicrosoft Copilot Studio公式資料では、標準ハーネスという実行方式のエージェントから、接続済みの有人対応システムへ履歴や変数を渡す方法を説明しています。一方、問い合わせ先のURLを案内するだけの構成も可能です。この二つでは、利用者が次に行う操作と、開発する連携が異なります。
また、GoogleのDialogflow CXでは、Live agent handoff応答は人へ渡すための信号で、それ自体は会話の状態を変更しません。実際の引継ぎ処理は連携するシステム側で行います。そこで発注時は、案内を出した段階、受付先に記録された段階、人が対応を始めた段階を分けて確認することを勧めます。以下は公式仕様を踏まえた編集上の提案であり、当社の導入実績や実測結果ではありません。
まず切り替え条件と、受け取る担当を決める
最初に、AIで案内する範囲と人が判断する範囲を業務担当者と整理します。利用者が人を希望したときに、同じFAQを繰り返して引き止める設計は避けます。根拠が見つからない場合も、推測で回答を続ける前に引継ぎ先を選べるようにします。
切り替え条件には、受け取る部署、受付方法、利用者へ見せる文面を一組で記録します。担当者不在や混雑時にも受付記録を残すのか、既存の窓口へ案内するのかを決めます。対応時間や返信目安は、実際に運用できる内容を担当部署に確認してから表示します。
- 利用者の希望：会話途中でも人への相談を選べる。引継ぎに不要な追加質問を続けない。
- 回答できない：根拠がない、質問の意図を確認しても解決しない場合の行き先を決める。
- 人の判断が必要：個別の承認や社内規程上の例外など、AIが確定しない範囲を明記する。
- 連携できない：受付システムの障害や権限不足では、届いたと断定せず別の窓口を示す。
仮のIT問い合わせで、受付の証拠をそろえる
社内IT窓口を想定した架空の例です。利用者が「社給PCが社内Wi-Fiにつながらない。案内された手順を試したが直らないので、人に相談したい」と入力したとします。AIは症状を再び最初から聞く代わりに、確認済みの内容と未解決点を整理し、担当窓口へ渡す準備をします。
この例では、問い合わせ管理システムの受付IDを受け取れたときだけ「問い合わせを受け付けました。受付IDはIT-042です。担当部署の対応待ちです」と案内する設計にします。IT-042は説明用の番号です。担当者がまだ確認していない段階で「担当者が対応しています」とは伝えません。
受付要求の返答が届かない場合は、登録できたか不明な状態です。同じ会話の識別情報で受付済みかを照合してから再送し、二重登録を防ぐ処理を検討します。状態を確認できなければ「受付完了を確認できませんでした」と表示し、あらかじめ決めた代替窓口と、照会に使える会話IDを示します。
夜間も同じです。記録だけ受け付けられるなら、受付済み・対応は受付時間内という区別を表示します。記録できずフォームへ案内する構成なら、利用者によるフォーム送信が必要だと伝えます。リンクを表示しただけで受付済みにはしません。
渡す内容は「次の担当者が続きを判断できる情報」に絞る
有人対応システムへ履歴を渡せることと、すべての会話を無制限に保存することは別です。業務上必要な項目、閲覧できる担当者、保存期間を決め、不要な情報まで引継ぎ用に集めないようにします。パスワードや認証コードを聞き出す欄は設けません。
仮のIT例では、問い合わせ要約を「Wi-Fi接続不可、案内手順を実施済み、未解決」とし、試した手順と結果を別項目にします。「端末が故障した」とAIが推測した内容を事実として渡さないことが大切です。要約に誤りがあったときに、権限のある担当者が必要な原文を確認できる参照先も用意します。
- 対応の目的：何に困っているか、利用者が求める次の対応。
- 確認した事実：利用者が述べた症状、実施済みの手順、その結果。推測は分ける。
- 未解決の内容：回答できなかった理由、次に担当者が確認する事項。
- 追跡用の情報：会話ID、受付ID、受付時刻、担当窓口、業務上必要な返信先。
テストは利用者画面と担当側の記録を突き合わせる
発注時の確認項目には、正常な切り替えに加え、時間外、受付失敗、再送を含めます。匿名化した入力やテスト用データを使い、同じ会話IDに対して、画面表示・受付先の記録・担当者の状態が食い違わないかを見ます。以下は検証案で、実施済みのテスト結果ではありません。
- 人を希望：受付先に必要情報が届き、利用者の画面には実際の受付状態が出る。
- 時間外：即時対応を約束せず、記録の有無と次に利用者が行うことを示す。
- 応答が途切れる：受付成功か失敗かを照会し、未確認のまま完了表示しない。再送しても同じ依頼を増やさない。
- 有人対応を開始：担当者が必要な履歴を確認できる。AIからの自動回答を止める条件も確認する。
「人へ回した数」だけで改善を判断しない
GoogleのDialogflow CXの分析仕様では、Live Agent Handoffは人への引継ぎが要求された会話数です。その数だけでは、担当側で受け付けたか、問題が解決したかは分かりません。自社の運用でも、引継ぎ要求・受付確認・対応開始・解決を別の状態として記録することを勧めます。
引継ぎが増えた場合は、根拠資料の不足なのか、利用者が人を希望したのか、受付連携が失敗したのかを分けて見ます。人への相談が必要な業務まで、引継ぎを減らすためにAIで完結させる必要はありません。
開発相談の前には、よくある未解決の質問を一つ、現在の窓口と受付時間、担当側で受け取りたい情報を用意してください。開発会社とは、表示文面だけでなく受付先の記録までを確認範囲に含めるかを合意します。関連するAI導入支援・業務システム開発の内容を確認し、自社の受付のどこに困っているかを具体的に相談すると、必要な連携を整理できます。
参考資料・出典
本文の情報は執筆時点のものです。仕様や提供条件は、リンク先の公式情報もご確認ください。