チャットボットを有人対応へ切り替える条件｜AI回答の停止と引き継ぎ

チャットボットを有人対応へ切り替える条件は、利用者の希望、回答の根拠、解決までの経過、人の判断が必要な操作に分けて決めます。切り替えると決めた後も、会話を渡せたか、担当窓口で受け付けられたかを確認し、その状態に合った案内を返す必要があります。

この記事では、AIによる自動回答から人へ引き継ぐための運用ルールを設計します。サービスの選定や返信文の作成全般とは分け、架空のフォームサービスを題材に、切替条件と引き継ぎ状態を整理します。以下はMakeAIの設計例で、実際のチャットシステムの稼働結果ではありません。

有人対応へ切り替える理由を、曖昧な言葉で終わらせない

「難しい質問は人へ」「AIが自信を持てないときは転送」とだけ書くと、何を難しいと判定するかが揃いません。まず、担当者が会話や資料から確認できる条件に置き換えます。

たとえば「利用者が人との対応を希望した」「対象に合う現行の案内が見つからない」「すでに同じ手順を試しても解決していない」といった条件です。自動回答を続けるか、必要な項目を一つ確認するか、人へ渡すかを分けます。

MicrosoftのAIエージェント評価ガイドでも、切替条件の見落とし、早すぎる切替、引き継ぎ時の文脈欠落、同じ応答の繰り返しを別の問題として扱っています。自動回答率だけを見るより、どの段階で利用者が止まるかを確認する設計にします。

自動回答・追加確認・有人切替の三つを決める

架空のフォームサービスでは、現行の操作ガイドに基づく案内はAIが行い、個別の契約条件や例外の判断は担当者が行う、と定めたとします。次は、その方針を切替条件へ落とした例です。

確認できる条件	選ぶ動作	理由
質問の対象が特定でき、現行ガイドに対応する手順がある	自動回答	今回の利用者の条件に合う案内を提示できる
管理者画面か利用者画面かなど、案内を選ぶ情報が一つ不足	必要な点を追加確認	その回答で、使う案内を絞れる
追加確認後も対象を特定できない、または根拠が見つからない	有人切替	推測で別の手順を案内しないため
案内済みの手順を実施しても解決しなかったと申告された	有人切替	同じ手順を繰り返すより、経過を引き継ぐ必要がある
利用者が担当者との対応を希望している	有人切替	自動回答を続けることが利用者の希望に合わない
契約条件の変更など、社内で人が判断すると定めた依頼	有人切替	案内できることと、判断・実行できることを分けるため

複数の条件が同時に当てはまる場合の優先順も決めます。この例では、人との対応を希望する場合と人の判断が必要な場合は、追加の操作案内より有人切替を優先します。切り替える前に、長い質問への回答を必須にしない運用です。

追加確認の回数は、業務と問い合わせの内容に合わせて設定します。この教材では同じ不足情報への質問を一度までとしていますが、どの業務でも一度が最適という意味ではありません。必要な情報が得られないまま、表現だけを変えて聞き続けないことを基準にします。

担当者へ渡すのは、会話の要約だけではない

「通知が届かないので確認してください」という要約だけでは、何をすでに試したかが伝わりません。担当者が同じ質問を繰り返さないよう、確認できた経過と、まだ分からないことを一緒に渡します。

【引き継ぎメモの架空例】
用件：フォーム送信後の通知メールが届かない
利用者の申告：管理者画面で通知を有効にし、保存したが届かない
案内済みの手順：操作ガイドN-01「通知の有効化」
実施したとの申告：設定の保存、テスト送信
担当側で確認済みの事実：まだなし
未確認：送信時刻、対象フォーム、配信記録
切替理由：案内済み手順を試しても解決しなかったとの申告
引き継ぎ先：サービスサポート窓口
現在の状態：引き継ぎ用メモ作成済み、窓口の受付確認はまだ

この例では、利用者が保存やテスト送信をしたと述べていることと、担当者が記録を確認したことを分けています。「実施済み」とだけ書くと、システムの記録まで確認したように読めるためです。

担当者が元の会話を確認できる参照先も、取り扱いルールに沿って残します。受け渡す情報は対応に必要な範囲に絞り、パスワードなどを引き継ぎメモへ追加で聞き出すことはしません。

「引き継ぎを決めた」と「受け付けられた」を分ける

AIが引き継ぎ用の文章を作っても、窓口への連携処理が実行されたとは限りません。利用者へ表示する言葉は、確認できた状態に合わせます。

確認できた状態	利用者へ伝えること	まだ言わないこと
有人切替が必要と判断した	担当窓口での確認が必要であること	「担当者が対応しています」
窓口で受付票が作成されたことを確認した	受付完了と、実際に発行された受付番号	担当者が内容を読んだ、解決したという説明
担当者が対応を開始したことを確認した	担当側で確認中であること	未確定の解決時刻や対応結果
連携処理が失敗し、受付を確認できない	受け付けられたことを確認できない旨と、用意された代替窓口	架空の受付番号、転送完了の案内

連携結果が不明なときは、すぐに同じ依頼を何度も作らず、同じ会話の受付票が存在するかを確認する運用を決めます。受付番号や連携記録を照合できる仕組みが必要です。文章の指示だけで二重受付の防止まで実装できたことにはなりません。

営業時間外と担当不在の案内を用意する

有人対応を組み合わせても、人がいつでも応答できるとは限りません。PKSHAの有人チャットボットの説明でも、オペレーターの対応時間が運用上の論点として挙げられています。

営業時間外には、次の対応時間、受付ができるか、利用者が次に使える窓口を、確認済みの運用情報から案内します。自動回答の範囲外だった質問を、担当者が不在という理由でAIが代わりに確定しないようにします。

たとえば「平日9時〜17時に担当者が確認する」という架空の運用なら、時間外に受付票を作成できた場合は、受付済みであることと確認時間帯を伝えます。いつ返答するかが決まっていなければ、「明日必ず解決します」のような期限を付け加えません。

担当部署が決まらない用件を受け取る共通窓口も決めておきます。受付先の名称だけでなく、誰が未割り当ての用件を見るかを確認すると、切り替えた後の放置を見つけやすくなります。

公開前に、切り替える例と切り替えない例を試す

最初から実際の問い合わせで試す前に、架空の会話と期待する動作を用意します。次の表は、上で決めたルールを点検するための基準です。実際のAIの検証結果ではありません。

試す会話・状態	期待する動作
「管理者画面で通知設定を開く場所を知りたい」。現行ガイドに記載がある	対象の手順を案内し、不必要に人へ切り替えない
「設定のボタンが見つからない」。どの画面か不明	管理者画面か利用者画面かを確認する
追加の質問にも「画面の種類が分からない」と回答	同じ質問を繰り返さず、未確認のまま窓口へ引き継ぐ
「その手順は試しました。担当者に代わってください」	操作案内を繰り返さず、経過を添えて有人切替
切替後に受付の連携が失敗した	受付完了と表示せず、結果確認と代替の案内へ進む
受付票を作成できたが、担当の対応時間外	受付状態と確認時間帯を伝え、即時対応を約束しない

実装を確認するときは、期待した動作、実際の動作、切替理由、担当側の受付状態、会話の引き継ぎ内容を記録します。ルールの追加後には、自動回答できる通常の質問まで人へ送るようになっていないかも確かめます。

AIが答えた割合を高めることだけでなく、回答できない場合に次の担当者へ必要な情報が届くことを、運用の完成条件に含めてください。

切替の理由と、受付の状態を別々に持つ

「人へ切り替えた」という一つの記録だけでは、なぜ切り替えたのかと、実際に担当へ届いたのかを区別できません。運用の記録では、切替理由、受付の状態、次の担当を別の欄にします。理由は変わらなくても、受付処理は作成待ちから受付済みへ進むためです。

記録する欄	仮の記入例	確認したいこと
切替理由	案内済みの手順で解決しなかったとの申告	人へ渡す条件に当てはまるか
元の会話	会話番号C-001	担当者が経過を読めるか
受付の状態	窓口への送信結果を確認中	受付済みと案内してよいか
受付番号	未発行	実際に発行された番号か
次の担当	受付管理者	処理が止まった場合に誰が見るか

受付番号がない状態で、会話番号をそのまま受付番号として表示しないようにします。社内では同じ会話を追う手がかりになっても、有人窓口で受け付けたことの証拠ではありません。利用者へ示す名称と意味も揃えます。

連携の結果が分からないときは、再送の前に照合する

担当窓口への送信後に応答を受け取れなかった場合、処理が実行されていないとは限りません。受付票が作成された後で返答だけを受け取れなかった可能性もあります。逆に、文章を作っただけで連携が始まっていない場合もあります。利用する仕組みで、どの状態を確認できるかを決めます。

この仮の運用では、会話番号C-001に対応する受付票があるかを調べ、存在が確認できればその番号を案内します。見つからず、受付失敗を確認できたら、担当者が再実行または代替窓口の案内を判断します。結果が不明なまま再送を繰り返すと、複数の担当者が同じ問い合わせを受けるおそれがあります。

確認する順序：
1. 引き継ぎ処理を開始した記録があるか。
2. 元の会話に対応する受付票が窓口に存在するか。
3. 受付番号と、利用者の問い合わせが対応しているか。
4. 受付を確認できない場合、誰が結果を調べるか。
5. 用意された代替窓口を案内する条件に当てはまるか。

これは実装へ渡す確認項目であり、ここに書いた手順だけで連携機能が動くわけではありません。利用するチャットや受付システムで、記録の取得方法と再送の扱いを実装担当者が確認します。

利用者へ追加で聞く項目を、引き継ぎに必要なものへ絞る

人へ対応を希望している利用者に、長い質問を続けると引き継ぎへ進めなくなります。本人確認に必要な項目、対象を特定するための項目、担当者が後から聞ける項目を分けます。人へ渡すこと自体に必要な情報と、原因調査に必要な全情報は同じではありません。

たとえば対象フォームの名称と連絡先が分かれば受付できる運用なら、詳しいエラーの再現手順は担当者から確認できます。既に会話に出ている情報をもう一度求めず、未確認だけを示します。パスワードや認証コードを受付のために聞き出す設計にはしません。

必要な情報を得られない場合の戻し先も用意します。画面の名称が分からない利用者を、名称の回答が必須という条件で止めないようにします。受付管理者が後から確認する形にできるかを、実際の業務の条件に合わせて決めてください。

引き継ぎ後の担当者が、受け取った情報を確認する

担当者が受付票を開いたときに、困っていること、案内済みの手順、利用者の申告、確認済みの事実、不足情報が分かるかを確認します。AIの要約だけで原会話の意味が変わっていないか、重要な条件を元の発言へ戻して見られる状態にします。

よくある不足	担当者が困ること	引き継ぎへ追加する情報
案内済み手順がない	同じ操作を再案内する	手順の名称・版と、試したとの申告
切替理由がない	何を人が判断するか分からない	利用者希望、根拠不足、例外判断などの理由
確認済みと申告が混在	調査が済んだと誤解する	情報ごとの確認状態
返答の約束が引き継がれない	案内した時刻を過ぎる	承認済みの連絡期限と担当

担当者が追加で聞いた質問を記録すると、引き継ぎのどこが足りなかったかを改善できます。ただし、全ての質問をチャットボット側で事前に聞く方向へ広げるのではなく、受付時に必要な情報へ絞る方針も保ちます。

変更したルールが、別の問い合わせへ影響しないか試す

一度の見落としを直すために切替条件を広げると、簡単な操作質問まで全て人へ送るようになる場合があります。修正した例だけでなく、正常に案内できた例、人を希望する例、受付失敗の例を再度確認します。条件の版と実際の動作を残してください。

評価では、切替の判断、引き継ぎ内容、受付の完了、利用者への案内を別々に見ます。正しいタイミングで切り替えても受付に失敗したなら、改善するのは判断だけではありません。窓口側の未対応を確認する担当も含め、問い合わせが次の人へ届くまでを運用の範囲にします。

受付段階の用件の分類を整理する場合は、問い合わせを内容と優先対応に分ける方法を参照できます。引き継ぎ後の返信案は、確認済みの事実と承認された対応から返信を作る手順へつなげると、切替と回答の役割を分けて整えられます。