HarnessOpt-Bench、エージェントハーネスの最適化をベンチマーク化――モデル選択の影響はcoding harnessの約1.8倍

エージェントの能力は重みだけで決まるものではなく、プロンプト、ツール定義、リトライ戦略、メモリ、制御フローで構成されるharnessにも左右される。8月6日に公開された[HarnessOpt-Bench](https://arxiv.org/abs/2608.06301)は、「あるモデルに別のエージェントを改善させる」ことを制約付きプログラム最適化として定義している。オプティマイザーは実行可能なharness全体を変更できるが、対象モデル、環境、検証器は変更できない。開発セットでは問題ごとの結果とトレースが提供され、検証セットでは総合スコアのみが公開される。テストセットは隔離されたサーバーで管理され、モデルが最終版を提出した後に初めて実行される。

ベンチマークはOfficeQA、BrowseComp-Plus、Terminal-Bench、GAIAを対象とし、開発分割と検証分割のそれぞれについて、完全なcase passを最大4回に制限するとともに、対象モデルのtoken数にも上限を設けている。研究ではClaude Opus 5、Claude Sonnet 5、GPT-5.6 Sol、GPT-5.6 Terra、Kimi K3を比較し、各モデルをOpenCodeとネイティブのcoding harnessでそれぞれ動作させた。111個の採点単位では、タスクとharnessを固定してモデルを変更した場合、normalized gainの平均変動は0.142だった。一方、モデルを固定してharnessを変更した場合の変動は0.079で、前者は後者の約1.8倍だった。ネイティブharnessと共通harnessを比較した20組では、共通ツールが11組、ネイティブツールが9組で勝利し、「純正の組み合わせ」が普遍的に有利だという結果は得られなかった。

結果からは、オプティマイザーの探索上のボトルネックも明らかになった。プロンプト、コンテキスト、ツールschema、検索、timeoutなど、より多くの設計レバーを操作することは、より高い改善幅と正の相関を示した。一方、完全なトレースを大量に読み込むことには、同様の関係が見られなかった。提出版の多くは、非公開テストセットにおいて、探索中に観測された最高のvalidationスコアを下回った。これは、validationのピーク値だけを報告すると、自己改善の効果を過大評価することを示している。この結果は、[Lilian Wengによるharness engineeringの整理](https://lilianweng.github.io/posts/2026-07-04-harness/)とも一致する。harnessは、単なるプロンプトテンプレートではなく、実行可能なシステム設計空間になっている。

エンジニアリングチームが今後注目すべきなのは、動的な問題、ツール動作への摂動、成熟した本番環境向けseedをベンチマークに組み込めるかどうかだ。現在のseedは、意図的に大きな改善余地を残しており、GAIAの初期状態に至っては動作すらしない。また、オプティマイザー自体の推論コストにも上限が設定されていない。そのため、このスコアを本番環境における費用対効果へ直接換算することはできない。