チャットボットから有人対応への切り替え（エスカレーション）は、ボットの導入で最も軽視されやすく、そして利用者の満足度を最も大きく左右する部分です。ボットが答えられる質問に正しく答えることは大切ですが、利用者が強く記憶するのは、ボットが答えられなかったときにどう扱われたかです。「分かりません」と返されて行き止まりになる、人と話したいのに何度もボットに戻される、やっと担当者につながったのに最初から説明し直させられる、といった体験は、ボットがない状態よりも強い不満を生みます。
エスカレーションの設計で決めるべきことは、大きく三つです。どんなときに人へ切り替えるか（条件）、どうやって人へつなぐか（手段）、人に何を渡すか（引き継ぎ情報）です。この三つを、ボットの回答内容を考えるのと同じ重さで設計しておけば、ボットが答えられない場面でも利用者の信頼を損なわずに済みます。
この記事は、AIチャットボットを導入済み、あるいは導入を予定しているカスタマーサポートの責任者や事業担当者、ボットの開発を担当するエンジニアに向けて書いています。切り替えが必要な場面の洗い出し方、切り替え条件の決め方、引き継ぎ情報の設計、営業時間外の扱い、担当者側の体制、運用での改善までを順に説明します。
エスカレーション設計が必要な理由
生成AIを使ったチャットボットは、幅広い質問にもっともらしく答えられるため、「とりあえずボットに答えさせておけばよい」と考えがちです。しかし、ボットに任せてはいけない問い合わせは必ず存在します。その理由は三つあります。
一つ目は、ボットには判断の権限がないことです。返金するかどうか、例外として対応するかどうか、補償をどうするか、といった判断は、企業として責任を持って行う必要があり、ボットが代わりに約束することはできません。
二つ目は、ボットが参照できる情報には限りがあることです。手元の文書にない情報、個別の契約や取引の詳細、システム障害の最新状況などは、ボットが正確に答えられない領域です。生成AIは情報が足りなくても文章を作れてしまうため、仕組みで止めない限り、根拠のない回答が出るおそれがあります。
三つ目は、感情への対応です。不満や怒りを抱えている利用者に、正確だが機械的な回答を返し続けると、問題がこじれます。相手の状況を汲み取り、裁量を持って対応できる人が受け止めるべき場面があります。
人とAIの役割を分担し、重要な場面で人が判断に関わる設計の考え方は、ヒューマン・イン・ザ・ループと呼ばれます。エスカレーションの設計は、問い合わせ対応におけるその具体化だと言えます。
有人対応に切り替えるべき場面を洗い出す
まず、過去の問い合わせの記録と、ボットの試作段階や運用中の会話ログから、人が対応すべき場面を洗い出します。洗い出した場面は、次の四つの型に分けると条件を設計しやすくなります。
| 型 | 場面の例 | 切り替えの考え方 |
|---|---|---|
| 答えられない | 参照文書に根拠がない、質問の意図が読み取れない、同じ質問が繰り返される | 根拠がない時点で推測を止め、人へつなぐ選択肢を示す |
| 答えるべきでない | 返金・補償・例外対応の判断、法的な見解、医療や安全に関わる内容 | 話題を検知した時点で回答を生成せず、人へつなぐ |
| 利用者が人を求めている | 「人と話したい」「担当者を出して」という要望 | 理由を問わず、すぐに人へつなぐ手段を示す |
| 状況が深刻 | 強い不満や怒り、事故や不具合による被害、個人情報の漏えいの申告 | 優先度を上げて人へつなぎ、緊急時の連絡先も示す |
この表のうち、「答えるべきでない」と「状況が深刻」は、件数が少なくても見落としてはいけない場面です。例えば、架空の例として、家電の通販サイトで「届いた製品から焦げたにおいがする」という問い合わせが来た場合、ボットが一般的な使い方の説明を返すのは不適切です。安全に関わる申告として、使用中止の案内とあわせて、すぐに担当者へつなぐ必要があります。こうした場面は、過去の記録に少数しか現れなくても、必ず条件に含めておきます。
洗い出しの際は、サポートの担当者だけでなく、返金や補償の判断をする責任者、法務や品質管理の担当者にも「ボットに絶対に答えさせたくない話題」を挙げてもらうと、現場の記録だけでは見えない場面を拾えます。挙がった話題は、例となる言い回しとあわせて一覧にし、切り替え条件の設計とテストの両方に使います。
切り替え条件を設計する
洗い出した場面をもとに、ボットが人へ切り替える条件を具体的に定義します。条件は、ボットが自分で判断する「AIの判断による条件」と、仕組みとして確実に動く「ルールによる条件」を組み合わせて設計します。
ルールによる条件
確実に人へつなぐべき場面は、生成AIの判断に任せず、仕組みとして決めます。
- 利用者が「担当者と話す」ボタンを押した、あるいは人を求める決まった表現を入力した
- 特定の話題（返金、解約、事故、個人情報、法的措置など）に該当する語句が含まれる
- 参照文書の検索で、根拠になる文書が見つからなかった
- 同じ趣旨の質問が一定回数繰り返された
- ボットの回答に「解決しない」が続けて押された
- 会話のやり取りが一定回数を超えても終わらない
AIの判断による条件
ルールでは拾いきれない場面は、生成AIに会話を判定させます。例えば、会話の内容から「不満や怒りが強いか」「緊急性があるか」「ボットの回答で解決したか」を判定させ、条件に当てはまれば切り替えを提案します。ただし、AIの判定は誤ることがあるため、判定の結果だけで重要な対応を決めず、ルールによる条件の補助として使うのが安全です。
切り替えの伝え方
条件に当てはまったときのボットの伝え方も設計します。いきなり「担当者におつなぎします」と切り替えるよりも、「この内容は担当者が確認してご案内します。おつなぎしてよろしいですか」のように、理由と次に起きることを伝えたうえで選んでもらう方が、利用者は安心できます。一方で、利用者が人を求めている場合は、確認を重ねず、すぐにつなぎます。「本当に担当者につなぎますか」「その前にこちらをご覧ください」と引き止める設計は、不満の原因になります。
ボットの振る舞いに制約をかけ、危険な回答を防ぐ仕組みはガードレールとも呼ばれます。切り替え条件は、そのガードレールの一部として設計すると整理しやすくなります。
引き継ぐ情報を設計する
切り替えた後に担当者が最初から聞き直すことになると、利用者は同じ説明を二度することになり、担当者の対応時間も伸びます。引き継ぐ情報は、担当者が会話を読み直さなくても状況をつかめる形に整えて渡します。
引き継ぎ情報に含める項目は、次のとおりです。
- 問い合わせの要約：利用者が何に困っていて、何を求めているかを数行で
- 分類：問い合わせのテーマ、緊急度、切り替えの理由（どの条件に当てはまったか）
- 利用者が入力した情報：注文番号、契約者名、製品名、発生日時など
- ボットが提示した回答：どの文書を根拠に何を案内したか
- 会話の全文：要約で足りない場合に確認できるように
- 利用者の連絡先と希望する連絡方法：時間外の場合や、折り返しが必要な場合
要約と分類は生成AIで作れます。ただし、要約が事実と違うと担当者の判断を誤らせるため、利用者が入力した具体的な情報（番号や日時など）は要約とは別に、入力されたとおりに渡します。
また、ボットの段階で必要な情報を集めておくと、担当者の対応がさらに早くなります。例えば、配送のトラブルなら注文番号と届いた日、不具合なら製品名と症状、といったように、テーマごとに聞くべき項目を決めておき、切り替えの前にボットが確認します。ただし、聞く項目が多すぎると利用者の負担になるため、担当者が最初に必ず確認する項目に絞ります。
引き継ぎの具体例
架空の例として、定期配送の食品サービスで、利用者が「先週届いた箱の中身が一部足りなかった。今週の分も同じだったら困る」とボットに書き込んだ場面を考えます。ボットは欠品に関する案内文を参照して、欠品時の対応方針を説明しますが、「補償の内容」は担当者の判断が必要な話題として切り替え条件に該当します。
このとき、ボットは切り替えの前に「お届け日」と「足りなかった商品」を確認し、「担当者が確認してご連絡します。おつなぎしてよろしいですか」と伝えます。担当者には、「先週の配送で一部欠品。今週分への不安あり。補償の確認を希望」という要約、分類（配送・欠品、緊急度は中、理由は補償に関わる話題）、利用者が入力したお届け日と商品名、ボットが案内した欠品時の方針、会話の全文が渡ります。担当者は会話を読み直さずに状況をつかみ、今週分の出荷状況を確認したうえで返答できます。
引き継いだ問い合わせは、既存の問い合わせ管理の仕組みに一件の案件として登録し、対応の状況を追えるようにしておきます。問い合わせを案件として管理する考え方は、用語ページのチケット管理で解説しています。
切り替えの手段と営業時間外の扱い
人へつなぐ手段は、担当者の体制と問い合わせの緊急度によって使い分けます。
| 手段 | 向く場面 | 注意点 |
|---|---|---|
| 有人チャットへの切り替え | 営業時間内で、担当者がすぐ対応できる | 待ち時間の目安を示す。待ちが長いときは別の手段を提案する |
| フォーム・メールでの受付 | 営業時間外、または調査が必要で即答できない | 返信の目安となる時期と、受付が完了したことを伝える |
| 電話窓口の案内 | 緊急性が高い、安全に関わる、文字でのやり取りが難しい | 受付時間と番号を明示する。時間外の緊急連絡先があれば示す |
| 折り返し連絡の予約 | 担当者が混み合っている、専門の担当者が必要 | 連絡の希望時間帯と連絡先を確認する |
営業時間外の扱いは特に重要です。時間外に「担当者におつなぎします」と表示して、誰も応答しない状態になるのは最悪の体験です。時間外は、受付だけを行い、受付番号と返信の目安を伝える設計にします。緊急性の高い内容が時間外に来た場合にどうするか（緊急連絡先を案内する、当番の担当者に通知する、など）も、事前に決めておきます。
担当者側の体制と運用
エスカレーションの設計は、ボットの側だけで完結しません。引き継がれた問い合わせを受ける担当者側の体制も合わせて設計します。
ボットの導入後、担当者に届く問い合わせの中身は変わります。簡単な質問はボットが処理するため、担当者のもとには、判断が必要な問い合わせ、感情的になっている利用者、複雑な事情の相談が集まります。件数は減っても、一件あたりの対応時間は長くなる傾向があります。人員配置と対応手順は、この変化を前提に見直します。
運用では、次の点を定期的に確認します。
- 切り替えの件数と理由の内訳：どの条件で切り替わっているかを見て、ボットで対応できるようにすべきものと、条件を見直すべきものを分ける
- 切り替え後の待ち時間：有人チャットで待たせすぎていないか、時間外の受付が適切に処理されているか
- 引き継ぎ情報の質：担当者が聞き直しをしている項目があれば、ボットで確認する項目や要約の作り方を見直す
- 切り替えなかったが解決していない会話：ボットの会話後に別の窓口で問い合わせがあったものを確認し、切り替え条件の漏れを探す
- 切り替えすぎていないか：本来ボットで答えられる質問が人に回っていないか
4と5は反対方向の確認です。切り替えが少なすぎると利用者の不満が増え、多すぎると担当者の負担が減りません。両方を見ながら条件を調整します。
一次対応と二次対応を分ける
問い合わせの量が多い場合や、専門的な内容が混ざる場合は、引き継ぎ先を一段階で考えず、一次対応と二次対応に分けると運用しやすくなります。一次対応の担当者が引き継ぎ情報をもとに受け止め、判断や調査が必要なものだけを専門の担当者や関係部署に回す形です。このとき、ボットが付けた分類と緊急度をそのまま振り分けに使えるようにしておくと、一次対応の負担が軽くなります。逆に、分類の精度が十分でないうちは、ボットの分類を参考情報として扱い、一次対応の担当者が最終的に振り分ける運用が安全です。
エスカレーション設計チェックリスト
- 人を求める利用者が、いつでも人へつなぐ手段を選べる
- 返金・補償・法的判断・安全に関わる話題で、ボットが回答を生成しない
- 根拠となる文書がないとき、推測で答えずに切り替えを提案する
- 切り替えの理由と次に起きることを利用者に伝えている
- 引き継ぎ時に要約・分類・入力情報・ボットの回答が担当者に渡る
- 営業時間外の受付で、返信の目安と受付の完了が伝わる
- 時間外の緊急の申告への対応方法が決まっている
- 引き継いだ問い合わせが問い合わせ管理の仕組みに登録される
- 切り替えの件数と理由を定期的に確認する担当者が決まっている
よくある失敗と避け方
ボットで完結させることを目標にしすぎる
ボットでの解決率を上げることだけを目標にすると、人へつなぐ手段を見つけにくくする設計に傾きがちです。利用者が人を求めたときにはすぐつなぐことを前提に、ボットで解決できる問い合わせを増やす方向で改善します。
切り替え条件を生成AIの判断だけに任せる
AIの判定は便利ですが、誤ることがあります。返金や安全に関わる話題など、確実に人へつなぐべき条件は、ルールとして仕組みに組み込みます。
引き継ぎ情報が会話の全文だけ
全文だけを渡すと、担当者は長い会話を読み直す必要があり、対応が遅れます。要約と分類、入力された具体的な情報を整理して渡し、全文は確認用にとどめます。
時間外の動きを確認していない
試作やテストは営業時間内に行われることが多く、時間外の動きが確認されないまま公開されることがあります。時間外の受付、返信目安の表示、緊急時の案内は、公開前に必ず確認します。
切り替えた後に利用者を放置する
切り替えを受け付けた後、担当者からの連絡がいつ来るのか分からない状態が続くと、利用者は別の窓口にも問い合わせ、対応が重複します。受付時に返信の目安を伝えることに加え、目安を過ぎそうな場合は途中経過を連絡するなど、受け付けた後の動きも手順に含めておきます。
よくある質問
Q. 有人対応の体制がない場合、ボットから何につなげばよいですか？
チャットで即時に対応する体制がなくても、フォームやメールでの受付につなぐことはできます。重要なのは、受付が完了したことと、いつ頃返信するかを伝えることです。ボットの会話内容を受付の情報として引き継げば、返信時の確認の手間も減らせます。
Q. 「人と話したい」と言われたら、すぐにつなぐべきですか？
基本的にはすぐにつなぐことをおすすめします。引き止めてボットでの解決を促すと、不満が高まりやすくなります。ただし、担当者の待ち時間が長い場合は、その目安を伝え、待つか、フォームで受け付けて折り返すかを選んでもらうとよいでしょう。
Q. ボットの会話ログを担当者に渡すとき、個人情報の扱いはどうすればよいですか？
引き継ぎ先の担当者が見られる範囲、ログの保存期間、目的外の利用をしないことなどを、社内のルールとして定めます。利用者に向けては、入力内容の利用目的を表示しておきます。具体的な取り扱いは、個人情報保護に関する最新の指針や専門家の助言を確認してください。
Q. メールの問い合わせにも同じ考え方を使えますか？
使えます。メールの場合は、AIで内容を分類し、ボットが自動返信してよいものと担当者が対応すべきものを振り分ける形になります。考え方は問い合わせメールの振り分けを生成AIで自動化する方法と注意点で解説しています。
Otsumuに相談できること
利用しているチャットボットのツールに有人チャットへの切り替え機能があり、問い合わせのテーマも限られているのであれば、この記事の切り替え条件と引き継ぎ情報の考え方を当てはめ、ツールの設定で対応できることは多いはずです。まずは会話ログから切り替えが必要な場面を洗い出し、条件と案内文を整えるところから、自社で進められます。
一方で、ボットと既存の問い合わせ管理の仕組みを連動させたい、注文や契約のデータを引き継ぎ情報に自動で含めたい、時間外の緊急対応を当番の担当者への通知と組み合わせたい、といった要件がある場合は、システムの設計と開発が必要になります。ボットの導入全体の進め方は、問い合わせ対応をAIチャットボットで自動化する設計と導入手順もあわせてご覧ください。
Otsumuでは、問い合わせの棚卸しと切り替え条件の設計から、生成AIを使ったチャットボットと有人対応の連携の開発、運用改善までを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した少人数の開発で、小さく始めて改善を重ねる進め方を取ります。詳しくはAIチャットボット開発のページをご覧ください。
今のボットのどこで利用者がつまずいているか、ログを見ながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01