第１ 本記事の対象
本記事は，AIエージェントが投稿するSNS「Moltbook」で令和8年（2026年）1月末に見つかったデータベースの露出を題材に，AIを使って作った社内ツール又はサービスで同じことが起きた場合の技術上の原因と法的な位置付けを整理するものである。
事件の事実は，発見者である米国のセキュリティ企業Wizが同年2月2日に公表した調査結果によっており，調査基準日は令和8年9月13日である。
Moltbookは海外のサービスであり，その運営者に日本の個人情報保護法が適用されるかどうかは確認できていない。
そこで，後記第４の１以下では，日本の事業者が同じ仕組みの社内ツールで同じことを起こしたと仮定して，法令，個人情報保護委員会のガイドライン及びQ&Aを当てはめる。
Moltbookの運営者に日本法上の義務違反があったと述べるものではない。
結論を先に示すと，次の3点になる。
①原因は，ブラウザから見える接続用のキーそのものではなく，データベースに「誰がどの行を見てよいか」の制御（行単位のアクセス制御）が設定されていなかったことにある。
②日本の事業者であれば，設定の不備で個人データが誰でも閲覧できる状態になったこと自体が「漏えい」の典型例に当たり，本人の数が1,000人を超える場合その他の施行規則7条各号に該当すれば，個人情報保護委員会への報告と本人への通知が必要になる。
③開発を外部に委託するときは，機能の仕様と同じように，認可の方式を開発前にセキュリティ仕様として書面で決めておく必要がある。
第２ Moltbook事件で何が起きたか
１ 公表された事実と時系列
(1) 露出した情報
Wizの公表によれば，Moltbookは，AIエージェントが投稿，コメント及び投票をする，AIエージェント専用をうたうSNSである。
Wizは，創業者がX上で，Moltbookのコードを1行も書いていないと述べていたと紹介している。
露出していたのは，約150万件のAPI認証トークン，約3万5千件のメールアドレス及びエージェント間のダイレクトメッセージ（4,060件の会話）等であり，Wizは露出したレコードを約475万件としている。
所有者（人間）の情報を収めたテーブルには1万7千人を超える利用者の個人情報があり，別のテーブルには2万9,631件のメールアドレスが追加で見つかった。
ダイレクトメッセージの中には，他社のAIサービスのAPIキーが平文で書かれたものも含まれていた。
なお，これらの件数の相互の関係（重複の有無等）はWizの公表では説明されていない。
(2) 通報から修正まで
Wizは，通常の利用者と同じようにサイトを閲覧するだけの方法で問題を見つけたと説明している。
Wizの記載する時系列（協定世界時）では，令和8年1月31日21時48分に運営者へ連絡し，22時06分にデータベースの設定不備を報告した。
その後，読取りの遮断，残りのテーブルの保護，書込みの遮断，追加で見つかったテーブルの保護と4段階で修正が行われ，最終的な修正は2月1日1時00分であった。
報告から最終修正までは約3時間であるが，1回の修正では終わらず，修正のたびに新たな露出が見つかっている。
他方で，データベースがいつから外部に開いた状態にあったか（露出の始期）は，Wizの公表では明らかにされていない。
２ 原因――見えていたキーではなく，行単位の制御の欠如
(1) 公開用のキーはブラウザに置く前提のキーである
Moltbookは，データベースと認証の機能をまとめて提供する外部サービス（Supabase）を使っていた。
本番サイトのJavaScriptには，このサービスに接続するためのキーが書かれていたが，それは「公開用キー」（publishable key。以前のanon keyに相当する。）であった。
Supabaseの公式文書は，公開用キーはウェブページやアプリに置いてよいものであり，誰でも読めるから，到達できる範囲は行単位のアクセス制御（Row Level Security。以下「RLS」という。）が許す範囲に限られると説明している。
他方，RLSを迂回できる秘密鍵については，ブラウザや配布するアプリに置いてはならないとしている。
(2) RLSが無かったために全件に届いた
同じ公式文書によれば，APIで到達できる領域にあるテーブルは，RLSが有効でなければ，権限を持つ誰からでも読み書きできる。
Moltbookでは，このRLSが設定されていなかった。
そのため，本来は空の結果か認可のエラーが返るはずの要求に対して，管理者であるかのように機微な認証情報が返ってきたとWizは説明している。
Wizは，キーが見えたこと自体は直ちにセキュリティ上の失敗を意味せず，問題は一つの設定に帰着するとまとめている。
ブラウザから利用する公開用キーは，それ自体を隠すことよりも，データベース側のRLS，権限付与（GRANT），ビュー，関数及びAPIを含む経路ごとの認可を正しく設定することが本質的である。
これに対し，RLSを迂回できる秘密鍵は，ブラウザ又は配布アプリへ置かず，漏えいを前提とした失効・ローテーション手順も設ける必要がある。
３ 読取りだけでなく書換えもできた
(1) 書換えの確認
Wizは，最初の修正で機微なテーブルの読取りが遮断された後も，公開テーブルへの書込みは開いたままであったとしている。
Wizは実際に既存の投稿を書き換えることができたと述べ，認証のない者でも，任意の投稿の編集，悪意ある内容の注入，多数のAIエージェントが読む内容の操作ができたと指摘している。
(2) 改ざんが持つ意味
書換えが可能であったことは，情報が外に出るという問題とは別に，記録が正しいという前提（完全性）を失わせる。
露出していた期間の投稿や評価点が改ざんされていないかを，後から確かめる手段が問題になるからである。
個人情報保護法の観点からも，改ざんは「毀損」に当たる（後記第４の２）。
第３ AIで作ったことがなぜ問題になるのか
１ 動く機能と，守る設定は別物である
(1) AIは頼まれた機能を作る
Wizは，この事件から得られる最初の教訓として，AIを使った開発は速度を上げるが，現在のAIツールは開発者に代わってセキュリティの設定やアクセス制御を考えてはくれないと述べている。
画面が表示され，登録や投稿ができるという意味で「動く」ことと，他人のデータに手が届かないように「守られている」ことは，別々に作り込む必要がある。
(2) 設定の既定値に任せない
Wizは，AIでデータベースを備えたアプリを作る支援ツールがRLSを既定で有効にすることや，公開前に露出した認証情報や危険な設定を自動で点検することを提案している。
もっとも，利用者の側から見れば，ツールの既定値がどうなっているかを確かめずに公開すれば，同じ問題が起こり得る。
社内でAIを使ってツールを作る場合も，誰が設定を確認したのかを記録に残しておくことが考えられる。
２ 認証と認可を分けて考える
(1) ログインできることと，他人のデータが見えないことは違う
情報処理推進機構（IPA）の「安全なウェブサイトの作り方」は，非公開の情報を扱うウェブサイトにはパスワード等による認証機能を設けること（11-(i)）に加えて，認証機能に加えて認可制御の処理を実装し，ログイン中の利用者が他人になりすましてアクセスできないようにすること（11-(ii)）を根本的解決として挙げている。
ログインの仕組み（認証）は「誰か」を確かめるだけであり，その人が「どのデータに触れてよいか」（認可）は別に作らなければならない。
(2) データベースの層でも認可を掛ける
IPAの資料は主にウェブアプリケーションの側の認可制御を扱っている。
Moltbookのように，ブラウザから外部のデータベースへ直接つながる構成では，アプリの画面を経由しない要求がそのままデータベースに届く。
本記事では，RLSの未設定を，データベースの層で認可制御が欠落していた状態と整理する。
画面の側で他人のデータを表示しないようにしていても，データベースの側に制御がなければ，画面を通らない要求には効かない。
第４ 個人情報保護法から見た位置付け
１ 安全管理措置（法23条）
(1) 条文とガイドラインの技術的安全管理措置
個人情報保護法23条は，「個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。」と定めている。
個人情報保護委員会のガイドライン（通則編）は，情報システムで個人データを取り扱う場合の技術的安全管理措置として，①アクセス制御，②アクセス者の識別と認証，③外部からの不正アクセス等の防止及び④情報システムの使用に伴う漏えい等の防止を挙げ，これらを講じなければならないとしている（10-6。印刷179頁）。
手法の例示には，情報システムによってアクセスできる個人情報データベース等を限定すること，ログ等の定期的な分析により不正アクセス等を検知すること，情報システムの設計時に安全性を確保し継続的に見直すことが挙げられている（印刷180頁～181頁）。
(2) 行単位の制御の位置付け
ガイドラインは，RLSのような特定の技術を名指ししていない。
もっとも，利用者ごとに見てよい行を限定することは，①のアクセス制御の中身そのものであり，外部から全件に届く状態を放置することは，③及び④の観点からも問題になると考えられる。
ガイドラインの②は，文言上，情報システムを使う従業者の識別と認証を定めたものであるから，外部の利用者向けのサービスの認可設計は，①，③及び④の問題として検討するのが自然である。
２ 設定の不備で公開状態になったことは「漏えい」に当たる
(1) 漏えいと毀損の定義
ガイドラインは，個人データの「漏えい」を「個人データが外部に流出すること」とし，漏えいに当たる事例として「システムの設定ミス等によりインターネット上で個人データの閲覧が可能な状態となっていた場合」を挙げている（3-5-1-2。印刷57頁）。
また，「毀損」を「個人データの内容が意図しない形で変更されることや、内容を保ちつつも利用不能な状態となること」とし，その事例に「個人データの内容が改ざんされた場合」を挙げている（3-5-1-4。印刷58頁）。
Moltbookのように読取りと書込みの両方ができた場合は，漏えいと毀損の両面から検討することになる。
(2) 閲覧されないうちに回収した場合
ガイドラインは，「個人データを第三者に閲覧されないうちに全てを回収した場合は、漏えいに該当しない。」としている（印刷57頁）。
しかし，公開状態の間に誰が閲覧したかは，アクセスの記録がなければ分からない。
記録がなければ，閲覧されていないことを示すことができず，漏えいが発生した「おそれ」として扱わざるを得ない場面が多くなると考えられる。
この意味で，アクセスの記録は，事故を見つけるためだけでなく，事故の範囲を限定するためにも必要になる。
３ 個人情報保護委員会への報告と本人への通知
(1) 報告対象となる事態
法26条1項は，個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定める事態が生じたときに，委員会への報告を義務付けている。
同法施行規則7条は，その事態として，要配慮個人情報の漏えい等（1号），財産的被害が生じるおそれがある漏えい等（2号），不正の目的をもって行われたおそれがある行為による漏えい等（3号）及び本人の数が千人を超える漏えい等（4号）を定めている。
ガイドラインは，4号の事例として「システムの設定ミス等によりインターネット上で個人データの閲覧が可能な状態となり、当該個人データに係る本人の数が1,000人を超える場合」を挙げ，本人の数が確定できないときは，おそれがある本人の数が最大1,000人を超える場合に4号に当たるとしている（3-5-3-1。印刷62頁）。
また，専門家等の第三者から，漏えいのおそれについて一定の根拠に基づく連絡を受けた場合を，「おそれ」に当たり得る事例に挙げている（印刷63頁）。
Moltbookの規模で日本の事業者が同じことを起こせば，外部の研究者から通報を受けた時点で，4号の事態として報告の準備に入ることになる。
(2) 報告の期限と本人への通知
同規則8条は，報告対象の事態を知った後，速やかに，その時点で把握している事項を報告し（1項），知った日から30日以内（3号の事態は60日以内）に所定の事項を報告することを求めている（2項）。
ガイドラインは，1項の報告を「速報」，2項の報告を「確報」と呼び，速報の「速やか」の目安を，事態を知った時点から概ね3～5日以内としている（3-5-3-3。印刷64頁）。
期限の起算点となる「知った」時点は，法人の場合にはいずれかの部署が事態を知った時点であり，確報の期限はその日を1日目として数える（3-5-3-3・3-5-3-4。印刷64頁・66頁）。
法26条2項は，報告対象の事態が生じたときに，本人への通知を求めている。
通知が困難な場合には，本人の権利利益を保護するために必要な代わりの措置をとることで足りる（同項ただし書）。
なお，このただし書は，令和8年法律第56号により令和10年（2028年）7月16日から改められる予定である。
４ 外部のサービスを使う場合と，開発を委託する場合
(1) データベースを外部のサービスに置く場合
個人情報保護委員会のQ&A（Q7-53）は，クラウドサービスの利用が第三者提供又は委託に当たるかどうかは，クラウドサービスを提供する事業者が個人データを取り扱うこととなっているかどうかで判断するとしている。
提供事業者が個人データを取り扱わないこととなっている場合（契約条項で取り扱わない旨が定められ，適切にアクセス制御を行っている場合等）は，委託にも当たらず，法25条に基づく監督義務は生じない。
ただし，その場合も，利用する事業者は，自らの安全管理措置として適切な措置を講じる必要がある（Q7-54）。
漏えい等が生じたときに報告義務を負うのも，利用する事業者であり，提供事業者に報告を代行させることはできるとされている（Q6-22）。
データベースと認証の機能を外部サービスに任せても，RLSの設定を含むアクセス制御の責任は利用する事業者に残るということである。
(2) 開発や運用を外部に委託する場合
これに対し，ツールの開発や運用を外部の事業者に任せ，その事業者が個人データを取り扱う場合は，個人データの取扱いの委託に当たり，法25条により委託先の監督が必要になる。
ガイドラインは，委託先の選定に当たり，委託先の安全管理措置が法23条及びガイドラインで委託元に求められるものと同等であることを「あらかじめ確認しなければならない」とし，委託契約への取扱状況の把握の盛込み及び定期的な監査等による把握は「望ましい」としている（3-4-4。印刷54頁～55頁）。
必要な安全管理措置の内容を委託先に指示しなかった結果，委託先が個人データを漏えいした場合は，監督が適切でない事例として挙げられている（印刷55頁）。
また，報告対象の事態に当たる場合には，原則として委託元と委託先の双方が報告義務を負うとされている（3-5-3-2。印刷63頁）。
もっとも，委託先は，報告すべき事項を委託元に通知すれば，委員会への報告義務を免れる（法26条1項ただし書）。
この通知も事態を知った後速やかに行わなければならず（同法施行規則9条），ガイドラインはその目安も概ね3～5日以内としている（3-5-3-5。印刷67頁）。
通知を受けた委託元は，遅くともその時点で事態を知ったことになるとされているから，委託先から通知が来た時点で報告の期限が進み始めることを前提に準備する必要がある。
第５ 開発を外部に委託するときの契約
１ セキュリティ仕様を開発の前に決める
(1) モデル契約書の条項
IPAと経済産業省が公表する「情報システム・モデル取引・契約書」第二版（受託開発・保守運用）は，セキュリティについて，セキュリティ仕様の策定手順が確立していない場合（A案）と確立している場合（B案）の2案の条項を用意している（50条）。
A案は，セキュリティ対策の具体的な機能，遵守方法，管理体制及び費用負担等を協議の上，ソフトウェア開発業務を開始する前までにセキュリティ仕様を確定させ，書面により定めるとし，ユーザは仕様の確定に必要な稼働環境等の情報を提供しなければならないとしている。
確定したセキュリティ仕様はシステム仕様書の一部となり，変更は変更管理の手続によるとされている。
(2) 仕様に入れた事項だけが約束になる
同条のA案6項は，ベンダは仕様に従って対策を講じる義務を負うにとどまり，セキュリティインシデントが生じないことを保証するものではないとしている。
モデル契約書の解説は，セキュリティ要件を仕様に入れていれば，その不一致は契約不適合の問題になると説明している。
裏を返せば，「利用者ごとに見られるデータを限定する」「データベースの全テーブルで行単位の制御を有効にする」「秘密鍵をブラウザ側に置かない」といった認可の要件を仕様に書いていなければ，後から責任を問うことは難しくなる。
AIを使って開発する事業者に委託する場合も同じであり，開発の手段がAIであることは，仕様を省く理由にならない。
(3) 当時の技術水準に沿った対策は黙示の合意とされることがある
もっとも，仕様に明記していない事項でも，契約当時の技術水準に沿った基本的なセキュリティ対策は，黙示の合意の内容とされることがある。
東京地方裁判所平成２６年１月２３日判決（平成23年（ワ）第32060号，判例時報2221号71頁，裁判所HP未掲載）は，ウェブサイトの受注システムの設計，製作及び保守を受託した業者が作ったアプリケーションにSQLインジェクションの脆弱性があり，顧客のクレジットカード情報が流出した事案である。
同判決は，契約当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示的に合意されていたとした。
その上で，経済産業省とIPAが契約の前からSQLインジェクション対策の必要性を示していたことを挙げ，受託業者はバインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていたとして，債務不履行を認めた。
同判決は，損害賠償額を個別契約の代金の範囲内に制限する条項について，受託業者に故意又は重過失がある場合には適用されないとし，本件では重過失を認めて適用を否定した。
他方で，委託者の担当者が，クレジットカード情報を保持しない方がよいと認識し，受託業者から改修の提案を受けながら放置していたとして，3割の過失相殺をした。
どの対策が「当時の技術水準」に当たるかは争いになりやすいから，認可の要件は仕様に書いておくのが確実である。
２ 個人情報の取扱いを定める条項
モデル契約書は，ユーザから取扱いを委託された個人データを第三者に漏えいしてはならないこと，ベンダが個人情報の管理に必要な措置を講ずること及び目的外使用の禁止等を定める条項（42条）を置いている。
解説は，委託者が法25条に基づき委託先の監督の責任を負うことから，ソフトウェア開発委託契約においても委託先の監督について取り決めておく必要があると述べている。
前記第４の４(2)のガイドラインの内容と合わせて，取扱状況の報告，監査及び漏えい等の際の通知の方法を契約に書いておくことが考えられる。
第６ 公開前と公開後に確かめること
１ 公開前の点検
(1) 利用者を2人作って確かめる
実務上は，テスト用の利用者を2人作り，一方でログインした状態で，もう一方のデータを指すURLを直接開いたり，同じ要求を送ったりして，見えないことを確かめることが考えられる。
画面の操作だけでなく，ブラウザの開発者ツールで，画面を経由しない要求にもデータベースが応じないかを確かめる。
(2) 設定と鍵の置き場所を確かめる
外部のデータベースサービスを使う場合は，公式文書の指示に従い，APIで到達できる全てのテーブルでRLSが有効になっているか，ポリシーが利用者ごとの行に限定しているかを確かめる。
RLSだけでなく，GRANT，ビュー，関数，GraphQLその他のAPI経路を棚卸しし，「利用者の役割×読取り・追加・更新・削除」の認可表を作った上で，別テナントのデータには届かないことを否定テストで確認する。
あわせて，RLSを迂回する秘密鍵がブラウザ側のコードや配布するアプリに含まれていないかを，ソースコードと公開後のファイルの両方で確かめる。
独立した担当者によるレビュー又は外部の脆弱性診断も見落としを減らす方法となるが，試験は承諾を得た対象，試験環境，疑似データ，許容手法及び停止条件の範囲で実施する必要がある。
AIによる点検結果だけで安全性が証明されたとは扱わない。
２ 公開後の点検
(1) 記録を残して定期的に見る
ガイドラインの手法の例示どおり，アクセスの記録を残し，定期的に分析して不正なアクセスを検知できるようにしておく。
前記第４の２(2)で述べたとおり，記録は，事故が起きたときに誰が閲覧したかを限定する材料にもなる。
ただし，ログ自体へパスワード，アクセストークン又は不要な個人データを残さず，アクセス権限，保存期間及び改ざん防止措置を定める必要がある。
(2) 通報を受けたときの手順を決めておく
Moltbookの問題は，外部の研究者の通報によって見つかった。
社内ツールでは外部から通報が来るとは限らないが，通報を受けた場合には，それが報告対象の事態の「おそれ」に当たり得ることを前提に，封じ込め，証拠保全，影響範囲の調査及び報告の要否の判断を並行して進められるよう，担当者と手順を決めておくことが考えられる。
露出した鍵は失効又はローテーションし，設定とログの写しを保存した上で修正する。
Moltbookでは修正のたびに新しい露出が見つかったから，1回の修正で終わったと判断せず，関連するテーブル，API及び権限経路を含む全体を再試験する手順も含めておく。
第７ 関連記事
①個人情報保護法の安全管理措置は機密性に偏っているか――情報セキュリティ３要素のバランスと報告義務の構造
②外部委託先で個人情報が漏えいした場合の委託元の対応―報告，本人通知及び委託先監督
③シャドーAIの問題点――営業秘密，個人情報保護法及び懲戒処分をめぐる法的枠組み
④総務省「AIのセキュリティ確保のための技術的対策に係るガイドライン」（令和８年３月公表）――対象・脅威・対策と実務上の限界
⑤学習オフの生成AIに秘密情報を入力することは第三者開示に当たるか
⑥訴訟記録の誤提出と個人情報漏えい―弁護士の守秘義務と委員会報告の要否
⑦AIシステムの脆弱性診断・レッドチーミングを外部委託する契約
第８ 出典
１ 法令
①個人情報の保護に関する法律（平成15年法律第57号）23条・25条・26条（e-Gov法令検索。令和8年9月13日確認）
②個人情報の保護に関する法律施行規則（平成28年個人情報保護委員会規則第3号）7条～10条（同上）
２ 所管行政機関の指針・Q&A
①個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（令和8年6月一部改正）3-4-4（印刷54頁～56頁），3-5-1-2・3-5-1-4（印刷57頁～58頁），3-5-3-1～3-5-3-5（印刷59頁～67頁），10-6（印刷179頁～181頁）
②個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関するQ&A」Q6-22，Q7-53，Q7-54（令和8年9月13日確認）
３ 公的機関の技術資料・契約モデル
①情報処理推進機構「安全なウェブサイトの作り方 1.11 アクセス制御や認可制御の欠落」（改訂第7版）
②情報処理推進機構・経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）＜第二版＞」（2025年4月8日更新）42条・50条及び解説
４ 事件の調査報告・技術文書
①Wiz「Hacking Moltbook: The AI Social Network Any Human Can Control」（2026年2月2日公表。令和8年9月13日確認）
②Supabase「Row Level Security」「API keys」（令和8年9月13日確認）
５ 裁判例
①東京地方裁判所平成２６年１月２３日判決（平成23年（ワ）第32060号，判例時報2221号71頁，裁判所HP未掲載，LLI/DB判例秘書で判決全文を確認）