AI時代のエンタープライズ・セキュリティ ── Leading.AI、日本の漏えい公表文300通と世界の提言211件を一次資料で検証し、経営者が平時に定めるべき3つの方針を提言

保有するデータの範囲、ログの保持期間、本人への初報の範囲 ── 経営者が平時に定めるべき3つの方針を、Leading.AI名義で漏えい台帳と提言書の2冊のオープンソース書籍で公開し、更新し続けます

合同会社Leading.AI

2026年11月4日 10時00分

■ 概要

Leading.AI LLC（本社：神奈川県横浜市、Founder/CEO・AIストラテジスト：山内怜史）は、2026年秋に日本で相次いだ個人情報漏えいを前に、セキュリティを情報システム部門に任せる技術の問題ではなく、経営者が自ら判断すべき経営課題として扱うために、2冊のオープンソース書籍をGitHub上で公開しました。

漏えい台帳『The Japan Breach Registry 2026』（2026年11月3日更新）と、提言書『パッチの向こう側 ── AI時代のエンタープライズ・セキュリティを、世界の提言から読む』（2026年10月30日公開）です。いずれも日英併記で、CC BY 4.0のもと誰でも引用・転載できます。

この2冊は、AI時代の変化の速さに合わせ、エンタープライズ・セキュリティの羅針盤であり続けるために、GitHub上で最新の情報に更新し続けます。

■ 背景 ── なぜ、今か

2026年10月7日、東京商工リサーチは、上場企業とその子会社が公表した1,000万件以上の個人情報漏えいが「2025年までの14年間で3回」だったのに対し、2026年は10月5日までに1,000万人分以上の漏えいが3回起きたと報告しました。同社は10月23日の集計で、上場企業とその子会社について「2026年は10月23日までに1,000万件以上の情報漏えい事故が佐川急便を含め、すでに8件（速報値）確認される異常事態となっている」と書きました。

10月15日、JPCERT/CC（一般社団法人JPCERTコーディネーションセンター）は、連続不正アクセス事案の攻撃手法に関する調査で「攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました」と書きました。JPCERT/CCが攻撃者のAI利用を一次資料で「確認」と書いたのは、台帳が集めた範囲で最初の例です。

同じ10月には、ソースネクスト（10月15日、22,519,960件）、カプコン（10月22日、11,774,247件）、良品計画（10月30日、「最大約2,726万件」、「外部に流出した可能性があることを確認しました」）と、1,000万件を超える事案の公表が続きました。

一方、世界の提言も出そろいました。
各国の政府・公的機関、標準団体、AI企業、セキュリティ企業、保険会社、学術、個人の有識者、規制当局が、2025年から2026年にかけて提言を書き、日本では金融庁と日本銀行が5月22日、金融機関等に、優先的に対応すべきサービス／ITシステムを「能動的に停止させざるを得ない場合についても、経営トップはあらかじめ選択肢として検討しておくべきである」とまで求めました。

事故と世界の提言が同じ秋に重なりました。

漏えい台帳は事故の公表文を、提言書は世界の提言を、それぞれ一次資料に基づき執筆したものです。

■ 1冊目：漏えい台帳『The Japan Breach Registry 2026』

公開先（2026年11月3日更新）：

https://github.com/Leading-AI-IO/the-japan-breach-registry-2026

誰に向けて：

日本企業の経営者と取締役会、および報道や推測ではなく一次資料で事実を確かめたい読者。

何のために：

2026年9月1日以降に日本の企業・組織が公表した個人情報漏えいを、当事組織の一次公表文に基づき、公表文の単位と表現のまま並べるために。件数を人数に換算せず、「可能性」を「確認」に書き換えず、経路が書かれていなければ「未公表」と書きます。

目指すこと：

「AIの悪用が原因」といった検証されていない言葉が広まる中で、一次資料に書かれたことと書かれなかったことを分けて記録し、ファクトベースで起きたことを理解するための台帳を更新し続けること。

漏えい台帳300行から見えたこと

300行。公表文の単位で100万件を超える行は38行、1,000万件を超える行は6行
侵入経路を書いた公表文は226通、書いていない公表文は74通。
ただし226通のうち179通の経路は「委託先」で、委託先がどう侵入されたかは、多くの公表文が書いていません。同じ委託先から複数の組織に広がった事案を1件にまとめると、300行は約144件の独立した侵入になり、侵入の経路が分かるのは、そのうち47件前後、約3分の1です。
攻撃者のAI利用に言及した公表文は、300通のうち1通。
ちとせグループが「AI等を用いて自動化された攻撃であったと推定されます」と書き、根拠として攻撃が「複数のIPアドレスから短時間に大量の操作を同時に行うもの」だったことを挙げていますが、推定の主体は書いていません。
JPCERT/CCは攻撃元のサーバーの調査で攻撃者のAI利用を確認しましたが、被害を受けた側の公表文で攻撃者のAIに触れたのは、この1通だけです。
同じ委託先から複数の組織に広がった漏えいは20系統超。
メール配信のブラストメール、Web構築のStudio、コミュニティのコミューン、メール配信のユミルリンク、航空の旅客サービスシステムのAmadeusなどです。

■ 2冊目：経営向け提言書『パッチの向こう側 ── AI時代のエンタープライズ・セキュリティを、世界の提言から読む』

公開先（2026年10月30日公開）：
https://github.com/Leading-AI-IO/enterprise-security-in-the-ai-era

誰に向けて：

日本企業の経営者と取締役会に。データの保有、ログの保持、事故時の公表について、方針を定める権限と責任を持つ立場の方々に向けて書いています。

何のために：

世界の提言の多くは侵入を防ぐ対策を求めていますが、会社が平時に自ら定めておくべき方針については、ほとんど書いていません。その方針を示すために。世界の提言211件を一次資料で確かめ、どこで一致し、どこで食い違い、どこが空白かを数えました。

目指すこと：

企業が他者の協力なしに自ら定められる3つの方針 ── 保有するデータの範囲、ログの保持期間、本人への初報の範囲 ── を、各社の経営者が平時のうちに自社の方針として定めること。

世界の提言211件の分析で見えた、3つの空白

どの対策が侵入を防ぐかを、実際の企業で測った提言は0件。
211件のうち14件は効果の測定に触れていますが、企業の実環境で、対策をした場合としなかった場合の被害を比べた測定は1件もありません。対策の効果を根拠にした投資判断の材料は、世界の提言の中にまだありません。
保有するデータを減らすよう求めた提言は、211件のうち13件。
提言を内容で9つの領域（脆弱性の発見と修正、検知、委託先、データの最小化、インシデント対応など）に分けたうち、最も少ない領域です。
13件のうち12件は政府・公的機関で、AI企業、セキュリティ企業、標準団体、学術の提言には1件もありません。保有するデータの量は会社が自ら決められるにもかかわらず、世界の提言の中で最も手薄です。
ログを何日残すかを日数で定めた提言は、211件のうち1件。
インドのCERT-In（2022年、180日）だけです。日本の公的機関の提言は「一定の期間」と書き、日数を示していません。ログが残っていなければ侵入経路は特定できませんが、何日残すかは各社の判断に委ねられています。

世界の提言が厚いのは、攻撃を防ぐ対策（脆弱性の修正、多要素認証、検知の製品）です。手薄なのは、攻撃が成功したあとに効いてくる備え（保有するデータの範囲、ログの保持期間、本人への初報の範囲）です。
Leading.AIの提言書は、この手薄な3つを、経営者が平時に定めるべき方針として示します。

方針1　持たない ── 保有するデータを減らす。

保有するデータの量が、万一の流出時に影響を受けうる件数の上限を決めます。

台帳のHelpfeel（Gyazo）の事案では、流出した約2,362万件のうち約76%が、メールアドレスの登録がない匿名ユーザーのものでした。これとは別に、第二報では「ユーザーが過去に削除した画像に関するメタデータ約1.74億件」の流出も確認されました。

方針2　気づく ── ログの保持期間を経営者が決める。

ログの保持期間と点検周期を、情報システム部門ではなく経営者が日数で決めます。

記録がなければ、侵入経路は「調査中」のままになり、漏えいの範囲は「おそれ」のまま最大値にとどまります。Mandiant（Google Cloud）は年次報告書「M-Trends 2026」で、侵入から発覚までの滞在期間が約400日に及ぶ攻撃（BRICKSTORM）を挙げ、「標準的な90日のログ保持では、最初の侵入経路を完全に見失う（筆者訳）」と書きました。

方針3　伝える ── 初報で誰に何件知らせるかを事前に決める。

初報で何件の本人に知らせるかは、法律ではなく会社が決めています。

記録があれば、速さと引き換えに範囲を絞れます。

漏えい台帳に並べた公表文300通を、初報で知らせた本人の範囲で分けると、保有する全件を上限として知らせたものが50通、記録で対象を絞って知らせたものが72通、件数を書けなかったものが94通、どちらとも読めないものが84通でした。
上限で知らせるか、絞って知らせるかを、事故の前に決めておくことが重要です。

３つの方針はいずれも、新たな製品やサービスの導入を求めるものではありません。

経営者が自社の方針として定めることで実行できます。

■経営者と取締役会へ

Leading.AIの提言書は、情報システム部門ではなく、経営者と取締役会に向けて書きました。

3つの方針は技術投資ではなく経営判断の領域にあり、「効果を示せ」という稟議の問いに答えられる資料が、世界の提言の中にないためです。代わりに提言書は、取締役会で問う7つの質問を置きました。答えはすべて、数字か、文書があるかないかで返せます。そのうち3つを示します。

当社は、個人のデータを何件持っているか？そのうち、法定保存期間を過ぎたものは何件か？
最終利用から1年以上たったものは何件か？
認証・アクセス・操作・通信の各ログは、現在何日残っているか？その日数は、誰が決めたか？
今日事故が起きたら、初報は上限で出すのか、絞ってから出すのか？それは誰が決めたか？

取締役会でこれらの質問に答えられない項目があれば、それが自社でまだ方針を定めていない領域です。

■ 羅針盤であり続けるために ── 更新し続けるオープンソース書籍として

攻撃側の最速は秒と分の単位で動き、公表文は毎週増えます。漏えい台帳は、10月10日の第1版（31行）から、10月16日の第2版（36行）、10月26日の第3版（71行）、11月3日の第4版（300行）へと、24日間で3回版を上げました。数字が動く速さに、書籍の側が合わせる必要があります。

そこで漏えい台帳と提言書は、書き終えて固める本ではなく、数字と台帳を更新し続ける書籍として設計しました。

台帳はデータとして公開します。
漏えい台帳は registry.csv / registry.json、世界の提言211件の台帳は proposals.csv。読者は本文を読まずに台帳だけを開くこともできます。提言書には、本文の件数を自分で数え直すスクリプトも同梱しています。
追記専用です。
行は消さず、訂正は訂正と日付を明記して追記します。本文を変えるときは、変更箇所の直前に「（YYYY年M月D日追記／訂正）」を置き、何がいつ変わったかを誰でも追えるようにします。
予測はしません。
提言書の終章には、次の版で数え直す16の指標を置きました。版が変わったとき、読者は主張が強まったか弱まったかを、その指標で確かめられます。
更新の手順書も公開しています。
台帳に書くのは著者一人で、その一人がどの手順で追記・訂正するかを、読者が検証できる状態に置いています。

AI時代の速度に追随する形で、必要に応じて、今後も更新を続けます。

■ 漏えい台帳と提言書が書かないこと

漏えい台帳と提言書は、どの対策が攻撃を防ぐかを書きません。測った資料がないからです。

現段階では、AIが漏えいの原因だとも書きません。日本が世界より遅れているとも書きません。

公表文を書いた組織を評価しません。

一次資料に書かれたことと、書かれなかったことを、分けて記録します。

■ 著者について

山内怜史　Leading.AI LLC Founder/CEO。AIストラテジスト / ビジネスデザイナー。

Future Architectにて大規模IT戦略コンサルティングに従事。Recruitにて新規事業開発・戦略企画および事業責任者を担当。Aireene Universityにてイノベーションマネジメントとデザインシンキングを学び、Leading.AIのビジネスデザイナー兼AIストラテジストとして活動。
ビジネス×テクノロジー×クリエイティブの3領域を越境するBTC人材として活動している。

Leading.AIでは、人とAIの共創黄金比「10：80：10の法則」や、生成AI時代の新規事業開発方法論「Depth & Velocity」を体系化し、2026年2月から、AI戦略に関するオープンソース書籍をGitHubで公開し続けている。

セキュリティの専門家ではなく、AIが事業と組織をどう変えるかを書いてきたAIストラテジストである。特定のセキュリティ製品・サービスの提供者と利害関係を持たない立場から、世界の提言211件を一次資料で数えたうえで、漏えい台帳と提言書を執筆した。

■ 会社概要

会社名	Leading.AI LLC
代表者	山内怜史（Founder/CEO）
所在地	神奈川県横浜市
設立	2026年2月
事業内容	AI戦略コンサルティング、企業変革アドバイザリー、講演・ワークショップ開催、執筆活動
公式HP	https://www.leading-ai.io/
GitHub書籍一覧	https://github.com/Leading-AI-IO
note（代表）	https://note.com/satoshi_yamauchi
NewsPicks（代表）	https://newspicks.com/user/1950744/
LinkedIn（代表）	https://www.linkedin.com/in/satoshi-yamauchi/
X（代表）	https://x.com/s3atoshi