Claude Code、Cursor、Devin、あるいは数ターン以上動くコーディングエージェントを何かしら本気で使っているなら、いちばん効いてくる変数はベースモデルではない。各ステップでコンテキストウィンドウに何が入っているか だ。2025〜2026 年の研究フロンティアは、この事実を中心に静かに再編成されつつある。本稿はその中で押さえるべき論文、失敗モード、そして本番で生き残るパターンを総合したものだ。

ベンチマークの数字はここでは要約しない。数字はすぐ古くなるが、議論の形 は古びない。読み終えたときに手に入れてほしいのは、なぜロングコンテキストが壊れるのかというメンタルモデルと、来週の月曜日から使い始められるコンテキスト形成のための小さな道具箱だ。

すべての土台となる主張

2025 年 7 月、Chroma Research が Context Rot: How Increasing Input Tokens Impacts LLM Performance というテクニカルレポートを公開した。Claude 4、GPT-4.1、Gemini 2.5、Qwen3 を含む 18 のフロンティア LLM を、タスクを固定して入力長だけを変える条件で評価している。結果は明快で、すべてのモデルがコンテキストが伸びるほど性能が落ちる——同じモデルが短いコンテキストでは完璧にこなすタスクでも、だ。一部のモデルではない。ほとんど、でもない。18 モデル全部だ。

これがこの先すべての経験的アンカーになる。200K トークンのウィンドウは 200K トークン分使えるという意味ではない。100 万トークンのウィンドウも 100 万トークン分使えるという意味ではない。容量と実効容量は乖離し、その乖離は名目上の上限のはるか下から測定できる。2025 年後半から 2026 年初頭にかけての独立した追試も、新しいモデルとより大きなウィンドウでこのパターンを確認している。

コーディングエージェントにとって、これはチャット以上に効いてくる。エージェントは読み込むファイル、ツールの出力、失敗したテスト、diff——あらゆるものを貪欲にコンテキストに積み上げるからだ。最終的な答えが一部で収まるようなセッションでも、1 回で 100K〜500K トークンに達しうる。したがって実務的な問いは「ウィンドウはどれくらい大きいか」ではなく「セッションが伸びる中で S/N 比 をどう高く保つか」になる。

ロングコンテキストが壊れる理由：3 つの重なり合うメカニズム

文献は 3 つのメカニズムに収束していく。それぞれに独自の論文の系譜がある。

アテンションの希薄化。 セルフアテンションのスコアは確率分布——合計 1 になる。1 万トークンなら各トークンは平均して意味のあるシェアを受け取る。100 万トークンなら 100 万分の 1 だ。信号が伸びなくてもノイズの床は長さとともに上がる。これが context rot の背後にあるメカニズム論であり、「モデルが 40 ターン前の重要な指示に気づいていないように見える」現象がハルシネーションではなく、根本的なアテンション予算の問題である理由だ。

Lost in the middle。 Liu らの 2023 年の論文 Lost in the Middle: How Language Models Use Long Contexts は、モデルがコンテキストの冒頭と末尾からは確実に情報を引き出せるが、中間からは苦手であることを確立した。性能カーブは U 字型になる。最近の 2026 年の論文 Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias は、この U 字が残差接続を伴う因果マスキング固有のものであり、学習や RoPE エンコーディングが効き始める前——初期化時点ですでに現れることを示している。つまり、これはスケールで解決するバグではない。アーキテクチャの位相的性質だということだ。

ディストラクタ干渉。 Chroma のレポートとそれに続く研究は、意味的に似ている ディストラクタ——関連しているように見えるが実はそうでないコンテンツ——を追加すると性能が非線形に落ちることを示している。似たディストラクタが 4 つあると、1 つの 4 倍以上に効いてくる。構造化されたコヒーレントな文書は、直感に反して、シャッフルされたものより 悪い——コヒーレンスがもっともらしく見える誤った経路を提供してしまうからだ。コーディングエージェントにとってはこれがいちばん危険なメカニズムだ。コードベースはニアデュプリケート（似たヘルパ、同じ関数の別バージョン、非推奨のバリアント）で溢れており、それらが正しいチャンクとアテンションを奪い合う。

誰もが最初に試すナイーブな答え：もっと大きなウィンドウ

新世代のモデルが出るたびにウィンドウは大きくなる。Gemini 2.5 は 100 万トークン、Llama 4 は 1000 万トークンを謳った。ナイーブな読み方は「全部突っ込んで、モデルに整理させる」だ。これは動かないし、その理由は今やよく文書化されている。2025 年後半に測定されたすべてのフロンティアモデルで、難しいタスクにおける検索精度は 256K から 1M トークンの間で目に見えて落ちる。Claude Opus は最良の長距離想起を保ったが、それでも 256K から 1M で難しいベンチマークの精度は 2 桁落ちた。GPT と Gemini はそれ以上に落ちた。

大きなウィンドウが役に立たないという話ではない。本当に必要なとき には極めて有用だ——ワンショットのドキュメント分析、稀な評価、研究プロトタイプ。危険なのは、それをエンジニアリングの代替として使うときだ。最適化すべき指標は容量ではない。信号密度だ。

いま競合するコンテキスト管理のパラダイム

エージェントの成長するコンテキストをどう扱うかについて、4 つのパラダイムが競合している。互いに排他ではない——本番システムはこれらを組み合わせる。

1. コンパクション（要約）。 古いターンを LLM 生成の要約で定期的に置き換える。Cursor と OpenHands のデフォルトだ。ロッシーで——真っ先に消えるのは具体性だ——要約自体が生成ステップなので独自のハルシネーションを持ち込む。コンパクションはアテンション希薄化を緩和するが、コーディングエージェントがいちばん必要とする厳密な詳細（変数名、行番号、設定値）を犠牲にする。

2. 観測マスキング。 2025 年 12 月、JetBrains の研究者が NeurIPS Deep Learning for Code ワークショップで The Complexity Trap を発表した。彼らの発見：洗練された LLM 要約は、はるかに単純な手法——古いツール出力を「Previous 8 lines omitted for brevity」のようなプレースホルダテキストに置き換えつつ、エージェントの推論と行動履歴は完全に保持する——と同等かそれ以下だった。観測トークンは平均的な SWE-agent ターンの約 84% を占める。マスキングだけで、コンテキスト管理なしと比べてコストを半減し、タスク完了で LLM 要約と同等かわずかに上回る。両方組み合わせるとさらに約 10% の節約になる。教訓は明快で、業界は複雑な圧縮に走ったが、バカみたいに単純なフィルタでほとんどのゲインを取れていたということだ。

3. サブエージェント分離。 Anthropic のサブエージェント関連ガイダンス はこの議論を明示している：専門タスクごとに新鮮なコンテキストウィンドウを与える。メインエージェントはオーケストレーション役に徹し、サブエージェント（code-reviewer、debugger、planner）はクリーンなコンテキストで走り、圧縮された結果を返して終了する。Anthropic のマルチエージェントリサーチシステムのレポートは「トークン使用量が結果の質のばらつきの 80% を説明する」と指摘している——これは「各エージェントが何を見ているか」のアーキテクチャが「どのエージェントか」より効くという言い換えだ。名前付きサブエージェントと独立したコンテキストウィンドウを持つ Claude Code が、アーキテクチャ的に本物の優位を持つのはここだ。

4. 呼び出し可能なツールとしてのコンテキスト。 Beihang らによる Context as a Tool (CAT)（ACL 2026 Findings）は、コンテキスト管理を外部ヒューリスティックではなく、エージェントが計画して呼び出せる一級のアクションにすべきだと論じる——ちょうど edit_file や run_tests のように。彼らの SWE-Compressor は SWE-Bench Verified で 57.6% に達し、しかもコンテキストを有界な予算内に収めている。狙いは、圧縮の仕方だけでなく いつ 圧縮するかをモデルに教えることだ。

見落としがちな第 5 のパラダイム：コーディングエージェント 自体 をロングコンテキスト処理系として使う

Coding Agents are Effective Long-Context Processors（Cao et al., 2026）は通常のフレーミングをひっくり返す。アテンションにもっとトークンを詰め込む方法を問うのではなく、エージェントにロングコンテキストをファイルシステムに外部化させ、grep、awk、Python で操作させたらどうなるかを問う。結果：既製のフロンティアコーディングエージェントが、3 兆 トークンにおよぶベンチマークで、公開されている SOTA を平均 17.3% 上回った。メカニズムは、ネイティブなツール習熟度とファイルシステムへの親和性の組み合わせで、エージェントが手に負えないコーパスの小さな標的化されたビューを構築できることだ。これはこの 1 年、Claude Code のパワーユーザーの間で民間伝承だった「in-context を減らして、in-file を増やす」流儀の経験的な正当化になる。

サブエージェント分離と組み合わせると、動作原理が見えてくる：ファイルシステムがあなたの拡張コンテキストウィンドウ だ、と。エージェントが grep で引ける情報は、そもそもアテンションに払わずに済ませられるコンテキストである。

コストを下げつつ間接的に rot も減らすプロンプトキャッシュ

Anthropic のプロンプトキャッシュ は 2024 年 12 月に GA になり、急速に普及した。仕組みは、プレフィックスに cache_control ブロックを付けると、そのプレフィックスを共有する後続リクエストが入力価格の 10% で課金される（デフォルト TTL 5 分、書き込みコストを上げれば 1 時間も可能）。よく引かれる例：100K トークンの書籍をキャッシュしたプロンプトで TTFT が 11.5 秒から 2.4 秒——レイテンシ 79% 削減、キャッシュされたトークンで最大 90% のコスト削減。

2026 年 1 月の PwC の評価 Don't Break the Cache は、OpenAI、Anthropic、Google にまたがる DeepResearchBench 上で 3 つのキャッシュ戦略をテストした。主要な発見：ナイーブに全コンテキストをキャッシュすると、プロンプト末尾の動的なツール結果がキャッシュ境界を壊し続けるため、逆にレイテンシが増える ことがある。戦略的な配置——system prompt を最初、static context を次、安定プレフィックスの末尾に cached breakpoint、その後に動的なツール出力——でコストを 45〜80%、TTFT を 13〜31% 削減できる。

プロンプトキャッシュは context rot を直接は治さない。ただし 2 つの二次効果が効いてくる：(a) 大きなコンテキストの経済的ペナルティが急激に下がるため、複数ターンで 1 つの汚れたコンテキストを積み上げるのではなく、意味のあるアクションごとに クリーンなコンテキストをリプレイ できるようになる。(b) キャッシュヒットを狙う設計は、プロンプトを [安定でキャッシュ可能なプレフィックス] + [小さくて動的な末尾] という構造に強制する——これは U 字型アテンションカーブの両端に重要情報を置くのに理想的な構造だ。

本番で生き残る 6 つのパターン

理論は少数の具体的な動作にマップされる。おおむね「工数あたりのインパクト」が大きい順に。

1. 重要な指示はプロンプトの両端に置く

Agrawal et al.（EMNLP 2024） の R&R（reprompting）は、長い文書を通じてタスク指示を定期的に繰り返すことで、GPT-4 Turbo と Claude-2.1 の QA 精度が約 16 ポイント向上することを示した。コーディングエージェントではこれが「最重要な制約を CLAUDE.md（コンテキストの先頭）に置き、かつ 現在のユーザーターン（コンテキストの末尾）で再度述べる」という形に一般化される。40 ターン前に述べた制約をモデルが覚えていると期待してはいけない。U 字カーブは容赦ない。

2. 状態をファイルシステムに外部化する

ファイルシステムを永続メモリとして使う。TODO.md、DECISIONS.md、サブタスクのメモを置くスクラッチディレクトリ。これはまさに Coding Agents are Effective Long-Context Processors が正当化しているメカニズムだ。エージェントのコンテキストウィンドウは、ペイロードではなくポインタを保持する。何かが重要になったら、エージェントは記憶ではなく小さな標的ファイルを読み直す。エージェントの再起動や事故的なコンパクションを生き延びるための道でもある。

3. サブエージェントの境界を、スキルだけでなくコンテキスト量で設計する

直感的にはロールで分解する——planner、coder、reviewer。それに加えて タスクがどれくらいノイジーか でも分解する。大量のツール出力を生むタスクはすべて——広範な grep、find、依存関係スキャン、長大なテストログ——独自のサブエージェントコンテキストの候補だ。メインエージェントには生の出力ではなく 5 行の合成が返ってくる。JetBrains 論文の「84% が観測トークン」という統計がいちばん効いてくるのがここだ：それらの観測はオーケストレータではなく、サブエージェントのコンテキストに置くべきだ。

4. concat する前に rerank する

任意の検索ステップ（コードベース、ドキュメント、過去の会話へのセマンティック検索）で、検索後に結果を並べ替え、最も関連性の高いチャンクをコンテキストブロックの 端 ——先頭と末尾——に配置する。ベクトル検索の距離順は、位置的重要度順と同じではない。U 字カーブを踏まえれば、これは労力に対して不釣り合いに効くシンプルな修正だ。

5. 安定なところをキャッシュし、末尾を動的にする

プロンプトを次のように構造化する：system prompt → tool definitions → CLAUDE.md → 過去の決定事項の要約 → キャッシュブレイクポイント。揮発するもの（現在のファイル diff、最新のツール出力、現在のユーザーメッセージ）はすべてブレイクポイントの後に来る。Don't Break the Cache の評価がプロバイダを問わず一貫して勝ちと認めたパターンだ。副次効果として、「静的」なはずのコンテキストが実は変化していること（キャッシュヒット率をひそかに殺しがちなよくあるバグ）に気づけるようになる。

6. 汚れたコンテキストを積み上げるより、クリーンにリプレイする

コストが許すなら、意味のあるアクションごとにクリーンな状態からエージェントの会話を再スタートし、最小限の状態ファイル、現在のタスク、ツール定義だけを与える。長時間セッションはエラー、矛盾、陳腐化した推論を蓄積する。安価なリプレイは、賢いコンパクションに勝ることが多い。プロンプトキャッシュは、18 か月前にはなかった経済性でこれを可能にする。

正直に言うべきエッジケース

分野はまだ落ち着いていないので、正直な留保もいくつか。

コンパクションが勝つワークロードもある。 タスクが本当にモデルに長い 意思決定 のスレッド（ツール出力ではなく）を跨いだ推論を要求するなら、LLM 要約はマスキングより構造をよく保つ。JetBrains の発見は、ツール観測が支配的なワークロードにいちばんきれいに当てはまる。選ぶ前に自分のトークン分布を見ること。

サブエージェントのオーケストレーションはタダではない。 メインとサブの間のホップごとにレイテンシ、追加プロンプト、調整オーバーヘッドが加わる。タスクが 30K ターンの単一会話にすっぽり収まるなら、キャッシュを効かせたモノリシックエージェントがマルチエージェントを上回ることもある。損益分岐点はタスクが大きくなり、キャッシュが良くなるにつれて動く。

Rerank は関連度シグナルの精度以上には良くならない。 クエリ埋め込みに対するコサイン類似度で rerank すると、最も 似て見える チャンクが端に来るが、それが最も 有用 とは限らない。ハイステークスな検索では 2 段階（bi-encoder リコール → cross-encoder rerank）のコストを払う価値はある。1 段階では足りない。

圧縮された要約の忠実性は現実の問題だ。 要約されたターンはハルシネートされたコミットメントを引き継ぎうる。エージェントが後に「PostgreSQL を使うと決めた」に基づいて推論するなら、その決定が本当に下されたのか、要約器が捏造したのかを検証すること。

来週の月曜日から使えるチェックリスト

読む順にたどる参考文献

  1. Lost in the Middle (Liu et al., 2023) — 経験的な礎石。短く、明快で、プロンプト構造がなぜ効くかについて今なお最も有用な 1 本。
  2. Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma, 2025) — 18 モデルにわたる 2025 年の再現・一般化。論文というよりエンジニアリングレポートとして読める。
  3. The Complexity Trap (JetBrains, NeurIPS DL4C 2025) — 観測マスキングの結果。シンプル、反直感的、インパクト大。
  4. Context as a Tool (CAT, ACL 2026 Findings) — 学習可能で呼び出し可能なアクションとしてのコンテキスト管理。
  5. Coding Agents are Effective Long-Context Processors (Cao et al., 2026) — 拡張コンテキストウィンドウとしてのファイルシステム。
  6. Don't Break the Cache (PwC, 2026) — 実務的なプロンプトキャッシュ評価。
  7. Anthropic のサブエージェント文書 — Claude Code におけるコンテキスト分離の運用マニュアル。
  8. Can't Remember Details in Long Documents (R&R, EMNLP 2024) — プロンプトレベルの緩和策としての reprompting と in-context retrieval。

一文でまとめると

context rot が病だとしたら、治療はより大きなウィンドウではなく——信号密度を高く保つエンジニアリングだ：安定なところをキャッシュし、ノイジーなところをマスクし、サブエージェントで分離し、ファイルシステムに外部化し、意図を両端で繰り返す。

この投稿の他のすべては、その一文への脚注だ。