99％の組織が直面「バイブコーディングが量産する脆弱なコード」 その具体例と理由、回避策：“AI任せ”に潜む落とし穴

生成AIによる「バイブコーディング」が急速に普及する一方で、脆弱なコードの増加が新たな課題として浮上しています。AIは何を間違え、どのような脆弱性を生み出すのでしょうか。

[雨輝ITラボ（リーフレイン）, 編集：平田修，＠IT]

　生成AIによるコード生成は、開発プロセスの中でコーディングのスピードを大きく向上させました。しかしその裏で、コードレビューや脆弱（ぜいじゃく）性修正が追い付かないといった問題も顕在化しています。

　「バイブコーディング」（Vibe Coding）とは、自然言語でAIに指示を出し、アプリケーションの実装やコード生成を大幅にAIに委ねる開発スタイルを指します。近年はAIコーディングエージェントの普及によって利用が広がっていますが、生成されたコードの安全性を巡る懸念も高まっています。

　Palo Alto Networksが2025年12月に発表した「State of Cloud Security Report 2025」（情報セキュリティ部門に所属する2800人以上が対象）によると、99％の組織が「バイブコーディング」を利用していると回答しました。セキュリティレビューより速いペースで安全でないコードが生成される状況で、コードを週次でリリースする52％のチームのうち、「同じペースで脆弱性を修正できている」と回答したのはわずか18％でした。

• 参考記事：「バイブコーディングが脆弱なコード量産」　99％の組織が直面　レビューや修正リリースを上回るペースで

　バイブコーディングはどのような脆弱性を生み出しているのか。本記事では最新調査や検証結果を基に、具体的なリスクと対策を整理します。

「バイブコーディングが生む脆弱なコード」具体的には？

　東京大学先端科学技術研究センターの客員研究員で工学部の非常勤講師、多摩大学大学院の特任教授を務める西尾素己氏は、汎用（はんよう）LLM（大規模言語モデル）によるバイブコーディングが抱えるリスクとして、「コードハルシネーション」と「パッケージハルシネーション」を挙げています。

　コードハルシネーションとは、存在しない関数や誤った関数を呼び出してしまう現象です。一方、パッケージハルシネーションとは、存在しないパッケージ名を生成してしまう現象を指します。

コードを書けないバイブコーダーの増加は、サイバー攻撃者にとって養分でしかない

　AIは短いコードで機能を実装しようとするため、多数の外部モジュールに依存する傾向があります。その結果、開発者が十分に確認しないまま外部パッケージを取り込んでしまい、サイバー攻撃者が汚染したライブラリを経由して侵害されるリスクが高まります。攻撃者はこれに目をつけ、外部パッケージ自体を汚染することで多数のソフトウェアを一気に侵害する「ソフトウェアサプライチェーン攻撃」を仕掛けてくるのです。

　こうした攻撃の脅威は既に現実のものとなっています。2022年に登場したサイバー犯罪グループLofyGangは、OSS（オープンソースソフトウェア）のコミッターに金銭的報酬を提示してバックドアを混入させる攻撃を展開しました。

　2026年には、著名なセキュリティスキャンツール「Trivy」のGitHubリポジトリが汚染され、1000社以上の企業にバックドアが仕込まれた事件も起こっています。バイブコーディングで開発されたソフトウェアに汚染されたパッケージが取り込まれると、サイバー攻撃の格好の標的となるのです。

• 参考記事：「バイブコーダーの増加はサイバー攻撃者にとって養分でしかない」　その理由とは

SQLインジェクションやXSSは回避できても安心できない

　AIコーディングエージェントは脆弱性に全く対応できないわけではありません。

　サイバーセキュリティ企業Tenzaiは2025年12月、「Cursor」「Claude Code」「OpenAI Codex」「Replit」「Devin」という5つのコーディングエージェントのセキュアコーディング能力を比較したベンチマークテストを実施しました。

各エージェントが構築したアプリケーションに含まれていた脆弱性の数（提供：Tenzai）

　その結果、SQLインジェクションやXSS（クロスサイトスクリプティング）といった明確な対策方法がある脆弱性は回避する傾向が高いことが確認されました。パラメーター化クエリの利用やフレームワークの保護機能を活用し、悪用可能なSQLインジェクションやXSSは確認されなかったとしています。

　一方で、5つに共通した弱点として次の3つが見つかりました。

認可の不備

　認可ロジックが複雑になると、プロンプトで明確な指示を与えても適切な認可が実装されないケースが頻発しました。

　例えばCodexがショッピングサイトを構築した際、異なるロールのユーザーがシステム内の全注文にアクセスできる状態になっていました。Claude Codeが注文削除APIへの未認証アクセスを誤って許可する欠陥を生じさせた事例もあります。

ビジネスロジックの脆弱性

　人間の開発者なら直感的に理解できるワークフローの常識を、コーディングエージェントは持ち合わせていません。

　そのため、「注文数量は正の数でなければならない」と明示しなかった場合、5つのエージェントのうち4つが検証せず、攻撃者が負の合計金額で注文できる状態になっていました。詳細な仕様がなければ重要な細部を見落とすリスクが高く、複雑なビジネスロジックを含むシナリオではこの傾向がさらに悪化する可能性があります。

SSRF（サーバサイドリクエストフォージェリ）の問題

　SQLインジェクションやXSSと異なり、SSRFは汎用的な対策では防ぎにくい脆弱性です。正当なURL取得と悪意あるURL取得の区別はコンテキストに大きく依存するからです。

　テストでセキュリティに関するガイダンスを一切与えずにリンクプレビュー機能を実装させると、5エージェント全てがSSRFの脆弱性を発生させ、攻撃者が任意のURLにリクエストを実行できる状態になりました。

• 参考記事：5大コーディングエージェントの比較で分かった「バイブコーディング」の落とし穴

“AI任せ”のコードに潜む4つのワナ

　Trend Microは、AIが生成するコードに潜む代表的なリスクとして4つの問題を挙げています。

1．意図しない依存関係

　OAuthログインのプロンプトが、開発者が明示的に選択していないヘルパーライブラリやスターターテンプレートを取り込む場合があります。

2．危険なデフォルト（規定）設定

　生成されたサービスが、デモ用には問題ないが本番環境では危険な、過剰なログ設定や広過ぎるネットワークバインディングを引き継いでしまう場合があります。

3．脆弱なシークレット処理

　一時的に入力していたシークレット（認証情報や秘密鍵）やテストトークンがそのまま残留するリスクがあります。

4．正常系のみのロジック

　エラーのない通常処理は問題なく動作しても、不正アクセスや権限逸脱、例外処理などが考慮されていないコードになりやすいとされています。

　上記のリスクは「ちょっとしたヘルパー関数」として過小評価されがちなものです。しかし、Trend Microはセキュリティ負債は1つの重大なミスではなく、デプロイのプレッシャーの下で行われる無数の合理的な判断の積み重ねで形成される点が重要だとしています。

セキュリティ負債が無数の判断の積み重ねで形成されるプロセス（提供：Trend Micro）

なぜ脆弱なコードが生まれるのか

　こうした問題は、開発者の能力不足だけで説明できるものではありません。なぜ起こるのかを理解しておく必要があります。

「動くかどうか」が優先される開発スタイルへの変化

　Trend Microは、バイブコーディングによって開発者の意識が「コードが動くかどうか」に集中しやすくなったと指摘しています。

　従来はコードを書く、レビューする、議論する、テストするという工程が自然に組み込まれていました。しかしAIを利用した開発では、生成されたコードがすぐ動作するので、「安全かどうか」「何をしているコードなのか」という確認が後回しになりがちです。

　その結果、基本的なテストは通過しても、脅威モデリングや深いセキュリティレビューを経ないまま本番環境に投入されるリスクが高まります。

従来の開発フローとバイブコーディングの違い（提供：Trend Micro）

責任の所在が分散してしまう

　Trend Microは指摘するもう一つの問題は責任の断片化です。AI生成コードでは、プロンプト作成者、AIエージェント、レビュワー、サービスオーナーなど複数の関係者が存在します。それによって「なぜこのコードを書いたのか」「なぜこのライブラリを採用したのか」といった意思決定の背景が失われやすくなります。

　さらに、コード生成とレビューの両方を同じAIに任せるケースでは、職務分離の原則そのものが機能しなくなる可能性も指摘されています。

• 参考記事：「バイブコーディングは危険」はもう古い　“AI任せ”のコードに潜む4つのワナと回避策

脆弱性リスクを低減するための対策

　AI活用をやめることは現実的ではありません。重要なのは、AIが脆弱性を生み出す前提で開発プロセスを再設計することです。

AIが生成するコードをセキュアにするための3つの教訓

　Tenzaiは「現時点では、どのコーディングエージェントを使ってアプリケーションを構築しても、脆弱性が発生することはほぼ確実だ」とした上で、コーディングエージェントが生成するコードのセキュリティを向上させるための3つの教訓を示しています。

・重要なセキュリティ対策は明示的に指示する

　コーディングエージェントに重要なセキュリティ対策を実装させるには、ツール任せにせず、開発者がプロンプトなどで明示的に指示を与える必要があります。

・適切なコンテキストを与える

　認可やビジネスロジックのようなコンテキスト依存の判断は、AIが苦手であることを前提にすることが重要です。

・能力向上に頼らない「テスト」の徹底

　AIモデルのコーディング能力が向上しても、脆弱性は残ります。最終的には継続的なテストが最も有効な対策です。

開発スピードを落とさずにリスクを下げるための4つの方策

　Trend Microは、バイブコーディングが定着した現実を前提に、ソフトウェア開発プロセスに有効なセキュリティ対策を適応させる4つの実践的なポイントを挙げています。

・問題を早期に検知する

　遅いアラートより早いシグナルが有効です。開発プロセスの早い段階でセキュリティ情報を提示すれば、開発を助けるガイダンスになります。

・ガードレール（安全対策）を自動化する

　セキュリティガードレールを自動化することで、開発者の記憶や注意力に依存しない仕組みを整備します。

・共有コンテキストに集中する

　開発チームとセキュリティチームが同じ情報を共有できる環境を整えることも重要です。

・セキュリティをワークフローに最適化する

　作業を止めないセキュリティをワークフローそのものに組み込み、開発を止めるのではなく支援する仕組みに変えます。

---

　従来、業務アプリの内製化の必要性が高まっており、バイブコーディングは今後さらに普及するとみられています。Trend Microも「バイブコーディングは無謀な行為ではない。無謀なのは、そのリスクを無視することだ」と指摘しています。

　脆弱性を発見、修正する手段として、開発ツールベンダーやセキュリティベンダーはもちろん、AIエージェント提供事業者も新機能を提供し続けています。それらや上記ガードレールを開発プロセスにいかに適用するか。企業・組織は、開発者のためにAIを前提とした仕組みを構築する必要があります。

　脆弱性を含むバグを減らすために、複数のAIエージェントにテストやバグの発見、修正などコーディング以外も任せるエージェンティックエンジニアリングやハーネスエンジニアリングといった考え方も広まりつつあり、既に実践している企業も出てきています。

　いずれの手段を採るにせよ、AIが生成したコードを人間がどのように理解、検証し、責任を持って活用するか。そこが安全な開発の分岐点になりそうです。