2025年2月、元Tesla AI責任者のAndrej Karpathyが「Vibe Coding」という概念をX（旧Twitter）上で提唱した。LLMに自然言語で指示を出し、生成されたコードを読まずに「Accept All」する開発スタイルである。それから1年、GitHub Copilotの累計ユーザーは2,000万人を突破し、全世界のコードの41%がAIによって生成される時代に突入した。しかし、Veracodeの2025年調査は衝撃的な数値を示す──AI生成コードの45%にOWASP Top 10の脆弱性が含まれている。本稿では、Vibe Codingが企業コードベースに持ち込む「理解債務（Comprehension Debt）」の構造を解析し、Policy-as-CodeとAI対応テストフレームワークによる実践的な防衛パターンを提示する。

Vibe Codingの定義と急速な普及

Andrej Karpathyは2025年2月2日、Xへの投稿で「Vibe Coding」を次のように定義した。「完全にVibeに身を任せ、指数関数的な進化を受け入れ、コードが存在することすら忘れる」新しいコーディングスタイルである。SuperWhisperなどの音声インターフェースでLLMに指示を出し、差分を読まずに変更を一括承認し、エラーメッセージをコメントなしでAIにコピー＆ペーストする。Karpathyは後に「次のフェーズはエージェンティック・エンジニアリングだ。99%の時間、あなたはコードを直接書かない。エージェントを統制する監督者として機能する」と進化の方向性を示した。

数値は急速な普及を裏付ける。2025年7月時点でGitHub Copilotの累計ユーザーは2,000万人を突破（Satya Nadella発表）し、わずか3カ月で500万人が新規追加された。Fortune 100企業の90%がCopilotを導入し、利用者のコードの46%がCopilotによって生成されている。Javaに至っては61%がAI生成である。2026年現在、開発者の92%がAIコーディングツールを日常的に使用し、全世界のコードの41%がAIによって書かれていると報告されている。

しかし、その急拡大の裏で深刻な問題が浮上していた。Fast Companyは2025年9月、「Vibe Codingの二日酔い（The Vibe Coding Hangover）」と題する記事で、PayPalのシニアエンジニアの「AIコーディングエージェントが生成するコードは開発地獄になり得る」という証言を伝えた。開発者のAIコードに対する肯定的センチメントは2024年の70%から2025年には60%に低下し、46%の開発者がAI生成コードの正確性を「信頼しない」と回答している。

45%のセキュリティ欠陥──数値が語る構造的リスク

Veracodeは2025年7月に公開した「GenAI Code Security Report」で、80のコーディングタスクを100以上のLLMで実行し、45%がOWASP Top 10の脆弱性を含むことを明らかにした。言語別ではJavaが70%超で最も脆弱であり、Python・C#・JavaScriptは38〜45%の範囲であった。脆弱性の類型では、クロスサイトスクリプティング（CWE-80）が86%、ログインジェクション（CWE-117）が88%という高い発生率を示した。

Snykの2025年調査はさらに深刻な構図を描く。AI生成コードは人間が書いたコードより30〜40%脆弱であるにもかかわらず、75%の開発者が「AIコードの方が安全」と誤認しており、SCA（Software Composition Analysis）ツールで脆弱性を確認していたのは25%未満であった。さらに80%の開発者がAIツールを使用するためにセキュリティポリシーをバイパスした経験があると認めている。AIが脆弱なパターンを生成し、開発者がそれを受け入れ、その受け入れがAIの学習を強化する「脆弱性の無限ループ」が形成されている。

GitGuardianの2025年レポートは、AI支援開発の秘匿情報漏洩リスクを定量化した。GitHub Copilotを利用しているリポジトリの6.4%でシークレット（APIキー、パスワード、トークン）の露出が確認されており、非利用リポジトリの4.6%と比較して40%高い漏洩率である。CodeRabbitの2025年12月の分析（470のプルリクエストを調査）では、AI生成コードは人間のコードと比較して、ロジック・正確性エラーが1.75倍、コード品質エラーが1.64倍、セキュリティ問題が1.57倍、パフォーマンス問題が1.42倍と、総合で1.7倍の問題を含むことが報告された。

理解債務（Comprehension Debt）の構造

従来の技術的負債（Technical Debt）は、納期優先で意図的に品質を犠牲にする「意識的なトレードオフ」であった。開発者は負債の存在を認識しており、返済計画を立てることができた。これに対し、Vibe Coding時代に蓄積される「理解債務（Comprehension Debt）」は本質的に異なる──開発者がコードを理解していないことすら認識していない、不可視の負債である。

Clutchが2025年6月に800人のソフトウェア専門家を対象に実施した調査は、この問題の規模を数値化した。59%の開発者が、自分が完全には理解していないAI生成コードを使用しており、96%がAI生成コードは機能的に正確ではないと認識しているにもかかわらず、コミット前に必ずコードを確認すると回答したのは48%にとどまった。自分で書くコードは創作行為を通じて理解が伴うが、機械が書いたコードは理解をレビュー時に再構築しなければならない。その再構築コストが「理解債務」の本質である。

Ox Securityが2025年10月に発表した「Army of Juniors」レポートは、300のオープンソースプロジェクト（うち50がAI生成）を分析し、AI生成コードの10の反パターンを特定した。「アーキテクチャ判断の体系的欠如」が最大の問題であり、具体的には、リファクタリングの回避（80〜90%の出現率）、モノリスへの回帰（40〜50%）、偽のテストカバレッジ（40〜50%）が報告された。AI生成コードは即座に機能する「ジュニアエンジニアの大軍」が書いたコードに似ており、局所的には正しいが、システム全体の設計思想を欠いている。これが理解債務を加速度的に膨張させる構造的要因である。

エンタープライズガバナンスの防衛パターン

Deloitteの分析によれば、AIガバナンスにおいて「Ready（準備完了）」レベルに達している企業はわずか9%である。Vibe Codingのリスクを制御するためには、ガバナンスをドキュメントではなく実行可能なコードとして実装する「Policy-as-Code」アプローチが不可欠である。以下に実践的な防衛パターンを示す。

第1層：AI生成コード検出と自動ラベリング。CIパイプラインにAI生成コード検出ツールを組み込み、プルリクエストに自動でラベルを付与する。GitHub Copilotの利用者のコード採用率は約30%（残りは無視・修正・書き直し）であるが、この30%が十分なレビューなしにマージされるリスクを可視化する。AI生成コードにはレビュー基準を強化し、人間のレビュアーが「意図との整合性」「統合ポイントの正常動作」「AIが典型的に導入する微妙なロジックエラー」を検証する体制を構築する。

第2層：セキュリティゲートの自動化。Veracodeの調査が示す45%の脆弱性混入率を前提に、SCA・SAST・DASTツールによるセキュリティスキャンをCI/CDパイプラインの必須ゲートとして設定する。特にAI生成コードで発生頻度の高いCWE-80（XSS、86%）やCWE-117（ログインジェクション、88%）に対するカスタムルールを定義する。GitGuardianが報告した40%高いシークレット漏洩率に対しては、シークレットスキャンをpre-commitフックとして実装する。

第3層：Human-in-the-Loop（HITL）開発フレームワーク。ICSE 2025で発表されたHULAフレームワーク（Atlassian DevAIチーム・Monash大学・Melbourne大学の共同研究）は、LLMベースエージェントに人間の監督を組み込むモデルを提案した。このフレームワークでは、作業項目の79%に対してコーディングプランが生成され、エンジニアの82%がプランを承認したが、最終的にプルリクエストに到達したのは25%、ユニットテストに合格したのは31%であった。この数値は「AIは加速装置であり自動操縦装置ではない」という原則を実証している。

第4層：理解債務の測定と管理。理解債務を管理するためには、まず測定可能にする必要がある。コードオーナーシップマトリクスとAI生成比率を組み合わせ、「チーム内の誰もロジックを説明できないコードブロック」を特定するメトリクスを導入する。定期的なコードウォークスルーをAI生成コードの比率が高いモジュールに対して実施し、理解の再構築を組織的プロセスとして制度化する。

Vibe Codingが破壊するオープンソースのエコシステム

2026年1月に公開された学術論文「Vibe Coding Kills Open Source」（Koren, Bekés, Hinz, Lohmann; arXiv: 2601.15494、欧州研究会議ERC助成）は、Vibe Codingがオープンソースソフトウェア（OSS）のエコシステムに与える構造的脅威を経済学的に分析した。Vibe Codingでは、AIエージェントがOSSを選択・組み立てる際に、開発者はドキュメントを読まず、バグを報告せず、メンテナーとの対話も行わない。これにより「開発者とOSSメンテナー間の障壁」が形成される。

論文の核心的主張は、OSSがユーザーエンゲージメントを通じてマネタイズされている場合、Vibe Codingの普及はOSSの参入・共有の低下、品質と可用性の低下、そして生産性向上にもかかわらず全体の福祉の低下をもたらすというものである。著者らは「現在の規模でOSSを維持するためには、メンテナーへの報酬の仕組みを根本的に変える必要がある」と結論づけた。この問題はVibe Codingのガバナンスにおいて、セキュリティや品質とは異なる次元のリスク──依存先エコシステムの持続可能性リスク──として認識すべきである。

結論──「理解なき速度」の代償

Vibe Codingは開発速度を劇的に向上させる一方で、セキュリティ欠陥（45%）、シークレット漏洩（40%増）、1.7倍の品質問題、そして59%の開発者が理解していないコードの蓄積という構造的リスクを企業にもたらしている。この「理解債務」は、従来の技術的負債とは異なり、負債の存在自体が不可視であるという点で、はるかに危険である。

防衛の鍵は「速度の否定」ではなく「理解の制度化」にある。AI生成コードの検出・ラベリング、セキュリティゲートの自動化、HITLフレームワークの導入、そして理解債務の測定──これらをPolicy-as-Codeとして実装し、CIパイプラインに組み込むことで、AIの生産性を享受しながらリスクを制御する。AIが生成するコードの量は今後も増加し続ける。問われているのは「AIにコードを書かせるか否か」ではなく、「AIが書いたコードを組織としてどう理解し、統制するか」である。

FAQ

Vibe Codingとは何か？

2025年2月にAndrej Karpathyが提唱した開発スタイルで、LLMに自然言語で指示を出し、生成コードを詳細に読まずに受け入れる手法である。音声インターフェースの活用やdiffの一括承認が特徴とされる。

理解債務（Comprehension Debt）と技術的負債の違いは？

技術的負債は意図的なトレードオフであり負債を認識できるが、理解債務はAI生成コードを開発者が理解していないことに起因する不可視の負債である。Clutchの調査では59%の開発者が理解していないAI生成コードを使用している。

AI生成コードのセキュリティリスクはどの程度か？

Veracodeの2025年調査では45%にOWASP Top 10脆弱性が含まれ、Snykの調査では人間のコードより30〜40%脆弱である。GitGuardianはAIツール利用リポジトリのシークレット漏洩率が40%高いと報告している。

企業がVibe Codingのリスクを軽減するにはどうすればよいか？

Policy-as-Codeによるガバナンスの自動化が有効である。AI生成コードの検出・ラベリング、CIパイプラインへのセキュリティゲート組み込み、HITLフレームワークの導入、そして理解債務の測定メトリクス導入が推奨される。

Vibe Codingはオープンソースにどのような影響を与えるか？

2026年1月の学術論文によれば、AIが自動的にOSSを選択・組み立てることで開発者とメンテナー間の対話が断絶し、OSSの品質低下と持続可能性の危機を招く可能性がある。

参考文献