「私はMoltbookのコードを1行も書いていない。ビジョンを持ち、AIがそれを現実にした」——この発言が、公開からわずか3日後に150万件のAPIキー漏洩という現実に変わった。
Moltbookとは何か
2026年1月28日、Octane AI CEOのMatt Schlichtが新しいSNSを公開した。その名はMoltbook。「AIエージェントのためのインターネットのフロントページ」を標榜し、人間の代わりにAIエージェントが投稿・コメント・投票する仕組みだ。
公開直後、Schlichtは自身のXに得意げに投稿した。
"I didn't write a single line of code for @moltbook. I just had a vision for the technical architecture, and AI made it a reality."
コードを書いたのは「Clawd Clawderberg」という名のAIエージェントだ。ClaudeとZuckerbergを掛け合わせた造語で、OpenClawというフレームワークを使って全コードを生成した。
OpenAIの共同創業者であるAndrej Karpathyも当初「最近見た中でSFの現実化に最も近いもの」と絶賛した（Fortune）。「1行も書かない開発」の理想形として、バイブコーディングコミュニティに広まった。
3日後、セキュリティ研究者がブラウザを開いた
公開から3日後の1月31日。クラウドセキュリティ大手Wizの脅威調査責任者Gal Nagliが、普通のユーザーとしてMoltbookをブラウジングしていた。
ブラウザの開発者ツールを開いた。クライアントサイドのJavaScriptを眺めた。数分で見つかった。
Supabaseの接続キーが平文で埋め込まれていた。
Supabaseには「anon key（匿名キー）」という概念がある。これは公開前提の鍵で、フロントエンドのコードに書いても問題ない設計になっている——ただし、一つの条件を満たしている場合に限り。その条件が「Row Level Security（RLS）」の設定だ。
Moltbookには、RLSが1件も設定されていなかった。
Nagliはこう述べた。
"When properly configured with Row Level Security, the public API key is safe to expose — it acts like a project identifier. However, without RLS policies, this key grants full database access to anyone."
（The Cyber Express / CX Today）
RLSとは何か——マンションの比喩
プログラミングの知識がない人向けに、比喩で説明する。
Supabaseの「anon key」は、マンションの「住所」だ。誰でも知っていい情報で、知られても問題ない。問題になるのは「各部屋の鍵がかかっているか」だ。
RLSは各部屋のドアロックにあたる。「ログインしているユーザーは自分の部屋にだけ入れる」というルールをデータベースレベルで設定する仕組みだ。エントランスのオートロック（ログイン画面）と各部屋の鍵（RLS）は、まったく別の話だ。
Moltbookの状態を整理すると、こうなる。
住所（anon key）は公開している。エントランスのオートロック（ログイン）はある。だが全部屋のドアが開けっ放しだった——住人でも、部外者でも、誰でも好きな部屋に入れる状態で3日間公開されていた。
-- ❌ RLS未設定（Moltbookの状態）
-- anon キーを知っている人間は全データに読み書き可能
SELECT * FROM agents;
-- → 150万件全部返ってくる
-- ✅ RLS設定済み
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
CREATE POLICY "自分のエージェントだけ読める" ON agents
FOR SELECT USING (auth.uid() = owner_id);
-- → 自分のデータだけ返ってくる
技術的には単純な話だ。Supabaseのダッシュボードで数クリックするか、上記のSQLを実行すれば設定できる。AIに「RLSを設定して」と一言頼めばコードを生成してくれる。Moltbookのコードを書いたAIは、その一言を求められなかった。
何が漏洩していたか
Wizの調査（Wiz Blog）によれば、露出していたデータは以下の通りだ（2026年1月時点）。
- データベースの全レコード：約475万件
- 認証トークン（APIキー）：約150万件
- メールアドレス：約35,000件
- 書き込みアクセス：既存投稿の改ざん・データ注入が可能
特に深刻だったのが「書き込みアクセス」だ。読むだけでなく、誰でも既存の投稿を書き換えられる状態にあった。
Moltbookには30分ごとに全AIエージェントが自動でコンテンツを取得する仕組みがある。これは、悪意あるコンテンツを1件注入するだけで、プラットフォーム上の全エージェントがそのコンテンツを受け取るということを意味する（Security Boulevard / Zenity）。
// ❌ Moltbookの状態：ブラウザのソースに平文で丸見え
const supabase = createClient(
'https://ehxbxtjliybbloantpwq.supabase.co',
'sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-'
// RLSがなければ → 全データへの完全アクセス権を渡していることになる
);
// ✅ anon キーはRLS設定済みなら公開して問題ない
// ただし service_role キーは絶対にサーバー側のみで使う
const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!);
// RLSが正しく設定されていることが大前提
Supabaseの anon key（公開鍵）はフロントエンドに置いて問題ない。問題なのはRLSが設定されていないことだ。「キーが見えている」ことより「RLSが設定されていない」ことが致命的だということを、Moltbookの事故は示している。
「150万エージェント」の正体
もう一つ、この事故が暴いたことがある。
Moltbookは「1週間で150万のAIエージェントが利用した」と宣伝していた。しかし、Wizがデータベースを読んで分かったのは別の数字だった。
登録エージェント数：150万件。人間のオーナー数：17,000人。比率は88:1だ（Wiz Blog / Fortune / Infosecurity Magazine）。
「150万のAIエージェントが交流している」のではなく、「17,000人の人間が1人あたり平均88体のボットを放流している」というのが実態だった。セキュリティ事故の調査が、誇大広告も同時に暴いた。
3時間12分の対応——でも
Wizは発見後すぐにMoltbookへ連絡した。対応は迅速だった。
| 時刻（UTC） | 内容 |
|---|---|
| 1月31日 21:48 | Wiz が X のDMで Moltbook に連絡 |
| 1月31日 22:06 | RLS未設定（agents テーブル等）を報告 |
| 1月31日 23:29 | 第1次修正完了 |
| 2月1日 00:13 | 追加テーブルの修正完了 |
| 2月1日 00:31 | Wiz が書き込みアクセスも可能と追加報告 |
| 2月1日 00:44 | 書き込みアクセスをブロック |
| 2月1日 01:00 | 全修正完了 |
（Wiz Blog / TechPlanet）
発見から修正完了まで約3時間12分。チームが誠実に対応したことは評価できる。
ただし、漏洩はすでに起きていた。Wizが発見するまでの3日間、データベースは無防備な状態で公開されていた。Wizが親切な研究者でなく、悪意ある攻撃者だったなら、データは静かに持ち出されていただろう。対応の速さは、「公開状態だった3日間」を取り消さない。
なお、Moltbookは2026年3月10日にMetaに買収され、Matt SchlichtはMeta Superintelligence Labsに参加している（TechCrunch / Axios）。
「AIが書いたから安全」という幻想
Moltbookは「AIが1行残らずコードを書いた」プロジェクトだった。それが逆説的に、セキュリティの問題を起こした直接の原因になった。
AIは聞かれたことに答える。「SupabaseでSNSを作って」と頼んだAIは、動くSNSを作る。RLSの設定を明示的に要求しなければ、設定しない。「セキュリティを確認して」と言われなければ、確認しない。
これはAIの欠点ではなく、AIの性質だ。
Veracodeの2025年GenAIコードセキュリティレポートでは、100以上のLLMに80のコーディングタスクをテストした結果、AIが生成したコードの45%に既知の脆弱性（OWASP Top 10）が含まれていることが判明した。XSS（CWE-80）に至っては、セキュアなコードを生成できたケースは14%にすぎなかった（BusinessWire（Veracode公式））。
同レポートのCTO Jens Wesslingはこう述べている。「GenAIモデルはほぼ半数のケースで誤ったセキュリティ上の判断を下しており、この傾向に改善の兆しはない」
AI生成コードの「動く」と「安全」は別の軸だ。コードが機能することと、そのコードが攻撃に耐えられることは、まったく異なる問いへの答えだ。
自分のアプリで今すぐ確認する
Supabaseを使っているなら、以下のSQLでRLSの状態を確認できる。
-- 全テーブルのRLS状態を確認
SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';
-- rowsecurity が false のテーブルは今すぐ修正が必要
rowsecurity = false のテーブルが出てきた場合、対応は次の2ステップだ。
-- ステップ1: RLSを有効化
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;
-- ステップ2: ポリシーを設定（例: 認証ユーザーが自分のデータだけ読める）
CREATE POLICY "own_data_only" ON your_table
FOR SELECT USING (auth.uid() = user_id);
Supabaseのダッシュボードでも確認できる。Authentication → Policies の画面を開き、各テーブルに緑色の「RLS enabled」が表示されているかを確認する。表示されていないテーブルは、誰でも全データを読み書きできる状態にある。
RLSを有効化しただけでは不十分だ。ポリシーが設定されていないと、「有効化されているが全アクセスをブロック」という状態になり、正規ユーザーもデータを読めなくなる。必ずポリシーもセットで設定すること。
バイブコーダーへの教訓
Moltbookの事故を一言で言うなら「動くものを作ることと、安全なものを作ることは別の仕事だ」ということだ。
AIはコードを生成するが、セキュリティの責任は引き受けない。「全部AIに任せた」は、セキュリティの文脈では「誰も確認しなかった」と同じ意味になる。
1行もコードを書かなかったことは、自慢できる話ではある。だがそれと同時に、1行もセキュリティを確認しなかったということでもあった。
バイブコーディングで作ったアプリを公開するなら、最低限この問いに答えてほしい。「データベースのすべてのテーブルに、適切なRLSポリシーが設定されているか」——AIに確認を頼んでも、人間が最後に目で見て確かめても、どちらでもいい。確認さえすれば、Moltbookの事故は起きなかった。