2025年2月、OpenAI共同創業者のAndrej Karpathyが「Vibe Coding」という概念を提唱した。LLMに自然言語で指示を出し、生成されたコードを精査せずに受け入れる開発手法である。Collins English Dictionaryが2025年のWord of the Yearに選出するほど、この概念は急速に浸透した。しかし、AI生成コードのセキュリティ品質を定量的に検証した複数の調査は、この開発スタイルが深刻なリスクを内包していることを示している。本記事では、Veracodeの脆弱性分析、METRの生産性調査、UpGuardの開発者行動分析を横断的に検証し、AI支援開発における品質保証パイプラインの設計パターンを提案する。

AI生成コードの脆弱性実態 ── Veracode 2025調査の衝撃

Veracodeが2025年7月30日に公開した「2025 State of Software Security」レポートは、AI生成コードの安全性に関する最大規模の定量調査である。100以上のLLMを対象に、MITRE CWE（Common Weakness Enumeration）に基づく80のコーディングタスクを実行し、Java、JavaScript、Python、C#の4言語で脆弱性の発生率を測定した。

結果は深刻である。全体の45%のタスクでセキュリティ上の欠陥が発見された。言語別では、Javaが72%と最も高い脆弱性率を示し、C#が45%、PythonとJavaScriptが38〜45%と続く。特に、クロスサイトスクリプティング（CWE-80）では86%、ログインジェクション（CWE-117）では88%のケースでAIツールが防御に失敗した。識別されたセキュリティ問題は43のCWEカテゴリにわたり、そのうち8つは2023年のCWE Top-25に含まれる深刻な脆弱性であった。

注目すべきは、モデルの規模や学習の洗練度に関係なく、セキュリティ性能が改善していないという点である。機能的に正しいコードを書く能力は向上しているにもかかわらず、セキュリティ品質は横ばいのまま推移している。一方で、人間によるレビューを追加すると脆弱性を60%削減できることも示されており、技術的な解決策の存在は確認されている。

生産性の幻想 ── METR調査「AI利用で19%遅延」の真相

2025年7月10日、AI評価機関METRが公開したランダム化比較試験の結果は、AI支援開発の効率性に関する通説を覆した。平均22,000スター、100万行以上のコードベースを持つ主要オープンソースリポジトリから16名の経験豊富な開発者を対象に、246の実際のイシューをAIツールの使用可否にランダムに割り当てた。使用されたツールは主にCursor ProとClaude 3.5/3.7 Sonnetである。

開発者自身は「AIを使って20%速くなった」と認識していた。しかし、客観的な測定結果は正反対で、AI使用時に19%遅くなっていた。調査前の予測でも開発者は24%の高速化を期待しており、主観と客観の乖離は約40ポイントに達する。遅延の原因として、プロンプト作成時間、AI生成コードのレビュー時間、複雑なコードベースへの統合に伴う調整コストが挙げられている。

ただし、METRはこの結果の一般化に慎重な姿勢を示している。対象が大規模OSSリポジトリの経験者16名に限定されており、学習効果やタスク特性の違いも考慮すべきだとしている。グリーンフィールド（新規）開発やプロトタイピングなど、異なるコンテキストでは結果が変わる可能性がある。

開発者の危険な行動パターン ── 「5人に1人が無制限アクセス」の実態

セキュリティ企業UpGuardが2026年2月に公開した調査は、Vibe Codingのリスクを開発者行動の側面から照射する。GitHubの公開リポジトリに含まれる18,000件以上のAIエージェント設定ファイルを分析した結果、開発者の5人に1人（20%）がAIコーディングツールに無制限のワークステーションアクセスを許可していることが判明した。

具体的には、20%がファイル削除権限を無制限に付与し、約20%がメインリポジトリへの変更を人間のレビューなしに自動保存することを許可していた。さらに、Pythonの任意コード実行権限を付与しているケースが14.5%、Node.jsでは14.4%に達する。これらの設定は、AIツールがセキュリティ脆弱性を含むコードを生成した場合に、それが即座に本番環境に反映されるリスクを意味する。

Stack Overflowの2025年開発者調査も興味深い数値を示している。84%の開発者がAIツールを使用または使用予定と回答する一方、46%がAIの正確性に不信感を持っている。にもかかわらず、AI生成コードを常にレビューしてからコミットする開発者はわずか48%にとどまる。「信頼していないが、確認もしない」という矛盾した行動が半数以上の開発者に見られるのである。

Snykの調査はさらに踏み込んだ実態を明らかにしている。80%の開発者が組織のAIコードセキュリティポリシーを回避してツールを使用しており、AI生成コードの脆弱性を特定するためにSCA（ソフトウェア構成分析）を使用している開発者は25%未満にすぎない。

コード品質への構造的影響 ── GitClearの2.11億行分析

コード分析プラットフォームGitClearは、2020年から2024年にかけて2.11億行の変更コードを分析し、AI支援開発がコード品質に与える構造的影響を定量化した。

最も顕著な変化はコード重複の増加である。コピー&ペーストされた行の比率は2020年の8.3%から2024年には12.3%へと、相対的に48%増加した。2024年には重複ブロックの出現率が2年前の約10倍に達している。同時に、リファクタリングの指標であるコードの「移動」比率は24.1%から9.5%に激減した。2024年は、コピー行が移動行を上回った初めての年となった。

さらに、新規コードが2週間以内に書き直される「コードチャーン」の割合も3.1%から5.7%に増加しており、早すぎるコミットの増加を示唆している。GitClearはこの原因として、AIアシスタントがTabキー一つで新しいコードブロックを挿入するため、既存関数の再利用よりも新規生成が優先されること、コンテキストウィンドウの制約によりアーキテクチャ全体を把握できないことを挙げている。

ただし、AIツールと構造化された監視フレームワークを組み合わせたチームでは、長期的な品質の低下がほぼ見られなかったことも報告されている。ツールの問題ではなく、運用プロセスの問題であることを示す重要な知見である。

品質保証パイプラインの設計パターン ── 速度と安全性の両立

上述の調査結果を総合すると、AI生成コードのリスクは技術的に制御可能であるが、そのためには意図的な品質保証パイプラインの構築が不可欠である。以下に、現時点で有効性が確認されている設計パターンを示す。

パターン1: シフトレフト・セキュリティゲート

IDE内にSAST（静的アプリケーションセキュリティテスト）をリアルタイムで統合する。Codacy Guardrailsのようなツールは、VS Code、Cursor、Windsurfで動作し、AI生成コードが書かれた時点でセキュリティおよび品質の欠陥をスキャンする。コードがエディタに表示される前に自動修正を行う「プリエンプティブ方式」が最も効果的である。

パターン2: マルチレイヤー検証

単一のセキュリティツールでは検出できない脆弱性が存在するため、CI/CDパイプラインに複数の検証レイヤーを組み込む。SAST（ソースコード静的解析）、DAST（動的アプリケーションテスト）、SCA（ソフトウェア構成分析）、シークレット検出の4層構成が推奨される。SASTはソースコードレベルでインジェクション脆弱性や設定ミスを検出し、DASTは実行中のアプリケーションでSASTが見逃すランタイム脆弱性を補完する。

パターン3: ポリシー・アズ・コード

組織のセキュリティポリシーをコードとして定義し、AIエージェントの設定ファイルに組み込む。OpenSSFが公開している「Security-Focused Guide for AI Code Assistant Instructions」は、AIコードアシスタントに対するセキュリティ指向の命令セットを体系化しており、このアプローチの実践ガイドとして有用である。80%の開発者がポリシーを回避するという現実に対し、ポリシーを人間の意志決定から自動化の領域に移行させることが鍵となる。

パターン4: レビュー必須化とメトリクス監視

AI生成コードを含むプルリクエストに対し、人間によるレビューを必須化するブランチ保護ルールを設定する。Veracodeの調査で示された「人間のレビューで脆弱性60%削減」のエビデンスは、このプラクティスの費用対効果を裏付ける。併せて、GitClearのデータが示すコード重複率やチャーン率を継続的に監視し、品質劣化の早期兆候を検出する。

結論 ── 問題はツールではなく、プロセスである

Vibe Codingのセキュリティ危機は、AIツールの技術的限界というよりも、開発プロセスの設計不備に起因している。Veracodeの45%脆弱性率は深刻だが、人間のレビューで60%削減できる。METRの19%遅延は大規模OSSでの限定的知見だが、AIツールの盲目的な信頼に警鐘を鳴らす。GitClearのデータは品質低下を示すが、構造化された監視があればほぼゼロに抑制できる。

共通するメッセージは明確である。AI生成コードの恩恵を享受しつつリスクを制御するためには、セキュリティを開発パイプラインに組み込む「意図的な設計」が必要である。セキュリティポリシーの自動化、マルチレイヤー検証、メトリクス監視の3点を核とした品質保証フレームワークの構築が、Vibe Coding時代のソフトウェア開発における必須要件となる。

FAQ

Vibe Codingとは何か？

2025年2月にAndrej Karpathyが提唱した開発手法で、LLMに自然言語で指示を出し、生成されたコードを詳細にレビューせず受け入れるスタイルを指す。Collins English Dictionaryの2025年Word of the Yearに選出された。

AI生成コードの脆弱性率はどの程度か？

Veracodeの2025年調査によると、100以上のLLMを対象にした検証で全体の45%に脆弱性が発見された。言語別ではJavaが72%と最も高く、クロスサイトスクリプティングでは86%のケースで防御に失敗している。

AI支援開発は本当に生産性を向上させるのか？

METRの2025年7月の調査では、経験豊富なOSS開発者16名を対象にしたランダム化比較試験で、AI使用時に19%遅くなるという結果が得られた。ただし、大規模OSSの限定的なコンテキストであり、新規開発やプロトタイピングでは異なる結果の可能性がある。

AI生成コードのセキュリティリスクを軽減するにはどうすればよいか？

IDE内へのSASTリアルタイム統合、CI/CDパイプラインでのSAST・DAST・SCA・シークレット検出の多層検証、セキュリティポリシーのコード化、AI生成コードへの人間レビュー必須化が有効である。Veracodeの調査では、人間のレビュー追加で脆弱性を60%削減できることが確認されている。

開発者はAI生成コードを適切にレビューしているか？

Stack Overflowの2025年調査によると、AI生成コードを常にレビューする開発者はわずか48%である。また、UpGuardの調査では開発者の5人に1人がAIツールに無制限アクセスを許可しており、Snykの調査では80%が組織のセキュリティポリシーを回避してAIツールを使用している。

参考文献