AIエージェント失敗の真因とは、モデル性能ではなく「エージェントが見ている情報」の欠陥である。
プロンプトを書き直す。モデルをアップグレードする。指示を追加する。それでもエージェントは間違える。ステージングでは完璧に動いていたのに、本番に出した途端に妙な回答を返し始めた。しかも自信満々に。そんな経験、心当たりがありませんか。
ある開発者は3年間、プロダクション環境のAIエージェントを作り続けてきました。デモ用ではなく、実際にトランザクションを処理し、外部APIを叩き、日曜の深夜2時に壊れるタイプのエージェントです。数百件の失敗トレースをスプレッドシートに記録し続けた結果、失敗の居場所はほとんどの開発者が疑う場所にはなかった、という結論に辿り着いた。その分析が本記事のベースになっています。
・AIエージェント失敗のうちモデル自体の論理エラーはおよそ12%にすぎない
・失敗の最大要因は「Perception層」（約38%）=エージェントが意思決定時に参照できる情報の欠陥
・Context Stack 5層で失敗を分類すれば、モデル変更前に打つべき手が見える
AIエージェント失敗の真因は「モデル」ではない
最初に、業界に広がっている思い込みから崩しておきます。GPT-5が出れば解決する、Claudeの次世代が出れば解決する、Geminiのフラッグシップなら大丈夫——この「次のモデル待ち」という心理が、実は改善サイクルを止めている張本人。
ベース記事の著者が数百件のトレースを読み込んで出した結論はシンプルでした。モデルは、与えられた情報の範囲ではほとんど合理的な判断をしている。問題は、与えられた情報の中身のほう。
モデルの論理エラーは全体の12%にすぎない
著者が集計したトレースでは、純粋にモデル側の推論ミス（与えられた情報で正しく考えられなかったケース）は約12%。残りの約88%は、意思決定の前段階にある情報設計の問題です。
この12%という数字は直感に反するかもしれません。現場ではどうしても「出力が間違った=モデルが悪い」と判断しがち。けれど、同じ失敗ログを「エージェントが意思決定の瞬間に何を見ていたか」という視点で読み直すと景色が変わります。見ていた情報が古かった、見るべき情報が欠けていた、関係ない情報が混ざっていた——こうしたケースが圧倒的多数を占めていた。
「次のモデルが解決する」という現場の口癖
現場の失敗対応パターンは驚くほど画一的です。本番でエージェントが誤回答を出す。チームの最初の一手はモデル変更。次にプロンプト書き換え。さらに指示を追加して「必ずデータベースを確認してから回答せよ」「絶対に推測で答えるな」と書き込む。
2週間後、同じ失敗が違う言葉で再発する。これが繰り返される理由は単純で、対症療法が当たっているのが失敗原因の12%だけだから。残り88%は情報フローの設計問題なので、モデルを入れ替えても指示を盛っても解決しません。
プロンプトに「ALWAYS check the database」と書けばチェックしてくれると期待するのは、そもそも「データベースに何をどう問い合わせるか」という情報フローが設計されていない状態では意味を持たない。この線引きを理解することが、改善の出発点になります。
失敗トレース分析で見えた「Context Stack」5層
ベース記事では、エージェントの処理を5層に分解する「Context Stack」というフレームが提示されています。失敗原因を層ごとに仕分けると、どこに手を入れるべきかが一瞬で見えるようになる診断フレーム。
5層の役割と失敗の責任範囲
5層は次のように整理されます。
- Perception（知覚）
- エージェントが意思決定の瞬間に参照できる情報の中身
- Retrieval（取得）
- 必要な情報をどのタイミング・鮮度で取ってくるかの仕組み
- Reasoning（推論）
- 与えられた情報からモデルが結論を導く処理（=モデル性能の領域）
- Boundaries（境界）
- エージェントに許された権限・責任範囲の設計
- Action（行動）
- 外部システムへの書き込み・APIコール・出力の実行
ポイントは、Reasoning以外の4層はモデル変更では改善しないこと。プロンプトも及びません。設計の話だからです。
各層の失敗比率（Perception 38%が最大）
著者が分類した失敗比率ではPerception層が約38%で最大。これは意思決定時に「見えるべきものが見えていない」「見えてはいけないものが見えている」類の失敗。Retrieval層の不具合やBoundaries層の設計ミスも積み上げると相当な比率になり、Reasoning=モデル責任はおよそ12%に落ち着く。
モデル側で解ける失敗と解けない失敗の線引き
モデル変更で改善が期待できるのはReasoning層の失敗のみ。具体的には、情報は十分揃っているのに論理を踏み外した、数学的な計算を誤った、複雑な条件分岐を追い切れなかった、といった類のケース。
一方、必要なデータが取得できていなかった、古いキャッシュを参照していた、権限外の操作を試みた、といった失敗はどれだけモデルを上げても再発します。ここを混同したまま改善を進めると、コスト増と工数浪費だけが残ることに。
最大のボトルネック「Perception層」で起きていること
Perception層がなぜ最大の失敗源になるのか。答えは、この層が「エージェントが世界をどう見ているか」を規定する層だからです。
エージェントが「見えていない」情報の典型パターン
よくある典型例を挙げます。ユーザーが「先週のオーダーをキャンセルしたい」と言った場合、エージェントは顧客IDからオーダー履歴を引けるはず。ところがRAGで渡されるコンテキストに直近7日分しか含まれていなかったら、該当データは「存在しない」と判断される。モデルは誠実に「該当のオーダーは見つかりませんでした」と答え、しかし実際にはデータはあった。
他にも、最新の在庫情報ではなく日次バッチの前日データを見ていた、会話履歴の中の重要な前提条件が要約で抜け落ちていた、複数テーブルの結合が必要なのに片方しか取得していなかった、などが頻出パターン。
こうした失敗はプロンプトを磨いても直りません。見ていない情報は、どんな指示でも見えるようにならないから。
自信満々の誤回答が生まれるメカニズム
LLMはハルシネーションを起こすときに「自信なさげ」にはなりません。与えられたコンテキストの中で最も尤もらしい答えを自信満々に出す。Perception層が欠陥を抱えていると、モデルは「欠けたデータ」を参照することなく、手元の不完全な情報から最適解を作ろうとします。結果として、サポート担当者がそのまま顧客に転送してしまうほど自然な誤回答が生まれる。
これは性格の問題ではなく構造の問題。LLMの自信度は回答の事実性ではなく、文脈内での尤もらしさに依存しているから、Perception層が汚染されていれば「自信満々の誤答」は必然的に出力されます。
①意思決定の瞬間、エージェントは最新データを見ていたか？
②必要な関連情報は全て揃っていたか（欠落がないか）？
③ノイズとなる無関係な情報が混入していないか？
対症療法から「情報フロー設計」へ
ここからは対処法の話です。Context Stackのうち、プロンプト改善では届かないRetrieval層とBoundaries層に手を入れる視点を紹介します。
Retrieval:取得タイミングと鮮度の設計
Retrievalの設計で崩しがちな前提が、「起動時にまとめて取得して、あとはコンテキストに乗せておけばよい」という発想。これが通用するのは静的な知識ベースだけで、リアルタイムに更新されるデータ（在庫、口座残高、シフト情報、会話の新しい前提）ではほぼ必ず破綻します。
取得タイミングは「意思決定の直前」が原則。ユーザーが何かを聞いた瞬間、あるいはエージェントが行動を起こす直前に、必要なデータを取り直す設計に切り替える必要があります。
鮮度の設計も同じ重要度。キャッシュのTTLをデータ特性に合わせて分けていますか？在庫データと商品説明文を同じキャッシュ戦略で扱っていたら、片方は常に古い情報を掴み続けている可能性が高い。
Boundaries:権限と責任を分ける設計
もう一つ重要なのがBoundaries層。エージェントに何を許し、何を許さないかを明示的に設計する層です。
参考になる発想として、自律エージェントに金銭的な処理を任せる実験では「権限分離型アーキテクチャ」が採用されています。個々のエージェントが直接支出を実行するのではなく、専用の「承認エージェント」が別ネットワークで動作し、すべての支出要求をルールに基づいて評価する構造。外部からアクセスできない内部チャネルでのみエージェント間通信を行うことで、誤動作が起きてもダメージが局所化される設計。
このアイデアは金銭処理だけの話ではありません。データベース書き込み、外部API呼び出し、顧客への通知送信——副作用を伴う操作は、必ず別レイヤーでの承認を通す設計にしておくと、Perception層のバグが即座にビジネス損害に転化するのを防げます。
開発アプローチを切り替えるチェックリスト
最後に、明日から自分のエージェントに適用できる診断手順をまとめます。
失敗トレースの読み方
失敗したリクエストのトレースを開いたら、最終出力を見るのではなく処理の全チェーンを追うこと。ユーザーの入力、エージェントが取得したデータ、呼び出したツール、意思決定の瞬間にコンテキストに載っていた情報——この順で読み下します。
読む順番を変えるだけで、Perceptionの欠陥なのかReasoningの失敗なのかが驚くほどはっきり分かれる。最初の数十件は時間がかかりますが、パターンが見えてきたら分類は数秒で済むようになります。
モデル変更を検討する前の5つの確認項目
モデルを変える前に、次の5つを必ずチェックしてください。
- 意思決定の瞬間にエージェントが見ていた情報を全てダンプできているか
- その情報は最新の状態だったか（キャッシュや古いスナップショットでないか）
- 必要なデータソースで取得漏れがなかったか
- 出力に影響する無関係情報（ノイズ）が紛れ込んでいなかったか
- 副作用のある操作に承認レイヤーが挟まっていたか
この5項目のどれかに「いいえ」があれば、モデル変更は後回し。先にその箇所を直すほうが、費用対効果が圧倒的に高い。
よくある質問
Q. Context Stackとは何層の構造ですか？
Perception・Retrieval・Reasoning・Boundaries・Actionの5層構造です。ベース記事の著者がプロダクション環境の失敗トレース分析から導いた診断フレームで、失敗原因を層ごとに分類することで「モデル変更で直るもの/直らないもの」を切り分けられます。
Q. モデルを上げても意味がないのでしょうか？
意味がないわけではありません。Reasoning層の失敗（全体の約12%）にはモデル性能が効きます。ただし残りの88%は情報フローの設計問題なので、Perception・Retrieval・Boundariesを手当てしないままモデルを上げても同じ失敗が再発します。
Q. Perception層を改善する具体的な手段は何ですか？
まずは失敗時のコンテキストを全ダンプして「何が見えていて何が見えていなかったか」を可視化することです。その上で、データ取得のタイミングを「起動時まとめて」から「意思決定の直前」に切り替え、キャッシュTTLをデータ特性ごとに設計し直します。
Q. 小規模プロジェクトでも5層設計は必要ですか？
副作用のある操作（書き込み・送信・支払い等）を含むなら小規模でも必要です。読み取り専用のチャットボット程度であればPerceptionとRetrievalだけでも十分ですが、本番運用に進む段階でBoundariesとActionの設計を追加する前提で作っておくと後戻りが少なくて済みます。
まとめ
AIエージェントが本番で失敗したとき、最初に疑うべきはモデルではありません。著者が数百件のトレースを分析した結果、モデル自体の論理ミスは約12%にとどまり、残り88%は情報フローの設計問題だった。
対処の順番はこうです。まず失敗トレースを全文読み、意思決定の瞬間にエージェントが見ていた情報をダンプする。Context Stackの5層で分類し、Perception層の欠陥から着手する。Retrievalのタイミングと鮮度、Boundariesの権限分離を順に見直す。モデル変更を検討するのは、この手順を一通り終えてから。
「次のモデル待ち」という心理から抜け出せれば、今のモデルでも解決できる問題の多さに気づくはずです。
コメント