テスト実行を禁止しても、AIのバグ修正率は変わらない場合は多い

Claude CodeやCodexのようなコーディングAIにバグ修正を任せると、多くの場合、「コードを直す」「テストを走らせる」「結果を見てまた直す」という流れが繰り返されます。テストを実行して合否を確かめながら修正することは、いまや最新のAIエージェントにとって標準的な動作になっています。

しかし、テスト実行にはコストがあります。1回走らせるたびにトークンを消費し、結果が返ってくるまで待ち時間も発生します。では、そのコストに見合うだけの効果は、本当に得られているのでしょうか。テスト実行を完全に禁止した場合と、自由に実行できる場合とで、バグの直り方はどれほど変わるのか。3つのエージェント、200件の実在バグ、3,000回の修正試行を使って、この問いが正面から検証されました。

そこで見えてきたのは、多くのエンジニアが持っている「テスト実行はあって当然」という感覚を揺さぶる結果でした。テスト実行は、どんな場面では役に立ち、どんな場面ではコストに見合わないのでしょうか。

コーディングAIは1タスクに何度ももテストを走らせている

現代のコーディングエージェントによるバグ修正は、単なるコード補完とは違います。状態を保ったまま複数回のやり取りを重ね、コードを読み、編集し、必要に応じて検証しながら進めていく作業です。

その中心にあるのがテスト実行です。テスト結果やエラーログがフィードバックとなり、次の修正方針を決める材料になります。この繰り返しによって、修正の質が少しずつ高まっていくと考えられてきました。

ただし、テスト実行は軽い操作ではありません。主なコストは、大きく3つに分けられます。

トークン

テスト出力やスタックトレースは長くなりやすく、読み返すたびにコンテキスト（AIが一度に扱える文脈の容量）とAPI料金を消費します。テストを何度も走らせるほど、修正そのものではなく、ログを抱え込むためのコストが増えていきます。

時間

テストスイートの完了を待つ時間も発生します。短いものなら数秒で終わりますが、数分かかることもあり、大きなプロジェクトではさらに長くなる場合もあります。人間が待つ時間だけでなく、エージェント全体の処理時間にも影響します。

環境構築

テストを走らせるには、対象リポジトリごとに正しい言語バージョンと依存関係をそろえた実行環境（Dockerイメージ）を用意し、維持する必要があります。展開先が増えるほど負担が大きくなる、地味だが重い「エンジニアリング税」です。

では実際に、コーディングAIはどれくらいテストを走らせているのでしょうか。バグ修正の代表的なベンチマークであるSWE-bench（実在のGitHubリポジトリと課題を集めたもの）に提出された7,745件の実行ログを調べたところ、テスト実行は、調査対象となったすべてのエージェントとモデルの組み合わせで使われていました。平均すると、1タスクあたり8.8回もテストが実行されていました。

ただし、ばらつきはかなり大きく、少ないものでは2回、多いものでは19回近く実行されていました。また、新しいモデルほど多くテストを走らせる傾向も見られました。

（SWE-bench提出ログより。数値は1タスクあたりの平均テスト実行回数）

興味深いのは、テストを走らせるタイミングです。会話の序盤よりも、終盤（全体の66〜100%地点）で走らせたテストのほうが、成功率が高くなっていました。全体の平均成功率は57.9%ですが、たとえばOpenHandsとClaude-3.5-Sonnetの組み合わせでは、序盤の42%から終盤の72%へと上がっています。

修正を進めるうちに、エージェントがコードの構造やバグの原因を把握し、より的を絞ったテストを実行できるようになるためだと考えられます。

テスト実行を禁止しても、バグの直る率はほぼ変わらなかった

テスト実行の効果を切り分けるために、今回の検証では、テスト実行へのアクセスを段階的に変えた4つのモードが用意されました。

完全禁止

テストフレームワークを走らせないよう指示し、依存ライブラリも入れない設定です。実行環境を立ち上げず、コードを読んで原因を考え、修正する状況に近いものです。

クォータ制限

ポイント予算の範囲内でだけ、テスト実行を許す設定です。テスト1回を1.0ポイント、スクリプト実行を0.3ポイントとし、予算は1ポイントと3ポイントの2段階で用意されました。自由に走らせるのではなく、限られた回数だけ実行できる状態です。

コスト意識

実行そのものは自由にできますが、毎回「この実行はコストに見合うか」を意識するよう促す設定です。テストを禁止するのではなく、必要性を考えながら使わせる条件です。

無制限

制約を設けず、自由にテストを実行できる設定です。多くのコーディングエージェントが標準的に行っている、「走らせて、結果を見て、また直す」というループそのものに近い条件です。

対象となったのは、Claude Code（Claude Sonnet 4.5）、Codex（GPT-5.2）、オープンソースのOpenCode（Qwen2.5-Coder-32B）の3つのエージェントです。データセットには、SWE-benchのLiteとVerifiedが使われ、それぞれ100件ずつのバグが対象になりました。

結果は直感に反するものでした。完全禁止と無制限の差は、ごくわずかだったのです。商用エージェントの4ケースを平均すると、その差はわずか1.25ポイントで、統計的に有意な差ではありませんでした（p>0.05）。

（数値は修正成功率%。生成されたパッチが公式評価を通過した割合。クォータ1・3は実行に使えるポイント予算の量）

ここから、いくつかの示唆が得られます。

実行回数と修正成功率は比例しない

まず、テスト実行へのアクセスが増えれば、修正成功率も上がる、という単純な関係は見られませんでした。CodexのLiteでは、完全禁止の成功率が74.0%で、無制限の73.0%をむしろ1ポイント上回っています。少なくともこの条件では、自由にテストを走らせられることが、そのまま高い成功率につながるわけではありませんでした。

中途半端な実行制限は逆効果になることがある

次に、少しだけ実行できる状態は、完全に禁止するより悪い結果を招く場合があります。CodexのLiteでは、完全禁止の74%に対し、クォータ制限では68〜69%まで下がりました。限られたフィードバックを十分に活かせず、かえって判断を乱してしまうケースがあるようです。

丸暗記だけでは説明できない

「AIが訓練データで答えを覚えているだけではないか」という疑いも検証されています。もし丸暗記が主な理由なら、テスト実行を禁止した場合と無制限にした場合で、同じようなパッチが出るはずです。しかし、完全に一致したパッチはClaude Codeで24%、Codexで1%、OpenCodeで14%にとどまりました。多くのケースでは、実行条件が違うと異なるパッチが生成されていたのです。

さらに、OpenCodeが使うQwen2.5-Coder-32Bは、訓練データの打ち切り時期がVerifiedの公開より前です。それでも、テスト実行の有無で大きな差が出ないという傾向は同じでした。この結果は、単なる記憶の再生だけでは説明できません。

禁止条件の抜け道も結論を変えなかった

なお、完全禁止はプロンプトによる指示なので、エージェントが指示を破ってテストを試みることもあります。ただし依存関係が入っていないため、その多くは失敗し、有用なフィードバックにはなりません。実際に、Claude CodeのVerifiedでツール側からテスト実行コマンドを物理的に遮断して再検証しても、差は−4ポイントにとどまり、結論は大きく変わりませんでした。

トークンは最大6割、時間は最大半分まで削減できた

修正成功率がほぼ同じなら、次に重要になるのはコストです。とくにClaude Codeでは、完全禁止にすると、無制限に比べてトークン消費が56〜62%、実行時間が48〜54%減りました。修正成功率の低下は、わずか1〜3ポイントです。

（完全禁止モードでの変化。「修正率の差」は禁止−無制限のポイント差で、マイナスは禁止がわずかに低いことを示す。トークン・時間は無制限に対する削減率）

ただし、コスト構造はエージェントごとに大きく違います。鍵になるのは、もともとの消費量です。

Claude Codeはテスト出力の影響を受けやすい

完全禁止モードでの基準値を見ると、Claude Codeの消費量は約6.5万トークンでした。ここにテスト実行を加えると、テスト出力がコンテキストにどんどん溜まっていきます。そのため無制限に実行できる状態では、トークン消費が129〜163%増えていました。Claude Codeでは、テスト実行を絞るだけで、コスト削減の効果がかなり大きく出ます。

Codexはもともとの消費量が大きい

一方でCodexは、完全禁止モードの時点で約47万トークンを使っていました。もともとの消費量が桁違いに大きいため、テスト実行を追加しても、増分は0.8〜15.5%にとどまります。Codexで最も効率がよかったのはクォータ1で、21〜25%の削減が見られました。無制限に走らせるよりも、少しだけ実行を許すほうが、成功率とコストのバランスを取りやすかったようです。

OpenCodeはコンテキスト上限に詰まりやすい

弱いモデルを使うOpenCodeでは、また別の問題が起きていました。完全禁止モードでの消費量は約15万トークンですが、テスト出力が6.5万トークンというコンテキスト上限を圧迫し、無制限にすると、かえって空のパッチが増えてしまったのです。最も良い結果になったのは、テストを1回だけ許すクォータ1でした。

小型モデルでは「少しだけ実行」が効く場合がある

コンテキストに余裕のない小型モデルでは、テスト実行を増やしすぎると、修正に必要な情報を保持しにくくなります。そのため、実行をあえて絞ることで、編集に集中させながら最低限の検証も残す、ちょうどよいバランスが生まれるようです。

環境構築の手間も減らせる

完全禁止には、表には出にくいもう1つの利点があります。テストを走らせないなら、リポジトリごとに実行環境を用意し、維持する必要がなくなります。大規模に展開するほど重くなる環境構築の手間そのものを、かなり減らせる可能性があります。

実行が結果を変えたのは、ごく一部のケースだった

では、なぜテスト実行は修正成功率を大きく押し上げなかったのでしょうか。

600の「エージェント×バグ」の組み合わせを見ると、547件では実行の有無によって結果が変わりませんでした。内訳は、両方成功が269件、両方失敗が278件です。

残る53件では結果が変わりましたが、その内訳も一方的ではありません。実行が「助けた」ケースは29件、実行が「邪魔した」ケースは24件でした。つまり、正味の利益はたった5件です。テスト実行は、ほぼ同じくらいの確率で助けにも妨げにもなっていたことになります。

結果が安定していたケースを詳しく見ると、テスト実行が修正結果を大きく変えなかった理由が2つ見えてきます。

理由①再現実行は、バグの場所を見つけるのに役立たない

まず、バグを再現するためのテスト実行が、修正すべきファイルの特定にどれだけ役立っているかです。

Claude Codeでは、直せたケースの55%で再現のための実行が行われていました。しかし、修正すべきファイルを特定する精度は、実行の有無にかかわらず95%を超えており、ほとんど差がありませんでした。

しかも、その再現実行のうち、スタックトレースや行番号のように場所特定に使える具体的な情報を返したものは48.8%にとどまりました。残りの半分は、環境エラーか、「全テスト成功」のような中身の薄い出力でした。

つまり、少なくとも多くのケースでは、テストを走らせなくても、ソースコードを読むだけで修正箇所を十分に特定できていたのです。

理由②自分で通したテストが、本番の評価では落ちる

次に、コードを編集したあとの検証です。

商用エージェントのケースでは、54〜66%が、テスト実行を使えるかどうかに関係なく、たった1回の編集で完了していました。最初から正しい修正に到達しているか、あるいはテスト実行では救えない問題だったかのどちらかです。

さらに深刻なのは、自分で走らせたテストと公式評価のずれです。失敗ケースの81〜100%では、エージェントが自分で走らせたテストには合格していたにもかかわらず、公式評価では落ちていました。AIが選んだテストと、正解を判定する検証基準がずれていたのです。

自分で通したテストは、正しい修正の保証にはなりません。弱いモデルでは、さらに手前でつまずくことも多く、そもそも自分で通せるテストを組み立てられない場合があります。OpenCodeで、失敗例の中で検証テストへの合格が確認できたのは、わずか11.1%でした。

複雑なバグほど実行が役立つとは限らない

「複雑なバグなら、テスト結果を見ながら少しずつ修正したほうが成功しやすいはずだ」と考えるのは自然です。しかし、この仮説も支持されませんでした。

修正の複雑さをhunk数、つまりdiff上の変更のまとまりの数で分け、Claude CodeのVerifiedで比較すると、差は複雑さに応じて大きくなるどころか、むしろ符号が反転しました。

（SWE-bench Verified、修正成功率%。「差」は完全禁止−無制限のポイント差）

単純なバグ（1 hunk）では、無制限のほうが6.5ポイント有利でした。しかし最も複雑なバグ（4 hunks以上）では、完全禁止が無制限を23.1ポイント上回り、約2倍のバグを直していました。

複雑な修正では、局所的な試行錯誤よりも、コード全体を見渡す推論が重要になります。そこでテスト出力が大量に入ってくると、コンテキストを圧迫し、かえって判断の邪魔になる可能性があります。

少なくとも、「複雑なバグほどテスト実行で直しやすくなる」という直感は、この結果からは成り立ちませんでした。

新しいモデルほど、実行を絞る価値は大きい

今回の検証の中心で使われたのは、Claude Sonnet 4.5、GPT-5.2、そしてオープンソースのQwen2.5-Coder-32Bです。最新世代と比べれば少し前の構成も含まれるため、「いま読んでも意味があるのか」と感じるかもしれません。

しかし、この結論がすぐに古びるとは考えにくい理由があります。大きく分けると、2つです。

直近のモデルでも同じ傾向が見られている

1つ目は、振る舞いの分析が、直近のモデルまで広くカバーしていることです。7,745件のログには、Claude-Opus-4.5、Gemini-3-Pro、GPT-5.2、DeepSeek-V3.2、Kimi-K2といった、比較的新しいモデルも含まれています。

それらすべてで、「終盤に走らせたテストほど成功率が高い」「実行回数のばらつきが大きい」という傾向が共通して見られました。さらに、新しいモデルほどテストを多く走らせる傾向もあります。GPT-4の3.2回に対し、Claude-4-Sonnetは18.7回でした。

つまり、テスト実行を減らして削れる余地は、むしろ新しいモデルほど大きい可能性があります。

推論力が上がるほど、実行は答え合わせに近づく

2つ目は、テスト実行による追加の価値が、モデルの推論力が上がるほど小さくなりやすいことです。強いモデルは、ソースコードを読むだけでバグの場所を高い精度で特定し、多くのケースを1回の編集で直してしまいます。

推論力が上がるほど、テスト実行は「修正を見つける手段」ではなく、「自分の修正が正しいかを確認する手段」に近づきます。そのぶん、テスト実行によって新たに得られる情報は少なくなります。

オープンソースの検証で、あえて訓練データの古いモデルが使われたのも、丸暗記の影響を抑え、「推論だけでどこまで直せるか」を見るためです。それでも、テスト実行の有無で大きな差は出ませんでした。

削減率は手元の環境で測り直す必要がある

ただし、注意すべき点もあります。「トークンを56〜62%削減できた」といった具体的な数値は、その時点のモデル構成やエージェントの実装に強く依存します。

そのため、手元で使うモデルや環境では、削減率そのものは目安として捉えるのが安全です。実際にどれくらい削れるかは、自分の開発環境やタスクの種類に合わせて測り直す必要があります。

まとめ

テスト実行は、コーディングAIにとって当然の武器だと考えられてきました。しかし今回の検証では、実行を禁止しても修正成功率はほぼ変わらず、むしろトークンや時間、環境構築の負担を大きく減らせる場合があることが示されました。

もちろん、テスト実行そのものが不要になるわけではありません。性能計測や動的解析のように、実際に動かさなければ分からない課題は残ります。ただし、少なくともリポジトリ単位のバグ修正では、「走らせれば直る」という前提は見直す必要があります。

重要なのは、実行できるかどうかではなく、どの場面で実行する価値があるかを見極めることです。AIエージェントに十分な自由を与えることと、必要以上の資源を使わせることは同じではありません。テスト実行もまた、無制限に与える機能ではなく、配分すべき資源として扱う段階に入っています。

本記事の関連研究