コンテキストが長くなるとLLM（AIエージェント）の出力精度はなぜ落ちるのか

Claude Code を使っていると、扱うファイルや指示を足していった後半で挙動が雑になる場面に出会うことが増えました。コンテキストウィンドウにはまだ余裕があるはずなのに精度が落ちる、というのが気になって調べていくと、実体験と一致する研究や報告がいくつか見つかります。LLM や AI エージェントは入力が長くなるほど出力精度が落ちるという性質を構造的に抱えていて、これを知っておくと運用の設計判断がしやすくなります。

LLM 自体が入力長で精度を落とす

「コンテキストウィンドウが伸びたから、たくさん渡しても大丈夫」と直感的には思いがちですが、研究を見ると逆のことが分かってきています。LLM 単体の性質に絞った報告を2つ並べておきます。

Lost in the Middle: 中盤は読まれにくい

よく引用されるのが Stanford らの「Lost in the Middle」という研究^[1]です。長い入力の中で関連情報が中央付近にあると、先頭や末尾にあるときと比べて性能が30%以上落ちる、と報告されています。

LLM は入力全体を均一には見ておらず、先頭と末尾に注意が偏る U 字型のバイアスがあると示されました。中盤に詰め込んだ指示やコードは、そもそも読まれにくい可能性がある、ということになります。

Context Rot: 長くなるほど品質が劣化する

もっと最近のものだと、Chroma が2025年7月に「Context Rot」という技術報告^[2]を出しています。GPT-4.1・Claude 4・Gemini 2.5・Qwen3 を含む18の最先端モデル全てで、入力トークンが増えるほど出力品質が劣化することを実測した内容です。

重要なのは、これが「ウィンドウ上限に達したとき」ではなく 入力が長くなり始めた時点から徐々に起きる 点です。200K トークンを謳うモデルでも、50K トークン付近からすでに目に見えて劣化することが示されています。

報告の中では、コーディングエージェントの主要な失敗モードは context rot だ、とまで言われています。検索・ファイル読み込み・試行錯誤の過程でコンテキストにノイズが積もっていき、それが後段の出力をじわじわ汚していく、という話です。

入力が太ると出力に使える予算が物理的に減る

精度の話だけでなく、API の作りとしても入力長が出力を圧迫する構造になっています。これは推論性能とは別の、より単純な算数の問題です。

input と output はコンテキスト枠を分け合う

Claude も GPT も、いわゆる「コンテキストウィンドウ」は input と output を合わせた合計のトークン上限として定義されていて、output 側にはさらに max_output_tokens という別の制限が乗っています^{[3] [4]}。

Claude Opus 4.7 と Sonnet 4.6 は 1M トークンのコンテキストですが、1リクエストで返せる出力上限はそれぞれ 128K と 64K に絞られています^[4:1]。OpenAI 側も同じ構造で、GPT-4.1 は 1M コンテキストに対して output 上限が 32K しかありません^[3:1]。

input でコンテキストを使うほど、output に回せるトークンが減っていきます。1M ウィンドウのうち 700K を input で使ったら、output に使えるのは残り 300K 以下です。先頭に大量のルールやファイルを毎回詰める運用は、AI が1回の応答で書けるコードの量や説明の厚みを物理的に奪っていることになります。

AI エージェントもコンテキストを削る方向に動いている

LLM 単体の精度劣化と input/output 予算の話を踏まえると、それを土台に動く AI エージェント(ハーネス)側がどう振る舞っているかも気になります。Anthropic 側の対策と、ユーザー側で起きる挙動の両面があります。

Anthropic の対策はコンテキストを削る方向に寄る

おもしろいのは、これに対する Anthropic 側の対策も、コンテキストを膨らませる方向ではなく削る方向に寄っていることです。

• prompt caching: 同じ前置き部分を再利用してコスト最大90%・レイテンシ最大85%削減^[5]
• Claude Code の auto-compaction: 以前はウィンドウの90%超でトリガーしていたが、新しいバージョンでは64〜75%で要約圧縮を走らせるようになっている^[6]
• context editing / memory tool: 古い検索結果やツール出力を会話から積極的に消す仕組み。100ターンの web 検索評価で、消さなければ失敗していたタスクを完了させつつ、トークン消費を84%削減したと報告されている^[7]

「広い文脈を渡せます」ではなく「いかに渡さずに済ませるか」が、API・エージェント基盤の両側で主戦場になっている、というのが今の景色です。

Anthropic 自身も「Effective context engineering for AI agents」というエッセイの中で、コンパクション・外部メモリ・サブエージェント分割の三本柱でコンテキストを管理することを推奨しています^[8]。

トークン経済の観点から見ても、入力が短く済むほど提供側の計算コストは下がります。企業側の利益構造とユーザー側の品質要求は同じ方向を向いているわけで、コンテキストを節約する設計に今後さらに最適化されていくのは自然な流れです。

体感として、長くなったエージェントは「手を抜く」

個人の主観としても、Claude Code を含むコーディングエージェントは、コンテキストが膨らんでくると目に見えて挙動が雑になります。

最初の方では丁寧にファイルを開いて確認していたのに、後半になると「ここはこうしておきました」だけで実コードが薄かったりします。複数ファイルへの修正指示のうち1〜2ファイルしか触らずに完了報告してくる、というのもよくあるパターンです。

「サボる」と言いたくなる挙動ですが、別に擬人化しなくても context rot と Lost in the Middle で説明がつきます。注意が先頭と末尾に寄ってしまえば、中盤で渡したファイル内容や指示は薄れます。入力が長くなれば、その分だけ出力に割けるトークンも実質的に減っていきます。

逆に言うと、コンテキストが短く保たれている間のエージェントは、たぶん多くの人が最初に Claude Code を試して驚いたときの精度に近い動きを返してくれます。あの初速をどれだけ長く保てるか、と考えると、毎回先頭に積まれるルールやファイルは小さければ小さいほど得です。

まとめ

AI エージェントに作業を任せていて「精度が落ちたな」と感じるとき、原因はたいてい context rot か Lost in the Middle のどちらかで説明がつきます。「モデルがさらに賢くなれば解決する」というよりは、ユーザー側の入力設計を変える方が早い、というのが現時点の実感です。

実際にどう運用に落とすかは別記事に書いています。自分のプロジェクトでは CLAUDE.md や AGENTS.md を置かず、Skill への呼び出し型に切り替えています。