In Silico

AI・信頼性・評価

ハーネス設定で修復率はどこまで変わる？AGENTS.mdの効果も検証

2026/9/6 （更新: 2026/10/19）

🤖 AIを使用して執筆

  • ハーネス
  • コーディングエージェント
  • AIエージェント
  • SWE-bench Verified
  • SWE-bench Pro
  • FeatureBench
  • AGENTS.md
  • CLAUDE.md
  • Claude Code
  • Codex CLI
  • context editing
  • コンテキストウィンドウ
  • コンテキストファイル
  • 設定パッケージ
  • ツール出力
  • fail-to-pass率
  • 完全解
  • コンパクション
  • 四ビット量子化
  • プロンプトトークン
  • 推論費用
  • 実行時間
  • 査読前
  • リポジトリ
  • ベンチマーク
目次
背景・問い・要点
背景

コーディングエージェントを動かすとき、働いているのはモデルだけではない。モデルの外側には、何を見せるか、どのツールを呼び出させるか、記録が長くなったら何を捨てるかを決めるソフトウェアが挟まっている。この外側の一式をハーネス（モデルを包んで実際の作業に当たらせる足場）と呼ぶ。同じモデルでもハーネスの組み方は何通りもあるのに、成績の報告で前へ出るのはモデルの名前のほうで、報告する側はハーネスを実装の細部として扱ってきた。

ハーネスが記録の扱いを決めなければならないのは、モデルが一度に読める量に上限があるからである。モデルは文章をトークンと呼ぶ短い断片の列として読み、量もトークンの数で数える。一度に読める量の上限をコンテキストウィンドウと呼ぶ。エージェントが読んだファイルの中身や検索結果、テストの出力（まとめてツール出力と呼ぶ）は記録として積まれていき、作業が長くなるとこの上限に近づく1。

ハーネスの設定には、記録の扱いを決める規則のほかに、エージェントへ渡す手引きもある。AGENTS.md や CLAUDE.md は、リポジトリに置いておき、そのリポジトリでの作業の指示や概要を書いてエージェントに読ませるファイルで、まとめてコンテキストファイルと呼ぶ2。

成績は、テストの付いたコード修正の課題を集めたベンチマークで測る。ここで修復率と呼ぶのは、エージェントが手を入れる前に落ちていたテストのうち、手を入れたあとに通るものの割合で、原典の fail-to-pass率に当たる1。

細部として扱うと、成績の数字がどれだけハーネスの設計に依存しているかが見えなくなる。ハーネスをいじって成績が動いたとしても、それがどんな条件でも起こるのか、特定の条件でしか起こらないのかも分からないままになる。

問い

ハーネスのどの設定が、どの条件のもとで、コーディングエージェントの成績を動かすのか。

要点

古いツール出力を自動で詰める規則を含む、三つの規則を束ねた設定パッケージを入れると、コンテキストウィンドウをもっとも狭くした条件で修復率が28%から49%へ動いた。各規則の効果は切り分けられていない。 著者一人による査読前の論文（プレプリント）が、モデルと課題を固定し、ハーネスの構成だけを二通りに分けて比べた結果である1。コンテキストウィンドウが狭いほど成績が良いのではなく、パッケージによる改善の幅が、課題で読む量に比べてコンテキストウィンドウが狭い条件ほど大きかった。コンテキストウィンドウが広めでも課題の要求が重い条件ではやはり動き、コンテキストウィンドウにも課題の要求にも余裕がある条件では、三つのベンチマークのうち二つで修復率の差がほぼ出ず、残る一つは課題ごとに数えるかリポジトリごとにまとめて数えるかで、差が有意かどうかの判定が割れた1。別の設定である、リポジトリに置くコンテキストファイルは、著者の異なる二本の検証で、正しく直せた課題の割合をほとんど動かさなかった23。したがって「ハーネスは効くか」への答えは一つではなく、どの設定が・どの条件で効くかを分けて読む必要がある。

モデル・例示

読み終える前にコンテキストウィンドウが埋まると、修正は始まらない

※ この節の例は、説明のために作った架空のものです。

古いツール出力を詰める規則があると、修正を書く前に読む量がコンテキストウィンドウを超える課題でも、エージェントは読み終えて修正に入れる。一つのバグを、規則の有無とコンテキストウィンドウの大きさを変えた三通りで追うと、規則が差を生む境目が数で見える。

手元にバグが一つあり、コーディングエージェントにそれを直させるとする。最初の修正を書く前に、エージェントは関係するファイルの中身・検索結果・テストの出力を読む。ここでは、そうしたツール出力が1件3,000トークンで10件、合わせて30,000トークン要るとする。計算を簡単にするため、課題の文やモデル自身の書いた文は数えず、コンテキストウィンドウが埋まったらそこで作業が止まるものとする。

コンテキストウィンドウを20,000トークンとする。ツール出力をそのまま残すハーネスでは、7件目を読んだあたりでコンテキストウィンドウが埋まり、エージェントは修正を1行も書かないまま止まる。6件で18,000トークン、7件目を足すと21,000トークンになるからである。修正に入れないので、この課題で直るテストは0本である。

同じコンテキストウィンドウで、古いツール出力を詰めるハーネスを使う。詰めるとは、出力の中身を機械的に短く切ることである1。新しい出力を読むたびに直近の3件はそのまま残し、それより古いものを1件300トークンに詰める。10件を読み終えた時点では、古い7件が詰められていて、コンテキストウィンドウに入るのは9,000+2,100=11,1009{,}000 + 2{,}100 = 11{,}100トークンで、20,000に収まる。エージェントは10件を読み終えて修正に入れる。ただし、詰めた出力から修正の手掛かりが落ちることもありうるので、この例が示すのは修正に入れるかどうかまでで、修正が正しいかどうかではない。

コンテキストウィンドウを100,000トークンにすると、どちらのハーネスでも30,000トークンを読み終えられるので、詰める規則があってもなくても修正に入れる。

三通りのコンテキストウィンドウと規則の組を並べると、詰める規則がいつ差を生むかが見えてくる。

  1. 詰める規則が効くのは、修正の前に読む量がコンテキストウィンドウを超える課題である。
  2. コンテキストウィンドウが読む量を上回っていれば、詰めても詰めなくても修正に入れるので、差は出にくい。
  3. 効き目を分けるのはコンテキストウィンドウの絶対値ではなく、読む量に対するコンテキストウィンドウの大きさである。

実験：何を比べたか

まず事実だけを並べる。

走行は各群1本ずつで、原典は実行ごとのばらつきを測っていない。原典が検証したのは四ビット量子化した公開重みなので、高精度の重みやホスト型のフロンティアモデルで同じ差が出るかも確かめていない1。

結果：コンテキストが苦しい条件ほど、大きく動いた

まとめるとこうなる。効き幅は一様ではなく、コンテキストウィンドウが狭くて情報が溢れる条件ほど大きい。 余裕のあるコンテキストウィンドウのVerifiedでは精度の差はほぼ出ず、動いたのは投入量のほうだった。処置側は1ターンあたりのプロンプトトークンが7.2%少ない（1課題あたりでは差が検出されていない）1。一方で、コンテキストウィンドウが49,152トークンあっても課題側の要求が重いProの圧力条件では大きく動いている。効き目を分けているのはコンテキストウィンドウの絶対値そのものではなく、課題が要るコンテキスト量に対してコンテキストウィンドウが足りているかどうかだと読むと、Verified と Pro の結果はつながる。

この条件は、原典が機序として測った「読み終える前にコンテキストウィンドウが埋まる」境界に当たる1。この境界は狭いコンテキストウィンドウの Verified で、処置を入れるとコンテキストウィンドウの0.71倍から1.81倍へ伸びている（課題が要るコンテキスト量をコンテキストウィンドウで割った比で、走行の半数が最初の修正の前に止まる点）1。ただしコンテキストウィンドウに余裕がある FeatureBench では、原典のコンテキストウィンドウ到達率が1%未満なのに、平均 fail-to-pass 率が 23.9% から 30.7% へ動いている1。この機序だけでは説明がつかない。もっとも、この比較は以前の実施期に固めた処置パッケージと、後で修正した統制を組み合わせたものだと原典が断っている1。

ただし28%→49%の中身は、テストを多く直したことより、採点できる記録を最後まで出せたことに近い。狭いコンテキストウィンドウの統制側では、課題の62%でfail-to-pass率の分母が得られず、採点規約によりそれらの課題にゼロが与えられている1。処置側はこの比較でプロンプトトークンを2.1倍、実行時間を3.5倍使っており、効率の比較ではない1。コンテキストウィンドウごとの比較にも条件が付く。原典自身が、実施時期が違い処置の版も一部違うため、コンテキストウィンドウの大きさと実施時期は切り分けられないと断っている1。

別の設定：コンテキストファイルは精度を動かさなかった

ハーネスの設定はコンテキストの詰め方に限らない。AGENTS.md や CLAUDE.md のようなコンテキストファイルをリポジトリ直下へ置くやり方も、エージェントの開発元が強く勧めてきた設定である2。

コンテキストを詰める規則を含む設定パッケージとコンテキストファイルは、同じ「ハーネス」の下にあるが、手を当てている場所が違う。片方はある条件で効き、片方は精度を動かさなかった。これは矛盾ではなく、「ハーネスは効くか」という問いのほうが粗すぎるということである。 ただし二つの結果は別のモデル群で測られている。パッケージの効果は四ビット量子化でローカル配信した公開重みのモデルで得られ1、コンテキストファイルの結果は主に Claude や GPT のホスト型モデルで得られている（一本目はローカル配信の Qwen3-30B-Coder も含む）23。同じモデルの上で二つの設定を比べた報告は、ここで引いた四本の中に無い。

出典5件

  1. Lewis「Same Model, Different Harness: Different Coding-Agent Results」arXiv, 2026（査読前・単著）. https://arxiv.org/abs/2608.26218 — モデルと課題を固定し、ハーネスの構成だけを変えて三つのベンチマークで比べた。課題別の結果: https://github.com/sydches/yuj ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24

  2. Gloaguen ほか「Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?」ICLR 2026 併設ワークショップ. https://arxiv.org/abs/2602.11988 — コンテキストファイルは成功率を概して上げず、推論費用を増やした。採択: https://openreview.net/forum?id=pLi3A8bscP ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  3. Khatri「Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories」arXiv, 2026（査読前）. https://arxiv.org/abs/2607.27250 — 3リポジトリ・2エージェントでコンテキストの届け方を変え、正答性は動かなかった。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Anthropic「Managing context on the Claude Developer Platform」2025. https://www.anthropic.com/news/context-management — コンテキストウィンドウの上限に近づくと古いツール呼び出しと結果を消す context editing を、公開ベータとして発表した。 ↩

  5. Lulla ほか「On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents」JAWs 2026（ICSE 併設ワークショップの短報）. https://arxiv.org/abs/2601.20404 — Codex 1種で効率を測った。正確さは範囲外。採択: https://conf.researchr.org/home/icse-2026/jaws-2026 ↩ ↩2

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。