チャットボットの有人切り替え設計｜判断条件と引き継ぎ項目

利用者が「担当者と話したい」と入力したにもかかわらず、チャットボットが同じ案内を続けていては、問い合わせは解決へ進みません。一方、表現が少し曖昧なだけで有人対応へ送る運用では、担当者が本来対応すべき相談に集中しにくくなります。

チャットボットの有人切り替えは、転送機能の有無だけでは決まりません。「どの用件を切り替えるか」「どの状態を切り替え条件とするか」「誰へ何を渡すか」を一組で設計する必要があります。営業時間外の受付方法や、担当者が引き継ぎ内容を確認する手順も欠かせません。

チャットボットの有人切り替えは条件と引き継ぎを一組で設計する

有人切り替えを設計するときは、先に転送先を設定するのではなく、問い合わせ業務の全体を整理します。進める順序は「用件分類、条件表、引き継ぎ票、時間外案内、公開前テスト、運用更新」です。

最初に、チャットボットだけで完了できる用件と、人の判断が必要な用件を切り分けます。次に、利用者の希望や回答不能など、会話中に切り替えを実行する条件を表へまとめます。条件ごとに担当窓口と優先度を割り当てれば、担当者や日時による判断のばらつきを抑えられます。

ただし、適切な条件で切り替わっても、担当者へ会話の内容が渡らなければ受け渡しは完了しません。担当者が用件を把握し、対応を始めるための最小限の情報を引き継ぎ票として定義します。利用者への案内文、営業時間外の受付方法、個人情報を閲覧できる担当者も同時に決めてください。

導入前の要件全体と有人接続の条件を照合したい場合は、AIチャットボットの要件定義チェックリストも確認できます。回答範囲や管理権限を含めて整理すると、有人切り替えだけが業務全体から切り離されるのを防げます。

有人切り替えが必要な用件を先に分類する

用件分類では、問い合わせ名だけでなく、回答を完了するために必要な処理を確認します。定型情報を提示すれば完了する用件は、チャットボットの担当候補です。契約内容の個別確認、本人確認、例外判断、担当者による処理が必要な用件は、有人対応の候補になります。

分類表には、少なくとも「用件」「ボットの担当範囲」「人へ渡す条件」「担当窓口」「時間外の扱い」を記載します。次のように整理すると、判断の根拠が明確になります。

用件	ボットの担当範囲	有人切り替えが必要な状態
営業時間や利用方法	公開済みの定型情報を案内する	案内にない個別条件の確認が必要
請求内容の確認	確認方法や窓口を案内する	契約者ごとの内訳確認や訂正が必要
住所変更	手続きの概要を案内する	契約者本人の確認や登録変更が必要
苦情	用件を受け付ける	個別の事実確認、謝罪、判断が必要
設備故障などの緊急相談	必要事項と指定窓口を案内する	安全確認や緊急対応が必要

住所変更では、チャット上で個人情報を集め続けるのではなく、本人確認を実施できる窓口へ案内します。請求内容の相違について個別の契約情報が必要になった場合も、定型回答の範囲を超えた時点で切り替えます。

「苦情はすべて同じ窓口」と決めるだけでは不十分です。商品への意見、返金を伴う相談、安全に関わる申告では、受け手と優先度が異なる場合があります。実際の担当体制に合わせて、処理の違いが生じる単位まで分類してください。

有人対応へ切り替える判断条件を条件表にする

チャットボットのエスカレーション条件には、担当者が読んでも同じ判断ができる具体性が必要です。「難しい問い合わせ」「必要に応じて転送」のような表現では、設定時にも運用時にも判断が分かれます。

代表的な条件として、利用者による明示的な希望、回答不能、本人確認の必要性、緊急性、感情の悪化、ボットの回答範囲外が挙げられます。ただし、すべての製品がこれらを自動判定できるとは限りません。利用する仕組みで取得できる情報と、担当者が確認する情報を分けて設計します。

判断条件	具体的な状態	基本動作	優先度
利用者の希望	「人につないで」「担当者と話したい」などの明示	自己解決を繰り返し強制せず、受付可能な有人窓口へ進める	通常
回答不能	回答候補がない、同じ案内が続く、会話が進まない	質問原文と提示済み回答を添えて引き継ぐ	通常
本人確認	契約変更や個別情報の照会に本人確認が必要	本人確認を行える担当窓口へ案内する	用件別
緊急性	安全、停止、故障など、早急な確認が必要な申告	通常の待ち行列とは分け、定めた連絡経路を案内する	高
感情悪化	強い不満や同じ苦情が繰り返される	追加の定型回答を止め、苦情対応の担当者へ渡す	用件別

条件表には、検知する表現だけでなく、除外条件も記載します。たとえば「担当者の営業時間を知りたい」は、有人希望そのものではありません。この入力だけで転送すると誤転送になります。前後の会話と組み合わせて判断するか、利用者へ「担当者への接続を希望しますか」と確認する流れを用意します。

緊急性のある問い合わせでは、一つの言葉だけで断定しない設計が重要です。安全側の確認質問や連絡経路を詳しく決める場合は、チャットボットの緊急問い合わせ切り分けルールを参照してください。

計画的な切り替えと回答不能時の切り替えを分ける

有人切り替えには、会話を始める前から人が担当すると決められる用件と、ボットでの対応を試した結果、人へ渡す用件があります。この二つを分けると、不要な質問や長いやり取りを避けやすくなります。

計画的な切り替えは、本人確認、契約者ごとの判断、返金の承認、個別の作業依頼などに使います。ボットは用件の選択や必要事項の案内までを担当し、判断や処理を行える窓口へ早い段階で渡します。

回答不能時の切り替えは、ボットが回答候補を見つけられない場合や、回答しても対話が進まない場合に使います。一般にフォールバックと呼ばれる考え方です。何回失敗したら切り替えるかだけでなく、「同じ回答が続いた」「利用者が解決していないと答えた」「質問が対象範囲外だった」など、失敗の状態を定義します。

配送状況を尋ねた利用者に、ボットが配送方法の説明を繰り返している場面を考えます。利用者が知りたいのは一般的な配送方法ではなく、自分の荷物の状況です。この場合は回答不能として扱い、質問原文、提示済みの説明、確認できていない注文情報を担当者へ渡します。

計画的な切り替えと回答不能時の切り替えでは、利用者への案内文も変えます。前者では「この手続きは本人確認が必要なため、担当窓口をご案内します」と理由を伝えます。後者では「ご質問に合う回答を確認できなかったため、担当者へ引き継ぎます」と現在の状態を説明します。

営業時間内と営業時間外で引き継ぎ先を変える

営業時間外に「担当者へ接続します」と表示しても、応答できる人がいなければ利用者は待ち続けます。有人切り替えの条件には、曜日、営業時間、休業日、臨時休業時の扱いも含めます。

営業時間内は、チャットや電話など、実際に応答できる窓口へ進めます。待ち時間を断定できない場合は、具体的な分数を表示しません。「順番に対応します」「混雑時は回答まで時間がかかる場合があります」など、実際の運用と一致する案内にします。

営業時間外は、次の四点を明示します。

• 現在は担当者が即時応答できないこと
• 問い合わせを受け付けるのか、営業時間内の再連絡が必要なのか
• 回答時期を案内できる場合は、その基準となる営業日や時間帯
• 緊急時に利用すべき別窓口がある場合は、その連絡方法

折り返し連絡を行う運用なら、希望する連絡方法と必要な連絡先を取得します。折り返しを行わない場合は、連絡先だけを収集してはいけません。何のために取得するかを利用者へ示し、必要な項目に限定します。

時間外受付では、受付完了と担当者による確認完了を区別します。「受け付けました」という表示を、解決済みまたは対応開始済みという意味で使わないようにします。回答予定を確約できない場合も、実際の体制を超える期限を案内しないでください。

有人対応へ渡す最小限の引き継ぎ項目を決める

有人対応の引き継ぎ票は、会話ログをすべて渡すだけでは完成しません。長い履歴の中から担当者が用件を探す状態では、対応を始める前の確認に時間がかかります。要点と原文を分けて記録します。

基本となる引き継ぎ項目は次のとおりです。

• 会話の短い要約
• 利用者の用件
• 利用者が入力した質問原文
• ボットが確認した事項
• まだ確認できていない事項
• 有人切り替えを実行した理由
• 希望する連絡方法
• 連絡に必要な場合だけ取得する連絡先
• 受付時刻と時間帯

たとえば、「用件：請求内容の確認」「確認済み：対象月」「未解決：請求内訳の相違」「切り替え理由：契約者ごとの確認が必要」と記録します。担当者は対象月を聞き直さず、請求内訳の確認から始められます。

要約だけに依存すると、内容の誤りによって判断を誤る可能性があります。質問原文と重要な回答履歴を参照できる状態を残し、要約が不確かな箇所には「未確認」と明記します。推測した内容を確認済み事項として記録してはいけません。

個人情報は「あると便利」という理由で増やさず、後続業務に必要かを項目ごとに確認します。取得目的、閲覧できる担当者、保存先、保管期間、削除方法は、社内規程や利用する仕組みに合わせて決めます。法令上の判断が必要な場合は、社内の管理部門や専門家へ確認してください。

利用者に同じ説明をさせない受け渡し手順を作る

引き継ぎ項目を決めても、担当者が内容を確認せずに会話を始めれば、利用者は同じ説明を求められます。受け渡しは、ボット側、利用者側、担当者側の三者が行う手順として定義します。

1. ボットが、有人対応へ切り替える理由と引き継ぐ内容を表示する。
2. 利用者が、用件や連絡先に誤りがないか確認する。
3. 担当者が、要約、質問原文、確認済み事項を読んでから応答する。
4. 担当者は、未解決事項と不足情報だけを質問する。
5. 対応後に、解決した内容と追加対応の有無を記録する。

利用者への確認文は、「請求内容について、対象月は確認済みです。請求内訳の相違を担当者へ引き継ぎます」のように、渡す情報を短く示します。要約が違う場合に訂正できる選択肢も用意します。

担当者の最初の応答では、「対象月は確認しています。内訳のどの項目に相違があるか確認します」のように、引き継ぎ内容を読んだことが伝わる言葉を入れます。ただし、本人確認が必要な手続きでは、すでにチャットへ入力された情報があっても、定められた確認手順を省略しません。

会話の要約を作れない仕組みを使う場合は、利用者が選択した用件、直前の質問、提示済み回答、切り替え理由だけでも構いません。取得できない情報を前提にせず、現在の環境で確実に渡せる最小構成から始めます。

担当者と引き継ぎ経路を用件別に割り当てる

有人対応へ切り替わった後に別部署への転送が続く場合は、切り替え条件ではなく担当表に問題がないか確認します。用件分類と組織上の担当範囲を対応させ、一次受付、専門担当、責任者のどこへ渡すかを決めます。

用件	最初の引き継ぎ先	次の判断が必要な場合	時間外
請求内容	請求を確認できる担当者	訂正や返金の権限者	受付または営業時間の案内
契約変更	本人確認と変更手続きを行える窓口	例外判断を行う責任者	受付可否と必要書類を案内
技術的な質問	一次受付または技術担当	調査を担当する専門部署	障害窓口の有無に応じて分岐
苦情	苦情対応の担当者	補償や重要判断を行う責任者	受付後の確認方法を案内
緊急案件	事前に指定した緊急窓口	安全管理上の責任者	通常窓口とは別の経路を案内

担当表には、個人名ではなく役割や窓口名を記載すると、異動や休暇があっても運用しやすくなります。そのうえで、当番や責任者など実際の受け手を別の管理表で更新します。

担当者が不在の場合の代替先も必要です。「請求担当が不在なら一次受付へ戻す」のか、「責任者へ送る」のかを決めます。受け付けられない用件を別担当へ送るだけでは、利用者の待ち時間と社内転送が増えるため、各窓口が受け付けられる範囲を確認してください。

有人切り替えを含む日常の担当範囲や例外処理をまとめる場合は、チャットボット運用ルールの作り方も参考になります。担当表と運用ルールの更新責任者をそろえると、古い転送先が残りにくくなります。

公開前テストで誤転送・転送漏れ・個人情報を確認する

条件表と担当表を作った後は、実際の会話を使って受け入れテストを行います。設定画面の確認だけでは、言い換え、前後の文脈、時間外の分岐を検証できません。

最低限、次の会話パターンを試します。

• 「人につないで」「担当者と話したい」など、明示的に有人対応を希望する入力
• 「よく分からない」など、希望が曖昧な入力
• 回答候補がない質問と、同じ回答が繰り返される会話
• 本人確認や契約者ごとの個別判断が必要な用件
• 「至急確認してほしい」など、緊急性を含む複数の表現
• 営業時間外、休業日、担当者不在時の入力
• 連絡先を入力しない場合や、入力途中で離脱する場合

各テストでは、切り替わったかどうかだけで合否を決めません。切り替え先、利用者への案内文、担当者へ渡った項目、不要な個人情報の有無、閲覧権限、受付時刻を記録します。

誤転送のテストでは、本来ボットで回答できる質問が人へ送られていないかを確認します。転送漏れのテストでは、本人確認や緊急対応が必要な用件に対して、ボットが回答を続けていないかを見ます。境界例として、「担当者の営業時間は？」「急ぎではないが今日中に確認したい」など、単語だけでは判定しにくい入力も含めます。

個人情報のテストでは、入力欄に不要な項目がないかを確認します。担当外の従業員から会話内容が見えないかも確認対象です。テストデータには実在する顧客の情報を使わず、検証用だと分かる架空の値を用います。

不合格になった場合は、条件の追加だけで対応しないでください。案内文の修正、担当先の変更、確認質問の追加、取得項目の削除など、失敗原因に対応する箇所を直して再テストします。

運用開始後は切り替え結果から条件と引き継ぎ項目を更新する

公開時の条件表は完成版ではありません。実際の問い合わせには、想定しなかった表現や用件が含まれます。定期的に引き継ぎ結果を確認し、条件、担当先、引き継ぎ項目を更新します。

確認する事象は、不要な転送、転送漏れ、引き継ぎ情報の不足、担当外への転送、時間外案内の不一致、有人対応後も未解決だった問い合わせです。件数だけで評価せず、なぜその結果になったかを会話単位で確認します。

たとえば、配送に関する転送が多くても、すべてが不要とは限りません。一般的な配送方法の質問が転送されているなら、回答範囲や判定条件を見直します。個別の配送状況に関する問い合わせが多いなら、担当窓口や引き継ぎ項目が実態に合っているかを確認します。

担当者から「対象商品を毎回聞き直している」という報告があれば、引き継ぎ票へ対象商品を追加する候補になります。ただし、すべての問い合わせで必須にせず、その情報が必要な用件だけで取得します。

会話ログから回答不能や引き継ぎ不足を見つける具体的な進め方は、チャットボットの会話ログ分析で確認できます。分析結果は、条件表、担当表、案内文、テストケースの順に反映し、変更後は該当する会話を再テストしてください。

有人切り替え設計を確認するチェックリスト

公開準備では、次の項目を上から確認します。一つでも担当者や処理方法が曖昧なら、設定へ進む前に運用上の決定を行います。

• ボットで完了できる用件と、有人対応が必要な用件を分類した
• 利用者の希望、回答不能、本人確認、緊急性などの条件を具体化した
• 計画的な切り替えと、回答不能時の切り替えを分けた
• 条件ごとに優先度と引き継ぎ先を割り当てた
• 営業時間内、時間外、休業日で案内と受付方法を分けた
• 担当者不在時の代替先を決めた
• 会話要約、質問原文、確認済み事項、未解決事項を引き継げる
• 利用者が引き継ぎ内容を確認または訂正できる
• 担当者が引き継ぎを読んでから不足情報だけを質問する
• 連絡先などの個人情報を必要な用件に限定した
• 個人情報の取得目的、閲覧権限、保存方法を確認した
• 誤転送、転送漏れ、時間外、連絡先未入力をテストした
• 有人対応後の解決状況と担当外転送を記録できる
• 条件表、担当表、引き継ぎ票の更新責任者を決めた

有人切り替えは、条件を増やすほど良くなるわけではありません。自社の担当体制で実行できる条件を選び、受け手が処理を始めるために必要な情報だけを渡します。公開後は実際の結果を確認し、不要な転送と転送漏れの両方を見ながら調整します。

チャットボットの有人切り替えに関するよくある質問

利用者が有人対応を希望したら、すぐに切り替えるべきですか？

明示的に「担当者と話したい」と希望した場合は、同じ自己解決案内を繰り返し強制しない運用が適しています。営業時間内は対応可能な窓口へ進め、時間外は即時応答できないこと、受付の扱い、回答予定を案内します。

回答不能は何回続いたら有人対応へ切り替えますか？

一律の回数だけではなく、回答候補の有無、同じ回答の反復、利用者による未解決の申告を組み合わせて判断します。自社の会話例でテストし、必要な用件が取り残されず、簡単な質問が過剰に転送されない条件を決めます。

担当者には会話ログをすべて渡せば十分ですか？

会話ログに加えて、用件、確認済み事項、未解決事項、切り替え理由を短く整理すると、担当者が対応すべき箇所を判断しやすくなります。要約に誤りがある場合に備え、質問原文や重要な会話履歴も確認できる状態にします。

営業時間外の有人希望では何を案内しますか？

担当者が即時応答できないこと、問い合わせを受け付けるかどうか、回答予定を案内できる場合はその基準、緊急時の別窓口を示します。折り返しに必要な連絡先を取得する場合は、取得目的と利用方法も伝えます。

Socratesで有人切り替えの運用範囲を確認する

チャットボットの有人切り替えは、用件分類、判断条件、時間帯ごとの窓口、引き継ぎ項目をそろえて初めて運用できます。まずは現在の問い合わせを分類し、誰がどの用件を受けるかを表にしてください。

整理した条件表と担当表を基に、Socratesで実現できる運用範囲や導入時に確認すべき事項をご相談いただけます。未決定の項目がある場合も、チャットボットへ任せる範囲と有人対応の担当範囲を切り分けたうえで確認すると、相談内容を具体化できます。

Socratesの導入について相談する