【詳細版】2026年に相次ぐ大規模個人情報流出｜何が入口だったのか？事件別の手口・防げた可能性・今すぐできる対策

2026年の春から秋にかけて、国内で大規模な個人情報流出のニュースが次々と報じられました。通販サイト、画像共有サービス、通信会社、保険会社、そして政府機関まで、規模も業種もさまざまです。

「いったい何が起きているのか」「自分の情報は大丈夫なのか」と不安になった方も多いのではないでしょうか。

この記事では、2026年4月〜10月に公表された主な事件を取り上げ、どこから侵入されたのか、防げた可能性はあったのか、そして企業と個人がいま何をすべきかを整理します。情報は2026年10月19日時点の各社公表・報道に基づいています。

過去最悪のペースで続く大規模流出

まず、今年の状況がどれほど異例なのかを数字で確認しておきます。

東京商工リサーチ（TSR）の集計によると、上場企業とその子会社が公表した100万件以上の個人情報漏えい・紛失事故は、2026年10月5日時点で10件に達しました。2025年の年間6件をすでに上回っています。

さらに、1,000万件以上の事故は2025年までの14年間でわずか3回でしたが、2026年は10月5日までの約9か月で同じ3回に達しました。今年の大規模事故のうち5件は、歴代の漏えい・紛失件数ワースト10に入っています。その後もソースネクスト（最大約2,252万件）、バーガーキング（約1,118万件）、Eストアー最終報（約2,336万人）などの公表が続いています。

こうした事態を受けて、2026年10月7日〜9日には個人情報保護委員会、JPCERT/CC、警察庁、国家サイバー統括室、総務省、経済産業省、IPA、金融庁が相次いで注意喚起を出しました。IPAは、特定の製品やサービスの脆弱性を狙った攻撃とは断定されていないとしたうえで、外部に公開しているアプリケーションやアカウントの侵害が起点になっている傾向を指摘しています。

主な事件の一覧

2026年4月〜10月に公表された主な事件をまとめました。件数は各社の公表単位（人数・アカウント数・レコード数）が異なるため、単純な比較や合計はできない点にご注意ください。

事件	規模	公表されている侵入経路	評価
Eストアー「ショップサーブ」	約2,335万6,000人	サーバー上のアプリの脆弱性	防げた可能性あり
Gyazo	ユーザー関連約2,362万件	画像アップロードサーバーの脆弱性	防げた可能性あり
ソースネクスト	最大22,519,960件	会員情報取得APIの不正利用（原因調査中）	判断材料不足
EPARK「PeakManager」	約2,218万レコード	公表差し控え	不明
skyticket	約1,464万件＋カード最大6,140名	管理機能の不正操作	原因の一部のみ判明
KDDI ISP向けメール	メールアドレス約1,223万件	第三者製ソフトのゼロデイ脆弱性	侵入は防ぎにくい
バーガーキング公式アプリ	約1,118万件	未公表	不明
焼肉きんぐ公式アプリ	10,788,963件	未公表（調査中）	不明
第一興商	約872万4,000件（おそれ）	委託先の従業員PCがマルウェア感染	委託先管理の問題
ムラウチドットコム	7,716,811件	Webシステムの脆弱性から横展開	防げた可能性あり
タイムズカー	約660万アカウント	未公表	保存方針が被害を拡大
ブックオフ	6,383,279人	未公表	不明
ヤマト運輸「クロネコ代金後払い」	約526万件	未公表	不明
アフラック生命	約440万人	照会への制御不足（通常利用と同じ形式）	被害の縮小は可能だった
デジタル庁GSS	約24.6万件	事前に把握していたVPN機器の脆弱性	防げた可能性が高い
YCC情報システム	山形市だけで約50万件（おそれ）	管理者認証情報の推測・取得	防げた可能性が高い
IDCFクラウド	495の企業・自治体に影響	特定済みだが非公表	不明

攻撃はどこから入ってきたのか

JPCERT/CCは、今回の一連の事案で見られる攻撃を大きく4つの類型に分けています。ただし、すべての事案に同じ手法が使われたわけではない、とも明記しています。

1. 既知の脆弱性や管理不備の探索：放置された設定ファイルやバックアップファイルなどを探し出すもの
2. APIキーの悪用：スマホアプリの解析などで得たAPIキーを使い、内部のAPIを不正に操作するもの
3. BIツール「Metabase」の脆弱性：SQLインジェクションの脆弱性（CVE-2026-72898）を突くもの
4. 簡易Webシェルの設置：公開Webサーバーから到達できるアプリケーションサーバーに、遠隔操作用の仕掛けを置くもの

また、ランサムウェアに限ると、入口は依然としてVPN機器とリモートデスクトップです。警察庁の統計では、2026年上半期のランサムウェア被害は123件と半期で過去最多で、うち79件が中小企業でした。感染経路の有効回答36件のうち、VPN機器が18件、リモートデスクトップが9件で、全体の75％を占めています。

なお、「AIが攻撃に使われたのでは」という見方も出ています。サイバーセキュリティクラウド社は、同じ攻撃者とみられる者が約40分間に326のIPアドレスを使い分け、1,200件を超えるアクセスで侵入の糸口を探っていたと報告しました。ただし、AIの利用を直接示すログは確認されておらず、あくまで振る舞いからの推測にとどまります。

事件ごとに見る「防げた可能性」

ここからは、原因が公表されている主な事件を取り上げ、何が問題だったのかを見ていきます。

デジタル庁GSS：知っていた脆弱性から侵入された

政府職員などが使う業務基盤「ガバメントソリューションサービス（GSS）」では、保守運用向けVPN機器の脆弱性を悪用されて侵入され、約24.6万件の情報が流出しました。マイナンバーや口座情報は含まれていません。

注目すべきは、デジタル大臣が会見でこの脆弱性の存在をインシデント以前から把握していたと述べた点です。既知の脆弱性にすぐパッチを当てていれば防げた可能性が高い事件といえます。ゼロトラストを導入していても、保守用の「裏口」が残っていればそこが入口になる、という教訓も残しました。判明から公表まで約2か月半かかった点も課題です。

YCC情報システム：管理者パスワードが破られた

山形県の自治体などからシステム業務を受託していた同社は、2026年4月にランサムウェアの被害を受けました。ネットワーク機器の管理者アカウントの認証情報が、推測または取得されて内部へ侵入されたと推定されています。

強いパスワードと多要素認証、ログイン試行の回数制限、管理画面をインターネットに公開しない、という基本対策で防げる類型です。

一方で、良い点もありました。メールなどの情報系システムと業務用PCを別の環境で運用していたため、そちらは影響を受けませんでした。ネットワークを分けておくことが被害を限定した好例です。なお外部の専門機関は、実際に情報が外部へ送信された明確な痕跡は確認していないと報告しています。

Eストアー「ショップサーブ」：約2か月半、気付けなかった

ネットショップ構築サービスを提供するEストアー（BASE子会社）では、サーバー上で動くアプリケーションの脆弱性を悪用され、データベースの情報が外部へ送信されていました。対象は利用店舗・過去の利用店舗あわせて7,858店舗、購入者など約2,335万6,000人に及び、約209万6,900人分はカード番号の一部（先頭6桁と下4桁）や有効期限も含まれていました。

当初は約2時間の不正アクセスとされていましたが、のちに2026年5月21日〜8月1日の約2か月半に訂正されました。被害を大きくした最大の要因はこの検知の遅れです。データベースからの大量読み出しや、外へ向かう通信の異常を監視していれば、被害は小さくできたはずです。また、多くの店舗のデータを1つの基盤に集めていたため、1回の侵害が7,858店舗に広がりました。

Gyazo：削除したはずのデータまで流出

画像共有サービスGyazoでは、画像アップロードサーバーの脆弱性を突かれてシステム上で任意のコマンドを実行され、データベースに到達されました。ユーザー関連データ約2,362万件、画像のメタデータ約4.9億件が流出し、続報では過去に削除された画像のメタデータ約1.74億件も含まれていたことが分かりました。

ファイルのアップロード機能は狙われやすい場所です。アップロードを受け付けるサーバーからデータベースへ簡単に到達できないよう、ネットワークと権限を分けておくことが基本になります。削除済みデータの情報が残っていたことは、データの保存期間の問題でもあります。

ムラウチドットコム：1か所の穴から社内に広がった

家電通販のムラウチドットコムでは、Webシステムの一部にあった脆弱性を起点に、複数のシステムへ次々と侵入（横展開）されました。氏名・住所・生年月日など7,716,811件が流出しましたが、カード情報とパスワードは含まれていません。

脆弱性診断と、外部公開サーバーだけでなく内部サーバーまで含めたパッチ適用、そしてネットワークの分離や認証情報の使い回し防止が鍵だったと考えられます。

KDDI：ゼロデイ攻撃でも「被害の大きさ」は変えられた

BIGLOBE、J:COM、ニフティなどISP6社が使うKDDIのメールシステムでは、第三者製ソフトウェアの脆弱性が悪用されました。これは、ソフトの開発元すら把握していなかった「ゼロデイ脆弱性」です。パッチがまだ存在しないため、侵入そのものを防ぐのは困難でした。

しかし、被害の大きさは別の話です。メールアドレス約1,223万件のほか、パスワード約762万件が流出し、個人情報保護委員会はこのパスワードが平文（暗号化もハッシュ化もしないそのままの状態）で保存されていたと認定しました。平文保存は一部のプロバイダ側の事情によるものでしたが、適切にハッシュ化していれば、不正ログインという二次被害のリスクは大きく下げられたはずです。約1か月にわたって侵害に気付けなかったことも、被害を広げました。

アフラック生命：正規の利用と見分けがつかなかった

アフラックでは、オンライン相談などのサービスを通じて、顧客約440万人の情報が取得されました。うち約22万人は保険料の振替口座の情報も含みます。

攻撃のアクセス形式が通常の利用と同じだったため、既存の検知機能では直ちに見抜けませんでした。同社は、設計時のセキュリティレビューや侵入テストは行っていたものの、今回の手口のリスクは想定できていなかったと自己分析しています。

侵入を完全に防ぐのは難しかったものの、次の2つがあれば440万人規模の大量取得は防げた可能性が高いと考えられます。

• 認可：照会のたびに「この利用者にこのデータを見る権限があるか」を確認すること
• レート制限：一定時間内に照会できる件数に上限を設けること

skyticket・Studio：鍵と金庫を一緒に置いていた

旅行予約サイトskyticketでは、管理機能を不正に操作され、他のサーバーやクラウドへ到達されました。当初は「カード番号は保存しておらず流出していない」としていましたが、のちに訂正し、最大6,140名のカード情報の流出を公表しました。

原因は、2018年に決済方式を切り替えた際、カード情報そのものは削除したものの、会費の支払い情報の変更履歴（ログ）が削除されずに残っていたことでした。しかもそのログは暗号化されていたものの、暗号を解くための情報も一緒に取得されてしまいました。

ノーコードWeb制作サービスのStudioでも同様に、暗号化していたデータと、復号に必要な鍵が同じ不正アクセスで読み出されています。鍵をデータと同じ場所に置けば、暗号化は事実上意味を持ちません。金庫と鍵を同じ引き出しにしまっていたようなものです。鍵は専用の鍵管理サービスなどで分けて管理する必要があります。

その他の事件から見える教訓

• NEXT STAGE、VOISING：BIツールMetabaseの脆弱性やアカウントが悪用されました。Metabaseは2026年8月6日に脆弱性を公表し、JPCERT/CCも8月14日に注意喚起を出していたため、修正版を適用していれば防げた可能性が高い事件です。
• トイポアプリ：一部のAPIで、権限のない第三者が他人の情報を取得できる状態でした。認可不備の典型例です。
• コミューン：非公開コミュニティの招待リンクを不正に取得され、管理者になりすまされました。利用企業にも影響が広がっています。
• 楽天ドライブ：管理用アカウントの認証情報を不正に取得され、約8か月間にわたってデータを閲覧・取得されていました。
• 第一興商：委託先の従業員PC1台がマルウェアに感染し、そこに一時保存されていた約872万4,000件が漏えいのおそれとなりました。大量の個人データを端末に置かせない、という委託契約上の取り決めが欠けていました。

原因がまだ分からない大型事件

タイムズカー、焼肉きんぐ、ヤマト運輸、ソースネクスト、ブックオフ、バーガーキングなどは、2026年10月19日時点で侵入経路が公表されていません。ここでは推測で手法を書くことは控えます。

ただし、タイムズカーについては、被害を大きくした要因が分かっています。約660万アカウントの情報が流出し、そのうち約160万アカウント分は運転免許証などの本人確認書類の画像でした。同社はこの画像を、会員期間中に加えて退会後も7年間保管していたのです。

同社は10月16日、確認後は画像を保有しない方針に変え、保有中の画像を10月末までに削除すると発表しました。最初から「確認が終わったら持たない」設計にしていれば、約160万件の本人確認書類の流出は起きなかったことになります。侵入経路などの詳細は10月23日に案内される予定です。

同じくヤマト運輸の「クロネコ代金後払いサービス」でも、2018年10月からの約8年分の利用者情報約526万件がまとめて持ち出されました。

また、IDCフロンティアのクラウドがランサムウェア被害を受けた件では、495の企業・自治体に影響が出ました。スナップショット（バックアップ）機能を使っていた契約者はデータを取り出せたことが確認され、利用者側のバックアップの有無が復旧の明暗を分けました。

被害を大きくした3つの共通点

個々の事件を並べると、被害を大きくした原因には共通するパターンが見えてきます。

もう1つ見逃せないのが、防御側の情報共有不足です。JPCERT/CCは、技術的な情報の共有が不足しており、把握している情報は限定的で断片的だと述べています。「同種の攻撃を誘発するおそれ」などを理由に手法を公表しない企業も多く、他社が同じ穴を塞ぎにくい状況が続いています。

企業がすぐに行うべき対策

国や専門機関の注意喚起をもとに、優先度の高い順に整理します。

1. 直近1か月のログを点検する

IPAは、まず直近1か月、その後3か月へと広げてログを確認するよう呼びかけています。見るべきポイントは次のとおりです。

• APIへの大量アクセス
• 403／404／503エラーの急増
• 一般利用者には許していない管理機能の利用
• 作った覚えのないアカウントや、無効化したはずのアカウントの有効化

異常があれば、すぐにインシデントとして扱い、専門ベンダーに調査を依頼します。

2. 外部公開の入口を塞ぐ

• VPN機器、Webアプリ、BIツール、業務用SaaSの脆弱性に修正を適用する（内部サーバーも対象）
• 不要な管理画面の公開をやめる
• 管理機能はIPアドレス制限と多要素認証で守る

3. APIを総点検する

• 管理対象から漏れているAPIがないか棚卸しする
• 認証に加えて、リクエストごとに認可を確認する
• レート制限を設ける
• レスポンスから不要な項目を除く
• IDを連番にせず、推測できない値にする
• APIトークンに有効期限を設ける

4. 認証と権限を見直す

• 管理者・保守用アカウントや社外からのアクセスには、フィッシングに強い多要素認証を必須にする
• 閲覧権限と更新権限を分ける
• 退職者や使っていないアカウントはすぐ無効化する

5. データを減らし、守る

• 保存期間と利用目的を確認し、不要なデータを削除する
• 本人確認書類の画像は、確認が終わったら保有しない
• 暗号鍵はデータと別の場所で管理する
• パスワードは強いハッシュ方式で保存する

6. 侵入される前提で備える

• 大量の照会や外部送信を検知・遮断する仕組みを持つ
• EDRやIDS/IPSを導入する
• ネットワークを分離する
• オフラインやスナップショットのバックアップを持つ

7. 委託先とクラウドを管理する

• 委託契約でセキュリティ要件を定め、渡す情報を最小限にする
• 委託先の端末に大量のデータを保存させない
• グループ会社が委託先でも、外部の委託先と同じ基準で監督する

8. 被害の情報を共有する

技術情報を国家サイバー統括室、所管省庁、JPCERT/CCへ速やかに提供します。経済産業省は、提供された情報を事業者の同意なく公表しないとしています。

私たち個人が今すぐできること

企業側の対策を待つだけでなく、利用者の側でもできることがあります。デジタル大臣が呼びかけた基本の3つから始めましょう。

さらに、状況に応じて次のことも確認しておくと安心です。

• 流出元を名乗る詐欺に注意する：流出の通知が出た直後は、その会社を装ったフィッシングが増えます。ヤマトやskyticketの件でも確認されています。
• 免許証画像が流出した場合：公安委員会で免許証を再交付してもらうと、顔写真と免許証番号を変更できます。信用情報機関（JICC・CIC）への本人申告制度の利用も検討してください。
• カード情報の一部が流出した場合：利用明細を確認し、必要ならカード会社に再発行を相談しましょう。
• 使っていないサービス：退会してもデータが残る場合があります。退会前に登録情報を消せるか確認しておくと安心です。

まとめ：「侵入されない」と「盗まれても被害が小さい」の両方を

2026年に相次いだ大規模流出を振り返ると、多くの事件は既知の脆弱性への対応、APIの認可、管理者アカウントの保護という基本で防げたか、被害を大きく減らせた可能性があります。最新の攻撃手法よりも、基本の抜け漏れが突かれているのが実情です。

一方で、ゼロデイ攻撃や正規の利用を装ったアクセスのように、侵入を完全には防げないケースもあります。だからこそ、必要のないデータは持たない、鍵は分けて管理する、異常に早く気付くという「侵入される前提」の備えが欠かせません。

私たち利用者にとっても、パスワードの使い回しをやめ、多要素認証を設定するだけで、二次被害のリスクは大きく下げられます。今日のうちに、よく使うサービスの設定を一度見直してみてはいかがでしょうか。

参考資料

• Eストアー プレスリリース
• Impress Watch（Eストアー関連報道）
• ITmedia NEWS（Gyazo）
• INTERNET Watch（KDDI）
• アフラック生命保険 調査結果（PDF）
• ITmedia ビジネスオンライン（デジタル庁GSS）
• INTERNET Watch（ムラウチドットコム）
• YCC情報システム 第五報
• ITmedia NEWS（Studio）
• skyticket お知らせ