Doc2Harness、LLMのコーディングエージェント用Harness構築力を評価

背景

コーディングエージェントの評価では、あらかじめ用意されたHarnessの中で、モデルがバグ修正やファイル編集を完了できるかを測る方法が一般的だった。しかし実運用での成否は、モデルだけでなく、プロンプトの組み立て、ツール呼び出し、ワークスペース、プロセス、実行結果を管理するHarnessにも左右される。Doc2Harnessは、この周辺ソフトウェアをモデル自身が構築できるかという、これまで十分に切り出されていなかった能力を評価する。

評価方法

ベンチマークは二段階で構成される。第1段階では、構築用の固定Harness内でビルドモデルを動かす。モデルには、インターフェースだけを示した契約の骨格と、12種類の先端Harnessの振る舞いをまとめた開発文書が与えられ、完全な候補Harnessを隔離コンテナ内で実装する。

第2段階では、その候補を凍結し、構築環境とは別のコンテナで実行する。テストケースごとに独立したコンテナを用意し、スクリプト化されたモックモデルがエンドツーエンドでHarnessを操作する。これにより、構築時の環境が評価結果を不当に助ける可能性を抑え、再現性を高めている。

採点対象は、モデルへ送られたリクエスト、ディスク上のファイル、プロセスの終了コード、コマンド出力という四つの観測可能な経路だ。さらにポジティブコントロールを使い、実質的な処理をしていない実装が偶然合格することも防ぐ。

結果と示唆

19の先端モデルを対象に、それぞれ3回の独立した構築を行い、328テストケースで評価した。GPT-6 Astraの通過率は53.05%で最高だった一方、最低のモデルは27.44%だった。差はおよそ26ポイントに達する。ただし、より重要なのは、最高のモデルでさえ半数近くのテストに失敗した点である。

失敗は単純なコード生成の誤りだけに集中していない。複数の機能に関係する処理をどのモジュールへ分割し、長い実行中も状態やツール、ファイル変更、モデルとの通信を一貫させるかという設計で問題が生じた。局所的には正しい実装でも、システム全体の連携で破綻するという構図だ。

Doc2Harnessの意義は、長期実行エージェントの能力を、モデル単体の生成品質だけで捉えない点にある。固定された環境でタスクを達成できるモデルが、契約と仕様から信頼できる実行基盤まで設計できるとは限らない。今後、エージェントが継続的に実ワークスペースを変更するなら、明確なモジュール契約、状態管理、エンドツーエンド検証が重要になる。このベンチマークは、その構造的な弱点を比較可能な形で可視化する。

出典：Hugging Face Daily Papers