個人情報漏洩はなぜ続くのか──国内の被害一覧と、企業・個人が今確認すること【随時更新】

1. 結論：入口、持ち出し、保有量を一緒に点検する

使っていたサービスから「お客様の個人情報が流出しました」と届く。名前とメールアドレスだけなのか、免許証の画像までなのか。自分の会社にも同じ弱点があるのか。2026年秋のニュースは、その問いを生活と仕事の両方に突きつけている。

企業は、外部から入れる入口、異常な情報取得を見つける監視、不要な情報を残さない保管方針を、同時に確認したい。個人は、公式発表で流出項目を確かめ、パスワードの使い回し解消と二次被害への備えを進める。 対策製品を一つ導入するだけでは、この三つは埋まらない。

IPAは10月9日、外部公開アプリケーションやアカウントの侵害を起点とする傾向を挙げ、経営者に点検を要請した。特定製品の脆弱性が一連の事件の共通原因と断定された段階ではない。^[1]

この記事は2026年10月21日（日本時間）までに確認できた公表情報による整理だ。以下は国内の代表例で、全件を網羅した被害ランキングではない。ニュースで一歩踏み込んで知りたい人と、自社のサービスを点検する担当者に向け、分かったこと、未確定のこと、今できることを分けて読む。

2. 国内の主な事例：発表日・規模・流出項目を分けて読む

「発表された日」「攻撃された日」「発見した日」は異なる。件数にも、会員アカウント、申込データ、予約という違いがある。同じ人が複数サービスを使っているため、各社の数字を足して被害人数にはできない。可能性のある最大範囲を、全件の流出確定とも読まないようにしたい。

タイムズの対象には退会者や入会未完了の人も含まれる。今回の発表対象はタイムズカー等の会員情報であり、「レンタカーを利用した全員」と読み替えない。ローソンの発表項目にもパスワードは挙がっていない。サービスごとに「何が漏れたか」を確認することが、行動の出発点になる。

また、skyticketはカード番号とパスポート画像を自社では保管しておらず、これらの流出を否定している。ただし、カード番号が漏れていなくても、乗っ取られたアカウントで保存済み決済手段を使われる危険は別にある。同社は保存済みカードによる支払いを停止した。データの窃取と、サービスを不正利用されることは、別々に点検する必要がある。^[6]

3. なぜ相次ぐのか：情報の集積と、見える事件の増加

会員登録、本人確認、配送、問い合わせ、決済連携。便利なサービスは、いくつものシステムをつなぎ、その接点に個人情報を置く。一つの入口で得た権限が広すぎれば、侵入者は本来の業務と同じ経路で大量の情報へ到達できる。skyticketの管理機能から他の保管先へ進んだ事例は、入口の修正と権限分離の両方を見る理由になる。

一方、ふるさとチョイスの申込復元では、利用者を識別できない場合に処理を止める確認が不十分だった。ここでは「誰かにログインされた」ことを防ぐ対策だけでは足りない。正規の処理が、別の人の情報を返さないかが問題になる。公表文だけで各社の細かな侵入手口や利用クラウドまで分かるわけではないため、未発表の原因をこの説明から逆算して断定しない。

発表件数は、そのまま発生件数ではない

個人情報保護委員会（PPC）の令和7年度年次報告では、法26条1項に基づく漏えい等報告の処理は17,139件。類型別では要配慮個人情報を含むものが61.9%、不正目的で行われたおそれのあるものが22.3%だった。これはサイバー攻撃による流出だけの集計でも、新聞に出た企業数でもない。^[10]

報告制度が働けば、以前は見えなかった事故が見える。検知や調査の進展で同じ時期に発表が集まることもある。したがって、秋の見出しの多さから攻撃件数の増加率を計算することはできない。

未検知・未報告の事案が存在する可能性はあるが、その規模を「公表の何倍」と推計できる根拠はここでは得られていない。中小企業だから公表しない、大手なら管理が優秀、とも評価できない。公表の有無、侵入前の対策、発覚後の対応は別の評価軸だ。金融機関についても、勘定系・顧客向けWeb・委託先・個人の口座乗っ取りを分けて見る必要があり、業種名だけでは安全性を判定できない。IPAの注意喚起も金融機関を含む幅広い事業者を対象としている。^[1]

4. AIは何を変えたのか：中国製モデルとの関係はどこまで分かったか

手掛かりになるのは、モデルの評判より、実際の攻撃で何が観測されたかだ。CrowdStrikeは10月7日、韓国の金融組織を狙った活動について、攻撃者側の公開ディレクトリからAIツールの設定やセッション履歴などを分析したと報告した。中国で開発されたペネトレーションテスト用ツールARTEXと、複数のLLMを組み合わせた活動である。同社は中国語話者で金銭目的の可能性を中程度の確信度で評価し、既知の攻撃者名には帰属させていない。^[11]

この観測はAI利用の具体例だが、国内一覧の各社を同じ攻撃者が襲った証拠にはならない。10月20日のITmediaによる本人への取材でも、VLCセキュリティラボの中本有哉氏は、国内の直近事件で中国製LLMが使われたことを直接確認していないと補足した。^[12]

AIによって変わりうるのは、調査、試行、結果の整理、次の操作をつなぐコストだ。以前なら途中で手が止まった攻撃を続けやすくなる。これは防御側にとって、放置された管理画面や小さな認可の穴を「見つかりにくいから」と許容しにくくする。

ただし、AIが暗号を万能に破る、MFAが無意味になる、という話ではない。攻撃者の作業が速くなるほど、資産の所在、修正責任者、封じ込めの手順をあらかじめ決めておく価値が高くなる。新しいAI対策製品の検討と並行して、既存の入口と権限を点検することが現実的だ。

5. 企業の点検：SSO・MFAの先にある「この人が、この情報を見てよいか」

認証は誰なのかを確かめること。認可はその人に、その操作や情報への権限があるかを確かめること。SSOはログインをまとめる仕組みで、導入しただけでMFAや個々のデータの認可まで保証されるわけではない。

MFAでは、知っているもの、持っているもの、生体のように異なる要素を組み合わせる。「パスワードの後に秘密の質問」という二つの手順は、知識の確認を重ねているだけだ。企業の管理者や重要サービスでは、FIDO/WebAuthnを用いるパスキーやセキュリティキーなど、フィッシング耐性のある認証を優先したい。CISAもこの移行を推奨している。復旧窓口や例外アカウントが弱いとそこが入口になるため、登録・紛失・退職まで含めて設計する。^[13]

以下は筆者の点検順序の提案であり、各社の侵害原因を推定した表ではない。対象システムの責任者と期限を付け、確認結果を残すために使ってほしい。

利用者A/Bのテストは、OWASPが挙げるオブジェクト単位の認可不備への基本的な確認になる。IDを推測しにくい値に変えるだけでは権限確認の代わりにならない。実データを大量取得して試す必要はなく、自社が許可した範囲とダミーデータで検証する。^[14]

AWSなら、GuardDutyの「有効」から一歩進む

GuardDutyは脅威の兆候を検出するサービスである。導入状況を確認するときは、対象アカウントとリージョン、必要な保護プラン、通知先と対応者まで見る。S3 ProtectionはS3のオブジェクト操作のデータイベントを分析する。基本機能を有効にしたという回答だけで、その保管先の監視範囲を確認し終えない。^[15]

一方、CloudTrailの標準のイベント履歴は、リージョンごとの直近90日の管理イベントで、データイベントは表示しない。証跡等で必要な操作を記録・保持する設計が別に要る。GuardDutyの検出情報と、調査に必要な生の操作記録は用途が違う。^[16]

実務では、S3の公開設定・バケットポリシー、IAMの最小権限、アプリのデータ参照権限、ログ保管の改ざん耐性を確認する。クラウドの正常な権限でアプリが別人の情報を返す不具合は、クラウドの監視だけでは見抜けないことがある。WAF、脆弱性管理、認可テスト、監視を役割別に組み合わせる。

「持たない」は被害の上限を小さくする

パーク24は10月16日、本人確認画像を会員期間中と退会後7年間保有していた運用を見直し、登録完了後は保有しない方針を公表した。既存画像も10月末までに削除する予定である。10月21日時点では予定であり、削除完了とは書けない。^[4]

自社でも「確認に必要」と「確認後も画像のまま必要」を分けたい。法令・契約で必要な記録は残しつつ、不要な免許証画像や退会者データ、分析用コピーを減らす。保存時暗号化も有用だが、復号権限を持つアプリが侵害されれば読まれうる。保有量・アクセス権・保管方法をまとめて見直す。

6. ハッシュ化されたパスワードが漏れたら、すぐ使われるのか

通常のパスワード認証では、入力された値を変換し、保存済みの値と照合する。適切なハッシュ化は元の文字列へ戻す復号手順を持たない。そのため、ハッシュが流出しただけで、元のパスワードがそのまま全員分読めるわけではない。

ただし攻撃者は、候補のパスワードを同じ条件で計算し、結果が一致するか試せる。これがオフラインの推測攻撃だ。短い・よく使われるパスワード、速すぎるハッシュ方式、低い計算コストでは突破されやすくなる。個別のsaltは事前計算や一括照合を困難にし、Argon2idなどのパスワード向け方式は推測一回の負担を増やす。単に「SHA-256でハッシュ化した」では、パスワード保存として十分とは言えない。^[17]

一般的なWebログインは、盗んだハッシュ文字列をパスワード欄に貼れば通るものではない。ただし、認証方式によってはハッシュ相当の値の再利用が攻撃になる場合があり、セッションやトークンの盗難も別にある。「ハッシュだから何もしなくてよい」とまとめるのも不適切だ。

ふるさとチョイスはハッシュ化パスワードの流出を公表し、他サービスで同じメール・パスワードを使う人へ変更を求めた。方式やパラメーターが明示されなければ、第三者が解読所要時間を計算することはできない。タイムズの「復元できない形式」という説明も、具体的な実装が公開されたことと同義ではない。^[9][2]

企業は平文保存を避け、方式・salt・コスト・旧方式からの移行状況を確認する。個人は、解読済みと決めつけず、将来の悪用を減らすために使い回しを解消する。今回確認した資料から、平文保存企業の割合や、国内各社の保存方式の分布までは分からない。

7. 漏洩を知ったとき：個人の行動と企業の報告を整理する

個人は「何が漏れたか」で行動を変える

1. 通知のリンクを踏む前に、公式サイトや公式アプリへ自分で入る。 対象期間・流出項目・対象者の確認方法を読む。安全確認を名目とする別サイトへ、免許証やパスワードを再提出しない。
2. 同じパスワードを使ったサービスを変更する。 メール、金融・決済、主要IDなど影響の大きいものを優先し、個別のパスワードにする。利用可能ならパスキーやMFAを設定。不審なログイン履歴・復旧先・接続アプリを確認し、提供されていれば他セッションを失効させる。
3. 連絡先や利用履歴が漏れたら、内容の詳しい詐欺にも備える。 予約日や住所を知っている相手でも、本人の証明にはならない。「返金」「補償」「緊急の再認証」の連絡は公式窓口から確かめる。
4. カード・口座・本人確認画像は、具体的な異常を記録する。 利用明細や予約変更を確認し、覚えのない取引は金融機関・カード会社へ。免許証画像等の悪用が疑われる場合は、事業者の専用窓口や警察へ相談し、通知・日時・連絡内容を残す。

住所や生年月日はパスワードのように簡単には変えられない。だからこそ、本人確認書類を保管する企業側の責任が重い。金融庁は10月9日、本人確認画像等の流出を踏まえて、金融機関等にセキュリティ点検と各種申込時の不正対策を求めた。画像があるだけで本人と扱わない仕組みを、情報の受け手も強くする必要がある。^[18]

企業は「調査完了まで待つ」を初動にしない

被害が疑われたら責任者を決め、侵害経路の遮断、ログや端末等の証拠保全、影響範囲の把握、専門家・委託元等への連絡を並行する。調査前の一括初期化やログ削除で原因を追えなくしない。窃取の疑いと確定、分かっている項目と未確認項目を分けた時系列を作る。

民間事業者の法定報告では、要配慮個人情報、財産被害のおそれ、不正目的の行為のおそれ、1,000人を超える規模などが報告対象の判断に関わる。対象事態を知ったら速報は速やかに（目安3〜5日）、確報は原則30日以内、不正目的のおそれがある類型は60日以内。本人通知も原則必要で、状況に応じ速やかに行う。^[19]

PPC等への報告、本人への通知、Webサイトでの公表は別の行為である。「すべての事件を3日以内に一般公表する法律」とは整理できない。本人への通知が困難で代替措置を取る場合や、業種別の規制・報告先もある。個別の適用は法務・専門家と確認する。報告義務は大企業だけのものではなく、規模だけで対象外にはならない。^[20]

8. 今後の見通し：攻撃の速さに、点検と封じ込めの速さで備える

ここからは公表事例を踏まえた予測だ。今後6〜12か月は、AIで効率化した探索と、既知の弱点や認可不備の組み合わせに警戒したい。漏れた連絡先や利用履歴を使い、もっともらしい案内を作る二次被害も、備えるべきシナリオになる。ただし、被害件数が何倍になるかを信頼できる数字で示すことはできない。

防御の評価も「製品が入っているか」から、「見つけて止めるところまで動くか」へ進めたい。筆者なら、未把握の外部公開数、管理者MFAの例外数、悪用中の脆弱性を放置した時間、通知から対応開始までの時間、不要な個人情報の残存量を継続して見る。弱点を直し、権限を絞り、異常を拾い、不要なデータを減らすほど、攻撃が成功する機会と被害の上限を小さくできる。

今日の着手は小さくてよい。個人なら最も重要なIDの使い回しを一つ解消する。企業なら、外部公開サービスの一覧と責任者を揃え、一つのアラートが担当者まで届くか確かめる。対策を重ねればリスクは下げられる。その安心は、「絶対に漏れない」という約束ではなく、実際に確かめた運用から作れる。

更新履歴：2026年10月21日初版。 国内事例、AI利用の観測、報告制度、技術・個人の対策を整理。続報では件数・流出項目・原因・対策を更新する。次の確認点はタイムズが10月23日に予定する案内と10月末の画像削除、ふるさとチョイスの調査・再開情報など。この記事は一般的な解説で、個別の事故調査や法的判断に代わるものではない。

参考文献・出典

1. [1]IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」（2026-10-09）。https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html ↩
2. [2]パーク24「タイムズカーWebシステム…第2報」（2026-09-28）。https://www.park24.co.jp/news/2026/09/20260928-1.html ↩
3. [3]パーク24「同・第3報」（2026-09-29）。https://www.park24.co.jp/news/2026/09/20260929-1.html ↩
4. [4]パーク24「同・第4報」（2026-10-16）。https://www.park24.co.jp/news/2026/10/20261016-1.html ↩
5. [5]ローソン「第三者による不正アクセスに伴う個人情報漏えいに関するお詫びとお知らせ」（2026-10-08、10-19更新）。https://www.lawson.co.jp/contents/cont07/1533174_3310.html ↩
6. [6]アドベンチャー「不正アクセスによるお客様情報の流出に関するお詫びとお知らせ」（2026-10-09）。https://skyticket.jp/news/maintenance/67603 ↩
7. [7]ソースネクスト「当社サイトへの不正アクセスによるお客様情報流出のお詫びとお知らせ」（2026-10-15）。https://www.sourcenext.com/support/i/2026/1015_info/ ↩
8. [8]トラストバンク「『ふるさとチョイス』における個人情報の漏えいに関するお詫びとお知らせ」（2026-10-05）。https://www.trustbank.co.jp/newsroom/news/news261005/ ↩
9. [9]トラストバンク「不正アクセスによる寄附者様情報の外部流出に関するお詫びとお知らせ」（2026-10-20）。https://www.trustbank.co.jp/newsroom/newsrelease/news261020/ ↩
10. [10]個人情報保護委員会「令和7年度年次報告」。https://www.ppc.go.jp/aboutus/report/annual_report_2025/ ↩
11. [11]CrowdStrike, “Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance” (2026-10-07). https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/ ↩
12. [12]ITmedia AI＋「『どの国のモデルか』は本質ではない」（専門家本人への取材、2026-10-20）。https://www.itmedia.co.jp/aiplus/article/2610/20/2000002430/ ↩
13. [13]CISA, “Require Multifactor Authentication.” https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/require-multifactor-authentication ↩
14. [14]OWASP, “API1:2023 Broken Object Level Authorization.” https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/ ↩
15. [15]AWS, “GuardDuty S3 Protection.” https://docs.aws.amazon.com/guardduty/latest/ug/s3-protection.html ↩
16. [16]AWS, “Working with CloudTrail event history.” https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html ↩
17. [17]OWASP, “Password Storage Cheat Sheet.” https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html ↩
18. [18]金融庁「現下の情勢を踏まえたサイバーセキュリティ対策の強化と各種取引申込等における対応について」（2026-10-09）。https://www.fsa.go.jp/news/r8/sonota/20261009/20261009.html ↩
19. [19]個人情報保護委員会「漏えい等の対応とお役立ち資料」。https://www.ppc.go.jp/personalinfo/legal/leakAction/ ↩
20. [20]個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」3-5。https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ ↩