【2026年最新】サイバー攻撃・情報漏洩の事例まとめ 事業停止・SaaS・認証・AI悪用から見る企業リスク

サイバー攻撃の事例

投稿日時: 更新日時:

【2026年】サイバー攻撃・情報漏洩の最新 事例

2026年のサイバー攻撃を振り返ると、単に「情報漏洩の件数が増えた」という説明では実態を捉えにくくなっています。

ニチレイではサイバー攻撃を受けて冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、日本交通ではマルウェア感染によって電話でのタクシー配車やハイヤーのWeb受注に影響が出ました。攻撃によるシステム停止が、そのまま物流や移動といった現場業務の停止につながっています。

一方、侵入先も自社ネットワークだけではありません。

東海大学では業務委託先へのランサムウェア攻撃から最大19万3,118人分の個人情報が漏洩しました。ApplyNowでは採用管理SaaSが内部で利用していたデータ分析ツールの脆弱性が悪用され、マイナンバーや口座情報を含むデータに影響した可能性があります。

さらに、ULTRA MARTが利用していたデジタル整理券システム「mogily」では、個人情報を盗み出すのではなく、本来「当選」だった133名の抽選結果を「落選」へ書き換える攻撃が発生しました。

2026年の事例から見えるのは、サイバー攻撃によって狙われる対象が「情報」だけではなく、企業の業務、委託先、認証情報、データの正しさへ広がっていることです。

この記事では、2026年9月13日時点で公表されている国内の代表事例を、被害件数の大きさではなく「企業がどこを見直すべきか」という観点から整理します。

2026年のサイバー攻撃で変わった4つのこと

2026年の代表事例を横断すると、大きく4つの変化が見えます。

変化 代表事例 企業側で起きたこと
情報漏洩から事業停止へ ニチレイ、日本交通 倉庫・出荷・配車・予約など実業務が停止
自社から委託先・SaaSへ 東海大学、ApplyNow、KDDI 自社外のシステムや共通基盤から影響が波及
大量データ保有基盤が狙われる Eストアー、アフラック、さくらインターネット 1回の侵害で数十万~数百万規模の情報が影響
機密性だけでなく完全性も狙われる ULTRA MART / mogily 抽選結果そのものが改ざんされ、利用者の権利に影響

この変化は、セキュリティ対策の優先順位にも影響します。

「外部から侵入されないようにする」「個人情報を暗号化する」だけでは足りません。

システムを遮断したときに現場業務をどう続けるか、委託先にどの情報を預けているか、認証情報が漏れた場合にどこまでアクセスされるか、業務データが書き換えられた場合に正しい状態へ戻せるかまで確認する必要があります。

2026年 主要サイバー攻撃・情報漏洩インシデント一覧

公表時期 組織・サービス 主な被害・影響 事例から確認できる論点
2026年9月 ULTRA MART / mogily 133名の抽選結果を「当選」から「落選」へ改ざん データ完全性、管理画面の防御
2026年9月 ApplyNow 採用・雇用関連データに不正アクセスの可能性、件数調査中 SaaS内部の第三者ツール
2026年9月 さくらインターネット レンタルサーバ951アカウント、販売管理システム最大136万563アカウントに影響の可能性 長期侵入、認証・顧客管理基盤
2026年8月 Eストアー「ショップサーブ」 最大延べ885万3,839件の購入者情報などが漏洩 EC共通基盤、認証情報漏洩
2026年7月 ニチレイ 冷蔵倉庫の入出庫、冷凍食品出荷が停止 事業継続、物流波及
2026年7月 日本交通 タクシー配車、ハイヤーWeb受注などが停止、一部ファイルの外部流出を確認 BCP、マルウェア、データ流出
2026年7月 アフラック生命保険 約440万人の個人情報が漏洩、うち約22万人は口座情報を含む 大量照会の検知、顧客基盤
2026年6月 KDDI ISP6社でメールアドレス・パスワード最大1,422万件に漏洩の可能性 共通基盤、第三者製ソフトウェア
2026年6月 はてな 不正な送金指示で最大11億7,900万円を特別損失計上 BEC、送金統制
2026年2月 東海大学 業務委託先へのランサムウェア攻撃で最大19万3,118人分の個人情報漏洩 委託先管理、データ持ち出し

※公表時期は主要な続報・被害確定時期を含みます。対象件数について「可能性」「最大」「延べ」とされているものは、漏洩が確定した人数とは区別しています。

ニチレイ サイバー攻撃で冷蔵倉庫と冷凍食品の出荷が停止

2026年7月13日、ニチレイは不正アクセスによるシステム障害を確認しました。

その後の調査で、自社サーバーがサイバー攻撃を受けたことが判明しています。

ニチレイが被害拡大防止のためグループ内システムをネットワークから遮断した結果、ニチレイロジグループ各社の冷蔵倉庫入出庫業務と、ニチレイフーズの冷凍食品出荷業務に影響が出ました。

7月17日から順次業務を再開し、7月24日には全拠点で通常稼働へ戻しています。

8月14日の第6報では、攻撃を受けたサーバーの一部に国内グループ会社の従業員情報が保存されており、氏名、生年月日、会社メールアドレス、従業員番号などが漏洩したおそれがあることも公表されました。

この事例で見るべきなのは、情報漏洩より先に「業務停止」が発生したことです。

食品物流では、ITシステムを遮断すると倉庫の入出庫、受発注、在庫管理、出荷指示といった物理的な業務へ影響します。

セキュリティ部門だけで復旧計画を作るのではなく、システム停止中でも出荷や入庫を継続できる代替手順を現場部門と決めておく必要があります。

ニチレイの事案は「ニチレイグループへのサイバー攻撃まとめ」で時系列を整理しています。

日本交通 マルウェア感染で電話配車やハイヤーWeb受注が停止

日本交通は2026年7月11日未明、社内システムへの外部からの不正アクセスとマルウェア感染を確認しました。

被害拡大を防ぐためシステムを遮断した結果、ハイヤーのWeb受注・予約管理システム、電話によるタクシー配車、一部の社内システムが利用できなくなりました。

日本交通はタクシー利用者に対し、アプリ「GO」、タクシー乗り場、流し車両の利用を案内しています。

7月22日には、同社から流出した疑いのある情報がインターネット上で確認されました。

8月19日の第4報では、同社が保有していたファイルの一部が実際に外部へ流出していることが判明しています。

この事例も、侵害直後の影響は「データが盗まれたか」より先に「サービスを提供できない」という形で表れました。

配車、予約、コールセンターなど顧客接点のシステムでは、システム隔離と事業継続が衝突します。

緊急時にどの機能を止め、どの業務を電話・紙・別サービスへ切り替えるのかを事前に決めていなければ、封じ込めの判断自体が遅れます。

詳細は「日本交通、マルウェア感染と不正アクセスでシステム停止」でも整理しています。

Eストアー「ショップサーブ」 最大延べ885万件超、店舗側の認証情報も漏洩

Eストアーは2026年8月1日、EC構築サービス「ショップサーブ」のサーバーに不正アクセスがあり、購入者情報が外部へ送信されたことを公表しました。

第2報では、不正なプログラムが実行されていた期間が2026年5月21日から8月1日までだったことが明らかになっています。

公表された件数は8,853,839件です。

ただし、これは同じ利用者に関する複数の登録データを含む「延べ件数」であり、885万人の利用者が被害に遭ったという意味ではありません。

購入者側では氏名、住所、電話番号、メールアドレス、会員情報、暗号化された会員ID・パスワードなどが対象となりました。

さらに店舗側でも、

  • ショップサーブ管理画面のID・パスワード
  • 店舗メールシステムのID・パスワード
  • FTPのID・パスワード
  • 振込先口座情報

が漏洩対象に含まれています。

この事例で特に警戒したいのは、購入者情報だけでなく「店舗を操作するための認証情報」が漏洩していることです。

顧客データの漏洩はそれ自体が被害ですが、管理画面やFTPの資格情報が窃取されると、後続の不正ログイン、Webサイト改ざん、フィッシング、追加侵害へつながる可能性があります。

SaaS事業者やEC基盤事業者では、漏洩件数だけではなく「漏れた情報を使って次に何ができるか」まで確認する必要があります。

アフラック生命保険 約440万人の個人情報が漏洩

アフラック生命保険では、契約者専用サイト「アフラック よりそうネット」などへの不正アクセスにより、約440万人の個人情報が漏洩しました。

不正アクセスは2026年6月10日から25日まで複数回発生しています。

漏洩した情報には、契約者の氏名、生年月日、住所、電話番号、被保険者・受取人情報、証券番号、保障内容などが含まれます。

約22万人については、保険料振替口座の金融機関名、支店名、口座番号、口座名義なども対象となりました。

アフラックの調査では、攻撃者によるアクセス形式が通常利用と似ていたため、既存の不正アクセス検知機能で直ちに検出できませんでした。

また、短時間に大量のデータ照会が行われた場合の監視・制御も不足していたと説明しています。

ここから確認できるのは、「ログインできたか」だけを監視しても、大量取得型の攻撃を止められないことです。

認証後の利用者についても、短時間での大量検索、通常とは異なる件数の照会、普段アクセスしないデータ項目の取得など、行動量を監視する必要があります。

KDDI ISP6社のメール認証情報が最大1,422万件に影響

KDDIは2026年6月23日、ISP事業者向けに提供するメールシステムへの不正アクセスを公表しました。

影響したのはSTNet、KDDIウェブコミュニケーションズ、JCOM、中部テレコミュニケーション、ニフティ、ビッグローブの6社です。

対象となる可能性がある情報は、メールボックスにひも付くメールアドレスとパスワードで最大1,422万件でした。

解約済みや休眠中の利用者も含まれています。

原因は、メールシステムで利用していた第三者製ソフトウェアの脆弱性が悪用されたことでした。

KDDI自身だけで完結するサービスではなく、複数のISP事業者へ共通基盤として提供されていたため、一つのシステムへの侵害が6社へ波及しました。

企業がSaaSや共通基盤を利用する場合、「自社の契約先」だけを見るのではなく、そのサービスの裏側でどのソフトウェアや共通インフラに依存しているのかを把握する必要があります。

詳細は「KDDI、メールシステムへの不正アクセスで最大1,422万件が漏洩の恐れ」で整理しています。

さくらインターネット 2023年から販売管理システムへの不正アクセスを確認

さくらインターネットは2026年9月10日、不正アクセスに関する調査結果を公表しました。

「さくらのレンタルサーバ」では、一部サーバーへの不正アクセスとマルウェア設置が確認され、第三者による閲覧または取得の可能性がある対象は951アカウントとなりました。

一方、販売管理システムに保存されていた会員情報は最大1,360,563アカウントが影響対象となる可能性があります。

重要なのは、販売管理システムへの不正アクセスが2026年に始まったものではなかった点です。

調査の結果、2023年4月以降から2026年3月までの間に不正アクセスが発生していたことが確認されています。

さくらインターネットは、データが外部へ持ち出されたことを裏付ける明確な事実は確認していないとしています。

また、最大1,360,563アカウントは「漏洩が確定した件数」ではなく、第三者に閲覧・取得された可能性がある対象総数です。

この事例では、検知後の封じ込めだけでなく、過去数年分の認証・操作ログをどこまで遡れるかが調査の精度を左右します。

ログ保存期間が30日や90日しかなければ、長期侵入が判明したときに初期侵入時期やアクセス範囲を追えない場合があります。

詳細は「さくらインターネット、不正アクセスで最大1,360,563アカウントに影響の可能性」で整理しています。

東海大学 自社ネットワークではなく業務委託先から最大19万3,118人分が漏洩

東海大学は2026年2月18日、業務委託先である東海ソフト開発へのランサムウェア攻撃により、大学が取り扱う個人情報が漏洩したと公表しました。

攻撃者は委託先ネットワークへ接続するための認証情報を不正に入手し、委託先システムへ侵入してランサムウェア攻撃を行ったとされています。

影響人数は最大延べ193,118人です。

東海大学の学内ネットワークへ直接侵入した形跡は確認されていません。

それでも大学の情報が漏洩した理由は、委託先が本来の運用ルールに反し、大学構内や大学環境で扱うべきデータを委託先社内へ持ち帰っていたためです。

この事例は、「委託先が侵害されたら困る」という抽象的なサプライチェーンリスクではありません。

委託先に何を持ち出させるか、どこで処理させるか、契約や規程どおり運用されているかを監査しなければ、自社ネットワークを守っても情報は漏れます。

委託契約ではセキュリティ条項だけでなく、データの保存場所、ローカルコピーの可否、作業終了後の削除、持ち出しログまで確認する必要があります。

ApplyNow 採用管理SaaS内部のデータ分析ツールが侵入口に

きちりホールディングスは2026年9月9日、子会社ApplyNowが提供する「Interview Cloud」「ApplyNow」「ApplyNow Sign」で、個人データが外部へ漏洩した可能性があると公表しました。

不正アクセスが確認された期間は8月9日から9月7日です。

9月7日に異常なアクセスログを検知し、調査したところ、システム内部で利用していたデータ分析ツールの脆弱性が悪用されたことが分かりました。

ApplyNow Signでは、漏洩した可能性がある情報に雇用契約情報、個人番号、基礎年金番号、金融機関口座情報などが含まれています。

対象件数は9月9日時点で調査中です。

画像、PDF、面接動画については別領域に保存され、今回の不正アクセス対象外とされています。

ここで見るべきなのは、「SaaSそのもの」ではなく、SaaS事業者が内部で利用していた別のツールが侵入口になった点です。

利用企業から見ると、契約しているのはApplyNowでも、その裏側では分析ツール、クラウド、ライブラリ、外部APIなど複数のコンポーネントが動いています。

SaaS調達時には、ベンダー本体のISMSやSOC 2の有無だけでなく、サブプロセッサーや第三者製品の脆弱性管理、セキュリティパッチ、インシデント時の通知条件まで確認する必要があります。

詳細は「きちりホールディングス 子会社ApplyNowに不正アクセス」で整理しています。

ULTRA MART 情報を盗まず、133名の「当選」を「落選」へ改ざん

2026年9月9日から10日にかけ、円谷プロダクションの直営店「ULTRA MART」が利用するデジタル整理券システム「mogily」の管理システムへ不正アクセスが発生しました。

第三者は、本来「当選」だった利用者の抽選ステータスを「落選」へ書き換えました。

影響した利用者は133名です。

mogilyはログ調査によって対象者を特定し、全員を本来の「当選」状態へ復旧しました。

氏名や連絡先などの個人情報漏洩は確認されていません。

この事案は、2026年の事例を考えるうえで象徴的です。

情報セキュリティでは「情報が盗まれたか」が大きく扱われますが、業務システムでは情報の正しさも同じように守る必要があります。

抽選の当落、予約枠、在庫数、商品価格、口座番号、承認状態、権限設定などが改ざんされれば、情報漏洩がなくても顧客や企業へ直接的な損害が生じます。

管理画面のMFAだけでなく、大量変更や重要ステータス変更のアラート、変更履歴、改ざん前の状態へ戻すバックアップも確認対象になります。

はてな 11億7,900万円の資金流出が示す「侵入されなくても負ける」リスク

サイバー攻撃の事例を不正アクセスやマルウェアだけに限定すると、2026年の大きな被害を見落とします。

はてなでは2026年4月、不正な送金指示を受けた従業員が外部口座へ資金を送金する事案が発生しました。

同社は6月12日、現時点における被害の最大額1,179百万円を特別損失として計上しました。

この事案では、ランサムウェアによってサーバーを暗号化する必要も、顧客データを大量に盗み出す必要もありません。

攻撃者が組織の意思決定や送金プロセスへ入り込み、正規の従業員自身に送金させれば巨額の被害が成立します。

そのためBECやニセ社長詐欺では、メールフィルターだけを強化しても最後の防御にはなりません。

高額送金、送金先変更、緊急を理由とした例外処理について、チャットやメールとは別経路で本人確認すること、複数人の承認なしに送金できないこと、承認者本人が送金先口座を確認することが必要です。

2026年のBEC被害は「ビジネスメール詐欺・ニセ社長詐欺 不正送金被害まとめ」で個別に整理しています。

2026年は「件数」だけでは被害の大きさを比較できない

サイバー攻撃の記事では「○万件」「○万人」という数字が目立ちます。

しかし2026年の事例では、それぞれの数字が意味するものが異なります。

Eストアーの8,853,839件は延べレコード数であり、被害者885万人を意味しません。

KDDIの最大1,422万件はメールボックスにひも付くメールアドレス・パスワードで、休眠・解約済みアカウントも含まれます。

さくらインターネットの1,360,563アカウントは、販売管理システム内の情報について第三者が閲覧・取得した可能性がある対象総数で、同数の漏洩が確認されたわけではありません。

一方、アフラックは約440万人の個人情報が実際に漏洩したと公表しています。

「最大」「可能性」「延べ」「漏洩確認」を区別しなければ、被害規模を誤って評価します。

企業側でも、インシデント発生直後に一つの大きな数字だけを出すのではなく、

  • システム上の対象総数
  • 実際にアクセスされた可能性がある件数
  • 外部持ち出しを確認した件数
  • 本人通知が必要な人数

を分けて集計できるようにしておくと、続報の精度が上がります。

侵入経路は「自社の境界」より外へ広がっている

2026年の事例で繰り返し現れるのが、自社のファイアウォールやPC以外から始まる侵害です。

東海大学では業務委託先、ApplyNowでは内部利用するデータ分析ツール、KDDIでは第三者製ソフトウェアが問題の起点になりました。

企業側で確認すべきなのは「委託先にセキュリティチェックシートを書いてもらったか」ではありません。

実際のデータフローを確認します。

顧客情報はどのSaaSへ送られ、そのSaaSがどのサブプロセッサーへデータを渡し、どこにバックアップが保存され、保守担当者はどの認証方法で接続するのか。

委託終了後にデータが残っていないか。

障害時にそのサービスを使わず業務を続けられるか。

こうした情報を資産台帳やデータフローへ反映しないと、委託先でインシデントが発生した際、自社の影響範囲をすぐ判断できません。

AIは攻撃の「新しい入口」より、既存攻撃を速く回す道具として使われ始めた

2026年はAIを悪用した攻撃も具体化しました。

Anthropicは2026年9月の脅威インテリジェンスレポートで、ShinyHuntersに関連するとみられる攻撃者クラスターがClaudeを利用し、認証情報の探索、未知のシステムの把握、データ窃取、恐喝に至る作業を進めていたと報告しています。

ある事例では、窃取済みの開発者トークンから被害組織のクラウド環境で完全な管理者権限を得るまで、約3時間だったとしています。

ここでAIが新しい脆弱性を作ったわけではありません。

入口になったのは認証情報や既存システムの弱点です。

AIによって変わるのは、その後の偵察、情報整理、権限拡大、スクリプト作成、データ探索を回す速度です。

企業側ではAIだけを禁止するのではなく、

  • インターネット公開資産を継続的に把握できているか
  • 漏洩したAPIキーやアクセストークンを即時失効できるか
  • 特権IDへの昇格を検知できるか
  • 1アカウントから短時間に大量データが取得された場合に止められるか
  • 脆弱性公開後のパッチ判断を週次・月次ではなく緊急度に応じて変えられるか

を確認する必要があります。

企業のAI利用とAIを悪用した攻撃については「AIセキュリティとは」で整理しています。

2026年の事例から情報システム部門が優先して確認したいこと

2026年の事例を個別の事件として読むだけでは、次のインシデントへの備えにはつながりません。

最初に確認したいのは、システム停止時の業務継続です。

基幹システム、配車、倉庫、受発注、予約などを止めた場合、何時間まで事業を継続できるのか。紙、電話、別SaaSなどへ切り替える手順があるのか。復旧優先順位は経営と現場で合意されているかを確認します。

次に、SaaS・委託先・外部アプリを含むデータフローを確認します。

契約先名だけではなく、保存される情報、サブプロセッサー、バックアップ、管理者権限、通知期限、契約終了後の削除まで整理します。

認証情報については、MFAの有無だけではなく、長期トークン、APIキー、初期パスワード、休眠アカウント、委託先アカウントを含めて棚卸しします。

ログについては、不正アクセスを検知するためだけではなく、数か月から数年前へ遡るフォレンジックに耐えられる保存期間があるかを確認します。

最後に、データの完全性です。

顧客情報が盗まれていなくても、抽選結果、振込先、在庫、権限、承認状態を書き換えられれば事業被害は発生します。

重要データについて、変更履歴、管理操作ログ、大量変更検知、バックアップからの復旧ができる状態にしておく必要があります。

月次記事と年次記事の使い分け

この記事では、2026年を代表する事例を「企業がどこを見直すべきか」という観点から選んでいます。

月ごとの全事例を確認したい場合は、以下の月次まとめを参照してください。

ランサムウェアだけを確認したい場合は「2026年 ランサムウェアの事例」で国内外の事案を整理しています。

 

出典