本文へスキップ
tech公開更新約8分で読めます

コールセンターAIの対応範囲をどう決めるか:用件と顧客の期待を分けて考える

シェア
【FC要修正】コールセンターAIの対応範囲をどう決めるか:用件と顧客の期待を分けて考える

コールセンターにAIを入れるとき、最初に作られるのはたいてい「用件の一覧」である。住所変更、パスワード再設定、配送状況の確認、解約。一覧の横に「AI対応可」「人が対応」と印を付けていけば、対応範囲はひとまず決まる。ところが、同じ「パスワード再設定」でも、電話をかけてくる人の事情はそろっていない。単に忘れただけの人もいれば、身に覚えのないログイン通知を受けて不安になっている人もいる。用件名だけで線を引いた範囲表は、この違いを表に載せる場所を持っていない。

本稿の問いは、用件名だけでAIの適否を決めず、顧客の困り方や期待の違いをどう範囲表に組み込むか、である。先に立場を置くと、私は「用件」と「期待」を別の列として扱い、期待はAIによる感情の推定ではなく本人の申告と状況の確認で見分け、例外を明記した表をマネジメントが決めるのが現実的だと考えている。なお、本稿の手順・表・ケースはすべて編集部の提案であり、ケースは説明のための架空の例である。

用件が同じでも求める支援は違う

用件が同じでも求める支援は違う

この論点の出発点は、CC AI Labの対談での議論にある。長掛文子氏と阿久根氏の対談で、長掛氏は、問い合わせには「困っていることを解決してほしい」というニーズと「困っている気持ちを理解してほしい」というニーズの2つがあると述べた。阿久根氏は、一次受付はAIに任せたいが、難解な案件や感情的な案件をすぐ人へ渡す制御をどこまで作り込めるかが課題で、現状は用件や内容の複雑さによる振り分けが中心だと論じている。以下は、この2人の見解を出発点に、編集部が独自に組み立てた判断手順である。

顧客側の調査にも、同じ方向の手がかりがある。Gartnerの顧客調査(2023年12月実施、5,728人、2024年7月発表)では、64%がカスタマーサービスにAIを使わないでほしいと答え、最大の懸念は人の担当者につながりにくくなることだった。もっとも、これは「AIそのものが嫌われている」とだけ読むべきではない。

米国でコンタクトセンターのアウトソーシングを手がけるLiveopsが2026年5月に米国成人1,000人に行ったLiveopsの調査(同社発表)では、46%が「自動化が最も役立つのは簡単で定型的な依頼」と答え、42%が「自動応答が問題を理解できなかった時点で人に移ってほしい」と答えている。同じ人が、ある場面ではAIで十分と考え、別の場面では人を求める。ただし、どちらも米国中心の調査であり、日本の顧客にそのまま当てはまるとは限らない。

ここから言えるのは、AIの適否を決める単位は「用件」だけでは粗すぎる、ということだ。駅の券売機にたとえると分かりやすい。切符を買うだけの人には券売機が最速だが、乗り越しで精算額が分からない人や、定期券を落として動揺している人には、同じ券売機の前でも窓口が要る。駅は「切符」という用件で窓口を決めているのではなく、困り方で窓口へ案内している。

架空の3ケースで見てみる。

  • ケースA: 久しぶりに使う会員サイトのパスワードを忘れた。急ぎではなく、手順が分かれば自分で済ませたい

  • ケースB: 身に覚えのないログイン通知が届き、不正利用を心配している。パスワードを変えたいが、それで安全になるのかを知りたい

  • ケースC: 再設定を何度か試して失敗し、今日が支払い期限。手続きを確実に終わらせたいが、同じ説明を繰り返すことに疲れている

用件名はどれも「パスワード再設定」である。しかし、Aが求めるのは手続きの完了、Bが求めるのは状況の説明と安心、Cが求めるのは期限内の確実な完了と、これ以上手間を増やさないことだ。

手続き完了と気持ちを受け止める支援を分ける

ここで編集部が提案したいのは、範囲表の列を「用件」と「期待」に分けることだ。期待は次の3類型で足りると考えている。

  • 手続き型: 手順どおりに完了すれば目的が果たされる(ケースA)

  • 説明・安心型: 手続きの前後に、何が起きているか、次に何が起きるかの説明を求めている(ケースB)

  • 受け止め型: 不満や焦りが強く、事情を聞いてもらうこと自体が支援の一部になっている(ケースCの一部)

重要なのは、期待の類型をどう見分けるかである。「AIが声のトーンから感情を推定して振り分ける」という発想は魅力的に見えるが、私はここを出発点にしないほうがよいと考えている。推定の精度をセンター側で検証する手段が限られるうえ、誤判定したときに顧客へ説明できないからだ。代わりに、次の2つを優先する。

第一に、本人の申告である。一次受付で「手続きだけ済ませたいですか、それとも状況の説明が必要ですか」と選択肢を示し、いつでも「担当者と話す」を選べるようにする。Gartnerの調査で最大の懸念が「人につながりにくくなること」だった点を踏まえると、この出口を常に見せておくこと自体が、範囲表の前提条件になる。

第二に、状況の確認である。「不正ログインの通知を受けた」「今日が期限」「直近に同じ用件で問い合わせている」「手続きに複数回失敗している」といった事実は、感情を推定しなくても確認できる。こうした状況フラグを、期待の類型に対応づけておく。

この分け方をすると、「AIか人か」の二択ではなく、中間の選択肢が生まれる。たとえばケースBなら、AIが不正利用時の一般的な手順を案内したうえで、再設定の完了後に人が状況を確認する、という分担もありうる。反対に、ケースCのように再問い合わせと期限が重なっている場合は、手続き自体は定型でも、最初から人が受けたほうが結果的に早く終わる可能性がある。

例外を残した対応範囲表をマネジメントが決める

例外を残した対応範囲表をマネジメントが決める

以上を1枚にまとめたのが次の表である(編集部案・架空の記入例)。

用件

期待の類型

見分ける手がかり

担当

例外(人へ回す条件)

パスワード再設定

手続き型

本人が「手続きのみ」を選択

AIで完結

本人確認で2回失敗

パスワード再設定

説明・安心型

「不審な通知を受けた」の申告

AI案内+完了後に人が確認

不正利用の疑いが具体的

パスワード再設定

受け止め型

期限当日、直近の再問い合わせあり

最初から人

なし(原則人)

住所変更

手続き型

本人が「手続きのみ」を選択

AIで完結

転居理由の相談を含む

この表で大事なのは、右端の「例外」列を空欄にしないことだ。用件ごとに「AIで完結」と書いた瞬間から、その行は例外を持たない前提で運用されやすい。例外列があることで、現場は「この条件なら人に回してよい」という根拠を持てる。

そして、この表を決めるのはベンダーでも現場の個々のオペレーターでもなく、センターのマネジメントである。長掛氏も対談で、どの部分をAIに任せ、どの部分を人に残すかはマネジメントが判断して導入すべきだと述べていた。編集部としては、決め方の手順を次の4段階として提案する。

  1. 用件別の件数上位から順に、期待の類型が混在しているかを通話録音やログの抜き取りで確認する

  2. 混在している用件だけ行を分け、見分ける手がかり(申告の選択肢と状況フラグ)を決める

  3. 各行に担当と例外条件を書き、現場のSVと一緒に抜け漏れを点検する

  4. 運用開始後、例外で人に回った件数と理由を定期的に見直し、行を足すか統合する

ここからは私の見立てとして、この方法の弱点も書いておく。期待を尋ねる選択肢を一次受付に足せば、その分だけ手続き型の顧客にとっては手間が増える。表の行が増えすぎれば、保守しきれず形骸化する。だから、すべての用件で期待を分ける必要はない。期待の混在が実際に見つかった用件だけを分け、それ以外は用件単位のままにしておくほうが運用は続く。

実装面で、人へ渡す判定のタイミングや文脈の引き継ぎをどう設計するかは、AIから人へ渡す設計の記事で扱っている。「人にしかできない対応」という言い方そのものを分解した議論は、共感・例外・交渉を分解する対話が前提を引き受けている。本稿は、その手前にある「どの用件のどの期待をAIに任せるか」を表に落とす段階に絞った。

まとめ

第一に、同じ用件でも、顧客が求める支援は手続き完了、説明と安心、受け止めに分かれうる。用件名だけで引いた線は、この違いを取りこぼす。

第二に、期待の見分けは感情の推定から始めず、本人の申告と確認できる状況を手がかりにする。そして「担当者と話す」という出口を常に見せておく。

第三に、範囲表には例外列を置き、決定と見直しをマネジメントが担う。行を分けるのは、期待の混在が実際に確認できた用件に限る。

あなたのセンターの用件一覧のうち、同じ用件名の裏で、まったく違うことを求めて電話してきている顧客がいるのはどの行だろうか。

対談で議論の出発点を読む

本稿の出発点になった、長掛氏と阿久根氏による「解決」と「共感」の議論、感情的な案件を振り分けることの難しさについての対談は、無料会員登録で全文を読めます。

【AIに「丁寧さ」はいらない?】AI時代に求められるコンタクトセンターの“応対品質”とは(会員限定)


注記: 本稿の事実関係は2026年9月18日時点で確認した。調査の数値は各発表元の公表内容に基づく(Liveopsの数値は同社発表)。本文中の3ケースと対応範囲表は説明のための架空例であり、判断手順は編集部の提案である。対談参加者の見解は各話者に帰属し、本稿の手順・表を話者の発言として示すものではない。記事中の見立ては筆者個人の見解である。


この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア