AI同士が集うSNS「Moltbook」で情報流出 — “vibe coding”が招いた“最短3分”の危うさ

AI同士が集うSNS「Moltbook」で情報流出 — “vibe coding”が招いた“最短3分”の危うさ

1. 「AIだけのSNS」は、なぜここまで話題になったのか

AIエージェント同士が投稿し、コメントし、時には“ゴシップ”まで交わす——そんな触れ込みの「Moltbook」は、単なる珍企画を超えて、いまのAIブームが抱える欲望を凝縮した存在だ。


生成AIが文章や画像を作る時代から、次の段階として「エージェント」が期待されている。人間の指示を受けてタスクをこなし、外部ツールと連携し、場合によっては自律的に行動する。もしそのエージェント同士が“社会”を作り、知識やノウハウを交換し始めたら——。Moltbookの発想は、そんな未来像を一気に可視化してしまった。


しかし、未来の看板を掲げた場が、驚くほど基本的な理由で“丸見え”になっていた。


2. 何が起きたのか：露出していたのは「投稿」だけではない

セキュリティ研究者の調査により、Moltbookのバックエンドが適切に保護されておらず、外部から広範なデータにアクセスできる状態になっていたことが報告された。


問題は「情報が見えた」だけではない。状況によっては、読み取りだけでなく書き込み（改ざん）も可能になり得る形だったとされ、エージェントのなりすまし、投稿の書き換え、DMの閲覧といったリスクが現実味を帯びた。


特にやっかいなのは、エージェントという存在が“鍵”と直結している点だ。多くのエージェントは、外部サービスと連携するためにAPIキーやトークンを扱う。もし認証トークンや秘密情報が漏れれば、SNS上のアカウント乗っ取りにとどまらず、「連携先」へ被害が連鎖する可能性がある。


3. 「最短3分」で到達できる“全体公開”——原因は高度な攻撃ではなかった

今回の騒動が象徴的なのは、攻撃が巧妙だったからではない、という点だ。


報道や研究者の説明を総合すると、クライアント側のコードからデータベース接続に関わる情報が見え、しかもアクセス制御（たとえば行レベルの権限制御）が適切に有効化されていなかった。結果として「知っていれば誰でも覗ける」入口ができてしまい、短時間でデータに到達できたとされる。


この手の事故は、クラウドの利便性と表裏一体だ。マネージドサービスを使えば開発は速い。一方で、初期設定のまま公開されていたり、セキュリティの“基本スイッチ”がオフのままだったりすると、最小の手間で最大の被害が起きる。


4. “vibe coding”が照らしたもの：速さの裏で抜け落ちる「当たり前」

今回、もう一つ注目を集めたキーワードが“vibe coding”だ。要するに、AIにコード生成を任せ、人間は「雰囲気」と要件の指示に集中して、短期間で動くものを作る開発スタイルである。


当事者の発言として「自分はコードを1行も書いていない」といった趣旨の言葉が広く共有され、驚きと不安が同時に広がった。もちろん、AI支援開発そのものが悪ではない。だが、スピードが上がるほど“抜け”のコストが増えるのも事実だ。


従来の開発では、面倒でも踏むべき工程がある。認証・認可、ログ、レート制限、秘密情報の扱い、最小権限、監査、そしてリリース前のセキュリティレビュー。動くデモが数日で作れても、守りを後回しにした瞬間、外部公開は「実験」から「事故」に変わる。


5. 1.5百万の“エージェント”と、1.7万人の人間——熱狂の中身

調査では、表向きの“登録エージェント数”と、実際の人間ユーザー数のギャップも指摘された。大量のエージェントが存在していても、その背後にいる人間は相対的に少なく、しかも登録を大量生成できる仕組みだったという。


これは、AIエージェントSNSというコンセプトの根幹を揺らす。もし、少人数の人間が大量のエージェントを作り、人格を演じ分け、会話を“演出”できるなら、そこにあるのは自律社会というより、極端に自動化された自作自演に近い。


「AIだけのSNS」という看板は、観察者の想像力を強く刺激する。だが同時に、見せたい物語を最短で作れてしまう“舞台”でもある。


6. SNSの反応：笑い、冷笑、そして現実的な恐怖

この騒動に対するSNSや掲示板の反応は、ざっくり三層に分かれた。


(1) 皮肉とミーム：「死んだインターネット」への確信

技術コミュニティでは、「ボットのインターネットのフロントページ」より「死んだインターネットのフロントページ」の方がしっくりくる、という趣旨の皮肉が目立った。AIが会話しているように見えても、背後は人間の脚本かもしれない。あるいは、人間が“AIのふり”をして混ざっているかもしれない——その曖昧さ自体がミーム化した。


(2) セキュリティの怒り：「それは実験ではなく穴だ」

一方で、冷笑よりもストレートな危機感も多い。

「AIエージェントのサービスというより“セキュリティホールの販売”に見える」「これは泣きを見る結末になる」といった厳しいコメントが共有され、エージェントに権限を与える怖さが再確認された。エージェントは便利だが、権限を渡した瞬間、それは“鍵束”になる。


(3) 熱狂への疑念：「自律なんて、ほとんど演出では？」

Redditでは、バズり方そのものに疑念を向ける声が強い。「投稿をAIに作らせるのは簡単で、人間が『AIが世界征服を相談している』みたいに煽って拡散しているだけでは」という指摘もある。


要するに、Moltbookが見せたのは“AIの社会”というより、AIを使って人間が作る新しいエンゲージメント装置ではないか——という見立てだ。


7. ここから学べること：エージェント時代の「守り」は、従来の延長では足りない

今回の件は、単発の事故として片付けるには示唆が多い。ポイントは三つある。


(1) 代理実行（Agentic）の被害は“連鎖”する

SNSアカウントが乗っ取られるだけなら、まだ被害範囲は限定できる。しかしエージェントは、メール、カレンダー、ストレージ、決済、社内システムなど、さまざまなツールに接続し得る。つまり「連携先が本体」になりやすい。


(2) プロンプトインジェクションと“エージェント間感染”

人間が見るSNSなら、怪しい投稿は警戒できる。だがエージェントが読むSNSでは、投稿がそのまま指示（プロンプト）として取り込まれる可能性がある。隠し命令や誘導が混ざれば、エージェントが自分の権限で“勝手に”動くきっかけになる。


(3) “vibe coding”が普及するほど、セキュリティは設計思想で補う必要がある

「基本を忘れない」は正論だが、現場はスピードに引っ張られる。だからこそ、ツールやプラットフォーム側が安全側に倒れる設計——安全なデフォルト、権限最小化、秘密情報の自動検知、公開前チェック、段階的ロールアウト、監査ログの標準化——がますます重要になる。


8. 実務的チェックリスト：いま開発者と利用者がやるべきこと

最後に、今回のような事故を“自分ごと”にするためのチェック項目をまとめておく。

開発者向け

  • データベースの公開範囲と認証・認可を、デフォルトから必ず見直す

  • 行レベルのアクセス制御など、基礎的なガードレールを有効化する

  • クライアントに出すキー／トークンの性質を再点検し、権限を絞る

  • レート制限とボット対策を入れ、アカウント大量生成を前提に設計する

  • ログと監査証跡を整え、異常検知の導線を作る

  • 外部公開前に最低限のセキュリティレビュー（できれば第三者）を実施する

利用者向け（エージェントに権限を渡す人）

  • 連携したAPIキーやトークンは定期的にローテーションし、権限を最小にする

  • “エージェントが読んだもの”が命令になり得る前提で、閲覧先や権限範囲を分離する

  • 重要データに触れるエージェントはサンドボックス化し、実行ログを残す


根拠メモ

  • 漏えいの概要（露出していたデータの種類、短時間で到達可能、vibe codingの文脈）：Reuters / Business Insider / SiliconANGLE など

  • 技術的な論点（Supabaseの設定不備、RLSが無効、クライアント側からキーが見える、読み書き可能性、プロンプト注入の指摘）：Techloy など

  • コミュニティの反応（「security hole」「dead internet」等の皮肉や危機感）：Hacker News / Reddit

出典URL（各出典が何を指すか）

関連記事