企業の不正アクセス事例2026｜漏えい対策と初動

2026年9月から10月にかけて、国内企業の不正アクセスや情報漏えいに関する発表が相次ぎました。タイムズカー、焼肉きんぐ、ブックオフの会員情報に関する事案に加え、委託先からの情報漏えいのおそれやクラウドサービスの停止も公表されています。

ただし、情報漏えいが確認された事件、漏えいのおそれを調べている事件、システム停止が中心の事件は、それぞれ状況が違います。自社の対策を考えるには、被害の数字だけでなく「何が確認され、何がまだ分かっていないか」を読む必要があります。

この記事では、2026年10月22日時点で確認した代表的な5事例を整理します。中小企業や店舗が見直したい対策から、不正アクセスが疑われたときの初動、個人情報保護委員会への報告と顧客への通知まで解説します。掲載したのは国内事案の一部です。

2026年の企業不正アクセス事例をどう読むか

事件の見出しだけを読むと、すべてが同じ攻撃に見えることがあります。最初に、発表日、確認された被害、数字の単位をそろえて確認しましょう。

表の出典は、以下の各社の事例説明に掲載しています。同じ人が複数サービスを使っていることもあり、各社の公表値を足して「何千万人が被害に遭った」とすることはできません。

「漏えいした」と「漏えいのおそれ」は違う

「漏えいを確認」は、企業の調査で情報が外部に渡ったなどの事実を確認した状態です。「漏えいのおそれ」は、第三者が接触できた可能性などがあり、実際の流出や範囲を調べている状態を含みます。

「不正利用が確認されていない」という説明も、情報が外に出ていないという意味にはなりません。情報が流出したか、その情報が悪用されたかは別の確認事項です。逆に、サイトが停止しただけで個人情報流出まで断定するのも早計です。

攻撃者がSNSなどで「情報を盗んだ」と主張しても、その投稿だけでは会社の保有データとの一致や件数は確定しません。企業の続報と調査結果を確認し、攻撃者の主張を確定被害として広めないことが大切です。

公表日を発生日にしない。PHPとの関係も分ける

不正アクセスが起きた日、企業が気づいた日、利用者に公表した日は一致しないことがあります。10月に発表されたからといって、すべて10月に侵入されたとは限りません。本記事では、確認できた検知日や公表日を区別しています。

IPAは10月9日の注意喚起で、相次ぐ事案について「特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されておらず」と説明しています。今回扱う5事例についても、同一犯、AIによる犯行、PHP2Shellが共通原因という説明は、確認した公式資料からは裏付けられません。出典：IPAの注意喚起

PHPの脆弱性への対応が必要かどうかは、自社サーバーの利用状況で判断します。技術的な問題と確認手順は、別記事のPHPの脆弱性とWordPress・レンタルサーバーの確認方法にまとめています。

タイムズ・焼肉きんぐ・ブックオフなど5事例の詳細

以下は、各社が公表した範囲の整理です。企業ごとに対象データも調査段階も異なるため、規模の大小だけで比較せず、自社にも似た情報の持ち方や業務があるかを確認してください。

タイムズカー：本人確認書類の保管も見直す事案

パーク24の発表では、9月25日に不正アクセスを検知し、9月28日までに第三者による会員情報の取得を確認しました。タイムズカーとタイムズビジネスサービスが対象で、現会員だけでなく退会者や入会申込みが完了していない人も含まれます。

漏えいしたアカウントは約660万件。そのうち本人確認書類が漏えいしたアカウントは約160万件と発表されており、両者を足す数字ではありません。氏名、住所、連絡先、運転免許に関する情報、本人確認書類の画像などが対象に含まれますが、個人ごとに対象項目は異なります。クレジットカード情報の漏えいはないと同社は確認しています。出典：パーク24・第2報／第3報

10月16日の第4報では、本人確認後は書類画像を保持しない運用に変更し、保有中の画像は10月末までに削除する予定と発表しました。10月22日時点で、削除がすべて完了したという説明ではありません。調査結果を踏まえた案内は10月23日に予定されています。出典：パーク24・第4報

自社に置き換えるなら、「本人確認に必要だから受け取ること」と「確認後も画像を保管し続けること」を分けて考える事例です。法令上の保存義務がある資料は義務を守り、それ以外は利用目的と保存期限を確認します。

焼肉きんぐ：アプリ会員情報と今後の非保持化

物語コーポレーションの発表では、焼肉きんぐの公式アプリ会員管理システムで10月2日に不正アクセスを確認しました。翌3日に情報漏えいが判明し、5日に公表しています。対象は10,788,963件で、会員番号、登録氏名、メールアドレス、電話番号が漏えいした項目です。

ログインパスワード、生年月日、性別、郵便番号、ポイントを含む利用履歴は対象外と説明されています。決済情報は同システムで保有していないとしています。この発表から「アプリ内のすべての情報が流出した」と広げることはできません。出典：焼肉きんぐ公式サイト・10月5日発表

10月20日の続報では、グループの公式アプリで取得・保持する情報を減らす方針を示しました。氏名と電話番号を保持しない新しいシステムの導入は、2027年上半期の予定です。メールアドレスの取得は続ける予定で、現時点ですべての個人情報を持たない仕組みになったわけではありません。出典：焼肉きんぐ公式サイト・10月20日続報

店舗の会員登録でも、特典配布に住所や生年月日の全項目が本当に必要か、登録欄を1つずつ点検できます。入力項目を減らす判断は、システムの防御とは別に、流出時の影響を小さくするための対策です。

ブックオフ：件数と人数、訂正された項目に注意

ブックオフグループホールディングスは、10月4日から6日にかけて会員情報が外部から取得されたことを確認したと発表しています。10月6日に検知し、10月9日に初報を公表。その後の調査結果を10月13日に発表し、10月16日に情報項目の記載を訂正しました。

公表値は、会員番号ベースで6,427,735件、同じメールアドレスの複数データを集約した対象者数で6,383,279人です。アプリ、オンラインストア、Web会員が対象で、カードだけを持ち、Webやアプリに登録していない人は対象外としています。出典：ブックオフ・10月16日訂正資料

対象になり得る項目には、氏名や連絡先、会員登録住所、生年月日、パスワードのハッシュ値などが含まれます。訂正では職業とニックネームが追加されました。決済情報、銀行口座情報、本人確認書類画像は対象外です。ハッシュ値はパスワードそのものとは異なる形式ですが、ハッシュ値という名称だけで「絶対に解読できない」と判断することはできません。

同社はパスワードの変更と、他サービスで同一・類似パスワードを使っている場合の変更を案内しています。案内メールにパスワード変更用のリンクを載せないとも説明しています。利用者は届いたリンクを反射的に押さず、公式アプリや公式サイトを自分で開いて手続きするほうが、便乗した偽メールを避けやすくなります。出典：ブックオフ・公式FAQ

第一興商：委託先からの情報漏えいのおそれを調査

第一興商は10月16日に同社が配信した発表の末尾で、10月8日に公表した委託先からの個人情報漏えいのおそれについて、調査・対応を継続していると説明しています。確認できたのは「おそれ」に対する対応継続であり、情報流出が確定したという説明ではありません。出典：第一興商がPR TIMESで配信した10月16日発表の末尾

この事例から自社の点検につなげたいのは、外部に預けた情報も管理の対象になるという点です。会員管理やメール配信を委託する際、必要な項目だけを渡しているか、業務終了後の削除時期を決めているかを確認します。

委託先から事故の連絡が来た場合は、自社に関係するデータの範囲と調査の進捗を確認します。原因や流出の有無が未確定なら、その状態を社内でも共有し、推測で「漏えいした」「問題なかった」と説明を変えないようにします。

IDCFクラウド：サービス停止と登録情報への不正照会

IDCFクラウドは10月7日に障害が発生し、IDCフロンティアはランサムウェア攻撃と確認したと発表しました。第2報では495の企業や自治体に影響があるとしています。ここでの数字は障害の影響先で、個人情報の漏えい件数ではありません。出典：IDCフロンティア・第2報

10月14日の第5報では、障害対象ゾーンの仮想サーバー内データについて、外部への持ち出しなどの痕跡を確認しておらず、同社は外部流出なしと判断しています。一方、別のクラウドポータルでは48社の登録情報への不正照会を確認しました。企業名、ログインID、パスワードのハッシュ値、通知用メールアドレス、利用料金の合計額が対象です。同社は、照会された情報についても外部への持ち出しの痕跡は確認していないと説明しています。出典：IDCフロンティア・第5報

同じ発表で、スナップショットを利用していた194顧客のバックアップを取り出せることも判明しています。ただし、全顧客のデータ復元完了を意味しません。10月18日にはバックアップサービスの再開を発表したものの、スナップショット機能の停止は続いています。出典：IDCフロンティア・第6報

この事例で自社が考えたいのは、クラウドを使うかどうかだけでなく、使っているクラウドが止まった場合の仕事の続け方です。バックアップの存在、取り出せる条件、別の環境に戻せるかを、それぞれ確認する必要があります。

中小企業・店舗にも関係する3つの被害

大手企業と同じ規模の仕組みを導入する必要はありません。自社の仕事とデータに当てはめ、どこに損失が出るかを具体化すると、優先すべき対策を決めやすくなります。

顧客情報が二次被害に使われる

氏名やメールアドレスだけでも、本人に関係があるように見せる連絡の材料になり得ます。店舗名と利用者の名前を組み合わせた「返金のお知らせ」などは、受け取った側が本物か判断しにくい文面です。これは想定例であり、今回の各社で同じ二次被害が確認されたという意味ではありません。

漏えい後の案内では、自社から求める手続きと、決して求めない情報を明確にします。たとえば、案内のために銀行口座の暗証番号や認証コードを聞くことはないと説明し、確認先を公式サイトにまとめます。電話受付の担当者にも同じ案内を渡し、窓口ごとに説明が食い違わないようにします。

予約・受注・請求が止まる

予約システムが開かなければ、来店予定や施術内容を確認できない場合があります。販売管理が止まれば、出荷先や請求金額が分からなくなることもあります。情報が漏れたかどうかとは別に、利用できない状態そのものが事業上の損失になります。

自社では「明日このサービスが使えなかったら、何の仕事が止まるか」を担当者に聞いてみてください。予約受付を一時的に電話へ切り替える、出荷判断ができない注文を止めるなど、業務ごとに代替手段を決めます。紙や表計算への切替えでも個人情報は扱うため、保管担当と終了後の回収まで必要です。

取引先への説明と復旧対応が重なる

事故対応には、システムの修理以外の仕事も発生します。対象顧客の特定、問い合わせ対応、委託元への報告、取引先との納期調整、再発防止策の説明などです。社長や少人数の社員に業務が集中すると、通常営業の再開が遅れます。

平時に技術担当、経営判断をする人、顧客向け説明をまとめる人を決めておくと、事故直後の混乱を減らせます。外部の保守会社に依頼している場合も、同社がどこまで対応する契約かは確認が必要です。サイトの復旧と、情報漏えいの専門調査や法的な対応では、必要な役割が異なります。

まず点検したいデータ・アカウント・公開システム

以下は、IPAの注意喚起にある点検の考え方を、小規模な会社や店舗で作業しやすい形にした確認例です。チェックが付いただけで安全を保証するものではなく、担当者と保守会社が同じ事実を確認するために使います。参考：IPA・速やかに行うべき点検

使っているサービスと保管データを書き出す

ホームページ、予約、通販、会計、メール、ファイル共有、顧客管理、勤怠などを一覧にします。契約している正式サービスだけでなく、部署や担当者が個別に使い始めた無料サービスも対象です。請求書やカード明細から探すと、忘れていた契約が見つかることもあります。

一覧には「サービス名・用途・管理者・問い合わせ先・入っている情報・解約時の取り出し方」を記載します。パスワードそのものは台帳に貼らず、権限管理された保管場所を記します。顧客情報を扱うサービスなら、データの書き出しが誰に許可されているかも確認してください。

保管データは、本番の顧客管理だけを見ても十分ではありません。ダウンロードしたCSV、問い合わせの添付ファイル、採用応募書類、テスト用の複製にも個人情報が残ります。業務や法令で必要な期間を確認し、不要になった情報を削除する日と担当者を決めます。事故の調査中は、証拠になるデータやログを独断で削除しないことが前提です。

管理者権限と多要素認証を確認する

最初に見るのは、サーバー、ドメイン、メール、顧客管理の管理者アカウントです。複数人で同じIDを共有していると、誰の操作か追いにくくなります。可能なサービスでは個人ごとのIDに分け、担当業務に必要な権限だけを付けます。

多要素認証は、パスワードに加えて認証アプリなど別の要素で本人を確かめる仕組みです。設定できる管理画面では有効化し、復旧コードを安全に保管します。代表者のスマートフォンだけに認証を依存させると、紛失や不在で管理できなくなります。サービスの正式な方法で、予備の管理者や復旧手順も用意してください。

退職者、以前の制作会社、期間限定の外注先のアカウントも見直します。不要な権限を停止する前に、動作中の連携や引き継ぎへの影響を確認してください。システム同士をつなぐAPIキーも、利用先、発行者、権限、保管先が分かる状態にしておきます。

更新状況とログを担当者に確認する

WordPress本体やプラグインに加え、PHP、サーバー、VPNなど、外部から接続される仕組みの更新状況を確認します。「自動更新を設定した」と「今回の修正が適用された」は別の話です。保守会社には、対象、適用した版、確認日、未対応の項目を聞くと、回答が具体的になります。

変更には動作確認と戻す手順も必要です。予約や決済を持つサイトなら、更新後にトップページが表示されるだけでなく、申込みが完了するところまで確認します。一方、すでに侵入が疑われるときは、通常の更新作業として上書きする前に調査担当へ相談してください。

ログは、管理画面へのログインやデータの書き出しなどの記録です。保存の有無、保存期間、取り出せる担当者を確認します。作成した覚えのない管理者、普段と違う時間の大量取得、削除したはずのIDの復活などがあれば、通常の点検から事故対応へ切り替えます。

委託先とバックアップで確認しておきたいこと

クラウドや外部の制作会社を使っていても、自社側で決める項目は残ります。契約先に何を確認するかが分かっていれば、専門用語をすべて覚える必要はありません。

「セキュリティは大丈夫ですか」から一歩具体的に聞く

委託先には、預ける情報と作業範囲をそろえて質問します。「顧客一覧を保管する場所はどこか」「再委託先はあるか」「担当者の私物端末に保存するか」「契約終了後にいつ削除するか」といった確認です。回答できない項目は、誰がいつまでに確認するかまで決めます。

• 事故や漏えいのおそれを把握した場合、どの窓口から誰へ連絡するか。
• 自社に関係するログや対象データを、どの範囲で提供してもらえるか。
• 休日・夜間にサービスを止める判断と操作を、誰が担当するか。
• バックアップの取得、復元、データの取り出しが契約に含まれるか。
• 復旧作業、専門調査、顧客対応の費用と役割を、どの契約で扱うか。

「認証を取っている」「大手サービスを使っている」という説明だけでは、自社に必要な復旧時間や連絡方法までは分かりません。サービスの安全対策と、自社との運用上の約束を、それぞれ確認します。

控えを取るだけでなく、戻せるか試す

バックアップは、データやシステムの控えです。ただ、同じアカウントで本番とバックアップの両方を削除できる状態なら、アカウントが侵害されたときに両方を失う可能性があります。保存先と管理権限を分け、サービスによっては削除や上書きを制限する機能も検討します。

確認したいのは「いつの控えが、どこにあり、誰が、どの環境へ戻せるか」です。予約データだけ戻せても、そのデータを読むアプリや設定がなければ仕事を再開できません。サイトなら画像やデータベース、設定を含め、別環境で復元できるかを試します。本番データを使う検証環境の公開範囲やアクセス権にも注意が必要です。

経営者は、どこまでのデータ消失を許容できるか、どれくらいの停止時間なら事業を維持できるかを担当者と決めます。これによって、取得頻度や復元方法を選びやすくなります。たとえば予約が頻繁に入る業務では、前日分までしか戻せない場合に、当日の予約をどう確認するかという課題が残ります。

IPAの中小企業向けガイドライン第4.0版では、基本対策にバックアップが追加されています。会社の規模に応じた運用を決める際の資料として利用できます。参考：IPA・中小企業の情報セキュリティ対策ガイドライン

不正アクセスが疑われたときの初動

身に覚えのない管理者がいる、ファイルが開けない、不審なデータ取得がある、取引先から流出の連絡が来た。こうしたときは、社内で確認を回すだけで時間を使わず、保守会社や専門の調査担当へつなぎます。

被害の拡大を止め、記録を残す

発見者は、気づいた時刻、対象の端末やサービス、画面表示、直前の操作を記録し、責任者に連絡します。感染が疑われる端末は、担当者の指示でネットワークから隔離します。会社のメールまで侵害されている可能性があれば、連絡には別の安全な手段を使います。

焦って初期化したり、怪しいファイルをすべて削除したりすると、侵入経路や流出範囲の調査に必要な証拠を失います。再起動や電源断の扱いも状況によって変わるため、調査担当に確認してください。クラウドではログの保存期限が短い場合があるので、提供会社への保全依頼を早めに出します。

侵害されたアカウントの停止、パスワードやAPIキーの変更、接続中のセッションの無効化も検討対象です。被害が疑われる端末上で変更を続けると、新しい情報まで取得されるおそれがあります。安全な端末と経路を確保したうえで、影響する連携も確認しながら進めます。

調査・報告・業務継続を同時に進める

担当を「技術調査」「経営判断」「顧客・取引先への連絡」に分け、確認事項を1つの記録にまとめます。少人数なら兼任でもかまいませんが、誰が最終判断をするかは明確にします。技術担当が調査している間に、経営側は停止する業務、代替手段、専門家への依頼、保険会社への連絡などを検討します。

調査では、侵入の時期と経路、触れられたデータ、外部への転送、他の端末への影響を確認します。アクセス記録の中に異常が見つからなくても、必要なログ自体が残っていなければ「被害なし」とは判断できません。不明な点を不明のまま記録し、調査範囲を広げる必要があります。

復旧は、画面が表示される状態に戻すだけでは終わりません。侵入に使われた原因への対処、残された不正なアカウントやプログラムの確認、必要な認証情報の変更をしたうえで、再開する範囲を決めます。攻撃者の連絡先へ独断で返答したり、支払いを決めたりせず、警察や対応専門家に相談してください。

相談先を探す場合は、IPAの企業向け窓口や警察のサイバー犯罪相談窓口、契約中の保守会社を確認します。調査依頼と、法令に基づく報告は別の手続きなので、相談しただけで報告が済んだとは扱わないようにします。参考：IPAの相談窓口・関連機関案内

個人情報保護委員会への報告と顧客への通知

個人データを扱う会社は、復旧の作業と並行して、報告や本人への通知が必要かを確認します。ここでは一般の民間事業者について説明します。行政機関やマイナンバーを含む事案、所管省庁に権限が委任された分野では、該当する窓口や規則の確認が必要です。

少人数の漏えいでも報告対象になる場合がある

個人情報保護委員会は、民間事業者の個人データについて、報告が必要な事態を次のように示しています。いずれも、漏えい等が実際に発生した場合に加え、そのおそれがある場合を含みます。出典：個人情報保護委員会・漏えい等報告

• 要配慮個人情報を含む場合。
• 不正利用によって財産的被害が生じるおそれがある場合。
• 不正の目的による行為によって漏えい等が生じたおそれがある場合。
• 対象となる本人の数が1,000人を超える場合。

「1,000人以下なら報告不要」という理解は誤りです。不正アクセスによって顧客の個人データが漏えいしたおそれがある場合などは、人数だけで対象外と判断できません。ランサムウェアで個人データが暗号化され、復元できなくなった事態も、報告対象の例として示されています。

ただし、高度な暗号化などで権利利益を守る措置が取られたデータは、報告対象から除かれる場合があります。委託先が所定の条件で委託元に通知した場合にも、報告義務の例外があります。暗号化という名前だけで対象外にせず、鍵の管理や委託関係を含めて確認してください。個人情報保護委員会・通則編の報告対象と委託の規定

期限は、報告対象の事態を知った後、まず速やかに速報を出し、目安は概ね3〜5日以内です。確報は原則30日以内、不正の目的による行為のおそれがある場合は60日以内とされています。すべての調査結果がそろうまで、最初の報告を待つ仕組みではありません。出典：個人情報保護委員会・通則編「漏えい等の報告等」

起算日、報告先、委託元・委託先の分担で迷う場合は、個人情報保護委員会や所管窓口、弁護士に相談します。担当部署が事態を知った時刻も残し、社長への説明が終わるまで記録の開始を遅らせないようにしてください。

顧客には確認済みのことと調査中のことを分けて伝える

報告対象の事態では、原則として本人への通知も必要です。本人に分かる方法で、事案の概要、対象のデータ項目、原因、二次被害のおそれ、対応の参考になる情報を伝えます。本人への通知が困難な場合には代替措置の規定がありますが、会社が都合よく「サイトに載せれば済む」と選べるものではありません。参考：個人情報保護委員会・本人通知の案内

以下は、初報を組み立てるための短い文例です。実在する事故の通知ではありません。実際に使う際は、事実に合う日時、サービス名、対象者、データ項目、実施済みの対応、問い合わせ先を補い、法務担当などと内容を確認してください。

当社が利用する会員管理システムで、第三者による不正なアクセスを確認しました。現在、外部専門家とともに、影響を受けた情報の範囲と原因を調査しています。

お客様の情報が外部に流出したかどうかは、現時点では確認できていません。判明した内容は、当社公式サイトのお知らせで更新し、対象となるお客様には必要なご案内をお送りします。

本件に関連して当社がお客様のパスワードや認証コードをお尋ねすることはありません。不審な連絡を受けた場合は、本文のリンクを開かず、公式サイトに掲載する窓口へご確認ください。

すでに漏えいを確認した事案で、この文例の「確認できていません」をそのまま使ってはいけません。事実に合わせて書き換え、対象者が取るべき行動を具体的にします。「安全です」「被害はありません」といった断定も、調査の裏付けがある範囲に限ります。

続報には更新日時を入れ、前の説明から何が変わったのかを明記します。情報項目や対象人数を訂正する場合は、古い説明を黙って差し替えず、変更点が利用者に分かる形にするほうが混乱を防げます。

自社の対策を決めるチェックリスト

次の表を、社内担当者や保守会社との確認に使ってください。「対応済み」の一言で終わらせず、確認日、担当者、根拠となる画面や記録を残します。分からない項目が見つかったら、その確認を次の作業にします。

着手の順番に迷ったら、まず「外から接続できる管理画面」「大量の顧客情報がある場所」「止まると営業できないサービス」を確認します。未適用の緊急修正や不審な操作が見つかった場合は、その対応を優先し、通常の点検とは分けて扱ってください。

ホームページについては、サーバー、WordPress、ログイン、監視、バックアップを分けて確認すると、管理範囲を整理できます。各項目の基本はホームページのセキュリティ対策でも紹介しています。現在の契約で誰がどこまで担当しているかを確認する際に使ってください。

ニュースを読んだ後に必要なのは、自社のサービス名と担当者が入った点検結果です。今日確認できなかった項目には担当者と確認期限を付け、変更後には予約・問い合わせなど実際の業務が動くことまで確かめましょう。