倉庫システムが止まると出荷も止まる｜ニチレイ事案に学ぶEC物流のBCPと委託先選定

何が起きたか——倉庫システム障害の概要

報道および企業の公表によれば、ニチレイは2026年7月13日にシステム障害を検知し、その後の調査でサーバーがサイバー攻撃を受けたことを確認しました。影響が生じたのは、グループの冷蔵倉庫の入出庫業務と食品の出荷業務です。つまり、倉庫という「物理的な設備」は無事でも、それを動かす情報システムが止まったことで、モノの出し入れそのものが滞りました。

不正アクセスによるシステム障害が発生し、冷蔵倉庫の入出庫業務および冷凍食品の出荷業務に影響が生じた。復旧に向けて外部のセキュリティ専門会社と連携し、安全対策を講じたうえで業務を順次再開する。

出典：株式会社ニチレイ「当社グループでのシステム障害発生について」（2026年7月）

「他人事」にできない理由

この事案は冷蔵・冷凍という特定領域で起きましたが、教訓は温度帯を問いません。常温を扱うEC倉庫であっても、入庫・保管・ピッキング・出荷はすべてWMSや基幹システムの上で動いています。システムが止まれば、在庫がどこにあるか分からず、出荷指示も送れず、伝票も発行できません。倉庫のシャッターが開いていても、EC事業者の注文は一件も処理できないという状況が起こり得ます。物流を止めないという発想の重要性はEC物流の主戦場は「機能」から「オペレーション」へでも論じています。

なぜEC出荷は「システム」で止まるのか

現代のEC物流は、受注から出荷までが一本のデータの流れでつながっています。どこか一箇所でデータが流れなくなると、後工程がすべて止まる——この連鎖構造を理解しておくことが、備えの第一歩です。

受注データはOMS（受注管理システム）からWMSへ渡り、ピッキング指示・在庫引き当て・送り状発行へとつながります。WMSの在庫同期が乱れると出荷が止まる仕組みはWMS在庫同期の設計パターンで詳しく解説しています。WMSそのものの役割は物流WMS（倉庫管理システム）とはを参照してください。

「止まった時間」がそのまま損失になる

この連鎖構造で怖いのは、停止が長引くほど損失が雪だるま式に膨らむ点です。出荷が止まっている間も注文は入り続け、未出荷の山が積み上がります。復旧後には滞留した注文を一気にさばく必要があり、通常のオペレーションに戻るまでにさらに時間がかかります。つまり、システムが一日止まれば損失は一日分では済まず、キャンセルの増加や配送遅延によるレビュー低下、モールの評価指標の悪化といった二次被害まで波及します。だからこそ、平時に「何時間で復旧できるか（復旧目標時間）」と「その間に何件までなら手作業で出荷を継続できるか」の二つを数値で把握しておくことが重要です。前者は被害の上限を決め、後者は被害の下限を引き上げます。この二つを自社と委託先の双方で共有できていれば、障害発生時にも慌てず、優先順位をつけて動けます。曖昧なまま運用していると、いざというときに現場が判断できず、復旧が遅れる悪循環に陥ります。

EC事業者が備えるべき3つの論点

システム起因の停止は、地震や台風のような物理的な災害とは別の備えを要します。EC事業者が自社と委託先の双方で確認すべき論点は、大きく3つです。

①データの保全と復旧の速さ

在庫・受注・出荷履歴のデータが失われれば、倉庫が無事でも業務は再開できません。定期的なバックアップと、どのくらいの時間で復旧できるか（復旧目標時間）が明確かどうかが要になります。

②止まったときの代替手順

システムが止まっている間、手作業やオフラインで最低限の出荷を回せる手順があるか。優先出荷する注文の基準や、紙ベースでの一時運用など、「止まっても完全にゼロにしない」設計が被害を抑えます。

③連絡と告知の体制

障害発生時に、顧客・モール・関係先へいつ・何を伝えるか。復旧見込みの発信が遅れると、機会損失だけでなく信用の毀損につながります。物理災害を含めた事業継続の考え方は物流BCPとは？EC事業者向け実務ガイドにまとめています。地震時の停止リスクと対策は三陸沖地震が露わにした宅配便停止リスクも参考になります。

サイバー起因の停止に特有の備え

物理災害と違い、サイバー起因の停止は「いつ復旧できるか」の見通しが立ちにくく、原因調査に時間を要するのが特徴です。独立行政法人情報処理推進機構（IPA）は、企業を狙う脅威として、取引先や委託先の弱点を突く攻撃や、データを人質に取る手口が上位を占め続けていると継続的に注意を促しています。物流のように多数の事業者がデータでつながる領域では、自社が直接狙われなくても、委託先や連携システムの障害が波及するリスクを織り込む必要があります。最新の傾向はIPAの情報セキュリティに関する資料で確認できます。

あわせて押さえておきたいのが、個人情報の取り扱いです。EC物流では顧客の氏名・住所・連絡先を大量に扱うため、万一データが漏えいした場合の報告義務や本人への通知といった対応を、平時から手順化しておく必要があります。漏えい時の対応の考え方は個人情報保護委員会のよくある質問が参考になります。委託先を選ぶ際も、顧客データをどう保護し、事故時にどう報告するかを確認しておくと安心です。

委託先の「止まらない物流」を見極める観点

自社倉庫を持つ事業者も、発送代行に委託している事業者も、確認すべき観点は共通します。委託先を評価する際は、次の項目を平時のうちに質問しておきましょう。

拠点やキャリアを分散させる考え方は物流拠点戦略の基本と分散・集約の判断軸やEC通販のマルチFC複数拠点戦略で掘り下げています。大手物流が事業者間で連携して「止まらない物流」を目指す動きは大手物流がBCP連携を始動で解説しました。

発送代行を選ぶときのBCPチェック

自社で高度なシステム冗長化や24時間の復旧体制を維持するのは、多くのEC事業者にとって負担が大きいものです。発送代行を活用すれば、こうした体制を専門事業者の側に持たせ、自社は本業に集中できます。ただし「任せれば安心」ではなく、委託先がどこまで備えているかを見極めることが前提です。

たとえばSTOCKCREWは、在庫・出荷をシステムで一元管理しつつ、出荷をヤマト運輸・佐川急便で行う体制です（常温商品が対象）。複数キャリアを使い分けられることは、特定の一系統が止まったときのリスク分散にもつながります。サービスの全体像はSTOCKCREW完全ガイド、EC物流全体の設計思想はEC物流完全ガイドで確認できます。委託先選定の基準を体系的に押さえたい方は発送代行完全ガイドを参照してください。

発送代行を検討する際は、料金や出荷スピードだけでなく、前節の評価表をもとに「止まったときにどう戻すか」を必ず質問しましょう。平時の効率だけで選ぶと、いざというときの復旧力が見えないまま契約してしまいます。BCPは、事故が起きてからでは整えられません。

自社倉庫を持つ事業者が今日からできること

自社で倉庫と出荷を担っている事業者も、備えを大がかりに構える必要はありません。まず着手すべきは、在庫・受注・出荷履歴のデータを、稼働中のシステムとは別の環境に定期的にバックアップすることです。同じサーバー内にだけ保存していると、そのサーバーが被害を受けた瞬間にデータごと失われます。次に、システムが使えない時間帯でも当日出荷分だけは紙のピッキングリストで回す、といった最小限の代替手順を一度でも訓練しておくと、いざというときの復旧速度がまるで変わります。

加えて、注文が集中する一拠点にすべてを依存している状態は、システム障害に限らず、災害や設備トラブルでも一気に出荷ゼロを招きます。出荷の一部を外部の発送代行に分散させておけば、片方が止まってももう片方で最低限の出荷を継続できます。「効率のための集約」と「止まらないための分散」は相反しがちですが、どこまでを一本化し、どこを冗長化するかを意図的に設計することが、これからのEC物流には欠かせません。

まとめ：復旧できる物流かを平時に確かめる

ニチレイのサイバー攻撃による障害は、倉庫という設備が無事でも、システムが止まれば入出庫・出荷が停止するという現実を示しました。これは冷蔵・冷凍に限らず、常温のEC倉庫にも当てはまる普遍的なリスクです。EC事業者は、①データの保全と復旧の速さ、②止まったときの代替手順、③連絡・告知の体制という3つの論点で、自社と委託先の備えを点検する必要があります。委託先を選ぶ際は、料金や速さだけでなく「何時間で・どう戻すか」を平時に確認しておくことが、機会損失と信用毀損を防ぐ最大の保険になります。サイバー起因の停止は、いつどの事業者に起きてもおかしくありません。だからこそ「起きない前提」ではなく「起きた後にどう最短で立て直すか」を、平時の投資判断に組み込んでおくことが重要です。データの多重バックアップ、手作業での代替出荷手順、拠点・キャリアの分散という三つは、いずれも派手ではありませんが、いざというときに事業を止めない土台になります。今回の事案を「大手の話」で終わらせず、自社の出荷が一日止まったらいくらの損失になるかを一度試算してみると、備えの優先順位がはっきり見えてきます。

物流の委託先選定を体系的に進めたい方は発送代行完全ガイドを、STOCKCREWの体制はSTOCKCREW完全ガイドをご覧ください。自社の物流のBCPを具体的に相談したい場合はお問い合わせから、サービス概要を先に把握したい場合は資料ダウンロードからご確認いただけます。