すでに正常に動いているコードに言語モデルを放てば、それなりの頻度で壊す。arXivに公開された新しい報告が、その直感に数字を与えた。ある条件下で自動修復ループは、正しいプログラムのおよそ26%を壊した一方、実際に壊れているプログラムを直せたのは約2.3%だった。比率にして10倍以上、望ましくない方向に傾いている。
要点
- 競技プログラミングの提出コードで測ったところ、LLM修復ループの破壊率は0.261、バグ修正率はわずか0.023だった。
- 反復を放置すると、モデルは同じ編集を加えては取り消す擬似バグ修正サイクルに陥った。ファイル全体の書き換えよりも、検索置換型の編集のほうが循環しやすかった。
- プロービングにより編集傾向を予測する内部方向が見つかり、第19層あたりでほぼ完全に分離した。この方向を抑えると破壊的なループは完全に止まったが、成功していた修復もすべて消えた。
何を測ったのか
シエタオ・ワンリン、アントン・イソプースー、ルイ・マホンによる論文If It's Not Buggy, Don't Fix Itは、著者らが「盲目的な反復利用」と呼ぶ使い方を検証している。モデルにプログラムを渡し、返ってきた編集をそのまま受け入れ、また繰り返す。修復ボットをコードレビューに組み込むチームが増えているが、その配線とほぼ一致する説明だ。
試験環境はCodeContests+である。20問、1問あたり40件のC++提出、1問平均23件のテストケースを、GoogleのGemini 2.5 Flash-LiteとアリババのQwen2.5-7B-Instructに通した。貪欲デコーディングと検索置換編集の条件で、Geminiの修復率は0.023 ± 0.002、破壊率は0.261 ± 0.032。別の条件では破壊率が0.293 ± 0.011まで上がった。著者らのまとめは率直だ。破壊率は修復率を大きく上回りうる、という。
この数字には二つの但し書きが要る。試験対象は最先端システムではなく、小型で高速なモデルだ。競技プログラミングの提出コードも、独自のテストスイートやレビューゲート、CIを備えた本番コードベースとは違う。このベンチマークが測っているのは停止条件も人間も介在しないループであり、そこが論点ではあるものの、十分に計測された修復パイプラインを測ったのとは同じではない。
収まらないループ
より落ち着かない発見は、処理を走らせ続けたときに起きることだ。モデルは安定版に収束するどころか、論文が擬似バグ修正サイクルと呼ぶ状態にたびたび陥った。同じ変更を入れ、取り消し、また入れる。プログラムは合格と不合格の間を行き来する。検索置換ブロックは、ファイル全体の編集に比べてこうしたサイクルを明らかに多く、しかも長く生み出した。
運用上これが厄介なのは、循環しているエージェントほど忙しそうに見えるからだ。差分を生成し、活動を報告し、トークンを消費する。ループにテストオラクルがつながっていなければ、出力を眺めても前進しているのか足踏みしているのかを示す手がかりがない。
「バグに見える」を担う内部方向
論文が本当に面白くなるのは機構解析の節である。著者らはモデルの活性をプロービングし、編集傾向を追う操舵ベクトルを構成した。分離度は初期層でAUC 0.7〜0.8、第19層付近で1.0近くまで上がる。モデルが「バグのあるコード」という内部表現を持ち、それが何の問題もないプログラムに対して誤って発火していることを意味する。ネットワーク内に番地の判明したハルシネーションと言ってよい。
γ = -0.5でその方向に逆らって操舵すると、破壊的なループは完全に停止し、正しい提出はすべて保たれた。同時に、修復も一件も起きなかった。すぐ実運用に回せるつまみというより、編集しようとする傾向と修復する能力がこれらのモデルの中で絡み合っていることを示した明快な実証である。偽陽性だけを下げて真陽性を残す、という都合のよい調整はできなかった。
修復ボットを回すチームにとって何が変わるか
実務的に読めば、自動修復が無用という話ではない。停止条件こそが製品だ、という話である。「ここには直すものがない」を信頼して判定できるオラクルを持たない修復ツールは、編集の大半を手を加える必要のなかったコードに費やす。そして先の数字は、その編集が差し引きでマイナスだと示している。
すでに出荷されているツールに見える設計の流れにも追い風となる。草案と作業ツリーの間に独立した批評役を挟むレビュー・修正型のパターンだ。本誌がProject HydraFusionの記事で取り上げたGitHubの新しいプレビュー版オーケストレーション層に含まれる、系統の異なるモデル同士の批評ステップも同じ狙いを持つ。こうした仕組みは、この論文が測った盲目的ループを断ち切るためにある。破壊が修復を一桁上回るのなら、反復回数の上限やツールを持たないレビュアー、フェイルセーフなパッチ適用は、もはや保守的な設計趣味ではない。
今後の見通し
この比率が実際のリポジトリで最先端モデルにも当てはまるかは当然の次の問いであり、今回の報告はそこまで答えていない。ただし、この失敗様式が偶発的ではなく構造的であることは示した。編集への傾向は内部に表現されており、健全なコードに対して発火し、反復はそれを洗い流すどころか増幅する。完全自律の修復を作る側は、次のモデルが解決してくれるのを待つのではなく、この前提の上で設計すべきだろう。
FAQ
この研究ではどのモデルを試験したのですか?
Gemini 2.5 Flash-LiteとQwen2.5-7B-Instructです。いずれも最先端システムではなく小型で安価なモデルであるため、報告された数値を最大規模のコーディングモデルの性能として読むべきではありません。
AIのコードレビューツールはコードを悪くするということですか?
これだけでそう言うことはできません。この研究が測っているのは停止条件も人間のレビューもない盲目的な反復で、一般的な運用形態というより最悪ケースです。修復ツールをどれだけ自律的に走らせるかに比例して、この結果の重みは増します。
誤ったバグ検出だけを止めることはできますか?
きれいには止められません。著者らは破壊的な編集ループを消す操舵ベクトルを見つけましたが、適用すると成功していた修復もすべて消えました。同じ内部表現が両方の挙動を駆動していることを示唆します。
