最初に結論から置く。今回のニチレイの事案で経営者が見るべき数字は、「何万件の個人情報が対象になったか」ではない。不正アクセスの公表(7月13日)から店頭の供給が戻る(日本KFCは7月22日に全店で通常営業を再開)まで、およそ9日で収束に向かったという事実のほうだ。被害に遭うかどうかは、正直なところ運の要素が大きい。だが、被害に遭ったあと何日で事業を戻せるかは、事前のバックアップ投資と復旧設計という「経営判断の結果」で決まる。ここが、同じ攻撃を受けても復旧できる会社とできない会社を分ける。
事実関係を公式ベースで整理する。ニチレイグループは2026年7月22日に「当社グループでのシステム障害発生について（第4報）」を公表し、システム障害の影響を受けていた入出庫業務および冷凍食品出荷業務について「今週中に全拠点が通常稼働に移行する予定」であること、そして「被害を受けたサーバの一部に個人情報が保管されていたため、対象者の方へ別途通知を行っています」と明らかにした(いずれもニチレイ公式リリース第4報の原文)。同社は「警察および関係機関と連携し、対応を進めていますので、サイバー攻撃の詳細は、情報開示を差し控えさせていただきます」とし、攻撃・被害の詳細と、どのような手段で復旧したかについては非開示の方針を明確にしている。復旧手段(バックアップからの復元か否か)について、公式リリースは言及していない。この点は、後述するとおり断定を避けて読む必要がある。
一方で、需要側の店頭は動き出した。日本ケンタッキー・フライド・チキンは同7月22日、委託先であるニチレイのグループ会社のシステム障害の影響で続いていたメニュー制限・時短などを解消し、全店舗で通常営業を再開したと発表した(Bloomberg、ITmedia NEWS、朝日新聞などが報道)。ニチレイが不正アクセスを公表した7月13日から数えて9日での通常営業復帰である。攻撃されたのは1グループでも、止まっていたのは取引網の先の無数の店だった——という構造は7月18日の別稿で扱った。本稿はその裏側、「なぜ9日で戻せたのか」「自社なら何日で戻せるのか」という復旧能力の側から、バックアップ投資の判断軸を組み立てる。
誰のための記事か
この記事は、セキュリティ製品の比較記事ではない。次のような立場の読者に向けている。
- 年商1〜100億円規模で、情シスが0〜1名、あるいは兼任情シスしかいない中堅企業の経営者・事業責任者
- 「バックアップは取っている」と報告を受けているが、それがランサムウェアに耐える設計になっているかを自分の言葉で確認できていない経営者
- ニュースを見て「うちが同じ目に遭ったら何日で戻れるのか」を一度も見積もったことがない意思決定者
- 個人情報を保管しているサーバがどこに何台あるか、棚卸しの台帳を持っていない管理部門の責任者
これらのどれかに心当たりがあるなら、この記事は「自社の問題」として読める。逆に、復元テストを毎四半期回していて、RTO(目標復旧時間)を業務ごとに定義済みで、個人情報保管サーバの一覧が更新されている会社は、すでに合格ラインにいる。確認のために読み進めてほしい。
INSTANT ESTIMATE
計算式より、60秒で概算を出しませんか？
システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。
公表の時系列(公式リリースベース)
まず、断定を避けるために公式で確認できる範囲を時系列で押さえる。報道各社の解説記事は日付や表現に幅があるため、下表は「公式リリースおよび複数報道で一致している事実」に絞った。攻撃手法・被害範囲の詳細はニチレイが非開示としているため、本表には含めない。
横にスクロールして確認できます
| 日付 | 公表・事象 | 出典区分 |
|---|---|---|
| 2026年7月13日 | システム障害/不正アクセスを公表 | 公式・報道一致 |
| 2026年7月15日 | サイバー攻撃を受けたことを確認したと公表 | 公式・報道一致 |
| 2026年7月17日 | 冷蔵倉庫の入出庫・冷凍食品出荷を一部制限つきで順次再開 | 公式 |
| 2026年7月22日 | 第4報公表:今週中に全拠点が通常稼働へ移行予定/被害サーバの一部に個人情報が保管され対象者へ個別通知 | 公式(第4報) |
| 2026年7月22日 | 日本KFCが全店舗で通常営業を再開 | 報道(Bloomberg/ITmedia/朝日) |
この時系列で経営者が読み取るべきは、「7月17日に順次再開が始まり、22日には全拠点通常稼働の見通しが立った」というスピード感である。ランサムウェアで基幹システムが暗号化された場合、復旧の速さは「使えるバックアップが手元に残っていたか」「そこから業務優先度の高い順に戻す手順が用意されていたか」に強く依存する。
なお、一部報道では復旧がバックアップから進んだ趣旨の解説も見られるが、ニチレイ自身は復旧手段を開示していない。したがって本稿では「ニチレイがバックアップで復旧した」とは断定しない。ここで重要なのは、ニチレイの内部事情を推測することではなく、「自社が同じ状況に置かれたとき、9日で戻せるだけのバックアップ投資と復旧設計を、いま持っているか」を各社が自問することだ。以降はその判断軸を提示する。
なぜ「バックアップを取っている」だけでは足りないのか
多くの中堅企業では、経営者が「バックアップは取っている」と報告を受けている。しかしランサムウェアの文脈では、その報告は三つの点で不十分なことが多い。
第一に、バックアップが本番と同じネットワーク上に置かれている場合。攻撃者は侵入後、暗号化の前にまずバックアップの探索と破壊を狙う。オンラインでつながっているバックアップは、本番と一緒に暗号化・削除される。「取っている」バックアップが攻撃時に生きているとは限らない。
第二に、復元(リストア)を試したことがない場合。バックアップは「取ること」ではなく「戻せること」がゴールだ。取得は自動化されていても、実際に別環境へ復元して業務が動くかを検証していない会社は非常に多い。いざ攻撃されて初めて、バックアップが壊れていた・世代が古すぎた・復元手順が誰も分からない、という事態に直面する。
第三に、戻す順番が決まっていない場合。全システムを同時に復旧できるわけではない。受発注・出荷・会計・在庫のうち、どれを何時間以内に戻すのか(=RTO)が業務ごとに定義されていないと、復旧作業は現場の混乱の中で場当たり的になり、結果として全体の復旧が遅れる。
ニチレイの事案が示したのは、供給を止めないためには「入出庫・出荷という中核業務を優先して戻す」という順序判断が効くということだ。順序は事前に決めておくものであり、被害の当日に考えるものではない。
復旧できる会社の条件(1)3-2-1ルールとオフライン/イミュータブル
バックアップ設計の土台は、古くから知られる3-2-1ルールである。すなわち、データは3つのコピーを持ち、2種類の異なる媒体に保存し、1つは物理的に離れた場所(オフサイト)に置くという原則だ。これは公式機関(米CISAなども繰り返し推奨)でも標準とされる考え方だが、ランサムウェア時代には「離れた場所」だけでは足りず、「攻撃者の手が届かない状態」であることが要件になる。
そこで加わるのが、オフラインバックアップとイミュータブル(改変不可)バックアップという二つの概念だ。
- オフラインバックアップ:ネットワークから切り離して保管する。テープや、取得後に接続を切る外部媒体などが該当する。物理的に切れていれば、遠隔からの暗号化・削除は届かない。
- イミュータブルバックアップ:一定期間、上書き・削除ができない状態でデータを固定する方式。オブジェクトストレージのオブジェクトロックや、WORM(Write Once Read Many)特性を使い、管理者権限を奪われても保持期間内は改変できないようにする。
この二つのどちらか(理想は両方)が入っていて初めて、「攻撃者にバックアップごと消される」リスクを外せる。経営者が確認すべきは、「うちのバックアップは、本番を管理している同じ管理者アカウントで消せるのか、消せないのか」という一点だ。消せてしまうなら、それはランサムウェア対策としては不十分である。バックアップ管理の権限を本番系の管理者から分離しているか、も併せて確認したい。
復旧できる会社の条件(2)RTO/RPOの決め方
復旧設計を語るうえで欠かせないのが、RTO(目標復旧時間)とRPO(目標復旧時点)である。用語だけ聞くと専門的だが、経営判断としてはシンプルな二つの問いに落ちる。
- RTO=止まってから、何時間・何日以内に戻さなければ事業に致命傷か
- RPO=最悪、何時間前・何日前の状態まで戻ってしまうことを許容できるか
RTOの決め方は、システムから考えないのがコツだ。まず業務から考える。「受注が3日止まったら顧客をどれだけ失うか」「出荷が1日止まったら取引先にどんな違約が発生するか」を業務単位で見積もり、耐えられない時間を洗い出す。そのうえで、その業務を支えるシステムのRTOを逆算する。全システムを一律「24時間以内」などと決めるのではなく、中核業務は短く、周辺業務は長く、とメリハリをつける。これがそのまま、被害時に「どれから戻すか」の優先順位表になる。
RPOは、バックアップの取得間隔を決める。1日1回の取得なら、最悪24時間分のデータが失われうる。受発注のように1件の欠落が事故につながる業務では、取得間隔を短くするか、別のログから再構成できる設計にする必要がある。RTO/RPOを詰めると、「どこにいくらのバックアップ投資が必要か」が数字で見えてくる。逆にここを決めずにバックアップ製品だけ買うと、要件に対して過剰にも過少にもなりやすい。
下表は、RTO/RPOを業務ごとに整理するための最小テンプレートだ。自社の主要業務を3〜5個並べ、埋めるところから始めてほしい。
横にスクロールして確認できます
| 業務 | 止まると起きる損害 | 許容停止時間(RTO) | 許容データ損失(RPO) | 優先順位 |
|---|---|---|---|---|
| 受発注 | (例)取引先への納品遅延・違約 | (例)4時間 | (例)15分 | 高 |
| 出荷・在庫 | (例)店頭欠品・機会損失 | (例)8時間 | (例)1時間 | 高 |
| 会計・請求 | (例)締め遅延 | (例)3日 | (例)1日 | 中 |
| 社内情報共有 | (例)生産性低下 | (例)5日 | (例)1日 | 低 |
復旧できる会社の条件(3)個人情報保管サーバの棚卸し
第4報のもう一つの要点は、「被害を受けたサーバの一部に個人情報が保管されていた」という事実だ。これは、多くの中堅企業に共通する弱点を照らし出している。どのサーバに、どんな個人情報が、何件保管されているかを正確に把握できている会社は少ない。棚卸しの台帳がなければ、被害時に「誰に通知すべきか」「何が漏えいの可能性があるか」を即座に判断できず、初動が遅れる。
平時にやっておくべき棚卸しは次の粒度だ。個人情報を扱うシステム・共有フォルダ・古い業務サーバまで含めて、以下を一覧化する。
- 保管しているデータの種類(氏名・住所・連絡先・取引履歴・従業員情報・応募者情報など)
- おおよその件数と保管場所(物理サーバ/クラウド/端末ローカル)
- 暗号化の有無、アクセス権限の範囲
- バックアップの有無と、その保管方式(オンライン/オフライン/イミュータブル)
- 廃止予定・すでに使っていないのに残っているデータ(=不要な保管はリスクなので削減対象)
この棚卸しは、セキュリティのためだけでなく、被害時の本人通知と当局対応のスピードを直接左右する。「どこに何があるか」が分かっている会社は、通知対象の特定が速い。分かっていない会社は、事故のあとにサーバを一台ずつ調べることになる。
本人通知と個人情報保護委員会への報告の実務
第4報でニチレイは「対象者の方へ別途通知を行っています」と明記した。個人情報の漏えい等が発生した(またはそのおそれがある)場合、個人情報保護法は事業者に対し、原則として本人への通知と、個人情報保護委員会への報告を求めている。ここは法令に基づく一般的な枠組みとして、自社が同じ立場になったときの手順を押さえておきたい。
なお、ニチレイの第4報の本文中には「個人情報保護委員会」への報告の記載はなく、本人への個別通知が行われている旨のみが確認できる。当局報告の有無は公式で要確認としておき、ここでは制度の一般論として整理する。
- 本人への通知:漏えい等の事態を知った本人が、必要な対応(パスワード変更、フィッシング警戒など)を取れるよう、対象者へ知らせる。通知が困難な場合は、公表など本人が知りうる代替措置をとる。
- 個人情報保護委員会への報告:一定の類型(要配慮個人情報、財産的被害のおそれ、不正目的、1,000人超など)に該当する漏えい等では、速報(概ね3〜5日以内が目安)と、後日の確報が求められる。
- 記録と再発防止:何が、いつ、どの範囲で起きたか、どう対応したかを記録し、再発防止策を整理する。
重要なのは、これらの手順は「事故が起きてから調べるには重すぎる」という点だ。平時に、誰が判断し、誰が通知文を出し、どの窓口に連絡するかの体制(=インシデント対応の役割分担)を決めておく必要がある。この体制設計は、インシデント対応支援のような外部の伴走を使ってでも、被害前に整えておく価値がある。
発注前・棚卸しチェックリスト(復旧できる会社になるための10項目)
自社が「9日で戻せる側」にいるかを、次の10項目でセルフチェックしてほしい。半分以上「いいえ/分からない」なら、投資判断の見直しが必要だ。
- バックアップの少なくとも1つは、本番と切り離された(オフラインまたはイミュータブルな)状態で保管されているか。
- そのバックアップは、本番系の管理者権限だけでは削除・改変できないようになっているか。
- 実際に別環境へ復元し、業務が動くことを直近で検証したか(いつやったか言えるか)。
- 主要業務ごとにRTO(許容停止時間)を定義しているか。
- 主要業務ごとにRPO(許容データ損失)を定義し、取得間隔がそれに合っているか。
- 被害時に「どのシステムから戻すか」の優先順位表があるか。
- 個人情報を保管しているサーバ・フォルダの一覧(台帳)が最新化されているか。
- 不要になった個人情報を放置していないか(削減できるものは減らしているか)。
- 本人通知・当局報告の判断者と手順、通知文の雛形が決まっているか。
- 攻撃の詳細が分からない段階でも動ける、外部の連絡先(セキュリティ専門会社・弁護士など)を平時から確保しているか。
ベンダー・情シスへの質問テンプレート
バックアップと復旧の状態を、専門用語なしに確認するための質問だ。答えに詰まる項目が、そのまま投資の穴になる。
- 「いまのバックアップは、ランサムウェアに感染したとき一緒に暗号化されない場所にありますか。それはなぜですか」
- 「最後に本番から復元テストをしたのはいつですか。そのとき何時間で戻りましたか」
- 「うちの受発注(または出荷)は、最悪何時間で復旧できる設計になっていますか」
- 「個人情報が入っているサーバは何台で、それぞれバックアップと暗号化はどうなっていますか」
- 「バックアップを消せる管理者は誰ですか。その権限は本番の管理者と分かれていますか」
- 「もし今日攻撃されたら、最初の72時間で誰が何をする手順になっていますか」
これらに即答できないなら、それは担当者個人の問題ではなく、設計と投資が未整備というサインだ。第三者の目で棚卸しをしたい場合は、セキュリティ診断・支援の全体像から入り、継続的に手当てするならセキュリティ顧問(リテイナー)のような形で外部の判断力を常設する選択肢がある。
FAQ
Q1. ニチレイはバックアップから復旧したのですか。 公式には復旧手段を開示していません。同社は攻撃・被害の詳細を非開示としており、「バックアップで復旧した」と断定できる一次情報はありません。本稿はニチレイの手段を推測するものではなく、「自社なら何日で戻せるか」を考える契機として事案を扱っています。
Q2. 3-2-1ルールを守っていればランサムウェアは大丈夫ですか。 3-2-1は土台ですが、それだけでは不十分です。オフラインまたはイミュータブルな保管(攻撃者が消せない状態)と、定期的な復元テスト、戻す順番の設計が加わって初めて「復旧できる」状態になります。
Q3. RTOはどう決めればよいですか。 システムからではなく業務から決めます。「その業務が止まると何時間で致命傷か」を業務ごとに見積もり、それを支えるシステムのRTOを逆算します。中核業務は短く、周辺は長く、とメリハリをつけるのがコツです。
Q4. 個人情報の棚卸しは何から始めればよいですか。 「どのサーバ・フォルダに、どんな個人情報が、おおよそ何件あるか」の一覧化からです。暗号化・アクセス権限・バックアップ方式まで書き足し、不要な保管は削減します。これが被害時の通知対象特定の速さに直結します。
Q5. 漏えいの可能性がある場合、必ず当局に報告が必要ですか。 個人情報保護法は一定の類型で個人情報保護委員会への速報・確報と本人への通知を求めています。該当性の判断は事案によるため、平時に判断者と手順、通知文の雛形を用意しておくことが重要です。
Q6. うちは小さいから狙われないのでは。 規模の大小ではなく、侵入できる穴があるかどうかで狙われます。むしろ復旧体制が薄い中堅・中小のほうが、止まったときのダメージは大きくなりがちです。
Q7. 何から手をつければ費用対効果が高いですか。 まず「バックアップが攻撃時に生き残るか」と「復元テストの実施」です。これらは比較的低コストで、復旧可否を大きく左右します。そのうえでRTO/RPOを定義し、投資の優先順位をつけます。
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、被害が起きる前に一度整理する価値がある。
- バックアップは取っているが、それがランサムウェアに耐える設計かを自社で判断できない
- RTO/RPOという言葉で業務の復旧目標を定義したことがない
- 個人情報保管サーバの台帳がなく、被害時の通知対象を即座に出せる自信がない
- ベンダーの「バックアップは大丈夫です」を鵜呑みにするしかなく、第三者の目で確かめたい
GXOは特定の製品を売るためではなく、「自社がいま何日で戻せる状態か」を可視化し、投資の優先順位を一緒に決める立場で関わる。まずは現状の棚卸しから相談したい場合はお問い合わせから、体制ごと継続的に手当てしたい場合はセキュリティ顧問(リテイナー)を入口に検討してほしい。被害を防ぐ確率は完全には上げられないが、被害後に戻れる速さは、いまの判断で確実に変えられる。
参考文献
- 株式会社ニチレイ「当社グループでのシステム障害発生について（第4報）」2026年7月22日 https://www.nichirei.co.jp/news/2026/515.html
- Bloomberg「日本KFC、22日から全店舗で通常営業を再開－ニチレイのシステム障害で制限」2026年7月21日 https://www.bloomberg.com/jp/news/articles/2026-07-21/TIJQGVT96OSH00
- ITmedia NEWS「KFC、全店舗で通常営業を再開 ニチレイへの不正アクセスから9日で 『詫びクーポン』も配布」2026年7月22日 https://www.itmedia.co.jp/news/articles/2607/22/news069.html
- 朝日新聞「ケンタッキー、全店で通常営業を再開 ニチレイに委託の配送回復で」2026年7月22日 https://topics.smt.docomo.ne.jp/article/asahi/business/ASV7P7XHQV7PULFA002M
- 個人情報保護委員会 個人情報の保護に関する法律(漏えい等の報告・本人通知に関する規定) https://www.ppc.go.jp/personalinfo/legal/
