止まらない情報漏えい、半年で延べ2億6000万人　10月の新事例と、利用者・開発者が今すぐ見直すこと

2026年10月28日、個人情報保護委員会は衝撃的な数字を公表しました。2026年4月1日から10月16日までの約半年間に、不正アクセスによる個人情報の漏えい（またはそのおそれ）として報告された対象者は延べ約2億6000万人。日本の総人口の2倍を超える規模です。

しかも勢いは衰えるどころか加速しています。10月に入ってからも、無印良品、佐川急便、ソースネクスト、カプコン、楽天トラベル、JAL・ANA、松屋と、誰もが一度は使ったことのあるサービスで公表が続きました。今回は、10月に新たに明らかになった主な漏えいを整理したうえで、利用者としてできる対策と、サービスを作る・運用する側が見直すべきことをまとめます。

数字で見る「止まらない」状況

個人情報保護委員会の資料によると、期間中の報告件数は合計2094件。月別に見ると、10月の伸び方が突出しています。

月	報告件数	1日あたりの目安
2026年4月	166件	約6件
5月	163件	約5件
6月	185件	約6件
7月	212件	約7件
8月	235件	約8件
9月	303件	約10件
10月（16日まで）	830件	約52件

10月は半月だけで9月の約2.7倍、期間全体の約4割を占めました。1日あたりの報告件数も9月の5倍以上です。

ただし、数字の読み方には注意が必要です。2億6000万人は重複を含む延べ人数で、同じ人が複数のサービスで数えられています。また「漏えいのおそれ」の段階の事案も含み、集計対象は民間事業者から委員会へ直接報告されたものだけです。所管省庁経由の報告や行政機関の事案は含まれていないため、実態はむしろこれより広いと考えたほうがよいでしょう。

10月に新たに公表された主な漏えい

10月上旬までの事例（焼肉きんぐ、タイムズカー、デジタル庁GSSなど）は以前の記事で整理したので、ここではそれ以降に公表・続報があった主なものを新しい順に並べます。件数・人数・アカウント数は単位が異なり、「漏えい確認」と「可能性」も混在するため、合算はできません。

公表日	組織・サービス	規模	主な対象情報	経路・原因
10/30	良品計画「MUJIアプリ」	最大約2726万件	メールアドレス、生年月日、性別（退会者も含む）	外部からの不正アクセス
10/30	松屋フーズ公式アプリ	約238万件	会員ID、氏名、電話番号、届け先住所など	アプリ管理システムへの不正アクセス（原因調査中）
10/29	グッドスマイルカンパニー公式ショップ	カード全桁＋セキュリティコード2800人、下4桁40万2466枚	カード番号、有効期限、セキュリティコード、注文者情報	脆弱性悪用で管理者権限を奪取、決済ページに不正プログラム設置
10/28〜29	JAL・JTA／ANA	JAL・JTAで約9万2000人（うち約2000人はパスポート番号も）、ANAは調査中	予約情報	共通の旅客サービスシステム提供元（Amadeus）経由
10/28	花キューピット	最大約423万件	ユーザーID、ハッシュ化パスワード、メールアドレス（退会者も含む）	システムへの不正アクセス
10/27	資さん（資さんうどん）	報道では約2万人	従業員・退職者の氏名、賃金履歴、一部は退職理由	委託先が運用する勤怠システムの設定不備
10/26	楽天トラベル（海外・多言語予約サイト）	最大約260万件、うちカード情報の一部約3.6万件	氏名、メール、電話番号、カード下4桁・有効期限	予約サイトへの不正アクセス（9月に異常検知）
10/23	佐川急便	最大約5323万件	約100日分の送り主・届け先の氏名、住所、電話番号など	荷物問い合わせサービスへの不正アクセス（9/30発覚）
10/22	カプコン「CAPCOM ID」	1177万件	メールアドレス、ログイン履歴など	不正アクセス
10/21〜	GMOインターネット「お名前.com デスクトップクラウド」	調査中	利用者の金銭被害、攻撃者による顧客情報らしきものの公開	FX自動売買用VPSへの不正アクセス、金銭要求
10/20〜	NECの委託先	大阪大学で約7万8000人など	卒業生・在学生・教職員の個人情報など	委託先の正規アカウント認証情報を悪用
10/16	ヤマト運輸「クロネコ代金後払い」	約531万件	氏名、住所、電話番号、商品明細など	不正アクセスによる持ち出し
10/15	ソースネクスト	約2252万件	氏名、メール、住所、パスワードなど	会員情報取得APIの不正利用（4日間気づかず）

このほかにも、メール配信サービスのユミルリンク（約900万件、影響はJR「スマートEX」やバンダイナムコのガンダムグッズ店の会員などに波及）、ジョーシン（最大623万件）、ブックオフ（最大約643万件）、バーガーキング（約1118万件）、So-net（約259万件）、コミックシーモア（最大約420万件）、日本経済新聞（183万件、開発用クラウドの認証情報が盗まれた）など、10月だけで数百万件規模の公表が相次いでいます。

10月の事例から見える6つの特徴

1. 退会者・退職者のデータまで漏れている

無印良品と花キューピットは退会済みの会員も対象に含まれました。資さんうどんでは5年分の在籍者、つまり退職者の情報が閲覧可能な状態でした。「もう使っていないサービスだから関係ない」とは言えないのが現実です。持ち続ける必要のないデータを持ち続けていたことが、被害の規模を押し上げています。

2. 入口は「APIと管理画面」

ソースネクストでは会員情報を取得するためのAPIが不正に使われ、約2252万件が抜き取られました。グッドスマイルカンパニーでは脆弱性を突かれて管理者権限を奪われ、決済ページそのものを書き換えられています。IDCFクラウドのランサムウェア被害も、外部からアクセスできるポータルの認証システムで使っていたOSSの脆弱性が起点でした。表のフロントだけでなく、裏口として作ったAPIや管理機能が狙われています。

3. 共通基盤・委託先からの「連鎖」

JALとANA、さらに韓国の大韓航空・アシアナ航空は、同じ旅客サービスシステム（Amadeus）を経由して被害を受けました。IDCFクラウドでは495の企業・自治体が影響を受け、ユミルリンクの件でも複数社に波及しています。自社のシステムが堅くても、預け先が破られれば自社の顧客の情報が漏れる構図です。

4. 決済ページの改ざんでカード全桁が流出

グッドスマイルカンパニーの事例では、決済ページに約1日半にわたって不正なプログラムが仕込まれ、入力されたカード番号の全桁とセキュリティコードが漏れた可能性があります。サーバーにカード情報を保存していなくても、入力画面を書き換えられれば盗まれる点は、EC事業者にとって重い教訓です。操作記録が残っておらず、対象者を絞り込めなかったことも課題として残りました。

5. 「漏えい」で終わらず、金銭被害・脅迫へ

GMOのFX自動売買用VPSの件では、利用者から金銭的損失の報告が相次ぎ、攻撃者が身代金を要求したうえで顧客情報らしきものを公開しました。別の経路ですが、PayPayに連携した銀行口座から不正送金される被害も8月ごろから増えています。漏えいした情報は、その後のフィッシングや詐欺の「材料」になります。

6. 背景にAIによる攻撃の高速化

ラックの倉持浩明CTOは10月28日の講演で、「対策を後回しにしたサーバが軒並み狙われている」と指摘しました。脆弱性診断を先送りしたサーバ、WAFを入れていないシステム、古いPHPを使い続けているシステムなどです。AIによって公開サーバの偵察コストが大きく下がり、脆弱性の発見から攻撃への転用までの速度も上がっているといいます。10月に緊急対応が必要になったPHPの重大な脆弱性も、AIを使って発見されたものでした。

一方で倉持CTOは、AIでまったく新しい問題が生まれたわけではなく、これまで見逃されていた弱点がAIによって次々と見つかるようになったのだとも述べています。つまり、対策の中心は相変わらず「基本」です。

ユーザーとしてできる対策

サービス側の漏えいを利用者が防ぐことはできません。できるのは、漏れても被害につながらない状態を作っておくことと、漏れた後の二次被害を避けることです。

漏えいの連絡が来たら：情報の種類ごとの対処

IPA（情報処理推進機構）が10月26日に公開した対処法をもとに、漏れた情報の種類ごとにやるべきことを整理しました。まずはサービス側の公式発表で、自分のどの情報が対象かを確認しましょう。

漏れた情報	想定されるリスク	やること
メールアドレス、電話番号、氏名、住所	フィッシングメール、詐欺SMS・電話	突然届くメールやSMSは基本的に詐欺と考え、リンクを開かず削除。アプリのインストールや情報入力をしない
ID・パスワード	不正ログイン	該当サービスのパスワードを長く複雑なものに変更。同じパスワードを使い回している他のサービスもすべて変更
クレジットカード情報	不正決済	カード会社に連絡し、利用停止・再発行を相談。当面は利用明細をこまめに確認
運転免許証などの本人確認書類	なりすましでのカード・ローン契約	信用情報機関（JICC、CIC、KSC）への本人申告を検討

「お詫びメール」を装ったフィッシングに注意

大規模な漏えいの後は、その企業を装った「お詫び」「パスワード再設定のお願い」「補償金のお知らせ」といった偽メールが増えます。ソースネクストの件では、本物の再設定メールすら「詐欺に見えて開けない」という声が上がりました。

メールやSMSのリンクからはログインしない。公式アプリか、自分で登録したブックマークから開く
「当社からパスワードやカード番号を尋ねることはない」と明記している企業がほとんど。入力を求められたら疑う
電話で「漏えいの件で」と言われても、その場で個人情報を答えず、公式サイトに載っている番号へかけ直す

AIによってフィッシングの精度も上がっています。ベルリン工科大学などの研究チームが大学職員を対象に行った実験では、ネット上の公開情報からAIがその人専用の文面を作ったメールのクリック率は10%で、一律の文面（3.9%）の約2.7倍でした。大学のメールフィルターではほぼ検知されなかったといいます。「怪しい日本語だから見抜ける」という時代は終わったと考えたほうが安全です。

スマホと決済まわりの守り

アプリはGoogle Play／App Storeからだけ入れる。PayPayは、偽アプリ経由のマルウェア感染で端末を遠隔操作され、不正送金される被害を確認しています
見知らぬアプリにアクセシビリティ権限や端末の遠隔操作を許可しない
決済アプリと銀行口座の連携は本当に必要か見直し、利用通知（プッシュ・メール）をオンにしておく
ネットショップにはカード情報をなるべく保存しない。使い捨て番号を発行できるバーチャルカードも選択肢

日ごろからの備え

パスワードを使い回さない。覚えきれないならパスワードマネージャーに任せる
パスキーや多要素認証が使えるサービスでは必ず設定する。パスワードが漏れても、それだけではログインされなくなる
サービスに登録する情報は必要最小限に。生年月日や住所が必須でないなら入れない
使わなくなったアカウントは削除する。ただし今回のように退会後もデータが残っているケースがあるため、退会前に任意項目を消しておくと被害を小さくできる
サービス用と個人のやりとり用でメールアドレスを分けておくと、フィッシングに気づきやすい

開発・運用側で見直すべきこと

ここからはサービスを作る側、運用する側の話です。内閣官房国家サイバー統括室は10月9日、「いつ攻撃を受けてもおかしくない」前提での対策を事業者に求め、Webシステムの管理、サプライチェーン対策、データ管理の3分野でポイントを示しました。ラックの倉持CTOも、重要なシステムから順に守るという守る側の都合は攻撃者には通用しないと警鐘を鳴らしています。攻撃者は公開されている弱い場所から入り、そこを足場に重要なシステムへ進むからです。10月の事例を踏まえ、見直したいポイントを7つに整理します。

1. 公開面の棚卸しと「パッチの速さ」

インターネットから届くサーバ、管理画面、API、検証環境を一覧にすることが出発点です。そのうえで、脆弱性の公表から適用までの時間を縮める必要があります。月1回の定期メンテナンスでまとめて更新する運用では、AIで高速化した攻撃に間に合わない可能性があると倉持CTOは指摘しています。PHPの脆弱性では、31市町村がサイトの一時停止を続けている（10月30日報道時点）ように、すぐに直せる体制がないと「止めるしかない」状況に追い込まれます。

使っているOSS・ライブラリをSBOM（ソフトウェア部品表）で管理し、脆弱性情報との突き合わせを自動化する（IDCフロンティアも再発防止策として採用）
サポート切れのPHPやCMSを使い続けない。予算がないなら、まず公開を止める判断も含めて検討する
「重要度が低いから」とWAFや脆弱性診断の対象から外したシステムこそ、改めて見直す

2. APIと管理画面を「裏口」にしない

ソースネクストの具体的な手口は公表されていませんが、一般論として、会員情報を返すAPIでは「誰が・誰の情報を・どれだけ取れるか」の設計がそのまま漏えい量を決めます。よくある落とし穴は、リクエストに含まれるIDを信じて、ログイン中の本人以外の情報まで返してしまう実装です。

// NG：IDさえ分かれば誰の会員情報でも返してしまう
GET /api/members/{id}   →  return db.findMember(id)

// OK：ログイン中の本人の情報だけを返す
GET /api/members/me     →  return db.findMember(session.userId)

// 管理用の一括取得APIは、外部から呼べる場所に置かない

そのうえで、管理画面や内部用APIは接続元を絞り、呼び出し回数にも上限を設けておくと、万一突破されたときの被害を小さくできます。以下はnginxでの一例です。

# 管理画面は社内・VPNのIPからのみ許可
location /admin/ {
    allow 203.0.113.0/24;
    deny  all;
}

# 会員情報APIは1IPあたりの呼び出し回数を制限
# （limit_req_zone は http ブロックに記述）
limit_req_zone $binary_remote_addr zone=member_api:10m rate=5r/s;

location /api/members/ {
    limit_req zone=member_api burst=10 nodelay;
}

IP単位の制限は、分散した攻撃には効きにくい「最後の砦」です。本命はあくまで認可の設計と、管理者アカウントへの多要素認証の必須化です。IDCフロンティアは再構築にあたり、侵入口となった認証システムを外部のIDプロバイダー（IdP）に切り替え、接続元IPの制限と多要素認証の必須化を決めています。

3. 決済ページの改ざんを前提にする

グッドスマイルカンパニーの事例は、カード情報を保存しない「非保持化」だけでは足りないことを示しました。決済ページ自体が書き換えられると、入力された瞬間に盗まれるからです。

カード入力は、決済代行会社のページへ遷移する方式（リダイレクト型）や、代行会社が提供する入力フォームに任せ、自社ページで番号を扱わない
決済ページで読み込むスクリプトを一覧化し、Content-Security-Policy（CSP）やSubresource Integrity（SRI）で想定外のスクリプトを動かさない。PCI DSS v4.0でも決済ページのスクリプト管理と改ざん検知が求められている
ページやファイルの改ざん検知を入れ、管理画面の操作ログを残す。ログがなければ、漏えい対象を絞り込めず「全員を対象」とするしかなくなる

4. 持たないデータは漏れない

10月の大規模事例の多くで、退会者・退職者・過去分のデータが規模を膨らませました。データ設計の段階で「いつ消すか」を決めておくことが、最もコストの低い漏えい対策です。

退会・退職の時点で、法令上の保存義務がない項目は削除または匿名化する
「とりあえず必須」にしている入力項目（生年月日、性別、住所など）を本当に使っているか見直す
パスワードは平文や可逆暗号で保存せず、bcryptやArgon2などのパスワード専用ハッシュで保存する
本番データを開発・検証環境にコピーしない。必要ならマスキングしたデータを使う

5. 盗まれた「正規の鍵」を使わせない

ラックは、従業員のPCのブラウザに保存されたID・パスワードを盗む「インフォスティーラー」の活動を多数観測しているといいます。NECの委託先の事例では正規アカウントの認証情報が悪用され、日本経済新聞では開発用クラウドの認証情報が盗まれました。脆弱性を突かずに正面から入られるため、外部からの攻撃を見張る仕組みだけでは気づけません。

クラウドの管理コンソール、ソースコード管理、委託先が使う保守アカウントには多要素認証を必須にする
APIキーやアクセスキーはソースコードや設定ファイルに埋め込まず、シークレット管理サービスで保管し、期限付きのものに置き換える
業務用の認証情報をブラウザに保存させない運用ルールと、端末側のEDRをセットで導入する

6. 委託先・共通基盤を「自社の一部」として扱う

資さんうどんの件は、委託先が自主点検で設定不備に気づいたものでした。逆に言えば、点検がなければ気づかれないままだった可能性があります。国家サイバー統括室も、委託先の対策状況を契約時だけでなく継続的に確認することを求めています。

個人情報を預けている委託先・SaaSを一覧にし、定期的にセキュリティ状況を確認する
事故時の報告期限、業務終了後のデータ削除を契約に明記する
大阪大学の件では、NECが大学に報告しないまま協力会社とファイルを共有していました。再委託やデータの共有先を、委託元が把握できる仕組みにする
クラウドストレージやデータベースの公開設定・アクセス権限を、定期的に自動チェックする

7. 侵入を前提に「早く気づく」

ソースネクストは不正アクセスに4日間気づかず、楽天トラベルでは9月に検知した異常が顧客情報への不正アクセスだと判明するまでに時間がかかりました。ラックの監視センターでは、重大インシデントの大半を社内から外部に向かう不審な通信をきっかけに検知しているそうです。

端末だけでなくサーバにもEDRを入れる
大量のレコード取得、深夜の管理者ログイン、外向きの大きな通信にアラートを設定する
ログは攻撃者に消されないよう別の場所に送り、侵入初期までさかのぼれる期間を保存する
共通の仮想化基盤を使っている場合、1台への侵入がどこまで広がるかをペネトレーションテストで事前に確かめる

番外：お知らせの出し方も「設計」する

漏えい後の通知メールにリンクを入れると、それを真似た偽メールとの区別がつかなくなります。リンクは入れずに「公式アプリまたは公式サイトから確認してください」と案内し、公式サイトに固定のお知らせページを用意する。こうした通知のテンプレートも、事故が起きる前に決めておくべき項目です。

まとめ

半年で延べ2億6000万人という数字は、もはや「自分の情報はどこかで漏れている」ことを前提に暮らす時代に入ったことを示しています。利用者としては、パスワードの使い回しをやめてパスキーや多要素認証に切り替え、漏えい後に届く「それらしいメール」を疑うことが最大の防御になります。

サービスを作る側にとって、10月の事例が突きつけているのは目新しい攻撃ではなく、後回しにしてきた基本です。公開面の棚卸しとパッチの速さ、APIと管理画面の認可、持たなくていいデータの削除、委託先の管理、そして侵入に早く気づく仕組み。AIで攻撃者の探索が速くなった今、「いつかやる」は「いつか狙われる」とほぼ同じ意味になりつつあります。

本記事は、個人情報保護委員会の公表資料、各社の発表、ITmedia NEWSなどの報道（2026年10月31日時点の情報）をもとに整理したものです。件数や原因は各社の調査の進展により変わる可能性があります。対象となるサービスを利用している方は、必ず各社の公式発表をご確認ください。コード例は説明用の一般的な例であり、実際の環境に合わせて調整が必要です。