公式発表の実例：受注再開と通常どおりの配送は別だった
アサヒグループホールディングスの2025年10月3日の第2報では、9月29日に公表したシステム障害について、国内グループ各社の受注・出荷への影響に加え、社外からの電子メールを受信できない状況が説明されています。システムによる受注・出荷は停止する一方、部分的な手作業での受注と、順次の出荷開始を進めていました。
その後の2026年2月18日の公式説明では、電子受発注システムによる受注を、アサヒグループ食品は2025年12月2日、アサヒビール・アサヒ飲料は12月3日に再開したと記しています。配送のリードタイムは2026年2月までに通常化し、物流業務全体は正常化したと説明する一方、出荷可能な商品の品目数は順次拡大する予定としていました。
これは当該企業が各公表日時点で説明した経過であり、現在の供給状況を示す案内ではありません。中小企業の復旧期間を予測する材料にも使いません。
自社の判断に置き換えるなら、「注文できる」「出荷できる」「通常の納期で届く」「必要な品目がそろう」を別々に確認することがポイントです。取引先が「再開」と発表しても、すべての条件が同時に戻ったと考えないようにします。
DBIRの第三者関与は、取引先が止まる確率ではない
Verizonの2025年版DBIRの公表資料は、収集・分析したセキュリティ事案と確認済みの情報侵害を扱い、第三者が関与する情報侵害について説明しています。2026年版の公表資料も第三者の関与を扱い、2025年のデータを用いた報告だと明記しています。
ここでの集計は、日本の取引先すべてを追跡した業務停止の統計ではありません。版をまたいで件数や割合を合算したり、自社の仕入先が止まる確率に読み替えたりしません。情報侵害のリスクと、商品・サービスが届かなくなる業務上の影響は分けて考えます。
最初に、止まった工程と未確認の情報を分ける
購買や営業の担当者は、取引先の公式案内、これまで使っていた連絡先、自社の注文・入荷記録をもとに、次の項目を整理します。担当者が集め、業務責任者が対応を決める流れにします。
| 確認すること | 自社で残す内容 |
|---|---|
| 情報の根拠 | 公式案内のURL・公表日時、担当窓口から確認した日時と内容 |
| 影響する工程 | 発注受付、入荷、出荷、請求、問い合わせのどこが止まっているか |
| 処理済みの範囲 | 受付確認のある注文、未回答の注文、入荷済み・未入荷の区別 |
| 続けられる条件 | 手元の在庫、代替品の可否、顧客との約束、利用できる連絡手段 |
| 未確認と次の行動 | 復旧予定・納期などの未確認事項、確認担当、次に確認する時刻 |
「連絡が来ない」は「注文が受け付けられていない」と同じではありません。送信結果や受付状況が不明な注文は、再送する前に確認待ちにします。 後からメールと電話の注文が両方処理される可能性があるためです。
急に届いた連絡先や振込先の変更は、そのメールに書かれた宛先だけで確認せず、既知の窓口や公式案内と照合します。自社の連携先について不審な動作や情報流出の疑いがある場合は、業務継続の工夫だけで済ませず、自社の情報管理担当や保守先へ引き継ぎます。
想定シナリオ：仕入先の停止で、卸売会社が出荷を見直す
以下は、仕入先の発注画面とメールが使えなくなった卸売会社の未実施の想定シナリオです。実在の被害企業の対応を再現したものでも、hirostaが導入・検証した記録でもありません。
この会社では、自社の受注管理は動いていますが、仕入先へ送った注文の受付と入荷予定が分かりません。営業が納期を案内する前に、購買・倉庫・営業が同じ記録で判断できるようにします。
在庫と、顧客が了承した条件から判断する
- 手元の在庫で対応できる注文： 倉庫担当が実在庫と引当済み数量を確認し、営業が顧客との条件に照らして出荷可否を決めます。
- 代替品や別の仕入先で対応する注文： 購買が仕様、価格、納期、最低注文量などを確認します。顧客の了承が必要な変更は、営業が確認してから発注します。
- 入荷の見通しが立たない注文： 納期を確約せず、保留理由と次の連絡時刻を記録します。保留・分納・取消のどれにするかは、顧客との条件を確認して責任者が判断します。
単に注文の早い順で処理せず、手元の在庫、約束済みの納期、代替の可否を並べて優先順位を決めます。どの顧客を優先するかをAIだけに決めさせません。
仮の管理表に、受付と実行の状態を残す
新しいシステムを急いで作る前に、利用を認められた社内の表計算などで、停止中の注文を管理します。画面の項目は「社内注文番号／元の送信日時／品目と数量／取引先の受付確認／代替対応／入荷・出荷の状態／確認担当／次の確認時刻」といった形です。
たとえば、一つの注文を「受付不明・出荷保留」と残し、取引先から電話で受け付けたと確認できたら、確認日時と担当者を追記して「受付確認済み・納期未確定」に変えます。受付の確認と、入荷・出荷の実行は別の状態にします。 訂正時も元の記録を消さず、変更内容をたどれるようにします。
購買は受付状況、倉庫は入出荷、営業は顧客との合意を更新し、責任者が保留の解除を確認します。個人ごとのメモを正本にせず、閲覧・編集する人と記録の保管先を決めてください。これは運用案であり、この管理表を実際に作って試したわけではありません。
顧客への案内は、事実と次の行動を書く
案内には、影響する商品や注文、現時点で分かること、未確定のこと、顧客に選んでもらう対応、次の連絡時刻を書きます。たとえば「仕入先のシステム停止の影響で、対象商品の入荷予定を確認中です。納期が分かり次第ご案内し、予定が分からない場合も、合意した時刻に状況をお知らせします」といった構成です。
攻撃者、侵入経路、漏えいの範囲を推測で説明しません。個別の注文や顧客情報を一斉案内に混ぜず、対象と内容を営業の責任者が確認してから送ります。
復旧後は、停止中の記録を照合してから通常運用へ戻す
発注画面が開いたことだけで、保留した注文を一括送信しないようにします。取引先に受付可能な範囲と停止中の注文の扱いを確認し、自社では次の順で戻します。
- 切り替えの境目を決める： どの時刻・注文番号から通常手順に戻すかを責任者が決め、担当者へ共有します。
- 仮記録と正式記録を並べる： 元の注文番号、品目、数量、受付確認、入荷・出荷の記録を照合します。代替先に発注した分も含めます。
- 未処理・処理済み・重複候補を分ける： 不明なものは取引先に確認します。同じ品目・数量だけで同一注文とは断定しません。
- 必要な処理だけ実行する： 未処理と確認できた分を承認後に登録します。実行した人・日時・正式な注文番号を仮記録に残します。
- 入荷・請求まで確認する： 発注だけで完了にせず、二重納品や二重請求がないかを購買・倉庫・経理で確認し、未解決の注文を引き継ぎます。
停止中に使った表や連絡記録は、正式記録への引き継ぎを確認する前に削除しません。保管期間と閲覧範囲は社内のルールに合わせます。自社ツールの権限や復旧手順は、保守・引き継ぎの記事で整理しています。
AIは整理や下書きを補助し、人が確認して動かす
AIを使うなら、公開された公式案内から影響・未確認事項を整理する、顧客への案内文の下書きを作る、仮記録と正式記録の食い違いの候補を挙げる、といった補助が考えられます。いずれも今回試した機能ではありません。
人は元の案内や注文記録と照合し、AIが省いた条件、誤って確定した納期、見逃した重複がないかを確認します。注文番号の一致や数量の集計は、まず表計算の関数など決めたルールで処理できるかを検討します。顧客情報や取引先の非公開資料をAIに渡す前には、入力可否の確認が必要です。
取引先への発注、顧客への送信、代替品の採用、保留の解除は人が承認する工程に残します。書類の受付・転記は書類処理の支援、連絡内容の分類・下書きは問い合わせ対応の支援で、業務の整理から相談できます。事故調査や取引先の復旧を代行する案内ではありません。
費用と期間は、代替対応と記録の整理を分けて考える
必要な負担は、取引先の規模だけで決まりません。影響する注文、確認する窓口、代替調達の条件、停止中の記録量、正式システムへ戻す方法で変わります。
- 代替対応の費用： 代替品・仕入先による価格差、追加送料、分納対応、人が確認・案内する時間を分けます。契約や実際の見積りで確認します。
- 手順整備の費用： 仮記録の項目、担当者の分担、二重処理を防ぐ確認、通常運用への戻し方を整理する作業です。
- 仕組み変更の費用： 必要な場合に限り、受付や記録の連携を改修します。AIサービスを使うなら、その利用料も別に確認します。
- 期間の条件： 自社の代替手順を用意する期間と、取引先の復旧を待つ期間を分けます。自社の整備が終わっても、取引先の再開日は保証できません。
まずは重要な取引先と一つの業務を選び、公式連絡先、影響する工程、代替条件、判断する人、再開時の照合方法を確認しましょう。hirostaの支援範囲・料金はサービスページで確認でき、相談窓口には業務の概要と困りごとからご相談いただけます。