コーディングエージェント向けの高額な「ハーネス」（開発フレームワーク）は、低価格な選択肢と比較して性能が向上するどころか、コストは最大3倍に達するにもかかわらず、合格率に有意な差は見られない——。中国の研究者らが発表した論文が、AIエージェント開発の現場に一石を投じている。
コーディングエージェントのハーネスとは、AIモデルにツール群やシステムプロンプト、コンテキスト管理機能を提供し、コード生成や修正を支援する枠組みのこと。AnthropicのClaude Codeや、オープンソースのOpenCode、軽量設計のmini-SWE-agentなどが代表的だ。各社は自社ハーネスの優位性をアピールするが、今回の研究はその主張の多くが統計的なノイズに過ぎない可能性を指摘している。
従来の性能差20ポイント超は「測定ノイズ」だった
先行研究では、ハーネス間の性能差が20ポイント以上に達するとの報告が相次いだ。しかし論文著者のLiu氏とHan氏によれば、これらの数値はほぼすべてが1回の実行結果に基づいているという。実際、同一設定を再実行するだけでSWE-bench Verifiedのスコアは最大6ポイント変動する。例えばZhipu AIは自社ハーネスがClaude Codeを2.4ポイント上回ると宣伝しているが、この差もノイズの範囲内に収まる。さらに、ハーネスごとにベンチマークへの接続方法が異なるため、比較の信頼性はさらに低下している。
オフライン検証の衝撃——Webアクセスが隠していた真実
研究チームは5つのモデル（Qwen3.6、Qwen3.8、Deepseek-V4-Flash、GLM-5.3-Flash、HY4-Preview）を3種類のハーネスでテスト。さらにClaude Opus 5をClaude Codeのみで参照用に実行した。テストにはSWE-bench Verifiedから選んだ難易度の高い45タスクと、追加の447タスクを使用。複数の設定で2回ずつ実行し、ノイズの大きさを測定できるようにした。
ここで重要なのは、すべての実行をオフラインで行った点だ。初期テストでWebアクセスを許可したところ、DeepseekとQwenのモデルは71%のケースでGitHubから正解を直接取得してしまい、本来の課題解決能力を測れなかった。Claudeモデルではこの現象はほぼ発生せず、研究チームはデータセットへの学習の有無は断言できないとしつつも、以降の全実行でWebアクセスを遮断した。
ハーネスを交換しても結果は「再実行」と同じ変動幅
447タスクの大規模プールでは、最も重いClaude Codeと最も軽いmini-SWE-agentの差は2ポイント未満。いずれのモデルでも、スコアは5ポイント以内の帯に収まり、統計的に同等である。
研究チームは難易度の高い45タスクで最大のハーネス効果が現れると予想したが、結果は異なった。ハーネス間の差はモデルあたり2〜5タスクの解答案の違いに過ぎず、同一設定の再実行でも最大3タスクの変動が生じる。mini-SWE-agentがリードするケースもあれば、Claude Codeが勝つケースもあり、一貫性は見られない。
フリップ率（同一タスクで結果が反転する割合）も同じ傾向を示す。同一ハーネスの再実行では中央値13%のタスクで結果が変わるが、異なるハーネス間でも同じ13%。モデルを交換した場合は22%に跳ね上がる。特定のハーネスが得意とするタスクは実行ごとにランダムに変わり、コイントスに等しい。著者らは「ハーネスの差は、同じノイズを新たに引き直したようなもの」と表現する。
OpenCodeだけが低迷——原因は出力制限
唯一測定可能なハーネス効果は、OpenCodeの一貫した劣勢だ。大規模タスクプールでは他の2つに最大9ポイントの差をつけられる。この差の約半分は出力トークン制限に起因する。モデルが推論途中でこの制限を超えた場合、Claude Codeは継続を促すプロンプトを送るが、OpenCodeはそこで処理を終了させ、試行は失敗に終わる。OpenCodeに継続プロンプトを追加しても効果はなく、同じタスクでも再実行時に同じ制限超過が発生するとは限らないためだ。
残りの差について著者らは明確な説明を持たないが、OpenCodeではモデルがはるかに早い段階で動作を停止する傾向があると指摘する。ローカル実行ではOpenCodeの時間制限がClaude Codeよりはるかに厳しく、これは統制されていない変数だとしている。一方、mini-SWE-agentはコンテキスト管理機能を欠くため、コンテキストウィンドウ超過が発生するが、他のハーネスでも失敗するタスクに限られる。
コスト3倍の原因はシステムプロンプトにあった
同じモデル、同じタスク、同じ料金体系でも、1タスクあたりのコストはハーネスによって最大3倍に達する。ツールの出力量に大きな差はないため、コスト差の実態はシステムプロンプトとツール定義にある。これらは各ステップで再送信され、Claude Codeでは約16,600トークン、OpenCodeで約7,000トークン、mini-SWE-agentで1,000トークン未満だ。さらにClaude Codeはモデルの推論出力を会話履歴に保持する仕様で、これもコストを押し上げる。
システムプロンプトのサイズがベースコストを決定し、ステップ数がそれを増幅する。どちらの要因が支配的かはモデル次第で、GLM-5.3-FlashではClaude Codeがmini-SWE-agentのほぼ2倍のコストになる一方、Deepseek-V4-Flashではmini-SWE-agentのステップ数が多いため両者は均衡する。キャッシュトークンの割引で差は縮まるが、順位は変わらない。
ホームグラウンドアドバンテージは存在せず
Deepseekの自社ハーネスは同社モデルでも他ハーネスと同等のスコアしか出せず、しかも最も高コストだった。Claude Codeからツールを削除してもOpus 5の結果は変わらず、1年前の旧バージョン（Extended Thinkingがデフォルトでオフ）が半分以下のコストで同等のタスク数を達成した。
思考（Thinking）の有無が唯一、ハーネス選択が結果に影響したケースだ。Qwen3.6でmini-SWE-agentを使用した場合、思考をオフにすると11ポイント低下したが、Claude CodeとOpenCodeではノイズの範囲内にとどまった。HY4-PreviewもClaude Codeで思考をオフにすると11ポイント低下する。ハーネスとモデルの組み合わせによって思考への依存度が異なることは確認されたが、その理由を説明できるだけのテスト規模ではないと著者らは認めている。
「ハーネスが買うのは合格率ではなく、請求書」
研究は主にSWE-bench Verifiedに依存しているが、Terminal-Bench 2.1でのクロスチェックでも同じパターンが確認された。著者らは「ハーネスが買うのは、タスクを落とす方法の減少と、請求書であって、合格率ではない」と結論づける。その上で、ハーネス比較の際には同一設定の再実行結果を併記することを推奨している。測定された差のうち、どれだけが単なるノイズなのかを判断する唯一の方法だからだ。
ハーネスへの過剰な投資が報われない傾向は他の研究でも確認されている。シンプルなMarkdownファイルが複雑なスキルシステムを凌駕したケースや、フレームワークの選択だけで同一モデルのコストが3倍近く変動した事例が報告されている。NVIDIAも最近、エージェントのステアリング最適化によりコーディングエージェントのトークンコストを半減させる技術を発表しており、業界全体がハーネス設計の効率化に向けて動き出している。今回の研究は、その流れに統計的な裏付けを与えるものと言えるだろう。データと分析スクリプトはGitHubで公開されている。
