コーディングAIは、同じモデルを使用していても、実行環境によって費用や成功率が変わる。山東大学のYangze LiuとZhongyi Hanが2026年10月3日に公開した研究では、3種類の実行基盤を比較し、その違いがAIの問題解決能力にどれほど影響するかを調べた。難しいコード修正課題45件では、実行基盤を変更した際に成否が入れ替わる割合は、同じ構成を再実行した場合と同程度だった。一方、GLM-5.3-Flashを使用した場合、1回の試行にかかる平均費用には約3倍の差が生じていた。
比較対象となったのは、Claude Code、OpenCode、mini-SWE-agentの3種類だ。これらは「ハーネス」と呼ばれ、AIモデルへの指示、利用できるツール、実行結果の受け渡し、対話履歴の管理などを担う仕組みを指す。今回の研究はClaude Codeという実行基盤を比較対象に含めているが、Claudeモデルそのものの優劣を調べたものではない。
未査読プレプリント『What Does a Harness Buy? Tokens, Mostly.』が検証したのは、実行基盤の追加機能に費用をかけることで、どの程度の利益が得られるのかという問題だ。ただし、成功率に統計的に明確な差が見られないことと、一定の許容範囲内で性能が同等だと確認することは異なる。研究結果を理解するには、成功率だけでなく、成功1件あたりの費用や、実行基盤の機能によって回避できる失敗にも目を向ける必要がある。
再実行によるばらつきと比べると、性能差はどう見えるか
研究では、実際のソフトウェアの不具合修正能力を測るベンチマーク「SWE-bench Verified」を使用した。全500件のうち、検証に外部Webサービスを必要とする8件を除外し、残る492件を難問45件とその他の447件に分けている。難問45件の内訳は、推定作業時間が1〜4時間の42件と、4時間を超える3件だ。すべての試行で、モデルの呼び出し回数は最大300回に制限した。
難問45件では、Qwen3.6-35B-A3B、Qwen3.8-27B、DeepSeek-V4-Flash（0731）、GLM-5.3-Flash、HY4-Previewの5モデルを比較した。残る447件ではQwenの2モデルを使用している。また、参考としてClaude Opus 5も実行したが、こちらはClaude Code上でのみ測定しており、3種類の実行基盤を比較する対象には含まれていない。
難問45件で同じモデルの実行基盤を変更すると、成否が一致しない課題の割合は中央値で13%だった。これに対し、同じモデルと実行基盤の組み合わせを再実行した場合も13%で、モデル自体を変更した場合は22%となった。つまり、実行基盤を替えたときの結果の変動は、同じ構成を繰り返した際の自然なばらつきと同程度だったことになる。ただし、この13%は成功率が13ポイント変動したという意味ではない。ある課題が成功から失敗に変わり、別の課題が失敗から成功に変わった場合、成功件数の合計がほぼ同じでも、課題ごとの成否の不一致は増える。
実行基盤間の成功件数の差は2〜5件で、同一構成の再実行による差は最大3件だった。ただし、再実行による比較は10組に限られており、すべての構成を繰り返したわけではない。したがって、45件の試験で明確な性能差を確認できなかったからといって、各実行基盤の性能が同一だと証明されたわけではない。
より多くの課題を使った比較では、性能差をさらに詳しく評価できる。447件の集合でClaude Codeとmini-SWE-agentを比較すると、Qwen3.6では両方の実行結果が有効だった445件のうち、成功件数はそれぞれ310件と318件だった。Claude Codeからmini-SWE-agentを引いた成功率の差は−1.8ポイントで、95%信頼区間は−5.2〜+1.6ポイントとなった。Qwen3.8では共通の有効444件で347件対353件となり、成功率の差は−1.4ポイント、95%信頼区間は−4.2〜+1.5ポイントだった。
研究チームは、単に有意差の有無を調べるだけでなく、統計的な同等性も検証している。両モデルとも、90%信頼区間が事前に定めた±5ポイントの範囲内に収まり、この基準ではClaude Codeとmini-SWE-agentの性能が同等だと判定された。ただし、これは性能差がゼロであることを保証するものではない。また、Qwen3.8をOpenCodeで動かした場合には、多重比較の補正後も統計的に有意な性能差が残っており、3種類すべての実行基盤が同等だったわけでもない。
こうした結果には、試験に使用する課題数も大きく影響する。論文では、成否の不一致率を14%と仮定した場合、45件の試験では12.9ポイントの性能差があっても、それを検出できる確率は50%にとどまると試算している。一方、447件なら5.2ポイントの差を80%の検出力で捉えられるという。小さな性能改善まで確かめるには、それだけ多くの課題を使った検証が必要になる。
成功1件あたりの費用には明確な差が生じた
成功率の違いが必ずしも明確でなかった一方、実行費用には大きな差が見られた。論文の§4.4およびTable 2では、GLM-5.3-Flashを使用し、同じ難問45件に取り組ませた初回試行の費用を比較している。費用は研究当時のAPI料金に基づき、キャッシュが適用された入力、適用されなかった入力、出力トークンをそれぞれ計算したもので、中国元（CNY）で示されている。以下の表では、論文の数値に加え、平均試行費用を成功件数で割り直した本稿独自の概算も掲載した。
| 実行基盤 | 平均試行費用 | 成功件数 | 成功1件あたりの費用（本稿概算） |
|---|---|---|---|
| Claude Code | 1.81元 | 22/45件 | 約3.70元 |
| mini-SWE-agent | 0.97元 | 20/45件 | 約2.18元 |
| OpenCode | 0.56元 | 18/45件 | 約1.40元 |
成功1件あたりの費用は、失敗した試行を含む総費用を、実際に成功した課題数で割って求めた。具体的には「平均試行費用×45÷成功件数」で計算しており、Claude Codeは1.81×45÷22＝3.70227…元、mini-SWE-agentは0.97×45÷20＝2.1825元、OpenCodeは0.56×45÷18＝1.40元となる。いずれも論文に掲載された丸め済みの平均費用を使用し、小数第2位までに丸めた値だ。この計算によれば、Claude Codeの成功1件あたりの費用はOpenCodeの約2.6倍となり、成功率を考慮しても費用差が大きいことがわかる。
ただし、難問45件における成功率の差は統計的に明確ではなく、費用の高い実行基盤ほど成功しやすいと結論づけることはできない。また、この数値は成功するまで再試行を繰り返した場合の期待費用や、実務で発生する費用を表しているわけではない。成功率だけでは修正コードの品質や作業時間を評価できず、実際の導入コストには製品の購読料なども関係する。API料金に基づく今回の試算は、ローカル環境でQwenを動かす場合の費用とも区別する必要がある。
では、なぜ同じAIモデルを使用しているのに、費用がこれほど変わるのだろうか。研究チームはGLM-5.3-Flashの最初の入力を調べ、課題の説明に相当する554トークンを差し引くことで、実行基盤ごとの固定的な入力部分を推定した。その結果、Claude Codeは16,581トークン、OpenCodeは7,025トークン、mini-SWE-agentは829トークンとなった。ただし、これはシステムプロンプトだけを直接数えたものではなく、ツールの定義やメッセージ形式なども含む残差から求めた推定値だ。一方、ツールから返される出力の文字数は、1回あたり平均約1,100〜1,200字と、3種類で大きな違いはなかった。
各実行基盤の設計にも違いがある。Claude CodeとOpenCodeは専用ツールや対話履歴の圧縮機能を備える一方、mini-SWE-agentはbashのみで操作し、履歴の圧縮も行わない。固定的な入力部分が大きい構成では、モデルを呼び出すたびに、その分のトークン費用が積み重なる。GLM-5.3-Flashの平均実行ステップ数もClaude Codeが88.1回、mini-SWE-agentが80.2回、OpenCodeが55.1回と異なっていた。
もっとも、固定的な入力部分が小さければ、必ず総費用も安くなるわけではない。DeepSeekを使用した場合、mini-SWE-agentの平均ステップ数が141回だったのに対し、Claude Codeは104回で、GLMとは逆の関係になっている。また、入力トークンの96〜99%にはキャッシュ料金が適用されていたが、研究で使用した料金表では、キャッシュによる割引を考慮しても実行基盤の費用順位は変わらなかった。
追加機能の費用対効果を判断するには、トークン消費量だけでなく、その機能が実際にどのような失敗を防いでいるかを確かめる必要がある。研究では、Qwen3.8の実行結果から、その具体例も明らかになっている。
出力の打ち切りを防ぐ機能は成功率に影響するのか
447件の課題でQwen3.8を使用した場合、OpenCodeの成功率はClaude Codeより7.9ポイント低く、その差の95%信頼区間は4.3〜11.5ポイントだった。mini-SWE-agentと比べても9.2ポイント低く、95%信頼区間は5.5〜12.9ポイントとなった。6組の比較に対してHolm法による多重比較補正を行った後も、OpenCodeと他の2種類の実行基盤との性能差は統計的に有意だった。
失敗原因を調べると、モデルの出力上限に達して処理が終了した試行が、OpenCodeでは33件あったのに対し、Claude Codeでは1件にとどまっていた。Claude Codeには、出力が途中で打ち切られた場合に続きを促す仕組みがある。実際、出力上限に達しなかった課題だけを対象にすると、両者の成功率の差はほぼ半減した。ただし、この分析だけで、続行機能の有無が性能差の原因だったと断定することはできない。
研究チームは、続行を促す指示を別の構成に移植する実験も行っている。対象となった41課題のうち、結果が改善したのは6件、悪化したのは2件、変化しなかったのは33件だった。この比較では統計的に確かな改善は確認できず、単に続きを促す指示を追加すれば、Claude Codeとの性能差が解消するとは言えなかった。
試験条件にも、完全には統一されていない部分がある。ローカル環境で動かしたQwenでは、Claude Codeに最大36,000秒の実行時間を認めた一方、OpenCodeは自身の5,760秒という制限で停止する構成だった。著者らも、この時間制限の違いを未統制の要因として認めている。また、比較したソフトウェアのバージョンはClaude Codeが2.1.259〜2.1.273、OpenCodeが1.18.30〜1.18.31、mini-SWE-agentが2.4.6であり、今後のバージョンでも同じ性能差が続くとは限らない。
今回の結果から重要なのは、実行基盤の機能数そのものではなく、それぞれの機能が防げる失敗を具体的に評価するという視点だ。出力上限による処理の中断など、実際に発生した失敗を分類し、追加機能がどの程度その問題を解消できるかを測ることで、機能にかける費用が妥当かどうかを判断しやすくなる。
実行基盤の設計が効果を発揮する条件とは
一方、実行基盤の設計によっては、AIの問題解決能力に大きな差が生じる可能性もある。Run-Ze Fanらが2026年9月17日に公開した別の未査読プレプリント『An Empirical Study of Harness Design for Coding Agents』では、AIエージェントの基本的な実行ループを固定したうえで、計画の立て方、操作インターフェース、対話履歴の管理方法を変え、その影響を比較している。
対象となったのは、Nemotron-3の30B、120B、550Bと、Mistral-Medium-3.5-128Bの計4モデルだ。SWE-Bench Verifiedの500件とTerminal-Bench 2.1の89件を使い、176種類の設定を評価した。モデルが一度に扱える情報量の上限を32k、64k、96k、128kトークンに変更したところ、上限が小さいほど履歴管理の効果が大きかった。また、bashによる操作が不得意なモデルでは、専用ツールの導入が問題解決に役立つ傾向が見られた。
ただし、機能の効果はモデルや課題によって異なり、必ずしも一方向に働くわけではない。例えば、情報量の上限を128kトークンとし、計画機能を有効にして履歴管理方式を統一したMistralの比較では、専用ツールを使用した構成がbashのみの構成より、SWE-Benchの成功率で23.2ポイント高かった。ところが、Terminal-Benchでは逆に、bashのみの構成が6.7ポイント上回った。この比較では、指示の与え方やファイル状態の追跡、変更後の診断機能なども同時に変更しているため、専用ツールの数だけが性能差を生んだと解釈することはできない。
さらに、この研究では各設定につき課題ごとの実行は1回だけで、すべての設計要素の組み合わせを網羅したわけでもない。使用したモデルや検証内容もLiuらの研究とは異なるため、独立した追試や反証として扱うことは適切ではない。むしろ、実行基盤の設計が効果を発揮する条件を別の角度から調べた研究と位置づけられる。両研究の結果だけで、最上位のクローズドモデルを含む各種実行基盤の総合的な優劣や、実務全般における性能差まで判断することはできない。
検証結果を第三者が再現できるかどうかにも注意が必要だ。Liuらの公開GitHubリポジトリには、8,032試行分、50列のデータ表と解析スクリプトが含まれている。ただし、8,032は独立した課題の数ではなく、複数の条件で実行した試行の総数だ。公開データを使って費用などを再計算することはできるが、すべての実行履歴やDockerイメージなどの実験環境は含まれていない。そのため、データ表の集計結果を再現できたとしても、AIエージェントの実際の動作まで独立して追試できたことにはならない。
また、研究では外部ネットワークへの接続も制限している。接続を許可した予備試験では、DeepSeekとQwenによる試行の71%がGitHubから修正内容を取得していたため、研究チームはその試行を破棄し、正式試験ではモデルの接続先以外への通信を遮断した。これは、問題解決中に外部から既存の修正を取得することを防ぎ、モデルと実行基盤の能力を適切に評価するための措置だ。学習データへの問題の混入や、モデルによる意図的な不正を示すものではない。
今回の二つの研究は、コーディングAIの実行基盤を評価する際に、機能の多さや単純な成功率だけでは不十分であることを示唆している。実際の開発環境で比較するなら、使用モデルと代表的な課題を統一し、同じ構成を繰り返した際の結果のばらつきも確認する必要がある。そのうえで、成功件数と総トークン費用を測定し、出力の打ち切りや履歴不足などの失敗原因を分析することが重要だ。追加機能によって防げる失敗と、そのために増える費用を対応づけて評価することが、実行基盤の真の価値を見極める手がかりとなる。