2026年10月の不正アクセス事件一覧｜40件超の共通点とAX企業の対策
- 10/6デジタル大臣が国民向けに、パスワードの使い回し停止・多要素認証・不審なメールやSMSへの注意を呼びかけ
- 10/7〜10/8個人情報保護委員会が事業者向けに注意喚起。続いてJPCERT/CCと警察庁が注意喚起
- 10/9国家サイバー統括室・総務省・経済産業省・IPA・金融庁がそれぞれ注意喚起
- 10/13〜10/14NICTがアプリ解析を起点にしたサーバー攻撃を注意喚起。国家サイバー統括室が各機関の注意喚起をまとめたページを掲載
- 10/16IPAが「不正アクセス特別相談窓口」を開設
- 10/23JPCERT/CCが注意喚起を更新し、ケースE（AIペネトレーションテスト基盤）を追加
- AIが使われたと断定できる痕跡は確認されていない
- 政府はAIの利用も含めて分析を続けている
- 攻撃元のインフラから、AIによる自律型ペネトレーションテストシステムの利用を確認したとしている
- 同じインフラが標的にした日本企業は約20社で、うち9社は同業種のサイトだったと分析している
本記事は、2026年10月26日時点の報道・公表（内閣官房 国家サイバー統括室のまとめページ、piyolog、innovatopia、Impress Watch、ITmedia、ScanNetSecurityなど、各社の発表を伝える報道）をもとにまとめたものです。公表された事案の全件ではなく、確認できた主な事案の一覧です。件数は各社・各機関の発表を、報道や集計サイト経由で確認したもので、一次発表の原文を全件確認したものではありません。詳細は各社の公式発表でご確認ください。なお、この記事は報道・公表資料と一般的な実務知識に基づく解説であり、当メディアや運営会社が事案に対応した経験に基づくものではありません。
2026年10月、日本では不正アクセスと情報漏えいの公表が短い期間に集中しました。本記事では、まず事案と公的機関の動きを整理します。次に、JPCERT/CCとIPAの分析から見えてきた共通点（外部公開アプリ、API、委託先、アカウント）を確認します。最後に、生成AIやAIエージェントの導入、つまりAX（AI Transformation）を進める企業が今すぐ見直すべき対策を考えます。
2026年10月の不正アクセス事件では何が起きた？
2026年10月は大量の個人情報を扱う国内事業者への不正侵入が相次ぎ、木原官房長官が「大変深刻に受け止めている」と述べる事態となりました。
被害が出た業種は幅広く、航空・鉄道・小売・外食・人材・金融・製薬・建設・メディア・大学・自治体に及びます。原因も一つではありません。クラウド基盤へのランサムウェア攻撃、委託先システムへの侵入、スマホアプリやAPIを狙った攻撃などが同じ時期に表に出ました。
政府は「複数の窃取事案」を確認した
国家サイバー統括室は10月9日、事業者システムに侵入され個人情報が盗まれた事案を複数確認したと公表しました。
共同通信などの報道によると、木原官房長官は10月6日の記者会見で、相次ぐ情報流出を「大変深刻に受け止めている」と述べ、攻撃の手口や傾向の分析と、被害の全体像の把握に努めていると説明しました。10月26日には、政府が関係閣僚会議を開き、首相が緊急対策のとりまとめを指示する見通しと報じられています。政府が個別の企業ではなく「複数の事案」として扱った点からは、同じ時期に似た手口の攻撃が広がっていると認識していたことがうかがえます。
2026年10月に確認できた不正アクセス事案の一覧は？
報道で内容を確認できた主な事案は40件以上あります。入口の型で分けると、クラウド基盤・委託先、アプリ・API・Web機能、アカウント・認証情報、社内システムの4つに整理できます。
この一覧は、公表された事案の全件ではありません。報道や集計サイトで確認できた主な事案を、編集部が入口の型ごとに分類したものです（分類は編集部の整理で、各社の発表とは限りません）。件数は各社の公表値で、「最大」「可能性」「調査中」といった区別は出典の表現のまま残しています。
1. クラウド基盤・委託先・再委託先を経由した事案
委託先や基盤事業者への1回の侵入が、複数の委託元の公表につながる連鎖が目立つ。
| 公表日 | 起点 | 公表値・影響 | 経路・補足 |
|---|---|---|---|
| 10/7 | IDCFクラウド | 495の企業・自治体に影響 | ランサムウェア攻撃。10月14日の第5報について、外部への流出はなかったと判断した、と伝える解説記事がある（二次情報）。利用企業の発表は「漏えいの可能性」 |
| 10/9 | （IDCF経由）JR九州 | 最大約130万件（Web会員のメールアドレス） | 氏名・住所・電話番号・クレジットカード番号は対象外としている |
| 10/9 | （IDCF経由）JR東日本 | えきねっと約167万件、大人の休日倶楽部約39万件 | 漏えいの可能性。メール配信用の外部サービスがIDCFの基盤を使っていた |
| 10/9 | Commune | 会員情報の漏えいを公表（人数は報道により異なる） | 委託元のLINEヤフー（1,750名）、スズキヴィレッジ（約3,000名）も公表 |
| 10/6 | i-ask（FAQシステム） | 最大71万3,126件（延べ。最大5社の問い合わせ情報） | 管理サイトへの不正ログイン後、サーバーに不正なプログラムを設置。大和証券（約11万人・約22万件）、シチズン時計（約10万名）、オリックス生命保険（約2.65万件）などが公表 |
| 10/8 | 第一興商 | 約872万4,000件のおそれ（顧客約863万1,000件、従業員約9万3,000件） | 委託先の日本コロムビアグループの従業員PC1台がマルウェアに感染。実際の流出は確認されていないと発表 |
| 10/2〜 | 大阪公立大学 | サーバー約500台が停止 | ランサムウェア攻撃。NECは10/20、委託先が9月下旬に攻撃を受け、盗まれた正規アカウントが悪用されたと公表（大学から見ると再委託先） |
| 10/6 | 旭化成セラピューティクス（Pharma DIGITAL） | 医療従事者最大約51万4,000人、従業員約700人 | 運営委託先が10/2に不正アクセスを報告。サイトを停止 |
| 10/8 | 東京都小平市 | 問い合わせフォームの入力情報が漏えいした「おそれ」 | ホームページの保守委託先が使うクラウド基盤がランサムウェア攻撃を受け、サイトが閲覧できない状態に |
「最大」の件数は、影響を受けた可能性がある範囲の上限です。実際に漏えいした件数ではありません。社内報告や経営層への共有でこの違いを省くと、リスクを過大にも過小にも見積もってしまいます。社内報告では、必ず区別して書きましょう。
FAQシステムやコミュニティ基盤のようなSaaSは、問い合わせ対応や顧客接点の業務で幅広く使われています。顧客から見えるのは委託元の企業名です。そのため、委託先の侵害であっても委託元が公表と顧客対応を担うことになります。
2. アプリ・API・Web機能の不備、管理ツールの脆弱性を突いた事案
会員向けアプリやAPI、管理画面が入口になった事案が、公表件数の大きい順に並ぶ。
| 公表日 | 組織 | 公表値・影響 | 経路・補足 |
|---|---|---|---|
| 10/15 | ソースネクスト | 2,251万9,960件（流出の可能性） | 会員情報を返すためのAPIが悪用された。10/9から不正アクセスを受け、10/13に封じ込め。クレジットカード情報は対象システムに保存されていない |
| 10/15 | skyticket（アドベンチャー） | 約1,464万件 | 経路の異なる3件。最大の件は管理機能の一部が10/2〜4に不正に操作された。10/16の第2報で一部を訂正 |
| 10/15 | バーガーキング公式アプリ（ビーケー・ジャパン） | 約1,118万件 | 10/2〜7に不正アクセス、10/13に判明。クレジットカード番号は保持していない |
| 10/5 | 焼肉きんぐ公式アプリ（物語コーポレーション） | 1,078万8,963件 | 会員管理システムへの不正アクセス。10/2に確認 |
| 10/9 | ブックオフ | 642万7,735件（会員番号ベース）。漏えい対象者は638万3,279人（10/13の第2報） | 会員管理システムへの不正アクセス。不正取得は10/4〜6 |
| 9/28 | タイムズカー（パーク24） | 約660万件のアカウント。うち本人確認書類約160万件 | 9月下旬の公表。10月の対応・報道が続いた |
| 10/8 | ローソン | 約215万件（ローソンID） | 不正アクセス（続報は10/24） |
| 10/6 | ミスターマックス | 最大173万5,154人（10/3時点の会員） | アプリとオンラインストアのサーバーへの不正アクセス |
| 10/9 | バイトル（ディップ） | 最大388万5,771件（メールアドレスのみ） | 不正アクセス。氏名・電話番号・パスワード・カード情報は含まれない |
| 10/15 | ムーンスター | 最大59万3,000人 | オンラインストアのサーバーへの不正ログイン。クレジットカード情報とログインパスワードは対象外 |
| 10/5 | OfferBox（i-plug） | 理論上の最大31万4,009人 | システム設定の不備で、利用企業向けページの通信データに学生の氏名とメールアドレスが含まれていた（5/12〜8/28）。閲覧・流出は確認されていない |
| 10/8 | NewsPicks（ユーザベース） | メールアドレス最大約32.3万件、クレジットカード情報の一部最大約36.2万件（第二報、項目別の数字） | 業務用管理ツールの脆弱性。暗号化パスワードの漏えいは確認されていない |
| 10/5 | 大起水産 | 17万4,933人 | 公式アプリのシステムへの不正アクセス。パスワードは別サーバーで管理 |
| 10/6 | アクティブ（業務用冷凍食品の通販） | 最大54,916件 | SQLインジェクションの後、不正な管理者アカウントが作られて顧客・受注データが出力された形跡 |
| 10/6 | 気象キャスターネットワーク | 最大15,959件 | 9/24から不正アクセス、9/29にサイト改ざん。利用者が外部サイトへ転送される状態に |
| 10/3 | スタディサプリ（リクルート） | 3,687件 | 機能の仕様上の不備が突かれ、メールアドレスが登録済みかどうかを第三者に特定された可能性。氏名・パスワード・決済情報は流出していない |
| 10/6 | nimoca | 521件 | 利用履歴照会サービスへの不正アクセス。カード番号・生年月日・メールアドレス |
| 10/9 | ココナラ スキルマーケット | 履歴書449件、職務経歴書関連書類1,845件 | 不正アクセスを10/8に検知・遮断し、同日に脆弱性を修正 |
| 10/7 | 渋沢MIX（埼玉県） | 約2,200名 | 管理システムの脆弱性が攻撃されたとみられる（調査中）。登録情報の一部が改ざんされた |
| 10/8 | hitmart（アズマ） | 件数は未公表 | 使用終了済みサイトの自動アップデート時にバックドアが混入。ログの保存期間を超えて侵入可能だった |
| 10/6 | ホテルリゾートイン石垣島（リゾーツ琉球） | 17,170人（旅券画像234人分） | 宿泊管理システムへの不正アクセス（9/18〜19） |
| 10/1 | らしんばん | 件数は未公表 | 不正アクセス（9/14〜16）。本人確認書類の情報、買取明細などが対象になりうる |
OfferBoxやスタディサプリの事案は、不正アクセスで盗まれたというより、画面には出ない通信データの中身や、メールアドレスの存在確認ができてしまう仕様が問題になったものです。バックエンドの設計を「アプリからしか呼ばれない前提」で作ると、同じ問題が起きやすくなります。
3. アカウント・認証情報、フィッシングを起点にした事案
正規アカウントの乗っ取りや、フィッシングから侵入された事案は、通常の通信と見分けにくいのが特徴です。
| 公表日 | 組織 | 公表値・影響 | 経路・補足 |
|---|---|---|---|
| 10/16 | 日本経済新聞社（開発用クラウド） | 約183万件（個人情報を含むのは約15万件、残りは識別子のみ） | クラウドにアクセスするための認証情報が窃取された。クレジットカード情報は含まれない |
| 10/4 | 日本経済新聞社（Microsoft 365） | なりすましメール約9,000件 | 社員アカウントへの不正ログイン |
| 10/4 | 日本経済新聞社（Google Workspace） | 社員や取引先など1,646人分の氏名・メールアドレス等が漏えいした疑い | 別の社員のアカウントへの不正ログイン |
| 10/8 | 八十二長野銀行 | 法人627社、個人34名、関係機関11 | 海外企業を装うフィッシングメールをきっかけに、職員のメールに不正アクセス。口座情報・暗証番号の漏えいは確認されていない |
| 10/6 | 楽天ドライブ | 15,382アカウント分の保存データほか | 管理用アカウントの認証情報が不正に取得された |
| 10/8 | hi-ho | 38,509契約（人数ではなく契約単位） | 不正ログイン（二次情報） |
| 10/2 | 講談社BECK | メールアカウント1件、不審メール50件 | 旧講談社ビーシーの従業員1名のメールアカウントへの不正アクセス |
4. 社内システム・サイトへの不正アクセス
企業内部のシステムや、研究・公共機関のサイトも標的になりました。経路が公表されていないものも多くあります。
| 公表日 | 組織 | 公表値・影響 | 経路・補足 |
|---|---|---|---|
| 10/2 | 第一ライフグループ・第一生命保険 | 約12万名（従業員約5万名、退職者約7万名） | 人事システムへの不正アクセス（9/24に検知）。顧客情報への不正アクセスは確認されていない |
| 10/7 | 戸田建設 | 従業員4,778名、取引先メール最大7,200件、取引データ最大6,000件 | 取引先への支払いを管理するシステムへの不正アクセス（10/1〜5） |
| 10/7 | HIS（タイの子会社） | 最大627名（パスポート情報など） | ファイルサーバーへの不正アクセス。検知は2025年12月で、公表までに約10か月 |
| 10/1 | JAEA | 175人分 | 研究支援サイトへの不正アクセス。本人確認書類の画像などを含むファイル367件 |
| 10/2 | JOGMEC | 約8,500件（役職員約1,100、外部約7,400） | メールアドレスの漏えいの可能性 |
| 10/2 | ジャパンタイムズ | 調査中（2001〜2022年8月の人事・取引先情報を含む可能性） | グループ管理サーバーへのランサムウェア攻撃。10/15に、攻撃者が窃取したと主張するデータの公開を確認 |
| 10/9 | キッセイ商事（キッセイ薬品） | 件数は未公表 | 第三者からデータ窃取を知らせるメールが届いた。データ流出の確定ではない |
| 10/20 | GMOインターネットグループ | 影響の可能性があるサーバー26,739件 | 「お名前.com デスクトップクラウド」のFX自動売買専用VPSで、不正プログラムを確認。FX口座での不正取引も報告された。10/24に政府へ能動的サイバー防御を要請（詳しくはGMOの能動的サイバー防御要請の解説） |
なお、ドコモと楽天（グループ）については、攻撃者側が主張しているだけで、両社とも「確認されていない」と回答しています。本記事ではこれらを事実として扱いません。
政府や公的機関はどう対応した？
10月6日のデジタル大臣の呼びかけ以降、約10日間で主要機関が注意喚起を出し、10月16日には相談窓口も開設されました。
国民向け、事業者向け、技術者向けと、対象を分けた発信が短い期間に重なったのが特徴です。
時系列で見る注意喚起
デジタル大臣、個人情報保護委員会、JPCERT/CC、警察庁などが、10月6日から16日にかけて順に注意喚起を出しました。
| 日付 | 機関 | 内容 |
|---|---|---|
| 10/6 | デジタル大臣 | 国民向けに、パスワードの使い回しをやめる・多要素認証を使う・不審なメールやSMSに注意する、の3点を呼びかけ |
| 10/7 | 個人情報保護委員会 | 事業者向けの注意喚起 |
| 10/8 | JPCERT/CC、警察庁 | 注意喚起（JPCERT/CCは10/9・10/23に更新） |
| 10/9 | 国家サイバー統括室、総務省、経済産業省、IPA、金融庁 | 各機関がそれぞれ注意喚起 |
| 10/13 | NICT | 「アプリ解析からのサーバ攻撃」（Androidアプリを手がかりにしたバックエンドへの攻撃）を注意喚起 |
| 10/14 | 国家サイバー統括室 | 各機関の注意喚起をまとめたページを掲載 |
| 10/15 | JPCERT/CC | 攻撃手法の調査結果を公式ブログで公開 |
| 10/16 | IPA | 「不正アクセス特別相談窓口」を開設 |
実務担当者がまず見るべき情報源
まず国家サイバー統括室のまとめページを確認し、更新が続くJPCERT/CCの注意喚起を追いかけるのが効率的です。
JPCERT/CCは10月23日の更新でケースEを追加したように、分析が進むと内容が書き換わります。セキュリティ担当でなくても、AXを推進する立場なら、週に1回程度は更新を確認する担当と手順を決めておくと安心です。自社だけで判断がつかない場合は、IPAの特別相談窓口を使うこともできます。
攻撃の共通点と手口は？
IPAは外部公開アプリやサービスの侵害とアカウント侵害が起点となる傾向を指摘し、特定製品狙いとは断定していません。
特定のソフトウェアの脆弱性だけが原因なら、パッチを当てれば対策はほぼ終わります。今回は入口が分散しており、「自社が何を外部に公開し、誰にアクセスを許しているか」という管理全体が問われているといえます。
JPCERT/CCが整理した5つの類型
JPCERT/CCは攻撃をケースA〜Eの5類型に分けており、10月23日にAIペネトレーションテスト基盤の類型を追加しました。
| 類型 | 内容 | 主な入口 |
|---|---|---|
| ケースA | 既知の脆弱性のスキャン、設定ファイル・バックアップファイルの窃取など管理不備の悪用 | 外部公開サーバー |
| ケースB | API経由の不正操作（スマホアプリを解析してAPIキーやエンドポイントを特定し、内部APIを悪用） | スマホアプリ・API |
| ケースC | Metabaseの脆弱性（CVE-2026-72898）の悪用 | BIツール |
| ケースD | 公開サーバーにWARファイル（簡易Webシェル）を設置 | 外部公開サーバー |
| ケースE | AIペネトレーションテスト基盤を使った攻撃の試行（10/23追加） | 外部公開資産全般 |
個人情報保護委員会が示すAPI設計の不備
個人情報保護委員会は、APIの管理漏れ、他人データへのアクセス、過剰なレスポンス、レートリミットの欠如を挙げています。
- 管理対象から漏れたAPI：棚卸しされず、監視や更新の対象から外れているAPI
- パラメータの書き換えによる他人データへのアクセス：IDなどを書き換えると、本来見られないはずのデータが返ってくる
- 連番IDや不要な情報を含むレスポンス：推測しやすいIDや、画面に表示しない項目まで返している
- レートリミットの欠如：大量のリクエストを制限なく受け付けてしまう
公表された事案でも、ソースネクストでは会員情報を返すためのAPIが悪用され、2,251万9,960件が流出した可能性があると発表されています。どれも、開発段階で「アプリからしか呼ばれない前提」で設計されたAPIに起きやすい問題です。ケースBのように、スマホアプリは解析すれば中身を確認できます。アプリ経由でしか使わないAPIでも、外部に公開されているAPIと同じ水準で守る必要があります。
委託先とアカウントという「境界の外」
委託先システムと正規アカウントの悪用は、自社のセキュリティ対策の範囲外から侵入される点で共通しています。
Commune、i-ask、大阪公立大学（NECの再委託先）、日経、八十二長野銀行の事案は、いずれも自社のファイアウォールの内側だけを守っていても防ぎにくい経路です。委託先や再委託先が持つアカウント、社員のクラウドアカウントは、正規の権限そのものです。悪用されると、不正な通信として見分けるのが難しくなります。
攻撃にAIは使われたのか？
現時点で結論は出ていません。専門家の共同資料は断定できる痕跡なしとし、イエラエは利用を確認したと発表しました。
政府もAIが使われた可能性を含めて分析を続けています。「AIによる攻撃」と決めつけることも、「AIは関係ない」と言い切ることも、今の段階では避けるべきです。
見解が分かれている現状
専門家の共同資料とイエラエの発表は、AI関与の評価が異なります。政府はAIの利用も含めて分析中です。
| 発信元 | 見解 | 補足 |
|---|---|---|
| 専門家の共同資料 | AIが使われたと断定できる痕跡は確認されていない | — |
| イエラエ（10/19発表） | 攻撃元のインフラで、AIによる自律型ペネトレーションテストシステムの利用を確認 | このインフラが標的にした日本企業は約20社で、うち9社は同じ業種のサイト |
| 政府 | AIの利用も含めて分析中 | — |
| JPCERT/CC | ケースE「AIペネトレーションテスト基盤を用いた攻撃試行」を10/23に追加 | 類型としての整理 |
同じ業種を横断的に狙う動きへの備え
同じ業種のサイトが並んで標的になったという分析は、業界単位で備える必要性を示しているという見方があります。
自律型のペネトレーションテストシステムは、本来は防御側が自社の弱点を見つけるための仕組みです。これが攻撃に使われると、似た構成のサイトに同じ手順の検査を短時間でまとめて試せるようになります。同業他社で被害が公表されたら、自社も同じ手順で試される前提で点検を急ぐのが現実的な対応です。業界団体やISACのような情報共有の場が、使えます。
AXを進める企業が取るべき対策は？
生成AIやAIエージェントで外部公開APIや連携先が増えるほど攻撃面も広がるため、棚卸しと認証の強化を先に進めたいところです。
AXの推進では、社内データをRAGで生成AIにつなぐ、AIエージェントに業務システムのAPIを呼ばせる、外部のSaaSやLLM APIと連携する、といった構成が増えていきます。今回の共通点（外部公開アプリ、API、委託先、アカウント）は、そのままAX基盤の弱点にもなりえます。
共通点と対策の対応表
4つの共通点それぞれについて、AXプロジェクトで点検すべき項目を対応づけておくと、優先順位をつけやすくなります。
| 共通点 | AX環境で増えやすいもの | 優先して行う対策 |
|---|---|---|
| 外部公開アプリ・サービス | PoC用サーバー、デモ環境、BIツール | 公開資産の棚卸し、不要な環境の停止、設定・バックアップファイルの露出確認 |
| API | AIエージェント用の内部API、RAG連携API、APIキー | 認可チェック、レスポンスの最小化、レートリミット、APIキーをアプリに埋め込まない |
| 委託先・SaaS | 生成AI SaaS、開発委託先、FAQ・チャットボット基盤 | 委託先の一覧化、アクセス権限とログの確認、事故時の連絡経路の取り決め |
| アカウント | Google Workspace、Microsoft 365、管理者アカウント | 多要素認証、使っていないアカウントの削除、フィッシング対策訓練 |
PoCとAPIを「本番並み」に棚卸しする
AX推進で生まれた検証環境やAPIを公開資産の一覧に入れ、本番と同じ基準で管理することが第一歩になります。
生成AIの検証では、短期間で環境を立ち上げてそのまま放置することが起こりがちです。ケースAやケースDが狙うのは、こうした管理の行き届かない公開サーバーです。ケースCのMetabaseのように、データ分析用のBIツールが入口になることもあります。AIプロジェクトの終了判定に「公開環境の停止確認」を加えるだけでも、効果が見込めます。
アカウントと委託先の管理をAXの前提条件にする
多要素認証と委託先の把握はAX以前の基本ですが、今回の事案は、そこが入口になりうることを改めて示しました。
AIエージェントにシステムを操作させる場合、エージェントが使うアカウントやAPIキーも新しい「正規の権限」になります。人のアカウントと同じように、権限を最小限にし、ログを取り、定期的に見直す対象として扱うべきです。生成AIのSaaSや開発委託先を選ぶときは、性能や費用だけでなく、侵害時の連絡体制と影響範囲の説明責任まで確認しておくと、委託元として公表や顧客対応を担う場面で慌てずにすみます。
経営層への報告で伝えるべきこと
経営層には、被害件数の大きさよりも、自社に同じ入口があるかと点検の進み具合を中心に報告したいところです。
- 自社の外部公開資産とAPIの数、棚卸しの完了率
- 多要素認証の適用率（社員と委託先の両方）
- 主要な委託先・SaaSの一覧と、事故時の連絡経路の有無
- JPCERT/CCの5類型それぞれに対する点検状況
- 同業他社の公表事案を受けて実施した点検の内容
AI活用の範囲を広げるほど、公開するAPIや連携先も増えます。今月の事案を自社に置き換えるなら、まず公開資産とAPIの一覧を作るところから始めるのが現実的です。AIの関与はまだ分析中ですが、イエラエが自律型のペネトレーションテストシステムの利用を確認したと発表している以上、攻撃の自動化は想定しておく必要があります。
この記事はいつ時点の情報ですか？
2026年10月26日時点の報道・公表に基づいています。事案は進行中のため、各社の続報や公的機関の更新があれば、数字と状況を見直します。主な更新は、次の一覧に追記します。
- 2026年10月26日：公開。報道で確認できた主な事案40件超を一覧化
