2026年夏の情報流出を『5つの欠陥パターン』で読み直す — 件数ランキングより先に見るべきもの

サマリ

2026年の夏、個人情報の流出とサイバー攻撃の公表が相次ぎました。報道は件数の大きさで並びますが、件数は「どれだけ漏れたか」であって、「なぜ漏れたか」ではありません。

本稿は、7〜9月に公表された7つの事例を、当事者の公表文と警察庁・個人情報保護委員会の一次資料だけを材料に件数順で並べたうえで、どの欠陥パターンで起きたかという軸で読み直します。パターンは、ランサムウェア感染による業務停止、パッチ適用前の侵入、正規アカウントの悪用、サプライチェーン経由、保持していたデータによる被害拡大の5つです（5つ目は、プレモータム分析では「過剰保持」として点検する項目です）。

結論を先に書きます。7件のうち原因を公表した3件（Gyazo、ムラウチドットコム、デジタル庁 GSS）は、いずれも Web システムや VPN 機器の脆弱性が起点でした。人為ミスを原因に挙げた公表はありません（残る4件は原因が調査中または未公表です）。また、3件（Gyazo、パーク24、ニチレイ）では、削除済み画像のメタデータ、本人確認書類の画像、退職者・求職者の情報といった「保持していたデータの範囲」が被害を大きくしました。Gyazo とニチレイでは件数を、パーク24では深刻度を押し上げています（その保持が必要以上だったかどうかは、各社の公表文には書かれていません）。これは、教育では止まらず、設計と運用の自動化で止める領域です。そして、その多くはコードと設定から静的に検査できます。

データの整理 — 2026年7〜9月の公表事例

件数順の一覧

順位	事例（公表元）	公表日	件数	欠陥パターン
1	Gyazo（株式会社Helpfeel）	2026年9月16日（第二報 9月25日）	ユーザー情報 約2,362万件、画像メタデータ 約4.9億件（第二報で削除済み画像のメタデータ約1.74億件を追加）	② ⑤
2	ムラウチドットコム	2026年9月15日（第一報 7月24日）	7,716,811件	②
3	パーク24（タイムズカー）	2026年9月29日（第1報 9月25日、第2報 9月28日）	約660万件（うち本人確認書類が漏えいしたアカウントは約160万件）	⑤
4	セイコーマート（株式会社セイコーマート）	2026年9月29日	約57万アカウント（不正アクセスを受けた可能性のある対象）	—（調査中）
5	デジタル庁 ガバメントソリューションサービス（GSS）	2026年9月11日	約24.6万件（漏えいの可能性がある対象）	② ③
6	ニチレイグループ	2026年7月13日〜9月18日（第7報）	53,866件	④ ⑤
—	京王電鉄グループ	2026年9月26日	件数なし（情報漏えいは未確認）	①

件数は各社公表時点の数字で、本稿の確認日は2026年10月6日（10月7日に再照合）です。件数欄には、各社の公表での位置づけ（確認済みの流出か、流出・不正アクセスの可能性がある対象か）が確認済みでないものは括弧で併記しています。一次資料に到達した事例だけを載せ、報道のみで当事者の公表に無い数字は載せていません。欠陥パターンの割り当ては、各社の公表文に書かれた原因や経路から本稿が当てはめたものです。原因が調査中または未公表の事例（パーク24、セイコーマート、ニチレイ、京王電鉄）は、公表された経路・影響・流出した情報の種類から読み取れる範囲に留め、公表されていない攻撃手法を当てはめていません。

5つの欠陥パターン

次の表の「点検すべき設計上の欠陥（仮説）」は、プレモータム分析で各パターンに対して自社で点検すべき項目であり、各社で確認された根本原因ではありません。「該当事例」は、公表された経路・影響・流出した情報の種類から本稿が当てはめたものです。

#	パターン	何が起きるか	点検すべき設計上の欠陥（仮説）	該当事例
①	ランサムウェア感染による業務停止	業務システムが止まり、復旧まで事業が止まる（プレモータムでは、夜間・休日など手薄な時間帯の侵入を想定して点検する）	異常を検知して自動で止める仕組みが無い。バックアップが同じ場所にあり一緒に暗号化される	京王電鉄
②	パッチ適用前の侵入	VPN や Web システムの未修正の脆弱性（多くは既知のもの）を突かれる	パッチ適用に手作業や停止が要る。境界防御に依存し、内部の横展開を防げない	Gyazo、ムラウチドットコム、デジタル庁 GSS
③	正規アカウントの悪用	盗んだ、または不正に利用したアカウントやセッションで、正規の経路から入る	パスワードだけの認証。管理用アカウントの権限が広い。セッションが長い	デジタル庁 GSS
④	サプライチェーン経由の侵入・連鎖	委託先や共通基盤が止まり、取引先へ影響が波及する	外部連携の依存関係を把握していない。1社の停止が多数へ連鎖する	ニチレイ（取引先への波及）
⑤	保持していたデータによる被害拡大	侵入は1回でも、残っていたデータの範囲によって被害が桁違いになる	過剰保持（データ最小化が守られていない。本人確認書類や削除済みデータの残骸が同じ場所にある）。保持が必要以上だったかは各社とも未公表で、自社で点検する項目	Gyazo（削除済み画像のメタデータ）、パーク24（本人確認書類画像）、ニチレイ（退職者・求職者の情報）

公表文から読み取った根拠を、事例ごとに添えます。

• Gyazo: 「画像アップロードサーバーに存在した脆弱性」を悪用された（②）。第一報の約4.9億件は主に2019年1月以前に登録された画像のメタデータで、第二報では「主に2023年2月以前に削除された画像」のメタデータ約1.74億件の流出が加わった（⑤）。脆弱性が既知のものだったかは公表されていない。
• ムラウチドットコム: 7月15日未明にシステム障害が発生し、16日に不正アクセスの痕跡を確認。「Web システムの一部に存在していた脆弱性」を起点に複数システムへ侵入が拡大した（②）。既知の脆弱性かは公表されていない。
• パーク24: 原因はフォレンジック調査中。流出した情報に運転免許情報・本人確認書類画像・パスワード（復元できない形式で保管）が含まれ、第3報で本人確認書類（運転免許証画像等）が漏えいしたアカウント数は約160万件と確認された。本人確認書類の画像を保持していたことが深刻度を押し上げた（⑤。約660万件はアカウント数で、画像の有無は件数を変えない）。
• セイコーマート: 「セイコーマートアプリのサーバーを経由して」会員情報サーバーに不正アクセスされ、端緒は9月24日の不正な退会処理1件だった。原因は調査中で、脆弱性の有無も認証情報の奪取の有無も公表されていないため、本稿では欠陥パターンを当てはめていない（正規のアプリ経路から会員情報へ到達している点は③で想定する経路に近いが、公表文からは断定できない）。
• デジタル庁 GSS: 「VPN 機器の脆弱性」から侵入され（②）、「保守運用担当者のアカウント」でサーバー上の大量ファイルにアクセスされた（③。認証情報の入手経路は公表されていない）。
• ニチレイ: 「不正アクセス」によるシステム障害で冷蔵倉庫の入出庫と冷凍食品の出荷が止まり、取引先へ波及した（④）。第7報で、2021年以降の退職者を含む従業員・家族・求職者の情報43,709件を含む53,866件の漏えいを確認した（⑤）。攻撃手法（ランサムウェアかどうか）は公表されていない。
• 京王電鉄: 「ランサムウェアによる攻撃」を9月26日未明に確認し、一部グループ会社の営業システムに支障が出た。情報漏えいは確認されていない（①。攻撃の時間帯や侵入経路は調査中で、「手薄な時間帯」「検知・バックアップの不備」は本稿の当てはめではなく点検仮説）。

統計で見る背景

警察庁の「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、2026年上半期のランサムウェア被害報告は123件で、半期として統計開始以来最多です。侵入経路は被害組織へのアンケートで VPN 機器が約5割を占め、被害組織の規模別では中小企業が約6割、業種別では製造業が約3割でした。

個人情報保護委員会の「令和7年度 年次報告」では、令和7年度（2025年度）の個人データの漏えい等事案に関する報告の処理件数は17,139件で、前年度の19,056件から減っています。年度統計は報告の件数であって1件あたりの規模を示す指標ではなく、今回取り上げた事例群と他の時期との比較も本稿では行っていません。言えるのは、今回取り上げた2026年夏の事例に、数百万件規模の流出が複数含まれるということです。

岡崎の分析

「人の教育」で止まるのは、5つのうち1つの一部だけ

情報流出のニュースのあとに社内で起きるのは、たいてい「注意喚起」と「研修」です。それ自体は必要ですが、今回の7事例のうち原因が公表された3件に当てはめると、教育で止まったはずの事例は見当たりません。脆弱性を起点とした侵入（②）、認証設計（③）、依存関係の把握（④）、データの保持（⑤）は、現場の注意力ではなく、設計と運用の仕組みで決まります（パッチ適用が遅れていたかどうかは各社とも公表しておらず、自社で点検する項目です）。①の「管理の隙」ですら、夜間に人を張り付けることではなく、異常を検知して自動で止める仕組みと、バックアップの分離で対処する領域です。

私たちは、流出対策の議論が「人の問題」に寄りすぎていると見ています。少なくとも公表された経路では、人は入口になっていません。残る4件は原因が未公表で、人を経由した可能性は否定できませんが、対策の優先順位を「人」から「設計」へ移す材料としては十分だと考えています。

件数を決めたのは「侵入」ではなく「保持」

⑤に該当する3件（Gyazo、パーク24、ニチレイ）に共通するのは、侵入そのものより、侵入した先に何が残っていたかです。Gyazo では削除済み画像のメタデータが、パーク24では本人確認書類の画像が、ニチレイでは退職者や求職者の情報が、それぞれ被害を大きくしました（Gyazo とニチレイは件数を、パーク24は深刻度を）。

これは経営の判断領域です。「いつか使うかもしれない」データを残す判断は、本来は現場ではなく経営が担うものです（各社がどう判断していたかは公表されていません）。保持期間を決めて自動で消す仕組みは、技術的には難しくありません。難しいのは「消してよい」と決めることです。

公表までの速さを左右する設計を点検する

デジタル庁 GSS は6月25日に異常なアクセスを検知し、7月9日に VPN 機器の脆弱性からの侵入と判明、9月11日に公表しました。ムラウチドットコムは7月15日にシステム障害が発生し、16日に痕跡を確認、7月24日に第一報、9月15日に件数を確定しました。検知から公表までの期間が何で決まるかは各社の公表文に書かれていませんが、ログが残っているか、何が漏れたかを特定できるデータ設計かは、影響範囲の特定を早めるために自社で点検したい項目です。追加専用のログとデータの分離は、特定と通知を早める余地を広げます。これも教育ではなく設計の話です。

提言 — どう付き合っていくか

1. 1件数ではなくパターンを見る公表文の原因・経路から、①〜⑤のどれに当たるかを読む。本稿の事例では、件数の大きさは侵入の巧妙さではなく『保持』の範囲で決まっていた。→↓
2. 2教育で防げる範囲と防げない範囲を分けるフィッシングや誤送信は教育の領域。脆弱性・認証設計・依存関係・保持期間は設計と運用の領域。後者を人の注意力に委ねない。→↓
3. 3システム側は今日から検査する多要素認証（MFA）の有無、セッションの長さ、ログへの個人情報出力、削除ジョブの有無、自動更新の設定は、コードと設定から静的に読める。まず自社のリポジトリで確認する。

✓件数に驚く前に、同じ欠陥パターンが自社にあるかを確認する。

人の教育で防げる範囲・防げない範囲

教育で効くのは、フィッシングメールへの対応、誤送信、持ち出しの判断といった「人が入口になる」経路です。これは続けるべきです。一方で、経路が公表された3事例はいずれも、人の注意力の外側にありました（残る4件は原因が未公表です）。脆弱性のパッチを数日で当てられる構造か、管理者アカウントに MFA が掛かっているか、委託先に渡した権限が最小か、保持期間を過ぎたデータが自動で消えるか。これらは「気をつける」では変わりません。

システム側は今日から検査できる

5つの欠陥パターンのうち②③④⑤は、リポジトリ内のコードと設定に現れる部分を今日から検査できます。認証ライブラリと MFA の実装、セッションの有効期限と Cookie の属性、ログに個人情報を出している行、削除ジョブの有無、Dependabot や Renovate の設定、外部 API を呼ぶ箇所とキーの渡し方。これらは、生成AIのコーディングエージェントに読ませれば、人が「分からない」と答えた項目のうちコードから読める部分を補いながら、優先順位つきの所見にできます。

私たちは、Claude Code でこの5パターンを検査する plugin を公開し、自社サイトのリポジトリを実際に検査しました。手順と結果は 情報流出の『システム側の欠陥』を Claude Code で15分検査する にまとめています。検査が見つけられないもの（運用の実地、クラウド側の設定、既知脆弱性との照合）も明記していますので、「検査すれば安心」ではなく「検査で見える範囲を先に片づける」ための入口として使ってください。

フィールフロウでは、自社システムの5パターン点検と、所見を設計と運用の改善に落とす伴走をご相談いただけます。システム側の点検について相談する