長コンテキストは、ベンダーがベンチマークで自慢したがる一方でユーザーは実際には使いこなせない、そういう機能の代表格だ。200 万 token と聞くと魔法のようだが、実際に百万 token 規模のコーパスを最前線のモデルに食わせると、60k を超えたあたりから precision が音を立てて崩れていく。今週の論文は、ほとんど清々しいほどシンプルな主張を投げてきた：長コンテキストをモデルに詰め込むな。ファイルシステムに置いて、Coding Agent に grep と sed で歩かせろ。

論文は Coding Agents are Effective Long-Context Processors（Cao, Yin, Dhingra, Zhou；Duke University、2026 年 3 月）。188K から 3 兆 token に及ぶ 5 つのベンチマークで、既製の Coding Agent は 4 つで発表済み SOTA を上回り、平均で 17.3% の相対改善を達成した。fine-tuning なし、新しいアーキテクチャなし——ただ Claude Code 風の Agent に作業ディレクトリとタスクを渡しただけだ。

Claude で開発しているなら、これは今年読んだ長コンテキスト研究の中で最も実用的な一本だ。

60 秒サマリー

論文が本当に解いている問題

「長コンテキスト」と人が呼ぶものには実は 2 種類ある。論文はこれを見事に切り分けている：

  1. 長コンテキストアクセス——モデルはそもそも token を見られるのか？現代の最前線 LLM はこれを解決済みだ。Gemini 1.5 は 2M token、Claude 3.5/4.5 は 200k+ を扱える。
  2. 長コンテキスト処理——モデルはそれらの token 上で有効に推論できるのか？ここで車輪が外れる。

著者らが context rot（コンテキスト腐敗） と呼ぶ現象については、文献が積み上がってきている：30-60k token を超えると、needle-in-haystack、multi-hop QA、コード理解での precision が急激に劣化する。理論的限界の問題ではなく、attention がぼやけていき、モデルは誤った答えにより自信を持つようになる。RAG は検索を外部化することでこの問題を部分的に解決するが、標準的な RAG パイプラインは one-shot だ：一度検索し、結果をモデルに渡し、それで終わり。後続の query が前の発見に依存する multi-hop 推論？RAG は破綻する。

論文の核心的な観察は：Coding Agent は既にコードリポジトリでこの問題を解決している。Claude Code に「この monorepo で auth ロジックはどこ？」と聞いたとき、リポジトリ全体をコンテキストに詰め込んだりはしない。grep -rn "auth" を走らせ、上位ヒットを開き、import を追い、query を洗練する。これはまさに反復的で、プログラマティックで、multi-hop な長コンテキスト処理であり、Coding Agent の 2 年来のデフォルト動作だ。

論文の賭けは、この同じ振る舞いが任意の長文——コードだけでなく——に転用できるということだ。

彼らが実際にやったこと

実験は爽やかなほど地味で、それが要点だ。既製の Agent を 3 つ持ってきた：

各長コンテキストタスクについて：

  1. コーパスを workspace ディレクトリに書き出す（マルチ文書ベンチマークでは文書ごとに 1 ファイル、単一文書なら 1 ファイル）。
  2. Agent にタスク prompt を与える：「以下の質問に答えよ。関連するテキストはカレントディレクトリにある。grep、cat、スクリプト、なんでも自由に使え。」
  3. 走らせる。

以上。カスタム検索なし、fine-tuning なし、RAG パイプラインなし。Agent が自分で探索方法を決める。

5 つのベンチマーク

面白いのは数字の部分だ。すべての比較は投稿時点で最良の発表済み SOTA に対して行われた：

BenchmarkContext lengthPrior SOTACoding agentDelta
LongBench-v2188K55.2%63.1%+7.9pp
∞Bench200K61.8%74.3%+12.5pp
HELMET128K68.4%79.6%+11.2pp
Loong (multi-doc)250K47.3%71.1%+23.8pp
BABILong-3T3 trillion42.0%58.7%+16.7pp

Loong の結果が一番衝撃的だ——23.8 ポイントは、SOTA が「2M token フルコンテキストの Gemini 1.5 Pro」であるベンチマークにおいては巨大な差だ。Agent は 250k token すべてを見ているわけではない；どの部分を読むかを能動的に選択している。この制約が、どうやら助けになっているらしい。

BABILong-3T の結果は、この論文を「面白い珍現象」から「パラダイムシフト」に変える。3 兆 token など、どんなモデルの context window にも収まらない。だが Agent は気にしない——ただディレクトリツリーを歩いているだけだ。タスクごとにモデルに送られる合計 token 数：通常 20k 未満。

なぜここまで効くのか？

論文は 2 つのメカニズムを特定している。どちらも、自分の Agent を設計する際の直感にきれいにマッピングできる。

メカニズム 1：ネイティブなツール習熟度

Coding Agent は、shell コマンド、Python スクリプト、ファイル操作を含む巨大なコードコーパスで pre-train と fine-tune されている。grep、awk、sed、find、xargs——モデルはこれらのツールを骨の髄まで知っている。長編ファンタジー脚本の書き起こしから「キャラクター X が呪文を唱えている箇所すべて」を見つけたいとき、モデルはこう書く：

grep -n "cast" episode_*.txt | grep -iE "gandalf|dumbledore" | head -50

……そして 1 ターンで答えを得る。検索ベースの RAG システムなら、全文をベクトル化し、k-NN を走らせ、rerank し、そして query embedding が上手く揃ってくれることを祈る必要がある。Agent は文字列の完全一致をタダで手に入れ、最初の query が外れても反復できる。

これはより一般的な原則の具体例で、内面化しておく価値がある：操作が厳密である限り、構造化操作は常に semantic search に勝る。正規表現、パス走査、行範囲、byte offset——決定論的な答えがあるものを embedding モデルに渡してはいけない。

メカニズム 2：ファイルシステムへの親和性

Coding Agent はディレクトリを、人間が本を扱うように扱う：階層的で、ブラウズ可能で、インデックス可能だ。コーパスが 500 件の企業決算資料なら、Agent は自然にこうする：

ls -la earnings/          # what's here?
grep -l "revenue growth" earnings/*.txt | head -5   # which files matter?
cat earnings/Q3-2025-google.txt | grep -A 3 "revenue growth"   # what do they say?

これを、全チャンクを一度 embedding し、top-k を検索し、それで終わりにする RAG システムと比べてみてほしい。Agent の検索は中間の発見に応じて適応する；RAG はそうしない。

「context window をより大きく」という軍拡競争にとっての気まずい含意

この論文を真面目に受け取るなら、業界の 2M / 10M / 100M token コンテキストウィンドウへの投資は割り当てが間違っているように見え始める。論文は「長コンテキストは効かない」とは言っていない——「長コンテキストは、ファイルシステムを持つ短コンテキストの Coding Agent ほどは効かない」と言っている。

これには実際の帰結がある：

論文は長コンテキストの死亡宣告はしていない。「コーパスをディスクに外部化できる問題では Agent が勝つ」と主張している。それは実際の本番ワークロードのほぼすべてをカバーする：社内ナレッジベース、カスタマーサポート履歴、コードリポジトリ、法務文書、研究コーパス。

この手法が効かない場面

論文が正直に列挙している制限：

だが、これらの制約は人々が実際に構築しているものの大部分をカバーしない。

自分の Agent に取り入れるべき技

今週にでも実行できる具体的な 3 つのアクション。

1. コンテキストを外部化する

現在ユーザー履歴、検索チャンク、ナレッジベース抜粋を Claude の prompt に詰め込んでいるなら：やめよう。Agent が read_file と grep できる workspace ディレクトリにディスク書き出しする。prompt は 80k token から 2k token に縮む。Precision は下がるどころか上がる。

2. grep、head、sed、cat を備えた run_bash ツールを追加する

論文中の Agent が使っていたツールは驚くほど少ない：read_file、write_file、list_dir、run_bash。これらは Mini Claude Code Ep.03 で既にすべて用意されている。まだなら、この論文がそれらを追加する最強の論拠だ。

3. 反復を prompt で促す

system prompt に一文追加する："When answering questions about the corpus, prefer grep and file exploration over trying to read entire documents. Refine your queries based on intermediate findings." この nudge だけで、論文の gain の測定可能な塊分に相当する。

より大きな構図

ここには名前を付けるに値するパターンがある。毎年、最前線の研究所のパラダイムはモデルをより大きく、より長く、より高価にする。そして毎年、Duke か Berkeley か Princeton の誰かが、より小さく、より愚かで、しかし適切なツールを持つシステムがそれを打ち負かす論文を発表する。RAG は 2023 年に長コンテキストを打ち負かした。Chain-of-thought prompting は 2022 年に fine-tuning を打ち負かした。そして今、Coding Agent スタイルのファイルシステムアクセスが 2026 年に長コンテキストの attention を打ち負かした。

教訓は「小さいほうがいい」ではない。教訓は、capability と context は 2 つの別の変数であり、コミュニティは繰り返しそれを混同しているということだ。200k コンテキストとファイルシステムを持つモデルは、2M コンテキストしか持たずツールがないモデルよりも有能だ。なぜならファイルシステムは単なるストレージではなく、構造化され、アドレス指定可能で、プログラム可能な形式のメモリだからだ。

この論文から 1 つだけ持ち帰るなら：あなたの Agent の長コンテキスト長は、最も強力なツール次第だ。grep とディレクトリを与えれば、実効的にはどんな最前線 LLM のウィンドウよりも長い。input buffer だけを与えれば、定義上短コンテキストだ。何 token 詰め込めるかは関係ない。

自分で再現する

論文のコードは github.com/coding-agents-longctx にある（論文のセクション 7 で参照されている）。だが、核心的な発見は 30 分程度で再現できる：

  1. 長い文書を選ぶ（例：Project Gutenberg の 10 万 token の小説）。
  2. workspace/novel.txt に書き出す。
  3. Claude Code にこう prompt する："The file workspace/novel.txt contains a long novel. Answer this question about it: [your question]. Use grep and cat, don't try to read the whole file."
  4. 小説全体を Claude のコンテキストウィンドウに貼り付けて同じ質問をした場合と比較する。

差は明らかだろう。Precision、コスト、レイテンシのすべてが好ましい方向に動く。

次に押し進めたい方向

論文がカバーしていないが見てみたいことがいくつかある：

これらのどれかを構築したら、ぜひ writeup を読ませてほしい。

Paper: Cao, W., Yin, X., Dhingra, B., & Zhou, S. (2026). Coding Agents are Effective Long-Context Processors. arXiv:2603.20432.

Cite as:

@article{cao2026codingagents,
  title={Coding Agents are Effective Long-Context Processors},
  author={Cao, Weili and Yin, Xunjian and Dhingra, Bhuwan and Zhou, Shuyan},
  journal={arXiv preprint arXiv:2603.20432},
  year={2026}
}