災害復旧システム（DR）開発の進め方/やり方/流れや方法/手法/工程/手順

DR開発は、業務ごとに守る範囲と復旧目標を決め、その目標に合う方式を選んで設計・開発していく流れです。テスト、稼働切替、訓練と改善へと順に進めることで、災害時に業務を再開できる状態が整います。

▼全体ガイドの記事
・災害復旧システム（DR）開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

災害復旧システム（DR）の概要

災害復旧システム（DR）は、本番環境が使えなくなったときに、別の拠点やクラウドへ切り替えて業務を再開する仕組みです。データを保存しておくだけでは再開できないため、復旧する業務と順序、各業務の状態までを手順として定めておきます。

バックアップとDRの目的の違い

バックアップとDR、BCP、BCMは役割が異なるため、復旧設計ではそれぞれの対象を区別する必要があります。

• バックアップ：削除や破損したデータを、保存時点の状態へ戻します。
• DR：依存関係を含めて業務を再開します。サーバーの起動順、認証、DNSが戻らないと、データを復元しても仕事は再開できません。
• BCP・BCM：事業継続計画と、その計画を見直していく管理活動です。DRは主に、ITサービスやデータを復旧する実装の部分にあたります。

事業部門が受注の継続や出荷の手作業化を決めたら、その判断を縮退運転や復旧順序へ落とし込みます。こうして初めて、BCPとDRがつながります。

業務ごとのRTOとRPO

業務ごとの目標を決める際は、用語の意味、停止時の影響、必要な費用を並べて見ます。

• RTO：目標復旧時間です。障害の発生から業務を再開するまでに許容できる時間を指します。
• RPO：目標復旧時点です。許容できるデータの復旧時点を示します。
• 業務別の目標例：受注管理はRTO4時間・RPO15分、社内ポータルはRTO24時間・RPO24時間です。
• 費用との調整：全システムをRTO15分・RPOゼロに近づけると、待機環境、専用回線、同期、監視、要員の費用が増えます。

経営層、業務責任者、情報システム部門は、業務ごとの目標を合意します。その際は、売上や顧客対応への影響、法令、従業員の安全を、復旧費用と比べます。

ホット・ウォーム・コールド・DRaaSの比較

復旧時間と継続費用の違いを押さえると、業務に合う方式を選べます。

• ホットサイト：別拠点を常時稼働に近い状態にして、RTO・RPOを小さくします。
• ウォームサイト：データや構成を待機させておき、障害時にサーバーを起動します。
• コールドサイト：データと手順を保管しておき、必要になったときに環境を構築します。
• DRaaS：クラウドでの複製、保管、復旧環境や操作を、サービスとして利用します。

ホットサイトは、二重の計算資源や同期、回線、監視が必要な分、継続費用が高くなります。一方で、ウォームサイトは費用と復旧時間のバランスを取りやすい方式です。

コールドサイトは、停止を長く許容できる業務や重要度の低いシステムに適しています。また、既存のオンプレミス環境をクラウドで保護するDRaaSという選択肢もあります。全社を一つの方式にそろえるより、業務ごとに方式を組み合わせるほうが現実的です。

災害復旧システム（DR）開発の進め方・流れ

DR開発では、まず業務影響分析で必要な復旧レベルを定め、そのうえで技術方式へ置き換えていきます。さらに、PoCや訓練で実測し、計画どおりのRTO・RPOや性能が出ているかを確かめます。

フェーズ1：要件整理で守る業務と復旧目標の決定

まず、社内の業務とシステムを洗い出して一覧にします。販売や在庫、会計といった業務系のほか、認証やファイルなどの基盤、顧客サポートや製造、物流も対象です。

業務ごとに、停止時の売上損失や顧客への影響、法令・契約上の影響を確かめます。そのうえで、手作業へ切り替えられるかも調べ、重要度をA・B・Cのように分けます。

分類は業務単位で行うことが要点です。成果物には、業務影響分析（BIA）や依存関係図、対象システム一覧を含めるほか、業務別RTO・RPOも記録します。

復旧の優先順位や縮退運転の手順、データの保存期間も記録しておきます。下に挙げる確認事項は、依存先、担当者、複製先について判断するための材料です。

• 認証・外部API：認証前に使える業務と、API停止時の代替手段です。
• 担当者：復旧担当者が不在でも判断できる体制かどうかです。
• データ所在地：個人情報や機密データを複製できる地域の範囲です。

フェーズ2：方式と開発会社の選定

候補は、クラウドDRaaSとパッケージ型です。別データセンターの予備機や、オンプレミスとクラウドのハイブリッド型も比べます。

選定では、要件への適合と訓練のしやすさを同じ条件で確かめます。あわせて、ベンダーの担当範囲を、導入後の運用まで含めて確認します。

• 技術適合：RTO・RPOを満たすか、既存のOS・仮想基盤・DBを保護できるか、切替と切戻しができるかです。
• 訓練：本番に影響を与えずに復旧訓練を行えるかどうかです。
• 支援範囲：調査、BIA、設計、移行、24時間監視、障害窓口、現地対応、訓練、復旧後の整合性確認まで含むかです。
• 実績と契約：同規模・同じOS・DBの実績、実測RTO・RPO、感染前の復旧点、データと設定の持出しについて質問します。

フェーズ3：復旧構成の設計と開発

設計では、通常時から復旧後までの各段階を分けて考えます。そのうえで、段階ごとに必要な複製や保護の要件を整理します。

• データ保護：複製、バックアップ世代、暗号化、イミュータブル保管を構成図に反映します。
• アクセス管理：別アカウント・テナント、MFA、最小権限を定めます。
• 環境分離：復旧環境のネットワークを分離し、バックアップ管理者と本番管理者を分けます。

複数サーバーの起動順は、認証・DNSやデータベースなどの依存関係に沿って決めます。依存先が先に動いていないと、上位のアプリは復旧できないためです。

構築はIaCやスクリプトで自動化します。手作業が残る部分には、実行者、判断者、確認方法、切戻し条件を書き残します。なお、個別開発を業務連携や監視画面に絞ると、専用アプリをゼロから作るより保守の負担を抑えられます。

フェーズ4：テストによる実測RTO・RPOと業務整合性の確認

テストでは、複製の状態だけでなく、復旧操作と業務データの整合性も確かめます。

• 復旧環境：非本番や重要度の低いシステムで、複製と復旧点を確かめ、起動、ネットワーク、アプリ接続、認証を試します。
• 業務確認：代表データで受注や在庫照会、帳票、外部連携、会計処理を試し、業務部門が受け入れられるかを判定します。
• 実測項目：障害検知から判断までの時間、起動時間、最終反映時刻、エラー、手作業時間、復旧後の性能です。

Azure Site Recoveryでは、複数VMの復旧順を計画できます。複製に影響しない訓練機能も紹介されています（出典：Microsoft Learn「Azure Site Recovery について」、2026年6月更新）。自社の方式でも、計画停止を伴う訓練と本番を止めない訓練を使い分けます。

フェーズ5：稼働切替とフェールバックの実施

切替と切戻しでは、実施する順番、確認内容、判断条件を先に決めておきます。

• 段階切替：重要度の低いシステムから順に本番へ切り替え、開始と中止の条件を決めて独自判断を防ぎます。
• 切替前確認：同期状態、復旧先の容量、回線帯域、ライセンス、DNS・ルーティング、認証情報、連絡網、判断権限を確かめる項目です。
• 業務受入れ：受注や出荷を実際に行い、二重登録や欠落を点検したうえで、業務部門が作業を確認します。
• フェールバック：差分反映や整合性確認、告知、監視の再開を行い、復旧先で更新されたデータは保持します。

フェーズ6：訓練と改善による運用の定着

DRは、稼働した時点で完成するものではありません。人事異動やシステム追加、データ増加があると、手順は古くなります。クラウドの設定や外部サービスが変わった場合も、手順の見直しが必要になります。

• 訓練シナリオ：自社の基準で定期訓練を設け、自然災害、ランサムウェア、認証障害、回線断、誤操作を試します。
• 記録項目：目標達成、手順書だけでの作業可否、連絡不能者、復旧データへのマルウェア混入、業務受入れ時間です。
• 要件の見直し：可用性、運用・保守性、移行性、セキュリティを、重要度とリスク受容方針に合わせて見直します。

デジタル庁の非機能要件の標準（地方公共団体向け）第1.2版は、要件を選べる形で整理しています。対象は、可用性や運用・保守性、移行性、セキュリティなどです（出典：デジタル庁「地方公共団体情報システム非機能要件の標準 第1.2版」、2025年9月）。

クラウド・オンプレミス・DRaaSの選び方

方式は、RTO・RPOをはじめとする目標や、データの所在地、既存ライセンス、通信帯域などの条件で比べます。さらに、要員の体制や訓練のしやすさ、監査要件も見ます。また、データの整合性や、復旧後に業務が成り立つかも確かめます。

小さく始めて実測しやすいクラウドDR

クラウドDRは、別のデータセンターを自社で保有せず、サーバーやストレージを従量課金で使える方式です。

• 複製先：オンプレミスからクラウド、またはクラウドの別リージョンの中から選べます。
• 小規模な検証：試験起動や復旧点の確認、自動化を行いやすく、重要なシステムの一部でPoCもできます。
• 費用確認：サービス料金に加えて、ストレージ、ログ、転送、復旧時のVM、監視、バックアップ世代、サポート、接続の費用がかかります。
• 費用の分け方：平常時の待機費用と、訓練時や本番復旧時の一時的な起動費用を分けて試算します。

PoCで復旧時間と月額を実測すれば、構成と費用を導入前に判断できます。

既存資産や規制に合わせやすいハイブリッド型

クラウドへ全システムを移せない場合は、既存資産や規制に合わせて、本番と複製先を組み合わせます。

• 移行を制約する条件：データ所在地、専用機器、低遅延の設備連携、ライセンス、社内規程を確認します。
• 複製構成：本番をオンプレミスや主データセンターに置き、重要データを遠隔地やクラウドへ複製します。
• 規制・監査：医療、金融、自治体、重要インフラでは、法令、委託先管理、監査証跡、国外リージョンの可否を確認します。
• 運用・維持：予備機は構成を再現しやすい一方で、設備、電源、空調、回線、要員の維持費がかかります。

クラウド併用時は、回線障害で接続できなくなるリスクや、認証基盤がクラウドに依存するリスクも検討します。また、復旧時に誰がどの操作をするかを図にして、手順の複雑さまで比べます。

災害復旧システム（DR）の費用相場とコスト内訳

費用は、対象サーバーの台数やデータ容量、RTO・RPOによって大きく変わります。方式や回線、監視時間帯、訓練回数、既存環境との連携も影響します。

DR専用の公的な一律相場はありません。ここで示すのは、業務システムの一般的な開発費と公開料金を組み合わせた検討用のレンジで、個別案件の確定見積もりではありません。

小規模なDRaaS導入の費用目安：初期50万〜300万円、月額5万〜30万円

小規模導入は、3〜10台程度を対象とする場合が目安で、期間は1〜3か月程度です。

• 対象と作業：既存バックアップ、クラウド複製、基本監視、復旧手順、初回訓練の準備です。
• 下限に近づく条件：対象を絞り、標準機能を使い、CSVや既存バックアップで連携する場合です。
• 月額の確認：平常時と、訓練を1回行った月を分けて、ストレージや計算資源、転送、ログ、監視、サポート、起動費を見積もります。

月額5万円で復旧先のすべてが動くとは限らず、請求額は利用する構成によって変わります。

中小企業向けの費用目安：初期300万〜1,500万円、月額20万〜100万円

10〜50台程度を別リージョンや別データセンターへ複製する構成が目安で、構築は3〜6か月程度です。

• 構築範囲：認証やネットワーク、DBの復旧順、複数業務の自動化、受入れテストまでを含みます。
• 費用目安：初期費用は300万〜1,500万円、月額は20万〜100万円です。
• 上限を超える条件：環境調査、移行、専用回線、監視・保守のSLAが加わる場合です。
• 受託開発の参考：一般的な開発費と技術者の月額も、比較の材料にします。

一般的な受託開発では、小規模な刷新は数百万円〜1,500万円、複数領域にまたがる場合は1,500万〜4,000万円程度です（出典：業務システム全般の一次Q&A、2026年）。技術者の月額は80万〜120万円程度が参考になります（出典：業務システム全般の一次Q&A、2026年）。

DRでは画面の数よりも、依存関係や復旧試験、切替と切戻し、運用設計の工数が見積額を左右します。

大規模基幹系の費用目安：初期1,500万〜5,000万円超、月額100万〜500万円超

複数拠点や基幹系を対象にする中堅・大企業向けの構成が目安で、構築は6〜12か月程度です。

• 対象範囲：基幹DBや認証、ネットワーク、外部API、受入れ、訓練、24時間監視までを含みます。
• 費用目安：初期1,500万〜5,000万円超、月額100万〜500万円超です。
• 大規模化する条件：常時二重化や専用施設・回線、物理サーバー、現地作業、厳格なSLAが加わる場合です。
• AWSの追加費用：ストレージや復旧時の計算資源も別課金のため、サービス料金だけでは総額を判断できません。

その条件が加わると、初期は3,000万円〜1億円超、月額は数百万円以上となる可能性があります。

AWS Elastic Disaster Recoveryは、ソースサーバー1台あたり1時間0.028米ドルです。730時間で計算すると、1台約20.44米ドルになります。

AWSの公開例では、100台・30TB・1日3.3％の変更率という条件で、DRサービス料金が2,044米ドルです。追加の資源を含めると、6,389.03米ドルになります（出典：AWS「AWS Elastic Disaster Recoveryの料金」、2026年8月確認）。

構成条件をそろえた公開料金の読み方

公開価格は、課金単位や追加料金も含めて読む必要があります。たとえば、Azure Site Recoveryは、各保護インスタンスの最初の31日間はサービス料金が無料です。

• Azure Site Recovery：保護インスタンスの単位で課金されます。
• NEC Cloud IaaS：構成ごとの公開価格例が示されています。
• 総額比較：公開例には開発や移行、監視、訓練が含まれません。台数や容量、変更率、回線、サポート時間などの条件をそろえます。

Azureでは、ストレージや操作、転送、復旧時のVMが別料金です（出典：Microsoft Azure「Site Recoveryの価格」、2026年8月確認）。NEC Cloud IaaSは、1台と50GBで月額3.6万円から、5台と10Mbps回線で月額35万円からです（出典：NEC「NEC Cloud IaaS DRサービス」、2026年8月確認）。

円換算や月額の数字だけで比べず、構成条件と含まれる作業範囲をそろえます。

災害復旧システムの見積もりを取る際のポイント

相見積もりでは、復旧対象と目標をそろえたうえで、初期費用と月額を分けて比べます。そのほかの項目は、次のとおり別々に扱います。

• 訓練：訓練を行うための費用です。
• 障害時の作業：障害発生時に行う作業の費用です。
• 追加容量：ストレージなどを増やす場合の費用です。
• 回線：通信回線の費用です。
• サポート：保守やサポートの費用です。

提案外の作業を見極めるため、RFPには、含むもの、含まないもの、前提条件、追加単価を明記します。

RFPに書く対象範囲と実測条件

RFPには、構成と業務の条件を記載します。条件をそろえておくと、各社の見積もりを同じ土台で比べられます。

• システム構成：台数、OS、仮想基盤、DB、データ容量、日次変更量、バックアップ世代を記載します。
• 業務条件：外部接続先、利用者数、ピーク時間、業務別RTO・RPO、許容できる手作業の範囲です。
• 運用・保護条件：運用時間、所在地、暗号化、監査ログ、個人情報の扱い、委託先管理、訓練の回数と時間帯です。

見積もりには、復旧後の業務受入れを含めます。認証やDNS、外部API、会計、顧客データの整合性などを検証します。

業務責任者が合格と判定するところまでを、範囲に含めます。RTOが起動を指すのか業務再開を指すのかを、契約と受入れ条件で区別しておきます。

開発会社の運用体制まで含めた比較

製品の知名度より、調査や業務合意、既存環境の理解、復旧後の確認まで担える会社かを見ます。

• 実行体制：調査やBIAの担当、業務合意の支援、認証・ネットワーク・DBへの理解です。
• 技術確認：復旧後の整合性を確かめられるか、提案者と実担当者の説明が揃うかを見ます。
• 運用・契約：証跡やSLA、休日夜間対応、連絡先、引継ぎ、解約時のデータ返却です。

社内で比較する際の配点の一例として、初期費用25％、要件適合25％、実績・技術力20％、運用・監視15％、訓練・改善10％、契約・移行条件5％とする方法があります。

見積もり段階で確認したい失敗しやすい前提

よくある失敗は、前提条件とリスクの一覧に書き出します。そのうえで、PoCやテストの担当者と期限を決めます。

• 復旧手順：バックアップはあっても順序がなく、訓練が起動確認だけで終わるケースです。
• 接続・容量：回線不足で複製が遅れ、認証基盤やDNSまで戻らない状態です。
• 人員・データ：担当者が不在で実行できず、復旧データにマルウェアが混入する事態です。

ランサムウェアでは、本番とオンラインバックアップが同時に暗号化される可能性があります。対策は、管理者の分離やMFA、別アカウント、改ざん不能な保管です。さらに、複数世代、環境分離、復旧前検査、感染前の復旧点の選択も確認します。

自然災害を想定したDRとは別のシナリオで、これらを検討します。

厚生労働省の医療情報システム安全管理ガイドライン第7.0版は、BCP確認表などを示しています。その確認表は、サイバー攻撃を想定しています（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年6月）。

発注前のチェックリスト

発注前には、守る業務と守らない業務、業務別のRTO・RPO、縮退運転、対象サーバーと依存関係を社内で整理します。

• 復旧設計：復旧順序と障害時の判断者、データの所在地と保管世代を定めておきます。
• 保護・訓練：ランサムウェア対策と、訓練の合格条件です。
• 費用：平常時、訓練時、本番復旧時のそれぞれの費用です。

未確定の項目があれば、選定を急がず、要件整理か短いPoCを先に行います。また、費用を先に固定すると、範囲や回線、試験の追加によって予算が増えることがあります。

業務の優先順位と受入れ条件を決めてから提案を受けると、必要な投資と、後回しにできる機能を区別できます。

災害復旧システム（DR）開発でよくある質問

導入前によく寄せられる疑問には、業務や構成によって答えが変わるものがあります。判断の順序を押さえておくと、相談や社内合意を進めやすくなります。

バックアップがあれば災害復旧システムは不要ですか？

不要とは限りません。バックアップはデータを戻すのに対し、DRは復旧先や起動順、ネットワーク、認証、業務確認まで含めて再開します。

停止を長く許容できる業務は、バックアップと手作業で復旧できる場合があります。一方で、許容時間が短い業務には、DRの設計と訓練が必要です。

RTOとRPOは何時間・何分にすればよいですか？

目標値は、業務の状況を見て決めます。

• 業務別の設定：業務ごとに、個別の値を決めます。
• 受注・決済：売上や顧客対応に直結する業務は、RTO・RPOを短くします。
• 分析・社内ポータル：翌日処理できる業務はRTO・RPOを長くするなど、停止影響と代替手段を比べます。
• 実測と見直し：PoCや訓練で実測し、未達なら構成を強化するか、業務目標を見直します。

DRはクラウドとオンプレミスのどちらがよいですか？

選ぶ際は、復旧目標や自社の制約と、方式ごとの特徴を比べます。

• 比較条件：RTO・RPO、データ所在地、既存資産、回線、体制、規制で選びます。
• クラウド：別拠点を用意しやすく、試験起動や自動化に適しています。
• クラウド費用：ストレージや転送は従量課金です。
• オンプレミス：既存構成を生かせる一方で、予備設備と保守要員が必要です。
• ハイブリッド：クラウドも含め、同じ条件で比べます。

ランサムウェア対策をDRに含めるべきですか？

含めるべきです。本番と同じ認証でつながるバックアップが暗号化されたり、感染したデータを復旧してしまったりするリスクがあります。

要件には、別権限や別アカウント、改ざん耐性、世代管理を盛り込みます。加えて、復旧前検査や感染前の復旧点の選択、サイバー攻撃訓練も要件に入れます。また、復旧後に業務部門が安全性を確認する流れも設計します。

災害復旧システムの開発期間はどのくらいですか？

期間の目安は、限定したDRaaSで1〜3か月、中小企業の複数サーバー構成で3〜6か月、中堅・大企業の基幹系や複数拠点で6〜12か月程度です。

この期間には、要件整理やPoC、テスト、業務受入れ、訓練が含まれます。資料の不足や設備連携、業務部門の合意に時間がかかると、期間は長くなります。

災害復旧システム（DR）開発の進め方まとめ

DR開発では、製品やクラウドを先に決めず、業務影響分析で守る業務を定めます。そのうえで、業務別のRTO・RPO、復旧順序、縮退運転について合意し、方式を比べます。

次に、PoCと復旧訓練で実測値を確かめます。要件整理から運用の定着までを、一つのプロジェクトとして進めます。

最初に決める「何を、いつまでに、どこまで戻すか」

費用は、対象台数や容量、変更率、RTO・RPOによって変わります。待機環境や回線、監視、訓練、セキュリティも影響します。

初期費用や月額に加えて、平常時、訓練時、本番復旧時の総額を試算します。さらに、復旧後の業務受入れまで契約に含めます。

こうした条件を先に決めておけば、起動後に業務を再開できない事態を防ぎやすくなります。

訓練結果の改善への反映

DRは、業務やシステム、脅威、担当者の変化に合わせて更新する運用です。訓練では、RTO・RPOや復旧順、連絡網に加えて、整合性とマルウェア検査の課題を見つけます。

見つかった課題は、手順書や構成、契約、教育に反映します。改善を続けることで、災害時に使える復旧システムになります。

▼全体ガイドの記事
・災害復旧システム（DR）開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。