要旨

2025年10月19日、オフィス用品通販大手のアスクルがランサムウェア攻撃を受け、WMS（倉庫管理システム）を含む基幹システムが全面停止しました。翌日には無印良品・ロフト・ネスレ日本など3PLとして物流を委託していた取引先のECサービスも出荷停止に追い込まれました[1]。

アスクルの2024年5月期の売上高は約4,716億円——単純計算で1日あたり約10億〜13億円の売上機会損失が発生し続けた計算です[2]。WMSが復旧したのは12月17日——約2か月間にわたって手作業での細々した出荷しかできない状態が続きました[3]。

DXが進んだ物流ほど、WMSが止まると現場の手足も止まります。「230アイテムしか出荷できない」状態から紙と手作業への回帰を強いられた現場は、デジタル依存の脆さを身をもって示しました[4]。

本記事では、アスクル事案の詳細を解剖し、エンジニアが設計段階から組み込むべき「事業を止めない」インフラ可用性設計の考え方を、BCP・DR・アーキテクチャの観点から整理します。

注意事項：本記事は教育目的のセキュリティ情報共有を目的としています。

記事本文

1. アスクル事案の詳細——WMSが止まると「何も動かない」

1-1. WMSとは何か——物流の「神経系」

アスクルの事案を理解するには、まずWMS（Warehouse Management System：倉庫管理システム）がいかに物流の中心にあるかを把握する必要があります。

WMS が担う機能と、停止時の影響：

WMS の主要機能：
  ├── 入荷管理：届いた商品をどの棚に置くか指示する
  ├── 在庫管理：何がどこにあるか（ロケーション管理）
  ├── ピッキング指示：注文に対してどの棚から何を取るか指示する
  ├── 出荷管理：梱包・ラベル発行・配送業者への引き渡し
  └── 在庫引き当て：注文を受けたとき「この在庫で対応可能か」を判断

WMS が停止すると：
  ├── 「商品がどの棚にあるか」がわからない
  │    → 倉庫内を人が歩き回って探すことになる
  ├── ピッキング指示が出せない
  │    → 何をどこから取ればいいか、誰も一覧できない
  ├── 在庫の引き当てができない
  │    → 注文を受けても「在庫があるかどうか」確認できない
  └── 出荷ラベルが発行できない
       → 梱包してもどこへ送ればいいか宛名が出力できない

アスクルの場合：
  10月19日の停止後、出荷できたのは
  → 箱単位の約230アイテム
  → 医療衛生など一部単品約500アイテム のみ[4]
  （通常数十万件/日の出荷に対してほぼゼロに等しい）

アスクルのWMSは、商品の種類や在庫位置を把握する他、出荷時にピッキングするため在庫として保管している商品を動かす機能などを担っていた。[3]

出典：日経クロステック「アスクルがシステムによる出荷再開 WMSを再構築、倉庫の自動化設備も公開」（2025年12月17日）[3]
https://xtech.nikkei.com/atcl/nxt/column/18/00001/11360/

1-2. 事案のタイムライン

アスクル株式会社へのランサムウェア攻撃は、2025年10月19日に発生しました。攻撃により、アスクルの基幹システムが暗号化され、法人向け通販「ASKUL」および個人向け通販「LOHACO」の受注・出荷システムが全面停止しました。[1]

アスクル事案のタイムライン：

2025年10月19日（日）午前
  外部からの不正アクセスによる異常を検知
  → ランサムウェア感染の疑いのあるシステムを切り離し
  → ネットワーク遮断を実施
  → 受注・出荷システムが停止

2025年10月20〜21日
  無印良品・ロフト・ネスレ日本が
  ネットストアの受注停止を公表
  → アスクルのASKUL LOGISTに物流を委託していたため

2025年10月末
  「データが外部流出した可能性が極めて高い」と発表
  → 二重恐喝型ランサムウェアによる被害

2025年11月初旬
  手作業による限定的な出荷を継続
  → 通常の数十万件/日に対して極めて少量のみ対応可能

2025年12月17日
  WMSを再構築して一部の拠点で出荷再開
  → まず東京DC・関東DCの2拠点から順次拡大

攻撃から完全復旧まで：約2か月（10月19日〜12月中旬）

1-3. サプライチェーン被害の波及——「自社だけの問題」ではなかった

子会社のASKUL LOGISTが請け負う、3PL（サード・パーティー・ロジスティクス）と呼ぶ他社商品の配送事業にも影響した。同事業の顧客には良品計画やロフト、ネスレ日本などがある。このため良品計画が運営する無印良品やロフトのネット通販の出荷も停止した。[5]

出典：日経クロステック「ランサム攻撃で出荷を停止したアスクル、システム再構築で12月に本格復旧へ」（2025年11月20日）[5]
https://xtech.nikkei.com/atcl/nxt/column/18/01157/111800147/

アスクル自身の損失にとどまらず、物流を委託していた複数企業のECサービスも連鎖的に停止しました。「1社の物流システム停止が、複数の大手ブランドのEC事業を止める」——これが現代の物流DXの脆弱性です。

2. 「紙と手作業への回帰」が示すDX依存の脆さ

10月末、アスクルは「データが外部流出した可能性が極めて高い」と発表。11月初旬時点で出荷できたのは、約230アイテム（箱単位）、医療衛生など一部単品約500アイテム。この"紙と手作業への回帰"は、DX化が進んだ物流の脆さを可視化した象徴的な出来事と言えます。[4]

出典：物流業界入門「アスクル物流障害の深層」（2025年11月30日）[4]
https://butsuryu-media.com/entry/2025/11/30/090524

通常のアスクルは高度に自動化・デジタル化された物流オペレーションを誇っています。それが一度システムが落ちると、紙と手作業で230アイテムしか出荷できない状態まで機能が落ちてしまいました。

これはアスクルの失敗ではなく、DXによって高度化したシステムが「非常用の手順」を失いやすいという普遍的な問題を示しています。ITが便利になればなるほど、ITなしで動く方法が失われていきます。

3. 機会損失の定量化——「止まることのコスト」を数字で知る

アスクルの2024年5月期の売上高は約4,716億円で、そのうちASKUL事業が約3,585億円、LOHACO事業が約368億円を占めています。全面的な業務停止により、1日あたり約10億円から13億円程度の売上機会損失が発生していると推定されます。[2]

出典：サイバーセキュリティ総研「アスクルが受けたランサムウェア攻撃」（2025年10月31日）[2]
https://cybersecurity-info.com/column/askul-cyber-attack-202510/

1日10億〜13億円、2か月で約600億〜780億円——これは売上機会損失の推計であり、実際には復旧コスト・システム再構築費・情報漏洩対応・信頼損失も加わります。

システム停止コストの構成要素：

直接的コスト：
  ├── 売上機会損失（1日10〜13億円 × 停止日数）
  ├── 手作業対応のための人件費増加
  ├── システム再構築費用
  └── 情報漏洩対応（調査・通知・コールセンター）

間接的コスト：
  ├── 顧客離脱（2か月間注文できなかった顧客の流出）
  ├── 取引先（無印良品・ロフト等）との関係への影響
  ├── ブランド・信頼性の毀損
  └── 株価・投資家への影響

比較：
  情報セキュリティへの投資「年間数百万〜数千万円」
  vs
  停止2か月の機会損失「数百億円」

  この非対称性が「事前投資の経営判断」を難しくする
  ——しかし事後の損失規模を見れば、投資対効果は明白

この「事前投資と事後損失の非対称性」は、可用性設計への投資を経営判断として正当化する重要な根拠です。

4. 可用性設計の基本概念——RTO・RPO・HAとDR

物流・WMSの可用性設計を議論する前に、基本概念を整理します。

4-1. RTO と RPO——「どれだけ速く・どれだけ戻せるか」

可用性設計の2大指標：

RTO（Recovery Time Objective：復旧時間目標）
  → 「障害発生から何時間以内にシステムを復旧させるか」
  → アスクルの場合: 約2か月（60日以上）
  → 目標とすべき値: WMSなら数時間〜24時間以内

RPO（Recovery Point Objective：復旧時点目標）
  → 「どの時点のデータまで戻せれば許容できるか」
  → 1日前のバックアップから復旧 → 1日分のトランザクションが失われる
  → アスクルの場合: WMSを「今まで同じシステムを再構築」[3]
    → バックアップデータの完全性が保たれていたことが前提
  → 目標とすべき値: リアルタイム〜数分以内（在庫データは最新性が重要）

アスクル事案が教えること：
  RTO と RPO の目標値を事前に定め、
  それを達成するためのアーキテクチャを設計していなかった場合、
  「再構築」が唯一の選択肢になってしまう。
  再構築には「同じシステムを作り直す時間」がかかる。

"BCPは「事業を止めない仕組み」、DRは「止まった後に戻す仕組み」です。両者は相互補完の関係にあり、DR設計はBCPの実効性を高めるうえで不可欠な要素です。"
— KSW Blog, 「クラウド障害・停電対策のススメ——中小企業のためのBCP・DR設計ガイド」[6]
https://www.ksw.co.jp/media/column/a46

4-2. HA（高可用性）と DR（災害復旧）の使い分け

HA（High Availability：高可用性）vs DR（Disaster Recovery：災害復旧）：

HA の考え方：
  「そもそも止まらないようにする」
  → 複数サーバーのクラスタリング
  → ロードバランサーによる負荷分散
  → Active-Active または Active-Standby 構成
  → 自動フェイルオーバー（障害検知→切り替えが自動）
  目標: ダウンタイムを「ゼロ」に近づける（数秒〜数分以内の切り替え）

DR の考え方：
  「止まっても素早く戻せるようにする」
  → 別リージョン・別データセンターへのレプリケーション
  → バックアップからの復旧手順
  → データの地理的冗長化
  目標: RTO・RPO を事前に定義し、その範囲内に収める

ランサムウェア攻撃への適用：
  HA は有効か？
  → 通常障害（ハードウェア故障・ネットワーク断）には有効
  → ランサムウェアには「条件付きで有効」
    ※ 暗号化が Active システム上で発生すると
      Standby も同時に感染する場合がある
    ※ レプリケーションが「暗号化データを同期」してしまう危険
  → ランサムウェア対策には「イミュータブルバックアップ」が必須（別論）

DR は有効か？
  → バックアップが攻撃者の手の届かない場所にあれば有効
  → アスクルがシステムを「再構築」できたのは DR の効果
  → RTO（復旧時間）を短縮するには、
    「再構築」ではなく「事前に用意したDR環境への切り替え」が必要

5. WMS・物流システム固有の可用性設計の課題

5-1. なぜ WMS は「普通の HA/DR 設計」が難しいのか

WMSには、一般的なWebアプリやデータベースには存在しない固有の制約があります。

WMS 可用性設計の固有課題：

課題1: リアルタイム在庫の整合性
  → 「どの棚に何個ある」という状態は1秒ごとに変わる
  → フェイルオーバー時に「どの状態が正しいか」を確定させる必要
  → 「棚A-3-2に商品が5個ある」という状態が
    システム切り替え時に「正確に引き継がれる」ことが必須

課題2: 物理設備との連携
  → WMS はコンベア・ソーター・自動棚（GTP）等の物理設備を制御
  → システムが切り替わったとき「設備も正しく制御できるか」
  → 設備のドライバー・プロトコルが DR 環境でも動作するか確認が必要

課題3: 外部連携の複雑さ
  → ERP（受注）・TMS（輸送管理）・配送会社API・ECシステムとの連携
  → DR 切り替え時にすべての外部連携先も切り替えが必要
  → エンドポイント変更の通知・テストが事前に必要

課題4: データ整合性の複雑さ
  → 「ピッキング中の在庫」「予約済みの在庫」「移動中の在庫」
    といった中間状態のデータをどう扱うか
  → バックアップから復旧すると「中間状態のトランザクション」が消える
    → 「あの棚から取り出した商品が宙に浮く」という状態になりうる

倉庫・物流業界ではECの拡大に伴う業務の増加や、少子高齢化による人手不足といった課題に対応するため、ITを活用した業務効率化や生産性向上に積極的に取り組んでいます。WMSの高度化では、倉庫管理や物流管理、販売管理といったさまざまな業務をデジタル技術の活用で精緻化することで、業務効率化のみならず、顧客満足度の向上など、ビジネスの拡大につなげようという動きが出てきています。[7]

出典：SIOS Blog「デジタル時代を迎えた倉庫・物流・小売業界」[7]
https://bcblog.sios.jp/wms-cloudlift-availability/

5-2. クラウド移行が可用性を高める理由——ただし「移行すれば安全」ではない

オンプレミス WMS vs クラウド WMS の可用性比較：

オンプレミス WMS：
  メリット:
    ├── 自社のネットワーク内で完結（外部依存なし）
    └── カスタマイズの自由度が高い
  デメリット:
    ├── 単一拠点の障害（火災・水害・停電）で全滅する
    ├── 冗長化には設備の二重投資が必要（コストが高い）
    ├── パッチ適用・メンテナンスを自社で実施する必要
    └── スケールアップに時間がかかる（ハード調達が必要）

クラウド WMS（AWS / Azure / GCP 等）：
  メリット:
    ├── マルチ AZ（可用性ゾーン）による自動冗長化
    ├── マネージドサービスによる高可用性（SLA 99.9〜99.99%）
    ├── DR サイトの構築がオンプレより低コスト
    └── バックアップの自動化・地理的冗長化が容易
  デメリット:
    ├── クラウドサービス自体の障害に引きずられる
    ├── インターネット接続が断絶すると操作不能
    └── 移行しただけで「ランサムウェア耐性が上がる」わけではない
       ※ クラウドに移行後も、同一テナント内に侵入されると
         クラウド上のシステムも暗号化される

重要な認識：
  「クラウドに移行すること」と
  「ランサムウェアに対して安全になること」は別の話
  → 認証・アクセス制御・バックアップ設計を合わせて実施しなければ
    クラウドでも同じ被害を受ける

6. 「事業を止めない」ための4層の可用性設計

物流・WMSの事業継続を考えるとき、技術的な HA/DR だけでは不十分です。PAL社のコラムが指摘する「3つのバックアップ（データ・システム・業務）」という考え方が参考になります。

必要な備えは、データを保存しておくこと（データのバックアップ）だけではありません。WMSや基幹システムが動かない状況でも出荷をつなぐ、「3つのバックアップ（データ・システム・業務）」と、ヒト・通信・判断権限まで含めた「二重化」、そして想定外に備える「イレギュラー対応の設計」が不可欠です。[8]

出典：PAL株式会社「物流BCP｜システム停止時も現場を止めない3つの備え」[8]
https://www.pal-style.co.jp/column/logistics-system-backup-duplication-bcp/

この「3つのバックアップ」を軸に、設計を4層で整理します。

物流・WMS の「4層可用性設計」：

Layer 1: データバックアップ
  「データを守る」
  ├── イミュータブルバックアップ（ランサムウェアで消えない）
  ├── 地理的に離れた場所への複製（DR サイト）
  ├── バックアップの定期的な復旧テスト（存在するだけでなく使えるか）
  └── RPO の定義と達成確認

Layer 2: システムバックアップ
  「システムを素早く復旧させる」
  ├── DR 環境の事前構築（本番と同等の環境を別リージョンに用意）
  ├── Infrastructure as Code（インフラ構成をコードで管理し再現可能に）
  ├── フェイルオーバー手順の自動化・テスト済み化
  └── RTO の定義と達成確認

Layer 3: 業務バックアップ
  「システムなしで業務を継続する」
  ← アスクルが最も苦しんだ層
  ├── 手作業による代替フローの事前定義
  │    → 「WMS がなくても最低何件出荷できるか」を事前に設計
  ├── 手作業でも使える在庫リスト（印刷・手書き更新できる形式）
  ├── 優先出荷ルールの事前定義
  │    → 「医療関連品を最優先」という判断が事前にあればすぐ動ける
  └── 手作業オペレーションの定期的な訓練

Layer 4: 組織・コミュニケーションバックアップ
  「判断と連絡ができる体制を維持する」
  ├── 障害時の意思決定権限の事前明確化
  │    → 「誰がネットワーク切断を承認するか」がすぐわかるか
  ├── 取引先への連絡手順の事前準備
  │    → アスクルが取引先（無印良品等）に連絡できたタイミングは翌日
  ├── 社内連絡手段の冗長化（メールが使えないときのコミュニケーション）
  └── プレス・顧客向けの初動コミュニケーションテンプレート

7. 実際のアーキテクチャ設計——Active-Active から Warm Standby まで

WMSの可用性設計には複数のアーキテクチャパターンがあります。コストとRTO/RPOのトレードオフを理解した上で選択します。

可用性設計パターンの比較：

パターン1: Active-Active（最高可用性・最高コスト）
  構成: 複数の本番環境が同時稼働
  RTO: 数秒〜ゼロ（切り替えではなく継続）
  RPO: ゼロ（データは常に同期）
  コスト: 本番環境の2〜3倍
  向いている場面: 分秒を争う決済・金融系

パターン2: Active-Standby（ホットスタンバイ）
  構成: 待機系が常時起動・データは同期
  RTO: 数分（フェイルオーバーに要する時間）
  RPO: 数秒〜数分（同期ラグ）
  コスト: 本番環境の1.5〜2倍
  向いている場面: WMS・ECサイト・ERPなど

パターン3: Warm Standby
  構成: DR環境は起動しているが最小構成で運用
  RTO: 数十分〜数時間（スケールアップが必要）
  RPO: 数分〜数時間（定期レプリケーション）
  コスト: 本番環境の30〜50%程度
  向いている場面: 重要度が高いが RTO 24時間以内で許容できる場合

パターン4: Cold Standby（バックアップからの復旧）
  構成: DR 環境は停止状態・バックアップのみ保持
  RTO: 数時間〜数日（環境を1から起動・復元）
  RPO: バックアップの間隔（1日1回なら最大1日分）
  コスト: バックアップストレージ費用のみ
  向いている場面: 開発環境・重要度が低いシステム

アスクルの推定状況:
  WMS を「再構築」したという事実[3] は、
  DR 環境（Warm/Hot Standby）が用意されておらず、
  Cold Standby 以下の状態だった可能性を示唆
  → だから 2 か月かかった

8. ランサムウェア特有の対策——「フェイルオーバーだけでは不十分」

前章までは「一般的な障害」を想定した可用性設計でした。ランサムウェアには追加の考慮が必要です。

ランサムウェアが従来の HA 設計を無効化するメカニズム：

典型的な HA 構成（Active-Standby）：
  本番データベース（Primary）
      ↕ リアルタイム同期
  待機データベース（Standby）

ランサムウェアが発生すると：
  Primary が暗号化される
      ↓ リアルタイム同期がそのまま動く
  Standby も暗号化データで上書きされる
  → フェイルオーバーしても暗号化されたデータに切り替わるだけ

対策：同期とバックアップの「時間的分離」：

  本番データ
      ↕ リアルタイム同期 → HA（高速フェイルオーバー用）
  Standby
      ↓ 定期スナップショット（1時間おき）
  時系列バックアップ（変更不可・イミュータブル）
  → ランサムウェア発生前のスナップショットに「巻き戻す」

重要なポイント：
  「いつの時点のバックアップが暗号化前か」を特定できる仕組み
  → アクセスログ・変更ログを外部に保存しておく
  → 「暗号化が始まった時刻」を特定できれば
    その直前のスナップショットを選べる

9. 物流 BCP の「10 チェックリスト」

PAL社が提示する「物流 BCP 10 チェック項目」を参考に、WMS を運用するエンジニアが点検すべき項目を整理します。

物流・WMS の BCP チェックリスト：

【データの保護】
  ✅ WMS のデータは毎日バックアップされているか
  ✅ バックアップがランサムウェアで暗号化されない場所に保存されているか
     （イミュータブルストレージ・オフライン媒体）
  ✅ バックアップからの実際の復旧テストを行ったことがあるか（年1回以上）

【システムの冗長化】
  ✅ WMS の RTO（復旧時間目標）と RPO（復旧時点目標）が定義されているか
  ✅ 定義した RTO・RPO を達成できる DR 環境が用意されているか
  ✅ フェイルオーバーの手順が文書化され、誰でも実行できる状態か

【業務の継続性】
  ✅ WMS が使えない場合の手作業フローが事前に定義されているか
  ✅ 「最優先で出荷すべき商品カテゴリ」が決まっているか
     （医療品・緊急性の高い商品など）
  ✅ 手作業フローを実際に訓練したことがあるか

【コミュニケーション】
  ✅ 障害時に取引先・顧客に通知する手順と文面の雛型が準備されているか
  ✅ 社内の障害対応指揮命令系統（誰が何を決定するか）が明確か

10. まとめ——「止まることの損失」を設計の前提に置く

アスクルの事案が示したのは3つの教訓です。

第1の教訓：DXが進むほど、止まったときの影響が大きくなる

WMSが高度化するほど、手作業への切り替えコストが上がります。「システムがなければ何もできない」状態は、便利さの裏返しです。

第2の教訓：サプライチェーンの脆弱性は自社だけの問題ではない

アスクルの停止が無印良品・ロフト・ネスレ日本のEC停止につながりました。物流の外部委託が増えた現代では、「自社のBCP」だけでなく「取引先を含めたBCP」が必要です。

第3の教訓：「止まってから考える」では2か月かかる

WMSを「再構築」しなければならなかったのは、「切り替える先の環境」が用意されていなかったからです。事前に DR 環境を用意し、RTO・RPO を定義し、フェイルオーバーをテストしておけば、停止時間は「2か月」ではなく「数時間」になりえました。

「BCPは「事業を止めない仕組み」、DRは「止まった後に戻す仕組み」です。両者は相互補完の関係にあり、DR設計はBCPの実効性を高めるうえで不可欠な要素です。」
— KSW Blog [6]

可用性設計への投資は「コスト」ではなく「保険」です。アスクルの事案が示した「1日10億円の機会損失 × 60日」という数字を見れば、事前の設計投資の費用対効果は計算するまでもありません。

参考文献

[1] DataClasys. 「アスクルのランサムウェア被害から考えるサプライチェーンリスクと事前の備え」. 2025年11月12日.
https://www.dataclasys.com/column/askul-ransomware-supplychain-resilience_20251111/

[2] サイバーセキュリティ総研. 「アスクルが受けたランサムウェア攻撃 ―物流を止めたサイバー攻撃の脅威―」. 2025年10月31日.
https://cybersecurity-info.com/column/askul-cyber-attack-202510/

[3] 日経クロステック. 「アスクルがシステムによる出荷再開 WMSを再構築、倉庫の自動化設備も公開」. 2025年12月17日.
https://xtech.nikkei.com/atcl/nxt/column/18/00001/11360/

[4] 物流業界入門. 「【アスクル物流障害の深層】ランサムウェア被害から「Web再開」まで」. 2025年11月30日.
https://butsuryu-media.com/entry/2025/11/30/090524

[5] 日経クロステック. 「ランサム攻撃で出荷を停止したアスクル、システム再構築で12月に本格復旧へ」. 2025年11月20日.
https://xtech.nikkei.com/atcl/nxt/column/18/01157/111800147/

[6] KSW Blog. 「クラウド障害・停電対策のススメ｜中小企業のためのBCP・DR設計ガイド」. 2025年.
https://www.ksw.co.jp/media/column/a46

[7] SIOS Blog. 「デジタル時代を迎えた倉庫・物流・小売業界。業務やビジネスを停止させないIT基盤がますます不可欠に」. 2022年6月.
https://bcblog.sios.jp/wms-cloudlift-availability/

[8] PAL株式会社. 「物流BCP｜システム停止時も現場を止めない3つの備え」. 2025年.
https://www.pal-style.co.jp/column/logistics-system-backup-duplication-bcp/

[9] 在庫管理ドットコム. 「物流部門におけるBCP対応の取り組みとは」. 2025年4月.
https://www.zaikokanri.com/column/341/

[10] Logi Today. 「アスクルのシステム障害続く、100人体制で原因究明」. 2025年10月.
https://www.logi-today.com/862858

[11] mono-x Blog. 「クラウドを活用したITの事業継続・災害対策とは？いま見直すべきBCPの新常識」. 2025年.
https://blog.mono-x.com/cloud-bcp-disaster-recovery

[12] さくらのクラウドマニュアル. 「BCP・DR」. 2026年6月30日更新.
https://manual.sakura.ad.jp/cloud/support/bcp-dr.html

[13] KSW Blog. 「クラウドBCP/DR設計入門：災害・障害に強い企業基盤の作り方」. 2025年.
https://www.ksw.co.jp/media/column/a69

[14] 経済産業省. 「サイバーセキュリティ経営ガイドラインVer3.0」. 2023年3月.
https://www.meti.go.jp/policy/netsecurity/mng_guide.html

[15] アスクル株式会社. 「弊社へのサイバー攻撃について（第1報）」. 2025年10月19日.
https://www.askul.co.jp/kaisya/news/2025/1019-1.html

[16] JPCERT/CC. 「インシデントハンドリングマニュアル」. 2025年.
https://www.jpcert.or.jp/csirt_material/

[17] IPA. 「事業継続計画（BCP）サイバー攻撃版策定・運用ガイド」. 2024年.
https://www.ipa.go.jp/security/

[18] AWS. "Disaster Recovery of Workloads on AWS: Recovery in the Cloud." 2021.
https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html

[19] Verizon. "2025 Data Breach Investigations Report (DBIR)." 2025.
https://www.verizon.com/business/resources/reports/dbir/

[20] セキュリティ対策Lab. 「アサヒグループも被害に——製造業を揺るがすランサムウェア攻撃」. 2025年.
https://rocket-boys.co.jp/security-measures-lab/asahi-group-holdings-cyberattack-halts-production-and-impacts-group-companies/