HarnessOpt-Bench、モデルによるエージェント・ハーネスの書き換えを評価——モデル選択の影響はコーディングツールの約1.8倍

エージェントの能力はモデルの重みだけでなく、その外側を構成するプロンプト、ツール定義、メモリ、リトライ戦略、制御フローにも左右される。Scale AIが発表したHarnessOpt-Benchは、この「ハーネス・エンジニアリング」をエンドツーエンドの評価へと落とし込んだ。最適化モデルには、初期エージェントプログラム、開発用ケースごとの実行トレース、検証セットの総合スコア、固定された評価予算が与えられ、コードを直接追加・削除できる。最終的に提出できる候補バージョンは1つだけで、隔離された信頼できる実行環境が非公開テストセットを用いて採点する。

ベンチマークはOfficeQA、BrowseComp-Plus、Terminal-Bench、GAIAを対象とし、5つのフロンティアモデルを、共通のOpenCode、およびClaude Code、Codex、Kimi CLIなどのネイティブツールとそれぞれ組み合わせ、合計111回の採点実行を行った。スコアには「正規化ゲイン」を採用し、新しいハーネスが初期バージョンに残されていた改善余地のうち、どの程度を獲得したかを測定する。タスクとハーネスを固定した場合、最適化モデルを変更するとスコアは平均0.142変動した。一方、モデルとタスクを固定してコーディングハーネスを変更した場合の平均変動は0.079で、前者は後者の約1.8倍だった。最も強力な組み合わせは、OfficeQAで残された改善余地の約3分の2、BrowseComp-Plusで約半分を獲得したが、中位モデル間の差は再実行時のばらつきより小さいことが多かった。

探索トレースからは、実務上の問題も明らかになった。プロンプト、コンテキスト、最大ステップ数、ツールスキーマ、検索戦略など、より多くの調整手段に手を加えることは、テストでの改善幅の大きさと正の相関を示した。しかし、完全な失敗トレースが要求されたのは、111の実験単位のうちわずか16件だった。検証セットで得られた最高スコアの多くは非公開テストセットで再現できず、エージェントに同じ評価を繰り返し見せると、選択バイアスを真の進歩と取り違えやすいことを示している。

エンジニアリングチームは、隔離テスト、リソース計測、バージョン保存という設計を応用し、監査可能なエージェント最適化プロセスを構築できる。ただし、各組み合わせの再実行は2回に限られ、最適化モデル自体の推論予算にも上限が設定されていない。現時点の結果は探索行動の比較には適しているものの、固定コスト下における本番環境での効果へ直接換算することはできない。