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

災害復旧システム（DR）の発注は、業務影響分析（BIA）とRTO・RPOの合意から始めます。そのあと、現状調査、PoC、構築、訓練の順に進めると、停止時に重要業務を再開できます。

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

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

災害復旧システム（DR）の発注・外注前に決める事項

発注先を探す前に、守る業務、復旧後の状態、復旧判断者を社内で決めておく必要があります。この条件をそろえておくと、提案内容と見積金額を同じ基準で比べられます。

BIAとRTO・RPOの事前合意

業務によって、停止時の影響は違います。そのため、まず業務影響分析（BIA）で、売上や顧客対応、法令、安全、取引先への影響を業務ごとに整理します。依存関係の対象には、販売、受発注、在庫、会計の業務システムがあります。認証、ネットワーク、外部APIも含まれます。

• 依存関係：どの業務が、どのシステムや外部APIに頼っているかを洗い出します。
• 復旧順序：依存関係を踏まえ、最重要業務から再開する順番を決めます。
• 目標値：業務ごとのRTO（目標復旧時間）とRPO（許容データ損失時点）。

目標値の設定例として、受注業務はRTO4時間・RPO15分、分析用データはRTO24時間・RPO24時間という組み合わせがあります。一方で、すべての業務を最短で復旧しようとすると、待機サーバーや回線などの費用が膨らみます。そこで、許容できる停止時間を経営層と業務部門が合意して決めます。

参考になるのは、デジタル庁の「地方公共団体情報システム非機能要件の標準 第1.2版」（2025年9月版）です。この標準では、自治体は規模、業務、リスク受容方針に応じて、幅を持たせられる項目を選べます（出典：デジタル庁、2025年）。

また、民間企業でも、重要業務に限ってRTO・RPOを厳しくすると、予算とリスクのバランスを取りやすくなります。

復旧範囲とセキュリティ境界の決め方

DRの対象には、本番サーバーに加えて周辺システムも含めます。周辺システムが戻らなければ、業務は再開できないからです。そこで、復旧対象と対象外、そしてその理由も記録しておきます。

• 対象の洗い出し：DB、ファイル、認証、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などを使います。
• 構成設計：担当者と自動化の範囲を、RFPで指定します。
• 検証と連絡：テスト頻度と、障害時に何分以内に連絡するか。

サービス利用料を払うだけでは、業務の復旧順序やDNS切替、認証は整いません。帳票やデータ整合性、訓練も、別途の準備が要ります。

ハイブリッド・個別設計型が向く制約の多い基幹系

既存設備やデータ所在地に制約がある企業は、オンプレミスや遠隔データセンター、クラウドを、専用回線でつないで組み合わせます。

• ハイブリッド案：金融や医療、自治体、製造設備などで、制約を確認します。
• 個別開発：既製サービスで足りない復旧オーケストレーターや連携画面に絞ります。
• 委託範囲：既製機能で足りる部分は使い、不足する差分だけを開発会社に依頼します。

個人情報の扱いや監査証跡、国外リージョンの可否などが問題になるなら、クラウド単独案と比べます。また、DRの中核を独自に開発すると、障害時に保守できる担当者が限られ、製品更新や環境変更のたびに改修も必要になります。

RFPと要件整理の準備範囲

RFPは、提案を比べるための前提条件をそろえる資料です。完成した設計書までは求めず、対象業務や現行構成、データ量と日次変更量を記載します。

RTO・RPOや復旧順序、セキュリティ要件は、提案の前提として必ず明記します。運用時間帯や訓練方針、納期、予算の考え方も、同じ資料に書いておきます。

RFPに書く復旧条件と成果物

「DR環境を構築する」とだけ書くと、納品の範囲があいまいになります。そこで、納めてもらうものを次のように分けて指定します。

• 設計資料：要件定義書、現行・目標構成図、依存関係一覧。
• 移行・復旧資料：データ移行計画、復旧手順、切替・切戻し手順。
• 検証・運用資料：テスト計画、訓練報告書、監視設計、SLA、運用引継ぎ資料。

受け入れ条件は実測値で定めます。技術担当者と利用部門の双方が判定できるよう、表現も具体的にします。

たとえば、受注データを15分以内の時点まで戻せることや、認証基盤の起動後30分以内に業務アプリから使えることを、条件にします。さらに、業務部門が受注登録と帳票出力を確認できることも、受け入れ条件に含めます。

現状調査とPoCの発注範囲

構成図が古いまま、依存関係を担当者しか知らない、データ変更率を測っていない企業は少なくありません。そうした場合は、本番構築の前に現状調査を切り出して発注します。PoCは、非本番環境または重要度の低いシステムで行います。

現状調査では、本番環境のつながりを把握し、次の観点で整理します。

• 調査対象：サーバーやDBから、認証、ネットワーク、外部API、ライセンスまで。
• 運用条件：回線帯域やバックアップ世代を確認します。
• PoC測定：複製やテスト復旧の結果から、整合性、復旧時間、回線使用量、月額料金を測ります。

Azure Site Recoveryは、Azure VMに加え、オンプレミスのVMや物理サーバーも対象にできます。製品の機能が自社環境で使えるかは、PoCで確かめます。

復旧計画で多層アプリの起動順を定義でき、業務を止めずに訓練できます（出典：Microsoft Learn「Azure Site Recovery について」、最終更新2026年6月4日）。

契約形態と委託範囲の設計

調査・企画、構築・移行、監視・訓練では作業の性質が異なるため、すべてを一つの契約にまとめず、フェーズごとに成果と責任を分けます。そうすると、追加費用や未確定要件を管理しやすくなります。

準委任・請負・サービス契約の使い分け

前提がまだ固まっていない段階と、作業内容が確定した段階では、契約の形を分けます。

• 準委任：現状調査やBIA支援、RFP作成、方式比較、PoCなど。
• 請負：構成や手順、テスト条件、納期、検収基準が確定している、開発・設定・移行の作業。
• 運用契約：監視やバックアップ確認、障害一次受付、月次報告、復旧訓練。

準委任では、作業時間や体制、報告物を決めます。そのうえで、調査で分かったリスクを次の構築見積に反映します。

クラウド料金や回線費、対象サーバーの増減、製品仕様による追加作業は変動しやすく、請負金額に含めると無理が生じます。固定範囲と変動範囲、変更管理の手順は、契約書と別紙に明記します。

運用契約では、対応時間や一次回答、復旧支援の目標を確かめます。計画メンテナンスや訓練回数、休日対応も、契約で確認しておきます。

現地作業費や再委託、データ返却、解約後の移行支援は、契約で取り決めておきます。

責任分界と障害時の判断権限の取り決め

障害時に誰が判断するかは、顧客、開発会社、クラウド事業者の間で明確にしておく必要があります。

• 復旧判断：災害宣言とフェールオーバーを、誰が承認するかを決めます。
• 業務再開：利用再開の通知と、個人情報を含むデータの利用判断。
• 切戻し：フェールバックの実施者と承認者を、事前に決めておきます。

平常時のバックアップ確認と、障害時の復旧操作は分けて考えます。例として、ベンダーはアラートから30分以内に連絡し、顧客責任者の承認後に復旧計画を実行します。時間、担当、判断、記録も、具体的に書いておきます。

医療機関などは、厚生労働省の「医療情報システムの安全管理に関するガイドライン 第7.0版」（2026年6月改訂）や保守委託機関編も、確認材料になります（出典：厚生労働省、2026年）。

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

国内の受託開発費は、対象台数やデータ容量と変更率、RTO・RPO、復旧方式によって変わります。さらに、回線や監視時間、訓練回数、既存環境との連携も、費用を左右します。

次の数字は、リサーチノートの業務システム導入相場と公開クラウド料金をもとにした、予算検討用のレンジです。特定の案件の見積額ではありません。

規模別の初期費用と月額費用

予算のレンジは、対象台数と復旧要件で変わります。下記の導入期間も、見積の比較に使います。

• 小規模：3〜10台、初期50万〜300万円、月額5万〜30万円、導入1〜3か月。
• 中小企業：10〜50台、初期300万〜1,500万円、月額20万〜100万円、構築3〜6か月。
• 中堅・大企業：初期1,500万〜5,000万円超、月額100万〜500万円超、構築6〜12か月程度。
• 常時稼働の二重化：初期3,000万円〜1億円超、月額数百万円以上の可能性。

小規模の目安は、重要システムに絞り、既存バックアップを使うDRaaSの場合です。設定や訓練の範囲が広がると、このレンジを超えることもあります。

中小企業向けの構成には、別リージョンやデータセンターへの複製と、復旧手順の自動化が含まれます。中堅・大企業の基幹系では、複数拠点の認証やネットワーク、外部連携、訓練、SLAまで含めることもあります。

専用施設や回線、24時間監視、現地作業を組み合わせた常時二重化は、さらに高額になる可能性があります。

ここまでの数字は、RTO・RPOを厳しくするほど待機用の計算資源と運用要員が必要になる構造をもとに算出した予算レンジです。RFPを出した後、対象範囲をそろえて見積を取り直します。

クラウド料金と外注費の別々の積算

クラウドサービスごとの課金条件と、見積で分けて扱う項目を確認します。

• AWSの単価：複製中のソースサーバー1台あたり1時間0.028米ドル。
• 見積の区分：サービス料、ストレージ・転送、計算資源、構築・移行、監視・保守、訓練・改善。

AWSの公式例では、100台を730時間複製した場合のサービス部分が月2,044米ドルです（出典：AWS Elastic Disaster Recovery料金ページ、2026年8月確認）。一方、Azure Site Recoveryは、保護するインスタンスごとに最初の31日間が無料です（出典：Microsoft Azure Site Recovery価格ページ、2026年8月確認）。

EBSなどのストレージや複製用EC2、データ転送のほか、テスト・復旧時の計算資源やサポート費は、別途発生します。Azureでは、Azure Storageやストレージ処理、転送、復旧時の仮想マシンに、別料金がかかる場合があります。

クラウド料金は、米ドルや為替、リージョン、割引契約、データ転送量によって変動します。そのため、平常時、訓練時、本番復旧時のそれぞれを試算しておきます。さらに、復旧が長引いたときの上限や費用増加の条件も確認します。

委託先の選定と見積比較の確認事項

見積額だけでは、訓練や休日対応、監視、回線、復旧後の業務確認が別料金かどうかは判断できません。そこで、価格だけでなく、要件の充足や実績、体制、運用、セキュリティ、将来の移行性まで、同じ評価シートで比べます。

復旧実績と運用体制の質問事項

導入社数だけでは判断しきれないため、自社の構成やデータ量に当てはまるかを確認します。

• 復旧実績：訓練の事例や、目標と実測のRTO・RPOを質問します。
• 検証方法：データの整合性と、復旧後に業務を受け入れる方法を尋ねます。
• 担当体制：要件定義、クラウド・ネットワーク、セキュリティ、運用、障害指揮の責任者を確認します。
• 連絡・引継ぎ：再委託や担当交代、休日・夜間の連絡経路、現地対応。

DBや認証、外部連携まで含めて自社環境で復旧できるかは、担当者に具体例を尋ねます。

見積の前提・除外・追加条件の比較

相見積もりでは、各社に同じRFPと台数、データ量、RTO・RPOを示します。

• 設計・構築：現状調査、設計、製品・クラウド、回線、構築、移行。
• 検証・運用：テスト、訓練、監視、保守、ドキュメント。
• 管理：プロジェクト管理費と追加作業の扱い。

見積の前提や除外条件では、サーバーの追加や容量増加、回線不足、ライセンス変更について、誰が負担するかを確認します。外部API試験や休日作業、復旧が24時間を超えた場合の計算資源についても、負担先を決めておきます。

内訳が「一式」だけの提案では、変更の管理も比較も難しくなります。

失敗例を想定した受入れテストの設計

受入れテストでは、サーバーの起動だけでなく、復旧後の業務まで確認します。

• 順序・接続：認証基盤の後にアプリを起動し、DNS切替後の接続を確かめます。
• データ・安全性：データ時点、整合性、マルウェアの有無を確認します。
• 業務・切戻し：認証、帳票、外部連携、受注・出荷、監査ログ、切戻しを試します。

認証基盤より先に業務アプリを起動すると、ログインできません。DNS切替の権限がなければ利用者は接続できず、回線帯域が足りなければRPOを満たせません。さらに、復旧データにマルウェアが残る事態も起こります。

災害やランサムウェア、誤操作、回線断、認証障害など、シナリオごとに訓練します。その結果と改善課題は、次の設計に反映します。

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

バックアップとの違いや、RFPが未完成のままでも発注できるか、費用の目安について、よく寄せられる質問に答えます。

バックアップを外注すれば災害復旧システム（DR）は不要ですか？

バックアップだけでDRが不要になるとは限りません。バックアップはデータの保存と復元を担いますが、DRは業務の優先順位や復旧環境、起動順序、切替判断、業務受け入れまで含めて、業務の再開を支えます。

バックアップを外注する場合も、復旧テストと業務部門の確認を契約範囲に含めておく必要があります。

RFPを作れない状態でも発注できますか？

発注できます。現状調査やBIA、RTO・RPOの整理、方式比較、PoCは、準委任で依頼できます。その成果をもとに構築を再見積もりすることで、企画段階と構築段階を分けて進められます。

対象業務や停止時の影響が未整理のまま構築契約を結ぶより、大幅な仕様変更を抑えやすくなります。

災害復旧システム（DR）の外注費用はいくらですか？

費用は規模や運用条件で変わるため、次の目安で比べます。

• 小規模DRaaS：初期50万〜300万円、月額5万〜30万円程度。
• 中小企業の複数システム：初期300万〜1,500万円、月額20万〜100万円程度。
• 複数拠点の基幹系：24時間監視や厳格なSLAを含め、初期1,500万円超、月額100万円超の可能性。

総額を判断するには、公開クラウド料金や構築費、回線、監視、訓練を分けて見積もることが必要です。

まとめ

発注前の確認事項

BIAで重要業務と依存関係を整理したうえで、業務ごとのRTO・RPO、復旧順序、縮退運転を決めます。

クラウド・パッケージ型、ハイブリッド型、個別開発型を比べます。そのうえで、現状調査とPoCで実測値を確かめてから、本番構築の範囲を確定します。

委託先選びの確認事項

クラウド利用料のほか、構築・移行や回線、監視まで比べます。保守、訓練、セキュリティ、業務確認も、あわせて確かめます。

価格や製品名だけで決めるのは避け、納品物、障害連絡、SLA、データ返却、実測の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を創業。