戦略編
第1回新連載
生成AIの普及とともに、コンタクトセンターにおけるAI活用への関心は急速に高まっています。しかし、「導入したい」という熱量と、「運用し続ける」という現実の間には、まだ大きな溝があります。本連載では、現場で直面する課題と、その判断基準をお伝えします。第1回は、AIオペレータ導入プロジェクトが失敗に終わる根本的な原因となる3つの罠を取り上げます。
「デモを見たとき、これは革命だと思った。でも、本番稼働まで漕ぎ着けたら、想定外の問題が続出した」。AIオペレータ導入に関わるコンタクトセンター担当者から、こうした声を頻繁に耳にするようになりました。
大規模言語モデル(LLM)の自律性を活用したAIオペレータは、柔軟な応対と幅広い問い合わせへの対応が可能になります。デモを見て、その可能性に心を動かされる方も多いでしょう。
問題は、「デモで動いた」と「本番で運用し続けられる」の間に、相当な設計の工夫と運用の積み重ねが必要だという点です。LLMに適切なコンテキストを与え、実運用に耐えるAIオペレータを構築するには、プロトタイプ作成とはまったく異なる難易度の取り組みが求められます。導入すれば「勝手にうまくいく」というシンプルな技術ではなく、正しく設計し、継続的に改善し続けることで、初めてその真価が発揮されます。
本稿では、その「工夫なき導入」が陥りやすい3つの罠を整理します。罠を知ることが、AIオペレータのポテンシャルを最大限に引き出す第一歩です。
導入プロジェクトが失敗する落とし穴は、PoC(概念実証)と本番運用の間にある深い「溝」です。MIT Media Lab NANDAの調査によれば、AIシステムのPoC導入プロジェクトのうち、本番展開まで到達するのは、わずか5%に過ぎません。残りの95%はPoC止まり、あるいはデモ止まりで終わります。この数字は、日本のAIオペレータ領域でも例外ではありません。
なぜ、これほど本番展開に至らないのか。PoC段階では、応対ルールは単純で範囲も限定的なため、問い合わせのパターンは少なく、一度構築してしまえば人力でなんとか管理できます。ところが、本番展開に向けて対応範囲を広げていくと、プロンプトの数、ナレッジデータの数、応対ルールの組み合わせが爆発的に増加していきます。
この「組み合わせ爆発」が起きた瞬間、急に機能しなくなるのです。また、デモで見せた滑らかな応対は、限られたシナリオの中での動作にすぎません。ここにも、対応するリーズンを広げれば広げるほど難しくなる、という構造的な問題があります。
ここからは、この「溝」を生み出す3つの具体的な罠を解説します。

第一の罠は、「顧客体験の罠」です。AIオペレータ導入の目的として最もよく挙がるのが、「コスト削減」です。しかし、カスタマーサポートの本来の目的は、顧客の問題解決にあります。コスト削減はその結果として得られるものであって、目的ではありません。AI導入による自動化が目的化し、問い合わせを無理に減らし、人員削減が先行すると、本質的な「顧客満足」が犠牲になってしまいます。
スウェーデンの決済企業Klarna(クラーナ)は2024年、コンタクトセンターを全面AI化し、大規模な人員削減を発表しました。AI活用の先進事例として注目を浴びましたが、その約1年後にこの方針を撤回しています。過度なAI化がNPS(ネット・プロモーター・スコア:製品、サービス、ブランドを他者に推奨するかを聞き、集計した指標。フレドリック・F・ライクヘルド氏およびベイン&カンパニーの登録商標)と顧客満足度を著しく低下させ、顧客離反を招いたからです。同社は採用を再開し、「適切なAIと人の協働」を模索しています。
なぜKlarnaの顧客体験は悪化したのか。AIが苦手とするのは熟練したオペレータが自然に行っている「暗黙の気遣い」──このタイミングで確認を入れる、顧客の状況に合わせて言葉を選ぶ、会話の流れを読んで寄り添う。こうした機微は、ナレッジデータには記述されていません。そのため、現状のAIには、人間のオペレータが持つ「文脈への敏感さ」の再現が難しく、人間と同水準の体験を提供することは困難なのです。
これを踏まえると、AIオペレータを設計する際は、「顧客満足度は下がっていないか」「会話がぶつ切りになっていないか」「お客様がAIに“ありがとう”と言っているか」といった顧客体験に関する指標を中心に置くことが不可欠といえます。コスト指標より先にCX指標を設計の起点に置く思想こそが、第一の罠を避ける出発点になります。
第二の罠は「チューニングの罠」です。
イベントや展示会でよく見るAIオペレータのデモの8〜9割は、 「ナレッジデータを用意し、応対ルールをすべてプロンプトに書き込む」というアプローチで作られています。このアプローチはPoC段階では機能しますが、いざ本番運用に移行すると、深刻な問題が浮上してきます。
まず「プロンプトの肥大化」です。対応範囲の拡大に伴い、応対ルールの組み合わせは指数的に増加し、プロンプトも膨大な文字数に膨らんでいきます。こうなると、プロンプトはブラックボックス化し、「どの記述がどの挙動に影響しているか」を追跡することが難しくなります。結果、特定の担当者にしか運用できない「属人化」という深刻な問題も出てきます。
さらに危険なのが「デグレーション(機能退行)」の問題です。AIオペレータの応対品質が悪いと気づき、1つのプロンプトを修正したとします。その修正によって特定の問題が解決される一方で、別の応対に意図しない悪影響を与えることがあります。
例えば、「回答できる質問はまずFAQページへ誘導する」という指示を追加したところ、「FAQを見たが解決しなかったので電話した」と明示している顧客に対して、再び「こちらのFAQをご確認ください」と案内してしまう、といった具合です。1つ改善すると別の場所が意図せず変わってしまう。このイタチごっこが、チューニングコストを際限なく引き上げていきます。
加えて「モデルアップデートのリスク」もあります。特定バージョンのLLMを前提にチューニングされたプロンプトは、ChatGPTの「GPT-4o → GPT-5」のように新世代モデルへ移行した途端に期待通り動かなくなることがあります。プロンプトへの依存度が高いほど、モデルの変化に対して脆弱になります。
チューニングを「プロンプト一辺倒」に頼る設計は、運用を本格化させた瞬間に、限界を迎えます。極力プロンプトではなく構造化されたナレッジデータを軸に改善運用を進め、変更の影響範囲を可視化できる設計を最初から組み込むことが、この罠を避けるカギとなります。
第三の罠は「ナレッジデータの罠」です。
AIオペレータはナレッジを参照して回答を生成します。ここで問題となるのが、多くの企業が保有するナレッジの形式です。オペレータ向けのマニュアルやスクリプトは、「人間が読むこと」を前提に作られています。PDFに画像が混在した規定集、表組みだらけのFAQ、分岐の多いフロー図ベースのトークスクリプトは人にとっては読みやすくても、AIにとっては解釈が難しいドキュメントです。
こうした、人向けのナレッジをAIに読み込ませるには、「AI-Ready化」と呼ばれる変換作業が必要になります。ただし、この問題は変換作業だけでは終わりません。既存のナレッジは通常、FAQ向け・オペレータ向け・システム向けと、すでに複数の形式で分断して管理されていることが多いです。そこにAI向けのナレッジが加わると、管理が二重、三重、四重と膨れ上がります。
多重管理において発生する変更コストの問題は、「本末転倒」といえます。「現場を楽にするためにAI化したのに、ナレッジの更新・管理コストがむしろ増えた」という逆転現象を生み出します。例えば、商品の手数料が変更になったとき、FAQページ・オペレータ向けマニュアル・AIオペレータ用ナレッジのすべてを個別に更新しなければなりません。この運用負荷が蓄積すると、ナレッジが陳腐化し、AIオペレータの回答品質が劣化していくことになります。
この罠を乗り越えるためには、ナレッジを「一元管理・多形式出力」できる統合基盤を設計段階から考える必要があります。単一のソースから、FAQページ・オペレータ支援・AIオペレータの三者に一括配信できる構造でなければ、運用は持続しません。

3つの罠を整理すると、それぞれに共通する本質が見えてきます。顧客体験の罠は「目的の歪み」、チューニングの罠は「構造の欠如」、ナレッジデータの罠は「管理の分断」です。いずれも、PoC段階では表面化しにくく、本番拡張の段階で突然、牙を剥きます。
コンタクトセンターのAI化は不可逆の流れであり、AIオペレータはその中心的な技術になっていきます。だからこそ、デモの感動に引きずられたまま導入を進めるのではなく、これらの罠の存在を正しく理解したうえで、スケーラブルな仕組みを最初から設計することが求められます。
重要なのは、導入するだけで完結する「魔法の杖」は存在しないということです。AIオペレータのポテンシャルを引き出せるかどうかは、これらの罠を知ったうえでの運用設計にかかっています。

◇◇◇
3つの罠の中でも、とりわけ運用フェーズで影響が大きく難しいのが「ナレッジデータの罠」です。AIオペレータの回答品質は、構築時の設計より、日々のナレッジ管理の質によって決まると言っても過言ではありません。
第2回では、この「ナレッジ」を中心に、運用課題についてより具体的に掘り下げます。