T4を含むコーディングエージェントのハーネス設計を分解検証

コーディングエージェントは、LLMが一度答えて終わる仕組みではない。課題を読み、ファイルを調べ、変更し、結果を確認する反復を続ける。その過程で、現在の計画を毎回見せるか、どんな操作手段を公開するか、増え続ける履歴をどう整理するかが結果に影響する。

たとえば、業務システムの不具合をリポジトリ内で直す場面を考える。エージェントは関連コードを探し、修正し、確認結果を読んで次の行動を決める。途中の検索結果や実行出力をすべて残せば、やがてコンテキスト窓を圧迫する。一方、古い情報を削りすぎれば、必要な手掛かりを失う恐れがある。計画やツールも同様に、助けになる場合と余分な負担になる場合がある。

この例は三要素の役割を示すためのものだ。本研究が測ったのは実際の企業開発ではなく、二つのベンチマーク上の成否とコストである。現場での保守性や導入効果まで示すものではない。

従来のように統合済みのエージェントを丸ごと比べると、成績差をどの部品へ帰属すべきか分からない。優れたモデルを使ったからなのか、計画の与え方がよかったのか、ツールが適していたのか、単に履歴切れを避けられたのかが混ざるからだ。先行研究には、統合ハーネス全体の比較や、単一モデルで一部だけを外す評価が多く、長いコーディング作業について三要素と明示的な窓予算を共通基盤で比べる証拠が不足していた。

著者らは軽量なReAct型の実行ループを固定した。これは、モデルの判断、外部操作、その結果の観察を交互に繰り返す方式である。そのうえで、計画、操作空間、コンテキスト管理だけを変更した。比較対象以外をそろえた「対応条件」を作ることで、完成品の順位ではなく、部品の条件付き効果を見ようとした。

第一は計画である。計画ありの条件では、最初に計画を作らせ、外部に保存された進行状態を更新し、各ターンで現在の計画を再び見せる。計画なしでは、計画を求める指示だけでなく、更新手段、再注入、注意書きもまとめて除く。そのため、比較しているのは単なる計画文の有無ではなく、計画を維持する仕組み一式である。

第二は操作空間である。ファイル閲覧、検索、変更、実行、Web操作などの型付きツールを与える構成と、文字によるシェル操作へ集約するbash-onlyを比べる。ただし、定義済みツール側では専用指示、ファイル状態の追跡、編集後の自動診断も変わる。結果を「ツール数だけの効果」とは読めない。

第三はコンテキスト管理である。何もしないT0、省略するT1、省略した内容を再取得できるT2、古い履歴を要約するT3、これらを段階的に組み合わせるT4の五方式を比較した。

T4の中心は、すぐ要約するのではなく、まず規則で減らす順序にある。履歴が一つ目の境界を超えると、中間部分にある大きなツール出力を短い印へ置き換え、元の内容は外部へ保存する。それでも二つ目の境界を超える場合に限り、古い中間イベントを同じ評価モデルの別呼び出しで要約する。最初の指示と少なくとも直近2ターンは元の文面のまま残す。

先の不具合修正でいえば、大量の検索結果や実行ログは「ここに保存済み」と分かる短い記録へ替える。それでも作業記録が長ければ、古い調査経緯を要約する。現在の指示と直近の作業は削らない。T2では省略した内容を再取得でき、T4にもこの機構が含まれる。ただし、取得可能であることと、モデルが実際に取りに戻ることは別問題である。

評価対象はNemotron-3の30B、120B、550BとMistral-Medium-3.5-128Bである。課題はSWE-Bench Verifiedの500件とTerminal-Bench 2.1の89件を使った。前者はPythonに限られ、後者はコマンドライン中心の課題である。

コンテキスト管理は32k、64k、96k、128kの四予算で比較した。この比較では計画ありと定義済みツールを固定した。計画と操作空間のアブレーションは、計算資源の制約からT4・128kだけで実施した。全要素の全組み合わせを試す完全要因実験ではない。合計は176の対応条件だが、各設定と各タスクの組み合わせは1回だけ実行された。

主要な物差しは成功率とタスク当たり平均コストである。コンテキスト管理では窓超過も調べ、成功率差が履歴切れの回避と対応するかを確認した。同じタスクにおける二条件の成否には、両側の正確McNemar検定を用いた。多数の比較から偶然の「差あり」を拾いすぎないよう、Benjamini–Hochberg法で偽発見率を0.05に制御した。

対応比較は課題ごとの難易度差を抑えられる。一方、各タスク1回なので、同じ設定を繰り返した場合の確率的な揺れは推定できない。特にTerminal-Benchは89件で、多くの対比が補正後に統計的有意とはならなかった。数値の大小がそのまま再現性の高い順位を意味するわけではない。

著者らは最終成否だけでなく、課題開始から終了までの判断と操作の記録である「軌跡」もLLM判定器で分析した。計画がどこで実行を止めるか、操作空間がどの細かさでコードを書くか、コンテキスト管理が行動そのものを変えるかを調べるためである。

判定器は200軌跡、計15,610のラベル単位について、3人の人間注釈者による非重複の分割と照合された。著者らの報告では、分割別の単純一致率は88.7%から98.4%、偶然一致を補正するCohenのκは0.858から0.980だった。統合一致率は約94.2%、加重平均κは0.929である。これは軌跡ラベルの整合性を支えるが、主要な成功率やコストを独立した研究者が再現した証拠ではない。

著者らの報告では、管理ありのT1からT4と無管理のT0との平均成功率差は、窓予算が広がるほど縮小した。SWE-Benchでは32k、64k、96k、128kの順に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%へ下がった。管理ありの各方式では全予算で窓超過が0件だった。軌跡分析も踏まえ、著者らは、管理がエージェントの行動方針を大幅に賢くしたというより、履歴切れによる終了を防ぎ、作業を続けられるようにしたと解釈している。窓が広いほど差が小さいことも、この説明と整合する。

T4はT1からT3と同程度の成功率を保ちながら、4モデルと2ベンチマークからなる8パネルのうち7パネルで最小コストだった。32kから128kまで、それぞれの窓予算について8組を平均した場合も、タスク当たり平均コストはT4が最小だった。これはT4が常に最高の成功率だったという主張ではない。規則による省略を先に行い、必要な場合だけLLM要約を使う順序が、成功率と費用の均衡に結びついたという結果である。

一方、省略内容を再取得できるT2は、省略だけのT1に対する一貫した改善を示さなかった。32比較で15勝14敗3分、平均成功率差はマイナス0.36ポイントだった。再取得可能な64設定中36設定では一度も呼び出されず、平均呼び出し回数も32kの0.540回から、64k、96k、128kでは0.069、0.011、0.007回へ低下した。回収機構を用意しても、モデルがほとんど使わないなら追加の仕組みは精度に結びつかない。

計画は最も小さいNemotron-3 30Bで成功率の足場になった。計画ありではSWE-Benchが13.6%から25.2%へ11.6ポイント、Terminal-Benchが8.99%から13.48%へ約4.5ポイント上昇した。一方、Nemotron-3 550BとMistralでは、SWE-Benchのコストがそれぞれ約30%、32%下がったものの、成功率は2.0ポイント、0.4ポイント低下した。強いモデルでは、計画は精度を上げるより、軌跡の停止位置を変えて費用を抑えた可能性がある。

操作空間も条件依存だった。30Bでは定義済みツールがbash-onlyより、SWE-Benchで15.0ポイント、Terminal-Benchで10.1ポイント高い成功率だった。550Bでは逆にbash-onlyが3.6ポイント、5.6ポイント高く、コストも53%、30%低かった。Mistralでは、定義済みツールがSWE-Benchで23.2ポイント高い一方、Terminal-Benchではbash-onlyが6.7ポイント高かった。モデル規模だけでなく、学習内容、ツールへの事前曝露、shell習熟度、課題の性質が影響し得る。

結果が直接支えるのは、有限のコンテキスト窓で長いコーディング課題を扱い、候補構成を対象モデルとタスク上で比較する場面である。成功率だけでなく、コスト、窓超過、停止位置、操作粒度も見る設計判断には有用な枠組みとなる。

ただし対象は4モデルと2ベンチマークに限られ、SWE-Bench VerifiedはPythonだけである。計画と操作空間はT4・128kでしか比較されておらず、短い窓や別の管理方式との相互作用は分からない。操作空間ではツール、専用指示、状態追跡、編集後診断が一緒に変わるため、どの成分が効いたかを分離できない。各タスク1回という設計も、成功率とコストの分散を示さない。

次に見るべき証拠は、全窓予算と管理方式を含む組み合わせ評価、同じタスクの反復実行、操作空間の各成分を個別に変える比較、未評価モデルや別言語での再検証である。実運用上の信頼性や導入後の成果も、この研究だけからは判断できない。Hugging Face上の反応は関心の現在値ではあっても、技術的な再現証拠ではない。