はじめに
「うちはEDRも入れている。MFAも導入した。バックアップもある。だから、ある程度は大丈夫だろう」
そう思っていても、取引先が止まれば、自社の商売まで止まります。
2026年7月13日、ニチレイで第三者による不正アクセスに起因するシステム障害が発生しました。
影響を受けたのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。翌7月14日には、日本ケンタッキー・フライド・チキンが、物流委託先のシステム障害によってKFC全店舗への食材納品に影響が出る可能性を公表しました。12
商品の品切れ、販売メニューの制限、営業時間の短縮、臨時休業。
さらに、公式アプリやWebサイトからのオンライン注文、モバイルオーダー、デリバリー、配達代行サービスまで一時停止しています。1
重要なのは、KFC自身がサイバー攻撃を受けたわけではないという点です。
それでも、顧客から見れば「ケンタッキーで注文できない」「欲しい商品が買えない」という事業停止です。
本稿では、今回の事案で何が起きたのかを整理したうえで、サプライチェーンやサードパーティへの依存から生じるサイバーリスクと、企業が実務上どこまで備えるべきかを考えます。
なお、2026年7月14日時点の公表資料では、侵入経路、具体的な攻撃手法、ランサムウェアの関与は明らかになっていません。また、ニチレイは個人情報や顧客データの社外流出について「確認されていない」としており、調査を継続しています。したがって、本稿では未確認の攻撃手法や被害を推測で断定しません。2
1. 何が起きたのか──物流システムの停止がKFC全店舗へ波及した
まず、公表されている事実を時系列で整理します。
| 日時 | 発生したこと | 公表された影響 |
|---|---|---|
| 2026年7月13日 | ニチレイで第三者による 不正アクセスに起因する システム障害が発生 |
冷蔵倉庫の入出庫業務、 冷凍食品の出荷業務に影響 |
| 2026年7月14日 | KFCが物流委託先の システム障害を公表 |
KFC全店舗への食材納品に影響 |
| 2026年7月14日納品分 | 発注通りの納品が困難 | 一部商品の配送を調整 |
| 2026年7月15日以降 | 委託先の復旧状況を 踏まえて判断 |
公表時点では復旧見込み未定 |
ニチレイの公式発表によると、影響を受けた業務は次の2つです。2
- ニチレイロジグループ各社の冷蔵倉庫における入出庫業務
- ニチレイフーズの冷凍食品出荷業務
KFC側は、影響対象を「KFC全店舗」としています。1
想定される店舗への影響は次の通りです。
- 商品の一部品切れ
- 販売メニューの制限
- 営業時間の短縮
- 食材在庫によっては臨時休業
- オンライン注文の一時停止
- モバイルオーダーの一時停止
- デリバリー、配達代行サービスの一時停止
流れを単純化すると、次のようになります。
第三者による不正アクセス
↓
ニチレイのシステム障害
↓
冷蔵倉庫の入出庫・冷凍食品出荷に支障
↓
KFC店舗への食材納品に影響
↓
店舗在庫が不安定になる
↓
品切れ・メニュー制限・営業時間短縮・臨時休業
↓
オンライン注文やデリバリーも一時停止
ここで興味深いのは、物理的な物流の停止が、デジタルチャネルの停止にまで波及していることです。
ただし、KFCのアプリやWebサイト自体がサイバー攻撃を受けたという発表はありません。
したがって、オンライン注文の停止は、店舗ごとの在庫状況が不安定な状態で注文だけを受け続けることを避けるための運用上の措置である可能性があります。これは公表内容からの推測であり、KFCが具体的な停止理由まで説明しているわけではありません。
しかし、この構造は重要です。
現代の事業では、
物流
↓
在庫
↓
店舗営業
↓
注文システム
↓
顧客体験
が連動しています。
つまり、サイバー攻撃はサーバーだけを止めるのではありません。
冷蔵庫から商品が出せなくなれば、最終的には店頭のレジも、スマートフォンの注文ボタンも意味を失います。
2. これは「KFCへのサプライチェーン攻撃」なのか
ここは、言葉を正確に分けた方がよいところです。
今回の事案を、
KFCがサプライチェーン攻撃を受けた
と断定するのは、現時点では適切ではありません。
一般にサプライチェーン攻撃とは、攻撃者が本来の標的を直接攻撃するのではなく、関連会社、委託先、ソフトウェアベンダーなど、サプライチェーン上の比較的弱い部分を侵害し、そこを足掛かりとして最終標的を攻撃する手法を指します。
一方、今回公表されている内容は次の通りです。
| 確認事項 | 現時点の状況 |
|---|---|
| ニチレイが不正アクセスを受けた | 確認済み |
| ニチレイの物流・出荷業務に影響した | 確認済み |
| KFCの食材納品に影響した | 確認済み |
| KFC自身のシステムに侵入された | 公表なし |
| 攻撃者がKFCを最終標的としていた | 公表なし |
| ニチレイを踏み台にKFCへ侵入した | 公表なし |
したがって、本稿では今回の事案を、
サードパーティへのサイバー攻撃によって、サプライチェーン上の事業継続リスクが顕在化した事例
と整理します。
細かい違いに見えるかもしれません。
しかし、セキュリティ対策を考えるうえでは非常に重要です。
「サプライチェーン攻撃」だけを想定すると、
委託先
↓
自社ネットワークへの侵入
を防ぐことに意識が集中します。
しかし今回考えるべきなのは、
委託先
↓
委託先自身が停止
↓
自社の事業も停止
というリスクです。
自社ネットワークに1台も侵入されていなくても、自社の売上は止まります。
IPAが公表した「情報セキュリティ10大脅威 2026」でも、「サプライチェーンや委託先を狙った攻撃」は組織向け脅威の第2位です。2023年以降、4年連続で第2位となっています。3
そして、IPAが進めるSCS評価制度でも、委託先へのサイバー攻撃によって生じるリスクとして、
- 自社事業・サービスの提供途絶
- 機密情報の漏えい
- 情報の改ざん
- 委託先を踏み台とした不正侵入
を挙げています。4
つまり、サプライチェーンのサイバーリスクは、「侵入されるか」だけではありません。
届かない、作れない、売れない、サービスを提供できない。
これもサイバーセキュリティの問題です。
3. 本当に見るべきなのは「その会社が安全か」ではなく「止まったら自社がどうなるか」
サードパーティ管理というと、よく次のようなチェックを行います。
- ISMSを取得しているか
- EDRを導入しているか
- MFAを導入しているか
- 脆弱性診断を実施しているか
- バックアップを取得しているか
- インシデント対応手順があるか
もちろん、これらは重要です。
しかし、これだけでは足りません。
なぜなら、どれほど対策していても、攻撃を100％防ぐことはできないからです。
本当に必要なのは、
その取引先が止まったとき、自社のどの業務が、何時間後に、どこまで止まるか
を把握することです。
本稿では、サードパーティリスクを考えるための簡易的な概念式として、次のように整理します。
第三者リスク
＝ 発生可能性
× 事業影響度
× 依存度
× 代替困難性
たとえば、非常に強固なセキュリティ対策を実施している大企業であっても、
- その会社が止まれば全国拠点が止まる
- 代替事業者へ切り替えるのに数か月かかる
- 手作業による代替手段がない
のであれば、事業上の重要リスクです。
逆に、多少セキュリティ成熟度が低くても、
- 委託業務が限定的
- 自社システムとの接続がない
- 機密情報を渡していない
- 翌日には別事業者へ切り替えられる
のであれば、相対的な事業影響は低くなります。
つまり、取引金額の大きさだけでサードパーティの重要度を決めてはいけません。
見るべき項目は、少なくとも次の5つです。
| 評価軸 | 確認する内容 |
|---|---|
| 事業影響 | 停止すると、どの業務やサービスが止まるか |
| データ | 個人情報、機密情報、認証情報を渡しているか |
| システム接続 | VPN、API、SaaS、ファイル転送などで接続しているか |
| 代替可能性 | 他社、他拠点、手作業に切り替えられるか |
| 復旧時間 | 何時間、何日まで停止を許容できるか |
IPAが公開しているサプライチェーン管理の実践例でも、委託先の棚卸し、企業規模などに応じた対策要求、問い合わせ窓口の設置、定期的な対策状況の確認などが示されています。5
ただし、ここでもう一歩踏み込む必要があります。
チェックシートで「対策済み」と回答してもらうことと、実際にその会社が止まったとき自社が生き残れることは、別の問題です。
4. サードパーティ停止から自社を守る6つの設計
では、何をすればよいのでしょうか。
本稿では、実務上必要な対策を6つに整理します。
4.1 まず「誰に依存しているか」を棚卸しする
最初に必要なのは、サードパーティ台帳です。
ただし、単なる取引先一覧では意味がありません。
最低限、次を紐付けます。
委託先
├─ 委託業務
├─ 対象サービス
├─ 利用データ
├─ システム接続
├─ 再委託先
├─ 停止時の事業影響
├─ 許容停止時間
├─ 代替手段
└─ 緊急連絡先
特に重要なのが、再委託です。
自社が契約しているA社が、実際の運用をB社へ委託し、さらにB社がC社のクラウドや物流拠点を利用していることは珍しくありません。
自社から見えないC社が止まって、自社サービスまで停止することがあります。
重要業務については、「契約相手を知っている」だけでなく、実際に誰が、どのシステムで、どの業務を動かしているかまで把握する必要があります。
4.2 セキュリティ対策を一律ではなく、重要度で分ける
すべての委託先へ、大企業と同じセキュリティ対策を要求するのは現実的ではありません。
そこで、たとえば次のように分類します。
| 区分 | 例 | 求める対応 |
|---|---|---|
| Critical | 停止すると主要事業が止まる | 詳細評価、監査、演習、BCP確認 |
| High | 重要データやシステム接続あり | 強化された技術・運用要件 |
| Medium | 限定的な情報や業務を委託 | 標準的なチェック |
| Low | 事業影響・データ影響とも小さい | 最低限の確認 |
重要なのは、会社の規模ではなく、自社にとっての影響度で分類することです。
小さな会社でも、自社の認証基盤を管理していればCriticalです。
巨大企業でも、いつでも代替可能なサービスなら相対的重要度は下がります。
4.3 契約に「インシデント時の動き」を入れる
契約時にセキュリティ要件を書く企業は増えています。
しかし、
適切なセキュリティ対策を実施すること
だけでは不十分です。
重要な委託先については、少なくとも次を具体化します。
- インシデント発生時の通知期限
- 24時間対応可能な緊急連絡先
- 影響範囲の報告方法
- 自社データへの影響調査
- 再委託先で発生した場合の報告義務
- ログや証跡の保存
- 復旧状況の定期報告
- 監査や調査への協力
- 契約終了時のデータ削除
- 代替サービスへの移行支援
「事故が起きたら速やかに報告する」ではなく、
検知後○時間以内に第一報
↓
○時間ごとに状況更新
↓
判明事項・未判明事項を分けて報告
まで決めておくと、実際のインシデント対応力が大きく変わります。
4.4 自社への侵入経路を分離する
委託先が自社システムへ接続している場合は、委託先側が侵害されることを前提にします。
代表的な対策は次の通りです。
- MFA
- 最小権限
- 接続元制限
- ネットワーク分離
- 委託先専用アカウント
- 特権IDの分離
- APIキーや秘密情報の定期ローテーション
- ファイル受信時のマルウェア検査
- 利用時間帯の制限
- ログ監視
- 契約終了時の即時アクセス停止
ここでの目的は、
委託先を信用しない
ことではありません。
委託先が侵害されても、被害を自社へ持ち込ませない
ことです。
ゼロトラストの考え方は、人や端末だけでなく、企業間接続にも適用する必要があります。
4.5 「止まっても続ける」設計を用意する
今回のKFC事案から最も強く学ぶべき点は、ここだと考えます。
セキュリティ対策を強化しても、サードパーティの停止をゼロにはできません。
したがって、
第三者を止めない
だけではなく、
第三者が止まっても、自社まで止まらない
設計が必要です。
具体的には次のような対策です。
- 複数事業者への分散
- 複数拠点への分散
- 代替輸送ルート
- 安全在庫
- 緊急時の発注方法
- 手作業への切り替え
- 最低限の商品・サービスだけを提供する縮退運転
- 別システムによる受注
- 緊急時の顧客案内
ただし、何でも二重化すればよいわけではありません。
冗長化にはコストがかかります。
特に物流では、設備、温度管理、輸送網、品質管理、契約などが絡むため、単純に「明日から別会社へ切り替える」というわけにはいかない場合があります。
だからこそ、事前に、
通常運転
↓
一部機能停止
↓
縮退運転
↓
緊急代替
↓
全面停止
の境界を決めておく必要があります。
4.6 委託先停止を想定した訓練をする
インシデント訓練というと、
社内PCがランサムウェアに感染した
というシナリオが多いかもしれません。
しかし、次のような訓練も必要です。
月曜日の午前6時、主要物流会社から「サイバー攻撃を受け、復旧時期は未定」と連絡が来た
このとき、
- 誰が経営層へ報告するのか
- どの店舗や工場が何時間後に止まるのか
- 在庫はどれだけあるのか
- 別ルートは使えるのか
- Web注文を止めるのか
- 顧客へいつ告知するのか
- 売上影響を誰が試算するのか
- 取引先から何の情報を受け取る必要があるのか
を実際に動かしてみます。
机上で決めたBCPが、本当に動くとは限りません。
連絡先が古い。
担当者が退職している。
必要なデータが止まったシステムの中にある。
代替手順はあるが、誰も操作したことがない。
こうした問題は、訓練しなければ見つかりません。
5. 2026年、サプライチェーン管理は「お願い」から「可視化」へ進む
日本では現在、経済産業省とIPAが「サプライチェーン強化に向けたセキュリティ対策評価制度」、通称SCS評価制度の準備を進めています。46
2026年度末頃から、★3と★4の申請受付開始を目指しており、★5は今後の検討対象です。
この制度では、委託元が委託先に対して適切なセキュリティ水準を示し、実施状況を確認することを想定しています。
これは重要な前進です。
これまでのサプライチェーン管理では、
「ちゃんと対策してください」
「はい、やっています」
で終わっていたケースも少なくありません。
今後は、一定の基準によって対策状況を可視化しやすくなります。
ただし、ここにも注意点があります。
評価を取得していることと、絶対に攻撃を受けないことは同じではありません。
経済産業省も、SCS評価制度は任意制度であり、特定のセキュリティ製品の導入を必須とするものではないと説明しています。6
つまり、
委託先のセキュリティを評価する
だけでは不十分です。
必要なのは、
委託先のセキュリティを評価する
＋
侵害されても自社へ波及させない
＋
停止しても自社事業を継続する
という3層の設計です。
実務では、まず次の3段階から始めるとよいでしょう。
今日やること
自社を止める可能性のある外部依存先を10社、または10サービス選びます。
30日以内にやること
それぞれについて、次を確認します。
・何を委託しているか
・どんなデータを渡しているか
・どこまで接続しているか
・停止すると何が止まるか
・何時間まで耐えられるか
・代替手段はあるか
・緊急連絡先は分かるか
90日以内にやること
最重要の1社が72時間完全停止するシナリオで、机上訓練を実施します。
これだけでも、かなりの弱点が見つかるはずです。
おわりに
今回のKFCへの影響を、
ニチレイがサイバー攻撃を受けて大変だった
だけで終わらせてはいけません。
攻撃者は、自社を直接攻撃しなくても、自社の事業を止めることができます。
物流会社が止まる。
クラウドが止まる。
決済会社が止まる。
認証基盤が止まる。
保守会社が止まる。
ソフトウェアベンダーが止まる。
すると、自社のサーバーが正常でも、商売は止まります。
もちろん、取引先を完全に守ることはできません。
他社のネットワークを、自社が直接管理することもできません。
しかし、
- 誰に依存しているかを知る
- 重要度を分類する
- 必要な対策を契約で求める
- 自社への侵入経路を分離する
- 停止時の代替策を用意する
- 実際に訓練する
ことはできます。
今回の事案から得るべき最大の教訓は、
「委託先もセキュリティを強化すべきだ」
だけではありません。
第三者が止まっても、自社まで止まらないように設計する。
そこまで含めて、これからのサプライチェーンセキュリティなのだと思います。
参考
- ITmedia NEWS「KFC、全店舗で品切れや臨時休業のおそれ ネット注文も停止 原因はニチレイへの不正アクセス」 ── KFCへの取材により物流委託先がニチレイであることを確認した報道
-
日本ケンタッキー・フライド・チキン「物流委託先のシステム障害に伴う一部店舗の営業への影響について」 ── KFC全店舗への影響、品切れ・メニュー制限・営業時間短縮・臨時休業の可能性、オンライン注文停止の根拠 ↩ ↩2 ↩3
-
株式会社ニチレイ「当社グループでのシステム障害発生について」 ── 不正アクセスの発生、冷蔵倉庫の入出庫業務・冷凍食品出荷業務への影響、情報流出調査状況の根拠 ↩ ↩2 ↩3
-
IPA「情報セキュリティ10大脅威 2026」 ── 「サプライチェーンや委託先を狙った攻撃」が組織向け第2位であることの根拠 ↩
-
IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 ── 委託先への攻撃による事業停止・情報漏えい・不正侵入等のリスクと制度概要の根拠 ↩ ↩2
-
IPA「プラクティス9-2 サプライチェーンで連携する各社が『自社ですべきこと』を実施する体制の構築」 ── 委託先の棚卸し、対策要求、問い合わせ窓口、定期確認等の実践例 ↩
-
経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 ── ★3・★4、制度開始時期、任意制度であること等の根拠 ↩ ↩2