バイブコーディングのアプリは安全？確認すべき8つの脆弱性

バイブコーディングで作ったアプリは安全ですか？

初期状態では安全ではありません。ここで取り上げた大規模な研究は、どれも調べたアプリの多くに深刻なセキュリティ上の穴を見つけています^[3][4][5]。アプリ自体はたいてい動きます。問題は、見知らぬ人に何を許してしまうかです。

2026年の監査は、Claude CodeとLovableで作られた9,041のオープンソースアプリを集め、そのうち公開中の200を調べました。見つかった脆弱性は1,186件で、200アプリ中182（91.0%）に少なくとも1件ありました^[4]。そのうち65.77%が「重大」または「高」と評価され、18.47%は「重大」でした^[4]。

著者らは、より良いプロンプトやエージェント設定で問題が解決するかも検証しました。問題は減りましたがなくならず、同じタスクを3回実行すると、ある回は安全、次の回は危険という結果もありました^[4]。つまり、ある回のビルドが問題なしでも、次も安全とは限りません。

手法の基本については、Pouyamのガイド「Vibe Coding Explained: What It Is, How It Works and the Real Risks」（バイブコーディングとは何か、本当のリスク）をご覧ください。最初のプロジェクトには「Vibe Coding for Beginners: How to Start Safely in 2026」（初心者向けバイブコーディング）が始め方の計画を示しています。このページはさらに一歩踏み込み、具体的な穴とそれぞれの確認方法を説明します。

セキュリティ研究はバイブコーディング製アプリに何を見つけていますか？

4つの独立した情報源が同じ弱点を指摘しています。本来見るべきでない人がデータを読んだり変更したりできることです^[1][3][4][5]。

• 公開中の200アプリの監査（2026年）：アクセス制御の不備が最大の分類で、1,186件中339件（28.58%）を占め、アプリの64.00%に影響しました。インジェクションは54.00%、認証の不備は51.50%に影響しました^[4]。
• ACM CCS 2026の研究：履歴がすべて残る8,641のLovableリポジトリでは、読み取りルールの11.2%が未ログインの訪問者に開かれており、リポジトリの61.2%にそのようなルールが少なくとも1つありました。再現テストでは、抽出した400リポジトリのうち353で露出が確認されました^[5]。
• Escape（2025年10月）：Lovable、Base44、Create.xyzなどのプラットフォームで作られた5,600以上の公開アプリを受動的にスキャンし、2,000以上の脆弱性、400以上の露出した秘密情報、そして診療記録、IBAN（銀行口座の識別番号）、電話番号、メールアドレスを含む175件の個人データを見つけました^[3]。
• CVE-2025-48757（2025年）：2025年3月21日に完了したスキャンで、1,645のLovableプロジェクトのうち170（約10.3%）に、行ルールが不十分なデータベースの接続先が303見つかりました^[1]。

Escapeは、スキャンでは破壊的な操作を一切していないため数字は下限であり、より深い検査ならさらに見つかると強調しています^[3]。ここにあるすべての数字に同じ注意が必要です。これらの研究は外部から見えたものを数えています。

なぜ人工知能ツールは安全でないアプリを作るのですか？

ツールは「動くアプリ」を目指しますが、セキュリティのルールはプロンプトにほとんど書かれない業務上の細部で決まるからです^[4][11]。

動くコードの確認は簡単です。ページが開き、ボタンが反応します。しかし、誰がどの記録を見てよいかは業務上の判断で、誰も書かなければツールは推測するしかありません。2026年の監査は、脆弱性を8つの繰り返し現れる失敗パターンに分類し、人工知能エージェントの3つの限界、つまり記憶、目的、知識にまとめています^[4]。

人工知能モデルの広範なテストでも同じ差が見られます。VeracodeのGenAI Code Security Report 2026によると、同社のテストではコード生成タスクの約44%でセキュリティ上の脆弱性が持ち込まれました^[11]。AWSが紹介したベンチマークでは、12のエージェント設定のうち最良のものでも、正しく解けたのは57%、正しくかつ安全に解けたのは11.8%にとどまりました^[10]。

さらに、多くのバイブコーディング製アプリはセキュリティをデータベースに任せています。ブラウザがホスティングされたデータベースと直接やり取りするため、そのルールが訪問者とすべての行の間にある唯一の壁になります^[1][6]。ルールがない、あるいは緩すぎれば、アドレスを知っている人なら誰でもすべてを取得できます。

まず確認すべき8つのセキュリティ上の穴は？

研究で最も多く見つかる穴から、起こりうる被害の大きい順に始めましょう^[1][3][4][5]。

1. 開いたデータベースルール：行レベルセキュリティのないテーブルや、どの訪問者にも全行の読み取りを許すルールです。CVE-2025-48757とACMの研究結果の原因はこれでした^[1][5]。
2. アクセス制御の不備：ログイン中の利用者が、アドレスやリクエスト内の番号を変えるだけで他人の記録を開けてしまう状態です。2026年の監査で最大の分類でした^[4]。
3. ブラウザ内の秘密鍵：フロントエンドのコードに置かれたSupabaseのsecretキーやservice_roleキー、決済キー、人工知能サービスのキーです。Escapeは400以上の露出した秘密情報を見つけました^[3][6]。
4. ログイン確認の欠如や不備：セッションなしでも応答する非公開ページやAPIの経路です。認証の不備は監査対象アプリの51.50%に影響しました^[4]。
5. インジェクション：利用者の入力が確認なしにデータベースへの問い合わせやHTMLに届く状態で、監査対象アプリの54.00%で見つかりました^[4]。
6. 書き込み可能なテーブル：訪問者に読み取りだけでなく、データの追加や変更まで許すルールです。CVEの事例では、ログイン用トークンのないリクエストが「支払い済み」と記された記録を追加し、支払い手続きを飛ばしました^[1]。
7. 情報を出しすぎる応答：ページには名前だけ必要なのに、利用者の記録全体やメール、トークンを返すAPIです。Escapeは露出した個人データを175件数えました^[3]。
8. 危険なエージェント権限：本番環境の認証情報を持つコーディングエージェントは実害を出しえます。2025年7月には、コード凍結中にエージェントが本番のデータベースを削除しました^[10]。

1から4の穴で外部の攻撃者が悪用するものの大半をカバーできるため、まずこれらを確認してください。

自分のバイブコーディング製アプリをどう検査すればよいですか？

攻撃者と同じようにアプリを使いましょう。見知らぬ人として、2人目の利用者として、そしてブラウザが受け取る内容を読むことで確認します^[1][4][5]。特別な道具は必要ありません。

1. テスト用アカウントを2つ作る。アカウントAで記録を作り、そのアドレスや番号をコピーし、アカウントBでログインして開く、編集する、削除するを試します。できてしまえば、アクセス制御に不備があります^[4]。
2. ログアウトして繰り返す。セッションのないプライベートウィンドウで同じアドレスを開きます。CVEの事例では、ログイン用ヘッダーを外すだけですべての確認を回避できました^[1]。
3. ネットワークタブを見る。ブラウザの開発者ツールで、ページが送る各リクエストと返ってくる内容を確認します。応答に含まれるべきはその画面に必要な情報だけで、他の利用者のメールやトークンが入っていてはいけません^[3]。
4. ページのコードで鍵を探す。sb_secret_で始まる文字列、service_roleという表記、決済や人工知能などのサービスのキーを検索します。publishableキーがあるのは普通ですが、secretキーがあれば緊急事態です^[6]。
5. 各テーブルのルールを確認する。データベースの管理画面で、すべてのテーブルで行レベルセキュリティが有効か確かめ、各ルールを平易な言葉で読み解きます。誰が読めて、誰が書けるのかです^[7]。
6. 変わった入力を試す。各フォームに非常に長い文章、引用符、HTMLタグを貼り付け、アプリが壊れないか、コードとして表示しないかを確認します^[4]。

検査するのは自分のアプリか、検査の許可を得たアプリだけにしてください。他人のアプリを書面による許可なく調べてはいけません。

開いたSupabaseのルールと漏れた鍵はどう直しますか？

すべてのテーブルで行レベルセキュリティを有効にし、厳しいルールを書き、秘密鍵はサーバーに置き、漏れた鍵はすべて交換します^[6][7][8]。

• 行レベルセキュリティをすべてで有効にする。Supabaseのガイドは、外部に公開されたスキーマのすべてのテーブルで有効にするよう述べています^[7]。有効にすると、ルールを追加するまで公開キーでは何にもアクセスできません^[7]。
• 初期設定の権限を外す。今も初期状態で権限を与えているプロジェクトでは、新しい公開テーブルは未ログイン（anon）とログイン済み（authenticated）の両方のロールにすべての権限が最初から与えられた状態で始まり、ルールを追加してもその権限は取り消されません^[7]。権限を取り消し、各ロールに必要なものだけを与え直してください^[7]。
• 利用者ごとのルールを書く。非公開テーブルのルールは、ログインした人なら誰でも許すのではなく、ログイン中の利用者の番号と一致させるべきです。機密性の高いテーブルでは、常に真となるルールを避けてください^[2]。
• 秘密鍵はサーバー側に置く。Supabaseのpublishableキーがブラウザで安全なのは、行ルールで制限されているからにすぎません。secretキーとservice_roleキーはすべてのルールを回避するため、サーバーのコードや安全な環境設定に置く必要があります^[6]。
• 漏れた鍵を交換する。秘密鍵が一度でもブラウザや公開コードリポジトリに出たなら、鍵を交換し、漏れた鍵を無効にします。これはSupabaseのキーガイドも勧めています^[6]。

2026年11月15日時点で、Supabaseのドキュメントによると、旧来のanonキーとservice_roleキーは2026年末までに廃止され、publishableキーとsecretキーに切り替わります^[8]。新しいsecretキーはブラウザで使うとエラー（HTTP 401）を返しますが、漏れた鍵は他のツールからなら使われる可能性があります^[6][8]。今のうちに移行するのは、アプリが使うすべての鍵を見直す良い機会です。

組み込みのセキュリティスキャンはすべてを見つけますか？

いいえ。プラットフォームのスキャンは役立ちますが、最も重要なルールを見逃すことが複数の研究で示されています^[1][2][5]。

2025年、CVE-2025-48757を見つけた研究者は、Lovableのスキャナーが行ルールの有無だけを確認し、正しさは確認していないことを突き止めました^[1]。彼らの勧告によると、Lovableの公開前チェックはルールのないテーブルには警告しますが、ルールが十分に厳しいかは示しません^[2]。開いたルールはこうしたチェックを通過してしまいます。

ACMの研究は数字でこれを示しています。6つのツール全体で開いたルールは6.3%とわずかでも、1つの開いたルールで十分なため、リポジトリの56.9%に露出したテーブルが少なくとも1つ残りました^[5]。著者らは、こうしたルールをコミット前に指摘する無料の確認ツールを公開しています^[5]。

スキャンは最初のふるいとして使い、2つのアカウントでの確認とログアウト状態での確認は自分で行いましょう。下の表に数字をまとめます。

他人がバイブコーディングで作ったアプリを使っても安全ですか？

個人情報、健康情報、支払い情報を求めるものには注意してください。利用者にはアプリがそれをどう守っているか見えないからです^[3][4]。Escapeは、露出したデータの中に診療記録とIBAN（銀行口座の識別番号）を見つけています^[3]。

簡単な習慣でリスクを下げられます。新しいアプリごとに別のパスワードを使えば、1つが漏れても他のアカウントは守られます。方法はPouyamのガイド「Password Managers Explained: How They Work and Whether They Are Safe」（パスワード管理ツールの仕組みと安全性）で解説しています。アプリに渡すデータは必要最小限にし、アプリ内のフォームより有名な決済事業者の支払いページを選びましょう。

主な責任は作り手にあります。他人のデータを保存するアプリを公開するなら、公開前と大きな変更のたびに上の確認を行ってください。新しい機能を1つ加えただけで、ふさいだ穴が再び開くことがあるからです^[4][5]。