ランサムウェアに備えるバックアップ復元訓練｜RPO・RTOと実行手順

2026年10月30日

ランサムウェア対策で「バックアップは毎日取っています」と答えられても、「最後にいつ、誰が、どの環境へ、何時間で戻したか」まで答えられる企業は多くありません。バックアップが存在することと、攻撃を受けた後に業務を安全に再開できることは別です。必要なのは、隔離した環境で実際に復元し、データの整合性と業務機能を確かめ、所要時間を記録する復元訓練です。

この記事は中小企業の経営者、情報システム担当者、外部委託先との調整を担う人に向けた実務手順です。復元目標の決め方、訓練前の隔離・権限設計、当日の進行表、合否判定、失敗後の改善まで扱います。ランサムウェア被害の初動そのものは企業のランサムウェア初動対応で、受発注停止時の代替運用は受注・出荷停止を想定したBCPで確認してください。本記事は、その先の「戻せるかを平時に証明する」作業に絞ります。

本文の数値例と組織設定は説明用の架空例です。自社の契約、業務停止許容時間、法令、委託契約、保存期間に合わせて調整してください。NIST、CISA、IPAの一次資料を参照し、確認日は2026年10月30日です。

復元訓練の合格条件を先に決める：RPO・RTOと業務の優先順位

復元訓練の最初の問いは「どの製品を使うか」ではなく、「何が、いつまでに、どの状態へ戻れば事業を続けられるか」です。目標が曖昧なままデータをコピーすると、作業者は成功したつもりでも、営業部門は注文を検索できず、経理部門は請求額を照合できないことがあります。訓練の合格条件は技術担当だけで決めず、業務責任者と経営者が合意します。

RPOは「どこまでのデータを取り戻すか」、RTOは「いつまでに業務を戻すか」

RPO（Recovery Point Objective）は、停止前のどの時点までデータを戻せればよいかという目標です。直近の利用可能なバックアップが前日の23時で、障害が翌日15時に起きたなら、最大で約16時間分の更新が復元対象から外れる可能性があります。RTO（Recovery Time Objective）は、対象システムを許容できない影響が出る前に復旧させる目標時間です。NIST SP 800-34 Rev.1はRPOをデータ損失の許容範囲、RTOを業務への影響を踏まえた停止許容時間と説明します。どちらも一律に短くするほどよいわけではなく、業務の重要度と費用を合わせて決めます。

たとえば毎時数百件の注文を受ける企業の受注DBと、月に数回だけ更新する社内規程の保存場所を同じ条件で管理する必要はありません。前者は直近データの差分確認と代替受付が不可欠です。後者は前日分まで復元できれば業務影響が小さいかもしれません。目標は「全社でRPO 1時間」のような標語ではなく、業務ごとに「許容する未反映件数」「代替手段」「再開判断者」まで落とします。

RPOの測定起点も決めます。バックアップジョブが成功を返した時刻ではなく、復元できたデータの最終更新時刻を確認します。DBのトランザクションログや増分バックアップがあるなら、どの更新まで適用されたかを照合します。RTOは「復元ボタンを押してからファイルが開くまで」では不足です。障害を検知してから隔離判断、クリーンな環境の準備、アプリ起動、必要な権限の確認、業務担当による受入れまでを、業務目標と整合する区間で計測します。起点と終点が違う数字を月ごとに比べても改善は見えません。

業務影響から復元順を作る

復元する順番はサーバー台数順でも、容量の小さい順でもありません。受注、出荷、請求、顧客対応など、止まると外部への影響が大きい業務を先に特定します。次に、その業務が依存する認証、DNS、ネットワーク、端末、データベース、ファイル保管、外部APIを図にします。アプリだけを復元しても認証基盤が止まっていれば利用者はログインできません。請求システムだけが動いても元の売上データが欠けていれば請求書を発行できません。

以下は架空の従業員80人の卸売企業が、復元訓練の対象を選ぶための例です。目標値は各社で合意して決めるものであり、業界標準値ではありません。

業務	止まった場合の影響	説明用RPO	説明用RTO	受入れ確認
受注登録	新規注文を処理できない	直近4時間	8時間	未処理注文を登録・検索できる
在庫引当	出荷可否を判断できない	前日締め時点	24時間	在庫数と引当数が一致する
社内共有資料	一部の事務作業が遅れる	前日分	48時間	指定した版を閲覧できる

この例では「受注登録を先に戻す」と決めても、在庫が分からなければ確約回答はできません。暫定運用として受注だけ受け付け、出荷日を未確定として伝える方法を用意します。受注DBの復元成功を業務再開の宣言と混同しないためです。業務責任者は訓練計画書に、復元後に実行する最小の取引シナリオと、再開を認めない条件を記載します。

「成功」の証拠を先に列挙する

合格基準を後から作ると、都合のよい結果だけを採用しがちです。訓練前に、少なくとも四つの証拠を決めます。第一に時間です。検知相当時刻、復元開始、データ利用可能、アプリ利用可能、業務受入れの各時刻を記録します。第二にデータです。事前に選んだ注文番号、更新日時、件数、金額合計、添付ファイルのハッシュなどを照合します。第三に業務です。担当者が読み取りだけでなく、権限に応じたテスト注文の登録・取消し・検索まで試します。第四に安全です。感染した環境とつながらず、復元元と復元先の権限・ログを確認します。

「全部のデータを一件ずつ見る」は現実的でありません。重要度の高い取引、直近更新、例外処理、文字コードの異なるファイル、複数拠点が同時に更新したデータなど、欠損すると痛いサンプルを選びます。総件数だけが一致しても、特定顧客の注文が別の顧客へ紐付いていれば不合格です。サンプル抽出の規則を残し、次回も比較可能にします。

なお、バックアップが存在することは漏えいを否定しません。ランサムウェアでは暗号化と情報窃取が併発する場合もあります。復元訓練は業務を戻す能力の確認であって、侵害範囲の調査や法的通知の要否判断を置き換えるものではありません。実際の事故では、証拠保全と影響調査を並行させ、清潔な復元元を選ぶ判断を専門家と行います。

訓練前の準備と隔離：本番を壊さず、汚染を戻さない

復元訓練は実施方法を誤ると、本番データの上書きや、検証環境からの意図しない通知・課金・外部通信を起こします。したがって、訓練の安全設計そのものが成果物です。CISAのStopRansomware Guideは重要データのオフライン・暗号化バックアップと、利用可能性・完全性の定期的な検証を勧めています。クラウド同期だけでは暗号化されたファイルが同期され得る点にも注意を促しています。製品の「バックアップ成功」の表示だけで訓練済みと扱わない理由です。

復元対象、復元元、復元先を三つに分けて記録する

対象は「業務で必要なもの」を具体名で選びます。顧客DBならデータ本体だけでなく、スキーマ、アプリの設定、暗号鍵の保管手順、認証連携、バッチの設定、必要なソフトウェアの版、ライセンス、DNS切替手順が関係します。ファイルサーバーなら共有権限、更新履歴、特殊文字を含むパス、長いファイル名、世代管理の設定を確認します。復元元はスナップショットID、作成時刻、保管場所、整合性確認の結果で識別します。復元先は本番とは別のネットワーク、別名のホスト、別のアカウントやテナントにし、誤接続を防ぎます。

クラウドの「別のフォルダ」は隔離とは限りません。同じ管理者アカウントで削除・変更できる、同じ同期クライアントで書き換わる、同じ仮想ネットワークから本番に到達できる場合があります。組織が使うサービスの仕様を確認し、バックアップの変更権限と復元の実行権限を分けます。可能なら保存後の変更を制限する仕組みや、日常の認証基盤が侵害されても直ちに全世代が消されない設計を検討します。ただし「不変」「オフライン」の表示だけで安全と断定しません。保護期間、削除権限、管理者の復旧手順を実際に試します。

復元先は、最低限、外部へのメール送信、決済、出荷指示、Webhook、顧客通知、会計連携を無効化または疑似接続にします。試験用のドメイン名と受信先を使い、本番の顧客へ誤通知しないようにします。復元した個人情報を検証環境で扱うなら、アクセス者、保存期間、削除方法、委託先の取扱いを先に決めます。実データが不要なテストでは、ダミーデータまたはマスキング済みデータで足りるか検討します。実データで整合性を試す必要がある場合でも、持ち出しや複製の範囲を最小にします。

「感染前の世代」を選ぶための条件

訓練では説明のために復元時点を決められますが、実際の事故では、最も新しい世代が最も安全とは限りません。侵入から暗号化までに時間差があれば、侵害後のアカウント変更や不正なタスクがバックアップに含まれる可能性があります。復元候補の作成時刻だけでなく、認証ログ、管理者操作、ソフト更新、異常な通信、バックアップジョブの挙動を調べます。証拠が不足すれば「安全な復元点は未確定」と記録し、範囲を狭めた業務再開と調査の両立を検討します。訓練ではあえて一つの世代を不適合にして、次の世代へ切り替える分岐を演習できます。

バックアップの暗号化鍵や認証情報が復元時に読めなければ、媒体が無傷でも戻せません。鍵の保管場所、緊急時に誰が取り出せるか、承認者が不在ならどうするか、退職者のアカウントに依存していないかを確かめます。機密情報を訓練記録に貼り付けてはいけません。記録するのは保管先の管理番号、取得手順の所在、承認ログです。鍵を共有メールや記事原稿へ転記しないでください。

外部委託先との役割と停止条件を紙にする

中小企業ではバックアップ設定をITベンダーが、業務システムを別ベンダーが、ネットワークを社内担当者が管理していることがあります。訓練当日になって「誰が復元ボタンを押すのか」「データ照合の正解を誰が持つのか」を確認していては、時間目標を測れません。開始前に、訓練責任者、技術作業者、業務受入れ責任者、証拠記録者、セキュリティ監視者、緊急停止の判断者を指名します。委託契約に訓練支援が含まれるか、休日対応や検証環境の料金が別途かも確認します。

停止条件は「本番への予期しない接続」「外部宛てメールや注文の送信」「訓練用以外のデータ消去」「マルウェア検知」「時間外の権限昇格」など具体化します。誰かが停止を宣言したら、操作を止め、ログを保全し、変更内容を戻すまでを手順書に書きます。停止条件は失敗を隠すためでなく、実運用の安全を守るためです。万一試験中に本番サービスへ影響が出たら、訓練を続行せず、通常の障害対応手順に切り替えます。

前日までの準備表

確認項目	担当	完了証拠	不備があった場合
対象業務と依存関係	業務責任者	最小取引シナリオと優先順位	対象を絞り、目標を再合意
復元元と世代	バックアップ管理者	媒体ID・作成時刻・権限	別世代または別媒体を選ぶ
隔離した復元先	インフラ担当	到達性確認と誤送信防止設定	接続を遮断し訓練延期
比較用データ	業務担当	件数・取引ID・ハッシュ等	比較表を作るまで開始しない
緊急停止・連絡	訓練責任者	連絡網・判断者・戻し方	当日の作業を見送る

表が埋まっていても、当日利用するアカウントで実際に検証環境へ入れるかを確認します。訓練前の確認で復元そのものをしてしまうと計測が歪むため、接続・権限・容量・通知停止の確認と、実復元を区別します。発見した不足は「準備できていなかった」と記録し、目標時間の計測から除外しません。事故時に同じ不足が起こるからです。

復元訓練の実行手順：検知から業務受入れまでを時刻で追う

ここからは、架空の卸売企業が受注管理システムを対象に行う半日訓練の進め方を示します。これはランサムウェアを本番環境へ投入する訓練ではありません。想定事故を宣言し、隔離済みの検証環境で復元する安全な演習です。実際の事故なら、技術的な証拠保全、侵害経路の調査、関係者への連絡を同時に進め、感染した機器を安易に再接続しません。NIST SP 800-184は、計画、プレイブック、訓練、テスト、改善を組み合わせた復旧能力の検証を勧めています。

開始前に測定範囲と禁止操作を読み合わせる

訓練責任者は開始時刻と想定の障害発見時刻を宣言します。記録係は時刻の基準となる時計を統一し、チャット投稿、チケット、復元ジョブのログを関連付けられるようにします。参加者が「それは本物の事故か、演習か」を取り違えないよう、全ての連絡に訓練識別子を付けます。一方、実際の事故同様に連絡が届かない状況も作りたいなら、メールを使わない代替連絡網を事前に承認したうえで演習します。知らない相手へ偽の被害通知を送ってはいけません。

禁止操作には、本番のバックアップ削除、既存DBへの上書き復元、顧客へのメール発信、本番DNSの変更、決済・出荷APIの発火、認証情報の平文共有を含めます。復元先のアカウント名、ネットワーク、ホスト名を参加者が声に出して照合します。「訓練だから小さなミスは気にしない」では、本番事故時の危険を見逃します。禁止操作へ進みそうになった時点で停止し、どの画面・権限・手順が誤認を招いたかを改善対象にします。

ステップ1：障害を検知し、復元判断へ必要な情報を渡す

想定は「受注画面が開かず、共有フォルダの一部が読めない」です。監視担当はアラートの時刻と内容を記録し、業務担当は最後に正常な注文処理ができた時刻を報告します。訓練では実際に暗号化されたファイルを作る必要はありません。アラート画面と障害シナリオを別途用意し、参加者が「これは単なる障害か、侵害の疑いか」を判断できる材料を与えます。判断に必要なログの場所が分からなければ、その探索時間を記録します。事故時にも同じ時間がかかるからです。

訓練責任者は、システム停止の影響を確認し、復元準備を指示する役割を明確にします。復元が必要かどうかは「サーバーが落ちた」だけでは決めません。利用可能な正本データ、代替運用、感染範囲、安全に戻せる世代の見込みを確認します。未知の侵害が進行中なら、急いで本番へ戻しても再び侵害される可能性があります。訓練では、この判断の情報不足や承認待ちをそのまま記録します。

ステップ2：被害想定環境を隔離し、復元先を再確認する

実事故を想定した演習では、被害を受けたネットワークから検証環境へ通信できないことをネットワーク担当が確認します。隔離とは単にPCの画面を閉じることではありません。管理ネットワーク、バックアップ管理画面、共有ID、VPN、外部連携を含めて到達性を調べます。ただし実事故では、証拠の保全や業務への影響があるため、遮断方法を一律に決めず、組織の初動計画と専門家の判断に従います。訓練では安全に準備した模擬環境だけを操作します。

記録係は、隔離開始と完了の時刻、担当者、対象範囲、承認者を残します。復元先の環境が古いままなら、脆弱な版へシステムを戻す危険があります。そこで、復元先のOS・アプリ版、必要な修正、管理者認証の状態も確認します。データを戻す前に清潔な基盤を用意する作業はRTOを左右します。訓練では、「環境構築は事前に終わっている」と仮定する場合と、ゼロから立ち上げる場合を区別して記録します。比較対象が違う時間を一つのRTOと呼ばないためです。

ステップ3：候補世代を選び、復元ジョブを走らせる

バックアップ担当は、事前に決めた候補の世代、保存先、整合性チェック結果を読み上げ、別の担当者が確認します。選定根拠は「最新だから」では不十分です。障害想定時刻より前であること、改ざんや失敗の兆候がないこと、復元に必要な鍵とソフトウェアが利用可能なことを確認します。最初の候補で解凍エラー、鍵エラー、容量不足が起きた場合は、その事象を消さずに記録して次の候補へ切り替えます。成功した試行だけを報告すると、事故時に必要な時間を過小評価します。

復元の途中で行う操作も時系列にします。対象のコピー、ベースイメージ適用、DBログの適用、アプリ設定の移行、権限の再設定、外部連携の無効化を個別に記録します。復元ジョブの「100%」は完了の一部にすぎません。バックアップ製品の成功表示をスクリーンショットで残した後、アプリ管理者へ次の検証を引き渡します。ジョブが失敗したときのエラーコード、空き容量、ネットワーク帯域、媒体読み込み速度も残します。これらは次回の改善で、容量増設か手順修正かを分ける材料になります。

ステップ4：データ・アプリ・権限を照合する

復元したDBへ技術担当が接続できても、売上や注文が正しいとは限りません。業務担当は訓練前に選んだ注文ID、最新更新時刻、顧客別件数、金額合計、取消し済み注文の状態を照合します。日付をまたぐバッチがある場合は締め処理を模擬実行し、二重計上が起きないか確認します。添付ファイルなら、開けるだけでなくファイルサイズとチェックサム、アクセス権が一致するかを確認します。個人情報を含む画面を証拠画像へ載せるならマスクし、原本の保存先を社内の安全な場所に限定します。

次に、業務担当が試験用注文を登録し、検索し、修正し、取消します。読取り専用でも画面が表示されれば「復旧した」と誤認しがちです。権限別に管理者と一般利用者で必要な操作ができるか、一般利用者が管理者操作をできないかも確認します。外部APIは無効化したまま、模擬の応答で連携処理が進むかを確認します。実際の顧客へメールや出荷指示が送られないことを監視ログで確かめます。

データの正確性は、単一の件数比較だけで判断しません。バックアップ時点の正本と現在の業務データの差分を確認し、RPOに含まれる損失を明らかにします。たとえば注文100件のうち96件が戻り、残り4件は紙の受注票から再入力できるとします。この場合、技術的には4件が欠けていますが、業務の再開基準としては再入力完了まで待つのか、暫定運用で受注を再開するのかを決める必要があります。訓練計画にその分岐がなければ、次回までの改善項目です。

ステップ5：受入れ判断と片付けを記録する

業務受入れ責任者は、確認項目の結果を見て「訓練上の復元完了」「条件付き」「不合格」のいずれかを決めます。条件付きなら、欠けた機能、影響業務、代替運用、解消期限を明示します。技術担当だけで「ログインできたので復旧」と宣言しません。時刻は、訓練開始、実復元開始、アプリ稼働、業務受入れの四点以上を残します。目標を超えた場合は、どの区間が長かったかを分解します。

訓練後は検証環境のデータと一時的な権限を消し、バックアップ媒体を元の保護状態へ戻します。削除証拠、例外設定の撤去、通知停止設定の復帰、外部接続の無効状態を確認します。検証環境を放置すると、新たな情報漏えいや侵入経路になります。片付けまでを訓練の完了条件に入れます。訓練中に見つかった本番システムの問題は、改善チケットに起票して責任者と期限を付けます。

半日訓練の進行表（架空例）

目安	作業	主担当	終了条件
開始前30分	環境・禁止操作の読み合わせ	訓練責任者	全員が復元先を確認
0〜30分	障害宣言、判断、隔離確認	監視・インフラ	想定被害範囲と候補世代が記録済み
30〜120分	クリーン環境準備・データ復元	インフラ・バックアップ	復元ジョブと失敗履歴が記録済み
120〜180分	データ照合、業務シナリオ	アプリ・業務部門	主要取引を模擬操作
180〜240分	受入れ判定、片付け、改善票	経営・業務・記録係	判定と次回作業が確定

この時間割は説明用です。容量、回線、クラウドの制約、外部委託先の対応時間により大きく変わります。特に大容量ファイルの転送とDBログ適用は、机上で想像した時間と実測がずれやすい部分です。時間内に終わらなかったことを隠さず、代替運用の有効性も同時に検証します。訓練の目的は予定表どおりに終えることではなく、実際の制約を事前に発見することです。

復元の合否をどう判定するか：時間・データ・業務・安全の四つの証拠

復元訓練の結果は「成功」か「失敗」の一語で終わらせません。復元できたファイル、使えたアプリ、満たせた時間、確認できた安全性を別々に判定します。たとえばRTO目標が8時間で7時間で画面が開いても、注文登録ができず業務受入れが9時間なら、目標達成とは扱いません。逆にRTOを少し超えても、隔離とデータ照合が安全に行われたなら、その成果を評価しつつ遅延要因を改善します。

時間：一つの合計だけでなく工程別の遅れを見る

目標時間と実測時間は同じ起点・終点で比べます。検知から隔離指示まで、隔離完了まで、復元元の選定まで、環境構築まで、データ適用まで、アプリ起動まで、業務受入れまでに分けます。外部ベンダーへの連絡から着手までに60分かかったなら、それは製品の復元速度ではなく連絡体制の問題です。媒体の読み込みに3時間かかったなら、容量と回線の設計を見直します。承認者が不在で止まったなら、代行承認の設定を見直します。改善対象を間違えないために工程別記録が必要です。

測定表には、予定、実測、差分、理由、次回までの対策、責任者を並べます。「想定より遅い」という感想だけでは、追加投資の判断ができません。例えば復元対象が1TB、実効転送速度が毎時200GBなら、転送だけで約5時間必要です。これは架空の単純計算であり、実際には圧縮率、ランダムI/O、検証、アプリ起動、競合する通信で時間が伸びます。実測値から逆算して、現在の構成がRTOと整合するか判断します。製品のカタログ速度をそのままRTOとしないでください。

データ：戻った件数より、使える状態と差分を確かめる

復元後のDBで「件数が一致した」だけでは、整合性を保証できません。注文ヘッダーと明細の対応、請求額と明細合計、在庫のマイナスや重複、消込済みデータの状態、文字コード、添付の参照先を確認します。復元時点をまたぐ処理については、途中で失敗したトランザクションが二重に実行されないかを試します。サンプルだけで全件保証はできないため、重要な集計値と代表サンプルの組合せを使い、未検証範囲も記録します。

RPOを満たすか判断するときは、バックアップ時刻だけでなく最終的に復元された更新を確認します。毎時バックアップでも、保存先が満杯で最後の3回が失敗していたら、見かけの設定と実際のRPOは違います。ジョブ監視のアラートが担当者へ届いていたか、届いても対応されなかったかを調べます。差分で失った取引を手作業で再入力するなら、入力元、責任者、二重入力防止、完了確認を訓練で試します。再入力が完了して初めて業務データが使える場合、RTOにもその時間を含めるかを事前に合意します。

復元元の整合性確認では、ファイルのハッシュ値が一致してもアプリ上の取引として正しいとは限りません。ハッシュはコピーの同一性を見る一つの手段です。業務側の正解データと照合する作業を省けません。また、復元時点から現時点までに承認済みの変更があるなら、古い設定へ戻すことで新しい権限や契約条件が消える可能性があります。復元後に再適用すべき設定の一覧を作り、変更管理の記録と照合します。

業務：最小の取引を最後まで通す

業務受入れは画面の表示確認ではありません。「仮の注文を受け付ける→在庫を引き当てる→出荷指示を模擬する→請求データを作る」という一連のシナリオを、検証環境で最後まで通します。外部への実送信を伴う手順はモックやテスト接続に置き換え、正しい受信・応答を確かめます。受付画面が動いても、夜間バッチが古い秘密情報を参照して止まることがあります。昼間の操作だけでなく、日次締めや定期処理も範囲に入れるか判断します。

利用者の種類も分けます。管理者は操作できても一般利用者がログインできなければ業務を再開できません。逆に全員が管理者権限で操作できてしまうなら、安全性の判定は不合格です。複数拠点がある企業では、本社だけが使えても現場の回線から使えない場合があります。代表拠点を選び、業務端末、ブラウザ、必要な周辺機器から接続します。テレワークが重要なら、別回線からも確認します。

受入れサインは、技術者の作業報告と別にします。業務責任者が「どの機能を確認したか」「何を確認していないか」「条件付きで使うなら制限は何か」を残します。経営者が再開を判断するときには、この受入れ結果と未解決の安全上の懸念が必要です。訓練では社内向けの再開案内文も作り、現場が使えない機能を誤って案内しないか確認します。

安全：清潔な環境で戻し、再侵害しない

バックアップはデータ損失を減らす手段であり、侵入経路を閉じる手段ではありません。脆弱なVPN、盗まれた管理者資格情報、未修正のサーバーへそのままデータを戻せば、再侵害の条件が残ります。訓練では、復元先の認証、OSとアプリの版、ネットワーク到達範囲、管理者アカウント、監視とログ取得を確認します。実事故なら専門家による原因調査と封じ込めの判断を踏まえ、段階的な接続を検討します。「データが戻ったから即本番へ再接続」は避けます。

安全性の証拠には、訓練中に本番へ書込みしていないこと、外部宛て通知が発火していないこと、検証環境で使った一時権限を回収したこと、機密データを適切に消去したことを含めます。復元元のバックアップ保護も戻します。訓練用の例外設定を残すと、本番の防御水準を下げかねません。安全項目に重大な未達があれば、時間とデータが目標内でも全体を「合格」としない、という判定ルールを先に決めておきます。

判定表と改善チケットの書き方

観点	合格の例	証拠	未達時の優先対応
時間	定義した起点から業務受入れまでが目標内	時刻表、ジョブログ、承認記録	遅い工程を分離し再測定
データ	RPO内の正本を復元し重要取引が一致	世代ID、件数・金額・ハッシュ	失敗世代と監視漏れを調査
業務	最小取引を権限別に完走	業務担当の受入れ票	依存システムと設定を追加
安全	隔離・誤送信防止・後片付けを確認	通信、権限、削除のログ	再接続を止め構成を修正

改善チケットには、観測事実、影響、原因の仮説、恒久対応、暫定対応、担当、期限、再試験条件を一件ずつ書きます。「ベンダーに確認」は成果物ではありません。誰が何をいつまでに受け取り、何をもって閉じるかを明記します。例えば「復元鍵が担当者個人のアカウントにしかない」という問題なら、暫定的に代行者を設定し、恒久的に鍵管理の権限と監査手順を整え、次回訓練で担当者不在を想定して取り出せるか試します。

未達の分類は、手順書の欠落、権限不足、機材・容量不足、バックアップ品質の問題、業務判定の不足、連絡・承認遅れに分けると直しやすくなります。一つの失敗に複数の原因がある場合もあります。原因を担当者個人の注意不足だけで終わらせず、画面や権限の設計、代行体制、確認手順で再発を防ぎます。NIST SP 800-184も、訓練や実際の事象から学び、回復計画を継続的に改善する考え方を示しています。

合格の場合も「二度と失敗しない」とは言えません。対象システム、バックアップ世代、時点、参加者、外部接続条件を限定して合格を記録します。次にクラウド構成、DB容量、認証、委託先が変われば、同じ結果が出る保証はありません。公開向けの説明に使うときは、「復元訓練を実施し、特定条件で確認した」と条件を添え、無条件の復旧保証のような表現を避けます。

訓練を続ける運用体制：年間計画・委託先連携・よくある質問

一度だけの訓練は、その時点の構成で戻せた証拠にすぎません。バックアップの対象、容量、管理者、クラウドの設定、業務システムの版が変われば、復元の難しさも変わります。IPAの中小企業向けガイドライン第4.0版は、基本的な対策にバックアップを追加し、緊急時の体制や復旧手順を整えた後に模擬訓練で機能を確認する考え方を示しています。小さな企業でも、実行可能な範囲から計画・実施・評価・改善を回すことが重要です。

最初の一年は対象を狭くして、段階的に難度を上げる

全システムを一度に停止して大規模な訓練をする必要はありません。最初は最重要の業務データ一つを選び、隔離先へ復元して読めるかを試します。次にアプリを動かして最小取引を試し、さらに認証、外部連携、代替連絡まで広げます。机上演習では意思決定と連絡順を確かめ、実機テストではデータとアプリが本当に戻るかを確かめます。片方だけでは不足します。NIST SP 800-184は演習とテストの組合せを推奨しています。

頻度は「年に一度なら必ず十分」と決め打ちしません。事業の重要性、データ更新速度、構成変更頻度、契約上の要求、過去の不具合、利用可能な人員に応じて決めます。目安として、重要なシステムは定期的な小規模復元を計画し、大きな更新後には追加で確認する方法があります。バックアップ製品の変更、保存先の移転、認証方式の変更、暗号鍵のローテーション、新拠点の追加、委託先の交代、データ量の急増は、予定日を待たずに再検証する契機です。テストの周期を決めた理由を残せば、経営者が投資判断しやすくなります。

次の表は架空の初年度計画です。各社の資産と体制に合わせて順番を変えてください。

時期	範囲	確認する問い	成果物
第1四半期	最重要データの一部を隔離先へ復元	正しい世代を選び、読み取れるか	世代・時間・不備一覧
第2四半期	業務アプリを含む最小取引	権限と依存サービスまで動くか	業務受入れ票と差分表
第3四半期	担当者不在・別世代への切替	個人依存を除き、失敗から戻れるか	代行手順と再試験記録
第4四半期	委託先を含む横断演習	連絡、承認、復元、再開判断がつながるか	翌年度の改善計画

各回で必ず全要素を試す必要はありません。ただし重要な対象が長期間一度も復元されていない状態は避けます。試験範囲を狭める場合は、対象外にしたシステム、なぜ対象外か、いつ試すかを記録します。「他のシステムも同様に戻せるはず」という推測を合格記録へ混ぜないようにします。

経営者・業務部門・IT担当・委託先の責任分担

経営者は、どの業務を先に戻すか、損失をどこまで許容するか、代替運用にどの費用をかけるかを決めます。業務責任者は、再開に必要な最小の取引と正解データを用意し、受入れを判定します。IT担当は復元先、権限、ログ、バックアップ世代、手順を管理します。委託先は契約範囲の作業、製品固有の復元操作、障害時の支援時間を明確にします。監査または記録係は、誰が何を見て判断したかを残します。一人が複数役を担ってもかまいませんが、責任と承認の境界は消してはいけません。

委託先への質問は具体的にします。「バックアップしていますか」だけでなく、「どのデータと設定を対象に、どの頻度で、どの世代まで保持し、どの権限で削除できますか」「最後に実際の復元をした日時と復元先はどこですか」「復元テストに参加する場合の費用と対応可能時間は何ですか」「障害時に自社が用意すべき情報は何ですか」と聞きます。回答がない項目は、自社の復旧計画の空白です。サービス契約のSLAに稼働率が書かれていても、自社アプリとデータが所定のRPO/RTOで戻る保証とは別です。

クラウドサービスの標準バックアップに頼る場合も、責任分界を確認します。事業者が基盤を守ることと、利用者が誤削除や侵害後の任意時点へ戻せることは同じではありません。保持期間、復元粒度、エクスポートの形式、退会後のデータ取得、サポート窓口、API制限、追加費用を確認します。復元したデータを自社で業務利用できるかまで試すことで、規約や機能説明の読み違いが見つかります。

訓練記録は「次の人が再実施できる形」にする

記録には、日時、対象、シナリオ、関係者、復元元の識別子、復元先、事前条件、操作ログ、開始・終了時刻、照合対象、結果、停止判断、改善チケットを含めます。画面キャプチャだけを大量に残しても、順序と判断理由が分からなければ次の担当者は再現できません。短い手順と、その手順を裏付ける証拠への参照を組み合わせます。機密データや鍵そのものは記録へ貼り付けず、権限管理された原本への参照にします。

訓練後一週間以内など、振り返りの期限も決めます。実施直後なら「ここで迷った」「この権限がなかった」という記憶が残っています。後からまとめて報告書を作ると、失敗の分岐が消えがちです。振り返りでは、うまくいった工程、時間が延びた工程、予想外の依存関係、安全上の懸念を分けて記録します。改善策には所有者と再試験予定日を付けます。「見直す」「徹底する」だけの対策は、次回確認できないので不十分です。

記録を経営層へ報告するときは、専門用語より事業影響で示します。「受注のRTO目標8時間に対し、受入れまで10時間だった」「不足した2時間の主因は鍵の承認待ち」「代替受注の開始にはさらに1時間必要」「次回は代行承認と模擬受注を含める」といった形です。合格率だけを示すと、どの業務が危険なのか見えません。事業部門が確認した残存リスクと、対応に必要な予算をセットで示します。

業務別の訓練シナリオ例：同じ復元方法を全社へ当てはめない

例A：小売・卸売の受注データ。 想定は、受注DBと注文票を保存した共有領域が利用不能になり、取引先への出荷予定を確定できない状態です。入力情報は、最後の正常注文番号、注文を受けたメールやEDIの履歴、前日の締め件数、バックアップ世代の時刻です。作業者は隔離環境へDBと添付を復元し、注文番号の連続性、取消し済み注文、顧客コード、単価表の有効日を照合します。業務担当は、試験注文を登録し、在庫引当を模擬し、出荷指示が誤って本番へ届かないことを確認します。完了条件は、決めたRPO内の注文を処理できることと、欠けた注文を手作業で復元する手順が具体化していることです。

失敗例は、受注DBだけが復元され、単価マスタの古い版が適用されるケースです。画面上は注文できても請求額が誤ります。この場合、どのマスタがどの時刻のデータに依存するかを追加し、同一の整合点から復元できるか再試験します。もう一つの失敗は、訓練用注文が本番の出荷システムへ飛ぶことです。送信先を無効化し、模擬応答でアプリの動作を試す設計に直します。実際の事故で注文を二重受付しないよう、紙や電話の代替受付番号と復元後のDB登録番号を突合する工程も加えます。

例B：会計・請求データ。 想定は月末締めの直前にファイルサーバーと会計アプリが停止した状態です。入力情報として、前日の締め済み一覧、入金消込表、請求書の採番台帳、取引先マスタ、承認状態を用意します。復元先で会計アプリを開くことだけを合格にしません。請求書番号が重複しないこと、支払先口座が正しいこと、未承認伝票が勝手に承認済みにならないこと、入金消込が重複しないことを確認します。外部への送金やメール送信は絶対に訓練先から実行せず、承認までの画面と模擬出力で確認します。

会計データのRPOを短く設定しても、明細の原本が紙や外部サービスにあり、再入力に数日かかるなら、実際の業務再開はその制約を受けます。経理担当は欠損取引を洗い出す手順、承認済みかどうかの判定基準、差額が出た場合のエスカレーション先を用意します。顧客へ請求書を再発行する可能性がある場合は、旧版の取消し方法と取引先への案内も検討します。訓練で見つけた差分を無理に埋めず、どこまで確定したかを明記します。業務判断を含めたRTOを計る理由です。

例C：設計・制作データ。 想定は、案件の共有フォルダが暗号化され、最新版の設計図や制作ファイルが見えない状態です。入力情報は、案件ごとの納期、最後の顧客承認版、ソース管理のコミット、外部協力会社との共有履歴です。復元先で「開けた」だけでは不足します。画像やCADなど容量の大きいファイルの破損、リンク先の欠落、フォントやプラグインの版、書き出し結果、権限を確認します。顧客へ渡してよい版がどれかを業務責任者が決め、復元したファイルからサンプル成果物を作って検査します。

このシナリオでよくある落とし穴は、ファイル本体は戻っても、制作アプリのライセンスや関連素材の保管場所が不明なことです。ソース管理がある場合も、リポジトリだけではビルド環境、外部依存、秘密情報の安全な再設定が必要です。バックアップ対象を「フォルダ」に限定せず、作業を再開するための材料を一覧にします。案件ごとの納品期限が異なるため、全ファイルを容量順に復元するより、期限が近い案件の必要ファイルを優先して復元する方法を検討します。優先度変更は顧客約束と整合させ、判断者を明記します。

例D：クラウド型の業務サービス。 サービス事業者が基盤を管理していても、利用者側で誤削除、権限の誤設定、不正アカウントによるデータ変更が起きる可能性があります。訓練では、標準機能で特定時点のデータを取り出せるか、エクスポートから別環境で業務を続けられるか、API制限やデータ形式の制約がないかを確かめます。事業者の説明にある「復元」はシステム全体か個別レコードか、ユーザーが自分で実行できるか、サポート依頼から何時間かかるかを確認します。SaaSの画面にログインできることと、自社の削除データを元どおり戻せることは別です。

外部サービスが停止した場合の代替運用も演習します。たとえば顧客からの問い合わせを一時的に別の安全な手段で受け付け、復旧後に重複せず取り込む方法です。ただし代替の共有シートへ個人情報を無制限に集めると、新たなリスクが生じます。入力項目を最小にし、アクセス権、保存期間、復旧後の消去を決めます。サービス固有の機能や料金は変わり得るため、契約中の公式文書とサポートへ確認します。

訓練計画書にそのまま転記できる確認項目

訓練計画書の冒頭に「対象業務」「想定停止」「RPO」「RTO」「復元対象データと設定」「依存する認証・通信・外部サービス」「復元元の候補世代」「隔離先」「禁止操作」「参加者と承認者」「業務受入れシナリオ」「停止条件」「片付け方法」を並べます。目標値は、希望の数字と現構成で実現できる数字を分けて書きます。差がある場合は投資か代替運用で埋める判断を求めます。目標が確定しない項目は空欄のまま運用せず、仮置きであることと決定期限を明記します。

当日の記録表には、判断と操作を分けて書きます。判断欄に「なぜこの世代を選んだか」「なぜ復元先を安全と見なしたか」「どの情報が足りなかったか」を残します。操作欄に「誰がどの権限で何を実行し、どのログで確認したか」を残します。結果欄には、時間、データ、業務、安全の四つを別々に判定します。トラブルが起きたら、最初に見えた症状と後で分かった原因を混ぜず、時系列で残します。原因の推測が誤っていても、迷った過程が次の手順改善に役立ちます。

報告書には「対象外だったもの」も必ず書きます。検証環境の性能が本番より低かった場合、時間測定をそのまま本番復旧の約束として使えません。担当者が通常より多かった場合、実事故の少人数体制では同じ時間で戻せない可能性があります。事前に復元元の場所を知らせていた場合、実事故で必要な探索時間は測れていません。これらを正直に書くことが、訓練成果の信頼性を高めます。

よくある質問：復元訓練を始める前の疑問

Q1. バックアップ製品が毎日「成功」と表示されます。それでも復元訓練は必要ですか。
必要です。成功表示は多くの場合、データ取得ジョブの状態を示すもので、障害時に必要な鍵、設定、ネットワーク、権限、アプリの依存関係まで戻せる証拠ではありません。保存元に誤ったデータが含まれていれば、そのまま正しく保存されることもあります。隔離先へ復元し、代表データを照合し、最小の業務操作ができるかを確かめます。まず一つの重要業務だけでよいので、実測を残してください。

Q2. クラウドへ同期していれば、オフラインのバックアップは不要ですか。
同期とバックアップを同一視しないでください。CISAは、ローカルファイルの暗号化がクラウドへ同期され、無傷のデータが上書きされ得ると注意しています。ただし全企業が同じ媒体を採用すべきという意味ではありません。保存世代、変更・削除権限、別アカウントや別環境での保護、復元粒度を確認します。オフライン、変更不可の保存先、独立した管理権限など、自社の脅威と予算に合う防御の組合せを検討し、実際に戻します。

Q3. 3-2-1ルールを満たせば訓練は不要ですか。
不要にはなりません。IPAは運用データと複数のバックアップ、異なる媒体、オフサイト保管という考え方を紹介しています。これは保存先を分散させる設計の目安です。媒体が複数あっても、鍵がない、対象から重要なDBが漏れている、復元に時間がかかりすぎるといった問題は残ります。分散と復元検証は補完関係です。保存先の設計を評価すると同時に、実環境に近い条件で戻せるか測ってください。

Q4. 本番環境を止めずに訓練できますか。
多くの場合、隔離した検証環境へ復元する方法で本番停止を避けられます。ただし本番と同じ性能・依存関係を再現できない場合、得られたRTOは参考値です。隔離先の構築時間、データ転送量、接続権限を含めた条件を記録します。本番に影響する切替やフェイルオーバーまで試す場合は、別途変更管理、業務部門の承認、戻し手順、緊急停止条件が必要です。初回から危険な切替訓練を行う必要はありません。

Q5. 個人情報を含むデータで訓練してよいですか。
必要性を確認し、可能ならダミーやマスキングしたデータを使います。ただし匿名化したデータでは、実際の文字種やデータ量、権限の問題を再現できない場合があります。実データを使うなら、利用目的、アクセス者、保存場所、委託先の取扱い、削除方法を確認し、訓練後の消去まで計画します。個人情報保護法や社内規程、契約の確認が必要な場合は担当部門や専門家へ相談してください。データの画面を無造作にチャットへ貼らないでください。

Q6. RPOとRTOを決められないとき、どこから始めますか。
まず「その業務が丸一日止まったら誰にどんな影響が出るか」「昨日までのデータに戻ったら何件を手作業で再入力するか」を業務担当に聞きます。契約上の納期、入金、法定保存、顧客対応の期限を洗い出します。仮の目標を置いて小さく復元し、実測と費用を見て調整します。最初から正確な数字を作るより、業務影響を説明できる数値と更新プロセスを持つことが重要です。目標を決めた日と承認者も残してください。

Q7. 復元が成功したら、侵害調査は終わりですか。
終わりません。データが戻っても、侵入経路、窃取の有無、漏えい通知の要否、残存する不正アカウントは別途調べる必要があります。検証環境で復元できたことを、そのまま本番再接続の許可としないでください。実事故では証拠保全と封じ込めを優先し、専門家や関係機関との調整を行います。復元訓練の成果物には、復旧作業と侵害調査の連携点を記載します。

Q8. 訓練で目標時間を超えたら、失敗として担当者を責めるべきですか。
責任追及だけで終わらせると、次回は時間超過や迷った手順が報告されなくなります。予定と実測を工程別に分け、権限、容量、手順、連絡のどこが制約だったかを調べます。安全な環境で問題を発見できたこと自体は訓練の価値です。ただし、重大な未達を「参加者は頑張った」で済ませず、対応費用と期限を経営判断に上げます。再試験で改善を確かめるまで完了にはしません。

Q9. 委託先へ任せていれば自社は参加しなくてよいですか。
業務の受入れ判断は自社が担います。委託先は機器やアプリの復元を支援できても、どの注文を優先するか、どの差分が許容できるか、顧客へ何を約束できるかを単独では決められません。契約の範囲、連絡手段、権限、費用、対応時間を確かめ、少なくとも業務責任者と意思決定者が訓練に参加します。外部委託の責任分界が曖昧なら、訓練はそれを見つける機会です。

Q10. どのくらいの頻度で復元訓練をすべきですか。
一律の回数で合否は決まりません。重要システムの更新頻度、バックアップ構成の変更、目標RPO/RTO、委託先の変化をもとに計画します。年次の横断演習と、より小さい範囲の定期的な実復元を組み合わせる方法があります。障害や復元失敗が起きた後、大きな移行の後は予定を前倒しします。次回日を予定表に入れ、対象と合格条件を事前に承認してください。

Q11. 復元訓練のために、あえて本番のデータを消す必要がありますか。
ありません。初回は本番と分離した検証環境へ、選んだ世代をコピーして復元する方法が安全です。本番データの削除や本番回線の切断を伴う訓練は、業務停止と情報損失のリスクがあります。切替やフェイルオーバーまで検証する必要がある場合は、対象、時間帯、承認者、顧客影響、戻し方、停止基準を別途定めます。「実戦的だから」という理由だけで危険な操作を正当化しないでください。隔離先で得た時間が本番切替時の時間と異なるなら、その差を報告書へ明記します。

Q12. バックアップは復元できましたが、目標RPOを満たせません。先に何を直しますか。
まず、設定した取得間隔と実際に復元できた最終更新時刻の差を調べます。ジョブ失敗、監視通知の見落とし、保存先の容量、増分ログの欠落、対象外フォルダ、業務側の更新方式など、原因は異なります。取得間隔を短くするだけでは、同じアカウントで全世代を削除できる危険や、復元時間が長すぎる問題は解決しません。欠損した業務取引を再構成できる原本があるか確認し、目標値を見直す場合は経営者と業務責任者に損失範囲を説明します。対策後は同じ条件で再試験します。

Q13. 復元時間を短縮するため、検証を省いて本番へ戻してもよいですか。
安易に省かないでください。データの整合性や侵害の残存を確認せずに再開すると、誤請求や再侵害で停止が長引く可能性があります。目標RTOが厳しいなら、検証を削る前に、業務を絞った段階的再開、事前に整えたクリーン環境、代替受付、復元対象の優先順位を検討します。何を確認できれば限定的に再開できるかを業務責任者と事前に合意し、未確認事項と制限を利用者へ伝えます。時間目標と安全性の対立を、現場担当者一人へ押し付けないことが重要です。

今日から始める最小の実行計画

最初の一歩は、全社の壮大な災害対策計画を書くことではありません。①止まると最も困る業務を一つ選ぶ、②その業務に必要なデータと依存サービスを列挙する、③最後のバックアップ世代と保護方式を確認する、④本番と切り離した復元先を用意する、⑤業務担当が実際の操作を試す、⑥所要時間と不備を記録する、という順です。ここまでできれば、自社の「戻せるはず」がどこまで事実か分かります。

訓練後には、管理者不在でも鍵を取得できるか、別世代へ切り替えられるか、全ての依存サービスを含められたかを見直します。次の一回で未達を再試験し、結果を経営層へ報告します。バックアップ復元訓練は、製品の性能を競うイベントではなく、会社がどの業務をどの条件で続けられるかを確かめる経営の練習です。

特に初回の訓練では、期待した結果が出ないことを前提に時間を確保してください。予定より遅い、権限がない、復元したデータが古い、業務担当が操作できないといった発見は、事故が起きる前に対処できる貴重な情報です。重要なのは失敗を隠さず、次の訓練までに直す担当者と期限を決めることです。経営者は、残るリスクを受け入れるのか、追加投資で減らすのかを選びます。現場の努力だけでは埋められない時間差や費用差を、測定結果として示すことが復元訓練の価値です。

参考・出典

IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版：バックアップ、緊急時の体制、模擬訓練の考え方。
IPA「日常における情報セキュリティ対策」：バックアップと3-2-1ルールの説明。
CISA「StopRansomware Guide」：オフライン・暗号化バックアップと復元検証。
NIST SP 800-34 Rev.1「Contingency Planning Guide」：RPO・RTOの定義と計画。
NIST SP 800-184「Guide for Cybersecurity Event Recovery」：復旧計画、演習、テスト、改善。

出典確認日：2026年10月30日。上記の資料は考え方の根拠です。本文の目標時間、架空企業の人数、訓練の四半期計画は公式資料が推奨する固定値ではなく、説明用の例です。

WithAIで、復旧手順と業務継続の整理を進める

復元訓練の記録整理、手順書の更新、業務部門とIT部門の確認項目づくりには、AIを補助役として使えます。ただし、バックアップ鍵、実データ、侵害調査の未公表情報を外部サービスへ入力してはいけません。公開してよい範囲の情報でたたき台を作り、担当者と専門家が事実を確認してください。WithAIでは、実務でAIを安全に使う考え方を学べます。