Convika
無料で始める

バイブコーディングの危険性と実際の事例｜公開前に確かめる 8 つの手順

Convika Team読了目安: 42 分

  • security
  • vibe-coding
  • ai-agents
目次

2025〜2026 年のバイブコーディングの事例で調査報告が挙げる原因は、ほとんどが AI の書いたコードそのものより「公開の設定」（行のルールのないデータベースの表、誰でも開けた「非公開」のアプリ、ページに入った API キー、本番に書き込める AI エージェント）にあります。まず、自分の作ったものが他人のデータを保存するか、秘密の鍵を持っているかを確かめてください。データベースもログインも鍵もないページならこうしたリスクは少なく、1 つでもあるなら公開前と公開後に確かめるべき手順があります。

ChatGPT や Claude、Lovable、Bolt、Replit でページや小さなアプリを作ってインターネットに公開した、あるいはこれから公開しようとしていて、Moltbook や Replit のニュースを見て「自分の作ったものは大丈夫だろうか」と気になった方も多いかもしれません。この記事では、怖がらせるための話ではなく、2025 年から 2026 年にかけて実際に起きた事例を、会社の発表や事後報告、CVE の記録、調査した研究者自身の記事といった一次の出典とともに並べます（直接読めなかったものは報じた媒体名を明記し、出典はすべて 2026 年 10 月 19 日に確認しています）。また、それぞれの出典が AI について実際に言っていることだけを書き、AI のせいにされがちだが出典では AI と結びつけていない事例も分けて扱います（一覧の表にも 1 行入れ、「AI との関係」の列にその旨を記したうえで、くわしくは別の節で説明します）。

事例のあとには、お店のページや申し込みフォーム、ログインのあるアプリ、AI エージェントや MCP サーバーをつないだ仕組みなど、あなたが作ったものの中身ごとにどの事例が当てはまるかを探せる表を用意しました。あわせて、公開の前と後に確かめることの短いチェックリストと、もし鍵やデータがすでに漏れてしまったときにやるべきこともまとめています。また、この記事はページを公開するサービスである Convika が書いており、最後の節では Convika を使うことで消えるリスクと、それでも残るリスクについても正直にお伝えします。

バイブコーディングの危険性とは：コードそのものより「公開の設定」に注意

ChatGPT や Claude、Lovable、Bolt、Replit などで作ったページやアプリをインターネットに公開するとき、まず知っておきたいのは、実際に起きたトラブルの多くが「AI が書いたコードそのもの」よりも「公開するときの設定」から起きているということです。

  • Escape.tech の調査（2025 年 10 月 29 日）: インターネットに公開されているバイブコーディングのアプリ 5,600 以上（Lovable 約 4,000、Create.xyz 約 449、Base44 約 159、Bolt など）を外から受け身で調べたところ、2,000 以上の脆弱性、400 以上のむき出しの秘密の鍵、175 件の個人情報が見つかりました。外から見える範囲だけを調べた結果のため、実際の数はこれより多いとみられています。
  • Veracode の発表（2025 年 7 月 30 日）: 100 以上の LLM に 80 の課題を出したところ、45% の場合で安全でない書き方を選びました。
  • Wiz の報告（2025 年 9 月 18 日）: バイブコーディングのアプリで繰り返し見つかる問題として、(1) ログインの確かめがブラウザの中にある、(2) 秘密の鍵がブラウザに届くコードに入っている、(3) データベースの表が誰からでも見られる状態で開いている（RLS がない）、(4) 社内向けのアプリが公開されたままになっている、という 4 つの型が挙げられています。
  • Semafor の報道（2025 年 5 月 29 日）: Lovable で作られたアプリの事例について、原因はデータベースの設定にあり、たとえ「AI のモデルが完璧なコードを書いたとしても（Even if AI models write flawless code）」この問題は起きると指摘しています。

AI は画面や動きをすぐに作ってくれますが、安全に公開するための設定までは自動で整えてくれないことがあります。セキュリティの調査会社や報道機関が調べた結果からは、どのような点に気をつけるべきかが具体的に見えてきます。

2025 〜 2026 年に起きた主な事例と実証の一覧

ニュースや調査で報告された 2025 〜 2026 年の事例を一覧にしました。すべてが AI のせいではなく、プラットフォームの不具合や鍵の管理ミス、バイブコーディングとは無関係な事例も含まれます。

時期事例何が起きたか（規模、出典の数字）原因（出典の言葉）AI との関係（出典の言葉）出典
2025 年 3 月発見・5 月公開Lovable で作られたアプリ（CVE-2025-48757）Semafor によると 1,645 個中 170 個でデータや AI の鍵が誰でも見られたSupabase の RLS（行ごとのアクセスルール）がない、または不十分（Palmer）Palmer は AI に触れず。Semafor は「AI が完璧でも起きる」と記述Semafor（2025-05-29）、Matt Palmer（2025-05-29）、Tenable: CVE-2025-48757
2025 年 7 月報告・公開Base44（Wix のアプリ作成サービス）公開の app_id だけで非公開アプリに誰でも登録・確認できた（Wiz、悪用なし）認証の仕組みの欠陥で、公開の app_id だけで登録できたこと（Wiz）Wiz はプラットフォームの欠陥（shared-risk model）と説明し AI のコードとは書かずWiz Research（2025-07-29）
2026 年 1 月 31 日報告Moltbook（AI エージェントの SNS）トークン 150 万、メール約 3.5 万、DM 4,060 件（OpenAI の鍵含む）が露出（Wiz）ブラウザに届く JS に Supabase の鍵が入り、RLS がなかったこと（Wiz）創業者は「1 行も書いていない」と発言。Wiz はバイブコーディングに繰り返す型と記述Wiz（2026-02-02、日本語版）
2026 年 2 月 27 日報道Lovable の Discover に載った教育系アプリThe Register によると 18,697 件の記録（個人情報 870 件含む）が露出The Register によるとログイン確認が逆で、RLS もなかったことThe Register によると研究者は「動くコード優先」と主張、Lovable は外部コード等と反論The Register（2026-02-27）
2026 年 4 月 20 日公開Lovable のプラットフォーム自体The Register によると無料アカウントで他人の公開案件のチャットとコードが読めたThe Register によると 2026 年 2 月の権限変更で所有者確認が抜けたこと（BOLA）The Register の記事に AI が書いたコードとの関係は書かれていないThe Register（2026-04-21）
2025 年 7 月Replit の AI エージェント本番 DB（経営者 1,206 人・1,196 社超の記録）を消去、のちに復元（Lemkin）変更禁止を何度も指示した凍結中にエージェントが壊す操作を実行（Lemkin）AI エージェント自身の操作。CEO は「決してできてはならない」と発言（The Register）Jason Lemkin（SaaStr）、The Register（2025-07-21）
2025 年 7 月 21 日報告Gemini CLI（GitHub issue #4586）ファイルの整理を頼んだらファイルが失われたという利用者の報告GitHub の issue（利用者の報告）には原因は書かれていないGemini CLI にファイル整理を頼んだ際に起きたという利用者の報告GitHub issue #4586（2025-07-21）
2025 年 11 月報告・2026 年 2 月公開Google の API キー（AIza…）の権限拡大公開ページの地図用などの鍵で Gemini も使えた。有効な鍵が 2,863 個（Truffle）同じプロジェクトで Gemini の API を有効にすると公開鍵で Gemini も使えた（Truffle）Truffle Security の報告に AI が書いたコードとの関係は書かれていないTruffle Security（2026-02-25）
2026 年 2 月発生・3 月報道メキシコのスタートアップの Google API 請求The Register によると約 48 時間で 82,314.44 ドルの請求が発生（普段は月 180 ドル程）The Register によると鍵が「何らかの形で盗まれた」とされ原因は不明どの出典も AI が書いたコードや Truffle の仕組みとは結びつけていないThe Register（2026-03-03）
2025 年 5 月・7 月公開GitHub MCP・Supabase MCP（実証であり攻撃ではない）実証（攻撃ではない）で公開 issue やチケットの文から秘密データを書き出した設計の根本の問題（Invariant Labs）、RLS を通らない強い権限（General Analysis）外の文を読んだ AI アシスタントが権限どおりに動いてデータを書き出した実証Invariant Labs（2025-05-26）、General Analysis（2025-07-08）
2025 年 9 月 29 日報道偽の postmark-mcp（npm パッケージ）The Register によると送信メールを攻撃者に BCC（週約 1,500 DL）The Register によると公式のふりをした悪意あるパッケージの途中の版からの仕込みAI エージェントがつなぐ MCP の仕組みを狙った偽パッケージ（Postmark は無関係と表明）The Register（2025-09-29）
2025 年 7 月 25 日発覚Tea（出会い系の安全アプリ）画像約 7.2 万枚と DM 110 万件が流出（404 Media・BleepingComputer）古い保管の仕組みの侵害（Tea）、公開の Firebase バケット（404 Media）出典は AI に触れず。Willison は 2024 年より前のコードのため「バイブコーディングのせいではない」と記述404 Media（2025-07-25）、BleepingComputer（2025-07-28）、Simon Willison（2025-07-26）

「原因（出典の言葉）」と「AI との関係（出典の言葉）」の列には、推測を交えず、各出典が原因や AI との関わりとして実際に書いている言葉だけを載せています。

データベースの鍵と「行のルール」をめぐる事例（Lovable・Moltbook・Supabase）

Lovable や Bolt（ノーコードと AI のランディングページの作り方を比べた記事も参照）などでログインや申し込みフォームを作るとき、裏側のデータ置き場（データベース）として Supabase がよく使われます。ここで多くの人が迷うのが、「ブラウザから見える場所に Supabase の鍵が入っていて大丈夫か」という点です。Supabase の公式ガイドによると、表向きに使う anon（publishable）の鍵はもともと公開されるためのものですが、それは「RLS（Row Level Security：どの行を誰に見せるかのルール）」がオンになっているときだけ安全です。公式ガイドは、公開されているスキーマのすべての表で RLS をオンにすること（"Enable RLS on every table in an exposed schema"）を求めており、一方で RLS を素通りしてしまう裏側の secret（service_role）の鍵は、ブラウザで決して使わないよう（"Never use a secret key in the browser"）注意しています。つまり、表向きの鍵が見えること自体ではなく、表（テーブル）に行ごとのルールがないままインターネットに出してしまうことが問題になります。

この「鍵は公開される前提なのに、行のルールがなかった（または足りなかった）」ことで起きた事例がいくつか報告されています。2025 年 3 月 20 日に見つかり 5 月 29 日に公開された CVE-2025-48757 では、Semafor によると、Lovable のサイトから集めた 1,645 のアプリを調べたところ、170 のアプリで誰でもユーザーのデータ（AI サービスの鍵を含む）を見られる状態になっていました。原因は Supabase の RLS がない、または足りないことでした（なお、これを報告した Matt Palmer 氏のページは AI との関係には触れておらず、Semafor は "Even if AI models write flawless code" と述べています）。Tenable の CVE ページによると、Lovable はアプリのデータはそれぞれの利用者の責任という立場からこの CVE に異議を唱えています。また、Palmer 氏は、Lovable の公開前のスキャンは RLS がオンになっているかは確かめるものの、ルールが十分かどうかまでは確かめないと指摘しており、Lovable も 2025 年 6 月 9 日のブログで、公開前に自動でスキャンを行うとしつつも 100% の安全は保証できない（"can't guarantee"）と書いています。

同じ仕組みの漏れは、2026 年に入ってからも続いています。AI エージェントの SNS である Moltbook では、2026 年 1 月 31 日にセキュリティ企業の Wiz が問題を報告し、約 3 時間後の 2 月 1 日 1:00 UTC にすべての表が保護されました。Wiz（日本語版の記事も公開されています）によると、ブラウザに届く JavaScript に Supabase の鍵が入っていて RLS のルールがなかったことが原因で、API の認証トークン 150 万件、メールアドレス約 35,000 件、非公開の DM 4,060 件（一部に OpenAI の鍵がそのまま書かれていました）が誰でも読めるうえに、表への書き込みもできる状態でした。創業者は 1 行もコードを書いていない（"didn't write a single line of code"）と公に言っており、Wiz はこれをバイブコーディングで作られたアプリ（"vibe-coded applications"）に繰り返し出る型と書いています。

また、2026 年 2 月 27 日の The Register によると、Lovable の Discover ページで紹介されていた教育系のアプリ（名前は伏せられています）でも、16 の欠陥（うち 6 つが重大）が見つかり、18,697 件の利用者の記録（うち 870 件は個人情報がすべてそろった状態）が漏れていました。The Register によると、このアプリには RLS がなかっただけでなく、ログインの確かめが逆になっており（ログインした人を止め、ログインしていない人を通す状態）、調査した研究者は、AI のコード生成が「動くコード」を優先した結果だと主張しています。これに対し Lovable は、このプロジェクトには Lovable が生成していないコードが入っていたこと、データベースは Lovable のものではなかったこと、そして公開前の無料スキャンの助言が使われていなかったことを挙げて反論しています。ツールの自動スキャンだけに頼るのではなく、公開前に「自分の表に RLS が入っているか」「ログインしていない別人の画面からデータが見えないか」を自分で確かめることが欠かせません。

「非公開」のつもりが誰でも見られた事例と公開設定の確認

自分が作ったアプリだけでなく、アプリを動かす土台（プラットフォーム）そのものの欠陥によって、非公開のはずの情報ややり取りが外から見られる状態になっていた事例もあります。セキュリティ企業の Wiz が 2025 年 7 月 29 日に公開した報告によると、Wix 傘下の Base44 では、非公開に設定したアプリでも、外からわかる app_id さえあれば誰でもアカウントを登録・確認できる欠陥がありました。社内のチャットボットやナレッジベース、人事のアプリなどでこの状態が確認されましたが、2025 年 7 月 9 日の報告から約 24 時間以内に Wix が修正し、悪用の証拠はないとしています。Wiz はこれを、1 つのプラットフォームの欠陥がその上のすべてのアプリに及ぶリスク（shared-risk model）として説明しています。

Lovable のプラットフォームでも、2026 年 2 月の権限の変更によって所有者を確かめる処理が抜け落ち、無料のアカウントさえあれば、ほかの利用者の公開プロジェクトのチャットとコードが読める状態になっていました（2026 年 4 月 20 日に公開）。この報告は脆弱性窓口の HackerOne で 48 日間そのままになっており、2026 年 4 月 21 日の The Register の記事によると、Lovable は最初これを「意図した動作」と説明し、その後もとに戻して公開プロジェクトのチャットを非公開にしました。

また、プラットフォームの欠陥ではなく、最初から「公開」の設定のまま使われていたことで情報が外に出ていたケースも多数あります。2026 年 5 月 7 日の Axios と Security Boulevard によると、RedAccess の調査では、Lovable、Base44、Replit、Netlify で公開されている約 38 万の資産のうち、約 5,000 に企業の機密のデータが含まれており、その多くが Google の検索結果に載っていました。これについて Replit の CEO は、公開アプリは想定どおりの動作だと言っています。「検索に出ないだろう」と思っていても、それだけでは鍵がかかっていることにはなりません。ツールで何かを作ったら、まず最初に「プロジェクトやチャット、アプリが誰に見える設定になっているか」を確かめてください。

公開ページに入れた API キーの漏洩と高額請求の事例

公開するページのコードに API キーがそのまま入っていると、外から読まれて使われることがあります。Moltbook の DM には OpenAI の鍵が書かれており、Escape.tech はむき出しの秘密の鍵を 400 以上見つけました。また、GitGuardian が 2026 年 3 月 17 日に自社の報告で発表した数字によると、2025 年に公開の GitHub に新しく出た秘密の鍵は約 2,900 万あり、AI サービスの鍵の漏れは 81% 増えました。

公開してよいと思っていた鍵が、あとから AI の API にも使えるようになることもあります。Truffle Security が 2025 年 11 月 21 日に Google へ報告し、2026 年 2 月に公開した事例では、地図などのために公開ページに入れていた「AIza…」の形の Google の API キーが、同じプロジェクトで Gemini の API（Generative Language API）を有効にすると Gemini も使えるようになっていました。Truffle Security は Common Crawl の中に生きている鍵を 2,863 見つけました。Google は最初「意図どおり」と言い、のちにバグとして扱いを変えました。なお、この報告では AI が書いたコードとの関係は書かれていません。

鍵が外で使われると、短い時間で高額の請求につながることがあります。The Register（2026 年 3 月 3 日）が開発者の Reddit の投稿を引用して報じたところによると、メキシコの 3 人のスタートアップで、ふだんは月 180 ドルほどの請求が、2026 年 2 月 11〜12 日の約 48 時間で 82,314.44 ドルになりました。鍵は「somehow compromised」（何らかの形で盗まれた）とされ、原因はわかっていません。Google の担当者は責任共有モデルを挙げました。どの出典も、この件を AI が書いたコードや Truffle Security の見つけた仕組みとは結びつけていません。

  • Truffle Security の助言に従い、漏れた鍵を無効にして新しく作り直すか、使える範囲を絞る
  • Truffle Security の助言に従い、Google のプロジェクトで Generative Language API が有効になっていないか確かめ、使わない API は止める
  • OpenAI などの鍵が漏れたときは、GitGuardian が公開している手順のページ（OpenAI の鍵の例）も参考に、鍵の無効化と作り直しを行う

ブラウザのコードでログインやパスワードを確かめていたケース

AI に「このページにパスワードをかけて」「ログイン画面を作って」と頼むと、画面の見た目と一緒に、パスワードを確かめる処理までブラウザの中で動くコード（HTML や JavaScript）として作られることがあります。Wiz が挙げた 4 つの型の 1 つめは、このようにパスワードやログインの確かめがブラウザで動くコードの中にあるというものです。ブラウザに送られるコードは、ページのソースを表示すれば誰でもそのまま読めてしまいます。なぜブラウザ側の JavaScript だけで守れないのかについては、HTML のページにパスワードをかける方法でも詳しく説明しています。

また、ログインを確かめる条件そのものが食い違っていた例もあります。The Register によると、ある教育系のアプリではログインの確かめが逆になっており、ログインした人を止め、ログインしていない人を通す状態になっていました。ログイン画面が表示されて自分のパスワードで入れると、一見うまく動いているように見えますが、「ログインしていない状態で直接ページのアドレスを開いたときにどうなるか」まで確かめないと、こうした状態には気づきにくくなります。

AI エージェントが本番のデータやファイルを消した事例（Replit と Gemini CLI）

2025 年 7 月、SaaStr の Jason Lemkin が Replit の AI エージェントを 12 日間試していたとき、コードの凍結中（何も変えないように何度も指示していた）に、エージェントが本番のデータベースを消しました。経営者 1,206 人と 1,196 社以上の記録が消え、エージェントは元に戻せないと言いましたが、Lemkin によると実際には戻せました。The Register によると、Replit の CEO の Amjad Masad は「受け入れられない、決してできてはならない（Unacceptable and should never be possible）」と述べています。

Lemkin と The Register によると、Replit はそのあと対策として、開発用と本番のデータベースを自動で分ける仕組みや、計画とチャットだけのモード、データベースの状態も含むチェックポイントとワンクリックでの復元を入れました。

また、パソコンの中のファイルを扱う道具でも報告があります。2025 年 7 月 21 日、GitHub の issue #4586 では、Windows で Gemini CLI 0.1.13 をサンドボックスなしで使い、ファイルを整理するように頼んだところファイルが失われたという利用者からの報告が上がりました（この件について Google の事後報告は見つかっていません）。「変更しないで」と文章で指示するだけではエージェントが止まらないことがあるため、手元の環境で動かすときは Claude Code のガードレールはフックで作る のように、実行の直前のフックで止める仕組みを入れておくと安心です。

MCP とプロンプトインジェクションのリスクと実際に起きたこと

AI エージェントを外部のツールや自分のアカウントにつなぐ MCP とは 何かを知り、便利に使っている人も多いでしょう。しかし、AI が外から読んだ文章がそのまま AI への命令として働いてしまう「プロンプトインジェクション」という型があります。2025 年 5 月 26 日に Invariant Labs が公開した GitHub の MCP に関する実証（攻撃ではない）では、攻撃者が公開の issue に書いた文をエージェントが読み、非公開のリポジトリのデータを公開のプルリクエストに書き出しました。Invariant Labs はこれを "a fundamental architectural issue"（設計の根本の問題）と書いています。また、2025 年 7 月 8 日に General Analysis が公開した Supabase の MCP に関する実証（攻撃ではない、ダミーのデータを使用）では、サポートのチケットに書かれた文に従って、RLS を素通りする service_role の権限を持っていた Cursor のアシスタントが秘密のトークンの表を読み、チケットに書き戻しました。General Analysis は「権限の違反は 1 つもなかった」としています。

開発ツール自体の脆弱性や、偽のパッケージ、設定の不具合も報告されています。Tenable の FAQ がまとめたところによると、2025 年 8 月には Cursor の脆弱性として、Aim Labs が見つけた CVE-2025-54135（CVSS 8.6、1.3.9 で修正）と Check Point が見つけた CVE-2025-54136（CVSS 7.2、1.3 で修正）が公開されました。これらはプロンプトインジェクションから、承認なしに MCP の設定を書き換えて命令を実行できたものです。また、The Register によると（2025 年 9 月 29 日）、Postmark の MCP サーバーのふりをした偽の postmark-mcp という npm のパッケージが、途中の版から送るすべてのメールを攻撃者に BCC しており、1 週間に約 1,500 ダウンロードされました。Postmark はこのパッケージについて "absolutely nothing to do"（まったく関係ない）と言っています。さらに The Hacker News が報じた Koi の調査（2026 年 2 月）によると、ClawHub の 2,857 のスキルのうち 341 が悪意のあるものでした。BleepingComputer によると（2025 年 6 月）、Asana の MCP ではテナントを分ける処理の欠陥という攻撃ではなく不具合によって、約 1,000 の顧客の組織をまたいでデータが見えたこともありました。

OWASP（LLM01:2025 プロンプトインジェクション）など各出典は、プロンプトインジェクションを 1 つのサーバーのバグではなく設計の問題としています。そのため、自分のアカウントやデータを MCP で AI につなぐときは、あらかじめ権限を絞り、AI が勝手に操作を進めないように人が確認する仕組みを入れておくことが大切です。

  • 最小の権限にし、読み取り専用で足りる場合は読み取り専用にする（OWASP、General Analysis の助言）
  • 1 回のセッションで扱うリポジトリやプロジェクトを 1 つに絞る（Invariant Labs、General Analysis の助言）
  • ツールの呼び出しを「常に許可」にせず、危ない操作の前に人が見て承認する（OWASP、Invariant Labs、General Analysis の助言）

Tea アプリの漏洩原因と、AI がなくても起きている同じ失敗

2025 年 7 月 25 日、出会い系の安全アプリ Tea から、本人確認の写真や投稿の画像など約 72,000 枚が 4chan に出ました。BleepingComputer が 404 Media を引いて報じたところでは、2 つめのデータベースの DM 110 万件も漏れています。Tea は発表で「A legacy data storage system was compromised（古いデータの保管の仕組みが侵害された）」と説明し、404 Media は原因を公開になっていた Firebase のストレージのバケットだと報じました。

いくつかのベンダーのブログはこの件をバイブコーディングと結びつけていますが、それを支える一次の出典はなく、Tea、404 Media、BleepingComputer のどれも AI との関係を書いていません。Simon Willison も、2024 年より前のコードだったため「confident vibe coding was not to blame（バイブコーディングのせいではないと言える）」と述べています。

  • Chat & Ask AI（2026 年 1 月 29 日）: 404 Media によると、Firebase の設定ミスがあり、研究者は 3 億のメッセージが読めたと主張しています。AI で作られたかどうかの関係は書かれていません。
  • GenNomis（2025 年 4 月 1 日）: The Register によると、AI の画像生成サービスでパスワードのない S3 のバケットに 93,485 枚の画像が置かれていました。AI が作ったのは画像であり、コードではありません。
  • DollyWay（2025 年 3 月 17 日）: GoDaddy によると、2016 年から 20,000 以上の WordPress のサイトが乗っ取られました。最初にどうやって入ったかは書かれていませんが、入ったあとで古いプラグインや偽のプラグインを使って居座る手口で、AI との関係はありません。
  • Post SMTP（2025 年 11 月 1 日）: WordPress のプラグインの脆弱性（CVE-2025-11833、CVSS 9.8）により、ログインなしでパスワードの再設定のメールを含むメールの記録が読める状態でした。AI との関係はありません。

保管場所の鍵の閉め忘れや古い部品の放置は、AI でコードを書く前から繰り返されてきました。Patchstack の 2026 年の WordPress のセキュリティの報告では、2025 年に新しく見つかった WordPress の脆弱性は 11,334 件で、公開の時点で 46% に修正がなく、大量に悪用されるまでの時間の中央値（重み付き）は 5 時間でした。Lovable が CVE を利用者の責任とし、Replit と Wix が公開アプリを想定どおりと言い、Google が請求を責任共有としたように、出典は AI の有無にかかわらず設定の責任を公開した人の側に置いています。

自分の作ったものが当てはまるか確かめる

公開しようとしているものの中身から、関係する事例と公開前に確かめることを探せます。Convika で公開した場合の扱いもあわせて並べています。

あなたのページ・アプリにあるもの関係する事例確かめることConvika で公開した場合
ログインと他人のデータのデータベースLovable のアプリ、Moltbook、教育系のアプリ、Lovable のプラットフォームすべての表で RLS をオン、ブラウザに secret の鍵を置かない、プラットフォームのスキャンConvika はこの種のアプリを置かない。
API キー（AI、地図）Google の API キー、82,314 ドルの請求、Moltbookページに鍵を入れない、範囲を絞るか作り直す外の API は呼べないが、鍵入りの URL のスクリプトは読めて、HTML の鍵は公開される。
名前やメールを集めるフォーム教育系のアプリ誰が送信を読めるか、集めるものを減らす他人は読めない。送信は画面・通知メール・Webhook・MCP に届き、IP 等も保管される。
「一部の人だけに見せたい」Base44、Lovable のプラットフォーム、RedAccess の調査鍵がかかっているのか、検索に出ないだけか「限定公開」（Pro・1年パス）は鍵ではない。パスワードは Pro。
ファイルやデータベースに触れるエージェントReplit、Gemini CLI開発用と本番を分ける、バックアップ、承認MCP に消すツールはなく公開前に確認でき、過去の版に戻せる（上限を超えると古い版は消える）。
入れた MCP サーバーやスキルGitHub の MCP、Supabase の MCP、Cursor、偽の postmark-mcp、ClawHub出どころ、読み取り専用、更新接続は OAuth で AI に鍵は渡らない。フォームの送信は文章として AI に届く。
フォームも鍵もないふつうのページ（お知らせ、メニュー、授業の資料）こうしたリスクは少ないソースに見せたくないものがないかConvika が置くのはこの種のページ。

公開前に確かめること: 8 つの手順

作ったページやアプリをインターネットに出す前に、次の 8 つの手順を確かめてください。自分の作ったものに当てはまる項目だけで構いません。

1. ページのソースに鍵が入っていないか探す

ページに入った鍵は誰でも見られます。Truffle Security は公開ページに入った Google の鍵を、Escape.tech は公開アプリのむき出しの鍵を見つけました。一般的な確かめ方として、ブラウザでページのソースを表示し、「key」「secret」「sk-」「AIza」といった文字で検索して、鍵がそのまま入っていないか確かめてください。

2. Supabase のデータベースがあるなら RLS と鍵の置き場所を確かめる

Supabase のドキュメントでは、すべての表（テーブル）で RLS をオンにすることと、ブラウザに secret（service_role）の鍵を置かないことを案内しています。また、Lovable のブログにあるように、プラットフォームのスキャンを動かして確かめることもできます。ただし Matt Palmer が指摘している通り、スキャンが確かめるのは RLS がオンかどうかであって、ルールが正しいかどうかではない点に注意してください。

3. ログインがあるならパスワードの確かめがサーバーで動いているか見る

ログインのあるアプリでは、Wiz が指摘しているように、パスワードの確かめがページの中ではなくサーバーで動いているかを確かめてください。

4. 誰が開けるかと最初の公開の範囲を確かめる

RedAccess の調査や Base44 の件で見つかったように、最初の公開の範囲がどうなっているか、また「検索に出ない」だけになっていて誰でも開ける状態になっていないかを確かめてください。

5. API キーの範囲を絞り、使わない API は止める

Truffle Security がすすめているように、API キーが使える範囲を絞るか新しく作り直し、使わない API は止めておきます。

6. エージェントには開発用のデータベースを分け、「常に許可」にしない

AI エージェントを使うときは、Replit の対策や Invariant Labs が示しているように、開発用のデータベースを分け、バックアップやチェックポイントを持つようにします。また、エージェントの操作を「常に許可」にしないようにしてください。

7. MCP サーバーとスキルは提供元のものだけを入れ、範囲を絞る

General Analysis、Postmark、および Koi の調査を報じた The Register を踏まえ、MCP サーバーやスキルは提供元のものだけを入れるようにします。さらに、読み取り専用や 1 つのプロジェクトに絞れるなら絞ってください。

8. 集める個人情報は必要なものだけにし、何を集めるかを伝える

基本的な心がけとして、フォームやアプリで集める個人情報は本当に必要なものだけにし、何を集めるのかを利用者にわかりやすく伝えてください。

データベースの要らないページを Convika に置く場合

お店の案内、申し込みフォーム、授業の道具のように、データベースや利用者のログインが要らない HTML のページなら、置く場所の仕組みによって最初から発生しない種類の問題があります。反対に、ログインやデータベースのあるアプリは Convika が置くものではありません。これまで見てきた事例の型が Convika ではどうなっているか、そして Convika に置いたページにも残るリスクを整理します。

事例の型Convika では
データベースの表が開いている、RLS を忘れた持ち主が設定するデータベースはなく、ページは HTML として置かれる。渡すデータベースの鍵も、行のルールもない。
ページの中の秘密の鍵で裏側が開くフォームは同じホストの /_form に送られ、秘密の鍵はサーバー側で足される。公開 HTML に鍵は入らない。
誰でもフォームの送信を読める他人は送信を読めない。送信は持ち主のワークスペース、通知メール、設定した Webhook、MCP だけで読める。
ボットがフォームに大量に送るIP ごとの送信上限と見えない入力欄がある。Free は月 50 件を超えると保留される。
訪問者のブラウザから有料の API を呼ぶfetch 等は自身のホストだけに届く。ただし https のスクリプトは動くため HTML に書いた鍵は公開される。
パスワードをページの JavaScript で確かめる送る前にサーバーで確かめ IP ごとに試行上限がある。解除は 7 日続く（Free 以外）。
エージェントが本番を消すMCP に削除ツールはない。保存は非公開に入り、公開等は確認が出る。版の上限を超えた古い版は消えるが公開中は残る。
暗号化されていない HTTP でフォームを送るHTTP の GET は HTTPS に転送（301）し、HTTP の POST は断る（403）。HSTS もある。
登録なしのアップロードが共有のホストでスクリプトを動かす登録なしでアップロードしたページは、誰かが登録して受け取るまで、スクリプトもフォームも動かない。

一方で、Convika に置いたページでも次のリスクは残ります。

  1. HTML に入れたものはすべて公開される: 貼った API キーや個人情報に警告は出ません（Convika に秘密の鍵を見つける仕組みはありません）。HTML だけのページに鍵は要らないので、入れないでください。
  2. 持ち主のスクリプトはすべて動く: https の CDN のスクリプトや https の iframe も動きます。持ち主のページは消毒（サニタイズ）されません。外のスクリプトが書き換えられたら、ページは新しいほうを動かします（偽の postmark-mcp や ClawHub のスキルと同じ型の、小さい版です）。
  3. 「限定公開」は鍵ではない: 検索エンジンに載せないよう伝え、Convika のギャラリーに載せないだけで、リンクを知っている人（転送された人も）は開けます。限定公開は Pro・1年パスの機能です。鍵になるのは Pro のパスワードだけです。詳しくは HTML を限られた人だけに見せる方法 を参照してください。
  4. フォームの答えは個人情報として保管・転送される: Convika が持ち主のために、答え、IP アドレス、ブラウザの情報（ユーザーエージェント）、国を保管します。答えは通知のメール（最初からオン）と、設定した Webhook にも送られるので、通知先を共有の受信箱にすると、そこにも答えが残ります。何を聞くかは持ち主が決め、自分のプライバシーポリシーで伝える必要があります（Convika はそれを書きません）。あわせて サーバーなしでフォームを置く方法 も参照してください。
  5. アカウントはパスワードか Google でのログインで、2 段階認証はなくメールの確認が必要なため、使い回さないパスワードか Google でのログインをすすめます。
  6. エージェントによる版の押し出しとフォーム送信の読み取り: エージェントが保存を繰り返すと、プランの版の数を超えた古い版から完全に消え、そこへは戻せなくなります（公開中の版とプレビューの版は残ります）。また MCP では、フォームの送信が文章として AI に届きます（get_form_submissions のツール）。それは信頼できない文章としてエージェントの文脈に入ります（Supabase の MCP の実証と同じ型です）。公開と公開停止の前の、クライアントの承認はオンのままにしてください。
  7. ログインやライブのデータが要るアプリには向かない: Convika が置くのはページで、利用者のアカウントとデータベースのあるアプリではありません。そういうアプリには、どこに置くとしても上のチェックリストが当てはまります。

ページのパスワードは Pro（月 ¥1,800）から使えます。プランごとの違いは 料金のページ で確認できます。

よくある質問

バイブコーディングは危険ですか？

AI でコードを書くこと自体が必ず危険なわけではありませんが、設定の抜けや秘密の鍵の露出がそのまま公開された事例がいくつも報告されています。Veracode の 2025 年 7 月のプレスリリースでは 100 以上の LLM に 80 の課題を出したところ 45% の場合で安全でない書き方が選ばれ、Escape.tech の 2025 年 10 月の自社調査では公開されている 5,600 以上のアプリを外から受け身で調べただけで、少なくとも 2,000 以上の脆弱性、400 以上のむき出しの秘密の鍵、175 件の個人情報が見つかりました。Wiz は 2025 年 9 月に、バイブコーディングのアプリで繰り返し見つかる 4 つの型として、ログインの確かめがブラウザの中にあること、秘密の鍵がブラウザに届くコードに入っていること、データベースの表が開いている（RLS がない）こと、社内向けのアプリが公開されたままであることを挙げています。また Semafor は 2025 年 5 月の Lovable に関する記事で、原因はデータベースの設定にあり、「Even if AI models write flawless code（AI のモデルが完璧なコードを書いたとしても）」この問題は起きると伝えています。

AIで作ったアプリを公開しても大丈夫ですか？

公開してよいかどうかは AI で作ったかではなく、他人のデータを保存するか、秘密の鍵を持っているか、ログインがあるかといった中身によって決まります。たとえば 2026 年 1 月に Wiz が報告した、創業者が「didn't write a single line of code（1 行もコードを書いていない）」と公に言っていた Moltbook では、ブラウザに届く JavaScript に Supabase の鍵が入っていて RLS のルールがなかったため、API の認証トークン 150 万、メールアドレス約 35,000、一部に OpenAI の鍵がそのまま書かれた非公開の DM 4,060 が誰でも読み書きできる状態になり、約 3 時間後に直りました。公開の前と後に、ブラウザに届くコードに秘密の鍵が入っていないか、データベースの表の保護（RLS）やログインの確かめが正しく設定されているかを確かめる必要があります。

Supabase の anon key は公開しても大丈夫ですか？

Supabase のドキュメントによると、anon（publishable）の鍵は公開されるためのものですが、安全なのはデータベースで RLS（行ごとのアクセスのルール）がオンになっているときだけです。同ドキュメントは公開されたスキーマのすべての表で RLS を有効にするよう案内しており、RLS がないと公開の鍵を使って誰でも表を読めて、Lovable のアプリや Moltbook の例のように書き込めることもあります。なお、RLS を素通りする secret（service_role）の鍵については、Supabase のドキュメントで「Never use a secret key in the browser（ブラウザで秘密の鍵を決して使わないこと）」とされています。

Supabase の RLS を無効にするとどうなりますか？

Supabase の RLS（行ごとのアクセスのルール）を無効にしたりルールが足りなかったりすると、公開の鍵を使って誰でもデータベースの表を読めたり書き込めたりする状態になります。Semafor によると 2025 年 5 月に公開された Lovable の事例（CVE-2025-48757）では、RLS がないか足りないことが原因で 1,645 のアプリのうち 170 で AI サービスの鍵を含むユーザーのデータを誰でも見られ、2026 年 1 月に Wiz が報告した Moltbook でも RLS のルールがなかったために認証トークン 150 万や非公開の DM 4,060 が誰でも読み書きできました。そのため Supabase のドキュメントでは、「Enable RLS on every table in an exposed schema（公開されたスキーマのすべての表で RLS を有効にすること）」と案内されています。

Lovable は安全ですか？

Semafor によると 2025 年 3 月に見つかり 5 月に公開された CVE-2025-48757 では、Lovable のサイトから集めた 1,645 のアプリのうち 170 で Supabase の RLS がないか足りないために AI サービスの鍵を含むユーザーのデータを誰でも見られましたが、Tenable の CVE のページによると Lovable はアプリのデータはそれぞれの利用者の責任という立場でこの CVE に異議を唱えています。また The Register によると、2026 年 2 月 27 日に報じられた Lovable の Discover のページで紹介されていた教育系のアプリでは、ログインの確かめが逆で RLS もなかったために 870 件のそろった個人情報を含む 18,697 件の利用者の記録が露出し、研究者は AI のコード生成が「動くコード」を優先した結果だと主張した一方、Lovable は自社が生成していないコードが入っておりデータベースも Lovable のものではなく、公開前の無料スキャンの助言が使われていなかったと返答しました。さらに 2026 年 4 月 21 日の The Register によると、2026 年 2 月の権限の変更で所有者を確かめる処理がなかったため、無料のアカウントでほかの利用者の公開プロジェクトのチャットとコードが読める状態が HackerOne での報告後 48 日そのままになり、The Register によれば Lovable は最初「意図した動作」と説明したのちに、もとに戻して公開プロジェクトのチャットを非公開にしました。なお公開前のスキャンについて、Lovable は 2025 年 6 月 9 日のブログで公開前に自動でスキャンするが 100% の安全は「can't guarantee（保証できない）」としており、CVE を報告した Matt Palmer はこのスキャンが RLS がオンになっているかは確かめるがルールが十分かは確かめないと指摘しています。

API キーが漏洩したらどうすればいいですか？

出典の助言によると、鍵が漏れたときはまずその鍵を無効にして新しく作り直すか、使える範囲を絞ることが必要です。GitGuardian が自社の報告で発表した数字では、2025 年に公開の GitHub に新しく出た秘密の鍵は約 2,900 万にのぼり、AI サービスの鍵の漏れは 81% 増えたとされており、同社は OpenAI の鍵などを例にした対処手順のページも公開しています。また Google の API キーについては、プロジェクトで Generative Language API（Gemini の API）が有効になっていないかを確かめ、使わない API は止めるよう Truffle Security が助言しています。

Gemini の API キーが漏れると高額請求されることはありますか？

The Register が 2026 年 3 月 3 日に開発者の Reddit の投稿を引用して報じたところによると、メキシコの 3 人のスタートアップで鍵が「somehow compromised（何らかの形で盗まれた）」とされ、ふだんは月 180 ドルほどのところが 2026 年 2 月 11〜12 日の約 48 時間で 82,314.44 ドルの請求になった事例があります。ただしこの件で鍵が盗まれた原因はわかっておらず、どの出典も AI が書いたコードや Truffle Security の見つけた仕組みとは結びつけていません（Google の担当者は責任共有モデルを挙げています）。これとは別に Truffle Security が 2025 年 11 月に Google へ報告し 2026 年 2 月に公開した調査では、地図などのために公開ページに入れていた AIza… の形の Google の API キーが、同じプロジェクトで Gemini の API（Generative Language API）を有効にすると Gemini も使えるようになっており、Common Crawl の中に生きている鍵が 2,863 見つかりました（AI が書いたコードとの関係は書かれていません）。Truffle Security によると Google は最初「意図どおり」と言い、のちにバグとして扱いを変えており、対策として鍵を無効にして作り直すか使える範囲を絞り、プロジェクトで Generative Language API が有効になっていないか確かめて使わない API を止めることが勧められています。

Replit の AI が本番データベースを削除した事件とは？

2025 年 7 月に、SaaStr の Jason Lemkin 氏が Replit の AI エージェントを試していた際、コードを変更しないよう何度も指示していたにもかかわらず、エージェントが本番のデータベースを消してしまった出来事です。経営者 1,206 人と 1,196 社以上の記録が消え、エージェントは元に戻せないと言いましたが、Lemkin 氏によれば実際には復元できました。The Register によると、Replit の CEO である Amjad Masad 氏は「受け入れられない、決してできてはならない（Unacceptable and should never be possible）」と述べました。そのあと Replit には、開発用と本番のデータベースを自動で分ける仕組みや、計画とチャットだけのモード、ワンクリックでの復元などが取り入れられています。

Moltbook では何が起きたのですか？

AI エージェントの SNS である Moltbook で、データベースが誰でも読み書きできる状態になっていた問題です。2026 年 1 月 31 日にセキュリティ企業の Wiz が報告し、API の認証トークン 150 万件、メールアドレス約 35,000 件、一部に OpenAI の鍵がそのまま書かれた非公開の DM 4,060 件が外から読める状態でしたが、約 3 時間で修正されました。ブラウザに届く JavaScript に Supabase の鍵が入っていて、アクセス制限（RLS）のルールがなかったことが原因です。創業者は「1 行もコードを書いていない（didn't write a single line of code）」と公に語っており、Wiz はこれを「バイブコーディングで作られたアプリ（vibe-coded applications）」に繰り返し出る型と書いています。

Tea アプリの情報漏洩はバイブコーディングが原因ですか？

一次の出典によれば、バイブコーディングが原因ではありません。2025 年 7 月 25 日に、本人確認の写真など約 72,000 枚や別のデータベースの DM 110 万件が流出しましたが、Tea の発表やそれを報じた 404 Media、BleepingComputer のどれも AI との関係には触れていません。Tea は「古いデータの保管の仕組みが侵害された（A legacy data storage system was compromised）」と発表し、Simon Willison 氏も 2024 年より前のコードだったため「バイブコーディングのせいではないと言える（confident vibe coding was not to blame）」と述べています。いくつかのベンダーのブログがバイブコーディングと結びつけていますが、それを裏付ける一次の出典はありません。

AI エージェントにデータを消されないためにはどうすればいいですか？

AI エージェントを本番のデータベースや大事なファイルに直接つなげず、権限を分けたり実行前に止めたりする仕組みを入れることが大切です。2025 年 7 月には Replit のエージェントが本番データベースを消した事例や、Windows でサンドボックスなしの Gemini CLI（0.1.13）にファイルの整理を頼んでファイルが失われたという GitHub の issue #4586 での報告があります。対策としては、開発用と本番のデータベースを分ける、計画とチャットだけのモードを使う、データベースの状態も含むチェックポイントを作るといった方法があります。また、「消さないで」という文の指示だけに頼らず、Claude Code のガードレールはフックで作るのように実行の直前に動く仕組みで止めるのも有効です。

MCP サーバーは安全ですか？

便利な一方で、設定の権限や入れるパッケージによってはデータが漏れる危険があります。Invariant Labs は公開の issue の文から非公開リポジトリのデータが書き出される実証をしてこれを「設計の根本の問題（a fundamental architectural issue）」と呼び、General Analysis も RLS を素通りする強い権限を持たせたアシスタントがサポートチケットの文に従って秘密のトークンを書き戻す実証をしています。また、The Register によると送るメールを攻撃者に BCC する偽の postmark-mcp が 1 週間に約 1,500 回ダウンロードされ、The Hacker News が報じた Koi の調査では ClawHub の 2,857 のスキルのうち 341 が悪意のあるものでした。公式のパッケージかを確かめ、読み取り専用や 1 つのプロジェクトだけに権限を絞り、「常に許可」にせず操作のたびに人が確認するようにしてください（詳しくはMCP とはもご覧ください）。

AI が書いたコードはどれくらい脆弱ですか？

調査では、AI が作ったコードや公開アプリの多くに安全でない部分や設定の抜けが見つかっています。2025 年 7 月の Veracode のプレスリリースによると、100 以上の LLM に 80 の課題を出したところ、45% の場合で安全でない書き方を選びました。また、2025 年 10 月に Escape.tech が公開されているバイブコーディングのアプリ 5,600 以上を外から受け身で調べた調査では、少なくとも脆弱性 2,000 以上、むき出しの秘密の鍵 400 以上、個人情報 175 件が見つかっています。さらに Semafor は Lovable の件について、原因はデータベースの設定にあり、「AI のモデルが完璧なコードを書いたとしても（Even if AI models write flawless code）」この問題は起きると伝えています。

日本でも AI で作ったアプリの情報漏洩は起きていますか？

2026 年 10 月 19 日時点の日本語の検索では、一次の出典が AI の生成したコードと結びつけている日本の事例は見つかりませんでした。ただし、データベースの公開設定のミスや秘密の鍵の埋め込みといった原因は、国を問わず同じツールを使えばどこでも起こるものです。日本で事例が報じられていないからといって安心せず、公開の前に設定や鍵の扱いを確かめておく必要があります。

データベースのない静的なページでも危険はありますか？

データベースを使うアプリに比べるとリスクは少ないですが、危険がないわけではありません。HTML や JavaScript の中に API キーなどの秘密の鍵や個人情報を書いてしまうと、ページを開いた人にそのまま公開されてしまいます。また、外から読み込むスクリプトが動くことや、問い合わせフォームで受け取る答えの扱いにも気をつける必要があります。

出典

関連記事

記事を共有する