チャットボットの有人切り替えがうまくいくかどうかは、AIの回答精度ではなく「どうなったら人に渡すか」を先に決めてあるかでほぼ決まります。精度99%のAIでも、残り1%が人に届かなければ問い合わせは行き止まりになるからです。J.D. パワーの2025年カスタマーセンターサポート満足度調査では、直近の問い合わせ窓口としてチャットボットを使った人は金融業界で11%、EC・通販業界で13%にとどまり、多くの問い合わせは今も人の窓口へ流れています。つまりAIは「入口」であって、設計すべきなのはその先の出口です。
この記事では、エスカレーション条件の作り方、引き継ぎ時に渡す情報、営業時間外のフォールバック、そして実際に現場で起きる失敗5例をまとめます。ツール選定より前に、この4つを紙の上で決めておくと導入後の手戻りがほぼ消えます。
結論：切り替えの成否は「AIの精度」ではなく「条件設計」で決まる
チャットボット導入の相談で最も多い質問は「どのAIが賢いか」ですが、運用が破綻する原因はほぼ別のところにあります。破綻するのは、AIが答えられなかったときに誰の画面のどこに、何を持って現れるかが決まっていないケースです。この部分はツールの機能ではなく、自社の運用ルールとして決めるしかありません。
実際、主要ツールの公式ドキュメントも「渡す判断」は利用側が設計するものとして扱っています。Google の Dialogflow CX は、有人へ渡す合図である LiveAgentHandoff について「Dialogflow はこれを、どの会話が人に渡されたかを計測するためだけに使う」「付随するメタデータの構造は Dialogflow 側では規定しない」と明記しています。つまり、渡す条件も渡す中身も設計者の宿題です。
だから最初に決めるのは、AIの学習データでもFAQの網羅率でもなく、「AIを止めて人を呼ぶ条件」のリストです。これを5〜7個に絞って明文化するところから始めます。
エスカレーション条件の設計表（トリガー×渡し方×記録）
エスカレーション条件は「トリガー（何が起きたら）」「渡し方（どう人に届けるか）」「記録（どこに残すか）」の3点セットで決めます。トリガーだけ決めて渡し方と記録を決めないと、後述する「通知が誰にも届かない」「記録が残らない」という典型的な失敗に直行します。以下はMihataが実際に設計するときの叩き台です。
トリガー（何が起きたら渡すか） | 渡し方 | 記録 |
|---|---|---|
同じ質問で2回続けて解決しなかった（連続失敗） | チャット内に「担当者に代わる」ボタンを出し、押されたら有人キューへ | 会話ログ＋失敗した質問文を問い合わせ管理に自動起票 |
ユーザーが「人と話したい」「オペレーター」と明示的に要求 | 質問を挟まず即座に有人へ。営業時間外なら折り返し予約へ | 要求時刻と要求文言を残す（AIの改善材料になる） |
クレーム・強い感情の語（解約、返金、ひどい、責任者 など） | AIの回答を打ち切り、責任者が見るキューへ優先度高で渡す | 該当発言を含む全文ログを必ず保存（後追い調査に使う） |
金額・契約・納期の確約を求める質問 | AIは回答せず「担当者から回答します」と明示して有人へ | 質問内容と回答者を紐づけて残す（言った言わないの防止） |
個人情報・機微情報の入力が始まった（電話番号、住所、口座など） | その場での入力を止め、専用フォームまたは有人チャネルへ誘導 | 本文をログに残さない設計にする（マスキング） |
営業時間外・有人が不在 | 切り替えボタンを出さず、フォームか折り返し予約に切り替える | 受付内容と希望時間帯を記録し、翌営業日の対応キューへ |
この表で重要なのは「連続失敗」と「明示要求」を必ず両方入れることです。明示要求だけだと、遠慮して言い出せない人がそのまま離脱します。逆に連続失敗だけだと、最初から人に用がある人をAIが足止めします。
Microsoft の Copilot Studio も、この2つを implicit trigger（意図が取れない・「担当者と話したい」と言われた場合に自動で Escalate トピックへ飛ぶ）と explicit trigger（設計者がトピックに「会話の転送」ノードを置く）として分けて説明しています。設計上も別物として扱うのが標準的な考え方です。
閾値は「回数」で決め、「確信度」で決めない
「AIの確信度が0.7を下回ったら有人へ」といったスコア基準は、一見きれいですが運用で使えないことが多いです。閾値の意味がモデル更新やプロンプト変更で変わってしまい、誰も再調整できなくなるためです。「同じ話題で2回外したら渡す」のように、非エンジニアでも判断・監査できる回数ベースにしておくと、運用が引き継げます。
引き継ぎ時に渡すべき4つの情報
有人へ渡すときに何を一緒に渡すかで、対応の質が決まります。渡すべきは会話ログ・認証状態・対応履歴・意図の要約の4つです。Copilot Studio の公式ドキュメントでも、引き継ぎ時に会話履歴に加えて直前のトピック（va_LastTopic）、直前の発話（va_LastPhrases）、会話ID（va_ConversationId）、言語（va_Language）、そして設計者が定義した変数がまとめて渡される仕様になっています。
- 会話ログ（全文）：要約だけ渡すと、担当者が「もう一度最初から説明してください」と聞くことになります。これが顧客体験を最も壊します。
- 認証状態：ログイン済みか、どの顧客IDか。渡さないと本人確認をやり直すことになり、対応時間が倍になります。
- 対応履歴：同じ人が過去に問い合わせているか。渡さないと「前回も言いましたが」と言われて信頼を落とします。
- 意図の要約（1〜2行）：AIが理解した用件と、詰まった箇所。全文ログだけだと担当者が読む時間がかかり、初回応答が遅れます。
この4つは、Webチャットに限らずどのチャネルでも同じです。自社サイトへのAIチャットボット設置でも、LINE公式アカウントでのAI応答でもでも、渡す情報が欠けた瞬間に同じ事故が起きます。
渡さないと現場で何が起きるか
引き継ぎ情報が欠けると、有人対応の時間はむしろ導入前より伸びます。担当者はまず「AIとどこまで話したか」を復元する作業から始めることになり、その間ユーザーは待たされ、同じ説明を2回させられるからです。AI導入で問い合わせ対応が遅くなった、という相談の多くはこれが原因で、AIの精度は関係ありません。
引き継ぎの仕様は既製ツールの設定範囲で足りることもあれば、自社の顧客管理と突き合わせる必要があって作り込みになることもあります。どちらが妥当かは、渡したい情報がどこにあるかで決まります。判断に迷う段階でしたら、要件の整理からご相談いただけます。
営業時間外・有人不在時のフォールバック設計
切り替え設計で最も抜けやすいのが、渡す先に誰もいない時間帯です。24時間動くAIに対して有人は営業時間内しかいないので、放置すると「担当者におつなぎします」と言ったまま誰も出てこない、という最悪の体験が生まれます。営業時間外は、切り替えボタンそのものを出さないのが基本です。
フォールバックは次の3つを、この優先順で用意します。
- フォーム誘導：用件が固まっている人向け。AIが聞き取った内容をフォームに初期値として渡せると離脱が減ります。
- 折り返し予約：話したい人向け。希望時間帯を選ばせ、翌営業日の対応キューに積みます。電話番号を取るならこの導線に限定します。
- FAQ回帰：急いでいない人向け。「関連しそうな回答」を提示して、翌営業日でよければそのまま解決してもらいます。
あわせて、いま自分がAIと話しているのか人と話しているのかを、常に画面上で分かるようにすることが重要です。LINE公式アカウントには応答設定に「応答状況の表示」があり、選択中の応答方法に応じてトークルームに「担当者が返信します」「自動で返信しています」「現在は応答時間外です」と自動で表示されます。自社サイトのチャットでも、これと同じ表示を自前で用意する必要があります。
営業時間外の受け皿としては、チャットだけでなく問い合わせメールのAI自動返信を組み合わせると、受付から一次回答までを止めずに済みます。
現場で起きる失敗パターン5例
1. たらい回しになる
AIが有人へ渡し、有人が「その件は別部署です」と再度転送する形です。原因は、エスカレーション先を1本しか用意していないことにあります。トリガーごとに渡す先を分ける（金額の話は営業、不具合は技術、クレームは責任者）と決めておけば、1回で正しい人に着きます。
2. AIが謝るだけで人に渡さない
「申し訳ございません、お答えできません」で会話が終わる形です。これは分からなかったときの遷移先を設計していない状態で、ユーザーから見ると門前払いです。「答えられない」の応答には必ず次の行き先（有人・フォーム・電話）を添えるルールにします。Copilot Studio の Escalate トピックも、既定では単純なメッセージを返すだけなので、サポートサイトのURLや連絡手段を自分で追記する前提の作りになっています。
3. 人に渡した瞬間に文脈が消える
有人チャットに切り替わると別ウィンドウが開き、それまでの会話が引き継がれない形です。ツールをまたぐ構成で起きやすく、たとえば Copilot Studio でも転送ノードを追加しただけの既定状態では、デモサイト上に「No renderer for this activity」と表示され、有人を実際に画面へ参加させるにはチャット画面側の作り込みが要る、と公式に注意書きがあります。「渡す合図が出せること」と「渡った先で会話が続くこと」は別問題だと理解しておく必要があります。
4. 通知が誰にも届かない
有人キューに積まれたが、担当者がその画面を開いていない、という形です。とくに専任オペレーターを置かない中小企業ではほぼ確実に起きます。通知先は個人ではなくチャネル（チームのチャット・共有メール）にし、一定時間で応答がなければ第二通知先へ上げるところまで決めておきます。ここは業務時間の実態に合わせるしかないので、ツールの既定値を疑ってください。
5. 有人チャネルがチャットツールだけで記録が残らない
切り替え先を社内チャットにすると立ち上げは速いのですが、対応内容が流れて消え、誰がいつ何を答えたか後から追えなくなります。記録先（問い合わせ管理・スプレッドシート・CRMのいずれか）を1つ決めて、通知とは別に必ず書き込む設計にします。記録が無いと、AIに学習させるべきFAQも増やせません。
社内向けの問い合わせでも構造は同じで、社内ヘルプデスクのAI化では「AIが答えられなかった質問」の記録がそのままナレッジ整備の入口になります。
既製ツールで足りるか、作り込みが要るかの判断
ここまでの設計を書き出すと、既製のチャットボットSaaSで足りるかどうかが自然に見えてきます。判断の分かれ目は「渡したい情報が自社システムの中にあるか」です。会話ログと意図の要約だけでよければ既製ツールの標準機能で足り、認証状態や契約情報まで渡したいなら連携の開発が必要になります。
また、トリガーの判定に自社固有のルール（特定の商品名、契約区分ごとの分岐など）が入る場合も、設定画面だけでは表現しきれないことが多いです。この場合は独自AI開発として自社の業務ルールごと実装する選択肢が出てきます。費用感の目安は独自AI開発の費用相場にまとめています。
よくある質問
よくある質問
エスカレーション条件はいくつくらい用意すればよいですか？
最初は5〜7個に絞ることをおすすめします。この記事の設計表にある「連続失敗」「明示要求」「クレーム語」「金額・契約の質問」「個人情報の入力」「営業時間外」の6つを土台にし、運用しながら記録を見て足し引きするのが現実的です。最初から細かく分けると、どの条件で渡ったのか集計できなくなります。
AIの確信度スコアを閾値にしてはいけないのですか？
使えないわけではありませんが、主軸にはしないほうが安全です。スコアの意味はモデルやプロンプトの変更で変わってしまい、非エンジニアが再調整できなくなるためです。「同じ話題で2回外したら渡す」といった回数ベースの条件なら、誰でも判断でき、後から監査もできます。
有人に渡すとき、会話ログは全文渡すべきですか？要約だけではだめですか？
全文と1〜2行の要約の両方を渡してください。要約だけだと担当者が細部を確認するために聞き直すことになり、ユーザーが同じ説明を2回することになります。逆に全文だけだと読む時間がかかって初回応答が遅れるため、要約は「担当者がすぐ状況を掴むため」に併せて必要です。
営業時間外はチャットボットを止めたほうがよいですか？
止める必要はありませんが、有人への切り替えボタンは出さないでください。「担当者におつなぎします」と言ったまま誰も出てこない状態が最も体験を損ないます。営業時間外はフォーム誘導・折り返し予約・FAQ回帰の3つに導線を切り替え、現在が時間外であることを画面に明示します。
有人対応の窓口を社内チャットにするのは問題がありますか？
通知先としては有効ですが、記録先としては不十分です。対応内容が流れて消え、誰がいつ何を答えたかを後から追えなくなります。通知は社内チャット、記録は問い合わせ管理やスプレッドシートなど別の場所、と分けて設計してください。記録がないとFAQの改善もできません。
まとめ
チャットボットの有人切り替えは、AIの性能ではなくエスカレーション条件・引き継ぐ情報・時間外の受け皿という3つの設計で決まります。この記事の設計表をそのまま埋めていけば、ツールを選ぶ前に必要な仕様はほぼ出そろうはずです。逆にここを飛ばすと、導入後に「AIが使えない」という結論になりがちですが、多くの場合は設計の抜けが原因です。
自社の問い合わせでどこまでAIに任せ、どこから人が受けるべきかの線引きは、業種と体制でかなり変わります。具体的な設計で迷われている場合はお気軽にご相談ください。現状の問い合わせの流れを伺ったうえで、どこを自動化できるかを一緒に整理します。