DR対策（Disaster Recovery＝災害復旧）は、災害や障害でITシステムが止まったときに、どこまでのデータを、どれくらいの時間で戻すかをあらかじめ決めて実装しておく備えです。難しいのは定義より「自社はどの構成を選ぶべきか」の判断でしょう。バックアップを遠隔地に置くだけで足りるのか、待機系を常時動かす必要があるのか。この判断は、RPO・RTOという目標値と、それを満たせる4つのDR構成パターンの対応関係が分かれば絞り込めます。本記事は内閣府「事業継続ガイドライン」（令和5年3月）とAWS Well-Architected 信頼性の柱の記述をもとに、指標の決め方からDR計画（DRP）の作成手順までを整理します。
まとめ：DR対策の要点
- DRはBCPの一部で、担当範囲はITシステムとデータの復旧です。業務フローや人員配置はBCP側が扱います。
- 内閣府の事業継続ガイドラインが重要業務ごとに決めるよう求めるのはRTO（目標復旧時間）とRLO（目標復旧レベル）です。RPO（目標復旧時点）は情報のバックアップに関する脚注で扱われ、位置づけが違います。
- RPOはバックアップ取得頻度を逆算するための値です。RPO1時間ならバックアップは1時間おき、という順序で設計します。
- DR構成はバックアップ＆リストア／パイロットライト／ウォームスタンバイ／マルチサイトアクティブ・アクティブの4パターンで、この順にコストと複雑性が上がり、RPO・RTOが短くなります。
- AWSは「必要以上に厳格な戦略の実装は避けるべき」と明記しています。RTOが24時間で足りる業務にマルチサイトを組むのは、不要なコストです。
- 計画は災害の種類で分けません。内閣府ガイドラインは原因事象ではなく結果事象（例：拠点が使用不能）で考えることを推奨しています。
以下、各項目の根拠と具体的な決め方を順に見ていきます。
DR対策の定義とBCPとの役割分担
DR（Disaster Recovery）対策とは、災害・障害でITシステムが停止したときに、データとシステムを復旧させるための事前準備です。バックアップの取得と遠隔地保管、待機系サーバーの確保、フェイルオーバー手順の整備が中心になります。対してBCP（事業継続計画）は、どの業務を優先するか、代替拠点で誰がどう働くか、サプライチェーンをどう維持するかまでを含む、事業活動全体の計画です。DRはそのBCPの中でITシステムの復旧を担う部分にあたります。BCP全体の考え方は災害時に役立つBCP（事業継続計画）とは何か？企業が知っておくべき基本知識と重要性を徹底解説で整理しています。
両者の境界線としての「決める指標」
両者の役割分担は、公的ガイドラインがどの指標を扱っているかを見ると明確になります。内閣府「事業継続ガイドライン」（令和5年3月）は「3.1.2 重要業務の決定と目標復旧時間・目標復旧レベルの検討」で、重要業務について「どれくらいの時間で復旧させるかを『目標復旧時間』（Recovery Time Objective、RTO）として、どの水準まで復旧させるかを『目標復旧レベル』(Recovery Level Objective、RLO)として決定し、また、重要業務間に優先順位を付ける」と述べています。本文で経営者が決める指標はこの2つです。
一方でRPO（目標復旧時点）は本文ではなく、情報のバックアップに関する脚注で「失ったデータを過去のどの時点まで復旧させるか（例えば、１週間前のデータまで、１日前のデータまでなど）の目標値」と説明されています。RTO・RLOは事業側が業務単位で決める目標、RPOはIT側がバックアップ設計に落とすための値です。3点セットとして同列に並べる解説は多いのですが、決める主体も順番も違います。
| 観点 | BCP | DR |
|---|---|---|
| 対象 | 事業活動全体 | ITシステム・データ |
| 主担当 | 経営層・事業部門 | 情報システム部門 |
| 決める指標 | RTO・RLO（重要業務ごと） | RPO（バックアップ設計） |
| 主な手段 | 代替拠点・代替要員・業務手順 | バックアップ・レプリケーション・待機系 |
| 成果物 | BCP文書 | DR計画（DRP）・復旧手順書 |
DRは可用性（Availability）設計とも目的が別です。AWSは「可用性はワークロードのコンポーネントに焦点を当てるのに対し、災害復旧はワークロード全体の個別のコピーに焦点を当てる」と整理しています。単一拠点内でサーバーを二重化しても、その拠点ごと使えなくなる事象には効きません（可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】／冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】）。
なお「DR」は電力分野ではデマンドレスポンス（需要応答）を指し、まったく別の概念です。電力の需給調整を調べている場合はデマンドレスポンス（DR）とは？下げDR・上げDRとネガワット取引の仕組みと導入判断を参照してください。
RPO・RTO・RLOの意味と決める順番
DR構成を選ぶ前に、目標値を確定させます。順番を間違えると、必要のない高価な構成を選ぶか、逆に業務が耐えられない構成を選ぶことになります。
RTO・RLO：許容限界より内側に置く設定値
RTO（Recovery Time Objective／目標復旧時間）は「いつまでに復旧させるか」、RLO（Recovery Level Objective／目標復旧レベル）は「どの水準まで復旧させるか」です。RLOがあるため「4時間以内に復旧」だけでは目標として不完全で、平常時の処理能力の何割まで戻すのかまで決めて必要な設備量が確定します。
設定手順について、内閣府ガイドラインは事業影響度分析（BIA）を経たうえで「それぞれの重要業務について、停止（相当程度の低下）が許されると考える時間の許容限界、レベルの許容限界を事業影響度の時系列分析から推定した上で、時間の許容限界より早く目標復旧時間を設定し、レベルの許容限界を上回るように目標復旧レベル設定する」としています。許容限界そのものを目標にせず、内側に余裕を取ります。
同ガイドラインは脚注で「目標復旧時間、目標復旧レベルは、単なる目標ではなく、講じた対策により達成可能なものでなければならない」とも釘を刺しています。BIA直後の目標値は実現性が未検証の「案」にとどまり、対策を決めてはじめて正式決定になります。
RPO：バックアップ取得頻度を逆算するための値
RPO（Recovery Point Objective／目標復旧時点）は、障害時点からどこまで遡ったデータで復旧するかの目標です。RPO1時間なら、直近1時間分のデータ損失を許容することを意味します。
内閣府ガイドラインは「情報のバックアップについては、平常時に使用している情報データが失われた場合に、どれくらいの期間のデータ損失を許容するかを慎重に検討して決定し、それに基づいてバックアップの取得頻度を決定することが重要である」と述べています。RPOを決める、取得頻度が決まる、という一方向の依存関係です。1日1回のバックアップ運用でRPO1時間を掲げているなら、それは達成不能な目標です。取得方式ごとの違いはシステムバックアップとは？種類（フル・差分・増分）と方式の選び方を発注者視点で解説で整理しています。同じ脚注は「データは直近まで復旧させるのがもちろん望ましいが、相応して対策費用が高くなる場合が多い」とも書き添えており、RPOを短くするほど定期バックアップから継続的レプリケーションへ移る必要が生じ、回線と保管先の費用が増えます。
| 指標 | 正式名称 | 問い | 決める順番 | 直接効いてくる設計 |
|---|---|---|---|---|
| RTO | 目標復旧時間 | いつまでに戻すか | 1（BIA後） | DR構成パターンの選択 |
| RLO | 目標復旧レベル | どの水準まで戻すか | 1（BIA後） | 待機系の規模 |
| RPO | 目標復旧時点 | どの時点のデータを戻すか | 2 | バックアップ取得頻度・複製方式 |
DR構成（DR環境）の4パターンとRPO・RTOの目安
目標値が決まれば、それを満たせるDR構成は絞り込めます。AWS Well-Architected 信頼性の柱のベストプラクティスREL13-BP02は、復旧サイトを別リージョンに置く場合の戦略を4つ挙げ、「コストと複雑性が増加する順、RTOとRPOが減少する順に並んでいる」と説明しています。自社データセンター間でDRサイトを組む場合も同じ考え方で整理できます。
バックアップ＆リストア（RPO数時間・RTO24時間以内）
AWSはこの戦略を「RPO in hours, RTO in 24 hours or less」と定義しています。データとアプリケーションを復旧サイトへバックアップしておき、被災時にインフラを展開してからデータを復元する方式です。平常時に復旧サイトで動かしておくものが無いため、4パターンで最も安価になります。
同ドキュメントは「自動または継続的なバックアップを使用するとポイントインタイムリカバリ（PITR）が可能になり、場合によってはRPOを5分程度まで短縮できる」とも記しています。RPOだけを短くしたいなら、構成を上位パターンへ上げる前にPITRを検討する余地があります。ただしRTOはインフラ展開とデータ復元の所要時間に支配されるため短くなりません。
パイロットライト（RPO数分・RTO数十分）
「RPO in minutes, RTO in tens of minutes」の構成です。復旧サイトにコアとなるインフラの複製を用意し、データを継続的に複製します。データベースやオブジェクトストレージなど複製に必要なリソースは常時稼働させる一方、アプリケーションサーバーは配置せず、必要になった時点で作成します。RPOは複製方式に直結し、非同期複製ならレプリカ遅延の分だけ後退します（データベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計を実装者目線で解説【2026年版】）。
ウォームスタンバイ（RPO数秒・RTO数分）
「RPO in seconds, RTO in minutes」の構成です。縮小してはいるものの完全に機能するバージョンの本番環境を復旧サイトで常時稼働させ、被災時は本番負荷を捌けるところまでスケールアップします。AWSは「復旧サイトがフル容量でデプロイされている場合、これはホットスタンバイと呼ばれる」としており、ホットスタンバイはウォームスタンバイの上限にあたります。
パイロットライトとの区別は迷いやすいところです。AWSの注記によれば「パイロットライトは追加のアクションを取らなければリクエストを処理できないのに対し、ウォームスタンバイは（低い容量水準で）すぐにトラフィックを処理できる」点が違いです。
マルチサイトアクティブ／アクティブ（RPOほぼゼロ・RTO実質ゼロ）
「RPO near zero, RTO potentially zero」の構成です。複数の拠点へ同時にデプロイし、すべてが実際にトラフィックを処理します。被災した拠点を切り離し、残りの拠点で可用性を維持します。代償は複雑性で、AWSは「この戦略ではリージョン間でのデータ同期が必要」であり「2つの異なるリージョンのレプリカで同じレコードに書き込みが発生した場合の競合を回避または処理しなければならず、これは複雑になり得る」と述べたうえで、「マルチサイトアクティブ／アクティブはDR戦略の中で最も運用が複雑であり、ビジネス要件が必要とする場合にのみ選択すべき」と明記しています。
| DR構成 | RPO目安 | RTO目安 | 復旧サイトで常時動くもの | 被災時の作業 |
|---|---|---|---|---|
| バックアップ＆リストア | 数時間（PITRで5分程度まで） | 24時間以内 | なし（バックアップ保管のみ） | インフラ展開＋データ復元 |
| パイロットライト | 数分 | 数十分 | DB・ストレージなどコア | サーバー起動＋スケールアップ |
| ウォームスタンバイ | 数秒 | 数分 | 縮小版の本番環境一式 | スケールアップ |
| マルチサイトアクティブ／アクティブ | ほぼゼロ | 実質ゼロ | 本番環境一式（全拠点で稼働） | 被災拠点の切り離し |
過剰なDR構成を選ばないという判断
DR構成の選定でよくある失敗は、上位パターンほど良いと考えて予算を使い切ることです。AWSはこれを明確に否定しています。「DR戦略の選択は、ダウンタイムとデータ損失（RTOとRPO）の削減と、その戦略を実装するコストおよび複雑性とのトレードオフである。必要以上に厳格な戦略の実装は避けるべきであり、それは不必要なコストを招く」という記述です。
経費精算や社内ポータルにウォームスタンバイを組んでいるなら削減余地です。逆に決済や受注のようにRTOが分単位の業務でバックアップ＆リストアを採用しているなら、訓練の時点で目標未達が露見します。
DRサイトの置き方：距離・AZ・遠隔地バックアップ
DRサイトは、本番環境が使えなくなったときにシステムを立ち上げる場所です。置き方は3段階あり、防げる事象の範囲が変わります。
1段階目は同一リージョン内の複数アベイラビリティゾーン（AZ）です。AZは独立した電源・空調を持つデータセンター群で、AWSは複数AZにまたがるDR戦略について「火災、洪水、大規模停電のような災害事象に対する緩和策を提供できる」とし、データ所在地の規制でマルチリージョンを選べない場合についても「マルチAZ戦略はほとんどの災害に対して良好な保護を提供する」と補足しています。
2段階目は別リージョン・遠隔地データセンターです。地震や広域停電のように地理的にまとまった範囲を襲う事象にはこちらが必要で、同一都市圏に本番とDRサイトを置くと同じ震源で両方が被災し得ます。金融など可用性要件の厳しい領域での拠点設計は金融システムのサーバー構成｜可用性・DR設計とクラウド移行の判断基準で扱っています。
3段階目は、DRサイトの有無にかかわらず必要になる遠隔地バックアップです。AWSは全戦略に共通する注意として「継続的なデータ複製は一部の種類の災害からは保護するが、保存データのバージョニングやポイントインタイムリカバリの選択肢を戦略に含めない限り、データの破損や破壊からは保護しない」と述べています。ランサムウェアによる暗号化や誤操作による削除は複製先にもそのまま伝播するため、複製とバックアップは別物として両方持ちます。復元作業そのものの整理はリカバリーとは？意味・リストア/バックアップとの違いと企業の実務判断【2026年】、AWS環境での取得状況の集中管理はAWS Backupとは？対応サービス・料金・バックアッププラン作成と復元手順を解説にまとめています。
DR計画（DRP）の作り方
DR計画（DRP：Disaster Recovery Plan）は、目標値と構成を、被災時に人が実行できる手順へ落とし込んだ文書です。作成順は次の3段階になります。
事業影響度分析による重要業務とRTO・RLOの確定
出発点は守るべき業務の特定です。内閣府ガイドラインは事業影響度分析について「影響の大小などで定性的に評価してもよい。直感的に重要業務、目標復旧時間等が把握できるならば、簡易な取組ではそれを用いてもよい」と述べており、厳密な定量化は必須ではありません。むしろ「事業影響度分析に時間をかけ過ぎると、その間に外部・内部の事業環境が変化し、作業が無意味になる可能性があることにも留意が必要である」と警告しています。重要業務が決まったら、その業務に不可欠な経営資源を洗い出し、復旧をこれ以上早められない要素を「ボトルネック」として特定します。「業務Aを4時間で戻すにはデータベースBとファイルサーバーCが必要」という対応表ができ、それが構成選定の入力になります。
原因事象でなく結果事象で組むシナリオ
DR計画で最も無駄が出やすいのが、災害の種類ごとに手順を書き分けるやり方です。地震編、水害編、サイバー攻撃編と並べれば文書量は増えますが、復旧作業の中身は大部分が重複しますし、実際に起きるのは想定した組み合わせとは限りません。
内閣府ガイドラインは「BCMでは、自社に生じた事態を原因事象（例えば、直下型地震）により考えるのでなく、結果事象（例えば、自社の○○拠点が使用不能）により考え、対応策を検討することが推奨される」と明記しています。「想定外の被害を受けた場合にも、『結果事象』としてみた被害が同じものであるならば、そのための戦略・対策は」有効に働くためです。
DR計画に翻訳すると、想定すべきシナリオは災害名ではなく状態になります。データセンター1拠点が全損した、本番データが破損または暗号化された、拠点は無事だがネットワークが到達不能になった、要員が出社できない。この4種類程度に絞れば、原因が地震でも火災でもランサムウェアでも同じ手順書が使えます。計画が災害名で章立てされているなら、結果事象での再編は文書量の削減と実効性向上を同時に達成できます。
手順書・体制・連絡手段の文書化
シナリオが決まったら実行内容を文書化します。含めるべきなのは、システムの復旧順序、フェイルオーバーの発動判断者、切り替え操作の手順、担当者と代替要員、ベンダーを含む緊急連絡先、平常時と異なる通信手段です。
発動判断では自動化の是非を決めておきます。AWSは「ヘルスチェックやアラームに基づく自動的なフェイルオーバーの開始は、不要なフェイルオーバー（誤検知）が可用性の喪失やデータ損失といったコストを招くため、慎重に使用すべきである。そのため手動で開始するフェイルオーバーがしばしば使われる」としたうえで、「その場合でも、手動の開始がボタンを押すようなものになるよう、フェイルオーバーの手順は自動化すべき」と続けています。判断は人が下し、判断後の手順は自動化しておく形です。
フェイルバック（本番拠点への復帰）の手順も同じ文書に含めます。切り替え手順だけが整備され、戻す手順が無い計画は珍しくありません。AWSは「フェイルバックの課題は、データストアの復元と、稼働中の復旧サイトとの整合性の確保である」と指摘し、「フェイルオーバーとフェイルバックに必要なすべてのステップは、チームの全メンバーが利用できるプレイブックに保持し、定期的にレビューすべきである」としています。
DR訓練による計画の実効性確認
文書化した時点ではDR計画はまだ「案」です。内閣府ガイドラインは目標復旧時間・目標復旧レベルを「講じた対策により達成可能なものでなければならない」と定めており、その確認手段が訓練にあたります。実施時期については「定期的（年次等）に行うほか、体制変更、人事異動、採用等により要員に大幅な変更があったとき、さらに、BCPの見直し・改善を実施したときに行う」としています。復旧手順は担当者の暗黙知に依存しやすく異動で失われるため、人が入れ替わったタイミングを契機に含める点が実務上の要点です。
形式も一段階ではありません。同ガイドラインは方法の例として、BCPやマニュアルに基づき役割分担・手順・確保資源を机上で確認する「内容確認（ウォークスルー）」と、重要な動作を繰り返して身に付ける実働訓練である「反復訓練（ドリル）」を挙げ、後者の例に「バックアップシステム稼動訓練」を含めています。DRでは机上での手順読み合わせと、実際に待機系へ切り替えて業務が回るかを見る実働訓練の両方が要ります。
そして訓練には合否基準を用意します。同ガイドラインは「いずれの教育・訓練方法についても、その有効性を評価するため、目標を明確に定め、その達成度を評価する方法をあらかじめ決めておくことが必要である」としています。DR訓練であれば基準はRTOとRPOそのものです。切り替えに要した実時間がRTOを超えたか、復元できたデータの時点がRPOに収まったかを毎回記録し、超過していれば目標値か構成を見直します。実施記録だけを残して達成度を測っていない運用は、目標が達成可能であることの裏付けになりません。
よくある質問
DR対策とBCP対策の違いは何ですか？
BCPは事業活動全体を止めないための計画で、業務の優先順位、代替拠点、人員配置、サプライチェーン維持までを含みます。DRはそのうちITシステムとデータの復旧を担う部分です。内閣府の事業継続ガイドラインが重要業務ごとに決めるよう求めるRTO・RLOはBCP側の意思決定であり、DR側はそれを満たす構成とバックアップ設計を担当します。
DR環境（DR構成）にはどのような種類がありますか？
復旧サイトを別拠点に置く場合、バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトアクティブ／アクティブの4つに整理できます。AWS Well-Architected 信頼性の柱の記述では、この順にコストと複雑性が上がり、RPOは数時間からほぼゼロへ、RTOは24時間以内から実質ゼロへ短くなります。同一リージョン内で複数AZを使う構成は、これらの要素を組み合わせた形です。
RPOとRTOはどちらを先に決めますか？
RTOとRLOが先です。事業影響度分析で重要業務を選び、停止が許される時間の許容限界より早くRTOを、レベルの許容限界を上回るようRLOを設定します。RPOはその後、バックアップ設計として許容できるデータ損失期間を決め、それに基づいて取得頻度を決定します。RPOを先に決めても、業務側の許容時間が分からないため構成を選べません。
DRサイトはどれくらい離せばよいですか？
距離そのものの基準値は公的ガイドラインになく、防ぎたい結果事象から逆算します。火災・洪水・大規模停電までを対象にするなら同一リージョン内の複数AZで足り、地震のように広域を襲う事象まで含めるなら別リージョンや遠隔地データセンターが必要です。データ所在地の規制で国外リージョンを選べない場合は、マルチAZ構成に遠隔地バックアップを組み合わせます。
DR訓練は年に何回実施すべきですか？
内閣府の事業継続ガイドラインは、定期的（年次等）に加えて、体制変更・人事異動・採用などで要員に大幅な変更があったとき、およびBCPの見直し・改善を実施したときに行うとしています。回数より、実施のたびに切り替え所要時間がRTOに、復元データの時点がRPOに収まったかを記録し、超過していれば目標値か構成を見直すことが重要です。
