AI対応のコンタクトセンターソリューションプロバイダーであるNovelVoxのCEO、Amit Gandhiは、組織が完璧な顧客体験を提供できるよう支援している。
コンタクトセンター向けに統合インフラを構築して16年。企業が同じ高額な過ちを繰り返すのを見てきた。高度なAIを購入し、華々しく導入したかと思えば、本番環境で静かに失敗していくのである。
こうしたケースで問題なのは、たいていAIではない。AIに見えていないものが問題なのだ。
AIに死角があるとき
2025年6月のMITのレポートは、AIプロジェクトの最大95%が失敗したと結論づけた。AIによるカスタマーサービスに投じた1ドルあたり平均3.50ドルのリターンを企業が得ているにもかかわらず、コンタクトセンターのAI導入の多くは、その潜在力に到達しない。
私の経験では、理由はアルゴリズムというよりアーキテクチャにあることが多い。チャットボットが口座残高を確認できないのは、基幹の銀行プラットフォームにアクセスできないからだ。バーチャルエージェントが顧客を有人オペレーターに転送するのは、顧客のCRM履歴が見えないからである。AIが顧客コンテキストの30%に基づいて解決策を勧めるのは、残り70%がAIと接続されなかったシステム内にあるからだ。
企業のデータ責任者を対象にした最近の調査によれば、「回答者の82%が、自社データの40%超が50以上の異なるアプリケーションに由来している」と報告している。コンタクトセンターも同様の形で運用されがちである。顧客データがCRM、基幹システム、音声基盤、チケッティングツールに散在し、リアルタイムでは連携していない。こうした断片化した環境にAIを投入すると、知性を引き出すよりも、無知を自動化する可能性が高まる。
統合なきAIがもたらす課題
顧客がAI搭載チャットボットに問い合わせた際、よく起きるのは次のようなことだ。
顧客：「請求先住所を更新したいのと、直近の支払いが反映されたか確認したいのですが」
AIが把握していること：CRM上に、その顧客の電話番号とメールアドレスが登録されている。
AIがアクセスできないもの：現在の口座残高。直近の取引履歴。未処理の支払い。登録されている請求先住所。支払いが実際に決済されたかどうか。
次に起きること：「喜んでお手伝いします。お客様のアカウントにアクセスできる担当者へおつなぎします」
企業はおそらく、処理時間の短縮とセルフサービス完結率の向上を狙ってAIに投資したのだろう。しかし実際には、回避したかった同じオペレーターへ顧客を誘導する、洗練された挨拶システムをつくっただけになってしまっている。
多額の投資にもかかわらず、AIの統合に成功したコールセンターは25%にとどまる。チャットボット利用者の解決率は大きくばらつき、請求に関する問題では17%から、返品やキャンセルでは58%まで幅がある。私が見てきたところ、このばらつきはAIの能力の問題ではなく、データへのアクセスの問題である。不運な皮肉だが、企業は取引を自動化するためにAIを購入する一方で、そのAIは自ら完了できない取引についての質問に答えることしかできないのだ。
コンタクトセンターAIを機能させる方法
研究によれば、AI導入の失敗の70〜85%は、貧弱なデータ基盤に起因するという。基盤とはAIモデルではない。AIが機能するために必要な統合インフラである。これを踏まえ、コンタクトセンターがAIの土台を固めるために取り得るステップをいくつか挙げたい。
1. ポーリングからイベント駆動の接続へ移行する。多くの統合は「ポーリング」——一定間隔でデータ更新を確認する方式——に依存している。これが遅延を生み、AIの滑らかさを損ないかねない。これを避けるには、リアルタイムのイベント駆動トリガーを支えるインフラを整えることだ。たとえば、顧客が電子カルテ（EMR）や基幹システム上でステータスを変更したとき、そのデータは「同期」遅延なしに、直ちにAIレイヤーから利用可能であるべきだ。
2. 双方向の「書き戻し（write-back）」機能を実装する。読み取り専用の統合は、読み取り専用のAIしか生まない。本当の自動化には、AIがデータを取得するだけでなく、記録を更新できることが必要だ。AIがERPで配送先住所を更新できない、あるいはCRMで予約を入れられないのなら、チケットを解決できない。統合レイヤーが双方向のデータフローに必要なセキュリティのハンドシェイクを処理できるようにしておくことが重要である。
3. スタック全体でデータスキーマを標準化する。請求システムでは「Account_Num」、CRMでは「Cust_ID」といった具合に、名称が不一致だとAIモデルは苦戦する。データがAIに届く前に、正規化レイヤーが必要だ。統合インフラ内でスキーマを標準化することで、AIが「単一の信頼できる情報源」を受け取れるようになり、データ形式の衝突によるハルシネーションを減らせる。
4. プロトコルの仲介（レガシーからクラウド）を解決する。現代のAIはRESTやJSONを話す。一方で、多くの企業の基幹システム——とりわけ銀行や医療——はSOAP、COBOL、独自SQLを話す。私の経験では、失敗点はたいてい翻訳にある。これを克服するには、このプロトコル仲介をネイティブに処理できる専用インフラレイヤーを追加し、クラウドネイティブなAIとオンプレミスのレガシーシステムの間の翻訳者として機能させることだ。（情報開示：私の会社も、他社と同様にこれらのサービスを提供している。）
行動できるAIをつくる
AI投資が、期待した完結率、平均処理時間（AHT）の削減、運用効率をもたらしていないのだとすれば、問題はAIではない可能性が高い。AIが機能するために必要なデータやシステムへのアクセスを可能にするインフラ、あるいはその欠如にある。モデル、ベンダー、ユースケースを責める前に、もっとシンプルな問いを立てたい。自社のAIは、顧客の要望を解決するために必要なシステムへ実際にアクセスできているのか。答えがノーなら、AIの問題ではない。統合の問題である。そして、統合の問題には解決策がある。
