精緻なAIエージェントハーネス、性能を向上させずトークンコストのみを3倍に跳ね上げるとの研究結果

AI開発ツールのベンダー各社は、高度なエージェントハーネスの採用によってコーディングベンチマークのスコアが大幅に向上すると頻繁にアピールしている。しかし、「What does a harness buy? Mostly tokens.（ハーネスは何をもたらすのか？ 主にトークン消費だ）」と題された最近の実証研究によって、複雑なハーネスがもたらすのは実質的な性能向上ではなく、大半がトークン請求額の膨張にすぎない実態が明らかになった。

山東大学の研究者Liu氏とHan氏が実施したこの研究では、大規模言語モデル（LLM）がコードリポジトリを探索・編集できるようにするシステムプロンプト、専用ツール、コンテキスト管理レイヤーなどで構成される「エージェントハーネス」の実際の影響を測定した。その結果、フレームワークを変更しても、まったく同一の構成を2回実行した場合と同程度しかベンチマークの成功率が変わらないにもかかわらず、推論コストは最大300％も増加することが判明した。

進歩ではなく「ノイズ」を測定している実態

従来のベンチマーク結果やベンダー側の主張では、異なるエージェントフレームワーク間で20ポイント以上の差があると報告されるケースが珍しくない。研究者らによれば、こうした主張のほぼすべてが単一のベンチマーク実行（1回限りの測定）に依存しているという。

SWE-bench Verifiedでは、まったく同じセットアップを複数回実行するだけでも、純粋な測定ノイズによって最大6ポイントのスコアのブレが自然に生じ得る。たとえば、Zhipu AIは自社独自のハーネスがClaude Codeに対して2.4ポイント優位であると主張していたが、この差は再実行による想定分散の範囲内に完全に収まるレベルだ。さらに、ベンダーごとにベンチマークの統合手法が異なるため、リーダーボード上での直接比較は信頼性に欠けるという。

ハーネス固有の影響を特定するため、研究者らは提供済みの3つのフレームワーク上で5つのモデルを評価した。

• Claude Code: 専用のファイルツールや検索ツール、自動履歴圧縮機能を備え、ツール定義を含むシステムプロンプトの合計は約1万6,600トークンに達する。

• OpenCode: 専用ツールを備え、初期プロンプトのオーバーヘッドは約7,000トークン。

• mini-SWE-agent: 標準のBashツールのみを提供し、コンテキスト管理機能はなく、システムプロンプトが1,000トークン未満という最小限の構成。

評価対象モデルにはQwen3.6、Qwen3.8、Deepseek-V4-Flash、GLM-5.3-Flash、HY4-Previewが含まれ、Claude Code内ではリファレンスとしてClaude Opus 5もテストされた。評価はSWE-bench Verifiedの最難関タスク45件と、拡張された447件のタスクプールを対象に行われ、Terminal-Bench 2.1によるクロスチェックも実施された。

すべての評価は完全にオフラインで実施された。インターネットアクセスを有効にした初期テストでは、DeepseekおよびQwenモデルによる試行の71％が、問題を自律的に解決するのではなくGitHubから修正コードを直接取得していた。著者らはテストデータによる学習を主張してはいないものの、ベンチマークの整合性を維持するためにWebアクセスは恒久的に無効化された。

ハーネスの変更は「コイントス」と同義

447件のタスクからなる大規模サンプルにおいて、最も重厚なハーネスであるClaude Codeと、最も軽量なmini-SWE-agentは、テストされたすべてのモデルにおいて互いに2ポイント以内の差にとどまった。これは5ポイントの信頼区間内では統計的に区別がつかないレベルである。

個々の問題の結果を分析すると、以下の傾向が判明した。

• 同一セットアップの再実行により、タスクの中央値で13％の結果が反転した（成否が入れ替わった）。

• ハーネスの変更でも、まったく同じ13％のタスクで結果が反転した。

• 基盤モデルの変更では、22％のタスクで結果が変動した。

最難関の45タスクにおいて、フレームワーク間の差はモデルあたりわずか2〜5タスクの解決数の差にとどまり、同一構成の再実行でも最大3タスクの変動が生じた。著者らは、ハーネス間の性能分散について、「同じノイズを新たに引き直しているようなもの」と表現している。

447件のタスクプールにおいて統計的に有意な低下を示した唯一のフレームワークはOpenCodeであり、他より最大9ポイント遅れをとった。研究者らによると、この差の約半分は出力制限への対処方法に起因していた。推論の途中でモデルが出力上限に達した際、Claude Codeは継続を促すプロンプトを出すのに対し、OpenCodeはそのステップを終了させてしまい、結果としてタスク失敗につながっていた。さらにOpenCodeは、ローカルモデルに対する時間制限が厳しい点や、初期のバイナリダウンロード試行によってオフライン環境下で検索ツールが動作しなくなる問題も抱えていた。

システムプロンプトにかかるコスト

合格率がほぼ横ばいにとどまる一方で、トークン消費量には大きな開きが生じた。ハーネスは対話の各ステップでシステムプロンプトやツール定義を再送信するため、初期プロンプトの長さがベースラインコストを決定づける。

• Claude Code: ステップごとに約1万6,600トークンのシステム指示とツールスキーマを再送信し、会話履歴内の思考ログ（推論トレース）も保持する。

• OpenCode: ステップごとに約7,000トークンを再送信する。

• mini-SWE-agent: ステップごとの再送信は1,000トークン未満。

GLM-5.3-Flashの場合、1回のタスク試行にかかるコストは、OpenCodeの0.56元に対し、Claude Codeでは1.81元となった。Deepseek-V4-Flashでは、mini-SWE-agentはより多くの対話ステップを要したため、プロンプトのオーバーヘッドが極小であるにもかかわらず、合計トークンコストはClaude Codeとほぼ同等になった。

さらに、Deepseek独自のハーネスは自社モデルを用いた場合でも競合フレームワークを上回るスコアを出せず、一方で最も高いコストを記録した。Claude Opus 5についても、研究者がClaude Codeの専用ツールを取り除いた場合ですら、まったく同一のベンチマーク結果を示した。

「思考プロセス」が果たす役割

ベンチマークのスコアをノイズの域を超えて一貫して変動させた唯一のアーキテクチャ上の要因は、内部的な推論（「思考 / thinking」）であった。推論を無効化すると、Qwen3.6と組み合わせたmini-SWE-agentは11ポイント低下し、Claude Code内のHY4-Previewも11ポイント低下した。ただし、エージェントが推論に依存する度合いは、特定のモデルとフレームワークの組み合わせに強く結びついているようだ。

研究者らは、ハーネスがもたらすものは主に「合格率の向上ではなく、タスクで失敗するパターンの減少と、請求書である」と結論づけている。リーダーボード上での誤解を招くマーケティング的な主張を防ぐため、著者らは開発者やベンチマーク主催者に対し、ハーネスの比較評価を行う際には同一構成での複数回実行結果を併記するよう強く求めている。