最近のセキュリティ侵害がどのように行われているのかを、時系列とあわせて説明している資料はないか。読者からそう尋ねられました。見つかったのは意見ばかりで、詳細も、根拠のある仮説もなかったそうです。目的は、金融機関の定量的リスク管理と、サプライチェーンのリスクを組み合わせることです。 これを1本でまかなう資料はありません。答えは方法にあります。一次資料から始め、それぞれの主張を「誰が、どの証拠で言ったか」で分け、すべてに日付を付け、それからモデルを当てはめることです。本記事は、8月から全件を追ってきた国内の侵害通知でそれを行い、数字を確かめられるようにデータとコードを公開します。
以下の4点が全体を支えています。
- 多くの通知は、侵入経路を書いていません。 2026年8月10日〜10月25日に組織自身のシステムについて出た攻撃の通知119件のうち、63件は経路の記載がありません。手口についての知見は、被害組織よりも主に対応機関から来ています。
- 攻撃の通知の4割は、委託先の侵害を顧客が公表したものです。 198件中79件が、19の委託先の顧客からの通知でした。4つのプラットフォームがその77%を占め、顧客の通知は同じ日にまとまって出ます。
- 侵害の規模には、意味のある平均がありません。 10万件を超える部分では、公表件数がべき分布に従い、裾の指数は約0.38です。曲がるのは最上位の通知だけです。1未満では、平均はデータではなく、許容する最大の事象で決まります。
- 委託先への集中は、平均を変えずに裾を変えます。 期待される事案数が同じ1,000社のポートフォリオで、全社が同じ1社に依存すると、99.9%点は企業ごとの事案影響61件から558件に増えます。
更新(2026年10月25日 16:15)。 データセットを8月10日〜10月25日の264件に広げ、ひとまとまりのデータとして分析し直しました。以下の図と表はすべて再計算したものです。変更点は末尾の更新履歴にまとめています。
どこを見るか、それぞれの資料から何が分かるか
報道は資料を探すために使い、出典にはしないでください。一次資料の種類ごとに答えられる範囲があり、それぞれに死角があります。
| 資料 | 分かること | 分からないこと | この秋の例 |
|---|---|---|---|
| 組織自身の通知と続報 | 経路(書かれていれば)、アクセスと発見の日付、データの種類、件数 | 会社が書かなかったこと。最初の件数は見込み | 11週間で264件。当サイトのCSV。その多くは侵害レビューに表で掲載 |
| 取引所での開示 | 上場企業への重要な影響を、期限付きで | 手口。小規模・非上場の企業 | 大和証券のTDnetでの開示。米国ではForm 8-KのItem 1.05で、重要と判断してから4営業日以内 |
| CERTの注意喚起 | 複数の事案に共通する手口、指標、観測期間 | 被害組織名。その手口がどの侵害の原因だったか | JPCERT/CC AT-2026-0030のケースA〜E |
| インシデント対応企業 | 調査の中で見えた挙動、時に攻撃基盤 | 自社の顧客以外の全体像 | マクニカ、CrowdStrike |
| 政府・規制当局 | 規模、政策、何をいつまでに報告するか | 手口の詳細 | NICT、国家サイバー統括室、個人情報保護委員会 |
| 侵害データセット | 多数の事案にわたる発生率とパターン | 中立な分類(分類は誰かが決めたもの) | VerizonのDBIRと公開データのVERIS Community Database。本記事のCSV |
日本の外でも構図は同じです。Verizonの2026年版DBIRは、Help Net Securityの要約によれば、初期侵入の31%を脆弱性の悪用とし、初めて認証情報の窃取を上回りました。報告書そのものは開けなかったため、この数字は報道ベースとして扱ってください。
時系列:2026年7月〜10月25日

図1:いつ何が起きたか(各組織の公表による)。同じ時期に並べたもので、ツールと被害組織を結び付けるものではありません。本記事のために作成した図です。
| 日付(2026年) | 出来事 | 証拠の種類 | 出典 |
|---|---|---|---|
| 7月 | マクニカの集計でWebシステムの侵害が急増に転じる。年間119件のうち81件が7月以降 | 対応企業の集計 | マクニカ |
| 7月26日 | オープンソースのAIペネトレーションテスト・エージェントARTEXがv0.1.0を公開 | ツールの経緯 | piyolog |
| 7月31日 | EPARKリラク&エステ:サロン向け予約基盤で約3,300万レコード | 被害組織の通知 | EPARKリラク&エステ |
| 8月14日 | JPCERT/CCがMetabaseのSQLインジェクション(CVE-2026-72898)で注意喚起 | CERTの注意喚起 | JPCERT/CC |
| 9月15日 | LEAN BODYが経路としてMetabaseを明記。アクセスは8月11日から | 被害組織の通知 | LEAN BODY |
| 9月16日 | Gyazo:画像アップロードサーバの脆弱性でコマンドを実行され、ユーザー情報約2,362万件 | 被害組織の通知 | Helpfeel |
| 9月18〜19日 | ARTEXがライセンスを改定。v0.3.13で政府・教育機関のドメインを既定で除外 | ツールの経緯 | piyolog |
| 9月下旬〜10月上旬 | 正体不明の攻撃者が言語モデルとARTEXで韓国の金融機関を攻撃 | 対応企業の報告(10月7日) | CrowdStrike |
| 10月1日 | 能動的サイバー防御の法律が施行 | 政府 | 国家サイバー統括室(PDF) |
| 10月5〜6日 | 大和証券とシチズン時計が、同じ問い合わせ業務の委託先にあったデータについて公表 | 被害組織の通知 | 大和証券(TDnet)・シチズン時計 |
| 10月7日 | IDCフロンティア:ランサムウェアで3時40分からIDCFクラウドが停止、顧客495社に影響 | 被害組織の通知 | IDCフロンティア・当サイトの分析 |
| 10月7日 | 個人情報保護委員会が、大量の個人データを持つ事業者に注意喚起。フィッシング耐性のある多要素認証、ログ分析、EDRなど技術的安全管理措置の見直し内容を先行して示し、典型的な漏えい事例にAPIの悪用を加えた | 規制当局 | 個人情報保護委員会・ScanNetSecurity |
| 10月8日 | JPCERT/CCが注意喚起AT-2026-0030(ケースA〜C)。サイバー安全保障担当大臣が「大変危急の状況」 | CERTの注意喚起、政府 | JPCERT/CC・Impress Watch |
| 10月9日 | ケースDを追加。国家サイバー統括室がWebシステム・サプライチェーン・データ管理について注意喚起。自民党のサイバー本部長「サイバー空間の有事」 | CERTの注意喚起、政府、政党 | INTERNET Watch・読売新聞(Yahoo!ニュース) |
| 10月9日 | 金融庁が金融機関に、サードパーティリスク管理とインシデント対応態勢の点検、非対面の本人確認での本人確認書類画像の確認徹底を要請 | 規制当局 | 金融庁 |
| 10月9〜14日 | コミューン:コミュニティの招待リンクが漏れる欠陥を突かれ、攻撃者が管理者になりすました。顧客23組織がそれぞれ通知を公表 | 被害組織の通知 | コミューン・朝日新聞 |
| 10月13日 | NICTが、アプリを解析してサーバに至る「A2B」攻撃を注意喚起 | 政府系研究機関 | NICT |
| 10月15日 | ソースネクスト:10月9〜13日に会員情報のAPIが悪用され、最大22,519,960件 | 被害組織の通知 | ソースネクスト |
| 10月16〜22日 | Studio:9月30日と10月1日に顧客のフォームデータに外部から到達できる状態。デジタル庁(フォーム入力13,323件)を含む顧客20組織が通知を公表 | 被害組織の通知 | Studio・デジタル庁・ITmedia NEWS |
| 10月21日 | PHP2Shell:首相がサイト運営者にその夜のうちのPHP修正を要請 | 政府 | 高市首相のX投稿・当サイトの分析 |
| 10月22日 | カプコン:CAPCOM IDの11,774,247アカウント | 被害組織の通知 | カプコン・INTERNET Watch |
| 10月23日 | 佐川急便の第5報:重複を含め最大約5,323万件。6月21日〜9月30日の送り状データ、顧客リスト、会員情報で、カード情報とパスワードは含まれない | 被害組織の通知(報道経由) | INTERNET Watch・Impress Watch |
| 10月23日 | フューチャーショップ:EC基盤の脆弱性を突かれ、1店舗(リンツ&シュプルングリー ジャパン)の会員3,147,469件 | 被害組織の通知 | フューチャーショップ・リンツ&シュプルングリー ジャパン |
| 10月23日 | JPCERT/CCがケースEを追加し、Cairn、CyberStrikeAI、ARTEXを攻撃の試行に名指し | CERTの注意喚起 | JPCERT/CC・当サイトのARTEX分析 |
公表日は攻撃日ではありません。 LEAN BODYのアクセスは8月11日に始まり、公表は9月15日でした。Eストアーへの侵入は5月21日から8月1日まで続いていました。発生頻度のモデルを作るときは、攻撃の日、発見の日、公表の日のどれを数えるかを決めてください。公開データから得られるのは、ほとんどが最後の1つです。それぞれの間の遅れは、下のモデルの節で測っています。
侵害はどう行われているか:証拠の強さで分ける
3つの段階を混ぜないことが要点です。
- 被害組織が書いたこと。 通知が経路を明記しているもの。その事案については直接の証拠ですが、組織自身のシステムについての通知119件のうち経路があるのは56件だけです。
- 対応機関が複数の事案にわたって述べたこと。 JPCERT/CC、マクニカ、NICTは、被害組織名を挙げずに複数の事案で見えた手口を説明しています。何が起きているかは分かりますが、どの事案の説明かは分かりません。
- 仮説。 当てはまるものの確認されていない見方です。たとえば、サイトごとの探索の一部にAIペネトレーションテスト・エージェントが使われているという見方。JPCERT/CCは攻撃の試行にそうしたツールを名指ししましたが、名前の分かる被害組織とは結び付いていません。
| 経路 | 経路を明記した自社システムの通知(119件中) | 委託先の事案(19件中) | 対応機関の説明 | ATT&CK |
|---|---|---|---|---|
| インターネットに公開されたシステムの脆弱性・設定不備 | 20 | 7 | ケースA:各標的で多数の既知の脆弱性と設定・バックアップファイルを探索。ケースC:MetabaseのSQLインジェクション。ケースD:公開Webサーバから到達できるアプリケーションサーバにWebシェルを設置 | T1595.002、T1190、T1505.003 |
| アカウントの悪用・フィッシング | 12 | 1 | 通知から:フィッシングで奪われたメールやMicrosoft 365のアカウント、漏れたトークン、リスト型攻撃(ファンくる:5日間で5,060,270回のログイン試行)、盗まれた管理者パスワード(楽天ドライブ) | T1078、T1566、T1110.004 |
| ランサムウェア・マルウェア | 10 | 4 | JPCERT/CCは別個の継続的な脅威として扱う。IDCフロンティアは事業者で起きた例 | T1486 |
| アプリ・API・Web機能の悪用 | 13 | 1 | ケースB:公開アプリを解析してAPIのエンドポイントとキーを探し、アプリが使わない内部APIを呼び出す。ブラインドNoSQLインジェクション。Torとレジデンシャルプロキシ。正規アプリと同じUser-Agent。マクニカのサイトごとの試行錯誤、NICTのA2B | T1190、T1090.003 |
| サポート詐欺 | 1 | 0 | 通知から:画面の偽の警告を信じた職員 | — |
| 記載なし | 63 | 6 | — | — |
| 委託先・プラットフォーム(上の経路と重なる) | — | 19件。顧客の通知79件の元 | 国家サイバー統括室の10月9日の注意喚起は、3つの領域の1つにサプライチェーンを挙げる | T1199 |
| AIペネトレーションテスト基盤 | 被害組織の通知での言及なし | — | ケースE:Cairn、CyberStrikeAI、ARTEXによる攻撃の試行。WSUSサーバや設定ファイルも対象 | T1588.002 |
プラットフォーム自身の通知は自社システムとして数え、その顧客の通知は、記載された委託先の事案ごとに1回数えています。
ケースDの内容は、10月9日の更新を要約した二次情報(issoh)によります。10月25日、当方の環境からJPCERT/CCのページを開けませんでした。ケースBとEは、公開された指標とあわせてARTEXの分析で詳しく扱っています。
何が取られたか、当局はどう応じたか
危険にさらされたデータの項目を書いた通知は119件です。
- 本人確認に使われる組み合わせ: 18件が、生年月日と実名に、電話番号かメールアドレスを含んでいます。
- パスワード: パスワードの扱いを書いた通知は38件です。14件が対象に含まれると書き(ハッシュ化12件、保存形式の記載なし2件)、10件は確認中、14件は含まれないとしています。
氏名、生年月日、住所、電話番号が漏えいリストに並べば、それらはもう本人確認の決め手になりません。金融庁は10月9日、金融機関に対し、非対面の本人確認で本人確認書類の画像に不自然な点がないかの確認を徹底し、サードパーティリスク管理とインシデント対応態勢を点検するよう求めました。個人情報保護委員会の10月7日の注意喚起は、フィッシング耐性のある多要素認証、ログ分析、EDRを、求められる安全管理措置として先行して示しています。
ransomware.liveによれば、データセット内の3組織がランサムウェアのリークサイトにも掲載されています。
- everest:キッセイ商事とユニリタ
- Black X:enTouch(東邦ホールディングス子会社)
掲載は犯罪グループの主張であって確認ではなく、通知とは別の事案についてのものである可能性もあります。
攻撃者のプレイブック:なぜこれらの経路が割に合うのか
上の経路は偶然ではありません。どれも、被害組織1件あたりの攻撃者のコストを下げます。
- 広く探し、既知の穴を突く。 各標的で多数の既知の脆弱性と、残された設定・バックアップファイルを調べます(ケースA、T1595.002、T1190)。Metabaseのような分析ツールがインターネットに公開されたまま、修正も遅れていました(ケースC)。
- 1つのサイトを調べ、そのサイト自身の機能でデータを取る。 公開アプリを読み、API呼び出しを一覧にし、アプリが使わないものを、偽のヘッダーや壊れたトークンを付けて呼び出します(ケースB、T1190)。要求をTorとレジデンシャルプロキシに分散させ、アプリのUser-Agentをまねて、アドレス単位の遮断や単純なフィルタに見えないようにします(T1090.003)。このサイトごとの作業には、以前は熟練者の数日が必要でした。計画を立て、ツールを呼び、遮断されても続けるエージェントはそのコストを下げます。マクニカとNICTが警告しているのはこの点です。
- プラットフォームを狙い、多くの被害組織を得る。 コミュニティサービス、サイト作成ツール、予約システム、問い合わせ窓口、クラウド事業者は、多数の組織のデータを一度に持っています(T1199)。1回の侵入が、そのシステムを運用していない会社からの何十件もの通知になります。攻撃者から見ればてこの原理、リスク管理者から見れば相関です。
- 到達できるサーバに居座る。 アプリケーションサーバ上のWebシェルは、最初の経路が塞がれた後もアクセスを保ちます(ケースD、T1505.003)。
- 収益化する。 データを売るか恐喝に使うか、基盤を暗号化します(T1486)。事業者で暗号化が起きれば、それだけで数百の顧客が止まることをIDCフロンティアが示しました。
リスクモデル
銀行のオペレーショナルリスク部門なら、この構造に見覚えがあるはずです。損失分布手法(LDA)は、損失がどれくらいの頻度で起き(頻度)、1件がどれくらいの大きさか(規模)を別々にモデル化し、シミュレーションで合成します。サプライチェーンのリスクは、標準的なLDAが扱わないものを加えます。依存関係、つまり委託先での1つの事象が多数の企業に同時に損失を生むことです。以下では、それぞれの部分を国内の通知に当てはめ、依存関係が何をもたらすかを示します。
以下はすべて、2つのCSVから1本のPythonスクリプト(標準ライブラリのみ、乱数シード固定)で計算しています。本記事の数字は、その出力ファイルから写したものです。
頻度:一定に増える過程と、群れで届く過程

図2:週ごとの攻撃の通知(侵害されたのは誰のシステムか別)。当サイトのデータセットから本記事のために作成した図です。
| 週ごとの件数(11週) | 平均 | 分散÷平均 | ポアソン検定 | 週あたりの傾向 | 傾向を除いた分散÷平均 |
|---|---|---|---|---|---|
| 攻撃の通知198件すべて | 18.0 | 14.58 | p < 0.001 | +25.7% | 4.52(p < 0.001) |
| 組織自身のシステムについての119件 | 10.82 | 2.60 | p = 0.004 | +11.5% | 1.67(p = 0.091) |
| 委託先のシステムについての顧客の79件 | 7.18 | 23.53 | p < 0.001 | +69.5% | 6.93(p < 0.001) |
発生率が一定のポアソン過程なら、分散÷平均は1前後になります。攻撃の通知をまとめると14.6で、上昇傾向を入れても消えません。侵害されたのが誰のシステムかで分けると、様子がはっきり分かれます。
- 自社システムの通知は着実に増えています。 週約11.5%の対数線形の傾向を入れると過剰分のほとんどが消え、残りはポアソンと矛盾しません(1.67、p = 0.09)。上昇の一部は実際のものです。マクニカの集計は7月に上向き、10月には政府が「危急」と表現しました。一部は情報源のカバーによるもので、8月はそれ以降の週より薄くなっています。
- 顧客の通知は群れで届きます。 9月下旬まではほとんどなく、最後の3週で25件、39件、10件です。どんな傾向を入れても残ります(6.93)。これらは独立した事象ではなく、群れの1つ1つが委託先の1件の事案です。
つまり、頻度のモデルは2つの部分からなります。自社システムの事案は、発生率が時間とともに変わるポアソン過程です。委託先の事案はクラスター過程で、事案が1件起きると、数日のうちに裾の重い数の顧客の通知が続きます。すべての通知に負の二項分布を1つ当てはめると(サイズ1.33)、2つが混ざり、ばらつきがどこから来るのかが見えなくなります。10月8日のJPCERT/CCの注意喚起のような出来事は発生率が変わった合図として、委託先の通知は群れの始まりとして扱ってください。
規模:裾の指数は1未満、最上位で曲がる

図3:公表された侵害の規模(両対数)。当サイトのデータセットから本記事のために作成した図です。
攻撃の通知198件のうち、件数を示しているのは140件です。中央値は約2万7,300件、合計は2億4,601万1,916件で、日本の人口の約2倍ですが、単位が混在し重複も含みます。上位3件(佐川急便、Gyazo、ソースネクスト)が合計の40.4%を占め、佐川急便の最大約5,323万件だけで21.6%です。
10万件を超える55件について、Hill推定量で求めた裾の指数は0.38です。2,000回のブートストラップでは、95%区間は0.32〜0.44です。件数のいくつかは上限値です。IDCフロンティアの顧客は「閲覧された可能性」として件数を出しており、一部は後に漏えいなしと判断しました。この顧客を除いても指数は0.385で、結果を動かしてはいません。別に集めた期間の長い12か月リスト(10万件以上の38件)では0.46です。
このブートストラップは通知を1件ずつ再抽出します。委託先ごとの集積構造を保持せず、公表の偏り、単位の混在、上限値の不確かさも補正しません。区間はこの再抽出モデルについてのもので、日本の侵害全体に対する母集団の信頼区間ではありません。
裾は最上位で曲がります。 最大級の通知だけで指数を求めると、値が上がります。
| 使った通知(大きい順) | 閾値 | 裾の指数 |
|---|---|---|
| 15 | 4,030,000 | 1.05 |
| 20 | 2,155,345 | 0.77 |
| 30 | 817,215 | 0.58 |
| 40 | 420,000 | 0.53 |
| 55 | 100,000 | 0.38 |
純粋なべき分布なら、どの閾値でもほぼ同じ指数になります。ここでは、10万件から数百万件までの裾の中ほどが非常に重く、最上位は薄くなっています。有限のサービス利用者数と整合する形ですが、日本の人口が物理的な上限だと示すものではありません。アカウント、取引、重複を含むレコードの件数は人数を超え得ますし、海外の顧客を持つサービスもあります。以下の人口に基づく上限は、例示的なモデルの仮定です。10万件から当てはめた単一のパレート裾は、これまでに見たものをはるかに超える通知の確率を大きく見積もります。そして、どこに上限を置くかが実際に効きます。
αが1未満の意味。 α ≤ 1のパレート裾では、平均は無限大になります。実際には、どの標本の平均も最大の1件に支配され、次の大きな通知で動きます。佐川急便が後から出した件数だけで、合計は5,300万件増えました。平均ではなく分位点で示し、使った上限(キャップ)を明記してください。
別のリストとの回顧的な照合。 当サイトの通知に当てはめた裾から、各リストに大きな通知がいくつあるはずかを予測できます。
| 規模 | 当サイトの通知:予測 | 実際 | 12か月リスト:予測 | 実際 |
|---|---|---|---|---|
| 100万件以上 | 22.8 | 29 | 15.7 | 17 |
| 1,000万件以上 | 9.4 | 7 | 6.5 | 5 |
どちらのリストでも同じ形が出ます。100万件以上は線の予測より多く、1,000万件以上は少なくなります。別に編集したリストですが、統合データセットと共通する事案を含むため、独立した検証でも、未観測の事案に対する予測の検定でもありません。当サイトの通知の1,000万件以上の7件は、佐川急便、Gyazo、ソースネクスト、skyticket(14,640,000件)、カプコン(CAPCOM IDの11,774,247アカウント)、バーガーキング・ジャパンのアプリ(11,180,000件)、焼肉きんぐのアプリ(10,788,963件)です。
注意点。 140件すべてに当てはめた対数正規分布(自然対数でμ = 10.193、σ = 3.828)も、観測した範囲にはよく合います。この点数では対数正規とパレート裾を区別できず、データの外では両者の答えが大きく違います。これがモデルリスクで、次の節でその大きさを測ります。
合計:モデルの選び方でどれだけ変わるか
頻度(件数を示す通知が年663.6件、分散÷平均15.84)と、3つの規模のモデルを組み合わせ、1件あたりを日本の人口で打ち切って、40,000年分をシミュレーションしました。頻度は11週間を年に換算したもので、10月の発生率を1年に広げています。水準は予測ではなくストレスとして読んでください。
| 規模のモデル | 中央値の年 | 99.5%点 | 99.9%点 |
|---|---|---|---|
| 経験分布:140件から復元抽出 | 11.51億 | 18.30億 | 19.82億 |
| 140件全体に当てはめた対数正規 | 24.96億 | 41.98億 | 45.90億 |
| 接続型:10万件以下は復元抽出、超える部分はパレート裾 | 33.43億 | 55.48億 | 60.41億 |
公表件数の年間合計。各通知の単位のままで、人数でも円でもありません。
水準よりも大事な結果が2つあります。
- モデルの選び方で、99.9%点が約3倍動きます。 経験分布は、すでに見た最大の通知より大きなものを決して生みません。パラメトリックな裾は生みます。データだけではどちらとも決められませんが、最上位の曲がりは控えめな答えの側を支持します。
- 上限が平均を決めます。 接続型のモデルでは、年間合計の期待値は、上限を5,323万(これまでの最大の通知)とすると20.20億、日本の人口とすると33.88億、10億とすると123.92億です。仮定によって平均が6倍変わるなら、その仮定こそがモデルです。
バーゼル委員会の先進的計測手法(AMA)は、オペレーショナル損失の1年99.9%点を銀行に求めましたが、損失の裾が重くデータが少ないと検証が難しく、バーゼル枠組みは裾の推定にシナリオ分析を求めていました。これがその理由です。後継の標準的計測手法は、銀行自身の実績で資本を調整します。過去10年の年間平均損失の15倍です。裾の指数が1未満なら、10年平均そのものが不安定で、1件の事象で決まり得ます。
委託先のリスクを「共通ショック」として扱う
ここからがサプライチェーンの部分です。1,000社のポートフォリオを考えます。銀行の法人顧客、保険会社のサイバー保険の引受先、あるいはグループ会社です。各社には自社起因の事案が年3%の確率で起きます。各社はまた、ある重要なサービスに依存しています。そのサービスの提供事業者には、顧客に及ぶ事案が年2%の確率で起き、起きれば顧客の半分が影響を受けます。
企業ごとの事案影響の期待件数は、市場の構造にかかわらず年30 + 10 = 40件です。変わるのは集中度だけです。
数え方: コードは自社起因と委託先起因の影響を加算します。同じ企業が両方の経路で被害を受ければ2件と数えるため、表と図は年間の被害企業の実数ではなく、企業ごとの事案影響の件数を示します。この仮定で重複を除いた企業数の期待値は、1,000 × [1 − (1 − 0.03)(1 − 0.02 × 0.5)] = 39.7社です。掲載した分位点は加算した影響件数についての値で、重複を除いた企業数の値ではありません。

図4:事案影響の期待件数が同じ5つの委託構造。図の企業数表示は両経路を加算したもので、二重に被害を受けた企業の重複を除いていません。各行200,000年分のシミュレーション。本記事のために作成した図です。
| 委託の構造 | HHI | 平均 | 標準偏差(シミュレーション/解析式) | 99.5%点 | 99.9%点 | 1年に影響が100件以上となる確率 |
|---|---|---|---|---|---|---|
| 全社が別々の委託先 | 0.001 | 40.0 | 6.2 / 6.2 | 57 | 61 | 0.00% |
| 同規模の委託先50社 | 0.020 | 40.0 | 11.5 / 11.5 | 77 | 87 | 0.01% |
| 同規模の委託先10社 | 0.100 | 40.0 | 22.9 / 22.9 | 135 | 150 | 1.69% |
| 集中型:40/20/10/10/5/5/5/5% | 0.230 | 40.0 | 34.2 / 34.1 | 242 | 276 | 4.27% |
| 全社が同じ1社 | 1.000 | 40.0 | 70.3 / 70.2 | 542 | 558 | 2.00% |
分散には解析式があり、シミュレーションの検算にもなります。企業数M、自社起因の確率p₀、委託先の事案の確率q、影響を受ける割合h、市場シェアsjとすると、
Var = M·p₀(1−p₀) + q·h(1−h)·M + q(1−q)·h²·M²·HHI(HHI = Σ sj²)
最初の2項は市場構造に依存しません。最後の項は、競争当局が使う集中度の指標、ハーフィンダール・ハーシュマン指数(HHI)とともに大きくなります。集中の項が支配的になると、標準偏差は√HHIに比例して増え、平均が動かないまま99.9%点は9倍になります。
実務での意味:
- 平均だけの比較では、集中が見えません。 影響1件あたりの費用が等しいと仮定すれば、期待損失のみに基づく比較はどの行でも同じです。反応するのは、裾の指標、資本、集中の上限だけです。
- HHIだけでは足りません。 集中型の市場は、1社集中(2.00%)よりも企業ごとの影響が100件以上になる確率が高く(4.27%)なります。大手2社にそれぞれ2%の確率があり、どちらか1社で足りるからです。指数だけでなく、最大のシェアも見てください。
- これは信用ポートフォリオのモデルが、デフォルトの相関を扱う方法と同じです。 共通の要因が、多数の債務者のデフォルト確率を同時に押し上げます。CreditRisk+はガンマ分布に従うセクター要因を使い、これは上で負の二項分布を生んだのと同じポアソン・ガンマ混合です。委託先がセクターにあたります。
国内の通知でショックを較正する

図5:攻撃の通知を、対象のシステム別に分類したもの。当サイトのデータセットから本記事のために作成した図です。
攻撃の通知198件中79件(40%)が、委託先のシステムについての顧客の通知で、委託先の事案は19件でした。 そのうち61件(77%)を4つのプラットフォームが占めます。コミューン23件、Studio 19件(20組織目の顧客の通知は、個人データが危険にさらされたとは書いていません)、IDCフロンティア12件、アルカディア7件です。残る15件の事案からは18件の通知が出ました。ApplyNow、NECの開発委託先、スカラコミュニケーションズが2件ずつ、12件の事案が1件ずつです。
- 顧客はまとまって公表します。 コミューンの顧客の通知23件のうち17件は、コミューン自身が公表した10月9日に出ました。Studioの19件のうち11件は、Studioが公表した10月16日です。4つのプラットフォームの顧客の通知は、いずれも7日以内に出そろいました。発見日を書いたStudioの顧客12組織は、全員が、Studioから連絡のあった10月16日を挙げています。関係のない企業が同じ日に事案を発見し、公表するのは、共通の委託先の痕跡です。共通ショックのモデルが表す事象、つまり1回の抽選が多数の企業に同時に当たる事象そのものです。
- 連鎖の大きさも裾が重い分布です。 23、19、12、7、次に2が3つ、その後は1が12続きます。モデルではq·hを固定せず、分布から引くべきです。
- それでも通知はショックを過小に数えます。 IDCフロンティアの1件の事案は495社に影響しましたが、個人データが危険にさらされたとする通知が当サイトのデータセットにあるのは12社、約2.4%です。侵害されたプラットフォームの顧客のほとんどは、何も公表しません。通知の件数で較正すると、q·h、そしてそれ以上に集中の項を過小評価します。
遅れて出る件数と報告の遅れ:IBNR(既発生未報告)
5件の通知は、件数を後の報告で初めて示しました。
- 扶桑電通: 47日後。
- 佐川急便: 23日後。第5報(10月23日)で、重複を含めて最大約5,323万件です。対象は6月21日〜9月30日の送り状データ、顧客リスト、スマートクラブ会員で、カード情報とパスワードは含まれません(INTERNET Watch・Impress Watch)。いまではデータセットで最大の件数です。
- ムーンスター: 13日後。最大59万3,000人です。
- コミックシーモア: 6日後。第4報(10月21日)で最大約420万件です。
- トラストバンク(ふるさとチョイス): 翌日。4,454,097件です。
JOGMEC(エネルギー・金属鉱物資源機構)の10月2日の通知(メールアドレス約8,500件)は、公表から23日後に当サイトのリストに入りました。
保険の用語では、これをIBNR(既発生未報告)と呼びます。ある期間に属する損失が、後になって報告され、あるいは規模が分かることです。締め切り日までに公表された件数で当てはめたモデルは、頻度も規模も過小に見積もります。標準的な補正は、件数や数字が第1報から最終報までにどう動くかから作る進展係数です。
通知に日付があるものでは、次のとおりです。
- 発見から公表まで: 中央値2日(72件。75%が3日以内、最長34日)。
- アクセスから発見まで: 中央値2日、75%が13日以内、最長25日(25件)。
- アクセスから公表まで: 中央値6日、75%が16日以内、最長141日(41件)。
アクセスの日付を書く通知は早く見つかったものに偏るので、これらの遅れは下限と見てください。知ってしまえば会社はすぐに公表します。遅れは、知るまでにあります。数えられる公表の時計は、攻撃の時計より中央値で約1週間、裾では数か月遅れています。
モデルはどうあるべきか
- 頻度: 自社システムの事案は、発生率が時間とともに変わるポアソン過程。委託先の事案はクラスター過程で、1件ごとに、数日のうちに裾の重い数の顧客の通知が続きます。
- 規模: 規模のモデルを少なくとも2つ使い、上限を明記した分位点で示します。裾の指数はブートストラップの区間(0.32〜0.44)でストレステストし、裾は上限の近くで薄くなるようにして、どこまでも伸ばさないでください。
- サプライチェーン: 上の共通ショックを使い、q·hはこうした連鎖で較正したうえで、何も公表しない顧客の分を上乗せします。
- データ: 第1報の件数も数字も動くので、当てはめの前に進展係数を当てます。
すでに使っている枠組みとの対応
| 枠組み | 求めていること | 上のモデルが提供するもの |
|---|---|---|
| Open FAIRのリスク分類 | 損失事象の頻度と損失の大きさを別々に見積もり、シミュレーションする | 頻度と規模の分解。公表件数は損失の大きさの要因として使い、損失そのものとしては使わない |
| バーゼル枠組みの先進的計測手法 | 1年99.9%点。重い裾にはシナリオ分析 | 合計の節:モデルによって裾がどれだけ動くか |
| バーゼルIIIの標準的計測手法 | 過去10年の年間平均損失の15倍で資本を調整 | 警告:αが1未満なら、その平均は最悪の年で決まる |
| バーゼル委員会のサードパーティリスク管理の原則(2025年12月) | 銀行単位とシステム全体の集中。重要なサービスの主要なn次委託先。監督当局がシステム全体の集中を把握する | 共通ショックのモデルとそのHHIの項 |
| EUのDORA(規則(EU)2022/2554) | 第28条:ICTサードパーティリスクと契約の登録簿。第29条:契約前のICT集中リスクの評価 | 同じ確認を、契約の前に |
| 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(2024年10月) | ガバナンス、特定、防御、検知、対応・復旧と並んで、サードパーティリスク管理を1つの領域とする | モデルに必要な委託先の一覧 |
| NIST SP 800-161r1 | サイバーセキュリティのサプライチェーンリスク管理:委託先の重要度と依存関係 | どの委託先をモデルに入れるか |
バーゼル委員会の原則は2025年12月10日に公表されました。金融庁のガイドラインのサードパーティの部分はPwC Japanの解説が整理しています。10月25日、当方の環境からBIS、金融庁、EUR-Lexのページを開けませんでした。上の説明は、検索結果に引用された各文書の本文と、これらの解説に基づいています。
防御側とリスク管理者のプレイブック
- 契約ではなく、依存を棚卸しする。 重要なサービスごとに、売上・顧客・データのどれだけが依存しているか、提供事業者自身の主要な委託先(バーゼル委員会のいうn次委託先)を記録します。HHIと最大のシェアを計算します。
- 委託先のシナリオは「多数の損失を伴う1つの事象」として書く。 下のシナリオカードを使ってください。委託先の事案は、500件の独立した事案ではなく、500社に同時に当たる1回の抽選です。
- 発生率は時間とともに変わるものとしてモデル化する。 頻度は通知と注意喚起から毎月更新します。JPCERT/CCや国家サイバー統括室の注意喚起は、雑音ではなく発生率の変化として、委託先の通知は群れの始まりとして扱います。
- 規模は上限を明記した分位点で示す。 規模のモデルを少なくとも2つ走らせ、その差をモデルリスクとして報告します。
- モデルをテレメトリーにつなぐ。 上の経路には検知手段があります。侵害レビューのJPCERT/CC指標のクエリ、分析ツールの公開状況のクエリ、大量ダウンロードのクエリ、ARTEXの指標、そしてPHP2ShellのSentinelとCrowdStrikeのルールです。検知の結果は、自社の頻度の推定に入れます。
- 報告の期限を知っておく。 個人情報保護法では、不正アクセスによる漏えいは、個人情報保護委員会への速報を速やかに(ガイドラインでは概ね3〜5日以内)、確報を60日以内に行う必要があります。委託先との契約上の通知期限は、その中に収まらなければなりません。
裾を動かす主要リスク指標(KRI):
| 指標 | 測り方 | なぜ重要か |
|---|---|---|
| 委託先の集中度 | 重要なサービスのHHIと最大のシェア(売上または顧客数で) | 分散のM²·HHIの項 |
| n次委託先の把握 | 重要な委託先のうち、その主要な委託先まで分かっている割合 | 2段先のクラウドやデータセンターが共通なら、それも1つのショック |
| 委託先からの通知の遅れ | 委託先が発見してから自社が知らされるまでの時間 | 個人情報保護委員会への報告期限を守れるかが決まる |
| 公開状態の期間 | JPCERT/CCの注意喚起や悪用が確認された脆弱性の一覧への掲載から、公開システムの修正までの日数 | ケースAとCは既知の脆弱性を突く |
| オブジェクト単位のAPIの確認 | 顧客向けエンドポイントのうち、2アカウント試験に合格する割合 | ケースBと大規模なAPI漏えい。当サイトのAPIガイドを参照 |
| 契約終了時の削除 | 終了した契約のうち、削除が確認された割合 | ApplyNowは契約が終わった顧客の応募者データを保持していた |
シナリオカード
シナリオ:[委託先・サービス]の事案が顧客に及ぶ
重要なサービス:[自社にとっての役割]
委託先:[名称] 主要なn次委託先:[依存するクラウド、データセンター、ソフトウェア]
自社の事業のうち依存する割合:[売上のx%/顧客y社/データz件]
ポートフォリオまたは業界のうち利用する割合:[s%] HHIへの寄与:[sの二乗]
きっかけ:[事業者でのランサムウェア/APIの欠陥/管理者認証情報の窃取/停止]
頻度q:[年あたり] 根拠:[通知の実績、CERTの注意喚起、事業者の表明]
影響を受ける割合h:[顧客に占める割合] 根拠:[類似事案。例:IDCフロンティア、2026年10月7日、顧客495社]
起きた場合の自社の損失:一次[復旧、残業、返金]、二次[通知、当局対応、請求]
委託先からの通知:契約上[時間]、確認日[日付]
個人情報保護委員会への報告:速報[日付まで]、確報[日付まで]
撤退または代替:切り替えに[日数]、確認日[日付]
責任者:[氏名] 見直し日:[日付] 次回見直し:[日付またはきっかけ]
データとコード
- 2026年8月10日〜10月25日の通知264件(CSV):公表日、組織名、区分、経路、顧客の通知が挙げる委託先の事案、件数と英日の表記、後の報告で件数が出た日、何が起きたか、通知にあればアクセスと発見の日付、データ項目、パスワードの状況、依拠した通知と二つ目の情報源。
- 2025年9月〜2026年10月の10万件以上の公表38件(CSV)
- モデル(Python、標準ライブラリのみ):2つのCSVと同じフォルダに置き、
python3 japan-breach-risk-model.pyで実行します。1分かかりません。 - 出力(JSON):本記事のモデルの節の数字は、すべてこのファイルから来ています。乱数シードが固定されているので、何度実行しても同じになります。
どちらのCSVもBOM付きのUTF-8なので、Excelでも日本語が正しく表示されます。日付はExcelでは各自の日付形式で表示されます。Excelから保存するときは「CSV UTF-8」を選んでください。ほかのCSV形式では日本語が失われることがあります。
まだ分からないこと
- 多くの攻撃者がどう入ったか。 自社システムの通知119件中63件、委託先の事案19件中6件は書いていません。経路の内訳は書いているもののもので、典型とは限りません。
- データから漏れているもの。 通知は、組織が公表を選び、当方の情報源が拾ったものです。8月は10月よりカバーが薄く、個人データが危険にさらされていない事案は侵害ほど一貫して記録できていないため、頻度のモデルには攻撃の通知198件だけを使っています。すべての行にすべての項目があるわけではありません。データ項目は119件、二つ目の情報源は108件、発見と公表の両方の日付は72件にあります。
- 単位。 件数はレコード、アカウント、人が混在し、多くは上限(「最大」「可能性」)です。ここにあるのは人数でも円での損失でもありません。
- 委託先のパラメータ。 共通ショックのモデルの3%、2%、50%は例示です。結果の形はこれらに依存しませんが、水準は依存します。
- ツールと被害組織。 被害組織、規制当局、CERTのいずれも、AIペネトレーションテスト・ツールを国内の特定の侵害と結び付けていません。
出典と更新
更新履歴
- 2026年10月27日。 2つのCSVの先頭にUTF-8のBOMを付けました。BOMがないと、ExcelはShift_JISとして読み込み、日本語が文字化けして列がずれていました。値は変えていません。
- 2026年10月25日 16:15(日本時間)。 データセットを8月10日〜10月25日の264件に広げ、1つのCSVにまとめました。アクセスと発見の日付、データ項目、二つ目の情報源は、分かるものについて付けています。表と図はすべて、まとめたデータで再計算しました。新たに加えたのは、自社システムと委託先の通知の分離、ブートストラップ区間と最上位での裾の曲がり、委託先からの連鎖(図5)、遅れて出る件数と報告の遅れ、危険にさらされたデータ、そして時系列の新しい行(個人情報保護委員会、金融庁、コミューン、Studio、カプコン、佐川急便の第5報、フューチャーショップ)です。佐川急便の件数は、通知ページがJavaScriptを必要とするため、INTERNET WatchとImpress Watchによります。
- 2026年10月25日 12:30(日本時間)。 初版公開。10月25日、当方の環境からJPCERT/CC、BIS、金融庁、EUR-Lexのページを開けませんでした。JPCERT/CCのケースA・B・C・Eは、10月24日にARTEXの分析のために確認した内容、ケースDは二次情報によります。枠組みは、検索結果に引用された各文書の本文から説明しています。
注意喚起、対応機関、政府
- JPCERT/CC「JPCERT-AT-2026-0030」と10月9日・23日の更新
- JPCERT/CC「JPCERT-AT-2026-0023」Metabase(2026年8月14日)
- issoh:ケースDの更新の解説
- マクニカ:2026年のWebシステムの侵害(2026年10月7日)
- NICT:A2Bの注意喚起(2026年10月13日)
- CrowdStrike:韓国の金融機関を狙ったARTEX(2026年10月7日、英語)
- piyolog:ARTEXのリポジトリの経緯
- 国家サイバー統括室(2026年9月30日、PDF)
- Impress Watch:各省庁の緊急会議(2026年10月8日)
- INTERNET Watch:国家サイバー統括室の注意喚起(2026年10月9日)
- 読売新聞(Yahoo!ニュース):自民党の本部(2026年10月9日)
- 個人情報保護委員会:漏えい等の報告
- 個人情報保護委員会:大規模な漏えい等事案を踏まえた対応について(注意喚起、2026年10月7日)・ScanNetSecurityの記事
- 金融庁:金融機関への要請(2026年10月9日)
各組織の通知
- EPARKリラク&エステ・LEAN BODY・Helpfeel(Gyazo)
- 大和証券(TDnet、PDF)・シチズン時計
- IDCフロンティア 第1報・ソースネクスト
- コミューン・Studio・デジタル庁・カプコン・フューチャーショップ・リンツ&シュプルングリー ジャパン
- 佐川急便の第5報:INTERNET Watch・Impress Watch
- データセットのすべての通知はCSVからリンクしており、108件は二つ目の情報源付きです。その多くは侵害レビューに表で掲載しています。
リスクの枠組みとデータ
- バーゼル委員会「Principles for the sound management of third-party risk」(2025年12月、PDF、英語)・プレスリリース
- バーゼル枠組みOPE30:先進的計測手法(英語)・FSIによる標準的計測手法の要約(英語)
- 規則(EU)2022/2554(DORA、英語)
- 金融庁:金融分野におけるサイバーセキュリティ対策・PwC Japan:サードパーティリスク管理の解説
- NIST SP 800-161r1(英語)・The Open Group:Open FAIRのリスク分類(英語)
- SEC:Form 8-KのItem 1.05(2023年7月、英語)・Help Net Security:Verizonの2026年版DBIR(英語)・VERIS Community Database
本記事は、公開された発表と当サイトのデータセットに基づく独立した編集上の分析です。個々の事案の調査ではなく、投資・金融に関する助言でもありません。

