情報漏えいはなぜ起きる？｜国内事例から考える情シス・インフラの対策

はじめに

2026 年の夏から秋にかけて、EC サイトの基盤、カーシェアリング、チケット販売、小売アプリ、証券会社の委託先、報道機関、研究機関、大学で、不正アクセスや情報漏えいの公表が続きました。ニュースを見て「自社は大丈夫か」「どこから確認すればよいか」と考えた情シス・インフラ担当者も多いと思います。

本記事では、2026 年 7 月 6 日〜10 月 6 日に公表された国内の主な事例を、各組織の公式発表をもとに整理します。確認基準日は 2026 年 10 月 7 日（日本時間）です。全件を網羅した一覧ではなく、主に不正アクセスに伴う事例を選んでいます。

結論として、今回の公表事例だけで国内の漏えいの増加やその原因を断定することはできません。一方で、海外の脅威分析では、攻撃者が AI を使って標的の調査や文面作成、ツール開発を効率化し、一部では攻撃工程を自動化している事例が観測されています。攻撃の効率化・高速化を踏まえると、弱点を把握するだけでなく、対策までの時間を短くし、侵害された場合の権限とデータの範囲を限定することが重要になります。

直近 3 か月の主な国内情報漏えい・サイバー攻撃事例

2026 年 7 月 6 日〜10 月 6 日に公表された事例のうち、本記事で公式発表の内容を確認できた 9 組織 10 事案を、公表日順に掲載します。日本経済新聞社は別々の 2 事案を公表しているため、2 行に分けています。大阪公立大学は、10 月 6 日時点で個人情報流出の有無が調査中のため、漏えい事例ではなく関連するサイバー攻撃事例として区別しています。

公表日（続報）	組織・対象	状況	公表された規模	主な対象情報・補足
8/1（第 2 報 8/2）	Eストアー「ショップサーブ」	漏えい確認	8,853,839 件（人数ではない）	購入者情報、会員 ID・パスワード（暗号化された状態で管理と公表）、カード名義・番号の一部・有効期限、店舗の管理画面などの ID・パスワード、店舗への振込先口座情報。発生期間は 5/21〜8/1、原因の詳細は調査中
8/7（8/28 更新）	科学技術振興機構（JST）	漏えいの可能性	メール約 18,000 件（役職員 12 名のメールボックス）	メールに含まれる外部のメールアドレス約 1,400 件、役職員のメールアドレス約 1,000 件。7/28 に外部機関から情報提供
9/25（第 2 報 9/28、第 3 報 9/29）	タイムズカー	漏えい確認	約 660 万アカウント（本人確認書類約 160 万件は内数）	氏名、住所、生年月日、電話番号、メールアドレス、運転免許情報、本人確認書類情報、パスワード（復元できない形式で保管と公表）、連携サービス ID など。対象者により異なり、退会者や入会未完了の申込者を含む。カード情報は漏えいなし
9/29	イープラス「スマチケ」	漏えい確認	1,463 件	払戻し管理システムの申請情報（メールアドレス、カナ氏名など。払戻し方法により振込先口座や送付先の情報）。会員情報とは独立したシステムで、カード情報とパスワードは対象外
10/2（10/5 会見）	大阪公立大学	ランサムウェア攻撃と判断。個人情報流出の有無は調査中	未確定	仮想化基盤の大規模障害により、学内ネットワーク、メール、Web サイト、教務・財務・人事給与などの多くのシステムが停止
10/4	日本経済新聞社（Google Workspace）	漏えいの疑い	1,646 人分	社員や取引先などのメールアドレスや氏名など。読者・取材先は含まれない。7 月下旬以降の不正ログインを 8 月上旬に Google からの通知で把握
10/4	日本経済新聞社（Microsoft 365、別事案）	漏えいとみられる（件数は調査中）	なりすましメール約 9,000 件を送信（漏えい件数ではない）	送信先のメールアドレス・氏名と一部メールの内容。9/30 に悪性サイトへ誘導するメールが送信された
10/5	大和証券（外部委託先の事案）	漏えいの可能性	約 11 万名（個人を特定できない問い合わせ情報を含めると約 22 万件）	顧客の氏名、メールアドレス、口座番号など。問い合わせ管理などを委託している外部事業者のサーバーへの不正アクセスによるもので、大和証券のシステムへの不正アクセスは確認されていないと公表
10/5	焼肉きんぐ（物語コーポレーション）	漏えい確認	10,788,963 件	公式アプリの会員番号、登録名、メールアドレス、電話番号。侵入経路の詳細は調査中
10/6	ミスターマックス	一部流出を確認	流出の可能性がある対象 最大 1,735,154 人	会員 ID、氏名、メールアドレス、電話番号（登録状況により異なる）。住所、生年月日、カード情報、パスワード、購入履歴は流出なしと公表

表の「公表された規模」は、件数、人数、アカウント数、メール件数、送信数と単位がそろっていません。そのため、各行の数字を合算したり、大小で比較したりすることはできません。また、表の対象情報は各組織が公表した範囲で、対象者全員の全項目が漏えいしたことを示すものではありません。

参考: Eストアー「不正アクセスによる個人情報漏えいに関するお知らせ（第2報）」
“対象となるお客様の人数を示すものではありません。”
https://estore.jp/press/20260802/

このほかの出典は、各組織の公式発表です。

• 科学技術振興機構: 不正アクセスによる情報漏えいの可能性に関するお詫びとお知らせ
• タイムズカー: 第 2 報 / 第 3 報
• イープラス: 公式発表（9/29）
• 大阪公立大学: 情報基盤システムにおける障害に関する記者会見を実施
• 日本経済新聞社: 不正ログインによる情報漏洩について / サイバー攻撃による情報漏洩、不審メールの送信について
• 大和証券: 公式発表（10/5、PDF）
• 物語コーポレーション: 公式発表（10/5）
• ミスターマックス: 不正アクセスによる情報流出に関するお詫びとお知らせ

情報漏えいが相次ぐ背景を考える――AI と攻撃・運用の変化

上の一覧では、10/2〜10/6 の 5 日間に 5 組織の公表が重なりました。ただし公表日は発生日ではありません。日本経済新聞社の Google Workspace の事案のように 7 月下旬以降の不正ログインが 10/4 に公表された例もあれば、タイムズカーのように検知当日に公表された例もあります。また、個人情報保護委員会の年次報告にある漏えい等報告の処理件数は誤送付や紛失も含む年度単位の数字で、この問いに直接答える指標ではありません。

そこで本章では、件数の増減ではなく「なぜ今、侵入されやすく、被害が大きくなりやすいのか」という構造を、次の 3 つの要因から考えます。

1. 攻撃に必要な手間と時間: AI による調査・文面作成・開発・自動化の支援
2. 守る範囲の広さ: 公開システム、メール、周辺システム、委託先への分散
3. 侵害後の被害規模: アクセスできる権限と、保管された情報の種類・量

海外で観測された変化

攻撃者による AI の利用が海外の脅威分析で観測されており、一部では攻撃工程の効率化や自動化が進んでいること。

運用への影響をどう考えるか

防御側の更新や検知後の対応の速さが変わらなければ、対策が終わる前に攻撃を受けるリスクが高まると考えられること。

国内事例との関係は未確認

今回の国内事例に AI が関与したこと、国内の漏えいが増えていること、その主な原因が AI であること。いずれも公表資料からは確認できません。

要因 1: AI で攻撃の手間と時間が減っている

まず、海外で観測されている事実を整理します。

Google の脅威インテリジェンスグループ（GTIG）は、2026 年 2 月の報告で、2025 年第 4 四半期に国家支援型の攻撃グループなどが生成 AI を標的の調査、フィッシングの文面作成、悪意あるツールの開発やデバッグに使っていたと報告しています。特に文面については、従来の見分け方だった不自然な文法や言い回しを、攻撃者が AI で消せるようになりつつあると指摘しています。同報告が対象とした 2025 年末の活動では既存の作業の効率化が中心でしたが、実行時に生成 AI の API を呼び出してコードを生成するマルウェアなど、新しい機能を試す動きも紹介されています。

2026 年 9 月の GTIG の報告では、さらに一部の攻撃者が AI エージェントを使い、脆弱性のスキャンから認証情報の収集までを自動化した事例が紹介されています。ある事例では、侵害したクラウド基盤を利用し、大量の認証情報を収集する活動を 6 時間未満で計画・構築・実行したとされます。これは特定の活動にかかった時間で、あらゆる侵入や漏えいが同じ速さで進むという意味ではありません。また、この観測事例だけで、攻撃者全体への普及度までは判断できません。

参考: Google Threat Intelligence Group「From Prompting to Autonomy: The Evolution of Adversarial AI」
“compressing the traditional window for defenders to respond”
（防御側が対応できる従来の時間的猶予を縮めている）
https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai

英国の NCSC（国家サイバーセキュリティセンター）は、2025 年 5 月に公表した2027 年までの評価で、AI によって脆弱性の公開から悪用までの時間はほぼ確実に短くなり、既知の脆弱性を悪用する能力も高まるとしています。あわせて、AI を使った脅威に追随できるシステムと、取り残されて脆弱になるシステムとの間に格差が生じるとの見通しも示しています。これは観測結果ではなく、将来に向けた評価です。

ここからは筆者の考察です。攻撃者の作業ごとに、変化と防御への影響を整理すると次のようになります。

攻撃者の作業	AI による変化（観測・評価）	防御への影響（筆者の考察）
標的の調査	組織の構造、担当者、メールアドレスなどの収集と整理が速くなる	担当者や業務に合わせた接触・なりすましを準備しやすくなる
文面の作成	不自然な文法などの手がかりが少ない、標的に合わせた文面を作りやすくなる	利用者が見抜くことに頼る対策の効果が下がり、MFA や送信元の認証など仕組みによる対策の比重が高まる
ツール開発・脆弱性の悪用	コード作成やデバッグが効率化し、公開から悪用までの時間が短くなる見通し	修正日が同じでも、悪用が始まる時期が早まれば、悪用可能な状態で残る期間が長くなる
スキャンと攻撃工程の自動化	一部の攻撃者が、脆弱性のスキャンから認証情報の収集までを AI エージェントで自動化	棚卸しから漏れた公開システムや修正が遅れたシステムが短時間で見つかる。検知後の遮断や無効化の判断が翌営業日になれば、その間に取得される情報が増える

つまり、AI によって攻撃者の「手間」と「時間」が減るほど、防御側の弱点の放置期間や判断の遅れが、そのまま被害の差になりやすくなると考えられます。守る側に問われるのは、弱点を見つけることに加え、修正や遮断までの時間をどこまで短くできるかです。なお、GTIG の報告でも脆弱性の発見や修正に AI を使う防御側の取り組みが紹介されているように、防御側でも AI の活用は進んでいます。攻撃側だけが進歩するわけではありません。AI の活用に加え、更新・監視・対応を実行できる体制も重要です。

要因 2: 守る範囲が複数に分かれている

攻撃者は弱い箇所を 1 つ見つければよい一方、防御側はすべての入口を管理する必要があります。今回の国内事例では、不正アクセスを受けたシステムが事例ごとに異なっていました。以下は公表事実から考えられる一般的なリスク構造で、各組織の管理不備を示すものではありません。また、多くの事例では最初の侵入経路や悪用された脆弱性・設定の詳細は公表されていません。

利用者向けサービスを支えるシステム

Eストアーは、サーバー上で不正なプログラムが実行され購入者情報が外部へ送信されたと公表しています。ミスターマックスは、サービスを構成するソフトウェアの機能が不正に利用されて侵入されたと説明し、タイムズカーも Web システムへの不正アクセスを公表しています。

業務アカウントとメールボックス

日本経済新聞社の 2 事案は社員が業務で使うサービスのアカウントへの不正ログインに関するもので、Microsoft 365 の事案ではアカウントから取材先などへなりすましメールが送信されました。JST も役職員のメールボックス内のメールが漏えいした可能性を公表しています。

本体とは別の周辺システム

イープラスでは、会員情報とは独立した払戻し管理システムが対象になりました。

外部の事業者

大和証券は、問い合わせ管理などを委託している外部事業者のサーバーへの不正アクセスにより、顧客情報が漏えいした可能性があると公表し、自社システムへの不正アクセスは確認されていないと説明しています。Eストアーの事案も、利用店舗から見れば、自社サイトの顧客情報がプラットフォーム事業者のサーバー上で漏えいした例です。

要因 1 と組み合わせると、守る範囲が広いほど「調査の速い攻撃者に先に見つけられる弱点」が残りやすくなります。自社への侵入が確認されなくても、委託先に保管した情報や、業務アカウント 1 つから見える情報は漏えいの対象になり得ます。メールアカウントの認証情報がどのように取得されたかは各事案で公表されていませんが、開発端末や CI/CD の認証情報からクラウドへ侵害が広がるケースについては、サプライチェーン攻撃対策｜開発環境からのクラウド侵害を防ぐ確認点で解説しています。

要因 3: 侵害後の被害は権限とデータの範囲で広がる

侵入を防げなかった場合、保管されていた情報の種類・量に加え、侵害された権限やアクセス可能な範囲が、漏えいの規模を左右します。タイムズカーの対象には退会済みの方や入会を完了していない申込者が含まれ、約 160 万件については本人確認書類の画像などの情報も対象になりました。Eストアーでは、購入者の情報だけでなく、店舗の管理画面や FTP などの ID・パスワード、店舗への振込先口座情報も対象になっています。

参考: タイムズカー「タイムズカーWebシステム」への不正アクセスに関する調査結果および今後の対応について（第2報）
“パスワードは復元できない形式で保管しており”
https://share.timescar.jp/news/2026/0928/1815.html

タイムズカーはパスワードを漏えいした情報に含めたうえで復元できない形式で保管していたと説明し、Eストアーも会員 ID・パスワードを暗号化された状態で管理していたと公表しています。保管方式によって悪用のしやすさは変わりますが、「平文のパスワードが流出した」とも「影響がない」とも読み替えないことが大切です。

攻撃工程が短時間で進む場合、検知後の対応だけでは情報取得に間に合わないおそれがあります。そのため、平時から各アカウントの参照範囲を絞り、権限昇格や別システムへの横展開を抑える構成にしておくことが重要です。大阪公立大学のように、共有の仮想化基盤が止まると多くの業務システムが同時に使えなくなる事例も、侵害の影響範囲が構成によって決まることを示しています。

なお、発見のきっかけは自社の監視とは限りません。JST は外部機関からの情報提供、日本経済新聞社の Google Workspace の事案は Google からの通知で把握したと公表しています。自社のログで気づけるか、外部から連絡を受けたときに判断と対応を始められるかの両方が問われます。

情シス・インフラ担当者が見直す情報漏えい対策

背景の考察を踏まえると、対策は「弱点を把握する」「対策までの時間を短くする」「侵害時の権限とデータを限定する」の 3 方向で考える必要があります。ここでは対策を 5 つの目的に分け、確認する内容、未完了と判断する状態、確認する相手を整理します。

5 つの目的で確認項目を分ける

目的	何を確認するか	未完了と判断する状態	誰と確認するか
侵入を防ぐ	インターネットから到達できるシステム・管理画面・リモートアクセスの一覧、保守責任者、MFA（多要素認証）の適用範囲と例外、緊急性の高い修正を判断・適用するまでの時間	一覧にない公開システムがある、保守責任者が不明、緊急修正の判断者と適用までの目標時間が決まっていない、または実績を測っていない、MFA の実際の設定と一覧を照合していない、例外アカウントに理由と見直し時期が記録されていない	インフラ・アプリ担当、クラウド管理者、保守委託先
被害を限定する	利用者・管理者・サービスアカウントの権限、1 つのアカウントで取得できる情報の範囲（一括エクスポートや API での取得を含む）、個人情報を持つ DB・ストレージ・メールボックスへの経路、委託先の接続方法・再委託・データ保有範囲	共有の管理者アカウントが残っている、強い権限のアカウントが取得できるデータの範囲を把握していない、委託先が保有するデータの範囲を契約や台帳で説明できない	システムオーナー、委託先、契約担当
異常に気づく	認証、権限変更、データ取得などのログの有無、保存先、保存期間、閲覧権限、検知後に誰が判断し、遮断・無効化へ進むか	侵害されたアカウントの権限でログを削除できる、保存期間が調査に足りるか判断していない、アラートを受けても遮断・無効化を判断できる担当者と権限が決まっていない（夜間・休日を含む）	運用担当、監視の委託先、法務（保存期間）
漏えい規模を抑える	保存目的と期限、退会者や旧システムの情報、本人確認書類、エクスポート・バックアップ・検証環境などの複製の所在	保存・削除の判断根拠が記録されていない、期限を過ぎた不要なデータが実際に残っている、複製の所在を説明できない	業務部門、個人情報保護・法務担当、システム担当
発覚後に動く	連絡体制、証拠保全の方針、外部専門家の相談先、侵害が疑われるアカウント・セッション・トークンへの対応範囲、復旧後の監視	連絡先が古い、初動が再起動や初期化になっている、認証情報を無効化する範囲が決まっていない	経営層、法務・広報、外部専門家、委託先

ログの保存期間やアラートのしきい値は、業務、システム、法令上の要件によって適切な値が異なります。一律の日数や件数を基準にするのではなく、「侵害に気づくまでに時間がかかった場合でも、調査に必要な期間をさかのぼれるか」という観点で判断することをおすすめします。

公表事例から作る自社の確認表

次の表は、公表事例で明らかになった論点を、自社の棚卸しに置き換えたものです。左列は事例から得た着眼点で、各組織の管理状況を評価するものではありません。右列の条件は、方針や台帳を作った段階で止めず、実際の設定やデータを確認した段階までを書いています。方法を決めただけの項目は「未確認」として残すことをおすすめします。

事例からの着眼点	自社の確認対象	確認できたと判断する条件
メールボックスに保管されたメールと、そこに含まれる社外の連絡先が対象になった（JST、日本経済新聞社）	メール・共有ドライブに保管された個人情報、メールアカウントの認証設定、外部アプリとの連携	管理画面の実際の設定と利用者一覧を照合し、MFA 未適用・例外アカウントを特定している。連携アプリも管理画面で一覧を確認している
不正ログインされたとみられるアカウントから、社外へなりすましメールが送信された（日本経済新聞社）	侵害時の社外への注意喚起の手順、送信ログの取得方法	送信ログから送信先を実際に抽出できること、その保存期間を確認している。注意喚起の文面と承認者を決めている
本体とは独立した払戻し管理システムに口座情報などが保管されていた（イープラス）	キャンペーン、払戻し、問い合わせ対応など、周辺システムや期間限定システムの個人情報	周辺システムが台帳に載り、保守責任者と保存期限が記載されている。停止したシステムのデータが実際に削除されているかを確認している
退会者や入会未完了の申込者の情報が対象に含まれた（タイムズカー）	退会者、未完了の申込み、休眠会員のデータ	保存理由と期限を定義したうえで、期限超過データの有無を実データで確認し、削除状況または保存を続ける例外の根拠を記録している
本人確認書類の画像などが対象になった（タイムズカー）	本人確認書類の画像の保存場所、参照権限、保持期間	保存の要否と期間の根拠が記録され、実際の参照権限を一覧化して不要なアカウントを除外している
プラットフォーム事業者や委託先のサーバーで、自社の顧客情報が対象になった（Eストアー、大和証券）	利用している EC 基盤・SaaS・委託先が保有する自社の顧客情報、再委託の有無、事故時の連絡経路、管理画面の認証設定	サービス・委託先ごとに保有データと連絡窓口が一覧化され、保有データは契約や委託先の回答で裏付けている。管理画面の二段階認証などは実際の設定で有効化を確認している
サービスを構成するソフトウェアの機能が不正に利用された（ミスターマックス）	公開サービスを構成するソフトウェア（CMS、プラグイン、ミドルウェアなど）	構成要素と版を実環境で確認して台帳と一致させ、更新の責任者を決めている。使っていない機能の無効化を設定で確認している
仮想化基盤の障害で多くのシステムが同時に停止した（大阪公立大学）	共有基盤に依存するシステム、仮想化やバックアップの管理系の認証とネットワーク	基盤停止時に止まる業務を一覧化している。手順書の整備と復元テストを区別し、復元を試していない場合は未検証と記録している

情報資産の一覧を作る際は、IPA の中小企業の情報セキュリティ対策ガイドライン（第 4.0 版）の付録「資産管理台帳（サンプル）」や「中小企業のためのクラウドサービス安全利用の手引き」が参考になります。中小企業向けの資料ですが、台帳の項目や外部サービス利用時の確認観点は、規模を問わず活用できます。

確認の優先順位

すべてを同時に進めることは現実的ではありません。次の順で範囲を絞ることをおすすめします。期限や所要時間は、組織の規模と体制に合わせて設定してください。

対策ごとの限界を理解しておく

個々の対策には、効果が及ぶ範囲があります。過信を避けるため、次の点を押さえておくことをおすすめします。

MFA

パスワードだけによる不正ログインの防止につながりますが、効果は適用したアカウントと認証経路に限られます。例外アカウントや、MFA を通らない古い認証方式、発行済みのトークンが残っていないかも確認対象です。

暗号化

保存データの暗号化は、媒体の持ち出しなどには有効ですが、正規の権限でアプリケーションやデータベースにアクセスされた場合、復号された状態で取得される可能性があります。鍵の保管場所と、鍵を使える権限の範囲を併せて確認します。

バックアップ

ランサムウェアなどで停止したシステムを復旧するための備えです。漏えいを防いだり、流出した情報を取り戻したりする対策ではありません。また、バックアップ自体も個人情報の複製として管理対象になります。復旧用データを削除や改ざんから守る方法は、S3 Object Lock の設定に関する記事で紹介しています。

不審なアクセスが見つかったときの初動

不審なアクセスや外部からの連絡があった場合、初動では「被害の拡大を止めること」と「後から調査できる状態を残すこと」を並行して進めます。製品やサービスによって有効な処置は異なるため、ここでは考え方を整理します。

被害拡大の防止と証拠保全

不正な通信経路の遮断、侵害が疑われるアカウントの停止を検討します。その際、ログや当時の状態が失われないよう、取得してから処置するか、処置の内容と時刻を記録します。

連絡と相談

社内の責任者、法務・広報、関係する委託先へ連絡し、必要に応じて外部の専門家へ調査を相談します。報告や公表の要否は、技術担当者だけで判断しないようにします。

対応範囲の決定

パスワードの変更だけでは、発行済みのセッションやトークン、API キー、外部アプリ連携が有効なまま残る場合があります。利用しているサービスの公式情報を確認し、無効化する範囲を決めます。

復旧と監視

原因と侵入経路の調査結果を踏まえて復旧し、復旧後も同じ経路や認証情報による再侵入がないかを監視します。

個人情報の漏えい等が発生した場合、一定の要件に該当すると個人情報保護委員会への報告が求められます。同委員会の漏えい等の対応とお役立ち資料では、速報と確報の期限、報告が必要な要件、不正アクセス事例の記入例を案内しています。対象となるかの判断は、法務・個人情報保護の担当部門と行ってください。

中小企業向けには、IPA のガイドラインの付録として「中小企業のためのセキュリティインシデント対応の手引き」が公開されています。また、重要インフラに関わる事業者では、別の制度による報告が求められる場合があります。制度の概要は能動的サイバー防御とは｜届出・報告義務の対象企業と情シスの確認ポイントで整理しています。

まとめ

直近 3 か月の国内事例は、公開システム、業務アカウント、委託先、周辺システムなど、被害を受けた範囲も漏れた情報も事例ごとに異なります。海外では攻撃者による AI の活用で攻撃の効率化・高速化が観測されており、弱点の把握に加えて、対策までの時間を短くし、侵害時の権限とデータの範囲を限定することが重要になります。

• 公表の集中だけでは、国内の増加や共通の原因は判断できない
• AI は攻撃者の調査・文面作成・開発を効率化し、一部で自動化も進む
• 緊急修正の適用や、検知後の遮断までの時間を短くする
• 1 つのアカウントで取得できる情報と、残っている不要なデータを減らす
• 委託先や外部サービスが保有する自社の顧客情報も棚卸しに含める
• 確認方法を決めた段階と、実際に確認した段階を分けて記録する
• 初動では、拡大防止と証拠保全を並行して進める

以上、最後までお読みいただきありがとうございました。