AIエージェントの性能を左右する「ハーネス（実行フレームワーク）」──その設計・進化をAI自身に任せる試みが、ByteDanceの研究チームによって報告された。同チームが発表したHarnessDevは、エージェントが使用するコード群（実行ループ、ツール、コンテキスト管理、状態管理、リカバリー、検証機構）を、AIモデル自らが生成し、タスクの実行結果に基づいて自律的に改善するフレームワークである。特筆すべきは、従来のベンチマーク評価が「固定されたハーネス」を前提としていたのに対し、HarnessDevは「AIが書くハーネスそのもの」を評価対象に据えた点にある。
HarnessDevとは何か──「ハーネス」を進化させるAI
AIエージェントの性能は、使用する基盤モデル（LLM）の能力だけでなく、その周辺を構成するハーネスに大きく依存する。例えば、Terminal-Bench 2.1のリーダーボードでは、同じGPT-5.5というモデルであっても、使用するハーネスによってタスク成功率が35.2%から49.6%へと変動することが確認されている。つまり、モデル本体の性能評価においても、ハーネスの質が結果を左右する重要な変数となっているのだ。
HarnessDevは、この「ハーネス」をAI自身に設計・進化させることで、モデル本来の潜在能力を最大限に引き出そうという試みである。研究はシンガポール工科デザイン大学、ジョージア工科大学、M-A-P、TokenWave.AIとの共同プロジェクトとして進められた。
2段階のプロセス──「Creation」と「Evolution」
HarnessDevのプロセスは、Creation（生成）とEvolution（進化）の2段階で構成される。
Creation：弱いシードからハーネスをゼロから構築
第一段階では、すべての生成AI（クリエイター）に、極めて弱いシードコードが与えられる。このシードには、パッシブなファイル操作、検索、プロセス実行のプリミティブと、結果・軌跡の出力機能しか含まれておらず、ループ、プランナー、検証機構、リトライ、停止ルールは一切存在しない。そのままでは、どのベンチマークでもスコアは0である。
クリエイターは、タスクファミリーの仕様書、簡単なデザインチュートリアル、1～3件の開発用ケースを基に、フルスペックのハーネスを構築する。このハーネスは、非公開タスクでテストされる前に凍結される。
Evolution：実績データに基づく反復改善
第二段階では、クリエイターは自身が生成したハーネスを出発点とし、固定された100件のSWE-bench Proタスクと89件のTerminal-Bench 2.1タスクからの実行フィードバックを用いて改訂を重ねる。各公式バージョンは、後にクリエイターが一切見ることのない630件の非公開SWE-Proインスタンスで評価される。
ハーネスの評価は、能力（タスク成功率）と効率（エグゼキュータのトークン消費量。クリエイターのトークンは除外）の両軸で行われる。
実験結果──Opus 4.8が人間設計に迫る
実験では、Opus 4.8、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4 Pro、Qwen 3.7 Max、Seed 2.0 Proの6モデルがクリエイターとしてテストされた。これらのモデルは、コード、検索、ライティング、機械学習実験という4つのドメイン、5つのベンチマーク（合計2,207インスタンス）でハーネスを生成する。
Self-Eval（各クリエイターが自身のハーネスを自身で実行）の結果、Opus 4.8が平均スコア67.8でトップに立ち、人間が設計したリファレンス（86.2）に迫る性能を示した。特に注目すべきは、コード分野でOpus 4.8がSWE-Proで69.3（リファレンスは80.0）、ライティング分野のEQ-Bench3では84.6（リファレンス83.7）と、リファレンスを上回る成果を記録した点である。
一方、検索分野（BrowseComp）では、GPT-5.5の52.6が最高であったが、リファレンスの92.2との差は大きく、この分野が最大の課題であることが明らかになった。
コード量と品質の相関、死にコードの問題
興味深い発見として、コードの量と品質にはほとんど相関がないことが挙げられる。18個のコードハーネスは合計17,111行のネットコードを追加したが、最も少ないコード（1,006行）を追加したGeminiがTerminal-Benchでトップに立った。
さらに、生成されたコードの多くが実際には実行されない「死にコード」であることも判明した。108個のコードコンポーネントのうち、実際に動作でトリガーされたのは72個で、18個は一度も起動しなかった。特に状態管理（State and memory）が脆弱で、18個中11個のハーネスがStateクラスを定義しているにもかかわらず、26,679の軌跡データ全体でチェックポイントイベントは一度も記録されなかった。ライティング分野でも、587の機能のうち124がデッドコードだった。
エグゼキュータの変更でスコアが激変
ハーネスの移植性にも大きな課題が浮かび上がった。エグゼキュータ（実行基盤）をGemini 3.1 Proに統一して評価した場合、ランキングは大きく変動した。
Qwen 3.7 MaxはBrowseCompで17.6ポイント、MLE-benchで12.9ポイントの大幅なスコアアップを記録した。一方、Opus 4.8はSWE-Proで69.3から33.0へと激減。その原因の一つは、あるハーネスが元のエグゼキュータ向けに120ステップという制限をコードにハードコードしていたためである。また、Opusの検索ハーネスでは、重複クエリ率が10.1%から88.2%に跳ね上がった。
この結果は、AIが生成したハーネスが、特定のエグゼキュータに強く最適化されているという現実を浮き彫りにしている。
進化プロセスでは2つの「勝ち」が確認
進化フェーズでは、9つの系統（5つは自己ランタイム、4つは固定Gemini）が73の公式バージョンと64の隣接スイッチを生成した。自己ランタイムで運用された5つの系統はすべて非公開タスクでスコアを向上させ、平均で+3.11ポイントの改善を達成した。中でもOpus 4.8は、100回の実行中99回が成功と報告されながら実際の合格が48回にとどまる「早すぎる完了」問題を特定し、完了ゲートを追加するという的確な修正を行った。
しかし、進化は決して単調な改善の連続ではなかった。64のスイッチのうち、8は両方のベンチマークでスコアを後退させ、16は片方で後退した。フィードバックスコアと非公開タスクのスコアが同じ方向に動いたのは、わずか34回（53.1%）に過ぎなかった。
実用化への課題と今後の展望
HarnessDevの成果は、AIエージェントの性能を最大化するための新しいアプローチを提示するものだ。しかし同時に、いくつかの重要な課題も明らかになった。
第一に、状態管理の脆弱性。多くのハーネスが状態管理機構を定義しながら、実際の運用ではまったく活用されていない。これは、複雑なマルチステップタスクにおける信頼性向上のための重要な改善ポイントとなる。
第二に、エグゼキュータ依存性。生成されたハーネスが特定の実行基盤に強く依存する傾向があり、移植性に課題がある。
第三に、デッドコードの多発。AIが生成するコードのかなりの部分が、実際のタスク実行において無駄となっている。
これらの課題は、AIによるコード生成の自動化がまだ発展途上にあることを示している。しかし、人間の設計に迫るスコアを叩き出したOpus 4.8の成果や、Self-Evalで人間のリファレンスを超えたEQ-Bench3の結果は、この分野に大きな可能性があることを示唆している。HarnessDevは、AIエージェントの開発プロセスそのものをAIに委ねるという、パラダイムシフトの第一歩と言えるだろう。
