10月の情報漏えい、気づいた日から公表まで66件の中央値は3日

気づいた日から数えた66件では、第1報までの日数の中央値は3日でした。2026年10月に第1報が出た国内の情報漏えいと不正アクセスを、当サイトの事故の記録から99行集め、発表が数え始めに使った日の意味を1件ずつ分けて数えた結果です。

ただ、この3日をそのまま自社の目標にはできません。

「検知した日」と「委託先から報告を受けた日」と「漏えいが分かった日」では、同じ日数でも測っているものが違うからです。ドン・キホーテなど4社の件は、報告を受けた日からなら33日、委託先が検知した日からなら43日になります。

数え始めは5種類あった

発表の言葉を読むと、起点の日は次の5種類に分かれました。日数は起点の日から公表の日までの暦の日数で、同じ日は0日です。

いちばん多い「気づいた日」の66件は、43件が3日以内、50件が5日以内に第1報を出しました。平均をとると16.9日まで伸びますが、ZonExpertの409日とH.I.S.のタイ法人の300日に引っ張られた数字です。平均だけを見ると、多くの事故の感覚からずれてしまいます。

同じ事故でも、どの文を起点にするかで数字は動きます。

• モスカードは、提供元の検知（10月14日）からなら9日、流出の確認（10月19日）からなら4日です。
• お名前.comデスクトップクラウドは、利用者の問い合わせ（10月19日）からなら2日、不正なプログラムの確認（10月20日）からなら1日です。
• 第一興商は、報告を受けた日（10月5日）からなら3日、委託先の感染判明（10月1〜2日）からなら6〜7日です。

「止めた日・起きた日」の16行には、気づいた日が書かれていません。中央値は1.5日と短いものの、起点が別物なので、いちばん早いとは読めないのです。

この種類には、停止や遮断の日か、不正アクセスが起きた日が1日に定まる発表を入れました。らしんばん（9月14〜16日）やIDARE（8月10日〜9月27日）のように発生が何日にもわたり、止めた日も書かれていない発表は外しました。楽天モバイルも、書かれているのは改修の完了日（6月20日）だけです。

公表の日は、その組織が不正アクセスや漏えい（疑いを含む）に初めて触れた日です。松屋の28日夜の告知は緊急メンテナンスだけだったので、不正アクセスの説明が出た29日を公表としました。続報の日も使っていません。ホワイトエッセンスの10月5日の発表は続報で、8月12日に不正アクセスを知らせていたため、対象から外しました。

3日以内の第1報、13件は件数なし

では、早い公表は中身が薄いのでしょうか。「気づいた日」の66行のうち、第1報に件数か人数の目安があるかを見られる64行で数えました。eギフトの不正発行のギフティと、広告アカウントの件のソルティドッグは、個人情報の件数という形の事故ではないので除きました。

3日以内の41件では、28件が件数や人数を書き、13件は書いていませんでした。4〜14日の15件では3件、15日以上の8件でも3件が書いていません。

3日以内の13件は、「止めた」「調査中」が中心の第1報です。たとえばコミックシーモアは10月16日の発表で「対象件数：精査中」とし、件数は21日の第4報で示しました。Joshinは10月17日の初報から10月26日の第2報まで、カーセンサーは10月18日の告知から10月21日の発表まで、件数が出ていません。

逆に、ブックオフは3日で最大約643万件を示し、13日の第2報で6,427,735件に確定しました。焼肉きんぐも3日で10,788,963件を示しています。ニフティは気づいた当日に最大542,513件を示し、21日の第二報で最大18,000件に絞り込みました。

ですから、日数の短さと第1報の中身は別に見たほうがよさそうです。編集部は、差を生む要因に「項目で数えられるデータかどうか」があるとみています。会員DBなら集計で件数が出ますが、ログの解析が要る調査では、まず止めたことしか言えない段階があるからです。もっとも、3日以内の会員DBなど36件でも、9件は第1報に件数を書いていません。項目で数えられるからといって、必ず早く数字が出るわけではないのです。

メールやファイルの6件は長めだった

差が目立ったのは、メールやファイルが対象の6件です。

図の左は、止めた日・起きた日を除く83行で比べた中央値です。起点の種類は混ざっています。メールか会員DBかが読めない15行は、どちらにも入れていません。気づいた日だけでそろえると、メールやファイル5件は18日、会員DBなど52件は3日です。

6件の日数はGDOの3日、JAEAの6日、大阪大学の12日、講談社BECKの18日、外務省の95日、H.I.S.の300日で、中央値の15日は12日と18日の間の値です。会員DBなどの62件は3日でした。中身の精査を発表で理由に挙げたのは、この6件ではH.I.S.だけです。発表に「調査に時間を要した原因（理由）」という節を立て、次のように説明しました。

サーバ内には個人情報とは無関係のデータ（会計上の記録など）が大量に混在しており、ファイル形式やデータの保存状態が多岐にわたっていたため、機械的な処理や検索を行うことができず、情報の正確性を期すために、一つひとつのデータを手作業を含めて慎重に精査・照合する必要があった

ただし6件しかなく、開きも大きい数字です。ゴルフダイジェスト・オンラインはファイルのダウンロードを確認しながら3日で公表し、日本原子力研究開発機構はダウンロードされた2,419件を確認して6日で公表しました。会員DBの側にも、楽天トラベルの46日があります。型だけで日数は決まりません。

委託先や提携先のシステムが絡む14件の中央値は6日で、自社のシステムの69件は3日でした。ただ、14件のうち9件は、起点が報告の届いた日です。残る5件は気づいた日が起点で、ZonExpertは委託先自身の発表です。中央値は、9件だけなら4日、5件だけなら9日、ZonExpertを除く13件なら5日と動きます。報告が起点の組織は、委託先の検知まで戻ると、図の右のように2段に分かれます。ドン・キホーテなど4社は、委託先の検知から報告まで10日、報告から公表まで33日でした。第一興商は3日と3日、ベネフィット・ワンは0日と7日、大和証券は0日と2日です。

釧路市はさらに長い例です。委託先の被害は8月29日で、当初は影響なしと報告を受けていました。10月13日に流出の可能性の報告があり、市は2日後に公表しました。公表までは2日でも、攻撃からは47日たっていました。

外から知らされた事故が長くなるとは、今回の数字からは言えません。infoQ、nimoca、アットリンク、お名前.comの4件は2〜3日です。もっとも、JOGMECや沖縄ツーリストのように、知らされた日を書かない発表はこの4件に入りません。

15日以上かかった10件を公表の順に並べると、発表に書かれた事情はまちまちでした。

遅れの理由を節に立てて書いた発表は、読めた範囲でH.I.S.だけです。公表が遅く見える事故にも、全ファイルの精査や委託先の調査のような事情はありえます。日数で優劣は決まりません。編集部は、長くなったときほど、その事情を1節書いておく価値が大きいと考えます。読む側が勝手に推測せずに済むからです。

委員会への報告は別の時計で動く

個人情報保護委員会への報告と公表は、別の話です。通則編のガイドラインによると、報告対象の事態の速報は「当該事態を知った時点から概ね3～5日以内」が目安で、確報は30日以内、不正の目的のおそれがある事態は60日以内です。一方、公表について書かれているのは、事案の内容等に応じて「速やかに公表することが望ましい」までで、日数の目安はありません。

だから第1報の中央値3日と、速報の目安の3〜5日は、数字が近いだけです。確報の期限の数え方も違います。ガイドラインは知った時点を1日目とし、土日祝も含めて数えるので、知った日を0日とするこの記事の日数とは1日ずれます。

報告の日が分かる発表は15件ありました。報告が先だったのは7件です。ZonExpertは405日、H.I.S.は282日、日本経済新聞社のクラウドの件とベネフィット・ワンは5日、GALLERY・2は2日、アルカディアとカプコンは1日、公表より前に報告を済ませていました。同じ日は7件でした。逆にふるさとチョイスは19日に疑いを公表し、報告は翌20日でした。書いている発表が一部なので、全体の傾向とは読めません。

つまり、委託先から「委員会に報告した」と聞いても、公表が済んだとは限りません。起算点の決まりも確認しておきたいところです。ガイドラインの基準は「いずれかの部署が当該事態を知った時点」で、委託元は通常、遅くとも委託先から通知を受けた時点で知ったことになります。流れの詳細は委託先で個人情報が漏えいしたら?に、委員会の件数の読み方は漏えい延べ2.6億人は実人数ではないにあります。

公表の日までの段取り

10月の「気づいた日」の66件は、当日に5件、翌日までに21件、3日以内に43件、5日以内に50件、60日以内に63件が第1報を出しました。この時間の感覚に、やることを重ねたのが次の図です。段取りは編集部の案で、法令が決めているのは報告対象の事態での委員会への報告と本人への通知です。

数字から見て、準備で短くなりそうな所は次の5つです。

1. ログとメールの監査記録を、気づいた当日に書き出す手順を決めておく。調査が長引くほど、古い記録から消えていきます。保存日数の考え方は外務省の記事の最後の節にあります。
2. 気づいた日、止めた日、漏えいが分かった日を、記録の別々の欄に書く。この3つを分けて公表すれば、読む側が起点を読み違えません。今回も16本は、起点に使える日か公表の日が読み取れず集計から外れました。
3. システムの台帳に「項目で数えられるか」の欄を足す。会員DBは集計の手順を、メールとファイルサーバーは対象を絞る順番と保存年数を決めておくと、第1報の中身が変わります。
4. 委託先との契約に、報告の期限と、検知の日時を報告に含めることを入れる。今回の例では、委託先の検知から報告まで0日から10日まで開きがありました。ガイドラインは委託元への通知の目安を「委託先が当該事態の発生を知った時点から概ね3～5日以内」としています。
5. 第1報の文案を用意する。分かったこと、止めたもの、調査中のこと、窓口、次に知らせる時期の5つです。件数が出ていないなら「精査中」と書けば足ります。

次のテンプレは、社内の第一報と時系列の記録に使えます。

この集計で言えないこと

数えられたのは、公表され、当サイトの記事になった事故だけです。公表しない事故は、ここには出てきません。10月は報告が急増した月でもあります。委員会の資料では、1日あたりの報告は9月まで5〜10件で、10月は16日までに830件、1日約52件でした（2.6億人の記事の表）。ほかの月の公表の日数が同じとは限りません。同じ事故の記録を入口の型で分けた10月の115件の記事とも、数え方が違うので件数は一致しません。こちらは日付の読める行だけを残しています。

出発点は、2026年10月に公開した事故の記録191本で、92本を外して99行にしました。

同じ根の事故は、種類ごとに1行にしました。i-askはスカラと大和証券の2行があり、NECの委託先に関わる大阪公立大学と大阪大学は別の事象として分けました。

起点の定義はそろっていません。「検知」「確認」「判明」「把握」を発表の言葉で読み分けたのは編集部で、人によって分け方は変わるはずです。起点の文を今回取得した公式の発表で照らせたのは54行です。残りの45行は、公式がrobots.txtや画面の仕組みで取得できなかった行や、日付の載る文書を取り直せなかった行で、当サイトの記事の記述か報道によりました。外務省、JAL、ビーケー・ジャパンのように報道でしか確かめられない行は注に書きました。暦の日数なので、土日の違いも時刻の差も入っていません。

99行の一覧

種類ごとに公表の日の順で並べました。日数の順位ではありません。

気づいた日（66件）

外から知らされた日（4件）

委託先の報告を受けた日（9件）

漏えいが分かった日（4件）

止めた日・起きた日（16件）

自社の第1報に、気づいた日と止めた日と漏えいが分かった日を分けて書けるか。次にこの表を作るとき、読み違えようがないのは、その3つが書かれた発表です。