
AIエージェントが「正しく計算して間違える」理由
朝の出汁版(通勤2分)
- ポイント1: AIエージェントがツールで正しい答えを出しても、長い出力を検索経由で読み返す際に「別の根拠」に切り替わり、誤答することが実験で確認された。
- ポイント2: GPT系モデルは検索読み込み時に精度が最大11点落ちる一方、Claudeは同条件でも低下がなく、モデルによって「証拠の使い方」に大きな差がある。
- ポイント3: エージェント設計でツール出力を参照させるときは、どのファイル・どのセクションが正解の根拠かを明示的に指定するだけで精度が6〜8点改善するため、プロンプトで「参照先の名前を書く」を試してみる価値がある。
出汁の素(深読みモード)
正しく計算したのに、なぜ間違えるのか
AIエージェントに「ツールで計算させる」設計は今や当たり前になりつつある。データ分析も、シミュレーションも、外部APIの呼び出しも、エージェントがツールを叩いて結果を得る。問題は、その後の「読み方」にある。
今回の研究で使われたのはUSGS(米国地質調査所)が公開している地球化学シミュレーターPHREEQC。1回の実行で最大84万字以上のレポートを吐き出すツールだ。エージェントはこのレポートを使って選択問題に答えるよう設計された。
現実的なエージェント設計では、こうした巨大な出力をそのままコンテキストウィンドウに詰め込むことは難しいため、ファイルに保存して「必要なときに検索して読む」方式が取られる。研究ではこの方式と、レポートをそのまま渡す方式を比較した。
結果は明確だった。シミュレーターが正しい値を計算できているにもかかわらず、検索経由で読み返したGPT系モデルの精度が最大11点低下した。注目すべきは「計算が間違ったのではなく、読み方が変わった」という点。研究チームはこれを「証拠の差し替え(evidence substitution)」と命名している。
GPTとClaudeで何が違ったのか
同じ条件の下で、モデルによって挙動に大きな差が出た点は見逃せない。
GPT-5.1とGPT-5.2は、検索経由でレポートを読む条件下で精度がそれぞれ11.3点、7.9点低下した。具体的に何が起きているかを分析すると、シミュレーターのレポートではなく、自分が持っている別の出力ファイル(エージェント自身が生成した中間ファイルなど)を根拠に回答を選ぶようになっていた。しかも選択肢の丸め方がずれて、隣の選択肢を選んでしまう「丸め誤差」まで発生していた。
一方、Claude Opus 4.6とClaude Sonnet 4.6では同条件での精度低下がほぼ検出されなかった。同じレポート・同じ検索方式でも、どの情報を根拠に使うかの「判断の仕方」がモデルによって根本的に異なるということだ。
これは「どちらのモデルが優秀か」という話だけではない。エージェント設計において「モデルを選ぶ」ことが、精度の浮き沈みに直結するという現実の話だ。temperature 0でもAIの回答はブレるという記事で触れた「設定を変えていないのに回答が変わる」問題と同じ構造がここにも潜んでいる。ツール出力の読み方という、普段は見えにくいレイヤーで、モデルの個性が影響を与えている。
「参照先を明示する」だけで精度が6〜8点上がった
研究の中で最も実用的な発見がここだ。複雑なアーキテクチャの変更なしに、プロンプトの書き方だけで精度を改善できた。
具体的には、エージェントへの指示に「正解の根拠が含まれるファイル名やセクション名を明示する」という一言を加えるだけ。これで検索経由の精度ロスが6.3〜7.9点回復した。
「どのファイルのどのセクションを見ろ」と伝えることで、エージェントが別の情報源に勝手に乗り換える「証拠の差し替え」を防げる。日本語に直すと、「この問いの答えは、simulation_output.txtの『Result Summary』セクションにあります。そちらを参照して答えてください」といった形だ。
一見地味に見えるが、エージェントにツールを使わせているとき、多くの場合プロンプトでは「ツールを使え」とだけ書いて、読み返す先は指定していない。その空白をエージェントが独自に埋めようとした結果、別の根拠にすり替わる。
これはマルチAIエージェント時代、コスト管理が鍵になるでも整理されているように、エージェントの「判断の余白」をどこに残すかという設計の問題でもある。余白を意図的に絞ることで、精度が安定する。
自分のエージェント設計で今すぐ確認すること
この研究の知見は、地球化学シミュレーターという専門ツールの話だが、構造は汎用的だ。以下に当てはまる設計を使っているなら、今すぐ見直す価値がある。
確認ポイント:
① ツール出力をファイルに保存して、後から検索・読み込みさせている設計がある場合。ここが「証拠の差し替え」の温床になる。
② プロンプトに「このツールを使って答えろ」とは書いているが、「どのファイルの・どのセクションを読め」は書いていない場合。
今すぐ試せる改善:
- ツール呼び出し後のプロンプトに「この回答の根拠は[ファイル名]の[セクション名]にあります。必ずそこを参照してから選択してください」を追加する。
- GPT系モデルを使っているなら、Claude系と比較テストを走らせて同じ条件での精度差を自分で確認する。モデルを変えるだけで改善できる可能性がある。
- 出力が長大なツール(PDFパーサー、データ分析ツール、API返却など)ほど、この問題が起きやすい。出力サイズと精度の相関を一度確認しておく。
「正しく計算させているから大丈夫」ではなく「正しく読ませているか」まで設計の射程に入れることが、エージェント精度を底上げする最短ルートになる。
エージェント設計に本格的に踏み込むなら
研究の元論文(arxiv.org/abs/2610.26836)では、11,007回分のシミュレーター実行ログが記録・分析されており、どの段階でエラーが発生したかをトレース可能な形で公開している。GPTとClaudeの挙動差異を自分の設計に照らし合わせたい場合、ログの分析手法が参考になる。
また、今回の「証拠の差し替え」問題は、RAGやLong Context設計と切っても切り離せない。LatComm(arxiv.org/abs/2610.26840)という手法では、複数LLM間でコンテキストを圧縮して受け渡す際に「受け取る側がプロンプトに応じて読む部分を選べる」設計を採用している。複数モデルを組み合わせたエージェントシステムを構築している場合、コンテキストの受け渡し設計の参考になる研究だ。
参照ソース
- [ArXiv]Kronecker Delta Rule for Long Context Linear Attention→ arxiv.org/abs/2610.26834v1
- [ArXiv]Same Simulation, Different Evidence: Where Retrieved Tool Output Costs LLM Agents Accuracy→ arxiv.org/abs/2610.26836v1
- [ArXiv]LatComm: Reusable Context Compression for Latent Communication between Large Language Models→ arxiv.org/abs/2610.26840v1
