title: "Vibe Codingの時限爆弾：AI生成コードの脆弱性論争と本番投入前セキュリティチェックリスト" description: "AI生成コードの45%にOWASP Top 10脆弱性が含まれるというVeracode調査をはじめ、Vibe Codingのセキュリティ論争を一次情報で整理。AI生成コードを業務システムに本番投入する前に、内製チームが踏むべきセキュア・プロンプトとレビュー体制、チェックリストをまとめる。" keyword: "Vibe Coding AI生成コード セキュリティ 脆弱性 内製 チェックリスト" slug: "vibe-coding-security-timebomb-checklist-20260625" date: "2026-06-25" updatedAt: "2026-06-25" category: "AI・DX" tags: ["Vibe Coding","AI生成コード","セキュア開発","内製","DevSecOps"] author: "GXO株式会社" lead_summary: "AIが書いたコードは速い。だが本番投入前にセキュリティを検証しなければ、脆弱性は静かに残り続ける。"
Vibe Codingの時限爆弾：AI生成コードの脆弱性論争と本番投入前セキュリティチェックリスト
結論：AI生成コードは「動くか」ではなく「安全に本番に出せるか」で判断する
AIに自然言語で指示し、出てきたコードをそのまま組み込む「Vibe Coding」は開発スピードを大きく押し上げた。一方で、誰もセキュリティ観点でレビューしないまま本番へ出すと、脆弱性が時限爆弾のように残る。
2025年7月にVeracodeが公開した調査では、100を超える大規模言語モデルが生成したコードのうち 45%がOWASP Top 10の脆弱性を含み、セキュリティテストに不合格 だった（※Veracode「2025 GenAI Code Security Report」2025年7月30日）。しかも、モデルが新しく大きくなっても、この失敗率はほとんど改善していない。
つまりAI生成コードの安全性は「より良いモデルを待つ」では解決せず、本番投入の前に人と仕組みでチェックする体制をつくるしかない。
押さえるべき1点：Vibe Codingで問うべきは「このコードは動くか」ではなく「このコードをセキュリティレビューに通せるか」である。
この記事は、開発リーダー・情シス・経営層が、AI生成コードを本番投入する前に確認すべき論点とチェックリストを一次情報で整理する。AI開発・内製で起こりがちな失敗の全体像はバイブコーディングの危機（連載）、セキュリティ事故の類型はセキュリティ失敗図鑑で押さえられる。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
なぜ「速いが危ない」のか：論争されている数字を一次情報で確認する
Vibe Codingをめぐる数字は誇張されて拡散しやすい。ここでは出典が辿れるものだけを扱う。
| 指摘 | 内容 | 出典 |
|---|---|---|
| 約45%が脆弱 | 100超のLLMが生成したコードの45%がOWASP Top 10脆弱性を含みセキュリティテスト不合格 | ※Veracode「2025 GenAI Code Security Report」2025年7月 |
| 言語差が大きい | Java 72%、C# 45%、JavaScript 43%、Python 38%が失敗 | ※同上 |
| XSS防御の弱さ | クロスサイトスクリプティング（CWE-80）で86%が防御に失敗 | ※同上 |
| 速度と欠陥の比 | AI活用開発者はコミット速度が3〜4倍だが、セキュリティ指摘の発生は約10倍 | ※Apiiro 2025（CSA研究ノート2026年4月で引用） |
| 改善しない | モデルが大きく新しくなっても、安全なコードを書く能力は横ばい | ※Veracode 2025 |
「45%」は実運用のリポジトリ全体ではなく、特定のコード補完タスクを評価した結果である点に注意は要る。それでも、放置すればAI生成コードは脆弱性が混入しやすい傾向があるという結論は動かない。Javaで72%、最も低いPythonでも38%が失敗しており、「うちはPythonだから大丈夫」とは言えない水準だ。
見落とされがちな第二のリスク：存在しないパッケージとサプライチェーン攻撃
脆弱性はコード本体だけにあるのではない。AIは 実在しないライブラリ名を平然と提案する ことがあり、これを悪用するのが「slopsquatting（スロップスクワッティング）」という新しいサプライチェーン攻撃だ。
仕組みはこうだ。
- AIが実在しないパッケージ名をimport文やインストール手順として提案する
- 同じ間違いが別のプロンプトやモデルでも繰り返し再現される
- 攻撃者がその「よくハルシネーションされる名前」を先回りしてnpmやPyPIに登録する
- 開発者がAIの提案どおりインストールすると、悪意あるコードが実行される
学術研究やセキュリティ各社のレポートでは、AI生成コードのパッケージ参照に実在しないものが相当数含まれ、そのハルシネーションが別の実行でも再現性高く繰り返されることが報告されている（※slopsquattingに関する研究および Trend Micro「Slopsquatting: Hallucination in Coding Agents and Vibe Coding」2025年6月）。再現性が高いほど、攻撃者は「次にどの名前が誤提案されるか」を予測して罠を仕掛けやすくなる。
Vibe Codingのリスクは「変なコードが混じる」だけではない。「実在しない依存先を信じてインストールしてしまう」調達側のリスクでもある。
このため本番投入前チェックには、コード本体のレビューに加え、依存パッケージが実在し、信頼できる提供元か を検証する工程が要る。依存関係やコンポーネントの棚卸しは、脆弱性診断で扱う基本項目でもある。
AI生成コードを業務投入する前のセキュア・プロンプト＆レビュー体制
「AIに任せる」のは生成までで、安全性の担保は人と仕組みの仕事だ。投入前の体制は、おおまかに3層で考える。
第1層：プロンプト段階で前提を与える（セキュア・プロンプト）
生成の入口で、セキュリティ要件を明示する。
- 入力値のバリデーションとエスケープを必須にする（XSS、SQLインジェクション対策）
- 認証・認可の判定をクライアント側ではなくサーバ側で行う
- 秘密情報をコードやログに直書きしない
- 依存パッケージは実在・著名・メンテ継続中のものに限定し、提案理由を併記させる
ただし、指示しても守られない前提で次の層を置く。モデルは指示しても安全なコードを安定して書くとは限らないからだ。
第2層：自動チェックをパイプラインに組み込む（DevSecOps）
人手レビューの前に、機械でふるいにかける。
- SAST（静的解析）で危険なパターンを検出する
- SCA（ソフトウェアコンポーネント解析）で依存パッケージの脆弱性と実在性を確認する
- シークレットスキャンで鍵やトークンの混入を止める
- DAST（動的解析）で稼働中の挙動を検証する
これらをCI/CDに常設し、不合格なら本番に進めない関門にする。仕組み化の設計は、DevSecOpsによるセキュア開発体制の中核論点である。
第3層：人によるレビューと責任の明確化
最後は人が見る。特に次の点はAIに任せきれない。
- ビジネスロジックの妥当性（権限の境界、金額・在庫・個人情報の扱い）
- 「なぜこの実装なのか」を説明できるか（説明責任）
- 生成コードの著作権・ライセンス上の懸念
AI生成コードの弱点は、書いた本人が「なぜ動くか」を説明できないまま本番に出てしまうことだ。レビューは正しさだけでなく、チームがそのコードを保守・説明できる状態か を確認する場でもある。
本番投入前チェックリスト
AI生成コードを業務システムへ出す前に、次を確認する。1つでも「いいえ」があれば、本番投入は保留する。
| 区分 | 確認項目 | 判定 |
|---|---|---|
| 入力処理 | 外部入力にバリデーションとエスケープが実装されているか | ☐ |
| 認証認可 | 権限判定をサーバ側で行い、画面非表示だけで隠していないか | ☐ |
| 秘密情報 | APIキー・パスワード・トークンがコードやログに直書きされていないか | ☐ |
| 依存関係 | 全パッケージが実在し、著名で、メンテされ、脆弱性がないか（SCA済か） | ☐ |
| 静的解析 | SASTで重大・高リスクの指摘が0件か | ☐ |
| 動的検証 | DASTまたは手動テストで主要な攻撃に耐えるか | ☐ |
| ログ | 不正アクセスや異常を後から追える監査ログが出力されるか | ☐ |
| 説明責任 | 担当者が「なぜこの実装か」を説明でき、保守できるか | ☐ |
| ライセンス | 生成コードや依存物のライセンス・著作権に懸念がないか | ☐ |
| 復旧 | 障害・脆弱性発覚時に切り戻せる手順とバックアップがあるか | ☐ |
このチェックはVibe Codingを禁止するためではなく、速さを活かしつつ本番審査に耐える状態に整える ためのものだ。PoCの段階から同じチェックを回せば本番化で手戻りしにくい。PoCがそのまま本番に進められるかは、PoC本番化レディネス診断で確認できる。
よくある質問（FAQ）
Q. Vibe Codingは禁止すべきですか。 A. 禁止ではなく、レビューと自動チェックを前提に運用するのが現実的です。速度の利点は大きく、問題は「無検証で本番に出す」運用にあります。チェック体制を先に整えるのが近道です。
Q. 「AI生成コードの45%が脆弱」は本当ですか。 A. Veracodeが2025年7月に公開した調査で、100超のモデルが生成したコードの45%がOWASP Top 10脆弱性を含み不合格でした（※Veracode 2025 GenAI Code Security Report）。実運用全体ではなく特定タスクの評価値ですが、無視できない水準です。
Q. 新しいモデルを使えば安全になりますか。 A. 同調査は、モデルが大きく新しくなっても安全なコードを書く能力はほぼ横ばいだと指摘しています。モデル更新では解決せず、レビューと自動チェックで担保する前提が必要です。
Q. slopsquattingへの対策は。 A. SCAで依存パッケージの実在性と脆弱性を機械的に確認し、提供元・実績・メンテ状況を人が確認します。AIが提案した名前を鵜呑みにインストールしないことが基本です。
Q. 内製チームだけで体制を組めますか。 A. SAST/SCA/DASTの常設や監査ログ設計は初回の立ち上げに知見が要ります。最初の体制設計を外部と整え、運用は内製に移すと定着しやすいです。
この記事を読むべき人
- AI支援開発（Vibe Coding）を現場で使い始めた開発リーダー
- AI生成コードを本番に出してよいか判断を求められている情シス
- 開発スピードと品質・セキュリティの両立を経営課題として見ている経営層
- 内製化を進めたいが、セキュアな開発体制をどう敷くか決めかねている担当者
GXOに相談すべきタイミング
- AI生成コードを業務システムに本番投入する前に、レビュー基準を決めたい
- SAST/SCA/DASTをCI/CDに組み込むDevSecOps体制を立ち上げたい
- 依存パッケージやサプライチェーンの安全性を点検したい
- PoCで作ったAI活用機能を、本番審査に通る状態に引き上げたい
GXOでは、AI開発・AI活用支援とDevSecOpsによるセキュア開発体制、脆弱性診断を組み合わせ、Vibe Codingの速さを活かしながら、本番投入に耐える品質とセキュリティを担保する支援を行っています。
本記事の本番投入前チェックリストは、AI生成コードのセキュリティ点検チェックリストとして無料ダウンロードできる。レビュー基準づくりや稟議の添付資料に活用してほしい。
SNSで刺さる論点
- AI生成コードの45%がOWASP脆弱性を含む（※Veracode 2025）。問題はモデルでなく「無検証で本番に出す運用」
- Vibe Codingの第二のリスクは「実在しないパッケージを信じてインストールする」slopsquatting
- 新しいモデルを待っても安全にはならない。本番前チェックリストを仕組みにする方が早い
- 「動いた」と「本番に出せる」は別物。AI時代のレビューは、保守と説明ができる状態かを問う
関連記事
- AIエージェントに社内システムを触らせる前に必要な認可・監査ログ・実行権限設計
- AI開発の発注で失敗しないための、セキュリティスキャン（SAST/DAST/SCA）の組み込み
- AI生成コードのOSSライセンスリスクと確認手順
- AI開発のCI/CDパイプライン・ガバナンス設計
参考資料
- Veracode「2025 GenAI Code Security Report」2025年7月30日 https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
- Veracode Blog「Insights from 2025 GenAI Code Security Report」 https://www.veracode.com/blog/genai-code-security-report/
- Cloud Security Alliance「AI-Generated Code Vulnerability Surge」研究ノート 2026年4月 https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/
- Trend Micro「Slopsquatting: Hallucination in Coding Agents and Vibe Coding」2025年6月 https://documents.trendmicro.com/assets/white_papers/techbrief-slopsquatting.pdf
- OWASP Top 10 https://owasp.org/www-project-top-ten/
本記事は2026年6月25日時点の公開情報をもとに作成。引用した統計は各調査の評価条件下での数値であり、実運用環境すべてに同率が当てはまるとは限らない。最新の数値・仕様は各一次情報を確認すること。
AI生成コードを本番に出す前に、レビュー基準とチェック体制を整えませんか
GXOでは、SAST/SCA/DASTの組み込み、依存関係の点検、本番投入前チェックリストの整備まで、Vibe Codingの速さを活かす安全な開発体制を支援します。
DevSecOps体制を相談する PoC本番化レディネス診断を見る
※ 開発リーダー・情シス・経営層の同席歓迎 | 内製チームの体制づくりから支援可
