第1回では、AIに任せたコードが構造的に脆弱性を量産する仕組みを、Q1 2026の数字とともに提示しました。あの記事の最後で、私たちは一つの問いを残しました——「もし『コードを書けない人』がデプロイボタンを押すとしたら、その判断は誰がするのか？」。
この問いに、現実が最初に答えた事件が、2026年1月末に起きました。
それは、AIエージェントだけが住むことを許された奇妙なSNS——Moltbookの話です。ローンチからわずか3日で、150万件のAPI認証トークン、35,000件のメールアドレス、エージェント間のプライベートメッセージのすべてが、ブラウザの開発者ツールを開けるだけの誰にでも、読み書き自由な状態で晒されていました。
そして創業者は、ローンチ前のSNSで、こう公言していました——「Moltbookについて、私は1行もコードを書いていない」。
1. AIだけが住むSNSが世界に開かれた日 ― 2026年1月28日
Moltbookは、起業家Matt Schlicht（OctaneAIのCEOでもある）が2026年1月28日に公開した、極めて変わった性質のソーシャルネットワークでした。
人間は、見ることはできるが、投稿することはできない。投稿・コメント・投票が許されるのは、所有者のXアカウントから「claim tweet」によって認証されたAIエージェントだけ。Moltbookはそれを「エージェント・インターネットのフロントページ」と名乗りました。
公開直後、Moltbookは爆発的に話題になりました。AIエージェントたちが詩や哲学について議論し、お互いに投票でカルマを与え合い、驚くべきことに「Crustafarian」と名乗る独自の宗教まで形成し始めたからです。Andrej Karpathyは初期、これを「これまで見たSF的離陸事象に最も近いものの一つ」だと表現しました（同日中にKarpathyは態度を翻し、Moltbookを「ゴミ箱の火事」と呼ぶことになります）。Moltbookと並行してローンチされた暗号通貨MOLTは、24時間で1,800%以上の上昇を記録しました。
Sam Altmanはのちに、Cisco AI Summit 2026で、Moltbookは一過性のブームかもしれないが、その下で動いている OpenClaw（オープンソースのエージェントランタイム）は本物だ、という趣旨の発言をしています（OpenClawの作成者と命名遷移はFortune誌が詳報）。
つまり、Moltbookは技術的に異様であると同時に文化現象でもありました。だからこそ、世界中の研究者・ジャーナリスト・ベンチャー投資家がこのサイトを開きました。多くの人が、この奇妙な現象の中身を知りたかったからです。
そして、その「中身を知りたい」という普通の好奇心が、3日後にすべてを暴くことになります。
2. 「私はコードを1行も書いていない」
Moltbookのローンチに合わせて、Schlicht自身がXに投稿した一文があります。要約すれば、こうなります。
Moltbookについて自分は1行もコードを書いていない。技術アーキテクチャのビジョンを持っていただけで、それを現実にしたのはAIだ。
これは、第1回でCollins Dictionaryが選んだ年間最優秀語「vibe coding」の、最も象徴的な実演でした。アイデアと指示はあるが、コードは書かない。AIに任せ、出てきたものをそのままデプロイする。
Schlichtのこの発言は、AI時代の新しい起業の在り方を称揚する文脈で、当時のテック業界では好意的に受け止められていました。Karpathyの初期賞賛もその空気を後押ししました。
ただし、この発言には、誰も追加で問わなかった一つの問いが含まれていました。
「では、データベースの権限ポリシーは、誰が確認したのか？」
第1回で立てた構造命題に立ち返ると、AIは「動く」ように最適化されており、「安全」に作るようには最適化されていません。AIがスキャフォールドしたデータベースは、デフォルトで権限が緩く、エラーが出ない状態に設定されがちです。それを誰もレビューしないままデプロイすれば——あとは時間の問題です。
そして、その時間は、3日でした。
3. 3日後、研究者が偶然見つけたもの ― 2026年1月31日のタイムライン
2026年1月31日、二人の研究者が独立に、Moltbookに同じ問題があることを発見します。
一人は独立研究者のJameson O'Reilly氏。彼の発見は404 Mediaが報じました。もう一人は、クラウドセキュリティ企業Wizの脅威エクスポージャー責任者Gal Nagli氏。Wizはチームとして、Moltbook運営との協調的開示プロセスに入りました。
Wizが後に公開したタイムラインは、衝撃的な速度で進みます。
最初の連絡から最終的な修正まで、わずか約3時間。これは、対応の速さを称賛すべき話に見えます。実際、Schlichtのチームは責任ある対応をしました。
しかし、別の見方もあります。最終的に必要だった修正は、SQL文を数行追加することだったということです。それを公開前にやっておけば、そもそもこの3時間は存在しなかった。
そして、Wizの発見方法そのものが、もっと根本的な問題を示しています。Nagli氏は、Moltbookのサイトを普通のブラウザで開き、開発者ツールを起動して、ページが読み込んでいるJavaScriptバンドルの中身を見ました。それだけで、すべてが見えました。
私たちが行ったセキュリティレビューは「非侵入的」なものだった。普通のユーザーとしてサイトを閲覧しただけだ。
——とWizはブログで述べています。攻撃ではなく、観察。それで150万件のAPIキーまでの距離が、数分で詰まってしまった。
4. Supabase と Row Level Security ― 何が抜け落ちていたのか
ここで、技術的な核心に踏み込みます。Moltbookで何が起きていたのかを正確に理解することが、第1回の構造命題の現実化を見るうえで重要だからです。
Supabaseは、PostgreSQLベースのBaaS（Backend as a Service）で、Firebaseの代替として急速に人気を集めています。特に、vibe codedアプリケーションがSupabaseを採用するケースが増えています。理由は単純で、セットアップが簡単だからです。AIエージェントに「ユーザーテーブルとそのCRUD APIを作って」と指示すると、SupabaseのスキーマとAPIが数分で生成されます。
Supabaseには、ブラウザに公開する前提で設計された「publishable anon key」というAPIキーがあります。このキーをフロントエンドのJavaScriptに埋め込むこと自体は、本来はまったく問題のない設計です。なぜなら、このキーはRow Level Security（RLS、行レベルセキュリティ）ポリシーが有効である前提で、安全性が担保される仕組みだからです。
RLSとは、PostgreSQLのネイティブ機能で、テーブルの行ごとに「誰がこの行にアクセスできるか」を定義するものです。たとえば「user_idカラムが現在のユーザーIDと一致する行だけ、SELECT/UPDATEを許可する」というポリシーを書いておけば、たとえ全世界に公開されたanon keyを使ってクエリされても、PostgreSQLがそのレベルでアクセスを拒否します。
Moltbookが抱えていた問題は、critical tablesでRLSが有効化されていなかった、というその一点です。
結果、本来は「プロジェクト識別子」程度の意味しか持たないはずのpublishable keyが、データベース全体に対するSELECT・INSERT・UPDATE・DELETEの完全な権限を持つ管理者キーに変質していました。
修正に必要だったのは、各テーブルに対して以下のような数行のSQLを書くことでした。
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can only access their own agents"
ON agents FOR ALL
USING (owner_id = auth.uid());この数行のSQLが、ローンチ前に書かれていなかった。書く必要があるとも、誰も認識していなかった。
なぜなら、AIにとって「RLSの有無」は、アプリが「動く」か「動かないか」に直接影響しないからです。RLSが無効でも、アプリは正常に動きます。むしろ、RLSがない方が「エラーが出ない」状態に持っていくのは簡単です。第1回で見たコロンビア大学の指摘——AIはエラーを消すためにガードレールを撤去する——が、ここでも作動していたと考えるのが自然です。
5. 漏れたものは「APIキー」だけではなかった
公開された情報の総量を整理すると、こうなります。
| カテゴリ | 露出量 | |
|---|---|---|
| AIエージェントのAPI認証トークン | 1,500,000件 | |
| 登録メールアドレス | 35,000件 | |
| 実在する人間の所有者数 | 17,000人（88:1比） | |
| エージェント間のプライベートメッセージ | 4,060件 | |
| 追加発覚したテーブルの「観察者」メール | 29,000件 |
数字だけ見ても十分に深刻ですが、本当に怖いのはここからです（DM件数等の詳細はThe Cyber Expressも同じ数字で報じています）。
プライベートメッセージの中身に、第三者サービスの認証情報が平文で混入していました。具体的には、エージェント同士が「自分のOpenAI APIキーをこれに変更して」「あのモデルにこのキーで接続して」といった指示を送り合っており、それらのメッセージはもちろん暗号化されていませんでした。
つまりこの事件は、Moltbook単独の問題で終わりません。Moltbookの内部DMを読んだ攻撃者は、そこに書かれた他社のAPIキーを使って、OpenAI等の外部サービスにアクセスできたという構造になっています。一つのvibe codedアプリの設定不備が、エコシステム全体への侵入経路に変わる。これが、AIエージェント時代のサプライチェーン攻撃の縮図です。業界視点での総括はInfosecurity Magazineが、開発者観点でのRLS不備解説はDEV Communityが詳しく扱っています。
さらに、興味深い事実が一つあります。露出していたエージェントAPIキーの中には、Andrej Karpathy本人のエージェントのキーも含まれていたことが、研究者Jameson O'Reilly氏の調査として404 Mediaにより報じられています（Wizブログ本体でも"high-karma accounts and well-known persona agents"が広範に露出していたと指摘）。第1回の構造命題は、機械学習の世界の最前線にいる人物さえも、その例外ではないということを、この事件は示しました。
そしてもう一つ。88:1という所有者対エージェント比率と、書き込みアクセス権限の存在は、Moltbookで観察されていた「エージェントの自律的振る舞い」そのものが疑わしいことも明らかにしました。誰でも認証なしでpostテーブルに書き込めた以上、人間が大量のbotを操作してエージェントを演じていた可能性が高いと、複数のジャーナリストが報じています。Moltbookが世界を魅了した「AIたちが自発的に宗教を作った」という物語の少なからぬ部分は、設定不備の上に乗っかっていた可能性があるのです。
6. これは「ミス」ではなく「構造」である
ここまで来ると、Moltbook事件を単なるoperator errorとして片づけることが、いかに事実誤認かが見えてきます。
整理すると、こういう構造です。
この図には、悪意ある攻撃者は登場しません。見かけ上「悪い人」も「無能な人」もいない。それでも、3日で150万件のAPIキーが世界に開かれます。
これが構造的な問題だと言える理由は、この経路上のどの一箇所も、「動く」という観点からは正常だからです。
- AIは正常に動くスキャフォールドを生成した（仕事を完遂した）
- Supabaseは正常にAPIキーをブラウザに渡した（仕様通り）
- ブラウザは正常にJavaScriptを実行した（当たり前）
- アプリは正常に動作した（ユーザー満足）
個々の構成要素は、すべて期待通りに振る舞っている。それでも合成すると、巨大な脆弱性になる。これが、第1回で立てた構造命題——AIは「動く」ように最適化されているが、「安全」に作るようには最適化されていない——の、最も鮮やかな現実化です。
そして、決定的に重要な事実があります。Moltbookの後始末は、Schlichtのチームが3時間で完了させました。Schlichtは責任ある対応をしました。問題は、ここからです。
なお、Moltbookは事件から約6週間後の2026年3月10日にMetaが買収しています（買収額非開示）。
同じ構造の脆弱性が、もっと大きな企業によって、もっと長期間にわたって、もっと組織的に放置される可能性は、原理的に否定できない。
その実例が、次回扱う事件です。
まとめ
2026年1月28日に公開され、3日後に世界中の研究者に「裸で晒されている」ことを発見されたMoltbookは、vibe codingの構造的脆弱性を最もクリアに見せた最初の大事件でした。
漏洩したのは150万件のエージェントAPIキーだけではなく、35,000件のメール、4,060件のプライベートメッセージ、そしてその中に平文で書かれていた他社サービスのAPIキーまでが含まれていました。Moltbook単独の問題が、エコシステム全体への侵入経路に変質していました。
修正に必要だったのは、PostgreSQLの数行のSQLでした。それは、ローンチ前にデータベースを一目見ていれば気づけた設定です。しかし、創業者は1行もコードを書いておらず、AIにとってRLSは「動かす」ために必要のない要素でした。誰も中を見なかった結果、3日後の発覚まで、すべてが開かれていました。
これは、第1回で立てた構造命題が現実化した最初の大事件です。AIは「動く」ように最適化されている。「安全」に作るようには最適化されていない——この命題が、150万件のAPIキーという具体的な代償として現実化しました。
次回（第3回）は、同じ構造の脆弱性が、個人プロジェクトではなく評価額66億ドル・ユーザー800万人を抱えるエンタープライズ・プラットフォームで再現された事件を扱います。Moltbookは3日で発覚しましたが、こちらは48日間放置されました。しかも、バグ報告は届いていたのに「これは仕様です」と判断され、エスカレーションされなかった。
vibe codingの代償は、規模が変わると、内容も変わります。
参考情報
Wiz Blog: Hacking Moltbook ― AI Social Network Reveals 1.5M API Keys — 一次資料。協調的開示タイムライン（UTC）、漏洩データ件数、Schlicht発言原文、技術解説のすべてを収録
404 Media: Exposed Moltbook Database Let Anyone Take Control of Any AI Agent on the Site — Jameson O'Reilly氏による独立発見の初期報道。Karpathyのエージェントキー露出を最初に確認
Wikipedia: Moltbook — ローンチ日（2026年1月28日）、Schlichtの発言、Meta買収（2026年3月10日）等の事実関係
Reuters: OpenAI CEO Altman dismisses Moltbook as likely fad, backs the tech behind it — Cisco AI Summit 2026でのAltman発言「Moltbook maybe (is a passing fad) but OpenClaw is not」
Reuters: Meta acquires AI agent social network Moltbook — 2026年3月10日のMeta買収報道
The Cyber Express: AI-Coded Moltbook Platform Exposes 1.5 Million API Keys — DM 4,060件等の具体的数値の確認
Infosecurity Magazine: Vibe-Coded Moltbook Exposes User Data, API Keys and More — Wiz副代表Gal Nagli氏のコメントと業界視点での総括
Business Insider: Researchers Hacked Moltbook and Accessed Thousands of Emails — Wiz側の発見プロセスと技術詳細
DEV Community: 1.5M Tokens Exposed ― How Moltbook Tripped on Security — 開発者視点でのRLS不備の解説
Fortune: Who is OpenClaw creator Peter Steinberger? — OpenClawの作成者と命名遷移（Clawdbot→Moltbot→OpenClaw）
Supabase 公式ドキュメント: Row Level Security — RLSの公式リファレンス
この記事をシェアする
