災害復旧システム（DR）開発の発注/外注/依頼/委託方法について

災害復旧システム（DR）の発注・外注は、製品を買うだけではなく、RTO・RPO、復旧対象、訓練、障害時の責任分界まで要件化してから委託先を選ぶことが成功の近道です。

地震や水害だけでなく、ランサムウェア、停電、機器故障、設定ミスで業務システムが止まったとき、どの業務をいつまでに再開するかを決めておかなければ、バックアップがあっても復旧作業は始められません。本記事では、災害復旧システム（DR）を外部の開発会社やインフラベンダーへ発注する際の形態、RFP・要件整理、契約、費用相場、見積比較、委託先の選定方法を、2026年時点の公開情報を踏まえて解説します。

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

災害復旧システム（DR）を発注・外注する前に決めること

発注先探しから始めると、ベンダーが得意な製品や構成に議論が引っ張られます。先に「何を守るか」「どの状態まで戻すか」「誰が復旧判断をするか」を社内で決めると、提案内容と見積金額を同じ土俵で比較できます。

最初に業務影響分析（BIA）を実施し、停止した場合の売上、顧客対応、法令、安全、取引先への影響を業務ごとに整理します。販売、受発注、在庫、会計、認証、ネットワーク、外部APIのように依存関係も洗い出し、最重要業務から復旧する順番を決めます。

RTOは目標復旧時間、RPOは許容できるデータ損失時点です。たとえば「受注業務はRTO4時間・RPO15分、分析用データはRTO24時間・RPO24時間」のように、業務単位で設定します。すべてを最短で復旧しようとすると、待機サーバー、回線、ストレージ、監視、訓練の費用が膨らむため、経営層と業務部門が許容停止時間を合意することが重要です。

自治体向けの参考材料として、デジタル庁の「地方公共団体情報システム非機能要件の標準 第1.2版」2025年9月版では、自治体の規模、業務の性質、リスク受容方針に応じて、幅を持たせられる項目を自ら選択できる考え方が示されています（出典: デジタル庁、2025年）。民間企業でも、すべてのシステムに同じ高水準を適用せず、重要業務だけRTO・RPOを厳しくする設計が、予算とリスクのバランスを取りやすくします。

DRの対象は、本番サーバーだけではありません。データベース、ファイル、認証基盤、DNS、ネットワーク、ジョブ、ライセンス、外部SaaSや決済APIが復旧しなければ、画面が開いても業務は再開できません。最低限の機能だけを動かす縮退運転を含めて、対象外にするシステムと、その理由も記録します。

また、自然災害とランサムウェアでは復旧の考え方が異なります。バックアップ管理者を本番管理者と分け、MFA、最小権限、暗号化、別アカウントや別テナント、イミュータブル保管、復旧環境のネットワーク分離、復旧前のマルウェア検査を要件に含めます。NISTの「Ransomware Risk Management: A CSF 2.0 Community Profile」2025年初期公開草案も、ランサムウェアに備える準備・防御・検知・対応・復旧を一連の活動として整理しています（出典: NIST、2025年）。

災害復旧システム（DR）の発注形態はどれが適していますか？

発注形態は、クラウドや既製サービスを組み合わせる導入型、開発会社が個別設計する受託型、運用まで任せるマネージド型に分けて考えると整理しやすいです。自社の運用要員、既存環境、RTO・RPO、データ所在地、業務固有の連携を基準に選ぶことが大切です。

既存のバックアップ製品、レプリケーション製品、AWS Elastic Disaster Recovery、Azure Site Recoveryなどを活用する方式です。標準的な仮想マシンやファイルサーバーが中心であれば、ゼロからDR専用アプリケーションを作るより、導入設定と業務連携だけを外注する方が、納期と保守負担を抑えやすいです。

一方で、サービスの利用料だけでは、業務の復旧順序、DNS切替、認証、帳票、データ整合性、訓練まで整いません。RFPには、製品名だけでなく、誰が構成設計を行い、どこまで自動化し、どの頻度でテストし、障害時に何分以内に連絡するかを明記します。

オンプレミスの予備機、遠隔データセンター、クラウド、専用回線を組み合わせる方式は、既存設備やデータ所在地の制約がある企業に適しています。金融、医療、自治体、製造設備のように、個人情報、監査証跡、設備制御、特殊なデータベース、国外リージョン利用の可否が問題になる場合は、クラウドだけに寄せず、ハイブリッド案も同時に比較します。

スクラッチ型は、復旧オーケストレーターや社内業務との連携画面など、既製サービスで足りない部分を個別開発する場合に限って検討します。DRの中核をすべて独自開発すると、障害時の保守担当者が限られ、製品更新や環境変更のたびに改修が必要になります。既製機能を活用し、差分だけを開発会社へ委託する切り分けが現実的です。

RFPと要件整理はどこまで準備してから発注しますか？

RFPは完成した設計書ではありませんが、提案を比較できるだけの前提条件は必要です。少なくとも対象業務、現行構成、データ量と日次変更量、RTO・RPO、復旧順序、セキュリティ要件、運用時間帯、訓練方針、納期、予算の考え方を記載します。

成果物は、要件定義書、現行・目標構成図、依存関係一覧、データ移行計画、復旧手順書、切替・切戻し手順、テスト計画、訓練報告書、監視設計、SLA、運用引継ぎ資料まで分けて指定します。「DR環境を構築する」という一文だけでは、構築後に何が納品されるのかが曖昧です。

特に重要なのは、実測値を受け入れ条件にすることです。たとえば「受注データを15分以内の時点まで復元できること」「認証基盤を起動後30分以内に業務アプリから利用できること」「業務部門が受注登録と帳票出力を確認できること」のように、技術担当者だけでなく利用部門が判定できる表現にします。

現行の構成図が古い、担当者しか依存関係を知らない、データ変更率を測っていないという企業は少なくありません。その場合は、本番構築の前に現状調査フェーズを切り出し、サーバー、DB、認証、ネットワーク、外部API、ライセンス、回線帯域、バックアップ世代を確認します。

PoCでは、非本番または重要度の低いシステムを使い、レプリケーション、テスト復旧、データ整合性、復旧時間、回線使用量、月額料金を測定します。Azure Site Recoveryは、Azure VMやオンプレミスのVM・物理サーバーを対象に、復旧計画で多層アプリケーションの起動順序を定義し、業務を止めずに訓練できる機能を提供しています（出典: Microsoft Learn「Azure Site Recovery について」、最終更新2026年6月4日）。このような製品機能が自社環境で実際に使えるかをPoCで確認します。

契約形態と委託範囲はどのように設計しますか？

DRは、要件が固まっていない調査・企画と、仕様が確定した構築・移行、継続する監視・訓練で性質が違います。すべてを一つの契約にまとめるより、フェーズごとに成果と責任を分けると、追加費用や未確定要件の扱いを管理しやすくなります。

現状調査、BIA支援、RFP作成、方式比較、PoCは、作業を進めながら前提を明らかにする準委任契約が向いています。作業時間や体制、報告物を定め、調査で判明したリスクを次の構築見積に反映します。

構成、手順、テスト条件、納期、検収基準が確定した開発・設定・移行は、成果物を定めた請負契約を検討できます。ただし、クラウド料金や回線費、対象サーバーの増減、製品仕様による追加作業まで請負金額に含めると、どちらかに無理が生じます。固定範囲と変動範囲、変更管理の手順を契約書と別紙に明記します。

監視、バックアップ確認、障害一次受付、月次報告、復旧訓練は、月額の運用・保守またはマネージドサービス契約に分けます。契約では対応時間、一次回答と復旧支援の目標、計画メンテナンス、訓練回数、休日対応、現地作業費、再委託、データ返却、解約後の移行支援を確認します。

DRの障害対応では、ベンダーだけでは判断できない場面があります。災害宣言、フェールオーバーの承認、業務部門への再開通知、個人情報を含むデータの利用再開、フェールバックの実施を、顧客・開発会社・クラウド事業者のどこが決めるのかを表にします。

責任分界には、平常時のバックアップ確認と、障害時の復旧操作を分けて記載します。たとえば、ベンダーは監視アラートを受けて30分以内に連絡し、顧客の責任者が切替を承認し、ベンダーが復旧計画を実行するというように、時間、担当、判断、記録を具体化します。医療機関など委託先管理が重い業種では、厚生労働省の「医療情報システムの安全管理に関するガイドライン 第7.0版」2026年6月改訂や、保守委託機関編も契約確認の材料にします（出典: 厚生労働省、2026年）。

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

災害復旧システム（DR）の国内受託開発費には、対象台数、データ容量、変更率、RTO・RPO、復旧方式、回線、監視時間帯、訓練回数、既存環境との連携によって大きな差があります。以下は、リサーチノートに記載された業務システム導入相場と公開クラウド料金を組み合わせた、発注前の予算検討用レンジです。特定案件の見積金額ではありません。

重要システムを3〜10台に限定し、既存バックアップを活用する小規模なDRaaS導入では、初期50万〜300万円、月額5万〜30万円程度、導入期間1〜3か月が一つの目安です。クラウド設定、監視、訓練、手順書の範囲が広い場合は、このレンジを超える可能性があります。

10〜50台を別リージョンやデータセンターへレプリケーションし、復旧手順の自動化まで行う中小企業向けの構成では、初期300万〜1,500万円、月額20万〜100万円程度、構築3〜6か月が目安です。中堅・大企業の基幹系で、複数拠点、認証、ネットワーク、外部連携、定期訓練、SLAまで含める場合は、初期1,500万〜5,000万円超、月額100万〜500万円超、構築6〜12か月程度のレンジも検討します。

常時稼働の二重化、専用データセンター、専用回線、24時間監視、現地作業を組み合わせる方式は、初期3,000万円〜1億円超、月額数百万円以上になる可能性があります。ここまでの数字は、RTO・RPOを厳しくするほど待機計算資源と運用要員が必要になるという構造から算出した予算レンジであり、RFP提出後に対象範囲をそろえて再見積します。

AWS Elastic Disaster Recoveryは、アクティブにレプリケートしているソースサーバー1台あたり、1時間0.028米ドルという公式料金が示されています。AWS公式の例では、100台を730時間レプリケートするDRサービス部分が月2,044米ドルです。ただし、EBSなどのストレージ、レプリケーション用EC2、データ転送、テスト・復旧時の計算資源、サポート費は別に発生します（出典: AWS Elastic Disaster Recovery料金ページ、2026年8月確認）。

Azure Site Recoveryは、保護するインスタンスごとに最初の31日間が無料ですが、Azure Storage、ストレージトランザクション、データ転送、復旧時の仮想マシンには別料金がかかる場合があります（出典: Microsoft Azure Site Recovery価格ページ、2026年8月確認）。このため、見積書では「サービス利用料」「ストレージ・転送」「待機・復旧時の計算資源」「構築・移行」「監視・保守」「訓練・改善」を行単位で分けます。

さらに、クラウド料金は米ドル、為替、リージョン、割引契約、データ転送量で変動します。RFPでは、平常時、訓練時、本番復旧時の3パターンを月額試算してもらい、復旧が長期化した場合の上限や費用増加条件も確認します。

委託先選定と見積比較では何を確認しますか？

見積金額だけを比べると、安い提案に見えても、訓練、休日対応、監視、回線、復旧後の業務確認が別料金になっていることがあります。提案書と見積書を同じ評価シートで確認し、価格、要件充足、実績、体制、運用、セキュリティ、将来の移行性を総合的に評価します。

委託先には、災害復旧の構築実績だけでなく、実際に復旧訓練を行った事例、目標と実測のRTO・RPO、データ整合性の確認方法、復旧後の業務受入れまで質問します。「導入社数」だけでは、自社のDB、認証、外部連携、データ量に適用できるか分かりません。

体制では、営業担当者ではなく、要件定義の責任者、クラウド・ネットワーク担当、セキュリティ担当、運用責任者、障害時の指揮者が誰かを確認します。再委託先の範囲、担当者の交代時の引継ぎ、休日・夜間の連絡経路、現地対応の有無も、契約前に明らかにします。

相見積もりでは、各社に同じRFP、同じサーバー台数、同じデータ量、同じRTO・RPOを提示します。見積書の比較項目は、現状調査、設計、製品・クラウド、回線、構築、データ移行、テスト、訓練、監視、保守、ドキュメント、プロジェクト管理に分けます。

そのうえで、見積の前提条件と除外条件を読みます。たとえば、サーバー追加、データ容量の増加、回線帯域不足、ライセンス変更、外部APIの接続試験、休日作業、復旧が24時間を超えた場合の計算資源が、どちらの負担かを確認します。内訳が「一式」だけの提案は、安くても比較や変更管理が難しくなります。

よくある失敗は、バックアップはあるのに復旧順序がないことです。認証基盤より先に業務アプリを起動してログインできない、DNSの切替権限がなく利用者が接続できない、回線帯域が足りずRPOを満たせない、復旧データにマルウェアが残っているといった事態が起こります。

そのため、テストではサーバーが起動したかだけで合格にしません。復旧対象のデータ時点、アプリケーションの整合性、ユーザー認証、帳票出力、外部連携、業務部門の受注や出荷操作、監査ログ、切戻しまで確認します。災害だけでなく、ランサムウェア、誤操作、回線断、認証障害など脅威シナリオを分け、訓練結果と改善課題を次回の設計に戻します。

災害復旧システム（DR）の発注・外注に関するよくある質問

発注前には、費用、外注範囲、契約、バックアップとの違い、訓練の必要性について質問が多く寄せられます。ここでは、比較検討の場で判断を誤りやすい疑問へ直接回答します。

不要とは限りません。バックアップはデータを保存して戻せる状態にする仕組みで、DRは業務の優先順位、復旧環境、起動順序、切替判断、業務受入れまで含めて再開する仕組みです。バックアップを外注する場合も、復旧テストと業務部門の確認を契約範囲に含めることが大切です。

発注できます。現状調査、BIA、RTO・RPOの整理、方式比較、PoCを準委任で依頼し、その成果をもとに構築を再見積する進め方があります。対象業務や停止時の影響が整理できていないまま構築契約を結ぶより、企画・要件整理の段階を切り出す方が、後からの大幅な仕様変更を抑えやすいです。

小規模なDRaaS導入は初期50万〜300万円、月額5万〜30万円程度、中小企業の複数システムでは初期300万〜1,500万円、月額20万〜100万円程度が予算検討の目安です。基幹系の複数拠点構成や24時間監視、厳格なSLAを含めると、初期1,500万円超、月額100万円超になる可能性があります。公開クラウド料金、構築費、回線、監視、訓練を分けて見積もらないと、実際の総額は判断できません。

まとめ

災害復旧システム（DR）の発注・外注では、まずBIAで重要業務と依存関係を整理し、業務ごとにRTO・RPO、復旧順序、縮退運転を決めます。次に、クラウド・パッケージ型、ハイブリッド型、個別開発型を比較し、現状調査とPoCで実測値を確認してから、本番構築の範囲を確定します。

相見積もりでは、クラウドの利用料だけでなく、構築・移行、回線、監視、保守、復旧訓練、セキュリティ、復旧後の業務確認を含めて比較します。安さや製品名だけで決めず、RFPの成果物、責任分界、障害時の連絡、SLA、データ返却、実測RTO・RPOまで確認できる委託先を選ぶことが重要です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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