なぜあなたのAIは間違っていても教えてくれないのか、そしてどう対処すべきか

先週、ライブベンチマーキング配信中に、予想外のことが起きました。

Claude – MCP経由でライブのJiraとSalesforceインスタンスに接続された状態 – に、現実的なエンタープライズクエリを尋ねました：

「優先度の高いオープンのエンジニアリング課題をすべて見つけ、それらの製品領域でオープンなサポートチケットを持つ顧客アカウントを特定し、詳細な内訳を出してください。」

Claudeは約6分間考えました。そして自信に満ちた、きれいにフォーマットされた回答をくれました。課題ID、アカウント名、チケット数付きで。

1つ問題がありました：JiraのMCP認証が夜間に静かにタイムアウトしていたのです。

Claudeはエンジニアリング課題にまったくアクセスできていませんでした。それを一切教えてくれませんでした。ただ先に進み、Salesforceから取得できるものを引き出し、残りを推測し、権威ある見た目の回答を返しました。どうやってその答えに至ったか尋ねると、問い詰められて初めて – 実際にはJiraにクエリを一度も実行していなかったことを認めました。

自信に満ちた回答。間違ったデータ。警告なし。

その瞬間は、エンタープライズAIが今どこにいるかについて重要なことを捉えています。

ベンチマーク

DevRev ComputerとClaude Codeの構造化比較を実施してきました。同じモデル（Sonnet 4.6）を使い、同じデータセット – 33件のエンジニアリング課題、124件のサポートチケット、37の製品領域、39のアカウント – に対して。

このクエリは、サポート担当VPやCTOが月曜日の朝に尋ねるような種類のものです：オープンの高優先度課題を、影響を受ける顧客アカウントとクロスリファレンスする。複雑な分析タスクではありません。ただ2つのシステム間のジョインです。

複数回の実行で観察されたことは以下の通りです：

同じモデル。同じクエリ。同じデータ。変数はコンテキストがモデルにどう届けられるかでした。

Claudeが実際に行うこと

MCPが正しく動作している場合でも、Claudeは回答する前に根本的な問題に直面します：スキーマを知らないのです。

Jiraが「高優先度」を何と呼ぶか知りません（High？Highest？Critical？P0？P1？）。どのカスタムフィールドが課題を製品領域にリンクするか知りません。Salesforceがアカウントレコードをどう構造化しているか知りません。

だから探索します。サンプル課題をフェッチしてフィールドを調べます。JQLクエリを試し、結果を見て、改良します。Salesforceオブジェクトを引き出して正しいフィールド名を見つけます。複数ページの結果をページネートするかもしれません – またはコンテキストウィンドウが埋まり始めると早期に停止するかもしれません。

これらの探索コールはそれぞれ大きなペイロードを返します。そのデータのほとんどは最終回答に現れません – AIがどこを見ればいいか把握するためだけのものでした。

最悪のケースでは、この探索で600万トークンを消費し、コストは$4.28 – 33件の課題のデータセットに対する、たった1回のクエリで。返された回答はそれでも完全に信頼できるものではありませんでした。

そしてより深い問題がここにあります：Claudeはこのスキーマ探索コストを毎セッション支払います。データモデルの永続的なメモリがないのです。明日の朝、またゼロからやり直しです。

なぜ非決定性が重要か

テスト実行を通じて、Claudeは同じ答えに対して異なるパスを取りました。Jiraを先に呼ぶこともあれば、Salesforceを先に呼ぶこともあります。JQLを使うこともあれば、個別レコードをフェッチすることもあります。出力は概ね似ていましたが – 「概ね似ている」は最高優先度の顧客と最も重要なエンジニアリング課題に関する判断で求める基準ではありません。精度が不可欠です。

SQLでは、同じソースオブトゥルースから、同じクエリを通じて、毎回同じ答えが得られます。そのクエリを検査できます。共有できます。ダッシュボードを構築できます。

Computerにどうやってその答えに至ったか尋ねました。SQLを見せてくれました – クリーンなジョイン、フィルター、ソートのセットです。再現可能で監査可能。

Claudeにどうやってその答えに至ったか尋ねました。探索の旅を説明してくれました – そして失敗した実行では、その旅が必要なデータの核心部分を静かに除外していました。

アーキテクチャのギャップ

これはClaudeやMCPへの批判ではありません。どちらも本当に素晴らしいものです。問題は構造的なものです。

汎用AIツールは検索と推論のために構築されています。記憶するようには構築されていません。すべてのクエリがゼロから始まります。すべてのセッションでスキーマ探索税を支払います。すべての回答は、モデルが時間やトークンが尽きる前にコンテキストウィンドウに引き込めたものだけに依存します。

DevRev Computerは異なる設計です。質問が尋ねられる前にスキーマが既知です。エンジニアリング課題、製品領域、サポートチケット、顧客アカウント間の関係は型付けされ、事前マッピングされ、継続的にメンテナンスされています。「この課題に影響を受ける顧客は？」と尋ねると、Computerは探索しません – トラバースします。ジョインキーはナレッジグラフのファーストクラスエンティティです。

トークンコストは回答のサイズに比例してスケールし、データのサイズには比例しません。だから小さなデータセットで95%少ないトークンが観察され – データが大きくなるほどそのギャップは広がります。企業がAIをより広く活用し続ける中、効率性はますます重要な関心事です。

サイレント障害の問題

配信中のライブ障害は単に恥ずかしいだけではありませんでした。エンタープライズスケールでのMCPベースアーキテクチャについて、重要なことを示しました。

接続を管理しています。各MCPサーバーは静かに障害を起こしたり、期限切れになったり、認証を失ったりする可能性があります。AIはデータが欠落していることを知らないかもしれません。教えてくれないかもしれません。手持ちのもので最善を尽くし、自信たっぷりに聞こえる回答を単に返すだけです。

エンタープライズスケールでは – 5、10、15の統合があるかもしれない場所で – これは深刻なガバナンス問題になります。AIがその推奨を行った際に、正しいデータにアクセスできていたことを保証する責任は誰にあるのでしょうか？

ナレッジグラフアーキテクチャでは、データは管理された同期パイプラインを通じて取り込まれ、最新に保たれます。同期が失敗した場合、それがわかります。回答が静かに劣化することはありません。

実際にはどういう意味か

95%のトークン削減と5.5倍の速度向上は実際の意味があります – 特に数百人の従業員が1日に数十のクエリを実行する中でトークンコストが蓄積される場合。しかし、より重要な数字は測定が難しいものです：あなたのAIが正しいデータに到達できなかったために、自信に満ちた間違った回答をどれくらいの頻度で返しているか？これらの回答に基づくアクションと意思決定の信頼性と安全性が、AIプロジェクトの成否を決定します。

MCPは有用なプロトコルです。しかし、ツールをAIに接続することはメモリを与えることではありません。リーチを与えるのです – そしてメモリなきリーチは、$4.28の回答や、AIが実際にはアクセスしなかったデータに基づく回答に行き着く方法です。

プロンプトキャッシングが解決策として手を挙げる人がいるでしょう。しかし、それでは問題は解決しません。今後の投稿でこれについて詳しく説明します。