アサヒグループのサイバー攻撃と受注停止｜中小企業の手作業BCP

2025年9月29日に発生したアサヒグループのサイバー攻撃では、日本で管理するシステムに障害が生じ、受注・出荷と顧客対応に影響が出ました。その後の公式発表では、受注・出荷システムの停止中に手作業で対応を続け、電子受注と物流業務を段階的に戻した経緯が説明されています。

この事例から中小企業が学ぶべきことは、侵入を防ぐ対策だけでなく、システムを安全のために止めた場合でも、注文・在庫・出荷・請求をどうつなぐかを事前に決めることです。この記事は公表された事実と一般企業向けの提案を分け、停止当日の判断、手作業での注文管理、復旧後の照合、安全な再開、30日間の準備を具体的に整理します。

アサヒグループの内部手順を推定したり、個々の対策が同社の被害を必ず防げたと断定したりはしません。自社の製品、契約、法令、システム構成に合わせ、情報システム担当、現場責任者、経営者、必要に応じて外部専門家が最終判断してください。

アサヒグループのサイバー攻撃で何が起きたのか

大企業へのサイバー攻撃は、情報システム部門だけの出来事ではありません。受注、在庫確認、出荷、問い合わせ対応まで止まると、商品を届ける仕組みそのものが揺らぎます。2025年にアサヒグループで起きた事案は、そのつながりを具体的に考える材料です。ここでは報道の推測を混ぜず、同社が公表した時点ごとの事実を確認します。そのうえで、自社の事業継続計画に移せる論点を分けて整理します。

2025年9月29日のアサヒグループホールディングスの初報は、サイバー攻撃を原因とするシステム障害が日本国内の事業に影響し、国内グループ会社の受注・出荷業務と、顧客相談窓口を含むコールセンター業務が停止したと説明しています。当時は復旧時期の見通しを示していませんでした。初報の「個人情報や顧客データの外部流出は確認されていない」という記述は、あくまでその時点の調査結果です。後の調査で判明したことまで否定するものではありません。

その後の2026年2月18日付の調査結果と再発防止策によって、事案の輪郭は更新されました。同社によると、9月29日午前7時ごろに障害が発生し、調査過程で暗号化されたファイルを確認。同日午前11時ごろ、被害拡大を抑えるためネットワークを遮断し、データセンターを隔離しました。初報だけを読んで現在の被害像を語ると、事実を取り違えます。事件を扱う記事では、必ず発表日と確認時点を併記する必要があります。

侵入から暗号化までの経過を時系列で読む

同社の調査では、具体的な侵入日時は特定できなかったものの、障害発生の約10日前に、攻撃者がグループ拠点のネットワーク機器を経由してネットワークへ侵入したことが判明したとしています。その後、主要データセンターに入り、パスワードの脆弱性を突いて管理者権限を奪取。不正に得たアカウントで内部を探索し、主に業務時間外に複数のサーバーへの侵入や偵察を繰り返したとみられる、という説明です。9月29日にランサムウェアが一斉に実行され、ネットワークに接続された複数のサーバーと一部のパソコン端末のデータが暗号化されました。

この説明から読み取れるのは、侵入と暗号化が同時ではなく、一定の間隔があったことです。ただし、「侵入の約10日前」という公表表現から、特定の日時、特定の製品の欠陥、攻撃者の所属、侵入時の具体的な設定値まで断定してはいけません。ネットワーク機器を経由したという事実と、「どの製品のどの脆弱性が唯一の原因だったか」という話は別です。同社の公表にない技術的詳細を、一般的なランサムウェア事例から埋めると誤情報になります。

一方、事業継続の観点では、この間隔は重要です。侵入を完全に防ぐことだけを前提とせず、権限の不自然な利用、普段と異なる時間帯の横断的なアクセス、複数サーバーへの連続接続などを検知し、広がりを止める設計が必要だからです。ただし、これは同社の環境に当てはまった検知ルールを推定しているわけではありません。公開事実から、自社で検討すべき一般的な管理課題を抽出したものです。

「侵入経路」「被害拡大」「業務停止」を混同しない

一つの事案でも、問いは三つあります。最初にどこから入られたのか。入られた後、どこまで権限や通信が広がったのか。被害を封じ込めるために、どの業務を止めざるを得なかったのかです。アサヒグループの公表では、侵入に使われた経路と、管理者権限の奪取や内部探索、ランサムウェアによる暗号化が説明されています。同時に、拡大防止のためにリモートアクセス、拠点間、クラウドとの専用回線やインターネット回線を遮断し、データセンターを隔離したことも示されています。

その結果、データセンターの全システムを停止し、業務システムにアクセスできなくなりました。バックアップの健全性を保つため、バックアップシステムも一時停止したと説明されています。ここで重要なのは、業務停止を単純に「攻撃でシステムが壊れたから」とだけ捉えないことです。感染や不正アクセスを広げないための安全上の判断が、利用可能なシステムの範囲をさらに狭める場合があります。原因調査、封じ込め、復旧準備と業務再開は、互いに制約し合う工程です。

実務上は、障害時のシステム停止を「悪い判断」と決めつけず、どのリスクを抑えるために何を止め、代わりにどの業務をどう続けるかを事前に設計することが必要です。例えば、受発注システムを遮断すべき状況でも、紙、電話、独立した通信環境などによる代替経路が定義されていれば、最低限の供給を続けられる可能性があります。逆に代替経路の権限や記録方法が曖昧だと、誤出荷や二重受注、後日の照合作業に追われます。これらは同社の実際の代替手順を示すものではなく、自社のBCPを点検するための例です。

初報と調査完了時点では「情報漏えい」の意味が変わる

初報では個人情報の外部流出は確認されていませんでした。しかし2026年2月の公表では、ゼロトラストモデルへの移行前の一部端末から情報の一部が窃取されたことが確認され、従業員と取引先関係者の情報について確認件数が示されています。一方、データセンター内の個人情報については流出の可能性があるものの、インターネット上に公開された事実は確認されていないとされています。「漏えいが確認された情報」と「漏えいのおそれがある情報」を同じ件数として扱うべきではありません。

同社は2025年9月30日に個人情報保護委員会へ速報、10月8日に続報、11月26日に確報、12月10日に追加報告を行ったと説明しています。この流れは、インシデント直後の情報が未確定でも、調査と報告を継続し、新しい事実に合わせて公表を更新する必要があることを示します。被害の有無を早く断言したくなる場面ほど、「現時点で確認できていない」と「存在しない」を区別することが大切です。自社の事故広報でも、調査中の範囲、確認済みの範囲、次に更新する時期を分けて記載すると、取引先が行動を判断しやすくなります。

具体的な通知対象や件数は公表の更新で変わり得ます。二次記事で古い数字を固定的に引用するより、該当する人は同社の最新の案内を確認してください。本稿は、件数の大きさで不安をあおるのではなく、受注・出荷の停止と復旧に何が必要だったかを中心に扱います。

何が公表され、何は断定できないか

事例を実務に使う前に、事実と推測の境界線を置きます。公式発表で確認できるのは、国内事業への影響、ネットワーク機器を経由した侵入、パスワードの脆弱性を突いた管理者権限の奪取、ランサムウェアの実行、複数サーバーなどの暗号化、封じ込めのための広範なネットワーク遮断、受注・出荷システムの停止と手作業対応です。これらは同社の調査結果として参照できます。

反対に、公表文だけで「従業員の一通のメールが原因」「バックアップがなかった」「多要素認証を導入していなかった」「すべての商品が完全に出荷できなかった」「特定の攻撃グループが唯一の実行者」とは言えません。後述する社内チェック項目にメール対策やバックアップを含める場合も、それはこの事案の未公表の弱点を示すためではなく、一般に備えるべき論点として扱います。攻撃者の主張や流出サイトの掲載だけを公式確認と同列に扱わないことも重要です。

この整理をしておくと、対策が特定企業への後知恵の批判になりません。自社への問いは「なぜあの会社が防げなかったか」ではなく、「自社で同じ種類の停止が起きたら、何時間後に誰が受注と出荷を再開できるか」です。被害に遭った企業の調査結果を読み、未確認事項には踏み込まず、確認可能な業務影響からBCPの設計を始める。それが事例記事の健全な使い方です。

受注・出荷への影響から見る事業継続の課題

システムを復旧することと、取引先へ商品を通常どおり届けられることは同じではありません。アサヒグループは2026年2月の公表で、商品供給に直接関係する受注・出荷システムが障害発生後に停止し、手作業による対応を続けたと説明しています。電子受発注システムによる受注は、グループ食品で2025年12月2日から、ビールと飲料で同月3日から再開しました。配送のリードタイムに残っていた制限も2026年2月までに通常化し、物流業務全体が正常化したとしています。

この日付の読み方には注意が必要です。12月の電子受注再開は、9月から12月まで一切の商品供給が止まったという意味ではありません。同社は手作業による対応を続けたと明示しています。また電子受注が再開しても、配送時間や出荷可能品目が直ちに平時の状態へ戻ったとは限りません。公表文では、取り扱い品目数を順次拡大すると説明し、物流全体の正常化を翌年2月としています。復旧には複数の段階があり、どの段階を「再開」と呼ぶかで取引先の期待が変わります。

受注システムを失うと、販売現場の何が困るか

受注システムは注文を入力する画面だけではありません。取引先から届いた注文を受け取り、商品コード、数量、納品先、希望日、価格条件、在庫、倉庫、配送便などの情報と結び、出荷指示へ渡す役割を持ちます。システムが使えないと、注文を「受け付けたか」、在庫を「確保したか」、いつ「出荷できるか」を一つの画面で確認しづらくなります。電話やメールで注文を受けても、最新の在庫と出荷能力に照らした約束ができなければ、取引先には不確実な回答しか返せません。

この段落は一般的な受発注業務の構造を示すもので、アサヒグループの内部システムの仕様を説明するものではありません。自社で点検する際は、自分たちの受注処理を「入口」「確認」「承認」「出荷指示」「配送」「請求」に分け、どこが同一システムに依存するかを可視化します。注文書を紙で受けられても、出荷指示を発行できなければ商品は動きません。倉庫から出せても、配送先や便を正しく確定できなければ誤配の危険が増えます。見かけ上の受注再開と、履行できる受注の再開は区別すべきです。

特にBtoB取引では、納品予定が取引先の販売計画や製造計画に組み込まれています。自社だけの納期遅延では終わらず、取引先の店舗、物流センター、製造ライン、販促予定にも波及します。だからこそBCPでは、復旧するシステムの順番をIT部門だけで決めません。事業部門が「どの注文を確実に処理すれば、どの顧客への供給を守れるか」を先に決め、技術側とすり合わせます。

「手作業で続ける」を具体的な業務設計へ落とす

手作業という言葉は便利ですが、実際には受付チャネル、受付時間、担当者、記録様式、優先順位、承認者、取引先への回答方法、後日システムへ戻す手順を決めなければ動きません。例えば電話注文を代替経路にするなら、誰が電話番号を案内し、通話中にどの項目を復唱し、どの注文番号を発行し、同じ注文がメールでも届いた場合にどう重複を消すかを決めます。Excelへの記録なら、共有場所、版管理、アクセス権、個人情報の扱い、停電時の保存先まで検討が必要です。

実務では「注文を受ける能力」と「配送できる能力」を別々に計測します。前者は一日あたり処理できる件数、必要項目の欠落率、二重登録率、問い合わせへの回答時間。後者は出荷可能な品目、倉庫の作業量、配送便、リードタイム、納品先ごとの制約です。受注件数を増やすだけで出荷能力を超えてしまえば、約束を守れない注文が積み上がります。反対に出荷可能でも、取引先から注文を確実に受け取る経路がなければ供給は進みません。

緊急時の優先順位は、平時に関係者間で合意しておくべきです。社会的な必要性、商品特性、在庫の賞味期限、代替品の有無、契約上の納期、取引先の影響を評価する枠組みを作り、恣意的に担当者が判断しないようにします。具体的な優先順位は各社の取引条件と商品性質に依存します。本稿からアサヒグループの実際の優先順位を推定することはできません。自社のBCPに記載する場合は、営業、物流、法務、顧客対応の責任者で合意し、必要なら取引先とも共有します。

復旧は「安全確認→連携→受注→配送」の段階で考える

同社は復旧にあたり、外部専門機関と協力し、安全性が確認されたバックアップからシステムを復旧したと説明しています。影響を受けたサーバーは再構築後に健全性を確認し、フォレンジック調査の結果を踏まえた対策を実施。健全性が保証されたシステムから段階的に再開しました。外部システムとのデータ連携も、健全性を確認したものから順次再開しています。これは、単に電源を入れて画面が表示されれば業務を再開できるわけではないことを示します。

受注・出荷業務では、まずシステムとデータが安全かを確認し、次に取引先や物流委託先とのデータ連携が正しく動くかを確認します。その上で新しい注文を受け、在庫引当、出荷指示、配送情報の受け渡し、実績の反映を試します。どこか一段階でも未確認なら、限定的な再開にとどめ、対象商品や取引先を絞る判断が必要です。自社の復旧計画も、システム名の一覧ではなく、「この検証を通ればどの業務を再開できる」という完了条件で書くと実行しやすくなります。

復旧時の大きな課題は、手作業期間に積み上がった注文と、復旧後にシステムへ入る新規注文の照合です。同じ注文が複数経路で入っていないか、出荷済みなのに未出荷と記録されていないか、請求額や納品日が食い違っていないかを確認しなければなりません。これも一般的な業務継続の論点で、同社の内部で実際に発生したミスを示すものではありません。BCPでは、注文ごとの一意な識別子、受付時刻、受付者、承認者、出荷状況、復旧後の突合担当をあらかじめ定義しておくと、手作業からシステムへ戻すときの混乱を抑えられます。

取引先への説明は「できること」と「まだできないこと」を分ける

受注停止が起きたとき、取引先が知りたいのは技術的な攻撃名だけではありません。注文は受けられるか。既に受けた注文の扱いはどうなるか。どの商品を、いつ、どの数量だけ出せるか。問い合わせはどこに送ればよいか。次回の状況更新はいつか。この問いに答えられないと、取引先は自分たちの在庫や販売計画を調整できません。コールセンターの停止も同時に起きた今回の初報は、通常の問い合わせ窓口まで使えなくなる状況を想定する必要性を示しています。

自社の発信では、障害の範囲を把握する前に「すべて通常どおり」と言わないことが重要です。一方で、分かるまで沈黙するのも取引先に負担をかけます。例えば「新規の電子注文は停止中」「既存注文は確認中」「優先度の高い案件は指定窓口で手動受付」「次回更新は何時」といったように、事実、暫定対応、未確定事項、次の更新時刻を分けます。システム復旧見込みがないなら、根拠の薄い日時を約束せず、「見通し未定」と明記します。

同社の初報も、復旧時期の見通しはないと述べていました。この慎重さは顧客の不安を残すかもしれませんが、後で破る可能性の高い約束をするより誠実です。発信の質を上げるには、広報担当だけでなく、受注・物流・情報システム・法務の承認を短時間で得る緊急時の連絡系統を用意します。問い合わせ窓口が停止した場合の代替窓口を一つに集約し、担当者ごとに説明が食い違わないよう同じ更新文を共有します。

売上影響の数字だけで全体像を語らない

2026年2月の同社公表には、2025年10〜12月の累計売上金額の前年比や、12月時点の取り扱い品目数も記されています。ただし、その数字だけを切り取って「サイバー攻撃が売上を何％減らした」と断定することはできません。比較対象の年の状況、市場環境、商品ごとの供給、季節性など、因果関係に必要な情報が別途あるためです。公表値は、業務への影響を考える手がかりにはなりますが、被害額の確定値として転用しないほうが正確です。

自社で測るべき影響も、単純な停止時間だけではありません。手動処理に必要だった人員と残業、注文を受けられなかった件数、納期の延長、代替輸送、取引先との個別調整、問い合わせ増加、復旧後のデータ照合、顧客への説明、外部調査費用などを分類します。直接費用と機会損失、確定したものと推計値を分けて記録すれば、次年度の対策投資を判断しやすくなります。ここでも、アサヒグループの内部費用や損失を本稿が推定しているわけではありません。

この事例から得るべき結論は、攻撃の技術的封じ込めと同時に、受注・出荷という事業の中枢をどの水準で続けるか決める必要がある、ということです。次の章では、この公開事実を自社のチェックリストと復旧訓練へ落とし込む方法を扱います。まずは自社の重要業務を一つ選び、ITシステムが停止した日に「誰が、どの帳票で、何件まで、どの顧客へ、どの納期を約束できるか」を具体的に答えられるか確かめてください。

受注・出荷システムが止まった日に実行する手作業BCP

アサヒグループホールディングスは、2025年のサイバー攻撃後、顧客への商品供給に直結する受注・出荷システムが停止し、手作業による対応を続けたと公表しています。電子受発注の再開は一部事業会社で同年12月初旬となり、配送リードタイムの通常化は2026年2月までかかりました。ここから読み取るべきことは「バックアップさえあれば即日元どおりになる」ではありません。情報システムの復旧と、受注・在庫・出荷という業務の回復は別の工程です。以下は同社の実際の運用手順を再現したものではなく、この公表事例とIPAのランサムウェア教訓集を踏まえて、中小企業が自社用に設計する手作業BCPの提案です。

サイバー攻撃を疑う段階では、通常の障害対応のように「別のパソコンで同じネットワークへつなぎ直す」「共有フォルダの古いデータをとりあえず開く」といった迂回を、現場判断で行わないでください。攻撃範囲を広げたり、証拠やバックアップの健全性を損なったりするおそれがあります。隔離する範囲や代替通信手段は情報システム責任者とインシデント対応チームが判断し、現場には安全と確認された手段だけを通知します。業務部門の役割は、その範囲で必要最小限の受注・出荷を維持し、すべての判断を記録することです。

最初の30分：業務を止める線と続ける線を決める

最初に「何を継続するか」より「何を停止するか」を決めます。注文を受けても在庫を確かめられず、配送会社との連携も見通せないなら、確約できない納期を答えてはいけません。現場リーダーは受注・在庫・倉庫・配送・請求の各責任者に、利用可能な端末、紙の帳票、電話、FAX、独立した通信回線の状態を確認します。ただし、使える機器と安全な機器は同じではありません。情報システム部門の許可が出るまで業務用端末や外部媒体を新たに接続しない、という線を明確にします。

次に、経営責任者または代行者が「手作業モードへの切り替え」を宣言します。宣言には開始時刻、対象拠点、受け付ける注文の種類、承認者、顧客向けの案内文、次回更新時刻を含めます。口頭だけでは夜勤や別拠点へ伝わりません。安全な連絡経路が確保できるなら同じ文書を関係者へ配り、通信が使えなければ紙で掲示し、受け取った人の署名または確認記録を残します。完成条件は、現場の全員が「受け付ける注文」「出荷しない商品」「例外の承認者」を同じ言葉で答えられることです。

社内の通常メールやチャットが影響範囲に含まれる可能性もあります。代替手段はあらかじめ登録した連絡先一覧と、独立性を確認した電話などから選びます。障害時に届いた「臨時連絡先はこちら」というメッセージを無条件に信じてはいけません。なりすましや送金詐欺が重なるおそれがあるため、重要な連絡は既知の番号に折り返して確認します。

当日中：注文の入口を一本化し、受付番号を振る

電話、FAX、営業担当への口頭依頼、ECサイトからの通知を別々に処理すると、同じ注文が二重に登録されます。代替運用中は受付窓口を原則一つに集め、受付簿の採番責任者を決めます。採番は「日付・拠点・通し番号」など既存システムの番号と混ざらない形式にします。例えば「M-20261030-TK-001」のような仮番号を使用し、本復旧後の正式な受注番号との対応欄を空けておきます。番号形式は自社の既存体系と重複しないよう事前に確認してください。

最低限の紙の注文票には、仮受付番号、受付日時、受付者、顧客コードまたは識別情報、注文者名と折り返し先、商品コード、数量、希望納期、配送先、支払条件の確認状況、注文を受けたチャネル、在庫確認者、出荷承認者、顧客への回答日時を記します。個人情報を含むため、紙は施錠保管し、複写枚数と持ち出し先を管理します。詳細な顧客台帳を無許可の私物端末や個人向けクラウドへ移すことは、業務継続ではなく新たな情報漏えいリスクです。

在庫数がリアルタイムで分からない場合は、前日までの安全な確定値、現物棚卸し、既に引き当てた数量を別々に記録します。「前日末に10個あった」だけで10個の新規注文を受けてはいけません。先行受注や別倉庫での引当があるかもしれないからです。確度を「現物確認済み」「記録上のみ」「未確認」の三段階で表示し、未確認の商品は納期を約束しないと決めておきます。商品の重要度だけでなく、返品・廃棄の難しさ、法令上の管理、温度管理、顧客との契約条件も優先度に反映します。

注文票は「受付」「在庫確認」「出荷承認」「実際の発送」の四つの状態に分けます。受付だけで出荷済みと扱わないことが、代替運用の最も重要なルールです。書き損じは修正液で消さず、訂正者・日時・理由が分かる方法で残します。番号の欠番も保管し、後から抜けた注文を検索できるようにします。受付終了時には採番の開始番号と終了番号、未処理件数、キャンセル件数を責任者が照合します。

優先順位は「大口順」ではなく、被害を減らす条件で決める

すべての注文を平常時と同じ速度で処理できないなら、出荷の優先順位を明文化します。単純な売上金額順は、納期遅延が顧客の操業停止につながる品目や、賞味期限・温度管理のある品目を後回しにするおそれがあります。経営者、営業責任者、物流責任者が、契約上の義務、顧客への影響、代替品の有無、在庫確認の確度、配送の実現性を併せて判断します。優先順位を担当者の勘に任せず、同じ条件なら同じ判断になる表を作ってください。

区分	判断の例	現場での扱い	承認者
最優先	停止すると顧客の重要業務に直接影響し、在庫と配送手段を確認できる	数量を限定して受け付け、出荷前に二人で照合する	営業・物流の両責任者
条件付き	需要は高いが在庫や納期の確度が低い	仮受付にとどめ、納期の確約は保留する	部門責任者
一時停止	商品確認や安全な配送ができず、誤出荷の影響が大きい	新規受付を止め、再開予定の更新時刻を伝える	経営責任者または代行者

この表は例であり、業種や契約によって基準を入れ替えます。例えば医療・食品・危険物のように別の安全管理が必要な商品は、紙の伝票があるだけで出荷を許可できません。品質保証部門や法令対応担当者が必須要件を確認します。判断に迷う注文は「出荷を急ぐ」のではなく「誰が、何を確認すれば出せるか」を記録し、その条件を満たすまで止めます。

出荷前に三つの情報を突き合わせる

手作業では転記ミスと二重出荷が増えます。出荷前に注文票、現物または安全と確認された在庫記録、配送伝票の三点を照合します。品番、数量、配送先、指定日、温度帯などの必須項目を、作業者と別の確認者が指差しまたは読み上げで確認し、両者の名前と時刻を残します。配送伝票を作れない場合、独自の紙伝票を使えるか、委託先の受託条件を満たすかを事前に契約先と確認します。運送会社のシステム側も止まっているなら、自社だけが紙に戻っても荷物は流れません。

発送を見送る場合も、理由を「システム停止」だけで終わらせず、在庫未確認、顧客情報未確認、配送手段なし、品質確認待ちのいずれかに分類します。翌日の担当者がそのまま作業を引き継げるよう、残作業と次の確認予定時刻を注文票に書きます。締め処理では、出荷承認済み件数と配送会社へ実際に引き渡した件数を比べ、差があれば個票まで戻って確認します。

顧客へは「確定したこと」と「未確定のこと」を分けて伝える

顧客には、システム障害の発生、影響を受けるサービス、注文受付の暫定方法、出荷可否を確認する方法、次回の情報更新時刻を伝えます。原因や復旧時刻をまだ確認できないなら「調査中」と明記します。攻撃者の手口、個人情報流出の有無、全注文の納期を推測で断定してはいけません。対外文面は広報・法務・経営責任者と統一し、営業担当ごとに違う約束をしないようにします。

特に、既に受けた注文が未出荷なのか、注文自体が受付簿へ入っていないのかは顧客にとって大きく違います。「注文番号が手元にある場合」「番号がない場合」の問い合わせ経路を分け、重複注文を避けるため、再注文の前に照合を依頼します。連絡の履歴には、日時、相手、説明した内容、約束した次回連絡時刻を残します。顧客への連絡が遅れるなら、その事実も社内の未処理リストに載せて追跡します。

復旧後の照合と再開判定：二重出荷・請求漏れを残さない

システムが起動した瞬間に通常運用へ戻すと、紙の注文票と復旧したデータの両方から同じ商品を出荷したり、片方の売上だけが請求に乗らなかったりします。アサヒグループは、健全性が確認されたバックアップから復旧し、サーバー再構築後の確認を経て、健全性を保証したシステムから段階的に再開したと説明しています。これは「手作業分を一括投入すれば終わり」という話ではありません。本節の照合方法は同社の実施内容を示すものではなく、一般企業が運用手順として準備する提案です。

復旧の判定者と、業務再開の判定者を分ける

情報システム部門は、システムとデータが安全に使えるかを判断します。営業・物流・経理は、その環境で業務を再開しても注文、在庫、出荷、請求が一致するかを判断します。両方の承認が出るまで平常運用へ戻しません。例えばサーバーが動いても、障害直前の注文履歴が欠けていれば、再開前に紙の伝票と突き合わせる必要があります。逆に、注文データがそろっていても侵害範囲や接続経路の安全確認が終わっていなければ、本番への再接続は待つべきです。

再開判定表には、最低でも次の六項目を設けます。①使用する端末・ネットワークの安全確認、②復旧データの基準時刻、③手作業期間に受けた注文票の総数、④出荷実績と配送会社側記録の照合、⑤在庫差異とその保留処理、⑥顧客への案内文と問い合わせ窓口です。各項目に責任者、根拠となる帳票、未解決の差分、承認日時を付けます。どれか一つでも「不明」のままなら、再開範囲を限定し、未解決の注文だけは手作業の追跡を続けます。

復旧データの基準時刻は非常に重要です。例えばバックアップが障害発生前日の23時時点なら、その後からシステム停止までの受注はバックアップに載っていない可能性があります。対象時間帯を明示して、メール、電話メモ、配送会社の受領記録、顧客の注文控えを照合します。ただし侵害のおそれがある端末やメールを現場が勝手に開かず、調査担当者が安全と判断した経路で情報を取得します。

仮受付番号を「正式注文・出荷・請求」に一対一で結び付ける

紙の仮受付番号ごとに、復旧した正式受注番号、出荷伝票番号、請求番号を一つの台帳で結び付けます。最初に仮受付簿の全件を読み込み、「正式注文に既に存在」「未登録」「重複候補」「キャンセル」「判断保留」に分けます。存在している注文は再入力せず、数量と配送先が一致するか確認します。未登録だけを承認付きで追加入力します。重複候補は二人の確認が済むまで出荷停止にします。仮受付番号を消してしまうと後で顧客から問い合わせがあっても追跡できません。

照合は件数だけでは不足します。「100件受けて100件登録した」でも、一件が二重で一件が抜けている可能性があります。商品コード、数量、顧客、配送先、日付、金額を個票で照合し、差異は理由と修正者を記録します。担当者の自己確認だけで終わらせず、別担当者が承認する仕組みが必要です。大量の注文を扱う場合は、差異リストを出す集計ツールを使ってもよいですが、侵害調査が終わった安全な環境と承認済みのデータだけを用います。

出荷済みかどうかは自社の出荷チェックだけで判断せず、配送会社への引き渡し記録、倉庫の搬出記録、顧客の受領情報を可能な範囲で突き合わせます。引き渡し済みでシステム未登録なら、出荷実績を正しく登録して請求につなげます。システム登録済みで現物が出ていないなら、顧客への連絡と再出荷の判断が必要です。誤出荷の可能性があるときは、同じ商品を再度出す前に顧客と配送会社へ確認し、二重配送を防ぎます。

在庫差異と金額差異を別々に扱う

注文は合っていても在庫が合わない場合があります。手作業中の現物数、復旧システム上の帳簿数、配送中の数量、返品予定数を別に集計し、差の原因を注文票までたどります。差が説明できない商品は「販売可能在庫」に戻さず、調査中として引き当て対象から外します。食品ならロット、賞味期限、保管条件も確認します。金額面では、単価、値引き、送料、税区分、支払条件を照合します。数量が合うだけで請求を確定しないでください。

経理部門は、請求済みなのに出荷記録がないもの、出荷済みなのに請求対象から外れたもの、返品・キャンセルが反映されていないものを別々のリストにします。月末締めが迫ると「とりあえず一括請求したい」と考えがちですが、誤請求は顧客対応と信用回復にさらに時間を使います。締め日や請求予定を変更する場合は取引条件を確認し、顧客へ早めに案内します。法令・契約上の義務が関係する部分は経理・法務担当者が個別に判断します。

架空ケース：地方の食品卸が三日間システムを使えない場合

ここからは説明用の架空のケースであり、アサヒグループの実績や実際の対応ではありません。従業員45人の食品卸A社は、受注管理システムと倉庫管理システムを利用しています。月曜午前にランサムウェアの疑いが生じ、安全確認のためシステムを停止しました。営業責任者は当日中に紙の仮受付簿を作り、取引先からの新規依頼を電話一本に集めました。物流責任者は現物確認ができた定番品だけを出荷候補にし、温度管理が必要な一部品目は、品質保証担当者が保管記録を確認するまで保留します。

初日に新規注文60件の問い合わせがありました。うち35件は現物と配送枠を確認して受付、15件は在庫の確度が足りず仮受付、10件は出荷条件を満たさず受付停止とします。この数字は説明用の設定です。翌日は仮受付分の顧客へ納期を再連絡し、受け付けた35件について注文票と倉庫搬出票を二人で照合します。配送会社へ実際に引き渡した件数を別欄へ書き、引渡し未了の注文を残します。三日目にシステムが使えるようになっても、すぐ全件を入力せず、安全な復旧データの基準時刻を確認します。

もし復旧データに初日の注文35件が入っていないなら、仮受付番号ごとに正式番号を発行します。仮受付15件のうち顧客が取り消したものは「キャンセル」として記録し、注文に変換しません。出荷済みの20件は配送会社の引渡し記録と照合し、請求対象へ反映します。残る15件は在庫と配送日を再確認してから出荷判断します。こうして、全注文の状態が一件ずつ説明でき、未処理一覧がゼロまたは担当・期限付きで管理されて初めて、通常モードへ戻します。

このケースで重要なのは、「三日間止まっても35件出せた」という数値ではありません。受付番号、受付・承認・引渡しの状態、顧客への回答、復旧時の正式番号をつないだ点です。もし初日から各営業担当者が個別の紙にメモを取り、倉庫へ口頭で指示していれば、復旧後に注文が一件も漏れていないと証明するのは難しくなります。BCPは出荷を続けるためだけでなく、後から整合性を説明できる状態を守るための手順でもあります。

平時の訓練は「システム停止」で終えず、復旧照合まで行う

年に一度、受注画面が使えないという想定だけを読み合わせても、紙の注文票が実際に回るかは分かりません。半日程度の訓練で、架空の注文を電話で受け、受付番号を振り、在庫を確認し、出荷を見送る判断を含めて模擬処理します。訓練後には仮受付票を復旧想定の台帳へ入力し、二重登録・漏れ・在庫差異を検出できるかまで試します。配送会社や重要顧客と連絡訓練を行う場合は、事前に訓練と明示し、本物の注文や緊急連絡と混ざらないようにしてください。

評価指標は「何分で切り替えを宣言できたか」「最初の顧客案内まで何分か」「仮受付番号の欠番・重複は何件か」「未処理注文を担当者付きで把握できたか」「復旧照合で差異を何件検出したか」です。訓練で判明した不備は、手順書の修正者と期限を決めます。連絡先一覧が古い、紙の帳票の保管場所が不明、承認者不在時の代行者がいない、といった欠陥は数値以上に重要です。IPAの教訓集も、侵害調査、復旧、業務継続、外部公表の判断には事前準備が必要だと示しています。事前に決めるべきことはシステムの復元方法だけではありません。

参照：アサヒグループホールディングス「サイバー攻撃被害の再発防止策とガバナンス体制の強化について」（2026年2月18日）、IPA「ランサムウェア被害から学ぶ教訓集」（2026年10月16日更新）。確認日：2026年10月30日。

業務再開を支えるIT・情報管理の安全確認

システムが再起動したことと、受注・出荷業務を安全に再開できることは別です。アサヒグループの2026年2月の公表では、外部専門機関による調査、健全性を確認したバックアップからの復旧、影響を受けたサーバーの再構築と確認、追加対策を経て、健全性が保証されたシステムから段階的に再開したと説明しています。これは同社が公表した対応の要約であり、個々の企業に同じ技術構成を求めるものではありません。しかし「動いたから即時に全接続を戻す」という判断を避ける点は共通します。

中小企業なら、再開判断を技術・データ・業務・取引先の四つに分けてください。技術面では侵入経路の調査、疑わしいアカウントの停止、必要なパッチ・設定変更、ログ取得の確認が要ります。データ面では復元点が侵害前か、バックアップが改ざんされていないか、受注や在庫のデータがどの時点まで正しいかを確かめます。業務面ではテスト注文から出荷指示、送り状、請求書まで一連の処理を通します。取引先面では再開する注文経路、残る制限、二重送信の扱いを伝えます。四つのどれかが未確認なら、全量再開は見送ります。

再開の品質ゲートを一枚にする

復旧会議で「大丈夫そうです」という感想だけが出る状態を防ぐため、対象システムごとに品質ゲートを作ります。欄は「対象」「確認する事実」「確認した人」「証拠の場所」「未了のリスク」「再開範囲」「次の見直し時刻」です。例えば受注システムなら、外部接続、アカウント、注文入力、在庫引当、出荷連携、監査ログを別々に確認します。物流会社のシステムへ送るデータだけ未確認なら、顧客からの注文入力を先に再開しても、出荷連携は止めるという選択ができます。全社一括で「復旧済み」と付けないことが重要です。

このゲートには経営者の承認だけでなく、現場とITの確認を入れます。経営者は顧客への供給と安全性の残余リスクを判断できますが、実際に送り状が作れるかは物流現場が試さないと分かりません。逆にIT担当だけで顧客への納期を確約することもできません。承認者を増やすための形式ではなく、異なる情報を一か所で突き合わせる場にします。決定の理由を残せば、後で新しい証拠が出たときも、どの前提を見直すべきか追えます。

バックアップを戻す前に何を決めるか

バックアップが存在するだけでは復旧可能とは言えません。保存先に攻撃者が触れた可能性、複製の独立性、復元に必要な鍵やアカウント、復元時点以降に受けた注文をどう補うかを確認します。攻撃を受けた環境にそのまま上書きすると、残っている痕跡や悪意ある設定を見逃すおそれがあります。隔離した検証環境で復元できるかを確認し、必要に応じて専門家と再構築方針を決めます。バックアップの健全性が判断できない場合は、復旧を急ぐより証拠保全と調査を優先します。

復元点が前日の夜なら、そこから停止までに受けた注文、停止中の紙や電話の注文、復旧後に再送された注文が重なります。この三つを時系列で照合し、顧客番号、発注番号、商品、数量、納品先、希望日で同一性を見ます。発注番号がない電話注文は、受付日時と担当者、折り返しで確認した相手を記録します。完全自動で判定できない場合は、重複の可能性がある注文を保留キューに分け、現場の担当者が相手へ確認します。「多少重複しても後で返品」と考えると、配送費、食品ロス、請求取消、信用低下が増えます。

在庫も同じです。倉庫にある実数、停止前のシステム在庫、手作業で出荷した数、返品・破損分を別々に記録します。数字が一致しない商品を「在庫あり」と公開すると、受けられない注文が増えます。まず高回転の商品や欠品時の影響が大きい商品から棚卸しし、確認できたSKUだけ販売可能にします。品目数を戻す速度より、誤った数量を流さないことを再開条件にします。対象品目と更新時刻を顧客対応窓口も見られるようにしてください。

外部連携は一本ずつ戻す

EC、EDI、倉庫管理、配送会社、請求、メール、クラウドストレージは、それぞれ異なる接続先と権限を持ちます。内部の受注システムが安全でも、古いAPIキーや侵害されたPCが接続したままでは再開時に再侵入する可能性があります。外部連携を一度に戻さず、最も必要な経路から、権限と監視方法を確認して開けます。テストデータで正しい宛先へ送信されるか、余分な情報が出ていないか、エラーを現場が検知できるかを確かめます。失敗したら切り戻せるよう、接続先、実施時刻、担当者、切断操作を記録します。

特にメールを止めていた間は、未配信の注文確認や自動通知が一度に流れる場合があります。テストでは一件の通知を送って、二重送信、旧テンプレート、古い価格、誤った宛先がないか確認します。取引先側の受信が正常かも、事前に登録した窓口で照合します。停止中の連絡はどこまで再送するのかを決めないまま自動配信を再開すると、顧客が複数の納期案内を受け取ります。再開前に未送信キューを数え、必要分だけ送る方針を業務部門が承認します。

「漏えいはない」と早く断定しない

アサヒグループの初日の公表では、当時確認された範囲で個人情報や顧客データの外部流出は確認されていないと説明され、その後の調査で一部の端末情報の窃取と、サーバー内の個人情報の流出可能性が公表されました。これは調査段階で分かる事実が変わる例です。最初の時点で分からないことを「ない」と断定せず、「現時点で確認できていない」「調査中」「次の更新予定」を分けて伝える必要があります。自社で事故が起きた場合も、通知の要否や期限は扱う情報と法令、契約によって異なるため、法務担当と専門家に確認してください。

漏えいの調査では、個人情報の種類、保管場所、アクセスできたアカウント、疑わしい転送の痕跡、ログの保管期間を整理します。証拠がないことと、漏えいがないことは同じではありません。ログが短期間で消えるシステムや、取得していなかった外部サービスについては、判断の限界を明記します。顧客への説明に必要な事実、確認中の事項、今後の連絡手段を文書で分ければ、担当者ごとの回答がぶれにくくなります。公表文の推測を埋めるために原因を決めつけないでください。

中小企業が30日で備える実行計画

大企業と同じ予算や専門組織を持たなくても、受注・出荷が止まったときに何を守るかは今日決められます。最初の30日は、ツールを買うことより、止まる業務と決定者を可視化することに使います。IPAのランサムウェア被害教訓集は、暗号化が分かった時点では時間的余裕がなく、調査、復旧、業務継続、外部公表を事前に用意する必要があると示しています。以下の工程はその考え方とアサヒグループの公表から、一般企業向けに編集した提案です。同社の内部手順を再現したものではありません。

1週目：止まる業務と連絡先を一枚にする

営業、経理、物流、ITの担当者を集め、注文の入口から請求までを一枚に描きます。受注はECだけか、メール、電話、EDI、代理店もあるか。注文が入ったあと、どのシステムで在庫を引き当て、誰が出荷指示を出し、どこで納品情報と請求情報が作られるか。各段階が止まったときに使える代替手段と、その代替も同じネットワークに依存するかを確認します。クラウドにあるから必ず独立して使える、紙に印刷してあるから最新である、という前提は置きません。

成果物は「重要業務一覧」と「緊急連絡先一覧」です。前者には業務、システム、責任者、止められる時間、代替手段、依存先を記載します。後者には経営者、IT担当、委託先、取引銀行、主要顧客、物流会社、法務・広報の窓口を記載し、社内システムが使えない場所にも保管します。個人の携帯番号を一覧で扱う場合は、閲覧権限と更新日を管理します。電話番号が古ければBCPは機能しません。登録済みの別経路で本人へ確認してから配布します。

2週目：手作業の受注を実際に通す

実在の顧客データを使わず、架空の注文を一件作ります。受付担当が紙または独立した環境で受け、在庫担当が引当を確認し、出荷担当が伝票を作り、経理担当が請求の記録を残します。大切なのは、紙の様式がきれいかではなく、重複発注、数量変更、欠品、キャンセル、納品先変更が起きたときも記録と承認が残るかです。個人が自由に表計算ファイルを複製すると、どの版が正本か分からなくなります。様式を一つにし、発行者、連番、更新時刻、保管先を決めます。

訓練では、注文を受けてから顧客に約束できる時刻まで測ります。想定では一日100件処理できると思っていても、電話で内容を復唱し、在庫を目視確認し、二人で出荷を承認すると処理件数は大きく下がるかもしれません。そこで、停止中に受けられる件数と品目を実測し、平時の受注量とのギャップを経営者へ示します。需要が処理能力を超える場合、優先する顧客・商品・地域の基準を事前に決めます。担当者がその場の声の大きさで順番を変えないためです。

3週目：バックアップと復元を試す

IT担当は、受注、顧客、在庫、請求のデータがどこにあるかと、各バックアップの時刻、保存期間、操作できる人を確認します。重要なのは、ファイルを開けるかだけではありません。隔離環境で復元し、架空注文を検索し、数量と顧客名が一致するか、業務アプリから参照できるかを試します。復元に必要な認証情報を同じシステムにだけ保管していたら、停止時に取り出せません。独立した管理方法を用意し、利用時の承認と記録を決めてください。

復元試験の記録には、復元開始・終了時刻、使用したバックアップの日時、失われ得るデータの期間、エラー、必要だった人員、顧客対応への影響を書きます。復元できなかった場合は「バックアップあり」と報告せず、原因と再試験日を決めます。委託先が復元する契約なら、連絡窓口、対応時間、復元先、費用の発生条件を確認します。災害用のバックアップがランサムウェア時にも使えるとは限らないので、侵害が疑われる環境へ接続せずに検証できるかも聞きます。

4週目：止める判断と顧客への説明を訓練する

机上訓練では「朝9時に受注システムとメールが使えず、10時には倉庫も接続を止める必要がある」という状況を置きます。経営者は何を止めるか、IT担当は何を隔離するか、営業は顧客へ何を約束しないか、物流は手作業をどこまで許すかを決めます。次に「復元データは前日23時、紙注文が20件、顧客からの再送が15件」と条件を変え、二重出荷をどう防ぐかを試します。実際の取引先に訓練メールを誤送信しないよう、架空の宛先とデータを使用します。

終了後は、うまくできたことだけでなく、決められなかった判断を残します。「社長不在時に誰が出荷停止を決めるか」「取引先の連絡先が社内メールにしかない」「委託先の緊急窓口が不明」「手作業の処理能力を超えた注文の断り方がない」といった穴は、訓練で発見する価値があります。一件ごとに担当者と期限を付け、次の訓練で閉じたか確認します。BCPを完成した文書として棚に置かず、業務と連絡先の変更に合わせて更新します。

予算が限られるときは何から支払うか

投資の順序は、製品名や広告ではなく、止まると顧客へどれだけ影響するかで決めます。第一に現状を把握できない問題を減らします。どのサービスと端末が受注、倉庫、請求に使われているかが分からなければ、障害時の判断も、更新すべき機器の選択もできません。第二に、外部から入れる経路と管理者権限を絞ります。使っていない接続を閉じ、必要な利用者に多要素認証を設定し、退職者や委託終了者の権限を消します。第三に、バックアップと復元試験へ時間を確保します。データが守れないと業務再開はできません。

その上で、ログの保管、異常の監視、端末保護、ネットワークの分離、外部専門家との契約を、事業への影響と運用できる人員に合わせて選びます。EDRを買っても通知を見る人がいなければ十分な対策とは言えません。高度な仕組みが導入できない企業でも、取引先マスターの保全、代替連絡先、承認ルール、定期訓練は始められます。逆に手作業だけを整えて侵入経路を放置してよいわけでもありません。技術対策と事業継続を別予算で競わせず、一つの停止リスクを減らす投資として判断します。

成果を何で測るか

「対策を実施した」という自己申告ではなく、停止時に動けるかを測ります。例えば、重要なシステムと管理者を特定できる割合、緊急連絡先がつながる割合、架空注文の手作業処理時間、復元試験の成功率、復元点から失う可能性のあるデータ量、顧客へ最初の状況連絡を出すまでの時間です。数値に固定の合格ラインはありません。自社の出荷量、顧客との契約、取扱商品の性質から、目標と許容できない限界を決めます。測定結果は月次または訓練後に経営者へ示し、未達の原因と次の変更を記録します。

扱う商品によっては、安全や法令の確認が優先されます。食品ならロットや賞味期限、医療関連なら法令上の記録、個人向け配送なら宛先情報の保護を、手作業中も外してはいけません。この記事のサンプル台帳をそのまま使う前に、自社の必須項目を追加してください。「とにかく出荷を続ける」だけでは、回収や誤配送を招きます。安全上の確認ができない商品は、受注を止める判断をあらかじめ決めます。

よくある質問：クラウドなら受注は止まりませんか

止まらないとは言えません。自社のクラウドサービスが正常でも、利用者のアカウント、社内のネットワーク、外部連携、倉庫の端末、メールが停止すれば、注文を出荷までつなげられない可能性があります。また事故時に安全のため接続を止める判断もあります。クラウドかオンプレミスかの二択ではなく、業務が依存する経路を端から端まで確認してください。クラウド提供事業者の障害情報、データの取り出し方法、認証の復旧手順も契約時に確認します。

よくある質問：バックアップがあれば手作業の準備は不要ですか

不要ではありません。安全な復元点の特定、調査、再構築、データ照合には時間がかかります。復元が完了するまでの受注や顧客連絡、既に受けた注文の扱いを決めないと、その時間に事業が止まります。手作業を長期間続けられるとは限らないため、処理できる件数と品目を訓練で把握し、限界を超えたら顧客へどのように知らせるかまで用意します。復元能力と代替業務能力は両輪です。

よくある質問：アサヒグループと同じ対策を採用すべきですか

事案の規模、既存のネットワーク、委託先、業務量が違うため、そのまま採用するべきではありません。公表から学べるのは、侵入や暗号化に対して封じ込めを行い、事業停止を前提に手作業を続け、健全性を確認しながら段階的に戻したという判断の構造です。自社では先に守るべき業務、依存するシステム、顧客へ約束できる条件を定義し、IPAの資料をもとに専門担当者と計画します。事件の侵入経路を読んだだけで「自社は同じ機器を使っていないから安全」と結論づけないでください。

技術面の初動はランサムウェア被害の初動対応、企業全体の優先順位はセキュリティ対策の30日計画で整理しています。サプライチェーン上の連絡・権限管理は委託先のセキュリティ確認表も参照してください。

出典・確認日：2026年10月30日
アサヒグループホールディングス：サイバー攻撃によるシステム障害発生について（2025年9月29日）
アサヒグループホールディングス：サイバー攻撃被害の再発防止策とガバナンス体制の強化について（2026年2月18日）
IPA：ランサムウェア被害から学ぶ教訓集
IPA：不正アクセスによる漏えい等の事案を踏まえた速やかな対策

AIの業務利用を安全に学びたい方へ

停止時の連絡文、確認表、議事録をAIで作る場合でも、顧客情報を入力してよいか、内容を誰が確認するか、公開前にどの事実を裏付けるかを決めてください。WithAIではAIの実務活用を学べます。個別の事故対応や法的判断、復旧作業の代行ではありません。自社の担当者とセキュリティ専門家の判断を優先してください。