バイブコーディングをはじめとするAIコーディングの普及により、Cursor、Claude Code、GitHub CopilotなどのAIコーディングツールが開発現場に急速に浸透しています。開発スピードは上がった一方、生成コードのレビューが追いつかないことを課題とする開発現場も少なくありません。
本記事では、バイブコーディングに潜むセキュリティリスクと、見落としがちなレビューのポイントを解説します。
バイブコーディングの普及とレビューが追いつかない現場
開発スピードとレビュー体制の乖離
バイブコーディングの現場では、プロンプト一つで画面もAPIも一気に組み上がります。以前なら数日かかっていた実装が、数時間で終わることも珍しくありません。
開発スピードが上がったことは間違いありませんが、レビュー体制がそれに比例して強化されたとは限りません。生成されるコード量が増えても、セキュリティの観点でのレビュー工数は従来のまま、というプロジェクトも少なくないはずです。実際、大手セキュリティ企業の調査でも、生成されたコードの4割超に何らかの脆弱性が確認されたと報告されています(詳しくは次の章で解説します)。「早く動くものができた」という達成感の裏で、レビューの網の目が粗くなっている可能性があります。
バイブコーディングとは
バイブコーディングとは、AIコーディングツールに大まかな指示(プロンプト)を与え、コードを生成するスタイルを指します。非エンジニアが詳細を細かく確認せずとも開発を進めることが可能です。この言葉は、AI研究者のAndrej Karpathy氏が2025年2月2日にX(旧Twitter)で提唱したことをきっかけに広まりました。
本記事では、このような開発スタイルを「バイブコーディング」として説明します。ただし、紹介する調査や事例には、AIコーディング全般を対象としたものも含まれます。
出典：Andrej Karpathy氏のX投稿(2025年2月2日)
バイブコーディングのセキュリティリスクを示すデータ
「実際どれくらいリスクがあるのか」という疑問に、客観的なデータで答えていきます。
OWASP Top10相当脆弱性の検出率45%
セキュリティ企業Veracodeが2025年7月30日に公開した「2025 GenAI Code Security Report」では、主要な生成AIモデルに一般的なタスクをコーディングさせたところ、生成されたコードの45%にOWASP Top10相当の脆弱性(Webアプリでよく起こる代表的な10種の脆弱性カテゴリ)が検出されました。半数以上には目立った脆弱性がなかった一方、4割超という数字は素通りできる水準ではありません。
出典：Veracode「2025 GenAI Code Security Report」
AI利用時のSQLインジェクション発生率36%
スタンフォード大学のPerry氏らが実施し、セキュリティ分野の査読付き国際会議CCS’23で発表された実験(arXiv:2211.03622)では、AIコーディングアシスタントを使用した開発者グループの36%が、SQLインジェクションに脆弱なコードを書いていました。AIを使用しなかったグループは7%(いずれもN=47)で、AIコーディングアシスタントの利用によって、脆弱な実装につながる可能性を示した結果といえます。
XSS対策の失敗率86%
同じVeracodeの調査では、クロスサイトスクリプティング(XSS、CWE-80)への対策について、86%のケースでAIが適切な防御コードを書けていなかったことも報告されています。①のOWASP Top10全体の検出率(45%)とは母数の取り方が異なりますが、XSSに絞った対策失敗率はさらに高い水準です。レビュー観点を絞り込むうえで参考になります。
レビューの網の目からこぼれやすい3つの具体パターン
「AIのせいにするな」「うちはちゃんとレビューしている」という声もあるかもしれません。ここで扱いたいのは責任の所在ではなく、運用のどこに穴が生まれやすいかという点です。とくに見落とされやすいのが、次の3つのパターンです。
①認証・認可の実装漏れ
見落とされやすい1つ目が、認証・認可の実装漏れです。認証とは「本人確認」、認可とは「その人が何にアクセスできるかという権限確認」を指します。この2つは混同されがちですが、実装ではそれぞれ別に考える必要があります。
AIコーディングツールは、ログイン機能(認証)は素直に実装する一方、「ログイン後のユーザーが他人のデータにアクセスできないか」という認可のロジックは、明示的に指示しない限り作り込まないことがあります。この失敗率を示す一次データはありませんが、認証と認可を分けてレビューする観点自体が、見落とし防止の第一歩になります。
②クラウド設定・公開範囲のミス
2つ目は、クラウド設定・公開範囲のミスです。アクセス範囲を絞る設定がされないまま公開されてしまうケースなどを指します。
2026年2月、Wiz社のブログは「Moltbook」というアプリの事例を報告しました。Supabaseの行レベルセキュリティが未設定のまま公開され、約150万件のAPIトークンや約3.5万件のメールアドレスが外部から閲覧できる状態でした。開発者本人が「一行もコードを書いていない」と発言していた点も、AIがコードを生成しても、クラウド側の公開設定までは自動で安全になるわけではないことを示す事例といえます。
同様の傾向は他の調査でも指摘されています。2026年5月に公表されたRedAccess社の調査では、AIを利用して開発された約38万本のアプリケーションのうち約5,000件で機密情報の漏洩が確認されたと報じられています。主な原因は、プラットフォームのデフォルト設定が「公開」のままだったこととされています。
出典：
Wiz「Exposed: Moltbook Database Reveals Millions of API Keys」
RedAccess社調査の報道記事(vibegraveyard.ai)
③認証情報をコードに直接書き込んでしまう問題
3つ目は、APIキーやトークンといった認証情報を、コードの中に直接書き込んでしまう問題です。本来は環境変数や設定ファイルなど、コードとは別の場所で管理すべき値を、そのままソースコードに固定して埋め込んでしまう状態を指し、「ハードコーディング」と呼ばれます。
香港中文大学の研究者らが実施し、セキュリティ企業GitGuardianが紹介した調査では、GitHub Copilotに900件のプロンプトでコード生成をさせたところ、提案されたコードの33.2%にAPIキーやパスワードなどの機密情報（シークレット）が含まれていたと報告されています。
先述のMoltbookの事例でも、クライアント側のJavaScriptにAPIキーが直接埋め込まれていたことが、情報露出の一因でした。サーバー側の設定ミスだけでなく、コードそのものに機密情報が書き込まれる点は、レビューで重点的に確認したいポイントです。
出典：GitGuardian「Yes, GitHub Copilot Can Leak Secrets」
AIが実在しないライブラリ・パッケージを提案するリスク（Package Hallucination）
Package Hallucinationとは
Package Hallucination（パッケージ ハルシネーション）とは、AIコーディングツールが存在しないライブラリやパッケージ名を、あたかも実在するかのように提案してしまう現象です。
2024年6月に公開され、USENIXでも取り上げられた大規模な実証研究（arXiv:2406.10279）では、主要なLLMが提案したパッケージ名のうち19.7%が実在しないものだったと報告されています。
偽のパッケージをインストールしてしまうリスク（Slopsquatting）
攻撃者が、AIが提案しそうな架空のパッケージ名で偽のパッケージを公開しておくと、開発者が実在するライブラリだと思い込み、誤ってインストールしてしまう恐れがあります。このような攻撃手法はSlopsquatting（スロップスクワッティング）と呼ばれます。
現時点では、研究者が防御目的で先回りしてパッケージを登録した事例が報告されている段階ですが、AIコーディングツールの普及に伴い、今後注意すべきリスクの一つと考えられています。
自社プロジェクトのセルフチェック観点
ここまでの内容を、自社プロジェクトの点検観点として整理します。いずれも、コードを書く段階で開発者自身の目で確認できる項目です。
- 認証・認可では、権限のないユーザーが他人のデータにアクセスできる状態になっていないか
- アクセス制御設定では、データベースやストレージの公開範囲が意図した通りに絞られているか(行レベルセキュリティの設定を含む)
- 認証情報の管理では、APIキーやトークンがコードの中に直接書き込まれていないか
- 依存パッケージについては、AIが提案したライブラリ名が実在し、公式に配布されているものか
こうした観点で目視確認を行うだけでも、レビューの網の目からこぼれやすい落とし穴の多くは防げます。
第三者への相談を特に検討したいケース
ここまでの観点を自分たちで点検するだけでは判断がつかない、あるいは不安が残るケースもあるかと思います。
特に次のような条件に当てはまる場合は、早めに第三者へ相談することをおすすめします。
- 患者情報、決済情報、人事情報など、機微な個人情報を扱うアプリケーションである
- 社内にプログラムやセキュリティに詳しい担当者がおらず、生成されたコードの妥当性を自分たちで判断できない
- 社内向けの試作段階を超えて、本格的に運用を始めようとしている
- 社外のユーザーがアクセスする、またはログイン・会員登録の機能を持っている
まとめ
バイブコーディングをはじめとするAIコーディングは、開発スピードを大きく向上させる一方で、レビューのあり方も変えつつあります。
AIが生成したコードをそのまま利用するのではなく、認証・認可、アクセス制御、認証情報の管理、依存ライブラリなど、見落としやすいポイントを意識して確認することが重要です。
また、目視でのレビューだけでは判断が難しいケースや、外部公開するWebアプリケーション、機微な情報を扱うシステムでは、第三者による脆弱性診断を活用することで、実際に攻撃可能な状態になっていないかを客観的に確認できます。
バルテスでは、Webアプリケーションやプラットフォームを対象とした脆弱性診断のほか、実際に侵入可能かどうかまで検証するペネトレーションテストも提供しています。AIを活用した開発に不安がある場合は、開発フェーズやシステムの特性に応じてご活用ください。
（コンテンツ編集部）