2026年10月22日
2026年9月から10月にかけて、日本国内で大規模な個人情報漏洩や不正アクセスの公表が相次ぎました。

わずか約2週間で33事案、対象規模の単純合計は延べ約1億3,000万件。
Gyazo、タイムズカー、焼肉きんぐ、ローソン、skyticket、ソースネクストなど、私たちの生活に身近なサービスも含まれています。
なぜ、これほど多くの企業で情報漏洩が問題になっているのでしょうか。
背景には、企業による大量の個人情報の保管、システムの複雑化、APIの安全管理、外部委託先のリスクなど、さまざまな課題があります。
さらに、AIを悪用したサイバー攻撃の確認、タイムズカーをめぐる集団訴訟の動き、一般には公表されていない情報漏洩の可能性など、問題は技術面だけにとどまりません。
本記事では、2026年9〜10月に公表された主な17社の事例を整理し、情報漏洩が相次ぐ原因、AI攻撃の実態、企業の法的責任、日本の情報公開制度、企業と個人が取るべき対策を、18枚のオリジナル図解とともに詳しく解説します。
※約1億3,000万件は延べ対象件数の単純合計であり、実際に流出した人数や確定被害件数を意味するものではありません。
情報基準日:2026年10月22日
① 日本で情報漏洩が相次ぐ!何が起きているのか?

2026年9〜10月の一連の公表事案が注目された理由は、対象企業の知名度だけではありません。
利用者が日常的に使っているサービスの裏側に、大量の個人情報が蓄積されている実態が、改めて明らかになったためです。
会員登録時に入力した氏名、メールアドレス、電話番号、住所などは、一つひとつを見るとありふれた情報に思えるかもしれません。
しかし、これらが組み合わさると、本人を特定したり、もっともらしい詐欺メールを作成したりするための材料になり得ます。
さらに、サービスによっては、運転免許証などの本人確認書類、予約履歴、利用履歴、認証に関わる情報も保管されています。
問題は、企業が大量の情報を持っていること自体ではありません。
本当に必要な情報だけを収集しているか、必要な期間だけ保管しているか、第三者が大量に取得できない設計になっているかという点です。
サイバー攻撃は以前から存在します。
今回の事案をもって、日本のすべての企業で攻撃が急増したと断定することはできません。
公表が特定の時期に集中したことと、実際の攻撃発生日が集中したことも別です。
それでも、短期間に多くの企業が大規模な事案を発表したことは、企業のデータ管理のあり方を見直す重要な契機といえます。
本記事では、個々の企業を一律に評価するのではなく、公表された事実と、そこから考えられる構造的な課題を分けて整理します。
② わずか2週間で33事案!約1億3,000万件の衝撃

2026年10月20日付のITmediaの集計によると、10月6日から19日までの約2週間に、情報漏洩またはそのおそれを公表した主な企業・組織は33事案に上りました。
各社が発表した対象規模を単純に合計すると、延べ約1億3,000万件に達します。
出典:
https://www.itmedia.co.jp/enterprise/articles/2610/20/news061.html
この数字は、情報漏洩問題の広がりを示す一つの指標です。
ただし、解釈には注意が必要です。
第一に、約1億3,000万件は約1億3,000万人を意味しません。
企業によって、会員人数、アカウント数、メールアドレス数、データベース内の記録数など、集計対象が異なります。
第二に、すべての情報について、外部への流出が確認されたわけではありません。
企業の発表には、調査で外部取得が確認されたものもあれば、不正アクセスを受けた範囲から最大件数を推定したものもあります。
第三に、同一人物が複数のサービスに登録している可能性があります。
別々の企業が公表した件数を足し合わせても、重複のない人数にはなりません。
第四に、10月6〜19日に「公表された」事案が33件だったということは、同期間に33件の攻撃が新たに始まったという意味ではありません。
侵入から発見まで、さらに発見から公表までには時間差が生じます。
では、なぜ短期間に公表が集中したのか
考えられる理由はいくつかあります。
攻撃者が複数のサービスに共通する弱点を狙った可能性、企業間で共通の委託先やソフトウェアを利用していた可能性、ある事案をきっかけに各社が調査を強化した可能性などです。
ただし、すべての事案に同一の攻撃者が関与したと断定することはできません。
セキュリティ企業ラックも、国内のウェブシステムやアプリへの不正アクセスに関する分析を2026年10月15日に公表し、近年の公表事案の増加やサーバー侵入に関する相談の変化を報告しています。
ただし、その分析は同社が設定した条件や対応案件に基づくもので、国内全体の発生率を直接示すものではありません。
重要なのは、センセーショナルな合計件数だけに注目するのではなく、情報の種類、攻撃経路、実際に確認された被害、企業の対応を見極めることです。
主な出典:
③ 情報漏洩17社一覧!企業名・公表日・対象件数

今回の情報漏洩問題を具体的に理解するため、2026年9〜10月に公表された主な17社・サービスを一覧にまとめました。
スライド③では一覧性を重視していますが、ブログでは情報を確認しやすいように、企業名、公表日、対象規模、確認資料の区分を掲載します。
| 公表日 | 企業・サービス | 公表された対象規模 | 主な確認資料 |
|---|---|---|---|
| 9月16日 | Helpfeel「Gyazo」 | 約2,362万アカウント | 企業公式発表 |
| 9月25日 | タイムズモビリティ「タイムズカー」 | 約660万アカウント | 企業公式発表 |
| 10月5日 | 物語コーポレーション「焼肉きんぐ」 | 1,078万8,963件 | 企業公式発表 |
| 10月6日 | ミスターマックス・ホールディングス「MrMaxアプリ」など | 最大173万5,154人分 | 報道集計 |
| 10月8日 | ローソン「ローソンID」 | 215万5,345件 | 企業公式発表 |
| 10月8日 | 第一興商 | 約872万4,000件 | 報道集計 |
| 10月9日 | アドベンチャー「skyticket」 | 約1,464万件 | 企業公式発表 |
| 10月9日 | ブックオフグループホールディングス | 638万3,279人分 | 報道集計 |
| 10月13日 | ライドオンエクスプレスホールディングス | 最大約650万件 | 報道集計 |
| 10月15日 | ビーケー・ジャパン「バーガーキング」 | 約1,118万件 | 報道集計 |
| 10月15日 | ソースネクスト | 最大2,251万9,960件 | 企業公式発表 |
| 10月16日 | 日本経済新聞社 | 約183万件 | 報道集計 |
| 10月16日 | ヤマト運輸 | 計約531万件 | 報道集計 |
| 10月16日 | Eストアー「ショップサーブ」 | 約2,335万6,000人分 | 報道集計 |
| 10月19日 | ニフティ | 最大54万2,513件 | 報道集計 |
| 10月19日 | 阪急阪神百貨店「H2O ID」 | 約126万件 | 報道集計 |
| 10月19日 | ユミルリンク「Cuenote FC」 | 延べ約900万件 | 報道集計 |
※この表は、企業の初回公表日または報道集計上の公表日を基準に整理したものです。調査結果の更新日とは異なる場合があります。
※「企業公式発表」は該当する公式告知を参照できる事案、「報道集計」は今回、各社の最新の一次資料をすべて個別照合できていない事案を示します。
※後者の数値は掲載時に最新の公式発表との再照合が望まれます。
※表中の「件」「人分」「アカウント」は単位が異なります。「最大」「延べ」などの表記も重要な条件です。
※「ホールディングス」は持株会社を表す企業名の一部です。
※「ID」はIdentification(識別)の略で、サービス上では会員を識別するための登録情報などを指します。
※「FC」はサービス名の一部として用いられています。
17社の一覧から見えてくること
この表から、少なくとも三つの特徴が読み取れます。
一つ目は、特定の業界だけの問題ではないことです。
小売、外食、旅行、物流、情報サービスなど、さまざまな分野で事案が公表されています。
二つ目は、一つのサービスに蓄積される情報が非常に多いことです。
会員数が数百万、あるいは数千万規模のサービスでは、一つのシステムが侵害された場合の影響も大きくなります。
三つ目は、企業によって発表内容の詳細度が異なることです。
漏洩した情報の種類、攻撃経路、調査の進捗、利用者が取るべき対応などが明確な発表もあれば、調査中のため詳細が限られている発表もあります。
件数が大きい企業ほど危険なのか
必ずしもそうではありません。
例えば、メールアドレスのみが対象となった事案と、本人確認書類の画像や認証情報が対象となった事案では、二次被害の性質が異なります。
また、暗号化された情報が取得された場合、その暗号化方式や鍵の管理状況によってもリスクは変わります。
そのため、企業別のリスクを評価する際は、件数の大小だけでなく、次の視点が必要です。
- どの種類の情報が対象となったか
- 実際の外部取得が確認されているか
- 情報が暗号化・ハッシュ化されていたか
- 本人が変更できる情報か
- 企業が適切な通知と対策を行っているか
ハッシュ化とは、元のデータを一定の計算方法で別の値に変換する処理です。
パスワード保護にも利用されますが、方式や設定によっては推測攻撃への耐性が異なります。
主な出典:
- ITmedia企業別集計
- 各社公式発表。個別の公式資料は以下の事例解説および記事末尾にまとめています。
④ Gyazoで約2,362万アカウント!侵入の実態

画像共有サービス「Gyazo」を運営するHelpfeelは、2026年9月16日に不正アクセスを公表しました。
その後、調査結果を更新し、10月21日には第三報を公開しています。
この事案で対象となったのは、約2,362万アカウント分の情報と、約4億9,000万件の画像メタデータなどです。
ここで注意したいのは、約4億9,000万件という数字が、そのまま画像ファイル本体の流出数を表しているわけではないという点です。
メタデータとは何か
メタデータとは、データに付随する管理情報です。
画像の場合、識別番号、保存場所、作成日時、画像に関する設定などが含まれる場合があります。
どの項目が含まれるかは、サービスの設計によって異なります。
画像ファイルそのものとメタデータは別のものです。
ただし、メタデータであっても、保存方法や内容によっては個人情報や利用状況の推測につながる可能性があります。
Helpfeelの発表では、133人の利用者に関係する432件の画像について、第三者による閲覧・取得が確認されています。
これは、メタデータへのアクセスと、画像ファイル本体へのアクセスを分けて評価する必要があることを示しています。
一つの機能の弱点が大きな影響につながる
この事案では、動画変換機能に関係する問題が侵入経路となったことが公表されています。
利用者から見れば、画像共有サービスの一機能にすぎません。
しかし、内部ではデータベースやファイル管理システムなど、重要な資産につながっている場合があります。
攻撃者が一つの機能の弱点を利用して内部へ侵入し、そこから別の情報にアクセスできる構造であれば、被害は当初の機能の範囲を超えて広がります。
このような被害拡大を防ぐには、システム間の権限を分離し、一つの機能が侵害されても大量の情報を取得できない設計が重要です。
利用者が確認すべきこと
Gyazoを利用していた人は、Helpfeelの公式発表で、自分が対象となる可能性や必要な対応を確認することが第一です。
不正アクセスを知らせるメールを装った詐欺も考えられるため、メール内のリンクを安易に開かず、公式サイトから案内を確認する方法が安全です。
主な出典:
Helpfeel「Gyazoに対する不正アクセスに関する第三報」(2026年10月21日)
⑤ タイムズカー約660万アカウント!免許証画像も対象

カーシェアリングサービス「タイムズカー」を運営するタイムズモビリティは、2026年9月25日に不正アクセスを公表しました。
その後の説明では、退会済みの利用者を含む約660万アカウント分の会員情報が対象となったことが示されています。
この事案が大きな注目を集めた理由の一つは、運転免許証の画像など、本人確認に関わる情報が対象に含まれていたことです。
運転免許証情報が持つ特殊なリスク
メールアドレスやパスワードは、一定の手続きを踏めば変更できます。
しかし、氏名、生年月日、顔写真、本人確認書類に記載された情報は、利用者の判断だけで簡単に変更できるものではありません。
こうした情報が第三者に取得された場合、なりすましや本人確認を悪用した詐欺などへの不安が生じます。
もちろん、運転免許証画像が対象となったことだけで、直ちにすべての利用者に具体的な金銭被害が発生したと断定することはできません。
それでも、変更しにくい情報であるからこそ、企業には厳格な保管管理が求められます。
本人確認後も画像を保存し続ける必要があるのか
この事件は、本人確認情報の保管期間という重要な問題を浮かび上がらせました。
サービスの利用開始時には、本人確認書類の提出が必要になる場合があります。
しかし、確認が完了した後も画像を長期間保存し続ける必要があるかどうかは、別途検討すべき問題です。
法令や業務上の必要性がある場合を除き、不要になった情報を適切に削除することは、漏洩時の被害を減らす有効な方法です。
企業にとって、データは事業活動に役立つ資産です。
一方で、保管し続けるほど、管理コストと事故発生時のリスクも生じます。
この事案は訴訟問題にも発展
タイムズカーの事案では、法律事務所が損害賠償請求を目指す集団訴訟への参加希望者を募集しました。
この動きについては、⑪で詳しく解説します。
主な出典:
⑥ 焼肉きんぐ・ローソンも!身近なアプリの危険性

大規模な情報漏洩は、専門的な情報サービスだけで起こるわけではありません。
飲食店やコンビニエンスストアの公式アプリも、大量の個人情報を扱うサービスです。
焼肉きんぐ:約1,079万件
物語コーポレーションは2026年10月5日、「焼肉きんぐ」の公式アプリに関係する不正アクセスを公表しました。
対象規模は1,078万8,963件です。
公表資料では、氏名、ユーザー名、メールアドレス、電話番号などが対象とされ、ログインパスワードやクレジットカード情報は対象に含まれない旨が説明されています。
ただし、パスワードが対象ではなかったからといって、二次被害のリスクがゼロになるわけではありません。
例えば、氏名とメールアドレス、電話番号が組み合わされば、実在するサービスの利用者を狙った偽の案内を作る材料になる可能性があります。
ローソン:約215万件
ローソンは2026年10月8日、「ローソンID」に関係する不正アクセスを公表しました。
ローソンIDの対象規模は215万5,345件です。
また、別の予約関連システムについても対象情報が公表されており、同じ企業のサービスでも、システムによって情報の種類や影響範囲が異なることが分かります。
なぜ日常のアプリに大量の情報が集まるのか
現在の企業アプリは、単なるポイントカードではありません。
会員管理、クーポン配布、予約、購入履歴、キャンペーン応募、問い合わせ対応など、多くの機能が一つの会員情報と結び付いています。
利用者にとっては便利ですが、企業側では複数の機能を安全に連携させる必要があります。
また、アプリの開発・運用を外部企業に委託している場合、契約先を含めた安全管理が欠かせません。
利用者が日常的に使うアプリほど、登録したまま長期間放置されることもあります。
不要なアカウントを整理することは有効ですが、根本的な安全管理の責任は、情報を収集・保管する企業側にあります。
主な出典:
⑦ skyticket・ソースネクスト!API攻撃の脅威

2026年10月には、旅行予約サイト「skyticket」とソフトウェア販売会社ソースネクストも、大規模な情報漏洩事案を公表しました。
skyticket:約1,464万件
旅行予約サービス「skyticket」を運営するアドベンチャーは、約1,464万件の顧客情報が対象となる事案を公表しました。
発表では、約413万件のハッシュ化されたパスワード情報も対象に含まれています。
ハッシュ化されたパスワードは、通常、元のパスワードをそのまま保存したものではありません。
ただし、短いパスワードや推測されやすいパスワードは、ハッシュ化されていても、方式や設定によっては推測される危険があります。
また、この事案では続報によって対象情報の説明が更新されています。
クレジットカード関連情報についても、初期発表だけで判断せず、最新の公式案内を確認する必要があります。
ソースネクスト:最大約2,252万件
ソースネクストは2026年10月15日、最大2,251万9,960件の会員情報が流出した可能性があると発表しました。
この事案では、会員情報を取得する仕組みであるAPIの不正利用が問題となりました。
APIとは、Application Programming Interface(アプリケーション・プログラミング・インターフェース)の略です。
アプリケーションやシステム同士が、決められた方法でデータや機能をやり取りするための接続口を意味します。
例えば、スマートフォンのアプリで会員情報を表示する際、アプリがサーバーのAPIに問い合わせ、必要な情報を取得する仕組みが使われることがあります。
APIはなぜ狙われるのか
APIは便利な仕組みですが、外部からの要求を受け付ける接続口でもあります。
認証や権限の確認が不十分だと、本来は自分の情報しか取得できない利用者が、別の利用者の情報まで取得できてしまう場合があります。
また、短時間に大量の要求が送られた際の検知や制限が不十分だと、情報の大量取得につながる可能性があります。
重要なのは、APIを利用していること自体が危険なのではなく、APIの設計、認証、権限確認、監視が適切かどうかです。
なお、skyticketとソースネクストの事件について、攻撃方法や被害状況がすべて同じだったという意味ではありません。
各社の発表に基づいて個別に評価する必要があります。
主な出典:
⑧ なぜ情報漏洩が続出?企業に共通する4つの弱点

個別の事件にはそれぞれ異なる事情がありますが、大規模な情報漏洩につながりやすい構造的な弱点は、四つに整理できます。
1.大量データの集中管理
会員情報を一つのデータベースに集中させると、管理や分析が効率的になります。
しかし、アクセス権限の設定に問題がある場合、一度の侵害で大量の情報が取得される危険があります。
データを集中管理する場合でも、情報の種類や用途ごとにアクセスを制限することが重要です。
2.システムの複雑化
現在のサービスは、ウェブサイト、スマートフォンアプリ、クラウド、決済システム、外部認証、顧客管理システムなど、多くの要素から構成されています。
クラウドとは、インターネットを通じてサーバーやソフトウェアなどの機能を利用する仕組みです。
システムが複雑になるほど、設定ミスや更新漏れ、管理対象の把握不足が生じる可能性があります。
一つの部分だけを安全にしても、別の接続先に弱点が残っていれば、全体としての安全性は確保できません。
3.一つの弱点から被害が拡大する
攻撃者が最初に侵入する場所は、必ずしも重要なデータベースとは限りません。
公開ウェブサイト、画像変換機能、アプリの接続口などから侵入し、そこを足掛かりに内部の別のシステムへアクセスする可能性があります。
このような被害拡大を防ぐためには、システムを分離し、機能ごとに必要最小限の権限だけを与える必要があります。
4.外部委託先への依存
企業は、アプリ開発、メール配信、顧客管理、予約システムなどを外部の専門会社に委託することがあります。
委託先のシステムが侵害されると、複数の顧客企業に影響が及ぶ可能性があります。
そのため、委託先の安全管理を確認することは、契約時だけの仕事ではありません。
継続的な監査、権限の見直し、事故発生時の連絡体制の整備が必要です。
本質的な問題は「攻撃されたこと」だけではない
サイバー攻撃を完全に防ぐことは困難です。
重要なのは、侵入された場合でも、大量の情報を一度に取得できない設計にすることです。
情報の収集量、保管期間、アクセス権限、監視体制を見直すことで、事故が起きた場合の被害を小さくできます。
参考資料:
⑨ AIを悪用したサイバー攻撃!実際に確認された手口

今回の情報漏洩問題では、人工知能を悪用したサイバー攻撃にも注目が集まりました。
AIとは、Artificial Intelligence(人工知能)の略です。
文章の生成、情報の整理、プログラムの解析、画像の認識など、従来は人間が行っていた知的作業の一部をコンピューターで支援・自動化する技術を指します。
JPCERT/CCが確認した攻撃活動
2026年10月15日、JPCERT/CCは、国内外のウェブサービスに対する連続不正アクセスの調査結果を公表しました。
JPCERT/CCは、Japan Computer Emergency Response Team Coordination Centerを由来とする名称で、日本国内のサイバー攻撃に関する情報収集、分析、関係組織との調整などを行う専門機関です。
同機関の調査では、攻撃に使われた可能性のあるサーバーから、AIを利用した既知の脆弱性の探索や、APIを経由した攻撃に関係する痕跡が確認されました。
脆弱性とは、ソフトウェアやシステムに存在する、安全性上の弱点です。
スマートフォンアプリの内部を調べる
調査では、Android向けアプリの解析に関係するファイルやツールも確認されています。
Androidは、主にスマートフォンなどで使われる基本ソフトウェアの一つです。
APKはAndroid Package Kitの略として知られ、Androidアプリを配布・インストールするためのパッケージ形式を指します。
攻撃者はアプリの内部構造を調べ、接続先のAPIや、プログラム内に含まれる情報を確認しようとしていたとみられます。
これは、攻撃対象がウェブサイトの表面だけではないことを示しています。
スマートフォンアプリの内部に接続先や認証に関する情報が含まれている場合、攻撃者がそれを分析してサーバー側の弱点を探る可能性があります。
AIが攻撃を効率化する
AIは、脆弱性情報の整理、プログラムの読解、調査結果の要約などを支援できます。
従来は専門知識と時間が必要だった作業の一部が効率化されることで、攻撃者が短時間に多数の対象を調べる可能性があります。
ただし、AIを使ったからといって、あらゆるシステムに侵入できるわけではありません。
実際の侵害には、利用可能な弱点、設定不備、認証情報の管理状況など、具体的な条件が関係します。
17社すべてでAIが使われたわけではない
ここは特に重要です。
JPCERT/CCの調査によって、AIを利用した攻撃活動が確認されたことと、本記事で紹介する17社すべての事件でAIが使用されたことは、同じではありません。
個別企業の攻撃にAIが使われたと断定するには、その事案に結び付く証拠が必要です。
主な出典:
JPCERT/CC「連続不正アクセス事案の攻撃手法に関する調査」(2026年10月15日)
⑩ AIで攻撃はどう変わる?攻撃と防御の新時代

AIはサイバー攻撃の効率化に使われる一方、企業の防御にも活用できます。
したがって、AIの進歩を「攻撃者だけが有利になる変化」と考えるのは適切ではありません。
攻撃側で考えられる変化
攻撃者はAIを利用して、公開されている技術情報を整理したり、プログラムの構造を分析したりできます。
また、攻撃対象となるサービスの特徴を把握し、調査作業を効率化する可能性があります。
特に、大量の情報を比較する作業や、繰り返し行う分析では、AIの利用によって時間が短縮される場合があります。
ただし、AIによる分析結果には誤りも含まれ得ます。
AIが出力した情報をそのまま使えば、必ず攻撃が成功するというものではありません。
防御側でもAIが役立つ
企業側では、次のような用途が考えられます。
- 大量の通信記録から不審な動きを探す
- ソースコードに潜む弱点を調べる
- 既知の脆弱性情報を整理する
- 社内のセキュリティ警告を分類する
- 事故発生時の調査資料を要約する
ソースコードとは、ソフトウェアの動作を記述したプログラムの元となる文章です。
また、ログとは、システムへのアクセス、操作、通信などの履歴を記録したものです。
AIが大量のログを分析することで、人間だけでは見落としやすい異常を発見できる可能性があります。
AIを導入すれば安全になるわけではない
一方で、防御用AIにも限界があります。
正常な通信を攻撃と誤判定したり、攻撃を見逃したりする可能性があります。
さらに、AIに入力する情報の管理を誤れば、新たな情報漏洩リスクが生じることもあります。
したがって、AIによる検知結果を人間が検証し、必要な対応を判断する仕組みが重要です。
企業はAIの導入だけに頼るのではなく、アクセス権限の管理、脆弱性の修正、データの最小化など、基本的な対策を継続する必要があります。
AIは攻撃にも防御にも利用できる技術であり、その効果は運用方法によって大きく変わります。
⑪ タイムズカーで集団訴訟の動き!利用者の怒りと不安

タイムズカーの情報漏洩問題では、利用者による損害賠償請求を目指す集団訴訟の動きが報じられました。
2026年9月30日ごろから、牧野法律事務所が参加希望者を募集する特設サイトを開設し、10月2日にはITmediaが、登録者が3,000人弱に達したことなどを報じています。
その後も参加希望者の登録が増加したと報じられていますが、登録者数は時点によって変わります。
数字を掲載する際は、必ず報道日と集計時点を併記する必要があります。
なぜ集団訴訟の動きが注目されたのか
今回の事案では、約660万アカウントという規模に加え、運転免許証画像などの本人確認情報が問題となりました。
本人確認情報は、日常生活のさまざまな場面で利用されます。
そのため、利用者にとっては、現時点で具体的な金銭被害が確認されていなくても、将来的な不正利用への不安が残る可能性があります。
また、情報を提供した利用者が、企業のシステム設計や保管期間を十分に把握することは困難です。
このような情報の非対称性も、企業に対して説明や責任を求める動きにつながると考えられます。
集団訴訟への参加登録と正式提訴は違う
ここで、法律上の手続きについて整理しておきます。
法律事務所の特設サイトに登録することは、一般に、訴訟への参加意思や関心を示すための手続きです。
一方、正式な提訴とは、裁判所に訴状を提出し、裁判上の請求を開始することです。
したがって、参加希望者が多数集まったことだけで、全員が正式な原告になったと判断することはできません。
また、訴訟が提起された場合でも、原告側の請求が必ず認められるとは限りません。
損害賠償の有無や金額は、具体的な事実関係と法律上の判断によって決まります。
利用者が訴訟情報を確認する際の注意点
訴訟への参加を検討する場合は、法律事務所の正式な案内を確認することが重要です。
特に、費用負担、成功報酬、個人情報の取り扱い、参加後の手続きなどを理解する必要があります。
また、情報漏洩事件に便乗した偽の補償案内や、法律事務所を装う詐欺が発生する可能性もあります。
見知らぬメールやメッセージから本人確認書類を送付したり、口座情報を入力したりする前に、公式の連絡先を確認してください。
主な出典:
⑫ 情報漏洩で賠償責任?過去の裁判と企業のリスク
【ここにスライド⑫を掲載】
情報漏洩が発生した場合、企業は必ず損害賠償を支払わなければならないのでしょうか。
答えは、必ずしもそうではありません。
情報漏洩の発生という事実と、法律上の損害賠償責任が成立するかどうかは、分けて考える必要があります。
損害賠償で問題となる点
一般に、民事上の損害賠償請求では、企業にどのような安全管理上の義務があったのか、その義務に違反したのか、利用者にどのような損害が発生したのかなどが検討されます。
また、義務違反と損害との間に因果関係があるかどうかも重要です。
例えば、企業が合理的な安全管理措置を講じていたか、既知の脆弱性を長期間放置していなかったか、必要以上の個人情報を保存していなかったか、といった事情が問題になり得ます。
ただし、どの措置が法的に必要だったかは、当時の技術水準、サービスの性質、取り扱う情報の種類などによって異なります。
ベネッセ事件から考える
過去には、ベネッセコーポレーションの顧客情報漏洩をめぐり、利用者側が損害賠償を求める裁判が行われました。
この事件は、個人情報の漏洩によって生じる精神的損害や、プライバシー侵害をどのように評価するかという問題を社会に提起しました。
ただし、過去の裁判で一定の判断が示されたからといって、別の事件に同じ結論がそのまま適用されるわけではありません。
漏洩した情報の内容、漏洩の経緯、企業の管理状況などが異なるためです。
企業が負担するコストは賠償金だけではない
情報漏洩が企業経営に与える影響は、損害賠償に限りません。
不正アクセスの調査、システムの復旧、外部専門家への依頼、利用者への通知、問い合わせ窓口の設置、再発防止策の実施など、多くの費用が発生する可能性があります。
さらに、サービスへの信頼が低下すれば、解約や利用控え、新規顧客の獲得難などにつながる場合もあります。
企業の経営者にとって、情報セキュリティは単なる技術部門の問題ではありません。
個人情報を大量に保有する経営上の利益と、その情報を守るための費用・責任を一体で考える必要があります。
利用者への補償はどうあるべきか
情報漏洩後の企業対応では、金銭的な補償だけでなく、正確で継続的な説明も重要です。
何が起きたのか、どの情報が対象なのか、どのような二次被害が考えられるのか、利用者は何をすべきなのか。
これらを明確に伝えることは、利用者の不安を軽減し、実際の被害を防ぐことにもつながります。
企業が調査中である場合は、未確認の事項を断定せず、分かっていることと分かっていないことを区別して説明する姿勢が求められます。
⑬ 未公表企業も存在する?見えない情報漏洩の実態

今回の情報漏洩問題を考えるうえで、もう一つ重要な疑問があります。
それは、ニュースで報じられている企業だけが被害を受けているのかという問題です。
結論からいえば、報道された事案が国内のすべての情報漏洩を網羅しているとは考えられません。
ただし、ここから直ちに、特定の企業が被害を意図的に隠していると結論付けることはできません。
1.企業が侵入に気づいていない可能性
不正アクセスが発生しても、企業がすぐに発見できるとは限りません。
攻撃者が正常な利用者に見える通信を使ったり、少しずつ情報を取得したりした場合、異常の検知が難しくなることがあります。
また、十分な通信記録を保存していなければ、過去の不正アクセスを後から調査することも困難になります。
つまり、企業が公表していない理由が、そもそも事件を認識していないことにある場合も考えられます。
2.調査中で対象範囲が確定していない可能性
不正アクセスを発見しても、直ちに被害の全体像が分かるとは限りません。
どのサーバーが侵害されたのか、どの情報にアクセスされたのか、実際に外部へ取得されたのかなどを調査するには時間がかかります。
その間、企業が外部専門家や関係当局と協議している場合もあります。
ただし、法令上の報告・通知義務が生じる場合には、調査が完全に終わるまで何もしなくてよいわけではありません。
3.対象者への通知と一般公表が異なる可能性
一定の要件に該当する個人データの漏洩等では、個人情報保護委員会への報告や本人への通知が求められます。
一方、すべての事案について、新聞やニュースサイトに掲載される形で一般公表しなければならないわけではありません。
対象者への個別通知を中心に対応した事案は、一般の人が把握しにくい場合があります。
4.公表対象として把握される範囲に限界がある
報道機関やセキュリティ企業の集計には、一定の収集条件があります。
例えば、企業の公式発表を対象とする集計であれば、公式発表のない事案は原則として含まれません。
また、件数を明示していない事案は、対象件数の合計から除外されることがあります。
したがって、公表事案の集計は重要な資料ですが、国内で実際に発生した情報漏洩の完全な一覧ではありません。
未公表の事案はどの程度あるのか
ここで慎重になるべきなのは、件数の推定です。
「公表されていない企業が多数あるはずだ」と感じることは自然ですが、十分な根拠なしに具体的な件数や割合を示すことはできません。
実態を把握するには、行政への報告状況、企業の公表情報、専門機関の観測結果など、異なる資料を組み合わせる必要があります。
さらに、報告対象の定義や集計期間が異なる場合、単純な比較はできません。
未公表と隠蔽は別問題
最も重要なのは、この区別です。
公表していないという事実だけでは、法令違反や隠蔽があったとはいえません。
反対に、一般公表していないからといって、行政への報告や本人通知の義務まで免除されるわけでもありません。
企業の対応を評価する際は、事案の内容、適用される法令、本人通知の実施状況、調査の進捗などを確認する必要があります。
主な参考資料:
⑭ 情報漏洩を公表しなくても違法ではない?法律の仕組み

日本の個人情報保護法では、一定の要件に該当する個人データの漏洩等について、個人情報保護委員会への報告と本人への通知が義務付けられています。
ここで理解しておきたいのは、次の三つが異なるということです。
- 行政への報告
- 対象となった本人への通知
- 一般社会に向けた公表
行政への報告
個人情報保護法上の報告対象となる事案では、企業は個人情報保護委員会など、法令で定められた報告先に必要な情報を報告します。
報告対象には、要配慮個人情報が含まれる事案、財産的被害が生じるおそれのある事案、不正の目的をもって行われたおそれのある事案、一定規模を超える事案などがあります。
要配慮個人情報とは、病歴など、取り扱いに特に配慮を要する情報です。
速報は、事態を知った後、速やかに行う必要があり、一般におおむね3〜5日以内が目安とされています。
確報は原則として30日以内、一定の不正目的による事案では60日以内となります。
ただし、個別の適用関係や報告方法については、公式の案内を確認する必要があります。
本人への通知
報告対象となる事案では、原則として本人への通知も求められます。
通知では、対象となった情報の内容や事案の概要など、本人が状況を理解するために必要な事項を伝えます。
ただし、本人への通知が困難な場合など、法令に定められた例外的な取り扱いがあります。
一般社会への公表
企業がニュースリリースを出したり、記者会見を開いたりする行為は、一般社会への公表です。
一般向け公表は、透明性の確保や利用者への注意喚起に役立ちます。
しかし、個人情報保護法上、すべての漏洩事案について一般公表が一律に義務付けられているわけではありません。
一方で、業界ごとの法令や監督指針、契約上の義務などによって、追加の対応が求められる場合があります。
したがって、「一般公表しなければ違法」「一般公表しなければ何の義務もない」という両極端な理解は、どちらも適切ではありません。
プライバシーマークや業界ルール
プライバシーマーク制度は、個人情報の適切な取り扱いに関する事業者の管理体制を評価する制度です。
関連する規格として、JIS Q 15001があります。
JISはJapanese Industrial Standards(日本産業規格)の略で、製品や管理方法などについて定められる国内規格です。
認証制度や業界のルールによって、法令とは別に、事故発生時の報告や対応が求められることがあります。
欧州のGDPRとの違い
欧州には、GDPRという個人データ保護の法制度があります。
GDPRはGeneral Data Protection Regulation(一般データ保護規則)の略です。
一定の個人データ侵害について、原則として認識後72時間以内に監督機関へ通知する仕組みが設けられています。
ただし、通知義務にはリスクに応じた条件や例外があります。
ここでいう72時間は、すべての事案について一般社会に公表する期限ではありません。
日本と欧州では制度の仕組みが異なりますが、共通して重要なのは、事案を把握し、必要な相手に迅速かつ正確に情報を伝えることです。
主な出典:
⑮ 企業が取るべき8つの情報漏洩対策

今回の一連の事案から分かるのは、サイバー攻撃を完全に防ぐことだけを目標にしても、十分ではないということです。
企業には、侵入を防ぐ対策に加えて、侵入を早期に発見し、万が一侵入されても被害が広がらない仕組みが必要です。
ここでは、スライド⑮に対応する八つの対策を紹介します。
1.社内のセキュリティ体制を強化する
情報セキュリティを情報システム担当者だけに任せず、経営層が責任を持って管理する体制を整えます。
どの部署がどの情報を管理しているのか、事故が発生した場合に誰が判断するのか、外部への連絡を誰が担当するのかを明確にします。
さらに、定期的なリスク評価を実施し、重要な情報資産を把握する必要があります。
2.従業員のセキュリティ意識を高める
技術的な対策が充実していても、従業員が不審なメールを開いたり、認証情報を第三者に渡したりすれば、被害につながる可能性があります。
そのため、フィッシング詐欺への対応、パスワード管理、機密情報の取り扱いなどについて、継続的な教育が必要です。
フィッシングとは、実在する企業や組織を装って利用者を偽サイトなどへ誘導し、認証情報や個人情報を盗み取ろうとする手口です。
ただし、従業員への教育だけで事故を防ごうとするのは不十分です。
人間が間違えることを前提に、被害を防ぐ技術的な仕組みも整える必要があります。
3.アクセス権限を適切に管理する
従業員やシステムには、業務に必要な範囲だけの権限を与えます。
例えば、問い合わせ担当者が顧客の連絡先を確認する必要があっても、全会員の情報を一括取得する権限まで必要とは限りません。
管理者権限を持つアカウントについては、利用状況を監視し、不要な権限を定期的に削除します。
APIについても、要求を送信した利用者が、その情報にアクセスする権限を持っているかをサーバー側で確認することが重要です。
4.システムやソフトウェアの脆弱性を管理する
ソフトウェアの脆弱性は、発見後に修正プログラムが提供される場合があります。
OSやアプリケーションを適切に更新し、脆弱性診断を定期的に実施することで、既知の弱点を悪用される危険を減らせます。
OSはOperating System(オペレーティングシステム)の略で、コンピューターやスマートフォンの基本的な動作を管理するソフトウェアです。
また、自社で開発したシステムについては、設計段階から認証や権限確認を検討し、公開前に安全性を確認することが重要です。
5.重要なデータを暗号化する
暗号化とは、情報を特定の鍵がなければ読めない形式に変換することです。
顧客情報などの重要なデータについて、保存時と通信時の両方で適切な暗号化を行います。
ただし、暗号化だけで情報漏洩を完全に防げるわけではありません。
攻撃者が正規の権限を不正に利用した場合、復号された情報にアクセスできる可能性があります。
そのため、暗号化とアクセス権限管理、監視などを組み合わせる必要があります。
6.外部からの攻撃に備える
企業は、不審な通信を検知する仕組みや、外部からの不正な接続を制限する仕組みを整えます。
代表的なものに、ファイアウォールや侵入検知・侵入防止システムがあります。
IDSはIntrusion Detection System(侵入検知システム)の略で、不審な通信や攻撃の兆候を検知する仕組みです。
IPSはIntrusion Prevention System(侵入防止システム)の略で、不正と判断した通信を遮断するなどの防御を行う仕組みです。
ただし、これらを導入するだけでは十分ではありません。
適切な設定と継続的な監視が必要です。
7.事故発生時の対応体制を整備する
情報漏洩が疑われる場合、企業は迅速に状況を把握し、被害拡大を防ぐ必要があります。
そのためには、事前に対応手順を定め、担当者を決め、必要な連絡先を整理しておくことが重要です。
対応手順には、不正アクセスの遮断、証拠保全、対象範囲の調査、行政への報告、本人への通知、再発防止策の実施などが含まれます。
定期的な訓練を実施し、実際に対応できるかを確認することも必要です。
8.第三者による定期的な評価を受ける
自社の安全管理を内部だけで評価すると、見落としが生じる可能性があります。
外部の専門機関による監査や脆弱性診断、侵入テストなどを活用することで、別の視点から問題を発見できます。
侵入テストは、許可された範囲で実際の攻撃に近い方法を用い、システムの安全性を検証する取り組みです。
また、外部委託先についても、契約上の安全管理要件や事故時の連絡体制を確認する必要があります。
八つの対策に加えて重要な「情報の最小化」
今回の大規模情報漏洩から得られる最も重要な教訓の一つは、不要な個人情報を保管し続けないことです。
どれほど防御を強化しても、保管する情報が多ければ、事故発生時の影響は大きくなります。
収集する情報を必要最小限にし、利用目的を終えた情報は適切に削除する。
これは技術的な対策と同じくらい重要な経営判断です。
参考資料:
⑯ 個人が今すぐできる7つの情報漏洩対策

情報漏洩は、企業のシステムで発生する問題です。
利用者がどれほど注意していても、企業側のシステムへの不正アクセスを直接防ぐことは困難です。
しかし、漏洩した情報を悪用した詐欺やアカウントの乗っ取りなど、二次被害を減らすためにできることはあります。
1.強固で固有のパスワードを設定する
最も重要な対策の一つは、複数のサービスで同じパスワードを使い回さないことです。
一つのサービスからパスワードが漏洩した場合、攻撃者が別のサービスでも同じ組み合わせを試す可能性があります。
長く、推測されにくく、サービスごとに異なるパスワードを利用しましょう。
多数のパスワードを管理する場合は、信頼できるパスワード管理ツールの利用も有効です。
2.多要素認証を有効にする
多要素認証とは、知識、所持、生体情報など、異なる種類の認証要素を組み合わせて本人確認する仕組みです。
例えば、パスワードに加えて、認証アプリや本人が持つ機器を利用します。
可能であれば、フィッシングに強いパスキーの利用も検討しましょう。
パスキーは、公開鍵暗号方式などを利用してパスワードの入力を減らす認証方法です。
公開鍵暗号方式とは、対になる鍵を使って暗号処理や認証を行う仕組みです。
多要素認証やパスキーを利用しても、すべての不正利用を防げるわけではありませんが、アカウント乗っ取りのリスクを減らす有効な手段になります。
3.不審なメールやメッセージに注意する
情報漏洩の公表後には、企業からの通知を装う詐欺に注意が必要です。
例えば、「情報漏洩の補償を受け取るには、こちらで本人確認してください」といった案内が届く可能性があります。
不審なメールやメッセージに記載されたリンクを安易に開かず、企業の公式サイトや公式アプリから情報を確認してください。
SMSはShort Message Service(ショートメッセージサービス)の略で、携帯電話番号を利用した短文メッセージの仕組みです。
SMSも詐欺の誘導に使われる場合があります。
4.アプリやソフトウェアを最新の状態に保つ
スマートフォンやパソコンのOS、アプリケーションを適切に更新することは、既知の脆弱性を悪用されるリスクを減らすうえで重要です。
可能であれば自動更新を有効にし、提供元からのセキュリティ更新を確認しましょう。
ただし、更新によって企業側で発生した過去の情報漏洩が取り消されるわけではありません。
あくまで、利用者自身の端末やアカウントを守るための対策です。
5.公共のWi-Fiを慎重に利用する
Wi-Fiは、無線通信を利用して端末をネットワークに接続する技術の名称です。
公共のWi-Fiを利用する際は、正規のネットワークかどうかを確認し、不審な接続先を避けることが重要です。
通信が適切に暗号化されたサービスを利用することも大切です。
VPNを利用する方法もあります。
VPNはVirtual Private Network(仮想プライベートネットワーク)の略で、通信経路を保護するための仕組みです。
ただし、VPNを利用すればすべての詐欺や情報漏洩を防げるわけではありません。
信頼できるサービスを選ぶ必要があります。
6.個人情報の公開範囲を見直す
SNSや公開プロフィールに、氏名、生年月日、住所、勤務先などの情報を必要以上に掲載していないか確認しましょう。
SNSはSocial Networking Service(ソーシャル・ネットワーキング・サービス)の略で、利用者同士が交流したり情報を発信したりするサービスです。
公開情報が多いほど、攻撃者が本人を装ったメッセージを作りやすくなる場合があります。
ただし、公開している情報を減らしたからといって、企業が保管する情報の漏洩を防げるわけではありません。
7.利用サービスの情報を定期的に確認する
利用しているサービスの公式発表、ログイン履歴、登録情報、決済履歴などを確認しましょう。
不審なログイン通知や請求があった場合は、公式窓口に問い合わせ、必要に応じて認証情報の変更や決済手段の停止を検討します。
また、使わなくなったサービスのアカウントは、必要に応じて整理しましょう。
ただし、アカウントを削除しても、法令や契約に基づき一定の情報が保存される場合があります。
削除によってすべての情報が直ちに消去されるとは限りません。
漏洩した情報の種類によって対応を変える
すべての情報漏洩に対して、同じ対応が必要なわけではありません。
パスワードが対象であれば、変更と使い回しの確認が優先されます。
メールアドレスや電話番号が対象であれば、フィッシングや不審な連絡への警戒が重要です。
クレジットカード情報が対象となった場合は、カード会社の案内を確認し、利用明細に不審な請求がないか注意します。
運転免許証画像などの本人確認情報が対象の場合は、企業の公式案内や関係機関の注意喚起を確認し、必要な手続きを検討します。
重要なのは、利用者が過剰な不安を抱えることではなく、確認されたリスクに応じて適切に行動することです。
⑰ 日本に必要な3つの改革!情報漏洩を減らすには

情報漏洩を減らすには、企業ごとの技術的な対策だけではなく、社会全体の仕組みも重要です。
今回の一連の事案を踏まえると、今後の課題は三つに整理できます。
第一の改革:法律・規制と情報公開の仕組みを充実させる
情報漏洩の実態を把握しやすくするには、行政への報告制度、企業の情報公開、専門機関による分析などを適切に連携させる必要があります。
ただし、一般公表の義務を広げれば、それだけですべての問題が解決するわけではありません。
公表する情報の正確性、本人への通知の迅速さ、調査中の情報の扱いなど、実務上の課題もあります。
また、企業の発表を比較しやすくするため、対象情報の種類、確認された流出範囲、調査の進捗などについて、説明項目の標準化を進めることも考えられます。
こうした改革を検討する際には、利用者の知る権利、調査の適正さ、企業の負担などを総合的に考える必要があります。
第二の改革:企業のガバナンスを強化する
ガバナンスとは、組織が適切に運営されるよう、責任と監督の仕組みを整えることです。
情報セキュリティを現場任せにせず、経営層が定期的にリスクを確認し、必要な投資を判断することが重要です。
企業は、新しいサービスを開発する際、機能や利便性だけでなく、情報漏洩時の影響も評価する必要があります。
特に、数百万件以上の個人情報を保管するサービスでは、情報の集中管理、アクセス権限、保存期間などについて、経営レベルで判断することが求められます。
また、委託先の管理を含め、事故発生時に責任の所在が不明確にならない仕組みも必要です。
第三の改革:国民の情報セキュリティに関する理解を高める
情報漏洩の二次被害を減らすには、利用者が基本的な対策を理解できることも重要です。
学校教育や社会人向け研修、自治体による啓発活動などを通じて、パスワード管理、多要素認証、フィッシング対策などの知識を広げる必要があります。
また、高齢者や子どもなど、デジタルサービスの利用に不慣れな人が相談できる窓口を整備することも大切です。
ただし、国民の意識向上を理由に、企業の責任を利用者へ転嫁してはいけません。
利用者が適切に行動できるよう、企業が分かりやすい情報を提供することも重要です。
三つの改革を同時に進める
法律や制度だけを整えても、企業の管理体制が不十分であれば、情報漏洩のリスクは残ります。
企業が技術的な対策を進めても、利用者への説明が不十分であれば、二次被害を防ぎにくくなります。
また、利用者が注意していても、企業のシステムに重大な弱点があれば、大規模な情報漏洩を防ぐことは困難です。
行政、企業、利用者がそれぞれの役割を果たし、情報を守る仕組みを継続的に改善することが重要です。
⑱ まとめ:あなたの個人情報は本当に守られているか?

2026年9〜10月、日本では多くの企業が個人情報の漏洩や、そのおそれを相次いで公表しました。
画像共有サービス、カーシェアリング、飲食店、コンビニエンスストア、旅行予約サイトなど、私たちの生活に身近なサービスが対象となっています。
今回の一連の事案から、五つの教訓が見えてきます。
1.身近なサービスでも大規模な情報漏洩は起こる
日常的に利用するアプリや会員サービスにも、大量の個人情報が保存されています。
企業は、情報を収集する段階から、その必要性と保管期間を検討する必要があります。
2.AIを悪用した攻撃が実際に確認されている
JPCERT/CCの調査では、AIを利用した脆弱性探索などの攻撃活動が確認されました。
ただし、今回紹介した17社すべての事案でAIが使われたと確認されたわけではありません。
確認された事実と推測を区別することが重要です。
3.情報漏洩は訴訟問題にも発展する
タイムズカーの事案では、損害賠償請求を目指す集団訴訟の動きが報じられました。
企業にとって、情報漏洩はシステムの問題だけでなく、利用者との信頼関係や法的責任に関わる問題です。
ただし、訴訟への参加希望登録と正式提訴、正式提訴と賠償責任の確定は、それぞれ異なります。
4.公表された事案だけでは全体像を把握できない
ニュースで報じられた情報漏洩が、国内のすべての事案を網羅しているわけではありません。
未発見、調査中、個別通知のみの事案などが存在する可能性があります。
ただし、一般向けに公表していないことだけを理由に、企業が違法な隠蔽をしていると断定することはできません。
5.企業と個人の両方にできることがある
企業は、個人情報の最小化、アクセス権限の管理、脆弱性の修正、監視、事故対応などを進める必要があります。
個人は、パスワードの使い回し防止、多要素認証、不審なメールへの警戒、利用サービスの公式発表の確認などによって、二次被害を減らすことができます。
ただし、情報を安全に保管する根本的な責任は、情報を収集・管理する企業側にあります。
最後に
デジタルサービスは、私たちの生活を便利にしています。
一方で、その便利さは、企業が大量の個人情報を預かる仕組みに支えられています。
情報漏洩を完全になくすことは難しくても、収集する情報を減らし、適切に管理し、問題が起きた際に迅速に対応することで、被害を小さくすることはできます。
今回の事件を、単なる一時的なニュースとして終わらせるのではなく、企業と利用者の双方が情報管理を見直す機会にすることが重要です。
あなたが利用しているサービスから、情報漏洩のお知らせが届いていませんか?
まずは公式発表を確認し、自分に必要な対策を一つずつ実行していきましょう。
主要な出典・参考資料
本記事では、企業の公式発表、セキュリティ専門機関の調査、行政資料、報道機関による集計を区別して参照しています。
企業の公式発表
| 企業・サービス | 資料 |
|---|---|
| Helpfeel「Gyazo」 | 不正アクセスに関する第三報(2026年10月21日) |
| タイムズカー | タイムズカー公式案内 |
| 物語コーポレーション「焼肉きんぐ」 | 公式発表 |
| ローソン | 公式発表 |
| アドベンチャー「skyticket」 | 公式案内 |
| ソースネクスト | 公式発表(2026年10月15日) |
専門機関・行政の資料
- JPCERT/CC「連続不正アクセス事案の攻撃手法に関する調査」(2026年10月15日)
- 情報処理推進機構「情報セキュリティ白書2026」
- 個人情報保護委員会「漏えい等の対応」
- 個人情報保護委員会・公式FAQ
- ラック「国内で相次ぐWebシステムからの情報漏えい」(2026年10月15日)
報道・訴訟関連資料
- ITmedia「2026年10月総まとめ第2弾」(2026年10月20日)
- ITmedia「タイムズカー漏えいで集団訴訟の動き」(2026年10月2日)
- 牧野法律事務所・タイムズカー情報漏洩集団訴訟特設サイト
出典の検証と記事を読む際の注意点
本記事の内容を正確に理解するため、以下の点を明記します。
第一に、企業の公表内容は調査の進展によって変わる可能性があります。
初回発表では対象情報が限定的に説明されていても、その後の調査で対象範囲が広がる場合があります。
特に、skyticketなど続報のある事案では、初回発表だけで判断しないことが重要です。
第二に、17社一覧のすべての数値を、各社の最新の一次資料で個別に再確認できたわけではありません。
表中の一部は、2026年10月20日付ITmediaの集計に基づいています。
掲載前に各社の最新発表を照合することで、記事の正確性をさらに高められます。
第三に、「漏洩確認」「漏洩のおそれ」「対象最大件数」は異なります。
各社の公表数値を単純に合計して、実際の流出人数や確定被害件数と解釈することはできません。
第四に、AIを利用した攻撃の確認と、個別企業の被害原因は区別する必要があります。
JPCERT/CCの調査は重要な資料ですが、それを根拠に17社すべての事件をAI攻撃と断定することはできません。
第五に、集団訴訟の動向は時間とともに変化します。
参加希望者数、正式提訴の有無、裁判の進行状況などについては、法律事務所や信頼できる報道機関の最新情報を確認してください。
第六に、未公表事案の可能性と、企業による違法な隠蔽は別問題です。
一般公表が行われていないことだけで、個人情報保護法違反を認定することはできません。
第七に、本記事の法律に関する説明は一般的な情報提供です。
具体的な事件についての法的判断や訴訟参加の可否は、個別の事情によって異なります。
