AI がバグ修正するとき、なぜ直しすぎてしまうのか

『過剰編集』って、要するに AI が余計なお世話をしちゃうってこと？

そう言えばそうなんですが、もう少し厳密には「AI が直すべき部分だけを認識できていない」という問題なんですよね。 人間のプログラマーなら「1行だけ直して」という指示を聞くと、自分の理解と照らし合わせて「ここがバグ」「だからこの部分だけ変える」と判断できます。でも AI は、バグを認識する過程で「この周辺のコードもより良く書き直せる」という判断を働かせてしまう。正しい修正に加えて、スタイルの改善とか変数名の変更とか、AI 的には「親切」な手直しまでやってしまうわけです。 興味深いのは、これが「手抜き」ではなく「完璧性へのこだわり」に近いということ。AI には「これで十分」という感覚がないから、見つけたすべての「改善機会」に反応してしまう。指示で「最小限」と明記するだけで 33% も改善するのは、実は AI が「どこまで手を入れるべきか」という判断軸を、指示という形で初めて与えられるからなんだと思います。 人間同士なら暗黙の了解ですが、AI にはそれが通じない。でも逆に言えば、学習で「最小限」を繰り返し経験させると、その感覚を身につけられるようになってきたということかもしれません。

自分が使ってる AI コーディング補助ツール（Copilot とか）でも、このバグ修正の『直しすぎ』って起きてるのかな？

実際に起きてる可能性は高いと思います。ただ、文脈によって見え方が変わるんですよね。 Copilot みたいなコード補助ツールは、バグ修正というより「次の行を予測する」という用途が主。 だから過剰編集が「問題」として顕在化しにくい側面がある。 コードを「生成」してるので、そもそも「元のコードに対する忠誠度」という概念が薄いんです。 ただ、既存コードに対して「このエラーを直して」と指示したときは、記事の問題と同じことが起きてる可能性がある。 Copilot でも ChatGPT でも、バグの原因と無関係な部分を「改善だと思って」書き直すことはあります。 変数名を変えたり、ロジックを整理したり。 利用者にとっての実感としては「直しすぎ」より「変な風に直る」と感じることの方が多いかもしれません。 その余計な変更が、実際には動作に影響を与えてないこともあるので、バグとして報告されにくい。 でも本番環境で走るコードなら、小さな変更でも新しいバグを呼び込む可能性は常にあるんですよね。

AI がコードを書くようになってから、こういう『直しすぎ問題』ってずっと指摘されてたの、それとも最近気づかれ始めたの？

AI がコード修正を始めた当初は、むしろ「修正できること自体」に目が向いていたと言えそうです。2022年の ChatGPT 登場後、プログラマーたちは「バグ修正ができる」という事実に驚き、その精度向上に注力していました。ところが使い込んでいくと、修正は正確なのに余計な部分まで書き直してしまう癖が見えてくる。この「過剰編集」は、実務的な不便さが目立つようになった2023年〜24年ごろから指摘が増えた印象があります。言ってみれば、医者が正確に治療できるようになったあと、「でもメスの入れ方が大きすぎないか」と気づくようなタイミングですね。AI が「まあまあ使える」から「本当に信頼できるか」という段階へ進む中で、こうした細かい問題が表面化してきたのだと考えても不思議ではなさそうです。

AI が『完璧を求めすぎて失敗する』のって、人間の完璧主義と同じメカニズムなの？

表面的には似ていますが、根っこは違う気がします。 人間の完璧主義は「もっと良くしたい」という心理的な欲求が働いています。自分の仕事に対するプライドとか、不安感の表れとか。だから一度修正を始めると、止めどころを見失ってしまう。 AI の「過剰編集」は、むしろ訓練データの性質から生まれているようです。修正されたコード例を学習するとき、AI が「バグを直す」という目標に対して、データに含まれる様々な修正パターンを全部吸収してしまう。結果として「バグを直すついでに、他もきれいにしたパターン」を優先度高く学んでしまうんじゃないか。 この研究で興味深いのは、指示を工夫したり強化学習で「最小限を心がけてください」と教えると改善する点です。つまり AI には、もともと「完璧を求めるべき」という衝動は無くて、ただ学習データから「これが良い修正」と思い込んでいただけなのかもしれません。人間と違って、メカニズムは教えれば書き換えられる領域にあるということだけで、その差は意外と大きそうです。

修正内容が元のコードより『読みやすくなる』ケースもあるはずだけど、逆にそういう改善を AI が積極的にやることは、プロジェクトの統一性に悪影響することもあるんじゃ？

コード修正の「正解」って、実は技術的な話じゃなくて組織的な話なんですよね。 読みやすくなる改善なら一見良さそうですが、プロジェクトって複数人で進むもの。Aさんが修正したコードはスタイルX、Bさんが修正したコードはスタイルYになってしまうと、全体が寄せ集めのような見た目になる。レビューも増える。「この修正は必要か」という議論も増える。チームが疲弊するんです。 だから実務では「最小限の修正」が求められるんですよね。バグだけ直して、あとはその周辺コードのスタイルに合わせる。変数名も既存のルールに従う。むしろ、プロジェクトの統一性を保つために、改善の誘惑を抑える方が大事。 AI が「このコード汚いから整形しようか」と勝手にやる気持ちは分かるんですが、それって本来はリーダーや別のプルリクエストで、チーム全体で合意してからやることなんです。バグ修正に個性が出ちゃうと、むしろノイズになるというのが実感なのかもしれません。