コンタクトセンターの自動化：封じ込めが本当に測っているもの

AIコンタクトセンターのあらゆるプレゼン資料では、ひとつの数字がすべてを物語ります。封じ込め率（コンテインメント率）です。それを十分に高く押し上げれば、ビジネスケースはおのずと成立します。しかし、もしその数字が、あなたが思っているものを測っていないとしたら？

その効果を判断するために誰もが用いる指標は、封じ込め率です。すなわち、エスカレーションなしにAIが最初から最後まで処理したインタラクションの割合です。

ここに落とし穴があります。どのコンタクトセンターも、封じ込めをスコアボードのように報告します。X%を自動化し、残りは人間が処理する、と。しかし、ひとつの質問がログ、チケット、注文に同時に触れた瞬間、ボットはエスカレーションします。答えが、ボットには到達できないシステムの中に存在するからです。封じ込めは、あなたの自動化がどれほど優れているかを測っているのではありません。AIがあなたのデータのどれだけに到達できないかを測っているのです。

その数字を実際に動かしているのは、あなたのAIがどれほど賢いかではありません。あなたのデータのどれだけに到達できるかです。そして、その上限は、あなたのダッシュボードが示唆するよりも低いのです。

どのコンタクトセンターも信頼するスコアボード

どのコンタクトセンターのレビュー資料も、同じ数字を筆頭に掲げます。今四半期は取扱量の67%を自動化した。

経営陣はうなずきます。スライドが進みます。その67%が実際に何を表しているのかを、誰も問いません。

封じ込め率は、コンタクトセンターのパフォーマンスを表す普遍的な代理指標になりました。追跡しやすく、提示しやすく、そして直感的に感じられます。封じ込めが多いほどAIがより多くの仕事をしていることを意味し、それは人間のエージェントに費やす額が少ないことを意味する、というわけです。

しかし、業界の調査は、高い封じ込めが、必ずしも優れたAIモデルではなく、多くの場合は優れたデータアクセスと統合を反映していることを、ますます明らかにしています。

MITの調査 は、AI施策のおよそ95%が本来の潜在力に到達できていないと指摘しており、コンタクトセンターにおけるボトルネックは、たいていアルゴリズム的なものではなくアーキテクチャ的なもの（統合／データアクセス）です。チャットボットが残高を確認できなかったり、CRMの履歴を照会できなかったりするのは、コアシステムへのリアルタイムのアクセスを欠いているからです。解決率は、モデルの能力ではなくデータへのアクセス可能性によって、ユースケースごとに17%から58%まで振れます。

その役員レビューで誰も問うていない問いがあります。その封じ込め率を、正確には何が動かしているのか？優れたAIなのか、それとも優れたデータアクセスなのか？というのも、この2つはスライド資料の上では同じように感じられますが、その上限はまったく異なるからです。

価値の高いタスクの多くは完全には封じ込められていませんが、それでも自動化の恩恵を受けます。以下は、FCR、AHT、エージェントの生産性を向上させながら、封じ込められていない作業を自動化するためのパターンです。

1. 事前作業とデータ収集（引き継ぎ前に自動で完了させる）

• 何を自動化するか：本人確認、アカウントの照会、注文／請求ステータスの取得、書類の収集、同意の取得、そして過去のインタラクションの要約。
• なぜ役立つか：たとえケースがエスカレーションしても、エージェントは完全で構造化された概要を引き継ぎ、より速く解決できます。これは、完全な封じ込めを必要とせずに、AHTを直接的に削減し、FCRを向上させます。
• 実装のヒント：イベント駆動型の双方向統合（読み取り＋書き戻し）を使い、ボットがCRM／チケットのフィールドを単に読むだけでなく、リアルタイムで更新できるようにしましょう。

2. 通話中のエージェント支援とガイド付きワークフロー

• 何を自動化するか：リアルタイムのナレッジ検索、ネクストベストアクションの提案、ポリシーチェック、フォームの自動入力、そしてライブのインタラクション中のコンプライアンスのプロンプト。
• なぜ役立つか：エージェントは複雑なケースをより速く、より一貫して解決します。封じ込めは控えめなままですが、FCRとCSATは上昇します。
• 実装のヒント：問い合わせ要因の上位10件を計測し、それらのシナリオ向けのガイド付きワークフローを、エージェントのデスクトップに組み込みましょう。

3. 通話後の自動化（封じ込めが失敗したあと）

• 何を自動化するか：自動要約、自動カテゴリ分類、自動ルーティング、SLAタイマー、フォローアップのスケジューリング、そして書類の生成（メール、レター、請求フォーム）。
• なぜ役立つか：手作業のラップアップ（後処理）時間と後工程のエラーを削減します。「封じ込めたが解決していない」が業務上の足かせになるのを防ぎます。
• 実装のヒント：要約を構造化されたフィールド（課題コード、製品、結果）に紐づけて、シナリオごとの再問い合わせ率を測定できるようにしましょう。

4. 例外のためのオーケストレーションされたヒューマン・イン・ザ・ループ

• 何を自動化するか：例外の検知（例：データの欠落、ポリシーの衝突）、マイクロタスクの自動作成、そしてコンテキストを伴った、適切な専門キューへの動的なルーティング。
• なぜ役立つか：複雑なケースに完全な封じ込めは必要ありません。必要なのは、完全なコンテキストを伴った摩擦のないエスカレーションです。これは転送と再問い合わせを削減します。
• 実装のヒント：タスクボード／オートメーションセンターを使って、これらのマイクロタスクをエンドツーエンドで追跡し、完了までの時間と手戻りを測定しましょう。

5. 先回りの、イベントをトリガーとしたアウトリーチ（問い合わせを未然に防ぐ）

• 何を自動化するか：バックエンドのイベントによってトリガーされる、ステータス変更の通知、支払いのリマインダー、書類の要求、そして予約の確認。
• なぜ役立つか：インバウンドの需要を、それがボットやエージェントに届く前に取り除きます。封じ込めは動かないかもしれませんが、総取扱量と解決あたりのコストは下がります。
• 実装のヒント：CRM、請求、OMS（注文管理システム）にまたがってデータスキーマを正規化し、AIレイヤーがトリガーのための単一の信頼できる情報源を持てるようにしましょう。

要するに、封じ込めは便利な代理指標ですが、それは多くの場合、優れたAIではなく、優れたデータアクセスと統合を評価しているにすぎません。封じ込めを超えて自動化（事前作業、エージェント支援、通話後、例外のオーケストレーション、そして先回りのアウトリーチ）を行い、ケースが完全には封じ込められていないときでも、FCRと生産性を引き上げましょう。

自動化された通話が本当にエスカレーションする理由

ある顧客からの電話を思い描いてください。その人はこう言います。この前の注文は発送されたのに、追跡がぷつりと途絶えてしまって、しかも二重に請求されている気がするんです。何とかしてもらえますか？

カスタマーエージェント なら、それを90秒で解決します。配送ログを引き出し、追跡を担う配送業者からの未解決チケットを確認し、請求記録を見ます。3つの情報源、ひとつの答え、それで完了です。

あなたのコンタクトセンターのAIは、それをエスカレーションします。質問が複雑だからではありません。ボットが、その3つのシステムのうち一度にひとつしか見られないからです。答えは存在していました。ただAIが、それに到達できなかっただけなのです。

それこそが、ほとんどのコンタクトセンターが生み出しているエスカレーションです。難しい問題ではなく——難しい問題の装いをまとった、到達（リーチ）の問題なのです。

これは音声だけの別個のワークフローではありません——それは、チャットや会話型AIの全体で使われているのと同じ、コンテキストを意識した推論モデルです。

要するに：ディフレクションは、あなたのボットが何を避けたかを教えてくれます。解決は、それが何を解決したかを教えてくれます。そのうちの一方だけが知性です。

封じ込めは知性ではなく到達（リーチ）を測る

封じ込めは、あなたのAIエージェントの推論能力ではなく、あなたのシステムへの到達（リーチ）を測ります。

同じモデルで封じ込めの数字が高いということは、より多くのデータを接続したことを意味します——AIが賢くなったということではありません。

同じフロンティアモデルを、サイロ化したデータセットと、接続されたデータセットに対して走らせてみてください。モデルがパラメータひとつ変わっていないにもかかわらず、封じ込め率は、ときに劇的に動きます。その違いは知性ではありません。アクセスなのです。

ほとんどのコンタクトセンターでは、そのアクセスは、あなたの注文、チケット、ログの各システムがどれほどうまくマッピングされ、エージェントに公開されているかによって決まります。DevRevでは、その情報はComputer Memoryの中に存在します。すなわち、これらのエンティティがどう関係し、AIが何に到達できるかをマッピングするナレッジグラフです。

コンタクトセンターにとって良い封じ込め率とは？

正直な答えを言えば、数字そのものよりも、それを動かしているものの方が重要です。

あなたのFAQ記事しか見られないAIの上に築かれた65%の封じ込め率は、あなたのCRM、請求システム、未解決チケットをひとつの推論ステップで読むAIの上に築かれた65%の封じ込め率とは、まったく別物です。前者は脆く——新しい製品ラインを追加すれば、その数字は崩れ落ちます。後者は、接続されたデータに根ざしているためスケールします。

正しい問いは「私たちの封じ込め率はどれだけ高いか？」ではありません。「私たちの顧客データのどれだけに、AIは実際に到達できるか？」です。それに答えれば、封じ込め率はおのずとついてくる傾向があります。

これはただのベンダーの言い分（スピン）では？

もっともな問いです。それは検証可能です。

あなたの現在のAIの構成を取り上げてください。それを、いまは読んでいない追加のシステム——請求記録、CRM、配送ログ——のひとつに接続し、モデルをまったく変えずに封じ込め率を観察してみてください。もしそれが動いたなら、上限は知性ではなくデータだったことを、あなたはたったいま証明したことになります。

DevRevのEnterprise-Bench は、まさにこのテストを大規模に実施しました。検証したのは、UC BerkeleyのAlexandros Dimakisです。その結果は、Computerが94.3%のタスク精度であったのに対し、同じフロンティアモデルが単独で動作した場合は63.6%でした。この差は、まったくもって、接続されたデータとナレッジグラフのアーキテクチャから生じたものであり、異なるモデルやより優れたモデルから生じたものではありません。

自動化の上限を実際に引き上げるもの

AIが、配送ログ、未解決チケット、請求記録をひとつの推論ステップで読めるようになると、先ほどエスカレーションした二重請求の通話は、代わりに解決されます。それはアーキテクチャの転換です。ひとつのシステムの内側を検索するAIと、それらすべてをまたいで推論するAIとの違いです。

Computer by DevRev は、その転換をエンタープライズ規模で実用的なものにする2つのコンポーネントの上に築かれています。

• Computer Memory は、あなたの顧客、チケット、製品、注文、請求記録のあいだの関係性をマッピングする、権限を意識したナレッジグラフです。だからAIは、それらの関係性を推測するのではなく、たどっていくことができます。
• AirSync は、あなたのシステムに対してリアルタイムで読み取りと書き戻しを行うことで、そのグラフを最新に保ちます。だからエージェントは、古くなったスナップショットではなく、常にライブのデータを扱って働きます。

その結果は、単に封じ込めが高くなることではありません。その封じ込めが本物になることです。処理されたと数えられた会話が、答えのないまま閉じられたのではなく、実際に解決されているのです。

効率の面での構図も、同じくらい鮮烈です。ナレッジグラフが64倍に大きくなったとき、Computerの正答あたりのコストは11%上昇しました。グラフなしで動作する同じフロンティアモデルでは、同じワークロードに対してコストが55%上昇しました。

出典：LinkedIn

このアーキテクチャは、単に品質を向上させるだけではありません——品質を、スケール時により安価に維持できるようにするのです。

音声通話は歴史的に、攻略が最も難しいチャネルでした。時間的なプレッシャーのもとで、複数のシステムをまたいだリアルタイムの推論を必要とするからです。DevRevのVoice AIは、SIPベースの統合——Amazon Connect、Twilio、Genesysなど——を通じて既存の電話システムに接続し、チャットとメールを解決するのと同じComputerエージェントを、ライブの通話に投入します。チャネル間のコンテキストの切り替えもなければ、別々のデータアクセスを持つ別々のボットもありません。同じエージェント、同じグラフ、同じ解決能力です。

実装プレイブック：封じ込めから解決への移行

虚栄の指標（バニティメトリクス）を超えて、真の解決のためにコンタクトセンターのAIを再設計するには、プレイブックを、封じ込めから解決へという捉え直しを直接的に実務へ落とし込む3つのアクションにそぎ落としましょう。これらのステップは、あなたの上限がデータの接続性なのか、それともモデルの知性なのかを明らかにし、自律的な解決を解き放つシステムへの投資を促します。

ステップ1：エスカレーションの理由を監査する（上限を診断する）

エスカレーションを単に数えるだけにしてはいけません。それらを、具体的なアーキテクチャ上の修正を指し示す、4つの診断用のバケットに分類しましょう。

• 到達（リーチ）の失敗：AIが必要なシステム（請求、配送、CRM、注文管理）にアクセスできなかった。
• インテント（意図）のギャップ：AIが顧客のリクエストを認識できなかった、あるいは正しく分類できなかった。
• ワークフローの摩擦：UX、レイテンシ、あるいはマルチターンの複雑さのために、顧客がプロセスの途中で離脱した。
• 信頼のギャップ：顧客がAIの答えを信じず、明示的に人間を要求した。

この診断は、どこに投資すべきかを教えてくれます。データの接続性（到達）、NLP／インテントのモデル（意図）、会話設計（摩擦）、あるいはエスカレーションのフローと信頼のシグナル（信頼）です。もしエスカレーションの大半が到達の失敗であれば、あなたは自分の制約を見つけたことになります。どれだけプロンプトをチューニングしても、欠けているAPIは直せません。

ステップ2：データの依存関係をマッピングする（接続性のロードマップを作る）

顧客のインテントを取扱量の多い順に上位10件挙げましょう。各インテントについて、次を文書化します。

• 読み取るべきシステム：CRM、請求、注文管理、配送、チケット、ナレッジベース。
• 書き込むべきシステム：ケースの作成、返金の開始、住所の更新、支払いプランの交渉。
• レイテンシの要件：リアルタイム（注文ステータス）か、バッチ（レポーティング、アナリティクス）か。

これがあなたのデータ接続性のロードマップになります。追加のシステムひとつで解決が解き放たれるインテントを優先しましょう。たとえば、配送業者のAPIを接続して、人間への引き継ぎなしに「私の注文はどこ？」を解決する、といった具合です。DevRevのComputer Memory のアーキテクチャは、この原則の上に築かれています。すなわち、CRMの記録、チケット、注文、業務アプリケーションを、AIがすぐ使える単一の信頼できる情報源へと統合する、永続的で、権限を意識したナレッジグラフです。

ステップ3：管理された接続性テストを実施する（制約を証明する）

取扱量の多いインテントをひとつ選びます（例：注文ステータス、請求に関する問い合わせ、パスワードのリセット）。AIを、いまは読んでいない追加のシステムのひとつ（例：配送業者のAPI、請求台帳、IDプロバイダー）に接続します。

前後で測定します。

• 封じ込め率：チャネル内にとどまった会話の割合。
• 解決率：顧客が自分の問題は解決したと確認した、AIとのインタラクションの割合。
• 再問い合わせ率：「封じ込められた」顧客のうち、同じ課題で24〜72時間以内に戻ってくる割合。

モデルを変えずに封じ込めと解決が上昇したなら、上限は知性ではなくデータだったことを証明したことになります。これは、予算をプロンプトエンジニアリングからシステム統合——自律的な解決のための実際のレバー——へと移すための、最も速い方法です。

虚栄の指標を最適化するのをやめよう

あなたのデータアーキテクチャを修正することの見返りは、より大きな封じ込めの数字ではありません。あなたのコンタクトセンターが、まったく間違ったものを最適化するのをやめることです。

エスカレーションが減ります。ボットのしきい値をより強く絞り込んだからではなく、手の届かないところにある答えが減ったからです。担当者（レップ）は、接続されたAIなら90秒で解決できたであろう通話ではなく、本当に複雑で、本当に人間を要する通話を扱います。一度電話をかけて、二度とかけ直さない顧客が生まれます。

2025年のGartnerのレポート は、エージェント型AIが2029年までに、一般的なカスタマーサービスの課題の80%を自律的に解決し、運用コストを30%削減すると予測しています。そこに到達する企業は、封じ込めのベンチマークを追いかけることでそれを成し遂げるのではありません。AIが自社のデータのより多くに到達できるようにすることで、成し遂げるのです。

あなたの封じ込め率は、あなたのAIがどれほど賢いかを語っているのではありません。あなたのデータのどれだけに、それが到達できないかを語っているのです。