AIに「ログインページを作って」と頼んだら5分で完成。でもそのコードにSQLインジェクションの脆弱性が潜んでいました。パスワードの暗号化も抜けていて。バイブコーディング(Vibe Coding)がMIT選定2026年10大革新技術に選ばれましたが、素早く作ったコードが素早く破られるというアイロニーが現実になりつつあります。
これは何?
2025年2月、元OpenAI共同創業者でTesla AIのリーダーだったAndrej Karpathyがこんな投稿をしました。「私はこれをバイブコーディングと呼ぶ。完全にバイブに身を委ね、コードが存在するという事実自体を忘れろ。」 自然言語でAIに指示を出し、AIが生成したコードをレビューなしに受け入れ、エラーが出たらエラーメッセージをそのままAIに貼り付ける、そういうやり方です。
この用語はあっという間に広まりました。Merriam-Websterが2025年3月に「スラング&トレンディング」表現として登録し、MIT Technology Reviewは2026年1月の10大革新技術リストに「Generative Coding」として掲載しました。Meta、Google、Microsoftが社内の新規コードの25〜30%をAIで生成しているという事実も紹介されています。
数字だけ見れば明るい話です。74%の開発者が生産性向上を実感し、コミット頻度は1.4〜1.9倍に増え、グリーンフィールド機能の作業完了時間が20〜45%短縮しました。 スタートアップ(20人以下)では60%以上がバイブコーディングを日常的に使っています。
問題はこのスピードの裏側です。
何が変わるのか?
速く作って、速く破られる
2025年12月、CodeRabbitが470のオープンソースGitHub PRを分析した結果は衝撃的でした。 AIが共同で作成したコードは、人間が書いたコードより平均1.7倍多くの問題を含んでいました。PRあたりの問題数が人間6.45件 vs AI 10.83件。セキュリティ脆弱性はさらに深刻でした。
| 人間が書いたコード | AI生成コード(危険度) | |
|---|---|---|
| XSS脆弱性 | 基準線(1x) | 2.74倍高い |
| 安全でないオブジェクト参照 | 基準線(1x) | 1.91倍高い |
| パスワード処理エラー | 基準線(1x) | 1.88倍高い |
| 安全でないデシリアライゼーション | 基準線(1x) | 1.82倍高い |
| ロジック/正確性エラー | 基準線(1x) | 1.75倍高い |
Tenzaiというセキュリティスタートアップはさらに踏み込みました。Claude Code、OpenAI Codex、Cursor、Replit、Devin — 5つの主要なバイブコーディングツールで同じアプリをそれぞれ3つ(合計15個)作ったところ、69件の脆弱性が発見されました。そのうち約6件が致命的(critical)レベルで。すべてのツールがSSRF(サーバーサイドリクエストフォージェリ)脆弱性を生成し、CSRFプロテクションやセキュリティヘッダーを設定したアプリは一つもありませんでした。
より大規模な調査もあります。Escape.techの研究チームが5,600以上の公開バイブコーディングアプリをスキャンした結果、2,000件以上の脆弱性、400件以上の流出したシークレットキー、175件の個人情報(医療記録、IBAN、電話番号を含む)が発見されました。 Lovableプラットフォームで作られたあるアプリでは、18,000人分のユーザーデータが流出した事例もありました。
Kasperskyの調査では、AIモデルが生成したコードの45%がOWASP Top-10の脆弱性を含み、この割合は2年間改善されていません。GPT-4oでコードを5回繰り返し修正すると、むしろ致命的な脆弱性が37%増加するという結果もあります。
見えない負債:認知的負債(Cognitive Debt)
セキュリティ脆弱性はまだスキャナーで検出できます。より怖いのが「認知的負債(Cognitive Debt)」です。技術的負債(Technical Debt)がコードに残るのに対し、認知的負債は開発者の頭の中に残る借金なんです。
AIがコードを書くとき、開発者がスキップするのは入力作業だけではありません。「なぜこの構造を選んだのか」「このコンポーネントがあのコンポーネントとどのように連携するのか」という深い思考をスキップしているのです。時間が経つと、自分で作ったシステムも修正できなくなります。
数字で見るとより明確です。AIエージェントが1分間に140〜200行の意味のあるコードを生成する一方、人間が読んで理解するスピードは1分間に20〜40行。5〜7倍の理解力ギャップが生じています。 Anthropicの調査では、AI支援を使う開発者のスキル習熟度が17%低下し、コード生成をAIに委任した開発者は理解度テストで40%未満を記録したのに対し、AIを概念探求に活用した開発者は65%以上を記録しました。
67%の開発者が、生産性向上にもかかわらずAI生成コードのデバッグにより多くの時間を費やしていると回答しています。認知的負債が積み重なると通常6〜12ヶ月後に問題が表面化しますが、その頃にはすでにチーム全体がシステムを理解できない状態になっています。
始め方のポイント
バイブコーディングを使わないわけにはいきません。でも「動く」を「安全だ」と勘違いしないことが肝心です。
- AIが生成したコードにセキュリティスキャンを標準で実施する
SAST(静的解析)ツールをCI/CDに統合してください。AIが作ったコードはジュニア開発者のコードと同程度の脆弱性パターンを示します。人間によるレビューの前に自動スキャンを先に走らせましょう。 - プロンプトにセキュリティ要件を明記する
「ログインを作って」ではなく「OWASP Top-10基準で安全なログインを作って。入力値の検証、bcrypt暗号化、CSRFトークンを含める」と指示してください。プロンプトが具体的なほど脆弱性が減ります。 - AIのコードを読む時間を確保する
生成スピードが5〜7倍速いからといってレビューを省くと認知的負債が積み重なります。少なくとも「なぜこの構造なのか」をチームメンバー1人以上が説明できる状態を保ちましょう。AIを「代わりに打つツール」ではなく「一緒に考えるツール」として使ってください。 - 5回以上の繰り返し修正は自分でリファクタリングする
AIに修正を繰り返させると脆弱性が37%ずつ増えます。3〜5回試しても解決しない場合は、自分でコードを読んで構造を再設計する方が結果的に早いです。




