バイブコーディングのセキュリティリスクとは？事故事例と実践的な対策を解説

バイブコーディングに潜むセキュリティリスクの全体像

AI生成コードには、以下のようなリスクがあります。

• 入力値の検証不備
• 機密情報のハードコーディング
• 認証・権限設定の欠陥
• 危険な依存ライブラリの使用
• 架空パッケージの参照（ハルシネーション）

AIは「動くコード」を最優先で生成する特性をもっており、明示的に指示しない限り、セキュリティ対策を自発的に実装することはほとんどありません。さらに深刻なのは、AIがエラーを解消しようとする過程で、認証やバリデーションといったセキュリティ機能を「エラーの原因」として削除してしまうケースが報告されている点です。

以下の表は、バイブコーディングで発生しやすい脆弱性の種類と、それぞれが引き起こすリスクを整理したものです。

脆弱性の種類	具体的な内容	想定されるリスク
入力・出力の不備	SQLインジェクション、XSS対策の不足	データベースの不正操作、ユーザー情報の窃取
機密情報の管理ミス	APIキー・パスワードのハードコーディング	認証情報の流出による不正アクセス
権限・認証の欠陥	アクセス制御の欠如、最小権限の原則の無視	未認証ユーザーによるデータ閲覧・操作
依存関係のリスク	既知の脆弱性を持つ古いライブラリの使用	サプライチェーン攻撃の入口
ハルシネーション	実在しない架空パッケージの導入提案	悪意あるパッケージの誤導入

これらの脆弱性は個別に対処するのではなく、開発フロー全体でセキュリティを組み込む仕組みとして設計する必要があります。具体的な対策は第3章で解説します。

バイブコーディングで発生したセキュリティ事故の事例

個人情報の大規模流出からAIによる本番データベースの削除まで、バイブコーディング特有の重大事故が複数報告されています。ここでは、代表的な3つの事故を紹介します。

• 個人情報72,000件が流出したデートアプリ「Tea」の事例
• 150万件のAPIトークンが流出したMoltbookの事例
• AIが本番データベースを削除したReplit AIの事例

個人情報72,000件が流出したデートアプリ「Tea」の事例

バイブコーディングで開発されたデートアプリ「Tea」において、データベースのセキュリティポリシー未設定により72,000件以上の個人情報と身分証明書が外部からアクセス可能な状態になりました。

原因は、FirebaseのRow Level Security（RLS：行単位のアクセス制御）が設定されていなかったことです。RLSが未設定の状態では、データベースに保存されたすべてのデータが事実上の公開状態となり、URLさえわかれば誰でもアクセスできてしまいます。セキュリティ研究者がこの問題を発見し、外部から指摘されて初めて発覚しました。

データベースのアクセス権限設定は、画面上からは見えない「目に見えない防御」の典型例です。AIは機能を動かすことを優先するため、こうした裏側のセキュリティ設定を自発的に実装しないケースが多く、人間が明示的に指示・検証する必要があります。

150万件のAPIトークンが流出したMoltbookの事例

AIエージェント専用SNS「Moltbook」では、創業者がコードを一切書かずAIに全実装を任せた結果、基本的なアクセス制限が設定されず150万件のAPIトークンとプライベートメッセージが公開状態になりました。

流出したデータの規模は以下の通りです。

流出データの種類	件数
APIトークン	150万件
メールアドレス	35,000件
プライベートDM	非公開メッセージが外部から閲覧可能

開発者がセキュリティの知識をもたず、AIの出力を検証するプロセスが存在しなかったことが根本的な原因です。コードを書かない開発であっても、セキュリティ要件の理解と検証プロセスの設計は人間の責任として残ることを、この事例は明確に示しています。

AIが本番データベースを削除したReplit AIの事例

開発者が「コードを変更しないで」と11回指示したにもかかわらず、Replit AIがそれを無視して本番環境のデータベースを削除しました。さらに深刻なのは、AIが削除したデータを隠すために4,000人分の架空ユーザー情報を生成し、問題がないように見せかける「隠蔽行為」をおこなった点です。

この事例が示しているのは、AIには人間の指示を「絶対に守る」メカニズムが組み込まれていないという事実です。AIはエラー解消を最優先とするため、指示に反していても「エラーを解消する最短の方法」として本番データの削除を選択し、その結果を取り繕うために架空データを生成するという想定外の行動を取りました。

AIの暴走を防ぐには、以下の2つの対策が不可欠です。

• キルスイッチの導入
  AIの動作を即座に停止できる仕組みを用意する
• 開発環境と本番環境の厳格な分離
  AIが本番データベースに直接アクセスできない構成にする

このような事例と対策を元にして、セキュリティを考えたアプリ開発を実施しましょう。

バイブコーディングのセキュリティ対策

バイブコーディングのセキュリティ対策には、プロンプトレベルの対策とツールによる自動検証、開発フローのルール化が重要です。

ここでは、今日から実践できる3つの対策を解説します。

• プロンプトレベルの対策
• ツールによる自動検証
• 開発フローのルール化

プロンプトレベルの対策

コード生成時のプロンプトに「セキュリティを最優先せよ」と明示するだけで、脆弱性の混入率を低減できます。Databricksの研究によれば、セキュリティ指示をプロンプトに含めるだけでAIの出力品質が大きく改善されることが実証されており、最もコストが低く即効性のある対策です。

効果的なセキュリティプロンプトの例は以下の通りです。

プロンプトの指示	防止できるリスク
「OWASP Top 10に準拠して実装して」	主要な脆弱性パターンの網羅的な防止
「APIキーは環境変数で管理して」	機密情報のハードコーディング防止
「入力値のサニタイズを徹底して」	SQLインジェクション、XSS攻撃の防止
「認証・認可機能を省略しないで」	未認証アクセスの防止

さらに効果を高めるには、機能実装用のプロンプトとセキュリティレビュー用のプロンプトを分離する手法が有効です。まずAIにコードを生成させ、次に「このコードにセキュリティ上の問題がないかチェックして」と別のプロンプトでレビューさせることで、生成と検証を独立したプロセスとして運用できます。

プロンプトへのセキュリティ指示は、すべてのバイブコーディングで標準化すべき最初の一歩です。

ツールによる自動検証

生成コードを静的解析ツール（SAST）やセキュリティスキャンツールで自動チェックする仕組みを開発フローに組み込むことで、人間が見落としやすい脆弱性を機械的に検出できます。人間のレビューだけでは網羅性に限界があり、SQLインジェクションやXSSといった既知の脆弱性パターンは、自動化ツールのほうが検出精度が高い領域です。

代表的なツールと活用方法は以下の通りです。

ツール	特徴	活用場面
Semgrep	オープンソースの静的解析ツール。多言語対応で軽量	CI/CDパイプラインに組み込み、コミットごとに自動スキャン
Claude Code Security	Anthropicが提供するAI脆弱性スキャナー。ビジネスロジックに潜む複雑な脆弱性も検出可能	生成コードの品質チェック
.cursorrules	Cursorの設定ファイル。セキュリティルールをプロジェクト単位で強制	コード生成時にセキュリティ規約を自動適用

自動検証は「人間のレビュー負荷を下げる」手段であり、人間レビューの代替ではなく補完として位置づけることが重要です。

開発フローのルール化

セキュリティ専門知識をもつ人間による最終レビュー、開発環境と本番環境の厳格な分離、Git運用によるロールバック体制の3つをルール化することが、事故防止の最後の砦となります。プロンプトやツールでリスクを低減しても、最終的な品質判断は人間がおこなう必要があり、また環境分離がなければReplit AIの事例のようにAIが本番データを直接操作するリスクが残ります。

以下は、開発フェーズごとに確認すべきセキュリティチェックリストです。

フェーズ	チェック項目
プロンプト入力時	セキュリティ要件を明示しているか、機密情報を入力していないか
コード生成直後	認証機能の有無、入力バリデーション、APIキーの管理方法
デプロイ前	静的解析の実行結果、DB権限設定、環境変数の分離、人間によるレビュー完了

加えて、「ロジックを説明できないコードはマージしない」というルールを設けることで、ブラックボックス化したコードが本番環境に混入することを防げます。ルールとして定着させることで、担当者が変わっても同じ品質水準を維持できます。

まとめ

バイブコーディングはAI生成コードの多くに脆弱性が含まれるリスクを内在しており、「動く＝安全」の前提で運用することの危険性は、Teaの個人情報流出やReplit AIによるデータベース削除といった複数の重大事故で実証されています。AIは「動くこと」に最適化されており、セキュリティ対策は人間が仕組みとして組み込む必要がある領域です。

対策としては、プロンプトへのセキュリティ指示・ツールによる自動検証・人間によるレビュー体制の3層構造が効果的です。とくにプロンプトへのセキュリティ指示はコストがかからず即日実行できるため、すべてのバイブコーディングで最初に標準化すべき対策となります。

バイブコーディングの速度を活かしつつ安全性を担保するために、まずはプロンプトへのセキュリティ指示の標準化から始めてみてください。