ニッスイのサイバー攻撃で日水物流の入出荷停止｜委託先クラウド障害に荷主が備える手順

ニッスイは2026年10月7日、グループ会社の日水物流でシステム障害が起き、同社が扱う商品の入出荷ができなくなったと公表しました。10月9日の第2報では、原因を委託先であるIDCフロンティアが受けた第三者の不正アクセスと明記し、同日から一部の入出荷を再開しています。本記事で整理するのは、ニッスイの第1報と第2報、IDCフロンティアの第3報を突き合わせて確定した事実です。そのうえで、自社が直接契約していないクラウドの障害で荷主の物流が止まる構造と、委託先の基盤を棚卸しするPythonの手順、止まったときの代替手段の線引きを示します。

まとめ：ニッスイのサイバー攻撃で確定した事実と委託先を使う企業が今週やること

確定している事実は四つです。10月7日に日水物流でシステム障害が起き、入出荷が止まったこと。原因が委託先IDCフロンティアへの第三者による不正アクセスであること。10月9日から一部の入出荷が再開したこと。被害を受けたサーバーに、ニッスイグループが管理する個人情報や顧客情報は含まれないと確認されたこと。全面復旧の見通しは、10月9日時点でまだ示されていません。

この事案の教訓は、ニッスイ本体がIDCFクラウドと契約していたかどうかに関係なく商品が動かなくなった点にあります。委託先の、さらにその先の基盤まで把握していなければ、自社の業務がどこで止まりうるかは見えません。委託先を使う企業が今週中にできるのは次の作業です。

公表内容を時系列で確認する｜ニッスイ第1報・第2報とIDCF第3報の対応関係

第1報で入出荷停止と委託先データセンターへの不正アクセスを公表した10月7日

ニッスイの10月7日の第1報は、日水物流でシステム障害が発生し、日水物流が取り扱う商品の入出荷ができない状況だと伝えました。原因は「日水物流が利用する委託先のデータセンターへの第三者による不正アクセスとみられる」との表現で、委託先の名前は書かれていません。個人情報や顧客データの外部流出については「確認を進めている」としていました。

同じ10月7日には、IDCフロンティアがIDCFクラウドへの不正アクセスを公表しています。同社の10月8日の第3報によると、障害は東日本リージョン1の一部ゾーンで起き、原因は第三者からのランサムウェア攻撃、影響はIDCFクラウドを契約する495の企業や自治体に及びました。対象ゾーンのデータは取り出しや復元が困難な見通しで、復元は利用者自身が持つバックアップからのみ可能というのが同社の見解です。事業者側の経緯と利用者の初動はIDCFクラウドの不正アクセスと利用者の復旧手順で詳しく扱っています。

第2報で委託先をIDCフロンティアと明記し一部の入出荷を再開した10月9日

10月9日の第2報で、ニッスイは委託先を株式会社IDCフロンティアと明記しました。第1報で「とみられる」とされていた原因が、ここで特定の事業者への不正アクセスとして書き直された形です。同日から一部の入出荷業務を再開し、通常の入出荷体制への回復を目指すとしています。

第2報は「全面的な復旧の見通しは改めて知らせる」と結んでいます。一部再開が、どの拠点のどの業務から始まったのかは書かれていません。取引先の立場では、自社向けの商品が再開の対象に入っているかを営業窓口に個別に確かめる必要があります。

個人情報や顧客情報は被害サーバーに含まれないと確認された点の読み方

第2報には「被害を受けたサーバーにニッスイグループが管理する個人情報や顧客情報は含まれないことを確認しました」とあります。第1報の「確認を進めている」から一歩進んだ記述です。ただし、IDCフロンティア側の発表では、10月8日の第3報の時点で情報漏えいの有無に触れておらず、侵入経路も調査中のままです。

読み方として押さえておきたいのは、ニッスイの確認は「自社グループが管理する情報」の範囲だという点です。取引先がニッスイや日水物流に渡していた発注データの扱いは、この一文だけでは判断できません。取引先として気になる場合は、渡したデータの種類を伝えて個別に照会してください。

契約していないクラウドの障害で荷主の物流が止まる構造｜委託の三層と依存の連鎖

荷主・物流会社・クラウド事業者の三層で見るとニッスイの出荷まで止まった理由

今回の連鎖は三つの層で整理できます。商品の持ち主である荷主がニッスイ、保管と入出荷を担う物流会社が日水物流、その物流会社が使うシステムの基盤を提供していたのがIDCフロンティアです。第1報が「日水物流が利用する委託先」と書いているとおり、IDCFクラウドを使っていたのは日水物流の側でした。

荷主から見れば、IDCフロンティアは契約相手の契約相手です。自社の情報システム部門の管理台帳には載っていないのが普通でしょう。それでも、物流会社のシステムが止まれば荷主の商品は倉庫から出ません。サプライチェーン攻撃の起点別の類型でいえば、委託先の基盤から被害が及ぶ型にあたります。

低温物流の入出荷が在庫引当・出荷指示・伝票発行のどこで止まるか

日水物流が具体的にどのシステムをIDCFクラウドで動かしていたかは、公表されていません。ここでは一般的な物流センターの業務で、システムが止まると何ができなくなるかを整理します。

入荷では、届いた商品をどの棚に置いたかを記録できなくなります。出荷では、荷主から届く出荷指示を受け取れず、どの棚から何をいくつ取り出すかのピッキングリストも出せません。送り状や納品書の発行、運送会社への出荷データの送信も止まります。倉庫の商品の在り処と数を正しく知っているのがWMS（倉庫管理システム）なので、ここが止まると現物が目の前にあっても動かせないのです。

低温物流ではもう一つ事情が重なります。冷凍・冷蔵の商品は、手作業で探す時間そのものが品質の劣化につながります。棚を一つずつ開けて確かめる運用は、常温の倉庫より長くは続けられません。2026年7月にニチレイのサイバー攻撃で冷蔵倉庫の入出庫が止まったときも、同じ構図が表に出ました。

委託先の復旧待ちで再開時期が決まる構図と荷主が自社で動かせる範囲

IDCFの第3報が示した「復元は利用者自身のバックアップからのみ」という見解は、利用者である物流会社にとって、自社の写しがなければ別環境での作り直しになることを意味します。荷主はこの判断に関与できません。物流会社がどこにバックアップを置いていたか、別環境を用意できるかで、荷主の出荷再開の日付が決まります。

荷主が自分で動かせるのは、物流会社の外側にある部分だけです。出荷予定や在庫の写しを自社で持っているか、別の倉庫へ出荷を振り替える契約があるか、取引先への連絡手段が委託先のシステムに依存していないか。この三つは平時に準備しておけば、委託先が止まった日にも使えます。

委託先の基盤を棚卸しする｜台帳の項目設計とPythonで危険な組み合わせを洗い出す

経産省ガイドライン指示9が求める委託先の特定と対策状況把握の具体化

経済産業省のサイバーセキュリティ経営ガイドライン Ver3.0は、経営者がCISO等に指示すべき重要10項目の一つとして、サプライチェーン全体の対策を挙げています。IPAのプラクティス・ナビの指示9では、システム管理の運用委託先を含めた対策状況の把握と、契約で役割と責任範囲を明確にすることが求められています。

同じページは、実践のファーストステップを「リスクのある委託先の特定」と「その委託先の対策状況の把握」の二点としています。想定される課題として挙がっているのが、部署ごとに業務委託していて会社として委託先を把握していない状況です。今回のように委託先の基盤事業者まで追う場合は、この「把握」を、聞く項目が決まった台帳にしておかないと続きません。

委託先台帳に持たせる9列と基盤事業者・バックアップ保管先を聞き取る質問

台帳はCSV一枚で始められます。列は次の9つです。業務、委託先、システム、基盤事業者、リージョン、バックアップ保管先、復旧目標時間（時間）、許容停止時間（時間）、手作業代替の有無。このうち委託先から聞き取るのは、基盤事業者、リージョン、バックアップ保管先、復旧目標時間の四つです。

業務,委託先,システム,基盤事業者,リージョン,バックアップ保管先,復旧目標時間h,許容停止時間h,手作業代替
出荷,A物流,WMS,Xクラウド,東日本,Xクラウド,24,8,なし
受注,B社,受注EDI,Yクラウド,東京,社内NAS,4,8,あり
請求,C社,販売管理,不明,,不明,,72,あり

委託先には「本番環境はどの事業者のどのリージョンで動いていますか」「バックアップはどの事業者に、何世代置いていますか」「その事業者が侵害されたとき、何時間で別環境に戻せますか」の三問を送ると答えが揃います。許容停止時間は委託先ではなく自社の業務部門が決める値です。物流の受け渡しは社内WMS・TMSと企業間EDIのデータ連携で層が分かれるため、EDIの中継事業者も一行として載せてください。

同一事業者内バックアップと許容停止時間超過をPythonで検出するスクリプト

委託先が数十社になると、台帳の全項目を目視だけで確認するのは困難です。次のスクリプトは、上の台帳を読み、事業者側の侵害に弱い組み合わせを一行ずつ出力します。Python 3の標準ライブラリだけで動きます。

# 委託先台帳（CSV）を読み、事業者側の侵害に弱い組み合わせを洗い出す
import csv
import sys


def check(row):
    issues = []
    base = row["基盤事業者"].strip()
    backup = row["バックアップ保管先"].strip()
    if base in ("", "不明"):
        issues.append("基盤事業者が未把握")
    elif backup == base:
        issues.append("バックアップが本番と同じ事業者")
    if backup in ("", "不明"):
        issues.append("バックアップ保管先が未把握")
    rto = row["復旧目標時間h"].strip()
    limit = float(row["許容停止時間h"])
    if not rto:
        issues.append("復旧目標時間が契約で未合意")
    elif float(rto) > limit:
        issues.append(f"復旧目標{rto}hが許容停止{limit:g}hを超える")
    if row["手作業代替"].strip() != "あり":
        issues.append("手作業の代替手順なし")
    return issues


with open(sys.argv[1], encoding="utf-8-sig", newline="") as f:
    for row in csv.DictReader(f):
        for issue in check(row):
            print(f'{row["業務"]}\t{row["委託先"]}\t{issue}')

python -X utf8 check_vendors.py vendors.csvで実行すると、上の例では出荷業務に「バックアップが本番と同じ事業者」「復旧目標24hが許容停止8hを超える」「手作業の代替手順なし」の3件、請求業務に未把握と未合意の3件が出ます。受注業務は何も出ません。-X utf8は、Windowsのコンソールで日本語の出力が文字化けしないようにする指定です。

最初に手を付けるのは、「本番と同じ事業者」と「許容停止を超える」が同じ業務に重なった行です。今回のIDCFのように事業者の基盤が侵害されると、その業務は委託先の復旧を待つ以外に道がなくなります。

委託先が答えないときにDNSとJPNIC WHOISで基盤事業者の見当を付ける

委託先への問い合わせに対し、すぐに回答が来るとは限りません。委託先のシステムがEDIの受付やWeb画面としてインターネットに出ていれば、外から基盤の見当は付けられます。JPNIC WHOISの案内にあるとおり、whoisコマンドで検索先にwhois.nic.ad.jpを指定すると、IPアドレスの割り当て先組織を引けます。

# 委託先が公開しているホスト名からIPアドレスを調べる
dig +short edi.example-logi.co.jp A

# 得られたIPアドレスの割り当て先組織をJPNICに問い合わせる
whois -h whois.nic.ad.jp 203.0.113.10

出力のネットワーク情報にある組織名が、クラウド事業者やデータセンター事業者の名前になっていれば手掛かりになります。ただし、CDNやWAFを前段に置いている場合は、それらの事業者の名前しか出ません。社内向けの業務システムはそもそも外から見えません。この方法は見当付けにとどめ、台帳には委託先の正式な回答を書き込んでください。

止まったときの代替手段を決める｜復旧待ちと手作業・別基盤への切替の線引き

内閣府ガイドラインの現地復旧戦略と代替戦略を委託先システムに当てはめる

内閣府の事業継続ガイドライン（令和5年3月）は、自然災害だけでなくサプライチェーン途絶やサイバー攻撃にも適用できると明記しています。戦略は二つの観点で整理されています。被害からどう復旧するかの「現地復旧戦略」と、使えなくなったときにどう代わりを確保するかの「代替戦略」です。同ガイドラインのチェックリストにも、現地復旧戦略とともに代替戦略を検討しているかという項目があります。

委託先システムに当てはめると、現地復旧は委託先がシステムを直すのを待つこと、代替は手作業か別の基盤で業務を回すことです。今回のIDCFのように事業者が「データの取り出しや復元が困難」と発表した場合、現地復旧の見通しは荷主の手の届かないところで決まります。代替戦略を一つも持っていない業務は、その発表を待つしかありません。考え方の土台は荷主と物流事業者が決める物流BCPの7項目でも整理しています。

出荷予定と在庫の写しを日次で手元に残し紙の出荷指示に切り替える準備

最も費用がかからない代替は、手作業で最低限の出荷を回すことです。前提になるのは、委託先のシステムの外に、出荷予定と在庫の写しがあることです。WMSの画面からCSVを書き出せる契約なら、毎日決まった時刻に自社のファイルサーバーへ保存する運用から始められます。

1. 取引先別・品目別の出荷予定と、拠点別の在庫数を毎日書き出して自社に保存する
2. 出荷を止められない取引先と品目の順位を、業務部門と事前に決めておく
3. 紙の出荷指示書と手書きの送り状で回す手順を、年1回は倉庫と試す

写しは前日の状態なので、停止当日の受注は反映されません。それでも、どの倉庫に何がいくつあったかが分かれば、優先度の高い取引先から手作業で出荷できます。写しがゼロの状態から棚を数え直すのとでは、初動に数日の差が出ます。

別基盤の待機系まで用意すべき荷主と週次の写しで足りる荷主の判断基準

別の事業者に待機系のシステムを用意する構成は、費用も運用の手間も大きくなります。採るべきかを決める判断基準は、自社業務の許容停止時間です。医薬品や学校給食向けなど、1日止まると代わりの供給元がない取引先を抱える荷主は、待機系まで用意する価値があります。出荷が数日遅れても取引先が在庫で吸収できる商品なら、待機系は過剰です。日次の写しと手作業の手順で十分です。

失敗しやすいのは、待機系を用意したのに切替の訓練をしていない状態です。データの同期が止まっていたことに、切り替える日に初めて気付く例は珍しくありません。待機系を持つなら、半年に1回は実際に切り替えて出荷伝票が出るところまで確かめてください。クラウドとオンプレミスの組み合わせ方はBCP対策の置き場所と責任分界で比べています。委託先任せになっている物流システムを、写しの書き出しや切替を前提にした構成へ作り直したい場合は、物流システム開発で現行の業務フローから相談できます。

取引先と顧客への説明｜委託先起点の障害で荷主が伝える内容と報告判断

止まっている業務・再開した範囲・次の発表日時を分けて伝える文面の組み立て

委託先が原因でも、取引先から見れば止まっているのは荷主の商品です。ニッスイの第1報と第2報は、止まっている業務、原因、個人情報の確認状況、復旧見通しを短い段落に分けて書いています。荷主が取引先へ送る連絡も、同じ分け方が使えます。

文面は、止まっている業務と対象の商品、再開した範囲、次に知らせる日時の順に置きます。見通しが立たないときは、立たないと書いたうえで次の連絡日時を約束してください。委託先の名前を出すかどうかは、委託先の公表を待ってから決めます。ニッスイも、委託先名を書いたのはIDCフロンティア自身の公表後の第2報でした。

個人データが委託先にあった場合に個人情報保護委員会への報告を判断する手順

ニッスイは被害サーバーに自社グループの個人情報が含まれないことを確認しています。一方で、自社の顧客の個人データを委託先のシステムに預けていて、そのサーバーが侵害された場合、委託元である自社も報告の要否を判断する立場に置かれます。最初にやるのは、委託先に「侵害されたサーバーに当社の個人データが含まれていたか」を書面で照会することです。

含まれていた、または判明しない場合は、漏えいのおそれとして扱うかどうかを判断します。対象となる類型と、速報3〜5日・確報30日の期限は個人情報保護委員会への報告義務で確認できます。委託先の調査結果を待つ間も期限は進むため、照会の日付と回答内容は記録に残してください。

よくある質問

ニッスイのサイバー攻撃と日水物流のシステム障害について、取引先や委託先を使う企業から出やすい質問をまとめました。

ニッスイのサイバー攻撃の原因はランサムウェアですか？

ニッスイの発表は「委託先であるIDCフロンティアが第三者による不正アクセスを受けたこと」を原因としており、ランサムウェアという言葉は使っていません。IDCフロンティアの第3報は、IDCFクラウドへの不正アクセスをランサムウェア攻撃としています。ニッスイや日水物流のシステムが直接攻撃されたのではなく、委託先の基盤が攻撃を受けた結果として業務が止まった構図です。

日水物流の入出荷はいつ復旧しますか？

10月9日の第2報で、同日から一部の入出荷業務を再開したと公表されました。全面的な復旧の見通しは、10月9日時点では示されておらず、改めて知らせるとされています。どの拠点や商品から再開したかは公表されていないため、取引先は営業窓口へ自社向けの出荷状況を個別に確かめてください。最新の状況はニッスイのニュースリリースで確認できます。

ニッスイの個人情報は漏えいしましたか？

第2報で、被害を受けたサーバーにニッスイグループが管理する個人情報や顧客情報は含まれないことを確認したと公表されています。ただし、これはニッスイグループが管理する情報の範囲についての確認です。IDCフロンティアは10月8日の第3報の時点で、侵入経路を調査中とし、情報漏えいの有無には触れていません。今後の発表で内容が変わる可能性があります。

ニッスイのシステム障害とニチレイの事案は何が違いますか？

どちらも冷凍食品の物流が止まった点は共通しています。違いは攻撃を受けた場所です。2026年7月のニチレイの事案はグループ自身のシステムが攻撃を受け、のちに個人情報の漏えいも公表されました。ニッスイの事案は、日水物流が利用していた委託先のクラウド基盤が攻撃を受け、その停止が物流に及んだものです。備え方も、前者は自社の防御、後者は委託先の把握と代替手段が中心になります。

自社の委託先がどのクラウドを使っているか分からないときはどうすればよいですか？

まず委託先に、本番環境の事業者とリージョン、バックアップの保管先、事業者が侵害されたときの復旧目標時間を書面で問い合わせてください。回答を台帳にまとめると、同じ事業者内にしか写しがない業務が見えてきます。回答を待つ間、委託先のシステムがインターネットに出ていれば、digとJPNIC WHOISで割り当て先組織を調べて見当を付けられます。

関連記事

• IDCFクラウドの不正アクセスとランサムウェア被害｜利用者の初動と別基盤への復旧手順：同じ攻撃を事業者と直接の利用者の側から整理した記事
• ニチレイのサイバー攻撃とは？漏えい53,866件確定までの経緯とRansomHouse声明・防御設計を解説：冷蔵物流が止まった先例と自社システムの防御設計
• IT-BCPとは？BCPとの違いと策定9ステップ・復旧優先度の決め方：業務ごとの復旧優先度を決めるときの手順
• 物流BCPとは？荷主と物流事業者が決める7項目と輸送中止の目安：荷主と物流会社の役割分担の整理
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：委託先の基盤から被害が及ぶ構図の全体像