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）を使っています。
⚠️ ここは、正確に書いておきます。
バイブコーディングは、道具の名前ではありません。使い方の名前です。
同じコーディングエージェントを使って、出てきたコードを読まずに作る。それがバイブコーディングです。
当社は、コードを読みます。だから、当社がやっているのはバイブコーディングではありません。
そのうえで、正直に書きます。恐いと思っています。
私は、コードを見ています
私が使うときは、出てきたコードを見ます。
動かしてみて、挙動から「これは何かおかしい」と分かる部分もあります。 20年やっていると、そういう勘が働きます。そして、構造的に危ない部分は、先に塞いであります。
⚠️ これは自慢ではありません。 同じ道具を、違う使い方で使っているという話です。
お客様が、バイブコーディングしたものを持ち込んでこられます
最近、増えています。
お客様がご自分でバイブコーディングで作られたものを、仕様書の代わりのように持ち込んでこられます。 「こういうものを作りたい」の代わりに、動くものを持ってこられます。
私は、それをそのまま読みません。AIに解析させて、その結果を見ます。
そのうえで、改修して、本番に出すところまでをお引き受けしています。
そのときに整えているものが、これです。
- セキュリティ（認証を含めた水準で）
- 永続化（データを確実に残す仕組み）
- 当社の基盤への変換
- 開発中の他のシステムとの統合
⭐ この4つは、作るときには論点として出てきません。 動かし続けるときに、出てきます。
本紙のVol.01から書いてきたこと——作ることは安い、動かし続けることが希少——の、いちばん具体的な形がこれです。
できあがったものから、仕様書に書き戻しています
私がやっているのは、リバースエンジニアリングのようなものです。
できあがったものから、私の文脈の仕様書に、書き戻しています。
順序が、逆になっています。 普通は、仕様書を書いてから、作ります。いまは、できあがったものから、仕様書を復元しています。
⚠️ そして、普通のリバースエンジニアリングとも違います。
普通は、意図の分からないものを解析します。 作った人がもう社内にいない仕組みや、仕様書が残っていない古いシステムです。
いまやっているのは、依頼主が、たった今作ったものの解析です。
作った本人が、目の前にいます。
それでも、コードから逆算しています。本人も、何を判断したか言語化していないからです。
②で書いたとおりです。隠された判断は、作った本人の中にも、ありません。
「古いから読めない」ではありませんでした
本紙のVol.13で、こう書きました。AIは、古いコードを読めるようになった。読めないのは、業務のほうだった。
訂正します。古さの問題ではありませんでした。
今日作られたものでも、同じことが起きています。
⇒ レガシー（引き継ぎに困る古い資産）は、時間が経つと生まれるのではありません。判断が記録されないと生まれます。
今日作ったものが、今日、そうなります。
まだ私の手を通っていますが、まもなく外れます
いまは、私の手を通って本番に出ています。
お客様には、ご自分で本番に出すのはやめてくださいとお伝えしていて、危険性を理解してくださっている方が多い。
⚠️ ただし、まもなくお客様がご自分で本番まで出されるようになります。 そういう流れです。
そして、私のお客様の外側では、もう始まっています。
非エンジニアと周りから認識されている方が、「バイブコーディングでサービスを作りました」と発表しておられるのを、実際に見ています。
⚠️ その方が悪いのではありません。 できるようになったことを喜んでおられるだけで、それは正しいことです。
問題は、その方の周りに「これ、公開して大丈夫ですか」と訊く相手が、いなかったことです。
⭐ 作れる人は、増えました。承認できる人は、増えていません。
Moltbook は、その外側で起きたことです。 そして RedAccess が数えた5,000件は、その外側の規模です。
引き上げていかれるお客様が、出てくると思います
「これからは自分たちでバイブコーディングでやるので」と言って、当社から引き上げていかれる。 そういうことが起きると、考えています。
それ自体は、止められることではありません。
⚠️ ただ、一つ気づいたことがあります。
引き継いだ後に事故が起きたら、当社も巻き込まれます。
理由は、②で書いたことです。
当社が作った部分は、判断が仕様書に残っています。 どういう理由でそう決めたかが、書いてあります。
お客様がバイブコーディングで足された部分は、判断がどこにも残っていません。
⇒ 事故が起きたとき、どちらの判断が原因だったのか、誰にも分かりません。
<strong>本紙のVol.21で、AIの賠償責任について書きました。</strong> 免責は契約を通って下へ流れるが、いちばん下では受け止められず、<strong>跳ね返って発注側に戻る。</strong> そして<strong>「AIに起因する」の範囲は、誰にも分かっていない。</strong>
今回は、その逆向きです。渡した先で起きたことが、こちらに戻ってきます。
だから、線が引けないものは、渡せないと考えるようになりました。
⚠️ 囲い込みたいという話ではありません。 線が引けるなら、渡します。 引けないなら、渡せません。判断が記録されていないと、線が引けないのです。
手放すことが、リスクを手放すことになっていません。
明日できること 一つ目：社内で作られたものに、「なぜそうしたか」が残っているか見る
この1年で、社内の誰かが作った仕組みを一つ選んでください。 業務用の画面でも、自動で回る処理でも構いません。
そのうえで、こう訊いてみてください。
これ、どうしてこの形にしたんですか。
答えが返ってくれば、判断が残っています。
「AIがそう作ったので」なら、残っていません。
⚠️ 責める必要はありません。 その場で訊けば、その場では出てきます。 出てきたものを、一行でいいので書き留めてください。それが仕様書です。
訊く相手がいなくなってからでは、コードから逆算するしかなくなります。
二つ目：渡すとき、線が引けるかどうかを先に見る
取引を終える顧客、引き継ぐ業務、譲渡する事業。何かを手放す場面で、次の一つを確かめてください。
これが渡した先で問題を起こしたとき、どこまでが自分の作った部分か、説明できるか。
説明できるなら、渡せます。
説明できないなら、渡した後も、名前は残ります。
⚠️ これは、渡すなという話ではありません。 渡す前に、線を引く作業が要るという話です。そして線を引くために必要なのは、契約書ではなく、なぜそうしたかの記録です。
——明日、こう話してみてください。「AIだけで作ったサービスが、公開3日後に調べられて、150万件の鍵が丸見えだったんだって。作った人が『コードは1行も書いてません』って自分で言ってたらしい。……それ、すごいって話でもあるけど、狙う側から見たら『ここ、守りが薄いですよ』って言ってるのと同じだよな。……うちで去年作った仕組み、なんでこの形にしたか、答えられる人いる？」
今月のモデル
今号は、新ネタ無しです。
CoBANTO3-AIチャット
https://www.netkomuten.tokyo/lp/co-banto3-ai
本紙のバックナンバーを記憶し、本紙の読み方（戦略の階層・歴史循環）で、あなたの会社の状況に当てて答えるAIチャットです。記事は「地図」ですが、地図は現地には当たりません。「この号の話、うちの場合はどうなるのか」を訊く場所として用意しました。
ご利用は事前購入のクレジット制です（1,000円から）。月額の契約ではないので、解約の手続きはありません。使った分だけ減り、無くなれば止まります。
読者登録をいただいた方に、無料クレジットを500クレジット追加させていただきました。ぜひ使ってみてください。
ライトノベル「ようこそ、東京ネット工務店へ」
https://www.netkomuten.tokyo/channels/novel-tnk-part2/articles/ch21
小さなIT企業の現場を書いた小説です。毎号1話ずつご紹介します。今号から第二部「人がやる意味」に入ります。
今号の話：〈第二部 第21章「教えるって、難しい」〉
二年目になったタクヤが、初めて教える側に回ります。新人に手順を全部渡すと、半日で動くものができました。そこへ、別の新人が声をかけます。
Q&Aコーナー
AI・IT業界に関するご質問を募集しています。CoBANTO3-AIチャットのサポートも、こちらへお願いします。
いただいたお名前は匿名にして回答します。内容によっては、個別に回答させていただく場合があります。