「AIはコードを速く書く」は争いのないところです。悪く書くのかどうかは別の、実証的な問いです — そして私たちは、どちらの陣営のトーキングポイントよりも、測定から答えることを選びます。 三つの独立した研究が、三つの異なる手法で、同じ答えに収束しています。
出発点：文書化された欠陥率
出発点となった研究は A Clean Benchmark Is Not a Clean Codebase （英語）で詳しく扱っています：Pearceら（IEEE S&P 2022）は、**Copilotが生成した1,689本の プログラムのうち約40%**が、MITRE Top 25の弱点クラスに対して脆弱であることを見出しました。 この研究はすでに古く、その数字を現在のものとして読むべきではありません — モデルは2022年から 変わっています。この研究が確立し、後続の仕事が積み上げてきたのは：この問いは現実のものであり、 標準的な手法 — 狙いを定めたシナリオ、大きなサンプル、名前を挙げた弱点リストに対する静的解析 — で答えられる、ということです。
メカニズム：ランダムなバグではなく、系統的な欠落
数字だけでは、何をすべきかは分かりません。人間の書いたコードとLLM生成コードの統制比較 — データ構造、アルゴリズム、暗号ルーチン、LeetCode型の問題を、ユニットテスト、ファジング、 静的解析で（arXiv:2409.19182）— はさらに踏み込み、こう見出しました：LLM生成コードの安全性が 低い主因は、防御的プログラミングの構成要素の欠落です — 注意深いエンジニアが習慣として 足す境界チェックや入力検証であって、実際に依頼された機能ではありません。その欠落こそが、 バッファオーバーフローや整数オーバーフローを招き入れます。ファジングの下では、LLM生成コードは 人間の書いた比較対象よりハングとクラッシュを起こしやすいものでした。正しさの失敗は明白では なく微妙であり得ます：あるケースでは、モデルはSHA-1の誤った実装を生成し、それはきれいに コンパイルされました — 間違っていて、そのことについて沈黙したまま。
「モデルに直させればいい」を安全網と見なす人が心配すべき発見はこれです：同じ研究は フィードバックループを組み、いま見せられた問題を除去してコードを再生成するようモデルに 求めました。それは確実には機能しませんでした。成功する場合もありました。他方で「修正された」 コードが新しい問題を含む場合があり、プロンプトを打つという行為そのものが、それまで きれいだったファイルに問題を持ち込む場合すらありました。著者に自分の宿題を採点させることは、 レビューではありません。
本番環境の証拠：コストは目新しさとともには消えない
最新の証拠は、実験室の完全に外から来ています。ある研究は、2024年1月から2025年3月の間に AIコーディングアシスタントCursorを導入したGitHub上の807のオープンソースリポジトリを、 導入していない1,380の比較可能なリポジトリの対照群に対して追跡しました — 静的解析警告、重複、 複雑度の測定器としてSonarQubeを使い、2025年8月まで。生産性の物語は予想どおりに進みました： 最初の1〜2か月でコミットと追加行数が短命の急増を見せ、3か月目にはベースラインに戻りました。 品質コストはそれとともに消えませんでした。静的解析警告は導入後およそ30%上昇し、高止まり しました。コードの複雑度は40%以上上昇しました — コードベースの成長だけでは説明できない 量です。速度の利得は一時的でした。負債はそうではありませんでした。
正直な境界
これは「AI生成コードは常に悪い」という一般法則の主張ではありません。タスク、モデル、仕事の 進め方はどれも影響します — AIの出力を、ジュニアエンジニアのプルリクエストと同じレビュー規律に 値する初稿として扱うチームは、未レビューのまま出荷するチームとは違う結果を見ます。上の研究は すべてのモデルやすべての仕事の進め方をテストしておらず、レビュー規律を変数として分離した ものもありません。三つの独立した手法（狙いを定めたCWEテスト、統制比較、縦断的な本番データ）を 通して一貫して確立しているのは：この効果は現実で、偶発的ではなく系統的であり — そして モデルに自分の仕事を確認させることは、他の誰かが確認することの代わりにならない、ということです。
なぜこれが、エンジニアリングだけでなくコンプライアンスの問題なのか
サイバーレジリエンス法の下で、メーカーは、デジタル要素を持つ製品が*「リスクに基づいて適切な サイバーセキュリティ水準を確保するように設計・開発・生産される」こと、そして「既知の悪用 可能な脆弱性なしに」*市場に供給されることを確保しなければなりません（規則(EU) 2024/2847、 附属書I第I部(1)および(2)(a)、参考訳 — 規則に公式な日本語版はなく、正文はEU公用語版のみです）。 どちらの条項も、コードがどう書かれたかには触れていません。そして、既知の弱点クラスを悪用可能に しないための構成要素 — 境界チェック、入力検証 — にまさに測定済みの系統的な欠落を持つプロセスで コードベースの表面積が生成されるほど、どちらの条項も満たすのは難しくなります。レビューを 増やさずに生成を速くすることは、この義務を回り込む近道ではありません。義務との距離が 広がっていくことです。
なぜ私たちに関わるのか
CounterProofで私たちは機械が書いたコードの敵対的レビューを実践しており、この三つの研究は、 私たちのプラクティスが埋めるために存在するまさにその隙間を記述しています：AIの出力 — 生成するものも、レビューするものも — を、信じるべき結果ではなく、確かめるべき主張として 扱うこと。確認する側のツールもAIベースで、その信頼性が未検証のままだと何が起きるかについては、 姉妹編 A Clean Benchmark Is Not a Clean Codebase （英語）を参照してください。上のすべての主張の条件付きの形も含む長い議論は、機械生成テキストの コレーション（校合）と来歴に関する私たちのワーキングペーパーにあります。 全文はこちら（英語）。査読前のドラフトであり、 そのことを明記しています。
上に引用した情報源は、公表されている要旨に照らして確認しました。Pearceらの数字は IEEE S&P 2022のもので、当時のCopilotを記述するものであり、現在のモデルではありません。 Cursorの数字は、807リポジトリを1,380リポジトリの対照群に対して2024年1月から2025年8月まで 追跡した縦断研究からのものです。引用したCRAの条項は規則(EU) 2024/2847を指し、英語原文に 照らして確認済みです。日本語の引用は当方による参考訳です。このページは英語原文の翻訳であり、 相違がある場合は原文が優先します。ここに誤りがあれば、このページで書面により訂正します。