← 記事一覧へ

日本の侵害は、どう行われているのか:一次資料で組んだ時系列と、委託先を「共通ショック」として扱うリスクモデル

侵害の手口を確かめられる一次資料、2026年10月25日までの時系列、そして国内264件の通知で組んだ再現可能なリスクモデル。裾の重さと委託先からの連鎖を示します。

事案の発生時期: 通知は2026年8月10日〜10月25日、時系列は7月〜10月25日出典確認日: 2026/10/25更新日: 2026/10/25

30秒でわかる要点

要点
最近の侵害がどう行われているかを時系列で示す資料はないか、という読者の質問に答えます。単一の資料はなく、一次資料を証拠の強さで分けて読むのが答えです。国内264件の通知(2026年8月10日〜10月25日)では、自社システムへの攻撃119件中63件が経路を書いておらず、攻撃の通知の40%は委託先の顧客からで、規模の裾の指数は約0.38です。
対応するチーム
委託先リスク、SIEM、IT運用、法務・プライバシー
最初のアクション
重要な委託先ごとに、自社の事業のどれだけが依存しているかを一覧にしてHHIを計算してください。次に、委託先の事案を全顧客に同時に及ぶ1つの事象としてモデル化し、その連動がある場合とない場合で99.5%点を比べてください。
不確実性・注意点
通知は組織が公表を選んだものです。多くは経路を書かず、件数はレコード・アカウント・人が混在し、8月は情報源のカバーが薄く、委託先モデルのパラメータは例示です。金額の損失は扱っておらず、どのツールも特定の被害組織とは結び付いていません。
ダーク背景のヘッダー:日本の侵害は、どう行われているのか。一次資料で組んだ時系列と、委託先を共通ショックとして扱うリスクモデル。自社システムの通知119件中63件は経路を書いていない。攻撃の通知の40%は委託先の顧客から。委託先が1社に集中すると99.9%点は9.1倍。
実務への示唆

明日どこかの委託先が止まったら、自社の顧客や取引先のうち何社が一緒に止まるでしょうか。その問い方をしたとき、リスクの数字は変わりますか。

最近のセキュリティ侵害がどのように行われているのかを、時系列とあわせて説明している資料はないか。読者からそう尋ねられました。見つかったのは意見ばかりで、詳細も、根拠のある仮説もなかったそうです。目的は、金融機関の定量的リスク管理と、サプライチェーンのリスクを組み合わせることです。 これを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日

2026年7月から10月25日までの時系列を3段で示す表。ツールと攻撃者:7月26日にARTEX v0.1.0を公開、9月18〜19日にライセンス改定と政府・教育機関ドメインの既定除外、9月下旬〜10月上旬に韓国の金融機関への攻撃に使用、10月8日に更新停止、10月23日にJPCERT/CCがCairn、CyberStrikeAI、ARTEXを攻撃の試行に名指し。対応機関と政府:7月にマクニカの集計が急増に転じる、8月14日にJPCERT/CCのMetabase注意喚起、10月1日に能動的サイバー防御の法律が施行、10月7日にマクニカが119件と集計、10月8〜9日にJPCERT/CCの注意喚起と大臣・国家サイバー統括室・自民党の発言、10月7〜9日に個人情報保護委員会、続いて国家サイバー統括室・金融庁・経産省・総務省・IPAの注意喚起、10月13日にNICTのA2B注意喚起、10月21日に首相のPHP2Shell要請。主な公表:7月31日にEPARK約3,300万、8月10日に本データセットの起点、9月16日にGyazo約2,362万、9月25日にファインズ1,536,322件、10月5〜6日に同じ委託先から大和証券とシチズン時計、10月7日にIDCフロンティアのランサムウェアで顧客495社、10月9日にコミューン(10月14日までに顧客23件の公表が続く)、10月15日にソースネクスト最大22,519,960件、10月16〜22日にStudio(顧客20件の公表)、10月23日に佐川急便の第5報で重複を含め最大約5,323万件。

図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つの段階を混ぜないことが要点です。

  1. 被害組織が書いたこと。 通知が経路を明記しているもの。その事案については直接の証拠ですが、組織自身のシステムについての通知119件のうち経路があるのは56件だけです。
  2. 対応機関が複数の事案にわたって述べたこと。 JPCERT/CC、マクニカ、NICTは、被害組織名を挙げずに複数の事案で見えた手口を説明しています。何が起きているかは分かりますが、どの事案の説明かは分かりません。
  3. 仮説。 当てはまるものの確認されていない見方です。たとえば、サイトごとの探索の一部に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件あたりの攻撃者のコストを下げます。

  1. 広く探し、既知の穴を突く。 各標的で多数の既知の脆弱性と、残された設定・バックアップファイルを調べます(ケースA、T1595.002、T1190)。Metabaseのような分析ツールがインターネットに公開されたまま、修正も遅れていました(ケースC)。
  2. 1つのサイトを調べ、そのサイト自身の機能でデータを取る。 公開アプリを読み、API呼び出しを一覧にし、アプリが使わないものを、偽のヘッダーや壊れたトークンを付けて呼び出します(ケースB、T1190)。要求をTorとレジデンシャルプロキシに分散させ、アプリのUser-Agentをまねて、アドレス単位の遮断や単純なフィルタに見えないようにします(T1090.003)。このサイトごとの作業には、以前は熟練者の数日が必要でした。計画を立て、ツールを呼び、遮断されても続けるエージェントはそのコストを下げます。マクニカとNICTが警告しているのはこの点です。
  3. プラットフォームを狙い、多くの被害組織を得る。 コミュニティサービス、サイト作成ツール、予約システム、問い合わせ窓口、クラウド事業者は、多数の組織のデータを一度に持っています(T1199)。1回の侵入が、そのシステムを運用していない会社からの何十件もの通知になります。攻撃者から見ればてこの原理、リスク管理者から見れば相関です。
  4. 到達できるサーバに居座る。 アプリケーションサーバ上のWebシェルは、最初の経路が塞がれた後もアクセスを保ちます(ケースD、T1505.003)。
  5. 収益化する。 データを売るか恐喝に使うか、基盤を暗号化します(T1486)。事業者で暗号化が起きれば、それだけで数百の顧客が止まることをIDCフロンティアが示しました。

リスクモデル

銀行のオペレーショナルリスク部門なら、この構造に見覚えがあるはずです。損失分布手法(LDA)は、損失がどれくらいの頻度で起き(頻度)、1件がどれくらいの大きさか(規模)を別々にモデル化し、シミュレーションで合成します。サプライチェーンのリスクは、標準的なLDAが扱わないものを加えます。依存関係、つまり委託先での1つの事象が多数の企業に同時に損失を生むことです。以下では、それぞれの部分を国内の通知に当てはめ、依存関係が何をもたらすかを示します。

以下はすべて、2つのCSVから1本のPythonスクリプト(標準ライブラリのみ、乱数シード固定)で計算しています。本記事の数字は、その出力ファイルから写したものです。

頻度:一定に増える過程と、群れで届く過程

2026年8月10日から10月25日までの、個人データが危険にさらされた攻撃の通知を週ごとに示す積み上げ棒グラフ。組織自身のシステムについての通知と、委託先のシステムについての顧客の通知に分ける。週ごとの合計は2、10、12、5、8、9、12、19、44、52、25件。自社システムの通知は2、10、12、4、8、9、9、18、19、13、15件で、点線の傾向線は週11.5%で上昇。顧客の通知は最初の3週はなく、その後1、0、0、3、1、25、39、10件。副題では、傾向を除いた分散÷平均を、自社システムで1.67、顧客の通知で6.93と示す。

図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未満、最上位で曲がる

両対数グラフで、各公表件数以上の通知の割合を示す。青い点は件数を示した攻撃の通知140件で、2件から約5,323万件まで。オレンジの丸は12か月リストの10万件以上の38件で、裾の割合をそろえて表示。10万件の点線の閾値より上では、両方が黒い直線、α 0.38のパレート裾に沿って並び、傾き−1より緩い。最大級の通知では線より下に外れ、上位15件だけではα 1.05。副題ではブートストラップ95%区間を0.32〜0.44、12か月リストでは0.46と示す。

図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社です。掲載した分位点は加算した影響件数についての値で、重複を除いた企業数の値ではありません。

1,000社について、自社起因と委託先起因の年間の影響を加算し、平均が同じ40件の5つの委託構造で示す点と線の図。各行に平均、99.5%点、数値付きの99.9%点。全社が別々の委託先(HHI 0.001):99.9%点61。同規模の委託先50社(HHI 0.020):87。同規模の委託先10社(HHI 0.100):150。集中型40/20/10/10/5/5/5/5%(HHI 0.230):276。全社が同じ1社(HHI 1.000):558。標準偏差は6.2から70.3に増える。

図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+はガンマ分布に従うセクター要因を使い、これは上で負の二項分布を生んだのと同じポアソン・ガンマ混合です。委託先がセクターにあたります。

国内の通知でショックを較正する

2026年8月10日〜10月25日の攻撃の通知198件を、対象のシステム別に示す横棒グラフ。組織自身のシステム(委託先の記載なし)119件。委託先のシステムについての顧客の通知を委託先の事案ごとに数えると、コミューン23件、Studio 19件、IDCフロンティア12件、アルカディア7件、ApplyNow 2件、NECの開発委託先2件、スカラコミュニケーションズ2件、その他の委託先の事案12件が各1件。副題は、198件中79件(40%)が19件の委託先の事案から出ており、上位4件で77%を占めると示す。注記は、顧客は委託先と同じ時期に公表するとして、コミューンの顧客23件中17件が10月9日、Studioの19件中11件が10月16日、4つのプラットフォームの顧客の通知はいずれも7日以内に出そろったと示す。

図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のページを開けませんでした。上の説明は、検索結果に引用された各文書の本文と、これらの解説に基づいています。

防御側とリスク管理者のプレイブック

  1. 契約ではなく、依存を棚卸しする。 重要なサービスごとに、売上・顧客・データのどれだけが依存しているか、提供事業者自身の主要な委託先(バーゼル委員会のいうn次委託先)を記録します。HHIと最大のシェアを計算します。
  2. 委託先のシナリオは「多数の損失を伴う1つの事象」として書く。 下のシナリオカードを使ってください。委託先の事案は、500件の独立した事案ではなく、500社に同時に当たる1回の抽選です。
  3. 発生率は時間とともに変わるものとしてモデル化する。 頻度は通知と注意喚起から毎月更新します。JPCERT/CCや国家サイバー統括室の注意喚起は、雑音ではなく発生率の変化として、委託先の通知は群れの始まりとして扱います。
  4. 規模は上限を明記した分位点で示す。 規模のモデルを少なくとも2つ走らせ、その差をモデルリスクとして報告します。
  5. モデルをテレメトリーにつなぐ。 上の経路には検知手段があります。侵害レビューのJPCERT/CC指標のクエリ、分析ツールの公開状況のクエリ、大量ダウンロードのクエリ、ARTEXの指標、そしてPHP2ShellのSentinelとCrowdStrikeのルールです。検知の結果は、自社の頻度の推定に入れます。
  6. 報告の期限を知っておく。 個人情報保護法では、不正アクセスによる漏えいは、個人情報保護委員会への速報を速やかに(ガイドラインでは概ね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社]
起きた場合の自社の損失:一次[復旧、残業、返金]、二次[通知、当局対応、請求]
委託先からの通知:契約上[時間]、確認日[日付]
個人情報保護委員会への報告:速報[日付まで]、確報[日付まで]
撤退または代替:切り替えに[日数]、確認日[日付]
責任者:[氏名] 見直し日:[日付] 次回見直し:[日付またはきっかけ]

データとコード

どちらの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は二次情報によります。枠組みは、検索結果に引用された各文書の本文から説明しています。

注意喚起、対応機関、政府

各組織の通知

リスクの枠組みとデータ

本記事は、公開された発表と当サイトのデータセットに基づく独立した編集上の分析です。個々の事案の調査ではなく、投資・金融に関する助言でもありません。

記事一覧へ →Read in English ↗