AIによるパイロット支援が、能力ではなく信頼の問題で停滞している理由

はじめに

カスタマーサポート向けにAIを試験導入している企業の多くは、同じ壁にぶつかります。システムは数週間は問題なく動作します。しかし、ある顧客に対して、自信満々でありながら完全に間違った回答をしてしまうのです。返金期限に関するものかもしれませんし、前四半期に変更されたポリシーに関するものかもしれません。上層部がこれに気づくと、待ち行列の大部分をカバーするはずだった導入は、そのほんの一部でひっそりと凍結されてしまいます。

業界データも、このパターンがいかに一般的であるかを裏付けています。OpenText、Capgemini、Sogetiによる『2025年ワールド・クオリティ・レポート』によると、調査対象企業の60％において、信頼性や「幻覚」に関する懸念がAI導入の最大の障壁となっていることが判明しました。Gongによる別の調査では、58％の企業がAIプロジェクトを停滞させており、計画されていたAI投資のほぼ半数が、予算ではなく信頼性の懸念によって差し止められていたことが明らかになりました。 ツール自体の能力には問題がない。遅れをとっているのは、それらに対する信頼感だ。

たった一つの誤った回答の背後にある数学

サポート業務は、平均精度を指標として評価すると不利益を被るような非対称性を持っています。正解は数分の時間を節約するだけです。しかし、誤答は、本来行われるべきではなかった返金を承認したり、存在しないポリシーをでっち上げたり、誰も承認していない約束をしてしまったりする可能性があります。たった1つのミスのマイナス面が、100回の正解によるプラス面を上回る場合、平均的なケースを最適化することは、根本的に間違った目標となります。

さらに、目立たないコストも存在します。AIの誤りを一度でも発見したサポートリーダーは、それ以降、すべてを二重に確認するようになり、本来節約されるはずだった時間のほとんどが失われてしまいます。信頼は会話ごとに評価されるものではありません。信頼は積み重なるか、あるいは崩壊するかであり、一度崩壊してしまうと、たとえシステムがほとんどのケースで正しい回答を出していたとしても、チームはシステムを信頼しなくなってしまうのです。

「幻覚」は消えるものではなく、管理されるもの

最も強力な言語モデルでさえ、適切な条件下では虚偽の情報を生成し、その実態は多くの人が想定しているよりも深刻です。自社のヘルプドキュメントに基づいて回答するタスクと本質的に同じである「グラウンデッド要約」において、Vectaraの「幻覚」リーダーボードによると、最良のモデルでも約3％の誤り率を示しており、よく知られた主要モデルは6％から15％の間に集中しています。 推論を多用する一部のモデルは、同じタスクで20％を超えることもあります。これは、より深い推論を行うほど、原文には存在しない主張を盛り込む余地が増えるためです。モデルを、根拠となるものが何もない自由回答形式の質問にさらすと、その数値はさらに悪化します。スタンフォード大学の研究者たちは、参考資料が提供されていない場合、主要なモデルが特定の法的質問の大部分で幻覚を起こしていることを発見しました。

これらはいずれも、特定のモデルが「悪い」という意味ではありません。つまり、単体のモデルだけでは、監視する仕組みなしに有料顧客の前に置くほど信頼性が高くないということです。

知能と制御は相反する方向へ引っ張る

単一のモデルだけではこの問題を解決できないのには、構造的な理由があります。システムが曖昧なケースや見慣れないケースへの対応能力を高めるにつれて、その挙動を完全に予測することも難しくなります。なぜなら、誰も想定していなかったケースに対処できるのと同じ推論が、時折、システムを本来あるべきではない場所へと導いてしまうからです。 より高性能なモデルが、自動的により安全なモデルになるとは限りません。このトレードオフこそが、信頼性をモデル単体から期待するのではなく、モデルを包み込むレイヤーとして設計しなければならない理由です。

Aissistは、単一の手法ではなく、4つの階層化された手法を用いてこの課題に取り組んでいます。プロンプトエンジニアリングは、すべてのタスクが従う基本ルールを設定します。これは、単一の顧客リクエストが十数ものサブタスクに展開され、それらすべてが同じガードレールを遵守する必要があるエージェント型システムにおいて、特に重要です。 ブースターステップでは、不確実な決定を複数回実行し、追加の計算コストを犠牲にして、ほとんどのエージェントが合意した回答を採用します。自己検査パスでは、顧客に何かが届く前に、システムが自身の出力を再検証するか、異なる役割を担う第2のモデルにその出力を渡します。そして、これらすべての上に積み重ねられたガバナンス層が位置し、出力やアクションが外部に出る前にポリシーに合致しているかを確認します。これはフィルターというよりは、システム全体の監督者としての役割を果たしています。

この組み合わせによって、同プラットフォームはAIのエラー率を1%未満に抑えています。この数値が注目に値するのは、主にこの分野のベンダーのうち、エラー率を公表している企業が極めて少ないためです。

「答えないべき時」の判断

サポートエージェントにとって最も価値のある行動は、より多くの質問に正しく答えることではありません。それは、どの質問に単独で答えようとすべきでないかを認識することです。複雑な請求に関する紛争を、完全な文脈情報を添えて早期にエスカレーションするシステムは、無理に推測して進めてしまうシステムよりも、はるかに損害を少なく抑えることができます。これはまた、解決策を説明するだけのエージェントと、実際に注文情報を呼び出し、変更を加え、顧客に確認を返すといった操作を行うエージェントとの違いでもあります。

信頼性は「構築」するだけでなく「維持」しなければならない

リリース当日に正確だったシステムも、監視する仕組みがなければその状態を維持することはできません。製品は変化し、ポリシーは更新され、それに伴って顧客からの質問の内容も変化していきます。継続的な測定を行うことで、その変化を苦情の波としてではなくデータとして捉えることができます。そして、規律ある評価・テスト・リリースサイクルによって、発見されたギャップを継続的に埋めていきます。実際の変更が行われる前には、依然として人間が最終承認を行う必要があります。

ベンダーを信頼する前に実際に確認すべきこと

自社のAIが決して間違いを犯さないと主張するベンダーは、疑ってかかるべきです。なぜなら、それは通常、その事実を確認できるほど綿密に測定している者がいないことを意味するからです。真剣に検討する価値のあるベンダーは、エラー率を公表し、顧客が気付く前にどのように間違いを捕捉しているかを正確に説明し、システムが推測するのではなく人間に引き継ぐタイミングについて率直に伝えています。これは「AIを信頼してください」という売り込みとは大きく異なり、実際のチケット処理量が殺到した際にも実際に機能するアプローチなのです。