この記事でわかること

  • 約1.6万件のSupabaseデータベースが個人情報を公開していた事実
  • 流出した情報の種類と影響範囲
  • AI生成コードで起きやすいセキュリティ設定ミス
  • バイブコーディングのリスクと対策

1.6万件のデータベースから情報流出

2026年9月25日、セキュリティ企業UpGuardが衝撃的な調査結果を発表しました。人気のデータベースサービス「Supabase（スーパーベース）」でホストされた約1万6000件のデータベースで、個人情報が誰でも見られる状態になっていたのです。

Supabaseは、アプリ開発者が使うバックエンドサービスです。つまり、アプリの裏側でデータを保存したり管理したりする仕組みを提供しています。最近ではAI（人工知能）を使ってアプリを作る人が増えており、Supabaseもよく使われるサービスの1つです。

今回見つかった問題の原因は、開発者による設定ミスでした。特にAIが生成したコードをそのまま使った場合に、セキュリティ設定が不十分になるケースが多かったと報告されています。

流出したのはどんな情報？

UpGuardの調査で見つかった情報は、非常に機密性の高いものでした。たとえば、氏名、住所、電話番号といった基本的な個人情報から、ユーザーパスワードや認証トークン（ログイン用の鍵のようなもの）まで含まれていました。

さらに深刻なのは、具体的な被害の内容です。インドの成人向け動画サイトでは、ユーザー同士の私的な会話記録が公開されていました。アメリカのバレットサービス（駐車場管理サービス）では、数千件の車のナンバープレート情報が流出しました。

他にも、移民や転居サービスを使った人の連絡先、アフリカのある国のフランス領事館のデータベース、SMS詐欺に使われる仮想SIM（スマホの回線を管理する技術）の通信記録なども見つかりました。

影響を受けたのは、Y Combinator（スタートアップ企業を支援する有名な組織）に参加している企業や、個人開発者が作ったアプリなど、規模も種類もさまざまです。つまり、大企業だけでなく小規模な開発者も同じリスクにさらされていたのです。

なぜこの問題が起きたのか

問題の根本原因は、RLS（Row Level Security、行レベルセキュリティ）という仕組みの設定ミスでした。RLSは、データベースに保存されたデータを「誰がどこまで見られるか」を行（データの1件1件）ごとに制限する技術です。

Supabaseでは、RLSを有効にしないと、誰でもデータベースの中身を見られてしまいます。ところが、RLSを「有効にしただけ」では不十分なのです。正しいルール（ポリシー）を設定しないと、結局すべてのデータが公開されたままになります。

たとえば、「USING(true)」というポリシーを設定すると、「全員が全部の行を見られる」という意味になってしまいます。これではRLSを無効にしているのと同じです。また、読み取りのルールだけを書いて、書き込みのルール（WITH CHECK）を忘れるミスも多く報告されています。

AI生成コードでは、こうした細かい設定が抜け落ちやすいのです。AIは「動くコード」を作るのは得意ですが、セキュリティの脅威（どんな攻撃があるか）や組織ごとのセキュリティ方針までは理解できません。

「バイブコーディング」とは何か

最近、「バイブコーディング」という言葉をよく耳にします。これは、AIにざっくりとした指示（バイブ＝雰囲気）を出して、コードを生成してもらう開発スタイルのことです。たとえば、「ユーザーログイン機能を作って」と伝えるだけで、AIが数百行のコードを書いてくれます。

2025年冬に行われたY Combinatorの調査では、参加企業の4分の1が「コードの95%以上をAIが生成した」と回答しました。つまり、バイブコーディングは既に主流の開発方法になっているのです。

しかし、問題もあります。2025年7月にVeracodeが行った調査では、AIが生成したコードの45%に脆弱性（セキュリティの穴）が含まれていました。具体的には、SQLインジェクション（データベースへの不正アクセス）、XSS（クロスサイトスクリプティング、Webサイト改ざん）、パスワードのハードコード（コードに直接書き込むこと）などです。

バイブコーディングの本当のリスクは、AIが危ないコードを書くことではありません。人間がそのコードを十分に検証せずに、そのまま公開してしまうことなのです。

Supabaseの反応と責任の所在

Supabaseの最高情報セキュリティ責任者（CISO）であるBil Harmer氏は、TechCrunchの取材に対してコメントを出しました。同氏は「Supabaseのプロジェクトはデフォルトで安全である」と述べ、セキュリティは「企業と顧客の共有責任」だと説明しています。

つまり、Supabaseはツール（道具）を提供しているだけで、それをどう使うかは開発者の責任だというわけです。この主張は、クラウドサービス業界では一般的な考え方です。たとえば、AWSやGoogle Cloudなども同じように「共有責任モデル」を採用しています。

とはいえ、開発者側からすると「デフォルトで安全なはずなのに、なぜ設定ミスで情報が漏れるのか」という疑問も残ります。特に初心者や、AIに頼りきりの開発者にとっては、RLSの細かい設定を完璧にこなすのは難しいでしょう。

Supabase側も過去に何度かセキュリティ強化を行っていますが、今回の大規模な流出を受けて、さらなる改善が求められる可能性があります。

あなたのアプリは大丈夫？確認すべきポイント

もしあなたがSupabaseを使ってアプリを開発しているなら、今すぐ以下の3つをチェックしてください。

1. RLSが有効になっているか
データベースのテーブルごとに、「enable row level security」が実行されているか確認しましょう。これが無効だと、誰でもデータにアクセスできます。

2. ポリシーが「USING(true)」になっていないか
「USING(true)」は「全員にアクセス許可」という意味です。本当にそれで良いのか、見直してください。適切なポリシーは、たとえば「自分が作ったデータだけ見られる」といった条件を含むべきです。

3. WITH CHECKが設定されているか
読み取り（USING）だけでなく、書き込み（WITH CHECK）のルールも必要です。これがないと、他人になりすましてデータを作れてしまいます。

また、自動テストの導入もおすすめです。手動でチェックするのは限界があるため、RLSが正しく機能しているかを継続的に確認する仕組みを作りましょう。2026年には、RLS設定ミスを自動検出するツールも登場しています。

まとめ

  • 約1.6万件のSupabaseデータベースが個人情報を公開状態にしていた
  • 原因はRLS（行レベルセキュリティ）の設定ミス
  • AIが生成したコードでは、セキュリティ設定が抜け落ちやすい
  • バイブコーディングは便利だが、検証なしで公開するのは危険
  • Supabaseはツールを提供するだけで、設定は開発者の責任
  • RLSの有効化、ポリシー内容、WITH CHECKの3点を今すぐ確認すべき

AI開発が当たり前になった今、セキュリティの知識はますます重要になっています。便利なツールに頼るのは良いことですが、最後は人間がしっかり確認する。それが、あなたのアプリと、ユーザーの大切な情報を守る唯一の方法です。