【検証】AIコード、長く使うほど壊れる。最新ベンチマークが11モデル全滅

AIに長くコードを書かせると何が起きるのか

ウィスコンシン大学マディソン校の研究チーム（SprocketLab）が、AIコーディングエージェントの「長期的な品質劣化」を初めて体系的に計測するベンチマーク「SlopCodeBench」を2026年3月25日に公開しました。

結果は厳しいものでした。Claude、GPT、Geminiを含む11のAIモデルを検証した結果、20の問題を最初から最後まで完全に解けたモデルはゼロ。最も優秀だったOpus 4.6でも、正解率はたった17.2%にとどまりました。

ここで言う「正解率」は、一般的なコーディングベンチマーク（「このバグを直せ」「この関数を書け」のような一発勝負の問題）とは根本的に違います。SlopCodeBenchでは、AIが自分で書いたコードを何度も拡張していく。仕様が変わるたびに、自分の過去のコードを引き継いで機能を追加する。実際の開発現場に近い設定です。

テストは通るのに「壊れている」とはどういうことか

「Slop code（スロップコード）」とは、AIが反復的にコードを拡張するときに蓄積していく低品質なコードのことです。テストは通る。動作もする。でも中身を見ると、同じ処理が何箇所にもコピペされていたり、ひとつの関数が1,000行を超えていたりする。人間のエンジニアが見たら「これは保守できない」と判断するコードです。

研究チームはこの劣化を2つの指標で計測しました。

ひとつ目は冗長性（Verbosity）。不要な重複コード、意味のない中間変数、過剰な防御的チェックなど、機能を追加しないのに増えていくコード行の割合です。137個のAST-Grepルールで自動検出します。

ふたつ目は構造的浸食（Structural Erosion）。新しい機能を既存の関数に継ぎ足し続けた結果、一部の巨大な関数に複雑さが集中していく現象です。わかりやすい例があります。Opus 4.6がある問題で書いたmain()関数は、最初は84行だったのに、チェックポイントを重ねるうちに1,099行まで膨れ上がりました。循環的複雑度（コードの分岐の多さを測る指標）は29から285に跳ね上がっています。

人間が書いたコードと比較すると、AIが生成したコードの冗長性は2.2倍。構造的浸食は人間が0.31±0.12なのに対し、AIは0.68±0.20。倍以上の差があります。

11モデルの成績表

テストされた11モデルの全成績です。「Strict」はすべてのテストに合格したチェックポイントの割合、「Erosion」は構造的浸食のスコア（低いほど良い）です。

ここにはっきりとしたトレードオフが見えます。正解率トップのOpus 4.6は、構造的浸食のスコアが0.774で最悪クラスです。一方、品質が最も良いGPT 5.4（浸食0.515、冗長性0.286）は、正解率ではOpus 4.6に5ポイント以上劣ります。「正しく動くコード」と「きれいなコード」を両立できるモデルは、今のところ存在しません。

もうひとつ気になるのはコストです。チェックポイントが進むにつれて、AIが使うトークン量は増え続け、最初のチェックポイントから最後にかけてコストが2.9倍に膨らんでいます。コードが膨張すると、AIがそれを読み込むだけでも費用がかかるわけです。

「きれいに書いて」と指示しても劣化は止まらない

「プロンプトを工夫すれば改善できるのでは？」と思うかもしれません。研究チームはまさにそれを検証しました。

GPT 5.3 CodexとGPT 5.4に対して、3つの戦略を試しています。通常の指示（ベースライン）、「冗長パターン・過剰な防御的エンジニアリング・不要な抽象化を禁止する」と明示的に指定する方法（anti_slop）、コーディング前にアーキテクチャ計画を要求する方法（plan_first）です。

結果はこうでした。anti_slopプロンプトは初期の冗長性を33〜34.5%下げました。出だしのコードはたしかにきれいになる。しかし、チェックポイントを重ねるごとの劣化の速度はまったく変わりませんでした。開始点が下がるだけで、悪化の傾きは同じです。しかもコストは47.9%増加しました（$304→$450/実行）。

正解率への統計的に有意な改善もありません（すべてp > 0.05）。つまり、「きれいに書いて」と頼むと最初はきれいに書いてくれるが、使い続けると同じペースで汚くなっていく。お金だけ余計にかかって、結果は変わらない、ということです。

Cursor・Copilot・Claude Codeのユーザーは何を気をつけるべきか

この研究はあくまでベンチマーク上の結果であり、CursorやGitHub Copilot、Claude Codeといったツールが「使えない」と言っているわけではありません。短期的なプロトタイピングやバグ修正、新しい関数の単発実装では依然として強力です。

問題は「長期的に同じコードベースをAIに拡張させ続ける」場合です。機能を追加するたびにコードが膨張し、既存の関数に複雑さが積み重なり、いつの間にかメンテナンスが困難になる。テストが通っているから気づきにくいのが厄介なところです。

研究チームが検証した「80%の軌跡で浸食が上昇、89.8%で冗長性が上昇」というデータは、これが特定のモデルの弱点ではなく、現在のAIコーディングエージェント全体に共通する構造的な問題であることを示しています。

実務で気をつけるべきことはシンプルです。AIが書いたコードを無検証でマージし続けない。定期的に人間がリファクタリングする。巨大化している関数がないかチェックする。今の段階では、AIは「書く」のは得意でも「整理する」のは苦手です。

今後どうなるのか

SlopCodeBenchが示したのは、既存のベンチマーク（SWE-benchのような一発勝負の問題集）では測れない「反復開発での品質維持能力」が、AIコーディングツールの実用性を決める重要な軸だということです。テストが通るかどうかだけでモデルを評価していると、実際のプロジェクトで起きる問題を見落とします。

研究チームはDARPA、NSF、Snorkel AIから資金支援を受けており、ベンチマークはGitHubでオープンソース公開されています。すでにCursorの内部では「deslop」というスラッシュコマンドでAI生成コードの品質劣化を除去する仕組みが使われ始めているという話もあり、問題意識は業界に浸透しつつあります。

プロンプトの工夫では劣化の速度が変わらなかったという結果は、この問題がモデルの訓練方法やツール側の仕組み（自動リファクタリングの強制など）で解決すべきレベルのものであることを示唆しています。AIにコードを書かせること自体が悪いのではなく、「書かせっぱなし」にするのが危ない。人間のエンジニアでも、レビューもリファクタリングもなしにコードを積み上げ続ければ同じことが起きます。違いは、AIのほうがそのペースが速いということです。

参照元

• •SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks（arXiv）
• •SlopCodeBench GitHubリポジトリ
• •SlopCodeBench公式サイト
• •Snorkel AI「Measuring Code Erosion as Agents Iterate」
• •Hugging Face Papers
• •SprocketLab（ウィスコンシン大学マディソン校）
• •Fred Sala教授のX投稿