メインコンテンツへスキップ
見出し画像

情報の「漏えい」について調べてみました

    「また個人情報の漏えいか」最近そんなニュースを何度も目にしませんか。4日前に数えた数字がもう古くなっていた。そのたびに「何百万件」「何千万人」といった数字が出てきます。でもその数字が何を数えたものなのか、ちゃんと説明されることはあまりありません。また漏えいの件数は単純には「足し算」はできません。

    主要な漏えい事案を数えた記事を書いたのですが、数え直してみるともっと大事なことが見えてきました。この記事では数え直しで分かったことと、同じ週に公表されたPHPの脆弱性のニュースを材料にこのことを順に見ていきます。

    結局日本でどれくらい漏れているのか

    知りたいのはたぶんこの一点です「日本で今どれくらい漏れているのか」
    全国の目安になる数字はあります。

    MM総研の調査では2026年10月13日時点で485事案。これは2026年分の件数で過去からの累計ではありません。1〜9月だけで454件、前年の同じ時期より49%増えたとされています。100万件以上の事案は19件で過去5年で最多です。

    ただしここで一つ注意があります。この485という数字の単位は「事案数」です。たとえば複数の会社が同じ委託先やサービスを使っていて、そこが攻撃されたら数え方としては1事案です。また漏えいの「可能性」の段階で数えた事案も含まれています。後から「漏えいは確認できなかった」となったものも含みます。

    つまり485は「今年これだけの騒ぎがあった」という全国の目安であって、「これだけの人が被害に遭った」という数字ではありません。なお私が数えたものはこの485の中のごく一部の主要事案です。全国の集計ではありません。

    前回の4件が今回は8件になった

    では主要事案の規模はどう数えればいいのか。私は公式発表を読み直して規模が公表されている主要事案を数え直しました。前回の記事で数えたのは4事案で合計は31,776,262。約3,178万です。今回、同じ基準で数え直すと8事案になり合計は62,676,359。約6,268万になりました。

    増えた分の中身を見るとここが少しややこしいところです。トラストバンク(ふるさとチョイス)とH2Oリテイリング(H2O ID)は、10月19日と20日に新しく公表されたものです。一方Eストアーと日本経済新聞社は10月16日の公表で、前回の私の調査が拾えていなかったものです。

    要するに世界が3,090万分も動いたわけではありません。数日間の新しい公表と前回の拾い漏れが混ざっています。数字は数える日と数え方によって簡単に変わります。

    主な8事案は次のとおりです。単位は各社の公表のままです。

    ・Eストアー ショップサーブ 8月1日(最終10月16日) 約23,356,000人
    ・KDDI ISP向けメール 7月6日(7月21日更新) 12,231,954(メールアドレス)
    ・物語コーポレーション 焼肉きんぐアプリ 10月5日 10,788,963件
    ・パーク24 タイムズカー 9月28日 約6,600,000アカウント
    ・トラストバンク ふるさとチョイス 10月20日 4,454,097件
    ・ローソン ローソンID 10月8日 2,155,345件
    ・日本経済新聞社 開発用クラウド 10月16日 約1,830,000件(大半は個人を特定しないID)
    ・H2Oリテイリング H2O ID 10月19日 約1,260,000件

    この合計は主要事案の延べ公表対象規模です。全国の総数でも被害者のユニークな人数でもありません。

    単位がそろっていない

    表を見ると単位がばらばらです。「人」「アカウント」「件」「メールアドレス」。単位別に分けると人が23,356,000、アカウントが6,600,000、件が20,488,405、メールアドレスが12,231,954です。

    1人が複数のサービスに登録していることは普通にあります。1人が複数のメールアドレスやアカウントを持つこともあります。だから単純に「6,268万人が被害に遭った」とは言えません。人に換算することもできません。

    中に入れ子の数字がある

    KDDIの発表ではメールアドレスの漏えいが12,231,954名分、パスワードが7,616,173名分とされています。このパスワードの数はメールアドレスの数の内数です。足すと二重に数えてしまいます。

    確定と可能性が混ざっている

    さらに同じ「漏えい」でも確度が違います。H2OリテイリングはH2O IDの約126万件の漏えいを発表しましたが、同時にHANKYU HANSHIN E-STORESとRemo Orderについては漏えいの可能性を調査中とし件数は出していません。これは126万件に足せません。

    ソースネクストは22,519,960件が「流出した可能性」があると公式に発表しています。ほかにも可能性や調査中の事案がいくつもありそれらをかき集めると約4,151万になります。ただし最大値や累計が混ざった数字で実際に持ち出されたデータの数ではありません。

    NECの事案は委託先がサイバー攻撃を受け、盗まれた正規のアカウント情報が悪用されて、顧客の環境にあるクラウド上のファイルが漏れたと発表されました。ただ個人情報の詳しい件数は公表されていません。件数がない事案に、こちらで推測の数字を付けることはしません。

    報道だけで伝わっている大型事案

    10月22日にはCAPCOMの事案が報じられました。ITmedia NEWS、INTERNET Watch、ファミ通はCAPCOM IDへの不正アクセスで全世界合計11,774,247件のメールアドレス等が対象になったと伝えています。
    Burger King Japanについても、Impress WatchやinnovaTopiaがアプリ会員の約1,118万件と報じています。報道情報として紹介するにとどめ上の合計には入れていません。

    同じ週に出たPHPの脆弱性

    数字を整理しているさなかにもう一つ大きなニュースが出ました。10月21日、PHP(多くのWebサイトで使われているプログラミング言語)の新しい版が公開され二つの脆弱性が修正されました。「PHP2Shell」という名前で報じられています。

    PHPのプロジェクトは認証なしで外部からプログラムを実行されうる問題だと説明しています。また完全な回避策はなく更新が唯一の安全策だとしています。これは重い話です。

    ここで混ざりやすいことが三つあります。
    一つ目は、穴があるということ。
    二つ目は、その穴を狙った攻撃が観測されたということ。
    三つ目は、実際に情報が漏れたと確認されたということ。
    この三つは別の話です。

    Cloudflareは公開前から顧客を狙う攻撃トラフィックを観測したとして、10月21日に防御機能の提供を始めました。ただし具体的な漏えい事案の報告はないとしています。Help Net SecurityはAmazonの観測システムが10月17日に悪用の試みを記録したと報じました。こちらも確認された情報漏えいはないと伝えています。つまり「穴は見つかり攻撃の気配も観測された。でも漏えいの確認は今のところない」というのが現状です。

    そして先ほどの国内の事案のどれかがPHP2Shellによるものだと示す資料は私の手元にはありません。たとえばKDDIの原因は「第三者製ソフトの脆弱性」と発表されていますが、それがPHPと関係あるのかどうかは分かりません。

    数字が足せないことが教えてくれること

    ここまでで二つのことが言えます。一つは数字は日付と単位と確度がそろって初めて意味を持つということ。もう一つは「穴の存在」と「漏えいの確認」はつなげて読むと誤解のもとだということです。

    もう少し踏み込むとこう考えられます。公表されている事案を見ると規模を決めているのは侵入口の種類よりも、一つのシステムにどれだけ集まっていたかのように見えます。H2Oリテイリングの発表はほぼ全H2O ID会員の個人情報の一部が漏れたとしています。原因が公表されている事案が少ないので断定はできません。ただそう見えるということは言えそうです。

    NECの事案も示唆的です。盗まれた正規の認証情報が使われたと発表されています。これは「ソフトの穴」とは別の入口です。企業が対策を怠ったと言いたいわけではありません。ただパッチを当てればすべて解決という話ではないということです。

    私たちは何をすればいいか

    私はここでこう考えます。パッチは必要です。PHP2Shellのように更新が唯一の安全策とされる場面ではなおさらです。
    でもセキュリティはそこで終わりではありません。侵入されたとしても全部には届かない設計。そもそも持つデータを減らす設計。そこまでを含めてセキュリティだと私は思います。
    読者のみなさんの立場に引き寄せて四つにまとめます。

    1. 数字を見たらまず単位を見る。 人なのか、アカウントなのか、件なのか、メールアドレスなのか。確定なのか可能性なのか。単位と確度が書かれていない合計はそのまま信じないほうがよさそうです。

    2. 数字は日付つきで読む。 初報の後に続報があり件数が変わることもあります。今回の数え直しがまさにそうでした。

    3. 脆弱性のニュースは穴・攻撃・漏えいに分けて読む。 自社のサイトや仕事を任せている委託先がPHPを使っているなら更新されているかを確認する。ここまでは必須です。でも「漏れた」と決めつけることはしません。

    4. サービスを運営する側なら持たない・分ける・見張る。 私は次の四つが要だと考えます。
      ・保持期間を決めて古いデータは消す
      ・権限を絞って必要な人にだけ見せる
      ・システムを分けて一か所が破られても全体に届かないようにする
      ・一度に大量のデータを取り出すといった異常を検知する

    AIエージェント(人の代わりに作業を進めるAI)を使い始めた人にも同じことが言えます。AIにすべての情報と権限を渡してしまえば、AIが侵入や誤作動に巻き込まれたとき届く範囲もそのぶん広くなります。AIにも人と同じ境界の設計が要ります。

    おわりに

    4日前に数えた数字はもう古くなっていました。その数字を数え直すと今度は足し算できないことが見えてきました。「日本でどれだけ漏れたのか」は実は簡単には答えが出ない問いでした。だからこそ数字の大きさに驚くだけでなく数字の中身に目を向けたいと思います。

    守る技術だけでなく漏れたときの量を小さくする設計まで。それがセキュリティの1つなのだと私は考えています。


    参考資料

    MM総研: https://www.m2ri.jp/release/detail.html?id=741
    KDDI: https://newsroom.kddi.com/news/assets/2026/kddi_nr_s-73_4619/kddi_nr_s-73_4619_pdf_01.pdf
    H2Oリテイリング: https://www.h2o-retailing.co.jp/ja/news/auto_20261019552921.html
    NEC: https://jpn.nec.com/news/info/20261020.html
    Eストアー: https://estore.jp/press/20261016/
    物語コーポレーション: https://www.yakiniku-king.jp/news/6875/
    タイムズカー: https://share.timescar.jp/news/2026/0928/1815.html
    トラストバンク: https://www.trustbank.co.jp/newsroom/newsrelease/news261020/
    ローソン: https://www.lawson.co.jp/contents/cont07/1533174_3310.html
    日本経済新聞社: https://www.nikkei.co.jp/nikkeiinfo/news/information/1561.html
    ソースネクスト: https://www.sourcenext.com/support/i/2026/1015_info/
    PHPプロジェクト: https://github.com/php/php-src/releases/tag/php-8.5.12
    Cloudflare: https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
    Help Net Security: https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
    ITmedia NEWS(CAPCOM報道): https://www.itmedia.co.jp/news/article/2610/22/2000002523/
    Impress Watch(Burger King報道): https://www.watch.impress.co.jp/docs/news/2148486.html


    関連記事

    注目の記事


     
     
    藤浪瞬輝です。AIを用いた独自研究・構造分析・思考実験。創作、認知、社会構造、未来仮説について、個人研究ノートとして記録しています。また自身に必要な知識もAIを活用して作成しています。現在はセキュリティアプリを構築中です。

    あなたへのおすすめ