コーディングエージェントのハーネス設計を実証的に検証

論文が調べたこと

コーディングエージェントは、言語モデルだけでできているわけではありません。モデルは「ハーネス」の中で動きます。ハーネスとは、制御ループ、ツールのインターフェース、そしてやり取りの履歴のうちどれをモデルに残すかを決めるルールを持つソフトウェア層です。論文「An Empirical Study of Harness Design for Coding Agents」(arXiv 2609.20804、2026年9月17日投稿)は、この層のどの部分が実際に効いているのかを問います。著者は9人で、UMass Amherst、Emory University、UNC Charlotte の所属です。論文には、作業の一部が Zoom Video Communications でのインターンシップ中に行われたとの注記があります。

著者によると、これまでの研究は完成したハーネスをまるごと比較することが多いといいます。論文は、ハーネス間の比較評価を引いています。そこでは Claude-Opus-4.5 が OpenHands で最も良く、Claude-Sonnet-4.5 は SWE-Agent で最も良かったとされます。この種の結果では、差が計画、ツール設計、コンテキスト管理、あるいはモデルとの相互作用のどれから来たのか分かりません。そこで著者らは軽量なハーネスをゼロから作りました。ReAct ループは固定です。変えるのは3つの構成要素だけです。計画(planning)、行動空間(action space)、コンテキスト管理(context management)です。権限処理、編集後の診断、行き詰まり検出は、すべての実験で固定です。

実験の設定

ハーネスは LangGraph 上に作られ、ベンチマークは Harbor 経由で実行されます。各タスクは最大300ステップです。テストするモデルは4つです。Nemotron-3 の3サイズ(30B、120B、550B)と Mistral-Medium-3.5-128B です。ベンチマークは2つです。SWE-Bench Verified は人手で検証された500件の GitHub issue を含みます。Terminal-Bench 2.1 は89件のコマンドラインタスクを含みます。論文は成功率とタスクあたりの平均コストを報告し、コストは OpenRouter の価格で計算しています。

コンテキスト管理は5段階です。T0 は何もせず、ウィンドウがあふれるとエラーで終了します。T1 は古いツール出力を短いスタブに置き換えます(elision、省略)。T2 はそれに外部ストレージと recall_event ツールを加え、省略された内容を読み戻せるようにします。T3 は LLM による要約だけを使います。T4 は3つを段階的に組み合わせます。まず省略を行い、それでも履歴が長すぎるときだけ要約します。ソフトとハードのしきい値は、使用可能なウィンドウの0.6と0.85です。5段階すべてを、32k、64k、96k、128k トークンのウィンドウで実行します。計画と行動空間(定義済みツール対 bash のみ)は、T4 と128kウィンドウでのみ切り分けています。合計で176の対応した設定になります。著者らは両側の正確 McNemar 検定で成功率を比較し、偽発見率を0.05に抑えています。

4つの発見と論文の数値

1. ウィンドウが狭いほど、コンテキスト管理の価値が高い。 モデル平均で、ウィンドウを32kから128kへ広げると、管理あり(T1からT4)と T0 の差は、SWE-Bench で35.7から15.9、5.5、2.7ポイントへ縮みます。Terminal-Bench では9.5から7.5、4.8、2.8へ縮みます。T0 のオーバーフロー失敗率は、SWE-Bench で78.7%から8.7%へ、Terminal-Bench で61.0%から12.1%へ下がります。管理ありの全段階は、どの予算でもオーバーフロー失敗がゼロです。表3の一例では、32kで Nemotron-3 550B の SWE-Bench 成功率は、T0 で6.40%、T4 で55.60%です。論文は、利益の大半は早すぎる打ち切りを防ぐことから来ると結論づけています。 2. 「先に省略、後で要約」の T4 が最も効率的で、リコールはほとんど効かない。 T4 の成功率は T1 から T3 と同程度です。8つのモデルとベンチマークの組のうち7つでコストが最も低く、どのウィンドウ予算でもタスクあたり平均コストが最も低くなります。4つの予算すべてでピークコンテキストの比率も最も低くなります。32kでは、T1 と T2 はまだウィンドウのほぼ全体に達します。リコール機構は事情が違います。32件の対応比較で、T2 は T1 に15件で勝ち、14件で負け、3件で引き分けました。平均差はマイナス0.36ポイントです。64設定のうち36設定(56.3%)で、モデルは recall_event を一度も呼びませんでした。タスクあたりの平均リコール回数は、32kの0.540から128kの0.007まで下がりました。

3. 計画は「精度の足場」から「コスト削減」へ移る。 Nemotron-3 30B では、計画により成功率が SWE-Bench で11.6ポイント、Terminal-Bench で4.5ポイント上がりましたが、コストも上がりました。120B モデルでは、一貫した向上はありませんでした。Nemotron-3 550B と Mistral-Medium-3.5-128B では、計画により SWE-Bench のコストが約30%と32%下がり、成功率は2.0と0.4ポイント下がりました。 4. 最適な行動空間はモデルによって違う。 Nemotron-3 30B では、定義済みツールセットにより成功率が SWE-Bench で15.0ポイント、Terminal-Bench で10.1ポイント上がりました。Nemotron-3 550B では、bash のみにすると成功率が3.6と5.6ポイント上がり、コストは53%と30%下がりました。Mistral は結果が割れます。SWE-Bench では全ツールが優れ(23.2ポイント上)、Terminal-Bench では bash のみが6.7ポイント上回りました。

軌跡分析が示すこと

著者らは、LLM 判定器を使って、エージェント実行の各ターンにワークフローの段階を付けました。この分析が、上の4つの発見を説明します。 コンテキスト管理は、主に実行を長くします。32kで管理がないと、SWE-Bench の軌跡の中央値は20から30ターンで、多くの実行は不具合の特定中に止まります。管理があると、中央値は約50から180ターンに伸び、実行は検証まで進みます。 計画は、弱いモデルと強いモデルで働き方が違います。Nemotron-3 30B の SWE-Bench で計画を切ると、軌跡の中央値は40ターンから5ターンに縮みました。計画がないと、実行の68.6%が編集を一度もせずに終わり、計画があると27.8%でした。最も強い2モデルでは、計画により中央値が108から74ターン(550B)、68から53ターン(Mistral)に短くなりました。著者らは、その大部分を編集後の検証の減少によるものとしています。

行動空間は、コードの書き方を変えます。Nemotron-3 30B の Terminal-Bench では、bash のみの実行の66%が、bash のみのレジストリに存在しないツールの呼び出しをモデルが出した後で終了しました。平均の実行は71ターンから15ターンに縮みました。550B モデルの Terminal-Bench では、bash のみにすると軌跡の中央値が47から31アクションに縮み、コードを書くアクションの割合が16%から27%に上がりました。すでに編集したファイルへの再パッチは4モデルすべてで減り、たとえば30B では3.3から0.4になりました。

私たちの分析

私たちの読みでは、この論文の主なメッセージは「勝者」ではなく「条件」です。どの発見にも「もし」が付いています。ウィンドウが狭いなら、モデルが弱いなら、モデルが bash に堪能なら、という具合です。単一の標準ハーネスは、これらすべてに合いません。「ハーネス A はハーネス B に勝つ」と報告する人は、モデル、予算、タスクの種類も明記するべきです。

第二のテーマは、余分な仕組みは無料ではないということです。リコールツールは仕組みを増やしましたが、モデルはほとんど使いませんでした。定義済みツールは弱いモデルを助けましたが、強いモデルには、著者の言葉で「行動選択とやり取りのオーバーヘッド」を加えたようです。一方で、結果は「単純なほど良い」とは言っていません。bash のみは 550B モデルのコストをほぼ半分にしましたが、30B モデルを大きく損ない、Mistral の SWE-Bench も損ないました。

第三の点はコストです。ドル建ての数値は、これらのモデルに対する2026年8月時点の OpenRouter の価格に依存します。計画の後にターンが減るといった向きの傾向は、ドルの値より移し替えやすいでしょう。

限界と未解決の問い

著者ら自身がいくつかの限界を述べています。結果は、彼らが作った具体的な構成要素についてのもので、普遍的に最良のハーネスを示すものではありません。計画と行動空間は T4 と128kウィンドウでのみ切り分けているため、他の組み合わせを調べるには完全な要因実験が必要です。各設定は、タスクごとに1回だけ実行されています。Terminal-Bench は89タスクしかないため、そこでの多くの比較は McNemar 検定で有意になりません。著者らはモデルと予算をまたぐ一貫した向きに頼っています。SWE-Bench Verified は Python のみです。モデルサイズは能力の不完全な代理指標であり、他のモデルファミリー、ハーネス、タスクに使う前に、交差点を検証すべきだと著者らは述べています。また、行動空間の変更には、ツールの有無、プロンプト、ファイル状態の追跡、自動診断が一緒に含まれるとも述べています。

論文の本文だけを読んだ立場から、2点を付け加えます。私たちはコードを実行せず、表も再確認していません。また、この研究は1つのオープンウェイトのファミリーと、もう1つのモデルを使っています。多くの商用コーディングツールが使うクローズドな最先端モデルについては、何も語っていません。

読者への実用的な示唆

コーディングエージェントを作るチームには、この論文からいくつかの習慣が読み取れます。巧妙な記憶機能を足す前に、長い実行がどのくらいの頻度でコンテキストの上限に当たるかを測ってください。論文は、利益の大半がオーバーフローの回避から来ると見ているからです。LLM の要約にお金を払う前に、安価なルールベースの省略を試してください。

リコールツールが使われると決めつけず、呼び出しログを確認してください。計画はモデルごとに別々に試してください。弱いモデルではコストが上がり、強いモデルでは下がることがあります。強いモデルには bash のみのインターフェースを試し、シェルが苦手なモデルには構造化ツールを残してください。最後に、モデルやコンテキスト予算を変えたときは、これらの確認をやり直してください。