コーディングエージェントのハーネスを分解して検証：コンテキスト管理の価値の大半は「ウィンドウを溢れさせないこと」
176組のペア実験、4モデル、2ベンチマーク：計画は弱いモデルには精度の足場、強いモデルにはコスト削減ツール。切り詰められたコンテキストを復元可能にすることはほとんど使われていない。事前定義ツールはbashが弱いモデルにのみ明確な利益をもたらし（+15.0%）、bashが強いモデルにはbashをより安く提供するだけ。
日本語
コピー
新しい実証研究が「コーディングエージェントの harness」を分解し、コンポーネント単位で比較した。これまでの研究の多くは harness をひとつの塊として評価しており、どの部品が何に効いているのかが見えなかった。この論文の手法は、実行ループを固定し、planning、action space、context management の3つだけを変数にする。そのうえで4つのモデル、2つのベンチマーク（SWE-Bench Verified、Terminal-Bench 2.1）で 176 組のペア実験を回し、5種類のコンテキスト管理戦略、4種類のコンテキストウィンドウ予算、planning と action space の的を絞ったアブレーションを網羅した。
結論は4つ。どれも「足せば足すほど良い」という類の直感ではない。
1. コンテキスト管理：価値の主源は「ウィンドウを溢れさせないこと」
コンテキスト管理の効果は、ウィンドウ予算が厳しくなるほど大きくなる。そしてその利益の大半は、コンテキスト溢れによる失敗を防ぐことから来ており、モデルを賢くすることではない。管理されていない軌跡でもウィンドウに収まるようになると、精度の向上幅は縮み、しかも特定のモデルに依存する度合いが強まる。
2. まずルールで削り、次に LLM で要約するのが最も割が良い
いくつかの戦略の中で最も良かったのは T4。ルールベースの elision で粗く削り、そのあと LLM で要約する。直感に反するのは、削った内容を復元可能にすること（recall / M2 メカニズム）がほぼ無意味だった点だ。モデルはほとんど呼び出さないし、精度も elision だけの場合と変わらない。研究者の言葉を借りれば、モデルがまず使わない機械的な構造を足しているだけで、精度は何も買えていない。
Takeaway: いくつかのコンテキスト管理戦略で精度が同等なら、T4 は安価な早期 elision によって LLM 要約への依存を減らし、全体コストで最良の成績を出す。
3. Planning：弱いモデルには足場、強いモデルにはコスト削減手段
Planning の価値は、モデル能力によってその性質を変える。
- 弱めのモデルでは、planning が軌跡を編集を一度試せる長さまで生かし、成功率を押し上げる。代償は計算量の増加。
- より強いモデルでは精度の変化はごく小さく、planning は主に「編集後の再検証」のような冗長を省き、コストを下げる。
データを見ると、Nemotron-3 30B で planning を有効にするとターン数、ツール呼び出し回数、呼び出しあたりの平均入力トークンがそろって増える。一方、より強いモデルでは効率化の手段としての性格が強い。中程度の能力帯では、その価値はタスク種別にも左右される。
4. Action space：強いモデルと弱いモデルを分ける分水嶺
定義済みツールセットは bash が苦手なモデルに明確に効く。bash を難なく使えるモデルは bash インターフェースひとつで十分で、しかもコストが目に見えて低い。コマンドライン系のタスクでは特に差が出る。
具体的な数字：
| モデル | 定義済みツールセットによる成功率の向上 |
|---|---|
| Nemotron-3 30B | SWE-Bench +15.0%、Terminal-Bench +10.1% |
| Nemotron-3 120B | SWE-Bench +1.6%、Terminal-Bench +4.5%（ただし実行はより効率的） |
もうひとつ説得力のある現象がある。Terminal-Bench では、bash-only の軌跡の 66% がインターフェース外のものを出して終了する。これにより平均軌跡長は 71 ターンから 15 ターンに圧縮される。つまり「bash だけを与える」こと自体が弱いモデルにとっては壁であり、単なるスタイルの違いではない。
軌跡レベルでの説明
論文の軌跡分析はメカニズム面の説明を与えている。コンテキスト管理は実行軌跡を長くするが、エージェントの振る舞いを実質的に変えない。planning が変えるのは軌跡がどこで止まるか。action space が変えるのはコードを書く粒度だ。
6モデルの価格の目安
論文は OpenRouter の2026年8月時点の価格でコストを換算している（100万入力／出力トークンあたり）：Nemotron-3 30B が $0.05 / $0.20、Nemotron-3 120B が $0.08 / $0.45、Nemotron-3 550B が $0.50 / $2.20、Mistral-Medium-3.5 が $1.50 / $7.50。
agent を作る人にとって何を意味するか
この論文の実践的な指針は比較的はっきりしている。
- モデル能力と予算に合わせて harness を組む。万能の「最適構成」を探すのではない。
- コンテキストに金をかけるなら「溢れさせない」ためが最も割が良い。まずルールで削り、それから LLM 要約に頼る。
- 「復元可能な削減」のような、より安全に見える設計は、複雑さを増やすだけの可能性が高い。
- 使っているモデルの bash が十分強いなら、ツールセットは減らしてよい。それはコスト最適化であり、能力への適応でもある。
論文は全43ページ。176 組の設定とアブレーション結果を完全に収め、新しい harness 設計をコンポーネント単位で評価するためのモジュール式フレームワークも提供している。