「システムが復旧したので、明日から通常どおり出荷できます」

事故対応の場面で、このように説明する前に、確認したいことがあります。

受注システムにログインできることと、通常の件数を処理できることは、同じでしょうか。停止中にたまった注文を処理しながら、新しい注文にも、いつもの納期で対応できるでしょうか。

システムを動かすことは、業務を戻すための重要な条件です。しかし、それだけで受注・出荷・配送まで通常の状態に戻ったとは判断できません。

2025年9月29日、アサヒグループホールディングスは、サイバー攻撃によるシステム障害と、国内グループ各社の受注・出荷業務などの停止を公表しました。その後の公表資料には、手作業による対応、電子受注の再開、配送に要する期間の通常化という、復旧の段階が示されています。

今回は、この復旧経過を入口に、中小企業が考えたい受注・出荷の継続策を整理します。

前回の記事で扱ったのは、予約データの内容を確認し、正しい状態へ戻すことでした。今回は、そこから視点を変え、**「一日に何件処理できるか」「どの注文を引き受けるか」「たまった仕事をどう減らすか」**という、業務量と処理能力の管理を中心に考えます。

公表資料から見る、電子受注の再開と物流業務の正常化

アサヒグループホールディングスの2026年2月18日付公表資料では、受注・出荷に関するシステムの停止後、手作業による対応を続けていたことが説明されています。電子受注の再開時期と、配送リードタイムが通常化した時期は、次のように分かれています。

時期公表資料に記載された経過
2025年12月2日アサヒグループ食品が、EOS（電子受発注システム）による受注を再開。ア
2025年12月3日アサヒビールとアサヒ飲料が、EOSによる受注を再開。
2026年2月まで配送リードタイムが通常化し、物流業務全体が正常化したと説明。

同資料では、出荷可能な商品の品目数については、順次拡大する予定とも説明されていました。したがって、電子受注の再開、配送条件の通常化、取り扱う商品の範囲は、分けて読む必要があります。これは当時の経過であり、現在も同じ制限が続いていると説明するものではありません。

また、この経過を「その間、すべての出荷が止まり続けていた」と要約することも適切ではありません。手作業での対応と、その後の段階的な再開が公表されているためです。

この記事で取り上げる処理件数や業務条件は、読者が自社の計画を考えるための架空の例です。同社の具体的な要員配置や手作業の能力、復旧に時間を要した個別の理由を推測するものではありません。

「復旧」を、システム・最低限の業務・通常運用に分ける

社内で「復旧」という言葉を使うときは、どの状態を指しているかを明確にしましょう。

本記事では、実務上の整理として、システムの利用再開、最低限の業務再開、通常運用への復帰を分けて管理する方法を提案します。

システムの利用再開では、安全に利用できる状態を確認し、必要な機能を使えるようにします。受注情報の表示や入力ができることは、この段階の確認事項です。

最低限の業務再開では、扱う商品や顧客、件数などを限定し、必要な仕事を実施します。例えば、既存顧客向けの標準品に絞り、一日に処理できる範囲で出荷する状態です。

通常運用への復帰では、通常必要な業務量を、合意した納期や品質で継続して処理できるかを確認します。事故によって増えた未処理案件や、臨時の手作業がどこまで残っているかも確認対象です。

これは、必ず三段階の順番でしか進められないという意味ではありません。システムが戻る前に、手作業で最低限の業務を再開することも考えられます。

大切なのは、「何ができるようになったのか」を区別することです。

例えば、「受注画面は使えるが、出荷指示の連携は未確認」「標準品は処理できるが、特注品は保留」と報告すれば、次に必要な判断が分かります。「復旧済み」という一つの言葉だけでは、この違いが伝わりません。

BCPには、「いつまでに」だけでなく「どの水準まで」を書く

事業継続計画、いわゆるBCPを考える際、「何時間以内に復旧するか」だけを決めていないでしょうか。

内閣府の「事業継続ガイドライン」では、重要業務について、どれくらいの時間で復旧させるかという「目標復旧時間」と、どの水準まで復旧させるかという「目標復旧レベル」を決める考え方が示されています。それぞれRTO、RLOという略称で表されます。

受注・出荷業務なら、「翌営業日までに再開する」という目標だけでは、再開後の能力が分かりません。

そこで、例えば次のように、対象と業務量を組み合わせます。

翌営業日までに、既存顧客向けの標準品について、一日40件を出荷まで処理できる状態を目指す。対応する商品、配送地域、納期条件は別に定める。

これは、目標の書き方を示す架空の例です。「40件」が中小企業に共通する基準という意味ではありません。

実際には、顧客がどの程度の供給停止に耐えられるか、自社が何件処理すれば重要な取引を維持できるか、どの人員や設備を確保できるかを確認して決めます。

また、実現できるかを試していない数字は、そのまま対外的な約束にしないようにしてください。内閣府のガイドラインでも、目標は実施可能性を検討したうえで、経営判断によって正式に決定するものとされています。

復旧目標は、希望する日時を書く欄ではなく、必要な業務水準と、それを実現する準備を結び付けるものです。

「電話で受ければよい」で、出荷まで終えられるか

システムが使えない場合の代替手段として、電話や紙の伝票を考えることはできます。

ただし、その手段で注文を受け取れることと、商品を届ける準備まで終えられることは別です。

本記事では、注文を受け取るところから、在庫確認、商品の確保、出荷指示、梱包、配送会社への引渡し、納品・請求に必要な記録まで、一連の流れを確認することを提案します。

例えば、電話で注文内容を聞けても、顧客ごとの商品コードが分からなければ、何を出荷すべきか確認できません。在庫数が分かっても、すでに他の顧客へ確保した数量を把握できなければ、同じ在庫を二重に約束するおそれがあります。

これらは、代替運用を検討するための想定例です。自社では、どの工程で何を参照しているかを確認してください。

実際に試す際も、伝票を一枚書くだけで終わらせず、検証用の注文を使って出荷までの手順を通してみましょう。途中で必要になった資料、問い合わせ、承認、待ち時間を記録します。

その結果、受注担当者を増やすよりも、在庫確認の担当者を確保する方が、処理できる件数を増やせるかもしれません。どこを改善すべきかは、実際の工程を確認して判断します。

また、同じ人を「受注担当二人」「在庫確認二人」「問い合わせ担当二人」と、複数の工程で重複して数えないようにしてください。担当者の勤務時間を、どの仕事へ割り当てるかまで確認する必要があります。

受注200件、出荷40件なら、未処理は毎日160件増える

代替運用の限界は、簡単な計算でも確認できます。

ここでは、架空の卸売会社を考えます。注文一件当たりの作業量は同程度で、通常は一日200件の注文が入り、200件を出荷まで処理できるとします。

システム停止後は、手作業で一日40件しか出荷まで処理できません。それでも毎日200件を受け付け、取消しなどがないとすると、一日の未処理増加数は次のとおりです。

200件の新規受付 − 40件の処理完了 ＝ 160件の増加

停止時点の未処理をゼロとして、この状態が5営業日続けば、未処理は800件になります。

160件 × 5営業日 ＝ 800件

ここでシステムが復旧し、一日200件を処理できる状態へ戻ったとします。新しい注文も引き続き200件入るなら、未処理の総数は減りません。

古い注文から処理すれば、新しい注文が待ちに回ります。元の処理能力へ戻ることと、事故で生じた遅れを取り戻すことは別なのです。

状態一日の新規受付一日の処理完了未処理件数の動き
手作業による対応中200件40件一日160件増える
通常の処理能力へ戻った後200件200件総数は減らない
追加対応で処理能力を確保した場合200件250件一日50件減る

最後の条件を維持できれば、800件を減らすには、計算上16営業日かかります。

800件 ÷ 一日50件 ＝ 16営業日

これは、受付量と処理量が一定で、誤処理や再作業などがないという条件での計算です。実際の復旧日数の予測ではなく、アサヒグループの処理件数を示すものでもありません。

この例から確認できるのは、たまった仕事を減らすには、処理量を受付量より大きくする期間が必要になるということです。

実務では、注文ごとの負荷も異なります。件数だけで比較しにくい場合は、注文明細数、梱包数、作業時間など、自社の負荷を表す指標に置き換えてください。

最初に決めるのは、「全部続ける」ではなく「何を絞るか」

処理能力が落ちているときに、通常どおりの条件で無制限に注文を引き受ければ、先ほどの例のように未処理が増えます。

そのため、本記事では、受付を続けるかどうかだけでなく、どの商品を、どの地域へ、どの納期条件で扱うかを決めることを提案します。

例えば、在庫と出荷方法を確認できる標準品を優先し、個別の設計確認が必要な特注品は回答を保留する方法が考えられます。即日出荷や細かな時間指定を一時的に制限し、処理可能な条件に整理する方法もあります。

ただし、単に「作業が簡単な注文から処理する」「大口顧客だけを優先する」と決めればよいわけではありません。

すでに約束している納期、供給停止が取引先へ与える影響、商品の用途、代替調達の可能性などを確認し、責任者が判断してください。内閣府のガイドラインでも、事業中断の影響を評価する際、顧客の事業継続や契約への影響などを考慮することが示されています。

注文内容を受け取った段階と、出荷日を回答できる段階も分けて管理しましょう。まだ納期を確認できない注文に対して、通常時と同じ出荷予定を自動的に案内しないようにします。

受付を制限する判断は、現場の担当者一人に任せないことをおすすめします。営業、出荷担当、経営者が、実際の処理能力と顧客への影響を共有したうえで決める必要があります。

代替運用に必要な情報を、停止したシステムだけに置かない

紙の伝票を用意していても、記入に必要な情報が停止中のシステムにしかなければ、作業を進められません。

そこで、自社の代替運用に必要な情報を、あらかじめ特定しておきましょう。

商品コード、荷姿、出荷条件、取引先の連絡先、配送会社の依頼方法などが候補になります。ただし、顧客情報をすべて複製するのではなく、代替運用に必要な範囲と、情報の保護方法を決めてください。

内閣府のガイドラインは、事業継続に必要な重要情報を、同じ事故や災害で同時に使えなくならないよう保管する考え方を示しています。

電子的に控えを用意する場合は、保存先だけでなく、利用する端末やログイン方法も確認します。保存場所を変えていても、同じ認証基盤が停止すると開けない構成なら、代替手段として使えるかを再検討する必要があります。

一方、古い在庫一覧を、現在の在庫数としてそのまま使ってはいけません。本記事では、情報の取得日時を明記し、その後の入出庫や確保済み数量を別に確認する手順を提案します。

紙で保管する場合も、閲覧できる人、保管場所、更新担当者、古い版の廃棄方法を決めます。

また、作業を急ぐために、被害拡大防止のために遮断した接続を現場の判断で戻さないようにしてください。IPAのガイドラインでも、初動対応では被害拡大を防ぐため、必要に応じた通信遮断や隔離などを行うことが示されています。

代替運用は、安全に利用できると確認した手段で行うことが前提です。

「業務停止時の代替運用表」を作る

確認した内容は、担当者が引き継いで使えるよう、一つの表に整理しましょう。

次の表は、本記事で提案する作成例です。公的機関の指定様式や、アサヒグループの実際の運用表ではありません。

管理項目決めておく内容
継続する業務の範囲対象の商品、顧客、配送地域、扱わない依頼
開始条件と判断者どの状況で代替運用へ移り、誰が開始を決めるか
注文の受付方法承認済みの窓口、受付時間、注文を識別する番号
使用する情報商品・取引先情報などの保管場所、更新日時、確認方法
在庫と出荷の管理在庫確認、商品の確保、出荷指示、配送依頼の手順
処理能力一日に完了できる件数、必要な人員、未確認の制約
受付を見直す条件未処理の増加、納期への影響、人員不足などの判断条件
顧客への回答回答できる内容、承認者、次に連絡する時刻
実施記録受付、変更、出荷、取消し、請求に必要な記録の残し方
通常運用への移行データ反映、重複防止、切替日時、完了確認の担当者

最初から細かな手順をすべて書く必要はありません。まず、今の体制で回答できない欄を明らかにし、担当者と確認期限を決めてください。

特に、処理能力の欄を「できる限り対応」としないことが重要です。試験で確認できた件数と、まだ確認できていない条件を分けて記録しましょう。

また、受付を見直す条件には、未処理の総数だけでなく、最も古い注文の待ち時間や、約束した納期を超える注文の有無も含めることをおすすめします。同じ100件の未処理でも、明日出荷する予定のものと、すでに納期を過ぎたものでは、必要な対応が異なるためです。

営業・倉庫・配送会社で、同じ対象を確認する

処理能力の管理では、部署ごとに「完了」の意味が違わないかを確認してください。

営業にとっては注文の登録が終われば完了でも、倉庫では商品を集める作業が残り、配送会社への引渡しも終わっていないかもしれません。

本記事では、「受付済み」「出荷準備中」「出荷済み」など、どの工程まで進んだかを区別し、共通の注文番号で確認する方法を提案します。

毎日の状況確認では、新しく受け付けた件数、出荷まで完了した件数、未処理件数、納期超過の件数を、対象と時刻をそろえて集計しましょう。

例えば、「本日15時時点、対象は標準品の国内出荷」と範囲を明記します。午前中の数字と夕方の数字、全商品の数字と一部商品の数字を、同じ表で比較しないようにしてください。

配送会社へも、自社の出荷予定を伝えるだけでなく、実際に引き受けてもらえる量や条件を確認します。自社で梱包を終えられても、その日の集荷や輸送を手配できなければ、顧客へ同じ納期を案内できません。

NISTのサイバーセキュリティフレームワークでも、関係する供給者などを、事故対応や復旧の活動に含める考え方が示されています。

自社の一工程だけを戻すのではなく、相手へ引き渡せるところまで、条件をすり合わせることが必要です。

長期化に備え、現場運用と復旧作業の人員を確保する

代替運用を始めるときは、初日を乗り切る人員だけでなく、その状態が続く場合の分担も考えてください。

例えば、システム担当者が、保守会社への説明、データの確認、従業員からの質問、顧客向け資料の作成をすべて担当する体制では、それぞれにどの程度の時間を使えるか確認が必要です。

本記事では、技術的な復旧を進める役割、手作業で業務を進める役割、取引先への回答をまとめる役割を整理し、同じ人へ割り当てる場合も、作業時間を分けて計画することを提案します。

人を追加する場合も、人数だけではなく、担当できる作業を確認しましょう。商品を探して梱包する作業、注文内容の不明点を判断する作業、出荷を承認する作業では、必要な知識と権限が異なります。

応援者が作業できる範囲と、判断を引き継ぐ先を決め、手順や帳票をそろえておくと、分担しやすくなります。内閣府のガイドラインにも、代替要員の育成・確保や、応援者を受け入れる体制・手順の整備が示されています。

また、初日の特別な対応で達成した件数を、そのまま長期間の処理能力として計画に使わないことをおすすめします。通常の勤務体制、休憩、交代、引継ぎを含めて維持できる量を確認してください。

代替運用の期間を延ばす判断には、そのための人員と、通常業務をどこまで減らすかという判断も必要です。

システム復旧後は、新しい注文と滞留分を並行して処理する

先ほどの架空の例では、一日200件を処理できる状態へ戻っても、毎日200件の新しい注文が入るため、800件の未処理は減りませんでした。

そこで、システムの復旧計画とは別に、事故で増えた未処理案件を減らす計画を作りましょう。

まず、何が残っているかを分類します。未出荷の注文、出荷したがシステムへの記録が未反映のもの、納期回答待ち、内容確認待ちでは、必要な作業が違います。

出荷済みで入力だけが残っている案件を、未出荷として数えないようにしてください。一方、入力が終わっただけで、出荷まで完了した件数へ入れることも避けます。

そのうえで、新しい注文の処理に必要な人員と、滞留分を処理する人員・時間を割り当てます。別の担当者へ任せるのか、業務時間内に専用の処理枠を設けるのか、外部へ依頼できる作業があるのかを検討してください。

先ほどの例で、一日250件の処理能力を確保できれば、200件の新規分に加え、50件ずつ滞留を減らせます。ただし、この数字を計画に採用するには、倉庫、検品、配送など、必要な工程がその量に対応できるかを確かめる必要があります。

毎日、受付と処理完了の実績を確認し、滞留が計画どおり減っていなければ、原因と対応を見直しましょう。

復旧後の仕事量は、「今日の通常業務」に「事故で残った作業」を加えたものです。 システムが戻った日から、必要な人員も直ちに通常どおりになるとは決めないようにしてください。

手作業から戻す日を、切替計画として決める

通常のシステムを再び使う際は、手作業の記録を、いつ、どのように反映するかを決めます。

本記事では、ある時刻を境に新しい注文の受付方法を切り替え、それ以前の注文は管理番号で追跡する方法を提案します。業務上、一斉切替えが難しい場合は、対象を分け、どちらの方法で処理するかを明確にしてください。

特に注意したいのは、出荷済みの注文を、未処理の新規注文として登録しないことです。

システムへ記録する目的が、履歴や請求情報を整えることなのか、これから出荷を行うことなのかを分けます。入力によって出荷指示や顧客通知が自動実行される仕組みがある場合は、その動作も確認してください。

手作業の記録には、反映済みであることと、確認した担当者を残します。途中で担当者が交代しても、どこから再開すればよいか分かるようにしましょう。

内閣府のガイドラインでも、代替手段から通常運用へ切り替える際、データの欠落や不整合を防ぐ復帰計画が必要とされています。

ただし、今回は予約データの照合そのものを詳しく扱う回ではありません。ここで押さえたいのは、切替えと記録の反映も、担当者と処理時間を必要とする業務として計画に含めることです。

取引先には、「復旧済み」ではなく注文できる条件を伝える

取引先が判断に必要とするのは、システムが動いているかだけではありません。

どの商品を注文できるのか。どの窓口を使うのか。いつまでに納期の回答を受けられるのか。以前に送った注文を、再送する必要があるのか。

本記事では、復旧状況のお知らせに、こうした実際の取引条件を含めることを提案します。

例えば、次のような案内文が考えられます。

本日、受注システムを再開しました。ただし、現在は出荷できる商品と一日の処理量に制限があるため、通常の納期ではご案内しておりません。出荷可能な商品と納期は、担当窓口から個別にご回答します。すでにお送りいただいたご注文については、重複を避けるため、再送前に受付番号を添えてお問い合わせください。次回の状況案内は、本日16時に行う予定です。

これは架空の状況に対する文例です。受付番号を発行していない場合や、次回案内の時刻を決めていない場合は、そのまま使わず、自社が実施できる内容へ修正してください。

また、「安全性の確認」「受注の再開」「出荷条件の変更」は、分けて説明すると誤解を減らせます。技術的に利用再開を判断できても、通常の納期で対応できるとは限らないためです。

NIST CSF 2.0でも、復旧作業と業務能力の回復状況を、必要な社内外の関係者へ伝えることが示されています。

詳しい原因を調査中であっても、現在確認できている受付条件や、次に連絡する予定は、別に整理して伝えましょう。

通常運用への復帰は、IT担当者だけで判断しない

通常運用へ戻す判断では、システムの確認結果と、業務側の確認結果をそろえます。

NIST CSF 2.0は、復元した情報やシステムの状態を確認することに加え、定めた基準に基づいて復旧の終了を判断することを示しています。

本記事では、次のような確認表を作り、経営者または業務責任者が最終判断する方法を提案します。

確認する範囲通常運用へ戻す際の確認例
システムの利用条件管理者・保守会社等による確認が済み、必要な監視や対策を維持できる
受注から出荷まで通常扱う注文を、一連の工程で処理できる
処理能力と納期必要な量を処理でき、納期条件を実績に基づいて案内できる
事故による滞留通常の未処理と区別し、解消状況や残件の扱いを説明できる
手作業の記録必要な反映と照合が終わり、二重処理や反映漏れを確認している
人員と外部協力特別な無理を続けなくても、必要な作業を分担・継続できる
残る課題と案内制限が残る範囲、担当者、期限、取引先への案内が明確になっている

ここで、「未処理が一件でもあれば通常運用ではない」と決める必要はありません。通常の業務でも、将来の出荷予定や処理待ちは存在し得ます。

区別したいのは、通常の処理サイクルにある案件と、事故によって余分に発生した遅延です。件数だけでなく、納期や待ち時間を見て判断してください。

また、一部の業務だけ先に通常化する場合は、その範囲を明示します。「標準品の出荷は通常化したが、特注品の見積りは制限中」といった説明です。

通常運用への復帰は、すべてを一つの完了マークで管理するのではなく、何が通常化し、何が残っているかを説明できる状態にすることと考えましょう。

訓練は、「伝票を一枚書けた」で終えない

代替運用表ができたら、実際に使えるかを確認します。

IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」でも、事業継続の要件に沿って復旧の準備を行い、訓練によって実効性を検証することが示されています。

本記事では、判断を確認する机上演習と、作業時間を確かめる実務の試験を分けて行う方法を提案します。

机上演習では、「本日は通常の五分の一しか出荷できない」という条件を置き、誰が受付制限を決めるか、どの注文を優先するか、何を取引先へ案内するかを確認します。

途中で「翌日もシステムが使えない」「出荷担当者が一人不在」「配送会社が受け入れられる数量も限られる」といった条件を追加すれば、計画の見直しができるかを試せます。

一方、実務の試験では、架空の注文とテスト用の資料を使い、受付から出荷準備までを実施します。取引条件の確認、担当者への問い合わせ、検品、記録作成を含めて、どの作業に時間がかかるかを測ります。

机上で「一日40件ならできる」と合意しただけでは、処理能力を実証したことにはなりません。逆に、一件だけ素早く処理できても、同じ速度を一日中維持できるとは限りません。

実際の顧客への通知や配送が行われないよう、本番環境への影響を防いだ方法で試してください。

訓練後は、不足した資料、判断できなかった事項、処理が詰まった工程を記録し、代替運用表と復帰条件を更新します。計画を作ったことより、使って見つかった課題を解消することが重要です。

まとめ――「会社が戻った」を、処理できる量と納期で説明する

受注システムが動くこと、最低限の出荷を再開できること、通常の納期と業務量へ戻ることは、分けて確認しましょう。

今回の計画づくりで、まず確かめたいのは、自社の一日の注文量と、システムが使えない場合に出荷まで処理できる量です。

その差が分かれば、どの条件を制限する必要があるか、何人の応援が必要か、どの工程を先に改善するかを考えられます。さらに、停止中に増える未処理を、復旧後にどう減らすかも計画できます。

「システムは復旧しました」だけでなく、「この商品を、この件数まで、この納期で扱えます」と説明できる状態を目指してください。

そのための準備は、IT担当者だけの仕事ではありません。営業、受注、倉庫、経理、保守会社、配送会社など、業務をつなぐ関係者が、それぞれ必要な条件を確認する取り組みです。

バックアップやシステムの復旧手順に加え、代替運用の処理能力と、通常運用へ戻す条件を整えること。それが、事故が起きても、引き受けた仕事に責任を持って対応するための備えになります。

ライトハウスコンサルタントでは、現状診断やインシデント対応机上演習を通じて、経営者・管理職・担当者の判断、連絡、復旧方針の確認を支援しています。自社の業務をどこまで続けられるか、どの条件で再開するかを整理したい場合は、ご相談ください。

投稿タグ
, , , , , , , , , , , , ,