サイバー攻撃のニュースで「受注を再開しました」と聞くと、ひとまず元に戻ったように感じます。しかし、注文できる商品が限られ、配送には通常より時間がかかるのであれば、顧客にとってはまだ復旧の途中です。
ランサムウェアの復旧期間は、データを戻す速さだけでは決まりません。使えるバックアップが残っているか、攻撃者が侵入した範囲を調べられるか、安全な環境を用意できるか。そして、受注から出荷までの業務をどの水準へ戻せるかで変わります。
アサヒとアスクルの公表資料を読むと、こうした問題が具体的に見えてきます。この記事では、両社の対応経過と復旧期間の調査から、何が復旧を妨げるのか、経営者や責任者が事前にどこまで確かめておくと役立つのかを整理します。
ランサムウェアの復旧期間はどれくらい？調査と事例を分けて読む
JIPDECの「企業IT利活用動向調査2026」を分析したレポートでは、ランサムウェア感染から復旧できた企業の7割以上が、検知から1か月以内にデータやシステムを復旧しています。一方、1か月を超える側の回答も約4分の1あります。
| 復旧できた企業の回答区分 | 割合 |
|---|---|
| 1か月～2か月以内 | 16.5％ |
| 2か月～3か月以内 | 6.3％ |
| 3か月以上 | 3.1％ |
これは感染企業のうち、復旧できた企業についての結果です。復旧できなかった企業には、復旧をあきらめた時点までの期間を別に尋ねています。「多くが1か月以内」という結果だけから、自社もその期間で戻ると見込むのは難しいでしょう。
さらに、調査が尋ねるデータ・システムの復旧と、顧客への商品供給が通常に戻る時点は、同じ尺度ではありません。企業の復旧報告では、何が再開したのかを分けて読むと状況を把握しやすくなります。
アスクルの事例：バックアップの被害と物流システムの停止が重なった
アスクルは2025年10月19日にランサムウェア攻撃を検知し、受注・出荷業務を停止しました。12月12日の報告では、物流システムが暗号化され、同じデータセンター内のバックアップファイルも暗号化されたこと、バックアップファイルの削除も確認されたことを説明しています。
同社の物流センターは、自動倉庫設備や商品を取り出すピッキングシステムなどを使う高度な自動化構造です。その動作を担うシステムの停止が、出荷業務の全面停止につながりました。
ここで重要なのは、商品が倉庫に残っていても、いつもの能力で出荷できるとは限らない点です。棚から商品を取り出し、注文と照合し、送り先を確認して発送するまでの仕組みが止まれば、人が一部を代替できても処理量や取り扱える商品に制限が出ます。
再開は、対象商品と拠点を絞って進んだ
| 日付 | 公表された対応・再開範囲 |
|---|---|
| 2025年10月19日 | 攻撃検知、ネットワーク遮断、受注・出荷業務停止 |
| 10月29日 | FAX注文による出荷トライアルを2拠点・ケース品37アイテムで開始 |
| 11月7～10日 | トライアルを最大7拠点・ケース品230アイテムへ拡大 |
| 11月12日～12月3日 | Web受注を含む次のトライアルを開始・拡大 |
この経過は「サイトが開いたか」だけでは、サービスの復旧状況を測れないことを示しています。注文方法、商品、出荷拠点、処理能力には、それぞれ再開条件があります。
なお、同社は基幹業務システムや顧客向けECサイトなどに侵害の痕跡がなかったとも報告しています。すべてのシステムが暗号化されたと理解するのは正確ではありません。直接被害を受けていないシステムでも、物流との連携が止まることでサービスを提供できなくなる場合があります。
アサヒの事例：安全確認を経て、受注と配送が段階的に戻った
アサヒグループでは2025年9月29日に障害が発生し、データセンターの隔離などを実施しました。2026年2月18日の公表資料によると、バックアップの健全性を保つためバックアップシステムも一時停止し、外部専門機関とシステムごとの侵害状況を調査しています。
復旧では、安全性を確認したバックアップを使い、影響を受けたサーバーを再構築した後に健全性を確認しました。外部システムとの連携やメールも、確認を経て順に再開しています。
| 再開の段階 | 公表された経過 |
|---|---|
| 手作業による対応 | システム停止中も受注・出荷を手作業で継続 |
| 電子受発注の再開 | グループ食品は2025年12月2日、ビール・飲料は12月3日 |
| 配送リードタイムの通常化 | 2026年2月までに通常化し、物流業務全体を正常化 |
| 取り扱い商品の拡大 | 2月18日の発表時点では、出荷可能な品目を順次拡大する方針 |
「物流正常化」と「すべての商品が従来どおり供給できること」も、同じ意味ではありません。この表は発表時点の経過を示すもので、その後も制限が残り続けたとするものではありません。
なぜサイバー攻撃の復旧に時間がかかるのか
1．戻すためのデータが、攻撃者に使えなくされる
バックアップの暗号化や削除は、単に保存データを失う問題ではありません。どの時点のデータが残っているか、別の場所に利用できるコピーがあるか、欠けた情報を再入力できるかを調べるところから復旧を組み直すことになります。
アスクルの公表は、その問題が実際に復旧を遅らせた例です。一方、アサヒは健全性を確認したバックアップから復旧しています。両社をまとめて「バックアップがすべて破壊された」と説明することはできません。
保存場所、権限、復元テストの確認は、既存記事のバックアップの実効性を確認する方法で詳しく整理しています。
2．壊れていない部分まで、安全かどうかを確認する
通常の障害でも復旧が難しいことはあります。攻撃で特に問題になるのは、見た目には動いている環境やアカウントも、既に侵害されているかもしれないことです。
侵入に使われた認証情報を残したまま環境を戻せば、攻撃者が再びアクセスする余地が残ります。復旧には、影響範囲の調査と並行して、認証情報や接続経路を見直し、安全な環境を整える作業が加わります。
アスクルはネットワーク遮断後にも外部クラウドサービスへの不正アクセスが発生したと公表しています。社内の通信を止めたことと、盗まれた認証情報による外部サービスへのアクセスを止めたことは別でした。
3．安全なシステムを用意しても、つながる業務が戻るとは限らない
例えば、受注システムが使えても、在庫の確認、倉庫への作業指示、配送伝票の発行がつながらなければ、以前と同じ量を出荷できません。これは両社の非公開事情を推測したものではなく、業務の依存関係を理解するための説明例です。
復旧を進める際は、個々のサーバーの稼働だけでなく、受注から配送まで一連の取引が成立するかを確認することになります。停止中の手作業記録をどう反映するか、重複や漏れがないかといった業務側の確認も関係します。
4．被害の調査とサービス再開を、同時に進める
JPCERT/CCのFAQでは、調査・証拠保全と復旧を計画的に進めることが説明されています。すぐに初期化すると、被害範囲や侵入原因を確認するための記録を失うおそれがあります。
これは全調査が終わるまで一切再開できないという意味ではありません。調査対象を保全しながら別の安全な環境で優先業務を戻すなど、専門家と進め方を調整する場面があります。工程を順番待ちの一本線として扱うと、実際の復旧の姿を捉えにくくなります。
復旧を早める備えは、どの問題を減らすのか
一般的な「対策を強化する」という報告より、何が使えなくなった場合に、何で代替できるのかを確かめるほうが、自社の復旧見通しを考えやすくなります。
| 長期化につながる問題 | 事前に確かめる材料 | 確かめても残る不確実性 |
|---|---|---|
| 本番とバックアップが一緒に侵害される | 削除・変更できる権限の分離、別環境からの復元実績 | 被害発覚前にどこまで侵害されたか |
| 認証・接続環境を信用できない | 管理者情報、構成図、記録の保存、再構築の担当・方法 | 調査で判明する実際の影響範囲 |
| 重要な業務が連携先とともに停止する | 受注・出荷・請求に必要なシステムと外部接続の対応表 | 接続相手の状況や個別の被害 |
| 手作業へ移しても量を処理できない | 代替方法で扱える商品・件数・人員を試した結果 | 停止が長引いた場合の疲弊や滞留 |
代替運用があるだけで安心するのではなく、通常の何割を処理できるのかが分かると、受注制限や顧客説明を考える材料になります。すべてを人手で続けることが難しければ、優先する取引や商品を絞る選択も考えられます。
事故時の連絡・判断の基本はインシデント対応の整理につながります。個別の被害では、社内だけで復旧期限を約束するより、調査結果と利用可能な環境を専門家と確認し、見通しを更新するほうが現実的でしょう。
ランサムウェアの復旧についてよくある質問
バックアップがあれば、数日で復旧できますか？
保存データが使えることに加え、復元先、認証、アプリケーション、外部連携、業務確認がそろうかで変わります。実際に試した復元時間は有用ですが、攻撃後の調査や環境の再構築まで含む保証にはなりません。
身代金を払えば、早く元に戻りますか？
復号用の情報が得られても、データが正しく戻るか、侵入経路や盗まれた認証情報を解消できるかは別の問題です。支払いだけから復旧を保証することはできません。JPCERT/CCのFAQでも、身代金支払いの問題を説明しています。
大企業の数か月という事例は、中小企業にも当てはまりますか？
そのまま期間を当てはめることはできません。大企業は連携や物流設備が複雑な一方、小規模企業では復旧担当者や予備環境が限られることがあります。事例から確認するのは日数の予言ではなく、自社にもある復旧の障害です。
「復旧した」より、何がどこまで戻ったかを共有する
両社の公表資料から見えるのは、同じランサムウェア被害でも、使えるデータ、認証の侵害、物流の依存関係、再開できる範囲が異なることです。
事前の備えで短縮を目指せる部分と、被害が起きてから調べる部分も分かれます。責任者が現場と共有したいのは、「何日で復旧するか」だけでなく、「今どの業務を動かせて、通常運用へ戻すために何が残っているか」という見通しではないでしょうか。
参考資料
- JIPDEC：企業IT利活用動向調査2026・セキュリティ編 — 2026年4月16日。図28の復旧期間。復旧成功・断念の回答対象を区別しています。
- アスクル：ランサムウェア攻撃に関する調査結果と安全性強化策 — 2025年12月12日。PDF1～4ページの経過、物流・バックアップの被害、初動。
- アスクル：サイバーセキュリティ — 2026年8月4日更新。対応経過と新しい構成でのサービス提供。
- アサヒグループ：再発防止策とガバナンス体制の強化 — 2026年2月18日。封じ込め・調査・段階的復旧・物流の正常化。
- JPCERT/CC：侵入型ランサムウェア攻撃を受けたら読むFAQ — 調査・証拠保全・復旧と身代金に関する説明。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント