2026年8月21日／株式会社東京ネット工務店 海老沢敦
① 事実
「私は、1行もコードを書いていません」
2026年1月28日、Moltbook というサービスが一般公開されました。 AIエージェント（人が逐一指示しなくても自分で手順を判断して動くAI）同士が交流する、SNSのような場です。
創業者が、こう書いています。
私は Moltbook のために、コードを1行も書いていません。 技術的なアーキテクチャ（全体の構造）についての構想を持っていただけで、それをAIが現実にしました。
3日後、セキュリティ企業の Wiz が調べ始めました。
数分で、鍵が見つかりました
Wiz の報告書に、こうあります。
数分のうちに、私たちは公開されている Supabase のAPIキーを発見した。
タグ＝セキュリティ, 開発
Supabase は、データベースを手軽に用意できるサービスです。サイトの画面を作るプログラム（ブラウザ側で動くJavaScript）の中に、そのキーが書き込まれていました。
⚠️ ここは、設計上の欠陥ではありません。 Supabase は、このキーが利用者側に見えることを前提に作られています。見えても安全なのは、RLS（Row Level Security＝どの行を誰が読めるかを、データベース側で制限する設定）が有効になっている場合です。
Moltbook には、その設定がありませんでした。
キーを持っている誰もが、データベース全体に触れる状態でした。
露出していたのは、150万件の鍵と、475万件の記録でした
Wiz が確認した内容です。
- APIの認証トークン：150万件
- メールアドレス：35,000件（利用者本人のもの）＋29,631件（観測用の登録）
- エージェント同士の私信：4,060件の会話。その一部に、OpenAI のAPIキーが、そのままの文字列で入っていました
- 記録の総数：約475万件
そして、読むだけではありませんでした。
Wiz は途中で、書き込みもできる状態だと気づいています。 報告書が挙げた教訓の4番目が、これです。
書き込みの権限は、データが見えてしまうことだけよりも、はるかに大きなリスクをもたらす。
通報から修正完了まで、約3時間でした。 Moltbook 側の対応は速かったと、報告書は書いています。
5,000件は、認証がありませんでした
⚠️ ここからの数字は、一次に当たれていません。 イスラエルのセキュリティ企業 RedAccess が2026年5月に公表した調査で、複数の報道が同じ数字を伝えています。 原典の報告書そのものは確認できませんでした。
- 調査対象＝380,000件の、公開されている資産（Lovable、Base44、Replit という、コードを読まずに作れるサービスと、Netlify という公開用のサービスで作られたもの）
- そのうち5,000件以上が、セキュリティも認証も実質的に何も無い状態
- 約40%が、機微な情報を露出——医療情報、財務データ、企業のプレゼン資料、事業戦略の文書、チャットボットと顧客の会話記録
調べ方が、報じられています。
Google と Bing で、各サービスのドメイン名と、いくつかの検索語を組み合わせて引いただけです。
本紙のVol.27で、AIが攻撃の9割を実行した事例を扱ったとき、こう書きました。新しい道具は、一つも作られていない。 今回も同じです。使われたのは、検索です。
② 構造 — 過去の抽象化は手続きを隠した。今回は、判断を隠している
1. 下の層が読めなくなるのは、毎回起きてきた
⚠️ まず、これを「AIのせいで人が育たなくなる」の話にしないでおきます。
コンピュータの歴史は、下の層を隠してきた歴史です。
マシン語（機械が直接読む数値の並び）を読める人は、いまも居ます。 数字の並びを見て「これは x86 だ」と分かる人です。ただし、その人数は減りました。
その上にアセンブラができ、さらに上にC言語ができ、いまの言語ができました。 一段上がるたびに、下の層を読める人は減っています。
そして、それで問題ありませんでした。
当社の代表である私も、マシン語は読めません。 読めないまま、20年以上この商売をしています。
2. 今回だけ違う点が、二つあります
一つ目。下の層が、決まった動きをしません。
コンパイラ（人が書いたプログラムを、機械が読める形に翻訳する仕組み）は、同じものを入れれば、同じものが出ます。 不具合があれば直り、直れば次から同じ動きをします。読めなくても、動作は保証されていました。
AIは、同じ指示でも違うものを出します。 そして本紙のVol.29で書いたとおり、正しく見えて間違っているものを出します。
二つ目。隠しているものが、違います。
マシン語に、その会社の商売は入っていません。 数値の並びは、手続きです。足す、比べる、記憶する。それだけです。
AIが書くコードには、判断が入っています。
本紙のVol.29で、仕訳をAIにやらせた場合の話を書きました。 杓子定規な仕訳になり、財務会計としては合っていて、管理会計が怪しくなる。エラーは出ません。
あれは、判断が埋め込まれた結果です。 規程に書いていないところを、AIが無難に埋めた。その判断は、コードのどこにも「判断」として書かれていません。
⇒ 過去の抽象化は、手続きを隠しました。今回の抽象化は、判断を隠しています。
⭐ そして、バイブコーディングという言葉自体が、それを表しています。
道具の名前ではありません。「出てきたコードを読まない」という、使い方の名前です。 ⇒ 判断を省くことが、言葉の意味に入っています。
だから、道具を止めても解きません。 同じ道具で、読む使い方もできるからです。
3. 隠された判断は、作った本人の中にも無い
ここが、この号でいちばん重要なところです。
Moltbook の創業者は、嘘を書いていません。 技術的な構想は持っていた、と書いています。
⚠️ ただし、構想は判断ではありません。
「RLSを有効にするかどうか」は、構想からは出てきません。 それは、作りながら一つずつ決めていく種類のものです。そして、決めていなければ、決めていないまま公開されます。
「1行も書いていない」は、「判断を一つもしていない」と、そのまま読むことができます。
⭐ そして、同じ一文が、読み手によって別の情報になりました。
- 発信した側にとっては、実績の表明です
- 探している側にとっては、防御が薄いという告知です
⚠️ ただし、「言うな」という話ではありません。 RedAccess は検索で見つけています。発言が無くても、見つかります。 発言は、探す手間を省いただけです。
問題は発言ではなく、その発言が指している先が、守られていなかったことです。
本紙のVol.09で、こう書きました。新しい道具は、その会社が決めていなかったことを映す鏡だ、と。 この一文は、何を決めていなかったかを映しました。
4. Vol.29と、向きが逆です
本紙のVol.29で、AIが「完了しました」と報告しながら実際には処理が通っていない現象を扱いました。 見抜こうとした別のAIは、自信のある締めくくりの言葉を、完了の証拠にしていました。
今回は、自信のある発表が、標的を選ぶ手がかりになりました。
どちらも、表明された自信が信号として働いています。向きが逆なだけです。
③ 経営者の自分事 — 作れる人は増えました。承認できる人は、増えていません
当社は、コーディングエージェント（人が逐一指示しなくても、自分で手順を判断してコードを書くAI）を使っています。
