読了時間 6分

「一行も書いていない」アプリから150万件のAPIキー — Moltbook事故の原因は設定1つ

2026年1月末、AIエージェント向けSNS「Moltbook」のデータベースが誰でも読み書きできる状態で公開されていました。機能は全部動いていた。壊れていたのは、Supabaseの「誰が読めるか」を決める設定（RLS）1つ。同じ設定はあなたのアプリにもあります。

動画で見る

結論から

2026年1月末、AIエージェント向けSNS「Moltbook」のデータベースが、誰でも読み書きできる状態で公開されていました。創業者は「コードは一行も書いていない。AIが作った」と語っています。アプリの機能は全部動いていました。

この記事で伝えたいのはこの一点です。壊れていたのは機能ではなく、「誰が読めるか」を決める設定1つ（Supabase の RLS）。同じ設定は、あなたのアプリにもある。

  • 露出したもの：APIトークン約150万件、メールアドレス約3.5万件、非公開メッセージ約4,000件（Wiz 調査）
  • 原因：Supabase の RLS（行レベルセキュリティ）が無効のまま公開されていた
  • AIツールは「動作確認のため」RLS を切って作り、戻し忘れる
  • 自分のアプリで見る場所は、Supabase 管理画面のテーブル一覧。赤い「RLS disabled」があれば同じ状態

動画版（約2分）は本文の上に埋め込んであります。

① 何が起きたのか

Moltbook は、人間ではなくAIエージェントが投稿・コメント・投票する「エージェントのためのSNS」として、2026年1月に急速に話題になりました。登録エージェントは150万、背後の人間アカウントは約1.7万。

1月31日、セキュリティ企業 Wiz の研究者が、Moltbook の Supabase データベースが 認証なしで丸ごと読み書きできる ことを発見しました。露出していたのは、

  • エージェントの認証用APIトークン 約150万件（他人になりすまして投稿できる）
  • メールアドレス 約3.5万件（別テーブルにさらに約3万件）
  • 非公開のダイレクトメッセージ 4,060件
  • 合計で 約475万レコード

Wiz からの通報を受け、Moltbook 側は約3時間半で修正しました。修正は4段階に分かれており、テーブルごとに「誰が読めるか・書けるか」の設定を足していく作業でした。

機能は全部動いていた。壊れていたのは「誰が読めるか」の設定1つ

② 壊れていたのは「設定1つ」

Supabase では、画面（ブラウザ）が「公開キー（anon キー）」を持ってデータベースに直接問い合わせます。このキーは公開前提で、誰でも見られます。それでも安全なのは、RLS（Row Level Security／行レベルセキュリティ） が各テーブルに「この行は誰が読めるか」の線を引いているからです。

Moltbook では、この線がありませんでした。RLS が無効のテーブルは、公開キーを持っている人なら 誰でも全行を読み書きできます。画面が見せていないだけで、データベース自体は開いていました。前回の記事「URLの数字を変えてみる」と構造は同じです。画面が隠しているのではなく、サーバー（ここではデータベース）が判断していなかった。

つまり、投稿できる・コメントできる・DMできる、という機能はすべて正しく動いていて、「誰に見せてよいか」の判断だけが抜けていた。「動く」と「安全」が別物であることの、これ以上ない実例です。

③ なぜAI製のアプリで起きやすいのか

AIツールで Supabase を使うアプリを作ると、開発中はほぼ必ず RLS が無効、または「全員に許可」の状態になります。理由は単純で、RLS が有効だと「ログインしていないと何も表示されない」「自分の行しか見えない」ため、動作確認の手数が増えるからです。AIは動作確認を優先して、まず線を引かずに作ります。

問題は、公開前に線を引き直す工程が 頼まれない限り入らない ことです。Moltbook の創業者の「一行も書いていない」は、AIが悪いという話ではなく、「線を引いてください」と誰も言わなかった、という話です。

セキュリティ企業 RedAccess が2026年5月に公表した調査では、AIを使って作られた約38万本のアプリのうち約5,000本で機密情報が外部から見える状態だった、と報告されています。主な原因は「プラットフォームの初期設定が公開のまま」。Moltbook は目立った1件にすぎません。

④ あなたのアプリの同じ場所を見る

Supabase を使っているなら、確認は5分で終わります。

  1. Supabase の管理画面を開き、左メニュー Table Editor へ
  2. テーブル一覧で、各テーブル名の横を見る。赤い「RLS disabled」 の表示があるテーブルが、Moltbook と同じ状態
  3. 「RLS enabled」でも安心しない。Authentication → Policies で、そのテーブルにポリシーが1つも無い、または true だけの「全員許可」ポリシーになっていないか見る
  4. ユーザーの個人情報が入るテーブル（profiles、orders、messages など）から優先して確認する

Lovable / Bolt で作った場合も、データの置き場所は多くの場合 Supabase です。ツールの画面ではなく、Supabase 側の管理画面で見てください。

⑤ 直し方：AIにこう頼む

「Supabase の全テーブルについて、RLS を有効にしてください。そのうえで、各テーブルに『自分の行だけ読める・書ける』ポリシー（user_id = auth.uid() を条件にする）を作ってください。全員に公開してよいテーブルがある場合は、その理由を添えて、読み取りだけを許可してください。作業後、RLS が無効なテーブルと、ポリシーが無いテーブルの一覧を出してください。」

直したあとの確認は、ログアウトした状態（シークレットウィンドウ）で自分のアプリを開き、他人のデータが表示されないこと。加えて、前回の「URLの数字を変える」チェックをもう一度やると、RLS が効いているかを画面側からも確かめられます。

RLS の考え方そのものは「AIに頼むための言葉」シリーズで別途扱います。ここでは「赤い表示を無くす」ことだけ覚えてください。

よくある質問

anon キーがブラウザで見えていました。これが原因ですか。

いいえ。anon キーは公開前提です。原因は RLS が無効だったこと。RLS が有効なら、anon キーが見えていても、その人が読めるのは「自分の行」だけです。逆に、RLS が無効なら、anon キーを隠しても意味がありません（画面がキーを持っている以上、必ず見えます）。

Firebase を使っています。関係ありますか。

同じ構造です。Firebase では RLS ではなく「セキュリティルール」が「誰が読めるか」の線です。テスト用の allow read, write: if true; のまま公開されている事例は多く、2025年に話題になった Tea App の免許証画像流出も、認証のかかっていない Firebase ストレージが原因でした。

Moltbook はすぐ直りました。大したことではなかったのでは。

修正は3時間半でも、150万件のトークンは修正前にコピーされていれば無効化するまで使えます。メールアドレスは回収できません。「直せる速さ」と「漏れたものの重さ」は別です。

自分のアプリの Supabase を見ても、赤い表示の意味が分かりません。

Table Editor のスクリーンショットをそのまま見せてもらえれば、どのテーブルが危ないかは数分で分かります。VibeCode本番化の無料相談で、その確認だけ先にすることもできます。

関連記事