BCPとDRの違い・策定の進め方：復旧の優先順位と訓練

BCP（事業継続計画）は、災害や障害が起きたときに、重要な業務を続ける、または許容できる時間内に再開するための計画です。DR（ディザスタリカバリ、災害復旧）は、その業務を支える情報システムとデータを復旧させるための計画と手段を指します。レジリエンスは、危機に備え、影響に耐え、回復し、変化に合わせて適応する組織の力です。

三つは別のものですが、役割が重なります。BCPは「どの業務を、どこまで、いつまでに続けるか」を決め、DRは「そのために必要なシステムとデータを、どう戻すか」を決めます。DRでシステムが戻っても、データの照合や業務の責任者の確認が済むまで業務を再開できないことがあるため、DRの完了と業務の再開は分けて確かめます。

DRという言葉の範囲は、資料や組織によって異なります。米国のNIST SP 800-34 Rev.1は、DR計画を、主に大きな物理的被害で代替拠点へ移る必要がある場合の情報システムの復旧計画とし、拠点を問わず個々のシステムを戻す計画と区別しています（2.2.6節）。日本では、情報システムの災害対策全般をDRと呼ぶこともあるため、社内で使う意味をそろえておきます。また、サイバーレジリエンスは、攻撃や侵害を含む悪条件に備え、耐え、回復し、適応するシステムの能力を指す言葉で（NIST SP 800-160 Vol.2 Rev.1）、組織全体のレジリエンスの一部にあたります。

災害のときに最も優先するのは、従業員本人と、その家族・親族・大切な人の命、健康、安全です。経営者がこの方針を平時から示し、従業員が安全のための行動を選べる体制を整えておくことが、計画の出発点になります。事業の継続とシステムの復旧については、安全を確保できる人員・場所・手段で、どこまで対応できるかを判断します。

内閣府の事業継続ガイドラインも、初動対応として、必要に応じた出社の抑制、避難や安全な帰宅・待機の指示、従業員が自身と家族の安否を報告する方法を挙げています（本文p.22〜23）。計画では、次の点を具体的に決めておきます。

• 避難と出社の判断：避難・待機・出社を控える基準と、判断して伝える人。災害時に一律の出社を求めない
• 安否と参加できるかの確認：安否の確認と、業務に参加できるかの確認を分ける。本人や家族の状況によって、すぐには参加できない人がいる前提で体制を組む
• 代理者と権限：主担当・承認者・委託先が対応できない場合の代理者と、任せる権限の範囲。特定の人の頑張りに頼らない
• 遠隔での対応と交代：在宅でも、周囲の安全、電源・通信、本人の状況によっては対応できない。長時間の対応には交代と休息を組み込む

復旧の目標を守るために、危険な場所への移動や作業、休息を取れない体制を前提にはしません。一方で、安全が確保できる別の拠点や担当者が並行して対応することまで止める必要はありません。災害時の避難や安否の確認と、身体に危険のない日常のデータ復旧とでは、判断の場面も分けて考えます。

BCPで備える事象は、地震や水害に限りません。機器の故障、クラウドや通信の障害、不正アクセス、設定の誤り、データの誤削除でも業務は止まります。原因によって、復旧の前と業務の再開の前に確かめることが変わります。

不正アクセスやランサムウェアでは、データを戻すだけで安全に再開できるとは言えません。NISTのインシデント対応の指針SP 800-61r3は、復元に使う前にバックアップの完全性を確かめることと、本番で使う前に復元したシステムに侵害の痕跡がないかを確認し、原因に対処することを挙げています（RC.RP-03・05、p.34）。対応の記録と証拠も保全します（RS.AN-06・07、p.29）。原因の調査と復旧を並行して進めるかは、対応の責任者が状況を見て判断します。平時の対策の着手順は、ランサムウェア対策の優先順位と確認事項で扱っています。

誤削除・誤更新では、事故の前の時点にシステム全体を戻せば終わり、とは限りません。全体を戻すと、事故の後に正しく入力された取引や更新まで失う場合があります。ファイル、レコード、データベース全体など、どの単位で戻すかを決め、関連するデータや連携との整合性、権限、業務で使える状態かを確かめます。SP 800-61r3も、影響を受けたファイルだけを戻すか全体を戻すかを、速さ・正確さ・信頼性を踏まえて選ぶことを挙げています（RC.RP-02）。どの単位で、どこまでさかのぼって戻せるかは、製品・契約・保存期間・権限によって異なるため、事前に確かめておきます。悪意のない操作の誤りによるデータの変更・破壊は、NISTのSP 1800-11でも、ランサムウェアや内部不正と並ぶ脅威として扱われています。

軽い誤削除まで、全社のBCPを発動する必要はありません。日常の障害や復元は通常の手順で扱い、業務への影響、停止の見込み、対応できる体制が決めた基準を超えたときに、インシデント対応やBCPの発動へ切り替えます。この基準と判断する人を、事象ごとに決めておきます。

復旧の優先順位は、システムの名前からではなく、業務から決めます。最初に、止まったときに顧客・取引先・法令の期限・資金繰りなどへの影響が大きい業務を選びます。業務が止まった場合の影響と時間の制約を整理するこの作業を、事業影響度分析（BIA）と呼びます。そのうえで、選んだ業務を続けるのに必要な人、拠点、認証、ネットワーク、データ、共通の基盤、委託先をたどります。機能を絞って再開する場合でも、認証や通信のような共通の基盤は必要になるため、復旧の範囲に含めます。複数の部門や拠点がある組織では、部門ごとの計画が同じ共通基盤や委託先を前提にしていないか、優先順位が食い違っていないかも確かめます。

重要な業務ごとに、次の三つの目標を決めます。

• RTO（目標復旧時間）：いつまでに再開するか。この記事では、業務が停止した時点から、決めた水準で再開するまでの目標時間として扱い、検知や判断、BCPの発動までに経過した時間も含める
• RLO（目標復旧レベル）：どの業務・機能・対象者・処理量の水準まで戻すか。「重要な顧客の受注確認だけ」「照会のみ」「特定の拠点だけ」など、確かめられる形で決める
• RPO（目標復旧時点）：失ったデータを、どの時点まで戻せればよいか

内閣府の事業継続ガイドラインは、業務の停止が許される時間とレベルの限界を見積もり、RTOをその時間より早く、RLOをそのレベルを上回るように置いたうえで、実現できるかを検討してから経営判断で決めるとしています（3.1.2、本文p.11〜12）。期限を複数の時点に分け、時点ごとの水準を段階的に決める方法も示されています（同、脚注33）。

ここで扱う業務の復旧目標は、システムが戻った時点ではなく、決めた水準で業務を再開できる時点で確かめます。システムを戻した後のデータの照合、手作業で処理した分の反映、業務の責任者による確認にも時間がかかります（同、脚注64）。システムごとの復旧時間を別に管理する場合も、検知・判断・発動からシステムの復旧、照合・業務の確認までを含む全体の停止時間が、業務側の期限に収まるように計画します。また、RTOとRPOは別の目標で、足し合わせて期限を決めるものではありません（NIST SP 800-34 Rev.1、3.2.1、p.17）。バックアップを取る頻度だけで、RPOを満たせると判断することもできません。目標、現時点で見込める復旧、試験で確かめた結果、まだ確かめていないことを分けて記録します。

すべての業務を同時に元どおりにすることを、計画の完成条件にはしません。業務ごとに、次のどれを選ぶかを決めます。

• 重要な業務だけを、決めた水準で再開する
• 手作業や別のサービスなど、代替手段で続ける
• 後の段階に回し、重要な業務の再開に目途が立ってから時期を決める
• 休止し、再開するかどうかを見直す

後回しや休止にする業務は、対象、理由、影響、承認した人、見直す時期を記録します。顧客への約束や契約の条件を変える必要があれば、相手との調整も計画に入れます。期限を後から延ばすだけでは、影響はなくなりません。

使っていない機能や古い環境は、残すべきデータや記録と、業務・契約・関係先への影響を確かめたうえで、元どおりには戻さず、代わりの手段へ移す判断もできます。同ガイドラインも、重要な業務ではないと判断した業務は、重要な業務の復旧に目途がついた段階で復旧時期を検討し、復旧の先送りや事業からの撤退を検討する場合もあるとしています（脚注29）。一時的に後回しにする業務と、復旧の対象から外す業務は、区別して記録します。

同じ地震でも、ある会社では機器が一台壊れただけで済み、別の会社では拠点と委託先が同時に使えなくなります。復旧計画は、震度や警報の段階だけで機械的に決めず、自社と依存先の実際の被害から選びます。確かめるのは、人の安全と参加できる人数、電源・通信、拠点、データ、認証と権限、委託先、機材の調達です。内閣府のガイドラインも、被害の想定に軽微・甚大・壊滅のような段階を付け、段階ごとに戦略と対策を検討すると実践的だとしています（4.2、本文p.16）。事象が起きた後も、組織のニーズと使える資源を見直して、計画していた復旧の手順を変えることがあります（NIST SP 800-61r3、RC.RP-02）。

次の表は、受注の確認と顧客への連絡を重要な業務とする会社を想定した記入例です。4時間・24時間は説明のために置いた仮の目標で、推奨する値ではありません。実際の目標は、各社の業務の要件と制約、試験の結果から決めます。

三つ目の例の「2時間後の再評価」は次に判断する時点で、復旧の期限を守れたことを意味しません。被害が重いからといって、期限を無条件に延ばしてよいわけでもありません。目標との差、顧客への影響、取れる対策を記録し、経営の判断に戻します。

復旧の計画を手順の所要時間だけで組むと、実際の対応では期限を守れなくなりがちです。被害の確認、連絡と承認、要員の交代、機材や保守先の手配待ち、認証や環境の準備、データの照合、業務の確認、やり直しの時間も見込みます。どの作業を並行でき、どの作業が前の作業を待つのかも整理します。必要な余裕は業務と体制によって違うため、所要時間を一律に何倍かにする、といった決め方はしません。内閣府のガイドラインも、精緻に被害を想定しても、想定を超える事象が起こりうることを認識しておく必要があるとしています（脚注46、p.14）。

余裕は、期限だけに持たせるものではありません。

• 代わりに対応できる要員と、任せる権限
• 別の経路の連絡手段
• 復旧の方法や業務の代替手段を、複数持つこと
• 業務の範囲を段階的に広げる計画
• 予算と調達を承認する手順

余裕を持たせることは、業務が耐えられる停止の期間を超えて期限を緩めることではありません。見込みが目標に届かないときは、その差と、対策・代替手段・範囲の変更の案を経営に示し、判断を受けます。

役割は、経営・対策本部が範囲と予算と残る影響を、業務の責任者が最低限の業務とその受け入れを、IT・セキュリティの担当が技術的な判断と安全性と復旧の作業を、委託先が合意した範囲の支援を担う形が基本です。それぞれに代理者と、任せる権限の範囲を決めておきます。小規模な組織では、一人が複数の役割を兼ねても構いませんが、誰が何を決めるかは分けて書きます。

前提が崩れたときは、分かった事実、まだ分からないこと、影響、選べる案、判断した人、次に確認する時点を記録します。そのうえで、続ける・縮小する・別の手段に移る・延期する・休止する、のいずれかを決めて関係先へ伝えます。安全や再開の条件を満たせなければ、作業を止める判断も含めます。

訓練の目的は、計画の弱点と、実行できるかどうか、判断の流れを確かめて改善することです。決めた手順を予定どおりに実演して終わりにはしません。内閣府のガイドラインも、訓練の目的に、手順にできない事項への判断の力を鍛えることと、BCPやマニュアルの弱点を洗い出すことを挙げています（6.2.1、本文p.27）。

訓練は、目的に応じて分けて行います。

• 机上訓練：場面を示し、役割・判断・連絡の流れを話し合って確かめる
• 連絡・代理判断の確認：連絡がつくか、代理者が判断できるかを確かめる
• 復元テスト：決めた対象をバックアップから戻し、データ・機能・権限を確かめる。進め方はバックアップ復元テストの進め方で扱っています
• 切替・復帰の試験：代替の環境や拠点へ切り替え、元に戻す手順を確かめる

机上訓練は話し合いで判断を確かめるもので、機器や資源を実際には動かしません（NIST SP 800-34 Rev.1、3.5.3）。机上訓練だけで、実際の復旧時間を確かめたことにはなりません。復元や切替の試験は、承認した対象、分離した環境、影響の範囲、中止の条件を決めて行います。

前提が途中で崩れる机上訓練は、例えば次のように進めます。

1. 重要な業務、対象、仮の目標を決める
2. 被害の情報を示す（例：本社の拠点が使えない）
3. 「主担当と承認者に連絡がつかない」「委託先の復旧が遅れる」「復元に使うデータの状態が分からない」などの情報を、一つずつ加える
4. そのたびに、戻す範囲・水準・期限と代理者を判断し直す
5. 判断の根拠、かかった時間、保留したこと、未確認のこと、次の行動を記録する
6. 見つかった課題に改善の担当と期限を付け、次の訓練で確かめる

評価では、業務を復旧できたかどうかに加えて、分からないことを分からないと伝えられたか、目標に届かない見込みを早く共有できたか、縮小・休止・別の手段へ切り替えられたかも確かめます。経営の判断が必要な課題は、月次IT報告などで、予算・担当・期限とともに経営会議に諮ります。

次の確認票は、計画で決めることを10項目に整理したものです。採点表や公式の様式ではなく、自社の計画の抜けを見つけ、担当と期限を決めるために使います。根拠は設定、契約、試験の記録、業務の責任者との合意などで示し、確かめていない項目は「未確認」と書きます。

計画の対象とする業務、目標、見送る業務と、残る影響を受け入れるかどうかは、自社の経営と業務の責任者が決めます。計画の整理、役割と代理の設計、訓練の準備と振り返りには、外部の支援を使うこともできます。資料がそろっていなくても、現状と分からない点からご相談いただけます。

この記事は、代表者がDeNA・メルカリでBCPに関わる業務を担当した経験と、公開されている指針をもとに整理しました。代表者の経歴は会社概要をご覧ください。