タグ: セキュリティ

投稿日:

Commune不正アクセスで約30.7万人の情報漏洩 ―利用企業が見直すべきSaaS管理

Share
Commune不正アクセスで約30.7万人の情報漏洩アイキャッチ画像

顧客や会員との交流を支えるコミュニティサービスで、個人情報の漏洩が発生しました。コミュニティサービス「Commune」「Commune for Work」を提供するコミューン株式会社は2026年10月9日、両サービスへの不正アクセスにより、推計約30.7万人の会員情報が漏洩したと公表しています*1。利用企業からも影響が公表されていますが、対象情報や漏洩の確認状況は各社で異なります。本記事では公表情報をもとに、事件の概要と、企業がSaaSを使う際に見直したい管理のポイントを整理します。

Communeで何が起きたのか

コミューンの発表では、非公開コミュニティの招待リンクが不正に取得され、一般会員としての登録が行われたほか、管理者へのなりすましによって会員情報の閲覧・取得やデータの上書きが行われました。今回の事案では、コミュニティへの参加方法と管理者権限の両方が確認すべきポイントとなります。約30.7万人は、コミューンの従業員・テスト用デモアカウントも含む推計です。また利用企業の設定や運用が原因ではないと説明しています。個々の利用者への影響は、参加するコミュニティと登録情報によって異なります。

なお同社は、10月13日、10月9日の公表以降に新たな不正アクセスや情報漏洩は確認されていないものの、引き続き調査と対応を進めていると発表しています。悪用された脆弱性の種類や認証の仕組みについて、詳細は明らかにされていません。

LINEヤフーとSansanで異なる情報漏洩の確認状況

LINEヤフーは、「DS.INSIGHT」内のコミュニティ機能「DS.LAB」の利用者1,750人について、情報が閲覧・取得された可能性を公表しました*2。対象には氏名、メールアドレス、自己紹介、所属グループなどが含まれます。同社のシステムへの不正アクセスは確認されておらず、コミューンが運営するサーバーで起きた事案と説明しています。

Sansanは「Sansan User Forum」について、漏洩を確認した1,325人と、漏洩の可能性がある8,687人を分けて公表しました*3。前者の対象情報にはメールアドレス、アカウント名、自己紹介、プロフィール画像、グループ所属情報が含まれ、後者はメールアドレスを除くこれらの情報が対象です。また、営業AXサービス「Sansan」など、同社の各サービスやそこで預かる情報への影響はないと説明しています。

今回の事案では、利用企業ごとに対象情報や漏洩の確認状況が異なります。情報漏洩の影響を判断する際には、対象となったサービスや情報の種類、漏洩が確認されているかどうかを区別することが重要です。

図：Commune事案の影響をサービスごとに確認

Commune全体の推計約30.7万人と、DS.LABの1,750人の漏えい可能性、Sansan User Forumの1,325人の漏えい確認および8,687人の漏えい可能性を区別した図
出典： コミューン株式会社、LINEヤフー株式会社、Sansan株式会社の2026年10月9日公表資料、およびコミューン株式会社の2026年10月13日公表資料をもとに弊社作成
※各社の対象人数は全体推計に加算していません。対象情報・漏洩の確認状況は各社の公表内容に基づきます。コミューンは10月13日、10月9日の公表以降、新たな不正アクセスや情報漏洩は確認されていないと発表しています。

SaaSの権限管理ではアクセスと操作の範囲を分けて考える

ここからは、今回の事案を踏まえて見直したい一般的なSaaSセキュリティ対策です。英国国家サイバーセキュリティセンター（NCSC）は、クラウドの安全性を評価する観点として、顧客間の分離、安全な利用者管理、認証、管理機能の保護を挙げています。ログインができることと、会員情報の一括取得や権限変更が許されることは、別々に制御しなければなりません。利用企業は、管理者を必要な担当者に限定し、退職や担当変更に応じてアクセス権を見直します。提供事業者に対しては、一般会員と管理者の境界や、顧客ごとのデータの境界を、どのように検証しているか確認することが重要です。

なお、今回の事案でテナント間の分離が破られたと確認されたわけではありません。多要素認証も有効な基本対策ですが、認証を強めればあらゆる権限の問題が解決するわけではありません。NCSCのSaaS利用ガイダンスを参考に、認証と権限設定をあわせて確認し、不要な機能や不要になった利用者のアクセスを残さない運用を整えましょう。

SaaSで扱う情報と事故調査に必要なログを把握する

SaaSを導入した部署が、登録項目や連携先を追加することもあります。契約時の評価だけで終えず、現在どの情報を扱っているのかを確認することが出発点です。会員登録の必須項目だけでなく、自由記述の自己紹介、追加プロフィール、画像に何が含まれ得るかまで運営担当者と整理します。事故への備えでは、監査ログを「保存しているか」だけで判断できません。NCSCは、利用企業が調査に必要な監査情報を入手できること、その提供方法や保存期間を把握していること、記録が改ざん・削除から保護されることを重視しています。会員情報へのアクセスや設定変更の履歴を、誰がどの手順で取り出せるのか、導入時から確認しておく必要があります。

連絡の受け手も決めておきたいところです。通知が契約担当者だけに届いても、運営の停止や会員への案内を判断する部署へ伝わらなければ対応が遅れます。SaaS事業者からの通知を、情報システム部門と実際の運営部門の双方が受け取り、対象者と対象情報の確定状況を同じ記録で追えるようにします。NCSCも、サービス全体の障害を含めた対応手順と、有効な連絡先の準備を求めています。

利用者には確認済みの情報を正確に伝える

利用者には、自分が参加するコミュニティの運営企業の公式発表を確認してもらうことが基本です。LINEヤフーは、本件に便乗する不審なメールやメッセージへの注意を呼びかけ、心当たりのないリンクを開いたり個人情報を入力したりしないよう案内しています。お詫びメールを装う連絡も想定し、正規の問い合わせ先と確認方法を明示すると、利用者が判断しやすくなります。一方で、漏洩項目に含まれない情報まで「流出した」と知らせるべきではありません。今回のSansanの発表でも、パスワードは対象外と明記されています。調査中の事項は調査中と伝え、対象範囲が変わった場合に更新する運用が必要です。

クラウド利用の管理体制を BBSecと見直す

SaaSの安全な利用には、技術的な設定と、委託先との役割分担・社内規程を結び付ける作業が欠かせません。ブロードバンドセキュリティ（BBSec）が提供している「ISO/IEC 27017 クラウドセキュリティ認証取得支援」は、クラウドの提供事業者と利用事業者を対象とし、現状のアセスメント、規格とのギャップ把握、規程文書の整備、社員教育を支援します。クラウドサービスの管理状況を把握し、権限管理や事故対応のルールを含めた管理体制の整備を検討される際は、BBSecへご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策

Share
skyticketで約1,464万件の情報流出アイキャッチ画像

旅行比較予約サイト「skyticket」を運営するアドベンチャーは2026年10月9日、顧客情報の流出に関する3件の不正アクセスを公表しました。さらに10月16日には、第2報として一部利用者のクレジットカード情報等の流出を発表しています。 発生した場所も、対象情報も一様ではありません。企業の対策に生かすには、個々の事案を分けて理解し、管理機能と利用者向け機能の双方で、アクセス制御が適切かを確認する必要があります。

※本記事は2026年10月16日時点までで確認できる公表資料に基づき作成しています。

約1,464万件の情報流出と3つの不正アクセス事案

10月16日の第2報では、サーバーへの不正アクセスにより、最大6,140名分のクレジットカード情報等が流出したことも判明しました。公式発表が整理した3つの経路と対象件数は下図の通りです。

図：skyticketの3つの不正アクセス経路と情報流出の概要

skyticketの3つの不正アクセス経路と情報流出の概要
出典：株式会社アドベンチャーの2026年10月9日および10月16日公表資料をもとに弊社作成
※約413万件は約1,464万件の内数です。第2報で判明したクレジットカード情報（最大6,140名分）はサーバー事案に関する追加情報です。3事案では件数の単位や調査状況が異なるため、合計を被害人数として扱うことはできません。

自社への教訓を考える際も、これらを一つの原因で説明しないことが重要です。管理機能からアクセスできる範囲と、利用者へ個人情報を返す機能のアクセス制御は、それぞれの担当者と仕様を確認する必要があります。

利用者が確認したい流出情報と注意点

同社は10月9日の発表でクレジットカード番号の流出を否定していましたが、10月16日の第2報で内容を訂正しました。2017年2月から2018年6月までに「skyticketプレミアム」の会費支払いに利用されたクレジットカード情報が、最大6,140名分流出したことが判明しています。対象にはカード番号、名義人名、有効期限が含まれますが、セキュリティコードは含まれていません。また、会員特典である「ベネフィット・ステーション」の会員ID、氏名、パスワードの流出も確認されています。同社は対象者にクレジットカードの利用明細の確認を求めるとともに、会員には公式サイト・アプリでのパスワード変更と、同じパスワードを使う他サービスでの変更を呼びかけています。

企業側の通知でも、どの情報が対象で、利用者に何をしてほしいのかを結び付けて伝える必要があります。氏名や連絡先、予約内容が対象であれば、単に「不審なメールに注意」とするだけでなく、問い合わせ先と確認方法を案内する方が、利用者は行動に移しやすくなります。

ハッシュ化されたパスワードも 流出後の対応が必要

パスワードのハッシュ化は、入力された文字列を一定の処理でハッシュ値に変換して保存し、元のパスワードをそのまま持たないための仕組みです。ただし、ハッシュ値が外部へ出た場合に、パスワードが絶対に判明しないことを意味するわけではありません。攻撃者がパスワードの候補からハッシュ値を計算して照合する攻撃に対し、解析を困難にする仕組みが重要です。

OWASPは、パスワード保存に適した方式や処理コストの設定、利用者ごとに異なるソルトの使用などを説明しています。ソルトとは、同じパスワードでも同じハッシュ値になりにくくするために加える値です。本件の発表では方式や具体的な設定までは示されていないため、解析の容易さを断定することはできません。企業が保管方法を点検する際は、「ハッシュ化しているか」という確認だけで終えないことが大切です。方式、設定値、ソルトの扱いを確認し、漏えい時に利用者へ変更を求める手順まで整えておきます。パスワードの安全な保存方法と、流出時の対応手順を併せて整備することが重要です。

認証と認可を分けて 予約情報へのアクセスを確認する

今回のバス予約ページの問題から、Webサービスの担当者が再確認したいのが認証と認可の違いです。認証は「誰であるか」を確認する処理、認可は「その情報や操作を許可してよいか」を判断する処理です。ログインできた利用者であっても、他人の予約情報を閲覧できていいわけではありません。

OWASPは、必要最小限の権限、原則としてアクセスを拒否する設計、リクエストごとの権限確認を推奨しています。URLが推測しにくいことや、画面にリンクが表示されないことだけを、アクセス制御の代わりにはできません。利用者と対象データの関係を、サーバー側で判断する設計が必要です。自社サービスの点検では、予約完了画面、マイページ、明細のダウンロード、APIなど、個人情報を返す機能を対象にします。未ログインの状態だけでなく、別の利用者として操作した場合や、権限を変更した後の状態も確認します。これは本件でAPIや別利用者の権限に問題があったと断定するものではなく、認可の確認を自社へ広げるための観点です。

管理機能の先にあるデータも 守る範囲に含める

今回の発表は、管理機能に使われた製品や具体的な操作方法を明らかにしていません。公表されていない製品や攻撃手法を、原因として推測することは適切ではありません。[1]企業側は、自社の管理機能からアクセスできるデータを確認するとよいでしょう。業務担当者に必要な操作、アプリケーションが必要とする接続権限、運用保守のための権限を区別し、それぞれが目的を超えて広がっていないかを点検します。必要最小限の権限は、画面の利用者にも、バックエンドの接続にも適用すべき考え方です。

第2報では、2018年7月にクレジットカード情報を自社サーバーで保管しない方式へ移行した際、会費支払いに関する記録（ログ）が削除されずに残っていたことが明らかになりました。このログは今回の不正アクセスで取得され、暗号化されたカード情報とともに、暗号化に用いる情報も不正に取得されていたため、情報が読み取られるおそれがあるとされています。この事案は、システム変更時に不要となったデータの削除状況や、ログに含まれる機密情報の管理を確認する重要性も示しています。

弊社が2026年10月8日に公表した提言でも、公開Webサービスの脆弱性修正、設定の適正化、認証・権限管理の徹底に加え、対策の実効性を継続的に確認することの重要性を指摘しています。新機能のリリース前だけでなく、運用中の変更がアクセス範囲を広げていないかを確かめることが重要です。

ブロードバンドセキュリティ（BBSec）「国内で相次ぐ不正アクセスを受け、
BBSecが公開Webサービスの基本対策の再点検を提言」（2026年10月8日）（https://www.bbsec.co.jp/news/20261008.html）

Webアプリケーション・APIの脆弱性を診断で確認

自社でログインできることは確認していても、許可されない操作が拒否されることまで十分に検証できているでしょうか。BBSecの「Webアプリケーション脆弱性診断」は、外部から動的に検証し、攻撃の入口になり得る問題の検出を支援します。開発時の確認に加えて、運用中のシステムにも定期的に活用できます。診断を検討する際は、顧客向けの画面だけでなく、業務管理機能、個人情報を返すAPI、利用者の役割ごとのアクセス範囲を伝えることが大切です。どの機能と権限の組み合わせを検証するかは、個別の対象や業務要件に合わせて調整します。さらに設計段階から見直したい場合には、要件定義・設計のレビューや開発標準の整備を支援する「Shift Leftコンサルティング」もご活用いただけます。

個人情報の収集・管理・提供に関わる各機能を横断的に確認することが、セキュリティ対策の抜け漏れを防ぐ第一歩です。自社のWebサービスでどこまで点検できているかを整理し、重要な情報を扱う範囲から具体的な検証につなげていきましょう。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

国内で相次ぐ不正アクセス、企業が点検すべきAPIと業務システム

Share
国内で相次ぐ不正アクセス、企業が点検すべきAPIと業務システムアイキャッチ画像

不正アクセスに関する注意喚起を受け、自社で利用している製品を確認するだけでは、点検すべき範囲を見落とす可能性があります。Webサービスの裏側で動くAPIや、限られた従業員だけが使う業務システムまで含め、公開範囲と操作権限を確認することが重要です。

JPCERT/CCは2026年10月8日、国内組織で相次ぐ不正アクセスについて注意喚起を公表し、翌9日に情報を追加しました*4。本記事では、注意喚起のうちAPIや業務システムに関する内容を中心に、OWASPの技術資料も踏まえながら、企業が実施すべき点検方法を解説します。

今回の注意喚起で確認されていること

JPCERT/CCが取り上げているのは、2026年9月前後に国内組織で相次いだ、個人情報等の漏えいにつながる不正アクセスです。既知の脆弱性の探索・悪用やAPI経由の不正操作、BIツール「Metabase」の脆弱性を悪用した攻撃などが報告されています。また、一般利用者向けのサービスだけでなく、BIツールや従業員向け管理システムも被害対象となっています。10月9日の更新では、公開Webサーバーからアクセス可能なアプリケーションサーバーにWebシェルが設置された事案が追加されました。

ただし、公表された事案を一つの原因で説明することはできませんJPCERT/CCは、攻撃に関する技術的な情報の共有が十分でない状況を説明し、把握している情報について「限定的かつ断片的」としています※。

出典：JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開、10月9日更新）（https://www.jpcert.or.jp/at/2026/at260030.html）I. 概要より一部引用。

こうした状況を踏まえ、以降はAPIや業務システムのセキュリティ対策について、企業が確認すべきポイントを解説します。

画面に表示されないAPIも点検が必要

APIは、アプリケーション同士がデータや機能をやり取りするための仕組みです。スマートフォンアプリやWeb画面でボタンを押すと、その裏側でAPIに要求が送られ、サーバーが処理する構成があります。画面の表示と、サーバーが要求を受け付ける条件は、それぞれ確認する必要があります。例えば、一般利用者には管理ボタンを表示しない設計でも、それだけで管理用APIへの要求を防げるわけではありません。要求を受けたサーバーが利用者の権限を確認しなければ、本来許可されていない機能を実行されるおそれがあります。OWASPは、こうした問題を機能レベルの認可の不備として整理しています*2。

認証は利用者が誰かを確認すること、認可はその利用者が何をしてよいかを判断することです。ログイン済みであっても、すべての顧客情報を閲覧してよいとは限りません。同じ閲覧機能でも、自分の契約に属するデータだけを扱えるよう、対象データごとに権限を確認する必要があります。

図：画面の表示制御とAPIの権限確認

画面の表示制御とAPIの権限確認
出典： OWASP「API Security Top 10 2023」（API1:2023、API5:2023）および「REST Security Cheat Sheet」を参考に弊社作成。
注記： 一般的なAPIの認証・認可の仕組みを示した模式図であり、今回の不正アクセス事案を再現したものではありません。

管理用や内部利用を想定したAPIであっても、適切なアクセス制御は欠かせません。OWASPの「REST Security Cheat Sheet」では、非公開のRESTサービスについても、各APIエンドポイントでアクセス制御を実施することを求めています。APIのURLが一般に知られていないことだけを安全性の根拠とせず、アクセス元の制限や利用者の認証・認可を適切に設定する必要があります。

自社で確認すべき6つの点検項目

公開中のシステムとAPIを把握しているか

まず、運用担当者や開発委託先に、現在動いているシステムとAPIの一覧を確認します。サービス名だけでなく、利用目的、管理担当者、接続先、扱うデータ、利用を許可する相手まで整理すると、見直すべき範囲がはっきりします。仕様書と実際の稼働環境に差がないかも確認したいところです。特に確認したいのは、更新前のAPI、試験用の環境、保守用の機能です。OWASPは、管理から漏れた古いAPIや不要な公開環境をリスクとして挙げています*3。本番のAPIを修正しても、同じデータに接続する旧版が動き続けていれば、点検は完了していません。廃止の判断には利用状況を確認し、停止する担当者と日程まで決めておきます。

また、公開Webサーバーから内部のアプリケーションサーバーや管理システムへ、どのような通信が許可されているかも確認します。外部公開していないシステムであっても、公開サーバーを経由して到達できる場合があります。業務上必要な通信に限定されているか、不要な接続経路が残っていないかを点検することが重要です。

利用者ごとの操作権限は適切か

権限の確認では、誰に、どの機能を、どのデータに対して許可するのかを明文化します。例えば「担当者は自分の担当顧客を閲覧できるが、他部署の顧客情報の出力はできない」といった業務上の条件です。一般利用者と管理者の区別に加えて、所属部署や契約先などの境界も整理します。そのうえで、許可された操作が成功することと、許可されていない操作が拒否されることの両方を確認します。機能単位の権限と、データ単位の権限は別々の観点です。実機での確認は、システム所有者と対象範囲を合意し、検証用アカウントやテストデータを用意して進めます。

APIキーやトークンを失効できるか

APIキーやアクセストークンの管理では、発行済みのものを把握できるかに加え、漏えいが疑われた際に失効させられるかを確認します。どのシステムが使い、どこまでの操作を許可し、誰が更新するのかが分からなければ、緊急時の判断が遅れます。OWASPも、秘密情報への最小限の権限付与と、更新・失効・有効期限を含む管理を示しています*4。実務では、鍵の値そのものを点検表に転記せず、識別子と用途、管理先を記録すると扱いやすくなります。更新後に古い認証情報が使えなくなるか、連携先の設定変更が必要かも確かめます。APIキーの所持だけを機密性の高い処理の許可条件とせず、システムの用途や扱う情報に応じて、適切な認証・認可の仕組みを組み合わせることが重要です。

APIの大量実行を制限できるか

操作権限の確認とあわせて、短時間に繰り返される要求への制限も確認します。検索やパスワード再設定など、機能ごとに通常の利用量を把握し、実行回数や一度に返すデータ件数に適切な上限を設けます。OWASPも、業務に応じたレート制限や応答件数の制限を推奨しています*5。ただし、回数を制限しても、権限のない操作が一度でも通る問題は解消しません。認可の点検と並行して進めます。

脆弱性の修正と暫定措置を管理できるか

既知の脆弱性への対応は、利用製品や部品のバージョンを把握することから始まります。開発委託先に確認する場合も、「対応済み」という回答だけで終えず、修正した対象と反映日、残っている課題を共有してもらいます。更新による業務影響が心配な場合は、検証環境で機能を確認したうえで反映します。すぐに更新できなければ、提供元の回避策や機能制限などの適用可否を検討します。OWASPも、修正版の検証と、修正できない場合の暫定的な緩和策を分けて扱っています*6。暫定措置には担当者と見直し期限を設定し、恒久対応まで追跡することを勧めます。

不審な操作をログで追跡できるか

ログの点検では、記録の有無に加えて、利用者と操作内容を結び付けて調べられるかを確認します。認証や権限確認の失敗、権限変更、アカウント作成、データ出力といった操作は、調査に役立つ手掛かりになります。OWASPのログ管理資料でも、これらの記録が取り上げられています*7。例えば、通常と異なる時間帯に大量の出力が行われた場合、操作した主体、対象データ、実行結果を追えるでしょうか。担当者が一件の操作を実際にたどってみると、記録項目や保存先の不足を見つけやすくなります。一方、パスワードやアクセストークンをそのままログに残すと、記録自体が漏えいの原因になり得ます。必要な情報を選び、秘密情報は記録から除外・マスキングする設計が必要です。

点検結果を改善と初動対応につなげる

点検で見つかった問題は、対応する人と完了を確かめる方法まで決めて初めて管理できます。本記事では、点検結果に「対象」「確認できた事実」「業務への影響」「対応担当者」「期限」「再確認の方法」を残す運用を勧めます。判断材料が不足する項目は、問題なしとして閉じず、未確認の内容を明らかにして担当者へ引き継ぎます。例えば、使われていない公開APIが見つかったなら、利用状況を確認して公開を止め、実際に外部から利用できなくなったかを確認します。権限の不備を修正したなら、許可されない操作が拒否されることと、正規の業務が継続できることを再度確かめます。修正作業の完了と、安全性の確認を対応記録の中で結び付けることが大切です。

不正アクセスが疑われる場合の対応

すでに不審な操作が確認されている場合は、予防目的の点検だけでなく、インシデント対応の担当者へ速やかに連絡します。原因調査に必要なログや設定情報などを保全し、証拠を失わないよう注意しながら、被害の拡大を抑える措置を検討します。平時から、夜間や休日の連絡先と、システムの利用停止を判断する責任者を決めておくことも重要です。

脆弱性診断を相談する前に整理しておきたい情報

専門家に相談する際には、対象URLの一覧に加え、API仕様書、利用者の権限区分、重要な業務機能、扱う情報を整理しておくと、確認したい範囲が伝わりやすくなります。顧客向けの画面だけを対象にするのか、管理機能やAPIも含めるのかを、依頼段階で明確にしておきましょう。自社のAPIや管理機能について、どこまでを診断対象に含めるべきか判断が難しい場合は、システムの構成や業務上の権限を共有したうえでご相談ください。運用中のシステムを定期的に点検する機会としては、脆弱性診断を活用できます。

Webアプリケーションの脆弱性を把握し、適切な対策につなげる

ブロードバンドセキュリティ（BBSec）の「Webアプリケーション脆弱性診断」では、Webアプリケーションの脆弱性を診断し、リスクの深刻度と推奨対策をご報告します。管理機能やAPIを含む診断範囲についても、お気軽にご相談ください。

【関連記事】

APIの脅威と対策について知りたい方は、「OWASP API Security Top 10とは？APIの脅威と対策を知ろう」もあわせてご覧ください。

公開範囲と権限を確かめることから始める

今回の注意喚起を自社の対策につなげるには、現在公開しているシステムを把握し、誰がどの情報を扱えるのかを確かめることが出発点になります。まずは主要な業務システムを一つ選び、APIの一覧、権限の設計、操作ログを担当者と確認してみてください。確認できない部分が見つかれば、そこから次の調査や改善につなげられます。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

サイバー対処能力強化法の対象企業とは？特別社会基盤事業者と届出義務を解説

Share
サイバー対処能力強化法の対象企業とは？アイキャッチ画像

サイバー対処能力強化法の対象企業は、業種や企業規模だけでは判断できません。直接の義務対象となるのは、経済安全保障推進法に基づく特定社会基盤事業者のうち、特定重要電子計算機を使用する「特別社会基盤事業者」です。対象となるシステムには、自社所有の設備だけでなく、クラウドや委託先が管理するものも含まれる可能性があります。本記事では、対象企業の判断基準、特定重要電子計算機の範囲、届出義務と企業が準備すべき事項を解説します。

制度全体については、「サイバー対処能力強化法とは？4つの柱と施行スケジュールをわかりやすく解説」で紹介しています。

サイバー対処能力強化法の対象となる企業の条件

法律上の直接的な義務主体は「特別社会基盤事業者」です。特定社会基盤事業者であることに加え、そのサイバーセキュリティが害された場合に特定重要設備の機能が停止または低下するおそれのある「特定重要電子計算機」を使用していることが条件になります。したがって、「基幹インフラ15分野の企業はすべて対象」「指定企業の全システムが対象」といった説明は正確ではありません。自社が個別指定を受けているか、対象となる特定重要設備は何か、その機能に影響する電子計算機はどこまでかを順に確認する必要があります。

特定社会基盤事業者と特別社会基盤事業者の違い

「特定社会基盤事業者」は、経済安全保障推進法に基づき、国民生活や経済活動の基盤となる役務を安定的に提供するため、事業所管大臣から指定された事業者です。特定重要設備を導入し、または重要な維持管理等を委託する際に、同法に基づく事前届出と審査を受ける制度の対象になります。一方の「特別社会基盤事業者」は、特定社会基盤事業者のうち、サイバー対処能力強化法上の特定重要電子計算機を使用する者です。名称が似ていますが、根拠となる義務と対象設備が異なります。特定重要設備の導入前審査と、特定重要電子計算機の導入後届出を混同しないことが重要です。

特定社会基盤事業者の対象15分野

経済安全保障推進法の基幹インフラ制度は、電気、ガス、石油、水道、鉄道、貨物自動車運送、外航貨物、港湾運送、航空、空港、電気通信、放送、郵便、金融、クレジットカードの15分野を対象としています。ただし、15分野に属するすべての企業が自動的に特別社会基盤事業者となるわけではありません。事業所管大臣による個別指定と、特定重要電子計算機の使用状況を確認する必要があります（内閣府「基幹インフラ役務の安定的な提供の確保に関する制度」。

2026年6月17日に公布された改正法で医療分野が追加されましたが、追加規定は公布から1年6か月以内に政令で定める日から施行されるため、施行日や新たな指定の状況を確認する必要があります。制度改正や新たな指定により範囲は変わるため、記事公開時や自社判定時には、内閣府の最新の指定一覧と施行状況を確認してください。

特定重要電子計算機とは

特定重要電子計算機は、特定社会基盤事業者が使用する電子計算機のうち、サイバーセキュリティが害された場合に、特定重要設備の機能が停止または低下するおそれのあるものです。対象はハードウェアだけではなく、組み込まれたOS、ミドルウェア、アプリケーション、ファームウェアなどのプログラムも含み得ます。

施行令は、大きく三つの類型を定めています。第一は、特定重要設備である電子計算機またはその一部を構成する電子計算機です。第二は、特定重要設備と直接または間接に接続され、その機能に影響する電磁的記録を送信する機能を持つ一定の電子計算機です。第三は、特定重要設備の情報処理に用いるデータを作成し、そのデータが一定期間ごとに入力されなければ設備の機能が停止または低下する一定の電子計算機です。

対象範囲を制御システム本体だけに限定すると、接続機器やデータ供給系を見落とします。反対に、社内の端末やサーバーを無条件にすべて含めるのも適切ではありません。「特定重要設備の機能にどのような影響を与え得るか」という関係を、システム構成図とデータフローで確認することが必要です。

クラウドや委託先、海外のシステムも対象になり得る

法令上の「使用」は、必ずしも自社所有を意味しません。2026年10月に公表された制度解説では、グループ会社が所有するシステム、クラウドサービス、海外に存在するシステム、他社と共同利用するシステム、災害復旧サイトも、要件を満たせば特定重要電子計算機に該当し得ると説明しています。ここで重要なのは、所有者と義務主体が同じとは限らないことです。クラウドや運用委託先が管理するシステムでも、特別社会基盤事業者が自社事業に使用し、特定重要設備の機能に影響するなら、対象となる可能性があります。共同利用の場合には、複数の特別社会基盤事業者がそれぞれ届出・報告義務を負う可能性もあります。

特定重要電子計算機の届出義務

特別社会基盤事業者は、特定重要電子計算機を導入した場合、原則として導入日から4か月以内に事業所管大臣へ届け出ます。2026年10月1日に届出制度が施行され、施行時点ですでに導入済みのものについては、施行日から6か月以内とする経過措置があります。届出事項を変更した場合も、原則として変更から4か月以内に変更届が必要です（e-Gov法令検索「重要電子計算機に対する不正な行為による被害の防止に関する法律に基づく特別社会基盤事業者による特定侵害事象等の報告等に関する命令」）。

届出には、事業者の概要、特定重要設備と電子計算機の区分、製品名、製造者名などが含まれます。ただし、主務省令は、広く一般に使用されているものとして主務大臣等が指定する製品を届出対象外とする仕組みを設けています。具体的な対象外製品については、公布された告示を確認する必要があります。届出対象外であっても、特定重要電子計算機である限り、インシデント報告の対象になり得る点には注意が必要です。

特定重要電子計算機で発生した事象の報告対象と期限は、「特定重要電子計算機のインシデント報告」で詳しく解説します。

届出に向けた資産管理のポイント

実務では、最初に特定重要設備と関連システムの境界を定め、ネットワーク接続、データ入力、運用委託、クラウド責任分界を可視化します。そのうえで、届出対象となるハードウェアとプログラムを抽出し、製品名、製造者、バージョン、用途、管理者、変更履歴を更新できる状態にします。制度解説は、システム概略図と資産一覧を整理する手順を示しています。これは単なる申請書作成ではなく、「どの資産で異常が起きたら、誰が特定侵害事象等を判定するのか」を決める作業でもあります。資産の所有者、運用者、監視担当、法令上の義務主体が異なる環境ほど、平時の関係者調整が重要です。

ITベンダー・クラウド事業者への影響

ベンダーや委託先が特別社会基盤事業者でなければ、本法の届出・報告義務を直接負うとは限りません。しかし、対象事業者が報告するためには、委託先からの迅速な通知、ログやIoC、影響を受けた製品・バージョン、対応状況などの情報が必要になります。契約やSLAでは、通知対象となる事象、初回連絡までの時間、連絡先、証拠保全、ログ提供の範囲、再委託先からの情報取得、緊急時の協力体制を確認しておくべきです。これはすべてのベンダーに法律が一律に課す義務ではありませんが、対象事業者との契約上、実務的な要求が強まる可能性があります。

外部公開資産の把握とASMの活用

特定重要電子計算機の届出に向けた資産整理では、内部のシステム構成や運用状況を把握することが基本となります。一方、外部に公開されている資産や設定上の問題など、内部の管理台帳だけでは把握しきれないリスクにも注意が必要です。

ブロードバンドセキュリティ（BBSec）の「アタックサーフェス調査」では、公開情報（OSINT）を活用し、攻撃者の視点から外部公開資産や潜在的なリスクを可視化します。法定届出を代行するサービスではありませんが、管理漏れや外部に露出したリスクの把握に活用できます。

まとめ

サイバー対処能力強化法の対象企業を判断するときは、業種、事業者指定、使用する電子計算機という三段階で確認します。基幹インフラ分野に属するだけで対象と決めつけず、特定社会基盤事業者として指定され、特定重要電子計算機を使用しているかを見極める必要があります。クラウド、共同利用、海外設置、委託先管理であっても対象になり得るため、資産の所有関係だけで線を引くことはできません。特定重要設備の機能、システム接続、データフロー、責任分界、連絡経路を一つの図で確認できる状態にすることが、届出とインシデント報告の双方に役立ちます。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

SCS評価制度の★3とは？26の要求事項・81の評価基準と自己評価を解説

Share
SCS評価制度の★3とは？アイキャッチ画像

SCS評価制度の★3は、一般的なサイバー脅威に対処できるセキュリティ対策の実施状況を、専門家の確認を受けた自己評価によって示す段階です。2027年3月頃の運用開始が予定されており、企業が自社の対策状況を取引先へ説明するための共通基準として活用されることが想定されています。★3には7分野・26の要求事項と81の評価基準があり、登録にはすべての基準への適合とSCSセキュリティ専門家による確認が必要です。本記事では、★3の要求事項、専門家確認付き自己評価、登録までの流れを整理し、企業が準備したい規程、運用、証跡について解説します。

※本記事の情報は2026年10月12日時点でIPA、経済産業省およびBBSecが公表している資料に基づいています。今後公表・更新される情報については、最新の公式資料をご確認ください。

制度全体の目的や★3・★4の違いは「SCS評価制度とは？★3・★4の違い、開始時期と企業が進める対策【2026年版】」で解説しています。

SCS評価制度の★3とは

SCS評価制度は、正式には「サプライチェーン強化に向けたセキュリティ対策評価制度」といい、経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営する制度です。委託元が取引先に求めるセキュリティ対策を共通の基準で示し、取引先側も自社の対策状況を説明しやすくすることが目的です。

そのうち★3は、IPAが「一般的なサイバー脅威に対処しうること」を水準として定めた段階です。★4が第三者評価、実地審査、技術検証を求めるのに対し、★3は登録希望組織による自己評価を基本とします。ただし、自己評価だけで完結するのではなく、★3確認責任者による妥当性の確認と署名が必要です。公式には「専門家確認付き自己評価」と呼ばれています。SCSセキュリティ専門家は、単にセキュリティ業務の経験がある人を指すわけではありません。IPAの制度事務局に登録された専門家であり、★3では自己評価結果の確認・助言を担います。IPAは、SCSセキュリティ専門家を2027年1月以降に公表する予定です。

なお、一般には「★3取得」と表現されることもありますが、IPAの公式文書では、要求事項への適合を申請し、登録組織台帳へ掲載されることを「登録」としています。本記事でも、原則として「登録」と表記します。

★3は「自己評価」だが自己判断だけでは登録できない

「自己評価」と聞くと、企業が自らチェックを付けて申請する仕組みを想像するかもしれません。しかし、★3は組織の自己判断だけで申請を完結できる制度ではありません。基本規程では、登録希望組織が要求事項・評価基準に基づいて自己評価を行い、社内外の★3確認責任者が内容の妥当性を確認し、署名する流れが定められています。その後、登録希望組織が自己適合宣言を行ってIPAへ申請し、不備がなければ登録組織台帳に登録・公表されます。

★3確認責任者は、自己評価表の文章を読みやすく整えるだけの役割ではありません。登録希望組織が作成した自己評価の内容と、それに関連する書類を確認し、評価内容が妥当かを判断します。必要に応じて修正を含む助言が行われ、最終的な提出内容について了承した場合に署名します。具体的な確認方法や必要書類については、今後公表される取得ガイドなども確認する必要があります。

SCS評価制度★3の26要求事項

IPAの要求事項・評価基準では、★3の対策を「ガバナンスの整備」「取引先管理」「リスクの特定」「攻撃等の防御」「攻撃等の検知」「インシデントへの対応」「インシデントからの復旧」の7分野に整理しています。公式Excelを要求事項単位で集計すると26項目、★3として適用される評価基準は81項目です。

大分類要求事項数主な内容
ガバナンスの整備3推進体制、守秘義務、セキュリティ対応方針
取引先管理3自社資産が接続する外部システム、機密情報、事故時の役割
リスクの特定4IT資産、ネットワーク、外部サービス、機密情報の管理
攻撃等の防御13ID・認証、教育、バックアップ、パッチ、マルウェア対策など
攻撃等の検知1不正通信の検知・遮断とアラート対応
インシデントへの対応1対応手順、連絡体制、報告・情報共有
インシデントからの復旧1重要業務の目標復旧レベルと復旧準備
出典：独立行政法人情報処理推進機構（IPA）「★3・★4 要求事項・評価基準」（2026年4月21日公開）（https://www.ipa.go.jp/security/scs/rcu1hd0000007a2i-att/20260327001-c.xlsx）を基に弊社作成

26という数字だけを見ると、対応範囲は限定的に感じられるかもしれません。しかし、一つの要求事項には複数の評価基準が含まれます。たとえば「管理者IDの管理手続」では、管理者と責任者の明確化、権限の限定、不要IDの無効化、発行・変更・削除の申請承認などが個別に確認されます。要求事項名だけを読んで「対応済み」と判断せず、評価基準の一つひとつまで確認する必要があります。

ガバナンスの整備では責任者と社内方針を明確にする

ガバナンスの整備では、セキュリティ推進活動を担当する部署、役員、従業員を決め、その役割と責任を定めます。守秘義務のルールとセキュリティ対応方針も必要です。方針を文書化するだけでなく、役員や従業員、派遣社員などが最新版を参照でき、改正時に周知される状態が求められます。★3の評価基準には、専任CISOや大規模な専任部門の新設自体を求める記載はありません。重要なのは、自社の組織規模に応じて責任の所在と連絡先を決め、年1回以上、平時の体制を点検することです。「情報システム担当者が何となく対応している」という状態から、経営と現場が役割を共有する状態へ変えることが出発点になります。

取引先管理では情報共有と事故対応の境界を決める

取引先管理では、顧客、子会社、関係会社、クラウドサービス提供者など、自社以外の組織が管理・提供し、自社の資産が接続しているシステムを把握する仕組みを整え、年1回以上、その内容を点検します。自社の機密情報を共有する相手とは、情報の定義、利用制限、保管方法、複製や第三者提供の可否、返還・廃棄について、業務開始前に取り決める必要があります。さらに、セキュリティインシデントが起きた場合の役割と責任も、共有先との間で明確にします。事故発生後に「どちらが調査するのか」「誰が委託元へ報告するのか」を決めるのでは遅いためです。契約書、覚書、クラウドサービスの利用条件、緊急連絡網など、複数部門に散らばる情報を整理する作業が必要になります。

リスクの特定ではIT資産と機密情報を把握する

リスクの特定では、パソコン、サーバ、OS、ソフトウェア、ネットワーク機器、クラウドサービスなどを把握し、管理する仕組みが求められます。機密情報についても、機密区分と取扱方法を定め、重要な情報の管理者、保管場所、保管期限、開示先などを把握できる状態にします。ここでつまずきやすいのが、台帳と実態のずれです。購入時の一覧が残っていても、退職者の端末、部門が独自契約したSaaS、保守切れの機器が反映されていなければ、正確なリスク評価はできません。★3対応は、IT資産管理と情報資産管理を見直す機会にもなります。

攻撃等の防御では日常的な運用が問われる

26要求事項の半数に当たる13項目は「攻撃等の防御」に含まれます。ユーザIDと管理者IDの管理、認証、アカウントロック、パスワード、アクセス権、教育・訓練、バックアップ、安全なシステム構成、パッチ適用、マルウェア対策、ネットワーク境界防護まで、日常のIT運用を広く確認する分野です。具体的には、重要な機密情報を取り扱うクラウドサービスへユーザや管理者がアクセスする際の多要素認証、役員、従業員、派遣社員、受入出向者を対象とした新規受入れ時かつ年1回以上のインシデント対応教育、対象・頻度・保管期間を定めたバックアップなどが求められます。

パッチ管理では、ベンダーが「重大」または「高リスク」と説明する脆弱性、CVSS基本値7.0以上の脆弱性、またはベンダーから深刻度の詳細が示されていない脆弱性を修正する更新プログラムについて、リリースから14日以内の適用を求めています。対象には、会社支給パソコンのOS・ブラウザ・Officeソフト、サーバのOS・ミドルウェア、会社支給スマートデバイス、インターネット境界機器などが含まれます。期限内に適用できない場合は、機能停止、ベンダー推奨の回避策、ネットワーク分離、通信監視と遮断などによるリスク低減が必要です。

したがって、「ウイルス対策ソフトを導入しているから大丈夫」とは言えません。設定が有効か、対象機器を網羅しているか、例外時の判断を記録しているかまで確認しなければ、運用の実効性を説明できないからです。

検知・対応・復旧までを一続きで整える

★3では、防御をすり抜ける攻撃も想定しています。社内外ネットワークの境界または端末で、インターネットから社内への不正アクセスと、社内から不正なサーバへの通信の双方をリアルタイムに検知・遮断する仕組みが必要です。ログやアラートを分析し、不審な事象がインシデントに該当するか判断する流れも整えます。インシデント対応手順には、発見・報告、初動、調査・対応、復旧、最終報告を含めます。社内外の連絡先、役員や担当部署の役割、報告フォーマットも事前に定めます。復旧については、事業継続上重要なシステムを特定し、サイバー攻撃を想定した業務の目標復旧レベルと、そこまで回復するための手段を用意します。

この3分野は、製品を導入するだけでは整いません。アラートを誰が受け、どの基準で判断し、経営や取引先へどう伝え、どの業務から復旧させるのか。検知から復旧までを一つのシナリオとしてつなぐことが重要です。

★3登録までの流れ

適用範囲と推進体制を決める

最初に、自組織内のどのIT基盤などを制度の適用範囲とするかを整理します。評価プロセスでは、登録希望組織が決めた適用範囲から対象をサンプリングして確認することが想定されています。全社を曖昧に対象とするのではなく、対象事業、拠点、システム、利用サービス、委託関係を言葉にできる状態にします。同時に、経営層、情報システム部門、総務・人事、法務・調達、事業部門などの役割を決めます。26要求事項は一部署だけでは完結しません。守秘義務、退職者対応、取引先との合意、教育、事業継続など、社内の複数部門が管理する証跡を集める必要があるためです。

26要求事項と81評価基準で現状を棚卸しする

次に、IPAの要求事項・評価基準を使い、適合している項目、対策はあるが証跡が不足している項目、未対応の項目を分けます。規程類だけで判断せず、資産台帳、申請記録、設定画面、ログ、教育記録、契約書、バックアップ記録など、実際に示せる根拠と結び付けて評価することが大切です。これらは準備時に確認しておきたい代表例であり、公式確認で必要となる書類の詳細は今後公表される取得ガイドなどで確認してください。公式FAQは、★3の登録には定められたすべての要求事項・評価基準を満たす必要があると説明しています*8。点数の合計で合否を決める方式ではないため、優先度の低そうな項目を未対応のまま残すことはできません。

ギャップを是正し、継続運用できる形にする

棚卸しで見つかった不足は、影響度、作業量、関係部門、予算、導入期間を踏まえて是正計画にします。規程の新設、ID管理手順の変更、多要素認証の導入、ログ監視体制の整備などでは、決裁や調達に時間がかかる場合があります。運用開始直前ではなく、制度開始前から準備する理由はここにあります。また、一度だけ証跡を作るのではなく、更新頻度と担当者を決めます。★3の有効期間は登録完了の通知日から1年間です。更新時には、要求事項の遵守状況について★3確認責任者の確認・助言を受け、自己評価の更新版を有効期間満了前に提出しなければなりません。

要求事項とのギャップ分析から是正計画、運用定着までの進め方は、「SCS評価制度への対応は何から始める？ギャップ分析から是正・運用定着まで」で詳しく解説しています。

SCSセキュリティ専門家の確認を受けて申請する

対策と証跡が整ったら、SCSセキュリティ専門家による確認を受けます。社内の専門家が担当する場合でも、制度が定める資格、研修受講、IPAへの登録が必要です。2026年10月12日時点では、登録されたSCSセキュリティ専門家は2027年1月以降に公表される予定です。★3・★4の申請方法、取得ガイド、要求事項・評価基準の解説書は、2026年10月頃の公開が予定されています。最新の公開状況はIPAの公式サイトで確認する必要があります。専門家の確認後、登録希望組織の経営層が、適用範囲内のIT基盤などがすべての要求事項・評価基準に適合していることを組織の責任において宣言し、制度運営機関であるIPAへ登録を申請します。申請内容に不備がなければ登録組織台帳に掲載され、制度の条件に従ってロゴマークを使用できます。

★3取得準備で企業が注意すべきポイント

「規程がある」と「運用できている」は別である

セキュリティ方針やインシデント対応規程があっても、連絡先が古い、教育記録が残っていない、定期点検をしていないといった状態では、評価基準を満たしていると説明できない可能性があります。規程、実装、運用記録の三つが一致しているかを確認する必要があります。

クラウドサービスと委託先を対象から落とさない

★3では、クラウドサービス提供者を含む取引先との関係や、外部情報サービスの利用管理も確認されます。情報システム部門が把握しているサーバやパソコンだけでなく、事業部門が利用するSaaS、外部委託先へ渡している機密情報、事故時の連絡方法まで棚卸しすることが重要です。

公式文書の更新を前提に準備する

2026年10月12日時点で、要求事項・評価基準、基本規程、制度に関する各種規則・基準・手順、登録料は公表されています*2。一方、申請方法、取得ガイド、要求事項・評価基準の解説書などは今後の公開が予定されています。実務上の確認方法や必要書類がさらに具体化される可能性があるため、現行資料で準備を進めながら、IPAの更新情報を継続して確認する必要があります。

BBSecの事前対策支援で★3対応を準備する

★3の準備で負担になりやすいのは、81の評価基準を読み解き、社内に散在する対策と証跡を集め、不足を具体的な是正計画へ変える作業です。自己評価では、既存対策の実態と証跡が評価基準に沿っているかを項目ごとに照合しなければなりません。外部の知見を取り入れることで、確認の抜けを抑え、是正の優先順位を整理しやすくなります。

ブロードバンドセキュリティ（BBSec）の「★3/★4自己評価対応支援（プレリミナリーサーベイ）」は、★3・★4の自己評価結果をコンサルタントが客観的に分析し、評価サマリーを提供するサービスです。自己評価そのものの支援にも対応し、結果を踏まえて、各要求事項の達成に向けた対策ロードマップの策定まで支援します。また、是正を継続的に進めるための「★3/★4準拠に向けた対策実行支援（BBSec Prime for Supply Chain Security Measures）」も提供しています。アセスメントで作成したロードマップに沿い、コンサルタントが1年間にわたって活動を支援するパッケージで、脆弱性情報の提供とインシデント発生時の初動対応相談も含まれます。必要に応じて、情報セキュリティ文書の整備、教育、インシデント対応訓練などの関連サービスも組み合わせられます。

これらは、現状把握、取得準備、是正・実装を支援するサービスです。SCS評価制度の登録やロゴマークの付与、★3確認責任者による公式確認そのものを代替するものではありません。まずはギャップを早期に把握し、★3確認責任者の確認を受けられる状態へ近づけるための準備支援と捉えると分かりやすいでしょう。

SCS評価制度★3に関するよくある質問

▼ ★3は第三者認証ですか
▼ 26要求事項の一部を満たせば登録できますか
▼ 社内のセキュリティ担当者が確認できますか
▼ ★3を取得してからでないと★4へ進めませんか
▼ ★3の有効期間は何年ですか
▼ ★3の登録範囲は全社でなければなりませんか
▼ ★3の自己評価ではどのような証跡を準備しますか
▼ SCS評価制度★3の登録料はいくらですか

★4の要求事項や第三者評価・技術検証については、「SCS評価制度の★4とは？43の要求事項・第三者評価・技術検証と取得準備を解説」で詳しく解説しています。

まとめ：★3対応は26要求事項を「運用と証跡」に変える取り組み

SCS評価制度の★3は、一般的なサイバー脅威へ対処するための基礎的な水準を、専門家確認付き自己評価によって示す仕組みです。要求事項は7分野・26項目ですが、実務では81の評価基準をすべて満たし、その根拠を説明できる状態にしなければなりません。準備の第一歩は、対象となるIT基盤と関係部門を定め、現状の対策と証跡を評価基準に照らして棚卸しすることです。そこで不足が見つかれば、制度開始を待たずに是正計画を立て、日常業務として継続できる運用へ落とし込みます。

【参考情報】

編集責任：木下

BBSecのセキュリティ対策支援サービス

ブロードバンドセキュリティ（BBSec）は、プレリミナリーサーベイによるギャップの可視化から、対策ロードマップの策定、文書整備や実装・運用支援まで、組織の状況に合わせて支援します。★3登録を取引先への説明力と継続的なセキュリティ改善につなげるためにも、早い段階から準備を始めることが重要です。

「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」
運用開始に備えた事前対策支援サービス

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

国内で相次ぐ情報漏洩・不正アクセス｜焼肉きんぐなど14事例とAI時代の対策

Share
【続】国内で相次ぐ情報漏洩・不正アクセスアイキャッチ画像

国内企業や公的機関で、情報漏洩や不正アクセスに関する公表が相次いでいます。「なぜこれほど被害が続くのか」「生成AIが攻撃に使われているのか」と疑問に感じる方もいるでしょう。ただし、公表の集中が攻撃件数の増加を意味するとは限らず、今回の国内事例でもAIの関与は確認されていません。本記事では、直近1か月に公表・続報があった国内14事例を紹介するとともに、海外で報告されたAI悪用の動向を踏まえ、企業が見直すべきセキュリティ対策を解説します。

※本記事は2026年10月7日時点までで確認できる公表資料に基づき作成しています。

図1：国内で公表された情報漏洩・不正アクセス14事例（2026年9月～10月）

国内で公表された情報漏洩・不正アクセス14事例アイキャッチ画像
出典：各社・各機関の公表資料を基に弊社作成
※日付は公表・掲載日です。漏洩の確認状況や数値の単位・対象は事例によって異なり、単純比較・合算はできません。i-ask関連の3社は1項目に集約しています。

会員アプリ・ECサイトへの不正アクセス

焼肉きんぐ｜会員情報約1,079万件が漏洩

物語コーポレーションは10月5日、焼肉きんぐ公式アプリの会員管理システムへの不正アクセスを公表しました。10月2日に不正アクセスを確認し、翌3日に会員情報の漏洩が判明しています。漏洩したのは10,788,963件で、会員番号、氏名として登録された名称、メールアドレス、電話番号が含まれます。一方、ログインパスワード、生年月日、店舗利用履歴などは漏洩しておらず、決済情報は同社が保持していないと説明しています。流出した情報と含まれない情報を区別し、不審な連絡に備えることが重要です。

ミスターマックス｜最大約173万人に情報流出の可能性

ミスターマックスは10月6日、MrMaxアプリとオンラインストアのサーバーへの不正アクセスにより、会員情報の一部が流出したと発表しました。流出の可能性がある対象は最大1,735,154人で、会員ID、氏名、メールアドレス、電話番号が挙げられています。最大人数全員の流出が確認されたわけではありません。同社は、ソフトウェアの機能を不正利用した侵入と説明しています。住所、生年月日、クレジットカード情報、パスワード、購入履歴は流出していないとしています。具体的な脆弱性や他社との攻撃手法の共通性は、公表内容からは断定できません。

GMOリサーチ＆AI「infoQ」｜情報漏洩とポイント不正交換

GMOリサーチ＆AIは10月5日、アンケートサイト「infoQ」への不正アクセスにより、会員の個人情報が外部に持ち出されたと発表しました。対象は最大948,498件で、氏名、住所、メールアドレス、暗号化されたパスワードなどが含まれます。侵入にはサイトで使用していたソフトウェアの脆弱性が悪用されました。また、611件、計2,869,500円分のポイントが本人の意思によらずAmazonギフトコードに交換され、同社は全額補填するとしています。個人情報の保護だけでなく、ポイント交換など価値の移転を伴う処理の監視も重要です。

ホワイトエッセンス｜約105万アカウントの情報を持ち出し

ホワイトエッセンスは10月5日、予約サイトと基幹システムへの不正アクセスについて、個人情報の外部持ち出しを確認したと公表しました。対象は約105万アカウントで、顧客のほか加盟院関係者や本部社員なども含まれます。対象情報は氏名、住所、連絡先、勤務先、暗号化されたパスワード、サービス利用・対応に関する情報などで、登録内容によって異なります。不正アクセスを確認したのは8月5日で、8月12日にシステムの一時停止を公表していました。10月5日の発表は調査の続報にあたります。

アバハウス｜個人情報漏洩の可能性と不審な返金メール

アバハウスインターナショナルは10月3日、会員情報・EC受注情報への不正アクセスの痕跡と、個人情報漏えいの可能性を公表しました。調査のきっかけは、実際の注文情報と一致する不審な返金案内メールを受け取った顧客からの連絡です。対象顧客には10月2日に個別通知しています。取得された情報の範囲は完全には特定できていません。同社は取引記録を保存しているため、退会者にも通知しています。注文商品や金額が一致していても正規の連絡とは限らず、返金案内は公式サイトから確認することが重要です。

Gポイント｜会員識別子最大約7万件が漏洩した可能性

ジー・プランは9月30日、Gポイントのシステムへの不正アクセスを公表しました。9月25日に異常を検知してサービスを停止し、外部からのアクセスを遮断しています。漏えいの可能性がある情報は最大約7万件の「会員識別子」であり、氏名や住所などの流出が確認されたわけではありません。9月30日時点で原因と影響範囲を調査中としています。

ニッポンレンタカー｜異なる手法による2件の不正アクセスが判明

ニッポンレンタカーサービスは9月26日、アプリへの不正アクセスにより41人の会員情報が閲覧されたおそれがあると公表しました。10月1日には、調査中に異なる手法による別の不正アクセスが判明し、55人の情報が閲覧されたおそれがあると説明しています。対象情報は氏名、連絡先、利用履歴などで、登録状況によっては免許証番号、住所、生年月日、クレジットカード番号下4桁、名義人名も含まれます。2件の対象者の重複は確認できないため、単純に96人とは合算できません。

日本郵政・日本郵便｜郵便局アプリで19人分の情報を不正取得

日本郵政と日本郵便は9月29日、郵便局アプリへの不正アクセスにより、ゆうIDとアプリに関連する顧客情報69件・19人分が不正取得されたと公表しました。対象者によっては会員情報のほか、住所録や送り状の差出人・受取人情報も含まれます。9月26日には調査と対策を実施したうえでサービスを再開しています。利用者本人だけでなく、サービスを通じて預かる第三者の情報も保護対象となります。

委託先・クラウドへの不正アクセス

スカラコミュニケーションズ「i-ask」｜大和証券・シチズン時計にも影響

スカラコミュニケーションズは10月6日、FAQシステム「i-ask」への不正アクセスを公表しました。管理サイトへの不正ログインと不正プログラムの設置により、同一サーバーで稼働する最大5社の問い合わせ情報が取得された可能性があります。対象は最大713,126件ですが、問い合わせ単位の延べ件数であり、実人数ではありません。大和証券は10月5日、約11万人分の氏名、メールアドレス、口座番号など、シチズン時計は10月6日、約10万人分の氏名、住所、連絡先などに漏洩の可能性があると公表しました。両社とも自社システムへの不正アクセスは確認されていません。シチズン時計では、問い合わせ内容に銀行口座情報やクレジットカード情報が記載されていた場合、それらも対象となる可能性があります。

図2：委託先のFAQシステム「i-ask」への不正アクセスと利用企業への影響

委託先のFAQシステム「i-ask」への不正アクセスと利用企業への影響アイキャッチ画像
出典：株式会社スカラコミュニケーションズ、大和証券株式会社、シチズン時計株式会社の公表資料をもとに弊社作成
※最大713,126件は問い合わせ情報の延べ件数であり、実人数ではありません。各社の対象人数との合算はできません。また、図は各社の自社システムへの侵入を示すものではありません。

IDCフロンティア｜クラウドサービスに障害

IDCフロンティアは10月7日、IDCFクラウドの一部システムへの不正アクセスにより、東日本第1リージョンでサービス障害が発生したと公表しました。同日時点で障害解消に向けた調査対応と、その他の領域の安全性確認を進めています。確認した公表資料からは、個人情報漏洩やランサムウェア被害が確定したとはいえません。情報の機密性だけでなく、サービスの可用性も重要な論点です。

GMOインターネット「ConoHa WING」｜426アカウントに影響

GMOインターネットは9月20日、「ConoHa WING」の一部顧客Webサーバー領域への不正アクセスと、不正プログラムの設置を公表しました。影響対象は426アカウントです。不正アクセスは9月3日に始まり、9月16日に検知、9月18日に原因・影響範囲の特定と不正プログラムの排除を完了したとしています。同社が別環境で管理する会員情報、契約情報、支払い情報の漏洩はないと説明しています。ただし、顧客がWebサーバー領域に保存したデータまで影響がなかったと判断することはできません。

ユニリタ｜社内文書管理システムから情報窃取

ユニリタは9月29日、特定の社内文書管理システムへの不正アクセスと情報窃取を確認したと公表しました。9月28日に情報を窃取したとするWeb上の公表を確認し、外部専門家と調査を進めています。事業上の機密事項や顧客情報を含む影響範囲は調査中で、公表時点ではシステム障害や業務上の支障は生じていないとしています。サービスが正常に稼働していても、情報の安全性が確保されているとは限りません。

公的機関への不正アクセス

日本原子力研究開発機構（JAEA）｜175人分の個人情報が漏洩

日本原子力研究開発機構（JAEA）は10月1日、クラウド基盤上の研究支援サイトへの不正アクセスによる情報漏洩を公表しました。不正にダウンロードされた2,419ファイルのうち、個人情報を含むものは367ファイル・175人分です。運転免許証やマイナンバーカードなどの画像、放射線業務の特殊健康診断結果、放射線業務従事者証明書が含まれ、6人分ではマイナンバーも確認されています。研究支援サイトは機構内の業務ネットワークから独立しており、他のシステムへの影響はないと説明しています。漏洩の影響は人数だけでなく、情報の内容からも評価する必要があります。

エネルギー・金属鉱物資源機構（JOGMEC）｜メールアドレス漏洩の可能性

エネルギー・金属鉱物資源機構（JOGMEC）は10月2日、不正アクセスによる個人情報漏えいの可能性を公表しました。9月9日に可能性が判明し、アクセス制限や通信制御などを実施しています。対象は役職員のメールアドレス約1,100件と、機構外のメールアドレス約7,400件です。公表時点で不特定多数への公開や不正利用は確認されていません。

相次ぐ情報漏洩をどう読み解くか

公表日と発生日の違い

情報漏洩の公表が相次ぐ理由と、攻撃が成立した原因は分けて考える必要があります。ホワイトエッセンスでは8月の不正アクセスについて10月に続報が出され、ConoHa WINGでも攻撃開始日、検知日、公表日は異なります。今回の14項目は国内被害の全件統計ではなく、同一原因による攻撃を集計したものでもありません。公表の集中だけから攻撃件数の増加やAIの影響を判断することはできません。

脆弱性と管理者アカウントのリスク

infoQではソフトウェアの脆弱性悪用、i-askでは管理サイトへの不正ログインと不正プログラムの設置が確認されています。侵入を防ぐには、脆弱性への対応と管理者アカウントの保護をそれぞれ点検する必要があります。ただし、原因が公表されていない事例まで同じ弱点に分類することはできません。企業は公開WebサイトやAPI、管理画面を把握し、修正プログラムの適用状況、管理者権限、多要素認証、接続制限などを確認することが重要です。開発時だけでなく、システムや委託先の変更時にも点検できる運用が求められます。

委託先と保存データの管理

i-askの事例では、一つの委託先への侵害が複数の利用企業に影響する可能性が示されました。シチズン時計は別システムへの移行中で、旧システムを継続対応のために限定利用していたと説明しています。また、アバハウスでは退会者の取引記録も調査対象となりました。企業には、現行システムだけでなく、移行中・停止予定の環境や保存済みデータまで含めた管理が必要です。委託先との間では、データの保存場所、削除条件、異常時の連絡方法、調査用ログの確認範囲を把握し、業務や法令上必要な保存との整合も図る必要があります。

AIの悪用とサイバー攻撃の変化

AIによる攻撃工程の効率化

英国国家サイバーセキュリティセンター（NCSC）は2025年5月7日の評価で、AIが標的調査、脆弱性調査、ソーシャルエンジニアリング、窃取データの処理など、既存の攻撃工程を効率化すると指摘しました。また、2027年に向けて既知の脆弱性を狙う攻撃が増え、脆弱性の公表から悪用までの時間もさらに短くなると予測しています。これは将来の脅威評価であり、今回の国内事例の発生原因や被害件数の増減を示すものではありません。

Anthropicが報告したAIエージェントの悪用

Anthropicは2025年11月13日、同年9月に検知した活動について、Claude Codeを悪用して約30の標的への侵入を試み、少数で成功したと報告しました。同社によると、偵察や脆弱性調査、取得データの分析などにAIが利用されました。一方、人間による指示や重要局面での判断は残っており、AIが使用できない認証情報を生成するなどの誤りも報告されています。これはAI提供企業による観測報告であり、すべての攻撃工程が自動化されたことを意味するものではありません。

図3：AIによるサイバー攻撃の変化と国内事例で確認された事実

AIによるサイバー攻撃の変化と国内事例で確認された事実アイキャッチ画像
出典：英国国家サイバーセキュリティセンター（NCSC）、Anthropicおよび各社公表資料を基に弊社作成

国内事例と区別して考える対策

NCSCの評価とAnthropicの報告からは、AIによって攻撃者の調査・分析が効率化され、防御側が脆弱性の修正や異常への対応に使える時間が短くなる可能性が読み取れます。ただし、今回の国内事例にAIが関与したと判断する根拠にはなりません。企業に必要なのは、AIの利用有無にかかわらず、不審な挙動を早期に把握し、対応できる体制です。i-askではデータベースの監視アラート、infoQでは会員からの問い合わせが調査の契機となりました。機器のアラートと顧客からの連絡を、調査・判断を担う担当者につなぐ仕組みが重要です。

企業が見直したいセキュリティ対策

今回の事例では、Webサイトや会員管理システムへの侵入に加え、委託先やクラウド環境を通じた被害も確認されています。企業には、自社の公開システムだけでなく、外部サービスや保存データも含めた継続的な点検が求められます。BBSecは2026年10月8日、国内で相次ぐ不正アクセスを受け、企業が見直すべきセキュリティ対策についてプレスリリースを発表しました。侵入の入口を減らす対策、異常の早期発見、被害発生後の対応について紹介しています。

関連情報：国内で相次ぐ不正アクセスを受け、BBSecが公開Webサービスの基本対策の再点検を提言

まとめ

今回の国内14事例からは、会員アプリやWebサイトだけでなく、委託先や社内システム、保存済みデータまで含めた対策の重要性が見えてきます。AIの関与の有無にかかわらず、企業には脆弱性や設定不備の継続的な点検と、異常の早期発見から初動対応までを実行できる体制づくりが求められます。

BBSecのセキュリティ対策支援

BBSecでは、公開システムの脆弱性診断から、ログ分析・監視、インシデント発生時の対応まで、企業のセキュリティ対策を支援しています。

関連サービス

国内インシデントの関連記事

国内で発生した不正アクセスや情報漏洩について、過去の事例もご紹介しています。ぜひあわせてご覧ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

国内の個人情報漏洩・不正アクセス事例まとめ ―セイコーマート・OZmallなど12事例

Share
国内の個人情報漏洩・不正アクセス事例まとめアイキャッチ画像

セイコーマートはアプリ登録会員57万2,022人分の情報が不正に閲覧されたことを公表し、OZmallは個人情報が閲覧された可能性のある対象範囲を最大44万2,779名分に更新しました。吉野家・はなまるの旧委託先での個人情報漏洩や、ヤマト運輸の「クロネコ代金後払いサービス」での情報漏洩の可能性が公表されるなど、9月末から10月初めにかけて、身近な企業・サービスに関する発表が相次いでいます。本記事では、国内で公表・更新された12事例について、対象規模や公表時点での状況を整理します。

※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

今回取り上げる12事例について、公表された対象規模と、公表時点での情報漏洩・不正閲覧等の状況を一覧にまとめました。詳細は各事例で紹介します。

図：国内の個人情報漏洩・不正アクセス事例

出典：各社の公式発表をもとに弊社作成（2026年10月2日時点）
※「確認」は情報の漏えい・不正閲覧・誤送付等が確認された事例、「可能性」は情報が閲覧・取得・漏えいした可能性がある事例です。対象規模は各社の公表単位に基づき、重複を含む場合があります。

OZmall（スターツ出版）｜最大44万2,779名の情報が閲覧された可能性

スターツ出版は10月1日、OZmall（オズモール）への不正アクセスに関する第2報を公表しました。個人情報が閲覧された可能性のある範囲は、会員と一部の退会者の最大44万2,779名分です。9月27日の初報で示した最大44万7,610名分から修正されています。対象はメールアドレスと、一部の方の氏名・住所（都道府県まで）です。9月26日に大量の不正アクセスを検知し、同社は原因を特定して脆弱性への対策と遮断を実施したと説明しています。脆弱性の詳細は公表していません。サービスは再開済みで、対象者には登録メールアドレスを通じて順次連絡しています。

らしんばん｜本人確認情報や銀行口座情報に漏洩の可能性

らしんばんは10月1日、9月14日から16日に受けた不正アクセスにより、顧客情報や配送先情報の一部が漏洩した可能性を公表しました。対象件数は未公表です。氏名や連絡先のほか、本人確認書類の種別・番号等、買取・注文の明細、買取申込時の銀行口座情報、買取にかかわる同意書画像などが含まれます。対象項目は利用状況によって異なります。同社はクレジットカード情報とパスワードの漏えいはないと説明しています。システム改修と不正アクセスの遮断を行い、警察への相談と個人情報保護委員会への報告を実施しました。影響を受けた可能性がある利用者への個別案内も進めています。

セイコーマート｜57万4,647人分の会員情報を不正閲覧

セイコーマートは10月5日の第四報で、アプリに登録したことがあるセイコーマートクラブ会員のうち57万4,647人分が、不正アクセスによる個人情報閲覧の対象になったと発表しました。9月30日の第三報で公表した57万2,022人分から対象人数が更新されています。9月24日までにセイコーマートクラブカードを退会した方は対象に含まれていません。同社は、すべてのアプリ会員に対し、個人情報閲覧の対象となったかどうかをアプリのお知らせで通知しています。また、アプリ・Web上での新規入会、会員情報の閲覧・変更、登録カードの変更機能を終了し、店舗またはフォームで受け付けたうえで同社が変更する運用としています。

ベネフィット・ワン｜1万3,460名の従業員情報が漏洩

ベネフィット・ワンは9月30日、企業・団体の担当者向け「ベネワン・プラットフォーム」のアンケート結果ダウンロード機能で、他企業・団体の従業員情報が表示される不具合を公表しました。対象は2,322企業・団体の1万3,460名で、氏名、社員・職員番号、生年月日、所属・役職などです。原因は2025年6月の改修に伴う条件設定の不備で、同年10月に認知していたものの解消作業が適切に行われていなかったと説明しています。2026年7月30日の利用企業からの連絡で本件が判明し、取得した担当者は1社1名でした。同社は第三者への提供がなく、連絡後にデータが削除されたことを確認しています。

VOISING｜約17万件の個人情報が漏洩

VOISINGは9月30日、8月に公表したBIツールへの不正アクセスについて、最終調査の完了を第四報で公表しました。漏えいが確認された対象は約17万件です。氏名・連絡先に加え、購買履歴や応援するタレントの選択情報などが含まれます。クレジットカード番号やログインパスワードに相当する情報は対象外です。同社は、BIツールの既知の脆弱性に対する修正の適用が、攻撃までに間に合わなかったと説明しています。侵害された環境を廃棄し、認証情報の失効・更新や権限の最小化を実施しました。今後は脆弱性対応の期限・責任者の明確化や監視の強化などに取り組む方針です。

吉野家・はなまる｜旧委託先から応募者情報が漏洩

吉野家ホールディングス、吉野家、はなまるは9月30日、旧委託先ApplyNowの採用管理プラットフォームへの不正アクセスによる個人情報漏えいを公表しました。応募者情報は吉野家4,998件、はなまる368件の計5,366件です。このほか採用担当者の情報418件も対象で、こちらは重複を含むアカウント数のため人数とは一致しません。発表によると、データ分析ツールの脆弱性が悪用されました。契約終了に伴い消去されると認識していた応募者情報が、旧委託先のデータベースに残っていたと説明しています。侵入経路の遮断と脆弱性の修正は完了しており、吉野家側のシステムへの不正アクセスは確認されていません。

損保ジャパン・TOPPAN｜17万7,426名の情報を誤送付

損保ジャパンとTOPPANは9月29日、保険料控除証明書発行サービスの委託業務で、契約者情報を別の損害保険会社1社へ誤送付したと公表しました。対象は17万7,426名ですが、同一契約者の重複を含む可能性があります。情報項目はカナ氏名、保険料控除用証券番号、業務IDです。9月1日、TOPPANの担当者がZIPファイルを操作した際に、損保ジャパンのデータを他社向けファイルへ混入させ、送付前の再確認も行っていなかったとしています。誤送付先での完全削除を確認し、発表時点で二次流出や不正利用は確認されていません。TOPPANは作業上の不備が原因で、サイバー攻撃によるものではないと説明しています。

イープラス｜払戻し情報1,463件が漏洩

イープラスは9月29日、電子チケット「スマチケ」の払戻し情報を管理するシステムへの不正アクセスで、1,463件の情報が漏えいしたと発表しました。不正アクセスは9月11日から12日にかけて発生しています。対象は2022年6月30日から2026年9月11日までに払戻しを申請した一部の利用者です。メールアドレスやカナ氏名、公演情報のほか、銀行振込751件には振込先口座情報、郵便振替払出証書68件には送付先住所などが含まれます。クレジットカード情報やパスワードは対象外です。同社は9月15日にアクセスを遮断し、9月29日から対象者への個別連絡を開始しました。具体的な侵入手法は公表されていません。

集英社｜ブロガー2,835名の情報が漏洩

集英社は9月28日、ファッション誌メディアで活動するブロガーの情報管理・連絡用システム「HAPPY PLUS COMMUNITY（ハピコミュ）」で、個人情報漏洩が発生したと公表しました。登録ブロガー2,835名の氏名や連絡先、プロフィール、SNSアカウントなどが対象です。登録内容によっては結婚状況や子の有無なども含まれ、項目は個人や媒体によって異なります。同社は、CMSの設定不備に起因するAPI認証情報への攻撃を受け、不正に作られた特権アカウントからAPIリクエストが繰り返されたことが、情報漏えいにつながったと考えています。不正アカウントの削除と設定変更を行い、9月25日に対象者へ通知しました。

手間いらず｜宿泊者情報が閲覧・取得された可能性

手間いらずは9月28日、宿泊予約管理サービス「TEMAIRAZUシリーズ」への不正アクセスを公表しました。9月21日深夜頃から、予約者に予約確認やカード情報の再入力、緊急支払いを求める不審なメッセージが届くとの連絡を受け、調査で不正アクセスを確認しています。宿泊者情報の一部が第三者に閲覧・取得された可能性を否定できず、件数や情報項目の詳細は未公表です。不審なメッセージとの関係も調査中としています。同社は原因への対策とアクセス制御・監視強化を実施し、停止機能を再開しました。予約者にはリンクを開かず、予約先などの公式窓口へ確認するよう案内しています。

東京メトロ｜約5万9,000件のメールアドレスが閲覧・取得された可能性

東京メトロは9月27日、メトロポイントクラブ「メトポ」の会員向けサービスが不正アクセスを受け、メールアドレス約5万9,000件が閲覧または取得された可能性があると公表しました。9月20日のメール配信サービスの不具合を調べる中、25日に通常と異なる利用記録を発見したとしています。対象は、送信不能のため配信を停止していたメールアドレスです。当該サーバーには、それ以外の会員情報は含まれていないと説明しています。防御措置は実施済みですが、影響範囲や原因の詳細は調査中です。対象者への案内で別途手続きや外部サイトへの移動を求めることはないとして、不審なメールへの注意を呼びかけています。

ヤマト運輸｜利用者情報が漏洩した可能性

ヤマト運輸は9月29日、「クロネコ代金後払いサービス」が第三者による不正アクセスを受けたことを公表しました。その後、10月2日の第2報で、情報の一部が漏洩した可能性があることを明らかにしています。漏洩した可能性があるのは、同サービスを利用した一部の顧客の氏名、住所、電話番号、メールアドレス、与信番号、請求金額、債権残高、商品明細のほか、一部の加盟店情報や担当社員の氏名です。クレジットカード情報やパスワード情報は含まれていません。対象範囲については引き続き調査中です。同社は9月28日に不正アクセスを確認し、外部からのアクセス制限などを実施したうえで、同日22時28分にサービスを停止しました。情報の漏洩が確認された利用者には個別に連絡するとしています。宅急便を含む他のサービスは通常どおり利用できます。

利用者が確認したいポイント

同じ「個人情報流出」という見出しでも、対象はメールアドレスだけの場合から、銀行口座、本人確認情報、購買履歴まで異なります。また、退会者や、過去の採用応募者が対象に含まれる事例もあります。利用中のサービスだけでなく、過去に登録・応募したサービスの公式発表や個別通知も確認してください。また、事故の通知を装った連絡への対応も大切です。手間いらずや東京メトロの案内では、不審なメッセージのリンクや外部サイトへの誘導に注意するよう呼びかけています。支払いや認証情報の入力を急がせる連絡を受けたときは、その本文から操作を進めず、公式サイトに掲載された窓口から確認してください。

企業が見直したい個人情報漏洩・不正アクセス対策

今回の事例では、外部からの不正アクセスだけでなく、脆弱性の悪用、システムの設定不備、委託先に残っていたデータ、ファイルの誤送付など、さまざまな要因で個人情報が影響を受けています。企業では、個別の対策だけでなく、システムの弱点を把握・改善し、異常を継続的に監視・検知し、インシデント発生時に適切に対応できる体制を整えておくことが重要です。

脆弱性を把握・改善する

Webサービスの技術的なリスクを確認するには、「Webアプリケーション脆弱性診断」があります。自動ツールとエンジニアによる手動診断を組み合わせ、認証やアクセス制御を含むWebアプリケーションの脆弱性を確認し、改善につなげます。

継続的に監視・検知する

脆弱性対策を行っても、サイバー攻撃を完全に防ぐことはできません。「G-MDR®」では、各種セキュリティ対策を統合的に監視・相関分析し、専門エンジニアが24時間365日体制で監視・運用します。脅威の検知から遮断・封じ込め、被害調査・対応支援まで、継続的なセキュリティ運用を支援します。

インシデントに備える

インシデント発生時に迅速に動くためには、平時から対応体制を整えておくことも重要です。「インシデント初動対応準備支援」では、既存の体制や文書を確認し、初動対応フローやガイドラインの策定を支援します。

ブロードバンドセキュリティ（BBSec）では、脆弱性の把握・改善から、継続的な監視・検知、インシデント発生への備えまで、企業のセキュリティ対策を支援しています。自社のシステムや運用体制に応じて必要な対策を検討したい場合は、お気軽にご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと

Share
ニチレイが個人情報漏洩を確認アイキャッチ画像

株式会社ニチレイは2026年9月18日、7月に発生したシステム障害に関する第7報で、サイバー攻撃を受けたサーバーの一部から個人情報の漏えいを確認したと発表しました。配送先や取引先の役職員、従業員・退職者とその家族、求職者などが対象です。7月24日には入出庫・冷凍食品出荷業務が全拠点で通常稼働へ移行していましたが、その後も調査は続き、8月の「漏えいのおそれ」の公表を経て、9月に漏えいが確認されました。本記事では、公式発表をもとに新たに判明した事実を整理し、業務復旧と漏えい調査を並行して進めるために企業が備えておきたいポイントを解説します。

※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

本件については、これまでの経緯もあわせて解説しています。あわせてぜひご覧ください。

漏えいが確認された対象と件数

第7報で示されたのは3区分です。ニチレイグループ各社が受託した配送業務の配送先のお客さまは3,308件で、情報の項目は氏名、住所、電話番号です。取引先の役職員は6,849件で、会社名、所属、役職、氏名、住所、電話番号、メールアドレスが挙げられています。グループ従業員と2021年以降の退職者、その家族、求職者の区分は43,709件です。氏名や連絡先、生年月日、従業員番号などに加え、給与賞与情報、在留資格、所属・異動等の人事情報が含まれています。ただし、1件ごとに公表された全項目が含まれるわけではありません。クレジットカード情報は含まれないとしています。

第7報で公表された3区分の件数を単純に合計すると53,866件です。ただし、これは本記事で各区分を加算した値であり、ニチレイが「漏えいした人数」として公表した数字ではありません。影響を確認する際は、合計値だけでなく、対象区分と漏えいが確認された情報の項目を分けて見る必要があります。

7月の業務復旧から9月の漏えい確認まで

7月13日の第1報では、不正アクセスによるシステム障害と、ニチレイロジグループ各社の冷蔵倉庫の入出庫業務、ニチレイフーズの冷凍食品出荷業務への影響が公表されました。第7報によると、同社は発生当日にシステムを遮断し、緊急対策本部を設置しています。7月24日の第5報では、受発注制限を解除して全拠点を通常稼働へ移行したと発表しました。

その後、8月14日の第6報で一部従業員情報の漏えいのおそれを公表し、9月18日の第7報で漏えいの確認と対象区分・件数を明らかにしました。第7報には9月11日に個人情報保護委員会へ報告したことも記載されています。業務の復旧日を、そのまま調査や対象者対応の完了日と捉えないことが、公表内容を理解する上での要点です。

第7報の時点でも原因分析と影響範囲の調査は続いています。確認した同社の発表には、具体的な侵入経路や悪用された脆弱性、ランサムウェアの使用を特定する説明はありません。攻撃の名称や原因を補って解釈せず、公表済みの事実と調査中の事項を分けて捉える必要があります。

図：ニチレイの漏えい情報と復旧後の調査

出典：株式会社ニチレイ「当社グループでのシステム障害発生について（第5報）」（2026年7月24日）、「当社グループでのシステム障害発生について（第7報）」（2026年9月18日）をもとに作成
※件数を人数と同一視しません。各記録にすべての情報項目が含まれるわけではありません。

対象者への案内と二次被害への注意

ニチレイは対象者へ順次個別に連絡しており、連絡先が分からないなど個別通知が難しい場合は公表をもって案内に代えるとしています。また、第7報の公表時点では、不正利用等の二次被害は確認されていません。この説明は9月18日時点の確認状況として読む必要があります。同社は、ニチレイや公的機関、金融機関を装った不審なメール、SMS、電話への注意も呼びかけています。不審な連絡に記載されたURLへのアクセス、個人情報の提供、添付ファイルの開封を避け、関連する不審な事象は公表資料に記載された窓口へ相談するよう案内しています。対象者は個別の通知内容と公式発表を確認し、自分に関わる情報の範囲を把握することが大切です。

業務復旧と調査を並行できる体制

ここからは、公表事実と公的な手引きを踏まえた企業一般への提案です。IPAの「中小企業のためのセキュリティインシデント対応の手引き」は、被害拡大を防ぐ初動、関係者への報告・公表、証拠保全と復旧・再発防止を整理しています。事業を早く再開する準備と、被害を正確に把握して説明する準備を、同じ対応計画に組み込むことが重要です。

物流や出荷を支えるシステムでは、停止した場合にどの業務へ影響が及ぶかを平時に整理しておくと、遮断や復旧の判断を具体化できます。IT部門だけでなく、現場責任者と経営層が、優先して再開する業務、代替手段、再接続を判断する責任者を共有しておくことを勧めます。サイバー攻撃では被害範囲がすぐに分からない場合もあるため、安全性を確認する工程を復旧計画に含めることが欠かせません。

証拠・ログを残す

漏えい調査に備えて、端末やサーバー、ネットワーク機器の記録をどの担当者が保全し、専門家に何を渡すかも決めておきます。IPAは、不用意な操作で記録を消さないことや、必要に応じたフォレンジック調査を挙げています。復旧作業の担当者と調査担当者が作業内容を共有し、記録の確保を確認した上で修復を進める手順にしておけば、後から事実を確かめるための手掛かりを残せます。

説明体制では、業務の稼働状況、漏えいが確認された情報、調査中の事項、対象者への連絡状況を分けて管理する方法が考えられます。問い合わせ窓口と公表担当者が同じ更新情報を参照できるようにし、追加の事実が判明した場合の確認・承認手順まで準備しておくと、復旧後も必要な説明を続けやすくなります。これは、IPAが示す状況に応じた継続的な報告・公表を、自社の運用に落とし込むための提案です。

個人情報の保管場所・権限を把握する

今回公表された対象には、配送先や取引先だけでなく、従業員、退職者、家族、求職者が含まれます。この範囲を自社点検の手掛かりにすると、顧客データベース以外に人事・採用関連のファイルや共有領域も確認対象となります。どの部署が何の目的で保有し、どのシステムに保存しているかを整理することが、影響範囲を調べる際の基礎になります。

あわせて、業務上必要な担当者だけが情報へアクセスできるか、異動や退職に伴う権限変更が反映されているかを点検します。個人情報保護委員会の通則ガイドラインも、担当者と取り扱うデータベースの範囲を限定するアクセス制御、アクセス者の識別・認証、不正アクセス対策などを示しています。給与や人事に関する情報を扱う部門も含め、保存場所と利用権限を確認することが実務上の出発点です。

IT-BCPとフォレンジックを平時から準備する

ニチレイは第7報で、グループ全体のセキュリティと監視体制の強化に加え、事業継続計画の見直しを進めるとしています。自社でも、通常の障害復旧手順に、攻撃の封じ込め、証拠保全、情報漏えい調査を組み合わせて対応できるかを確認しておきたいところです。

サイバー攻撃を想定した復旧計画の具体化には、ブロードバンドセキュリティ（BBSec）の「ランサムウェアに対応したIT-BCP策定支援」を活用できます。同サービスはランサムウェアを含むサイバー攻撃を対象に、企業の状況やニーズに応じたIT-BCPの策定・見直しを支援します。現行計画の対象や復旧判断の手順を整理する際の相談先として、ご検討ください。

情報漏えいの疑いが生じた際には、業務復旧を進めながら、調査に必要な証拠を適切に保全し、被害状況を確認する必要があります。BBSecの「デジタルフォレンジック」では、事象の把握や証拠保全・データ収集、原因や影響範囲の調査をご支援します。平時から調査支援を依頼する手順まで整えることで、業務復旧と事実確認を進める体制を具体化できます。平時のご相談はSQAT.jpよりお問い合わせください。

インシデントレスポンス／フォレンジック

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

ニチレイへのサイバー攻撃で何が起きた？ RansomHouseの主張と情報漏えいの可能性・供給網への影響

Share
「ニチレイへのサイバー攻撃で何が起きた？RansomHouseの主張と情報漏えいの可能性・供給網への影響」アイキャッチ画像

2026年7月13日、ニチレイは不正アクセスによるシステム障害を公表しました。影響は冷蔵倉庫の入出庫や冷凍食品の出荷に及び、7月24日に全拠点が通常稼働へ移行しました。その後、RansomHouseを名乗るグループによる犯行声明や、20万件以上のファイル公開が報じられています。本記事では、その後に明らかになった情報を踏まえ、公式発表で確認できる事実と攻撃者側の主張、第三者の観測を分けて整理し、食品・物流サプライチェーンへの影響と企業に求められる備えを解説します。

ニチレイが公式に確認したのは、サーバーへのサイバー攻撃、システム障害に伴う入出庫・出荷業務への影響、被害サーバーの一部に個人情報が保管されていたことです。一方、RansomHouseの関与、ランサムウェアによる暗号化、公開ファイルの真正性、情報漏えいの対象人数と範囲、侵入経路は、2026年8月13日時点で公式に確定していません。

→【続報】2026年9月18日、ニチレイは第7報で個人情報の漏えいを確認し、対象区分と件数を公表しました。最新の公表内容はこちらの記事で解説しています。
「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

※本記事は2026年8月13日時点で確認できる公表資料に基づき作成しています。RansomHouseの主張と20万件報道は、公式発表と混同しないよう補足情報として区分しています。

7月31日時点の公式発表に基づく経緯や、業務再開までの対応、BCPの観点はこちらの記事で解説しています。
前回記事（速報版）　：「ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP」

ニチレイへのサイバー攻撃で何が起きたのか

今回のニチレイへのサイバー攻撃は、情報システムだけの障害ではありませんでした。冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、モノの流れそのものに影響が及んだ点が特徴です。食品物流は、保管温度や納品時間が厳しく管理される業務です。受発注や在庫、倉庫作業を支えるシステムが使えなくなれば、倉庫に商品があっても通常どおりに動かせない状況が起こり得ます。

ニチレイは障害発生当日に緊急対策本部を設置し、個人情報や顧客データの保護を優先してグループ内システムを遮断しました。遮断は被害拡大を防ぐために重要な措置ですが、その判断によって業務への影響が表面化することもあります。サイバーインシデントでは、「止めないこと」と「安全を確認できない状態で動かさないこと」の間で、経営判断が求められます。

ニチレイのサイバー攻撃を時系列で整理

7月13日～24日：サイバー攻撃の確認から通常稼働への移行

ニチレイは7月13日、不正アクセスによるシステム障害が発生したと発表しました。7月15日には自社サーバーへのサイバー攻撃を確認し、被害サーバーの一部に個人情報が保管されていたことから、個人情報保護委員会へ漏えいの可能性がある事案として速報しています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には受発注制限を解除。影響を受けた全拠点が平常時の通常稼働へ移行しました。

※発生から業務再開までの詳しい経緯は、前回の速報版で解説しています。

8月7日：業績への影響を公表

8月7日の2026年12月期第1四半期決算説明資料（決算期変更に伴う変則決算）で、ニチレイはシステム障害による売上面のマイナス影響を最大50億円、営業利益への影響を8億円と見込み、緊急対応で発生したコストや今後見込まれる損失として特別損失10億円を織り込みました。金額の意味が異なるため、これらを単純に合算して「被害総額」とみなすことはできません。

8月10日：「20万件以上」のファイル公開が報じられる

8月10日、テレビ朝日ANNニュースはS&Jの観測として、RansomHouseを名乗るグループが少なくとも20万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*3。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、8月13日時点で、ニチレイの公式サイトには第5報以降、漏えい範囲や対象人数を確定する追加発表は掲載されていません。

ニチレイから個人情報は漏えいしたのか

結論からいえば、ニチレイは「個人情報の漏えいの可能性」を公表していますが、実際に社外へ流出した情報の項目や対象人数、件数は明らかにしていません。公式に確認できるのは、被害サーバーの一部に個人情報が保管されていたこと、個人情報保護委員会へ報告したこと、対象者へ通知したことまでです。この対象者への通知が行われたこと自体も、個人情報の社外流出が確定したことを意味するものではありません。

個人情報保護法では、不正アクセスなどによる個人データの漏えいが発生した場合だけでなく、発生したおそれがある場合にも、一定の要件のもとで個人情報保護委員会への報告と本人通知が必要になります*2。したがって、「個人情報保護委員会へ報告した」という事実だけで、漏えいが確定したとは判断できません。調査が進むにつれて公表内容が更新されることもあるため、初報だけで結論づけず、続報を追う必要があります。

「20万件以上」は20万人分の個人情報ではない

報道で使われた「20万件以上」は、文書や画像、フォルダー内のデータなどを含むファイル数です。1人に複数のファイルがひもづく場合もあれば、個人情報を含まない業務資料が数えられている可能性もあります。反対に、1つのファイルに複数人の情報が含まれる可能性もあります。そのため、ファイル数から被害人数を換算することはできません。さらに、公開されたとされるファイルのすべてがニチレイから窃取された真正なデータなのか、S&Jがどの範囲を確認したのかについて、ニチレイによる公式な検証結果は出ていません。

RansomHouseとは？ニチレイへの犯行は確認されたのか

RansomHouseは、被害組織からデータを窃取し、公開をちらつかせて金銭を要求する恐喝活動で知られるグループです。パロアルトネットワークスのUnit 42は、RansomHouseをRansomware as a Service（RaaS）として分析し、データ窃取と暗号化を組み合わせる二重脅迫、ESXi環境を狙う管理ツール「MrAgent」と暗号化ツール「Mario」の利用を報告しています*3。

ただし、これはRansomHouse一般の活動に関する技術分析です。ニチレイの環境でMrAgentやMarioが使われたこと、サーバーやファイルが暗号化されたことを示すものではありません。RansomHouseを名乗るグループは犯行を主張していますが、ニチレイは攻撃主体を公式に特定しておらず、侵入経路や攻撃手法も公表していません。

サイバー攻撃は食品・物流サプライチェーンへどう波及したか

ニチレイの事例で見落とせないのは、被害が自社のサーバー内にとどまらず、商品の保管と配送を待つ取引先や、その先の店舗運営へ波及し得ることです。食品物流は、多数の荷主、倉庫、輸配送会社、小売・外食企業をつなぐ共通基盤です。中核となる事業者の機能が止まれば、取引先自身のシステムが侵害されていなくても、商品を受け取れないという形で事業が止まります。

同時期、日本ケンタッキー・フライド・チキン株式会社（以降KFC）も、食材配送を委託する物流会社で発生した不正アクセス起因のシステム障害により、商品の一部品切れ、販売メニューの制限、営業時間の短縮などが生じたと公表しました*4。7月22日には全店舗への食材納品体制が整い、通常営業へ戻っています。KFCは物流委託先の社名を公表していないため、ニチレイの事案との関係を公式情報だけで断定することはできません。一方、この事例は、物流委託先のシステム障害が消費者向けサービスにまで波及し得る構造を示しています。

「サプライチェーン攻撃」と「サプライチェーンへの影響」は別物

ここで用語を分けて考える必要があります。サプライチェーン攻撃は一般に、取引先や委託先、利用するソフトウェアやサービスを足がかりとして標的へ侵入する攻撃を指します。今回、ニチレイへの侵入経路は公表されていないため、攻撃経路という意味でサプライチェーン攻撃だったとは断定できません。

一方で、サイバー攻撃による業務停止が供給網の先へ広がる「サプライチェーンリスク」は明確に表面化しました。侵入経路の問題と、事業依存関係による影響の連鎖は別の論点です。この二つを混同しないことが、ニュースを正確に読み、自社の対策へ落とし込む第一歩になります。

ニチレイが公表した業績への影響

ニチレイの2026年12月期第1四半期決算説明資料では、事業停止に伴う売上面のマイナス影響を最大50億円と見込んでいます。内訳は食品事業が20億円、低温物流事業が30億円です。営業利益への影響は8億円で、食品事業2億円、低温物流事業4億円、持株会社のシステム対応費用2億円とされています。さらに、緊急対応で発生したコストと今後発生が見込まれる損失として、10億円の特別損失を織り込みました。

※ニチレイが公表した売上への影響、営業利益への影響、特別損失は、それぞれ意味の異なる数字です。これらを単純に合算して「サイバー攻撃による被害総額」とみなすことはできません。

親会社株主に帰属する当期純利益の予想は252億円から204億円へ48億円下方修正されましたが、この48億円すべてがサイバー攻撃による損失ではありません。中東情勢によるコスト増や食品・物流事業の進捗など、複数の要因が含まれています。なお、連結売上高の通期予想自体は海外事業の伸長を反映して上方修正されています。

企業が学ぶべきサイバー攻撃対策

重要業務と外部依存を、システム単位ではなく事業単位で洗い出す

まず必要なのは、どのシステムが止まると、どの業務、取引先、商品、売上に影響するのかを平時に把握することです。自社システムの一覧だけでは足りません。物流、決済、クラウド、保守会社、受発注先など、重要業務を支える外部依存まで含め、許容停止時間と代替手段を整理します。委託先が止まった場合の連絡順序、手作業へ切り替えられる範囲、代替事業者の有無も、BCPとインシデント対応計画の両方で確認しておく必要があります。

また、インシデント対応訓練では自社がサイバー攻撃を受けるケースだけでなく、物流会社やクラウドサービス、主要な仕入先など、重要な委託先・取引先のシステムが停止するケースも想定することが重要です。自社システムが正常でも外部サービスが利用できない状況で、どこまで業務を継続できるのかを確認しておく必要があります。

「業務復旧」と「情報漏えい対応」を別の時計で管理する

ニチレイは7月24日に通常稼働へ移行しましたが、その後もダークウェブ上でのデータ公開が報じられました。ここから分かるのは、システム復旧の完了と、情報漏えい調査の完了は一致しないということです。前者は業務を安全に再開できるかという可用性の問題、後者は何が持ち出され、誰にどのような影響があるかという機密性と法令対応の問題です。復旧宣言後も、フォレンジック調査、漏えい範囲の特定、本人通知、二次被害の監視、対外説明を継続できる体制が欠かせません。

遮断・復旧・証拠保全を同時に進められる初動体制をつくる

攻撃を疑った場合は、インシデント対応責任者や専門家の判断のもと、必要に応じて感染が疑われる端末やサーバーをネットワークから隔離し、被害拡大を抑える必要があります。一方、電源断や安易な初期化によって調査に必要な証拠を失うおそれもあります。誰が遮断を判断し、どのログを保存し、外部の専門会社や警察、監督機関へいつ連絡するのかを事前に決め、机上訓練で確かめておくことが重要です。

経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」でも、インシデント発生に備えた体制構築とサプライチェーン全体での対策を経営課題として位置づけています。

バックアップは取得だけでなく、隔離と復旧テストまで行う

ランサムウェアを含む破壊的な攻撃に備えるには、バックアップを本番環境と同じ認証基盤やネットワークに置き続けないことが重要です。実際に戻せるかを定期的に試し、復旧に必要な時間が事業側の許容範囲に収まるかまで確認して、初めてBCPとして機能します。

よくある質問

▼ ニチレイへの攻撃はランサムウェアだったのですか？
▼ 20万件とは20万人分の個人情報ですか？
▼ 個人情報の漏えいは確定していますか？
▼ ニチレイのシステムと業務は復旧していますか？
▼ 今回の事案はサプライチェーン攻撃ですか？

まとめ―復旧の速さだけでは測れないサイバー攻撃の損失

ニチレイへのサイバー攻撃は、冷蔵倉庫と冷凍食品出荷の停止、取引先への影響、個人情報漏えいの可能性、財務損失という複数の問題を同時に突きつけました。全拠点が通常稼働へ戻った後にデータ公開が報じられた経緯は、事業継続と情報保護を別々に備える必要性を示しています。

企業が見るべきなのは、自社への侵入を防げるかだけではありません。重要な委託先が止まったときに業務を続けられるか、攻撃を検知した直後に安全に遮断できるか、バックアップから所定時間内に戻せるか、漏えい調査と対外説明を長期にわたって続けられるかまでが、現在のサイバー攻撃対策です。平時のうちに外部専門会社との連絡経路や調査体制を整え、実際のシナリオで検証しておくことが、被害の大きさを左右します。漏えい調査と対外説明を長期にわたって続けられるかまでを想定することが、現在のサイバーリスク対策には求められます。

参考情報

公開日：2026年8月13日
更新日：2026年10月6日

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

    Share
    ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

    2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    【続報】2026年9月18日、ニチレイは個人情報の漏えいを確認したと発表しました。最新の公表内容はこちらの記事で解説しています。
    「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

    ニチレイへのサイバー攻撃とは

    2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*5。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

    この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

    7月13日から24日まで―公式発表で追う対応と復旧

    7月13日：不正アクセスによるシステム障害を公表

    ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

    ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

    7月15日：サイバー攻撃を確認、個人情報漏えいの可能性を報告

    7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

    同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

    7月17日：受発注を制限しながら部分稼働

    7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

    7月22日から24日：対象者への通知と通常稼働への移行

    7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

    7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

    なぜ食品サプライチェーンへの影響が注目されたのか

    ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90％を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

    実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

    なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

    個人情報は漏えいしたのか

    2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

    個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それがある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

    対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

    ※その後、9月18日の第7報で個人情報の漏えいが確認されました。最新情報はこちら。

    ランサムウェア攻撃だったのか

    ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

    攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

    ニチレイの事例から企業が見直すべきサイバー攻撃対策

    重要業務とシステムの依存関係を可視化する

    対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析（BIA）を用いて復旧の優先順位を整理し、目標復旧時間（RTO）や目標復旧時点（RPO）に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

    多層防御によって被害範囲を限定する

    ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

    サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

    「システムを止めた状態」で続ける手順を用意する

    不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

    だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

    復旧可能なバックアップと復旧手順を検証する

    バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

    さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

    サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

    初動対応をIT部門だけに背負わせない

    インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

    平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

    取引先を含めて復旧情報を共有する

    自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

    公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

    よくある質問

    ▼ ニチレイのシステム障害はいつ発生しましたか
    ▼ どの業務に影響が出ましたか
    ▼ 個人情報は漏えいしましたか
    ▼ ランサムウェア攻撃だったのでしょうか

    まとめ―サイバー攻撃対策は業務復旧まで設計する

    ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

    今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

    【参考情報】

    公開日：2026年8月5日
    更新日：2026年10月6日

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る