有人エスカレーションの設計｜AIチャットボットと人の切り分け方

「チャットボットは便利そうだけれど、AI が答えられない質問や、怒っているお客様が来たらどうするのか」──AI チャットボットの導入を検討すると、必ずこの問いに行き当たります。答えは有人エスカレーション、つまり AI が受けた問い合わせを人の対応へ引き継ぐ仕組みを設計しておくことです。ただし、ここに大きな誤解があります。有人エスカレーションは「AI が失敗したときの保険」ではなく、最初から人が受けると決めた用件を確実に人へ渡すための設計です。保険として後付けするか、設計として先に引くか。この順序の違いが、導入後の運用が回るかどうかを分けます。この記事では、人に渡す用件の線引き、切り替えの起点、切り替えた先の受け皿、そして設計を回す 4 ステップを、順番に解説します。

有人エスカレーションとは ── AI と人の役割を分ける仕組み

有人エスカレーションとは、AI チャットボットが受け付けた問い合わせを、途中からオペレーター(人)の対応に引き継ぐ仕組みのことです。チャット上で「担当者におつなぎします」と切り替わる動きが、もっとも分かりやすい形です。多くのチャットボットが標準機能として備えており、機能そのものは特別なものではありません。

問題になるのは機能の有無ではなく、その機能をどういう位置づけで使うかです。「AI がうまく答えられなかったときの逃げ道」として捉えると、切り替えの条件も受け皿も曖昧なまま導入が進みます。そして、うまく答えられなかった場面が実際に起きてから慌てて設計することになります。

順序を逆にします。まず「この用件は人が受ける」と決め、その用件が来たときに確実に人へ届く経路として有人エスカレーションを作る。線を先に引いておくと、AI に任せる範囲を広げても怖くありません。任せられない用件は必ず人に届くと分かっているからです。

この線が引かれていない導入は、経験的に両極のどちらかに寄ります。片方は過剰規制で、「AI が誤ったことを言うと困る」という不安から回答できる範囲を極端に狭め、結果として顧客は「結局電話するしかない」と判断してしまう状態です。もう片方は丸投げで、AI が何でも答えようとして、判断や例外対応にまで踏み込んだ回答を返してしまう状態です。線を引く作業は、この両極を同時に避けるためのものだと考えてください。

AI チャットボットが「一問一答の FAQ を作り込まずに答えられる」仕組みと、そこで答えられない質問を有人へ渡す前提については「FAQ作り込み不要のAIチャットボットとは」で触れました。本記事はその「有人へ渡す」の中身を、具体的な設計手順まで掘り下げるものです。問い合わせ対応の負荷を下げる打ち手の全体像は「コールセンターの問い合わせを削減する方法【完全ガイド】」にまとめています。

何を人に渡すか ── 切り分け線の引き方

設計の出発点は「何を人に渡すか」です。用件を性質で分けると、業種を問わずおおむね次の 4 種類に収まります。それぞれ一次対応をどちらが受けるべきかが構造的に決まります。

実際の問い合わせをこの 4 種類に振り分けるとき、迷う用件が出てきます。そのときは次の 3 つを順に問うと判定できます。

• ①答えが「文書に書いてあること」で足りるか ── 足りるなら AI。足りず、その場の解釈や裁量が必要なら人です。
• ②会社として約束・意思決定をする用件か ── 金額・期日・特例の約束が絡むなら人です。AI に約束をさせない、というのは設計上の原則にしてよい線です。
• ③間違えたときにやり直しが効くか ── 案内を訂正すれば済むなら AI に任せられます。訂正が効かない(手続きが進んでしまう・信頼を損なう)なら人です。

ここで正直に書いておくと、AI が答えられない領域は必ず残ります。③④のように構造的に人が受けるべき用件があり、加えて①②の中にも社内文書が整っていない領域は残るためです。有人エスカレーションの設計とは、この「残ること」を前提に置く作業です。ゼロにしようとするのではなく、残る用件が確実に人へ届くようにする──そう捉えると、設計するべきものがはっきりします。

なお、線の位置は業種で動きます。不動産管理や設備保守のように夜間の緊急連絡があり得る業種では「緊急の申告」を独立した層として扱う必要がありますし、医療・金融のように回答自体に法令上の制約がある領域では、①に見える質問でも人が受ける設計にすることがあります。自社の 4 分類を作るときは、この業種固有の例外を最初に足しておきます。

いつ切り替えるか ── 3 つの起点

渡す用件が決まったら、次は「どのタイミングで切り替わるか」です。切り替えの起点は 3 つあり、3 つを重ねて使うのが前提です。どれか 1 本足で組むと必ず取りこぼしが出ます。

この 3 層を重ねたうえで、もう 1 つ決めておきたいのが切り替えの速さです。顧客の不満は「AI が答えられなかったこと」より「答えられないまま何往復も付き合わされたこと」で大きくなります。切り替えは早い方が体験が良い──この前提で回数の上限を先に決めておくと、AI の精度を上げる作業と顧客体験を守る作業を切り離して進められます。

切り替えた先の受け皿を決める

設計でもっとも抜けやすいのが、切り替えた先です。「オペレーターにおつなぎします」と表示されたのに誰も出てこない、という状態は、機能としては動いていても設計としては未完成です。受け皿は次の 4 点を決めて初めて完成します。

• ①どのチャネルで受けるか ── 有人チャットでそのまま続ける、電話番号を案内する、フォームに用件を残してもらう。自社の体制で無理なく回るものを選びます。
• ②誰が受けるか ── 担当者・当番の決め方と、通知がどこに飛ぶか(メール・チャットツール・管理画面)を決めます。「気づける人が気づく」運用にしないことが要点です。
• ③営業時間外はどうするか ── 有人の受け皿が営業時間内だけなら、時間外は「用件を受け付けて、いつ返すかを伝える」形に切り替えます。時間外は人につながらないと明示すること自体が誠実な設計です。
• ④待たせる場合の伝え方 ── すぐ応答できないときに、順番や返答の目安を伝えます。待つこと自体より、待ち時間が分からないことが不満を生みます。

もう 1 つ、導入前に確認しておきたい論点があります。切り替えたあと、オペレーター側で顧客がそれまでに書いた内容をどこまで参照できるかです。ここはツールによって対応範囲が異なるため、検討中のサービスに個別に確認してください。参照できない前提で組む場合は、切り替える前に用件の要点を確認する、フォームに要点を残してもらってから人が受ける、といった運用でカバーできます。「顧客に同じ説明を二度させない」ための工夫は、機能で解く場合と運用で解く場合があり、どちらでも設計として成立します。

切り分け設計の 4 ステップ

ここまでの内容を、実際に進める順番に並べます。特別なツールは要りません。手元の問い合わせ記録から始められます。

ステップ 1: 直近の問い合わせを 4 分類に振り分ける

2〜4 週間分の問い合わせ(電話のメモ・メール・フォーム)を取り出し、前半の 4 分類に振り分けます。ここで見たいのは件数の多さより「自社の問い合わせに ③④ がどれだけ含まれるか」という質です。③④が厚い業種なら有人の受け皿を先に固める必要があり、①が大半なら AI 側のナレッジ整備に投資の重心を置けます。振り分けの過程で「これは AI に任せたくない」と感じた用件は、その理由を一言メモしておきます。次のステップの材料になります。

ステップ 2: 切替ルールを文章にする

3 つの起点それぞれについて、条件を文章で書き出します。顧客の申し出はどこに出口を置くか、AI 側の判断は何往復で渡すか、強制ルールはどの語・どの経路を条件にするか。あわせて禁止事項も書きます。「金額・期日・特例の約束を AI にさせない」「謝罪で終わらせる回答を AI に出させない」といった線です。ここを口頭合意ではなく文章にしておくと、担当者が変わっても設計が生き残ります。

ステップ 3: 受け皿と担当を決めて通知経路を作る

前のセクションの 4 点(チャネル・担当・時間外・待たせ方)を決め、通知が実際に届くところまで作ります。ここで一度、自分たちで顧客役をやって切り替えを試すことをおすすめします。通知が誰にも届かない、当番が不在の時間帯があるといった穴は、机上の設計では見つかりません。試すのは 10 分で済みます。

ステップ 4: ログで線を引き直す

運用が始まったら、月に一度、切り替わった会話のログを見返します。見るのは切替の件数ではなく切替の理由です。理由ごとに次の一手が変わります。定型の質問なのに人へ渡っていたなら、その質問をナレッジに反映して AI 側に戻します。AI が答えてしまっていたが本来は人が受けるべきだった用件が見つかったなら、強制ルールの条件に足します。この往復で、最初に引いた線が自社の実態に合っていきます。

AI 側が答えられる範囲は、突き詰めると資料の質と構造で決まります。どんな資料をどう整えると回答の精度が上がるのかは「社内ナレッジをAIに回答させる仕組み(RAG入門)」で仕組みの側から解説しています。ステップ 4 で「ナレッジに反映する」と決めたとき、実際に何をどう書き足すかの判断材料になります。

なお、切り替えた先のオペレーター側の運用──当番の組み方、応対の品質をどう見るか、チャット対応と電話対応の兼務をどう設計するか──は、それ自体が独立したテーマです。本記事では受け皿として決めるべき 4 点までにとどめ、有人対応側の体制設計は別記事で詳しく扱う予定です。

AI と人の切り替えを前提に設計するなら

ここまでの設計を前提にした AI チャットボットの一例として、当社の「コルット」を紹介します。コルットは HP に設置する顧客対応 AI チャットボットで、ボタン選択式ではなく記述式(自由入力)のため、顧客は用件を自分の言葉で書くだけで済みます。知識源はマニュアル・規定・対応ログなどの社内ナレッジで、一問一答の FAQ を作り込む必要はありません。そして本記事の主題である切り替えについては、クレームや複雑な相談はオペレーターへ即時切替する設計です。24 時間 365 日稼働するため、有人対応が営業時間内だけの体制でも、時間外の一次対応と受付を止めずに運用できます。設置は HP に専用タグを 1 行貼るだけ、最短 3 日で本番稼働します。

よくある質問