Vibe Coding を本番環境に出すコスト:セキュリティ脆弱性、スケール障害、実践サバイバルガイド
3 回の週末で Lovable を使ってアプリを作った。機能は揃い見た目もきれい。Product Hunt でローンチする準備は万端。しかし考えたことがあるだろうか——データベースに誰でもアクセスできないか?AI が API キーをフロントエンドに書き込んでいないか?認証ロジックが逆転していないか?実際のテストと複数の研究によると、これらは 2026 年 2 月に発生した実際のインシデントだ。エンジニア経験なしで実行できるセキュリティチェックポイントを提供する。
TL;DR
- Veracode:100+ AI モデルテスト、45% で OWASP Top 10 脆弱性を含むコード生成
- Escape.tech:5,600+ アプリスキャンで 2,000+ 脆弱性、400+ シークレット漏洩を発見
- 2026 年 2 月:Lovable アプリで 18K+ ユーザー漏洩、Moltbook で 150 万認証トークン流出
- 最大リスクはコード品質ではなく DB デフォルト設定(RLS 無効)と API キーのハードコード
45%:AI が書くコードはどれほど安全でないのか
Veracode 2025 GenAI Code Security Report は 100+ LLM を 80 のコード補完タスクでテスト。45% で AI が安全でない実装を選択し、OWASP Top 10 脆弱性を導入した。XSS 失敗率 86%、Java 72%、SQL Injection 20%。
これはコード補完タスクであり「アプリに 45% の確率で脆弱性がある」とは直接言えない。しかし実際の観察から、ベースライン警戒値としては妥当だ。CodeRabbit は 470 PR を分析し XSS 導入率が人間の 2.74 倍、Tenzai Security は 5 ツールで 15 アプリを作り全ツールが SSRF を導入した。
第 1 の関門:RLS が静かにすべてを漏洩している
Lovable/Bolt のバックエンドはほぼ Supabase。Retool/Beesoul データによると約 70% の Lovable アプリで RLS が無効。Escape.tech は 170 アプリに重大 RLS 脆弱性を確認。Lovable にはスキャナーがあるが公開前は任意で必須ではない。
確認方法:Supabase > Authentication > Policies で全テーブルの RLS ポリシーを確認。
第 2 の関門:API キーがプロンプトから漏洩する
AI がキーをハードコード → デプロイ → フロントエンド JS が公開 → Google がインデックス。Escape.tech は 400+ の漏洩シークレットを発見。.env と環境変数を使い、GitHub Secret Scanning を有効にすること。
第 3 の関門:認証ロジックの逆転
The Register によると Lovable の試験アプリで 認証ロジックが完全逆転——ログインユーザーが拒否され未認証者がアクセス可能。18,697 ユーザーが被害。curl でトークンなしの API アクセスをテストし、401/403 が返ることを確認すべき。
スケーリングの崖
The New Stack:「50 ユーザーなら問題なし、5,000 で負債、50,000 でインシデント」。N+1 クエリ、コネクションプール枯渇、レートリミットなし、モニタリングなしが根本原因。Upstash Redis + Sentry + k6 で対策可能。
実際のインシデント(2026 年 2 月)
Lovable 試験アプリ:16 脆弱性、18,697 ユーザー漏洩。Moltbook:150 万認証トークンと 35K メール漏洩。共通パターン:セキュリティレビューなしで実ユーザーデータを公開。
エコシステム現状
Lovable:4 スキャナーあり(任意)。Bolt:スキャンなし。Cursor/Claude Code:コードアシスタント型で異なるリスクプロファイル。どのツールもデフォルトが安全とは仮定しないこと。
関連:Vibe Coding 入門、モバイルアプリの落とし穴
15 項目チェックリスト
優先度 1(今日)
- Supabase RLS:全テーブルにポリシーあり
- GitHub Secret Scanning 有効
- Lovable Security Scan 実行
-
.envが git 履歴にない -
NEXT_PUBLIC_/VITE_変数にシークレットなし
優先度 2(今週中)
- 不正トークンでの API テスト(401/403 を期待)
- レートリミット追加
- CORS をドメイン限定
- Sentry でエラーモニタリング
- service_role key がフロントエンドにない
優先度 3(ローンチ前)
- AI セキュリティレビュー
- k6 ロードテスト
- DB バックアップ確認
- インシデント対応計画
- 高リスクアプリは外部監査
結論
条件付きで本番投入可能。15 項目チェックリスト完了後の vibe-coded アプリは、レビューなしの従来型開発より安全かもしれない。vibe coding のスピードは強みだが、削減した開発時間の一部をセキュリティに再投資すべき。
FAQ
Vibe coding で作ったものを商用プロダクトに使えますか?
条件付きで可能です。RLS 検証、シークレットスキャン、認証テスト、レートリミットのチェックリストを完了すれば使えます。これらをスキップすればユーザーデータでギャンブルしているのと同じです。
エンジニアでなくてもセキュリティ問題に対処できますか?
基本的なものは可能です。Lovable のスキャナー、Supabase の RLS 確認、GitHub Secret Scanning はすべて UI があります。ただし金融・医療データを扱う場合はセキュリティ専門家の監査を推奨します。
「AI コードの 45% に脆弱性」とはどの研究ですか?
Veracode が 100+ AI モデルを 80 タスクでテスト。45% で安全でない実装を選択。コード補完タスクのテストであり、アプリ全体に直接適用はできませんが、レビューなしでは体系的な盲点を持つシステムと協業していることを意味します。



