LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

可用性・DR設計の外注とは — 定義と委託範囲

可用性・DR（Disaster Recovery＝災害対策）設計の外注とは、システムの稼働継続性を担保するための技術設計を、専門知識を持つ外部パートナーに委託する取り組みです。クラウド移行作業やBCP（事業継続計画）の策定全体とは異なり、「システムが止まったときに、いつまでに、どこまで戻せるか」を設計する専門工程に絞った外注形態を指します。

RTO・RPOとは何か — クラウドベンダー公式定義

RTO（Recovery Time Objective＝目標復旧時間）とは、災害発生時に許容されるダウンタイムの上限時間です。Microsoft Azureの公式ドキュメント（2025年11月更新）では、災害発生時に許容されるダウンタイムの上限を時間単位で示す指標と定義されており^*1、「8時間のダウンタイム」のように表します。

RPO（Recovery Point Objective＝目標復旧時点）は、災害発生時に許容できるデータ損失の上限期間です。同Azure公式では「30分間のデータ」「4時間のデータ」のように時間単位で測定されると説明されています^*1。Google Cloud公式のDR計画ガイドでも同様に、RPOをアプリケーションからデータが失われている状態が許容される時間の上限として定義しています^*2。

RTO・RPOの値が小さい（短い）ほど、より高度な技術構成が必要となり、コストと設計複雑性が増加します。Google Cloud公式はこの点を明確に述べており^*2、外注発注時にも「どこまで求めるか」を数値で合意することが不可欠です。

「可用性設計」と「DR設計」の役割の違い

可用性設計とDR設計は密接に関連しますが、対象とするリスクの範囲が異なります。Azureの公式定義によると、可用性（HA）は「一時的な障害や断続的な障害が発生した場合でも、特定のワークロードが必要なレベルのアップタイムを日常的に維持できる状態」を指します^*1。

一方、DR設計は「自然災害、重大な人的エラー、重大なセキュリティインシデントなど、一般的でないリスク」に対処する計画です^*1。ネットワーク瞬断や単一サーバー障害はHAで対処し、リージョン全体の停止や大規模サイバー攻撃はDRで対処するという役割分担になります。外注先にどちらを依頼するかを事前に切り分けておくことで、スコープの曖昧さを防げます。

DR戦略4分類とRTO/RPOのトレードオフ

DR戦略には、コストと復旧速度のバランスによって複数のアプローチがあります。AWS公式ホワイトペーパー「Disaster Recovery of Workloads on AWS」では、4つの戦略が体系的に整理されています^*3。外注先に要件を伝える際、この分類を使うと技術選択の共通言語になります。

出典：AWS「Disaster Recovery of Workloads on AWS」ホワイトペーパーの4戦略分類^*3をもとに、RTO/RPOとコスト水準を整理。RTO・RPOの数値は一次資料での個別確認を推奨します（市場参考値・一次資料ではありません）。

Google CloudのDR計画ガイドでは、同様の概念をコールド型・ウォーム型・ホット型の3分類で整理しています^*2。「RTO・RPOの値が小さいほどコストと管理複雑性が増加する」という原則はどのクラウドプラットフォームにも共通します。外注先との議論では、この表を起点にして目標水準を合意することが、スコープ確定の近道になります。

なお、Azureのリスク分類では、リージョン全体の停止がDRリスクに分類されますが、アクティブ/アクティブ構成で複数リージョンを使用するワークロードでは同じリージョン停止がHAリスクとして分類されるケースもあります^*1。このような境界線も外注先と事前に確認しておく必要があります。

外注でカバーする4つの設計領域

DR設計の外注範囲は大きく4つの領域に分かれます。それぞれを把握しておくことで、発注時の見積もり取得とスコープ交渉が具体的になります。

バックアップ設計 — RPO起点の設計

バックアップ設計はRPOを起点として考えます。どの時点のデータを残すか、バックアップ頻度（1日1回・1時間ごと・継続的）をどう設定するかで、RPOが決まります。AWS公式は「バックアップの頻度がRPOを決定する」と明記しており^*3、外注先にはこの頻度設定とバックアップ先リージョンの選定を依頼します。

バックアップのみではデータ復旧に時間がかかるため、RTOが長くなる傾向があります。「RTOを短縮したい」という場合はバックアップ設計だけでは不十分で、次のレプリケーション設計との組み合わせが必要です。

レプリケーション設計 — リアルタイム同期

レプリケーション設計は、データをリアルタイムまたは準リアルタイムで別リージョン・別データセンターに同期させる設計です。AWS公式のPilot Light戦略では「継続的なデータレプリケーションが低RPOに有効なアプローチ」とされています^*3。

一方、継続的なレプリケーションはデータ破壊（ランサムウェア等）が即座に伝播するリスクも伴います。AWS公式はこの点を「data corruption or destructionに対してはバックアップとの組み合わせが必要」と指摘しており^*3、外注先に対してはレプリケーション単独ではなくバックアップとのセット設計を求めることが重要です。

マルチリージョン・クラスタ構成設計

Warm StandbyやMulti-site Active/Activeを採用する場合、DRリージョンへのインフラ展開が必要です。AWS公式はこの展開を「Infrastructure as Code（IaC）なしに複数リージョンへの安定したデプロイは難しく、RTOが伸びる」と指摘しています^*3。CloudFormation・Terraform等のIaCを用いたマルチリージョン展開は、専門知識なしでは設計・維持が困難な領域です。

外注先に求めるスキルとして、対象クラウドのIaCツール経験と、データベースのリージョン間レプリケーション（Aurora Global Database・Azure SQL Geo-Replication等）の設計経験を確認することが実務上重要です。

フェールオーバー自動化とテスト計画

DR設計の仕上げとして、「フェールオーバーを自動で起動するか手動で起動するか」の判断と、定期的なDRドリル計画の策定があります。Azure公式は「DR計画は定期的に見直して更新する必要があり、プロセスとして管理する」と述べており^*1、AWS公式も「定期的にDR戦略を評価・テストすることが不可欠」としています^*3。

外注先との契約にDRドリル実施と報告書作成を含めるかどうかは、事前に明確にしておく必要があります。フェールオーバーの実行はコントロールプレーン（管理API）依存の手順が多く、AWS公式は「コントロールプレーンよりデータプレーン（実行系）に依存する手順の方がDR時の信頼性が高い」と解説しています^*3。この技術的詳細を外注先が理解しているかどうかも、選定の評価軸になります。

外注発注の5ステップ — 要件整理からベンダー選定まで

可用性・DR設計を外注する際は、以下の5つのステップを順に進めることで、スコープと責任範囲を明確にできます。

1. 業務継続要件の洗い出し → RTO/RPO目標を決める
2. 現状アーキテクチャの棚卸し
3. クラウド戦略（AWS/Azure/GCP）の方向性確認
4. RFPと要件定義書の作成・ベンダー選定
5. 実装・テスト・定期的なDRドリル

ステップ1では、システムが止まった場合の事業影響（売上損失・顧客への影響・法的リスク）を業務部門と合意し、「何時間のダウンタイムまで許容できるか」「何時間分のデータ損失まで許容できるか」を数値化します。Azureの公式解説では「RPOとRTOを指定するプロセスによって、固有のビジネス上の懸念事項（コスト・影響・データ損失）の結果として、ワークロードのDR要件が効果的に作成される」とされています^*1。この数値がないまま外注先に相談すると、見積もりが過大になるか、設計がないまま契約に進んでしまうリスクがあります。

ステップ2では、現行システムのデータベース構成・アプリサーバー数・ネットワーク構成・既存バックアップ設定を文書化します。外注先がアーキテクチャを理解していない状態でDR設計を進めると、設計後に「現行構成と整合しない」という手戻りが発生します。

ステップ3では、将来的にAWS・Azure・Google Cloudのどのプラットフォームを主とするかを確認します。DR設計のアーキテクチャ（使用するサービス・IaCツール・フェールオーバー方式）は、プラットフォームによって大きく異なります。移行計画が未確定な場合は、外注先に「クラウド中立の設計」を要件として明示することが有効です。

ステップ4では、ステップ1〜3を踏まえてRFP（提案依頼書）を作成し、ベンダーに提示します。RFPには「RTO目標・RPO目標・対象システム範囲・DRドリル頻度・成果物（設計書・Runbook・テスト報告書）・保守体制」を明記します。複数ベンダーから提案を取得し、設計アプローチ・実績・価格を比較することが品質確保につながります。

ステップ5では、設計・実装後にDRドリル（フェールオーバーのリハーサル）を実施します。AWS公式は「テストせずに本番の災害で初めて試みると大きな問題に直面する可能性が高くなる」と述べており^*3、ドリル結果をもとにRunbookを更新するサイクルを外注契約に組み込む設計が望まれます。

ベンダー選定の評価軸と発注リスク

元請（プライムベンダー）型と多重下請け型の違い

DR設計の外注先を選ぶ際、ベンダーが「元請（プライムベンダー）として設計から実装まで一貫して担うか」それとも「設計のみ受けて実装を再委託する多重下請け型か」を確認することが重要です。

多重下請け型では、設計意図が下流に伝わりにくく、障害発生時の責任者が曖昧になる問題が生じやすくなります。元請（プライムベンダー）型であれば、RTO/RPO目標から最終的なDRドリル報告書まで、単一の窓口で責任を持ちます。発注側にとっては、問題発生時の連絡先が一本化される点が主要なメリットです。

契約形態（請負 vs 準委任）と責任範囲

DR設計の外注では、契約形態によって責任範囲が変わります。請負契約は成果物（設計書・構成図・Runbook等）の完成を約束する形態で、仕様通りの成果物が得られない場合は契約不適合責任が発生します。準委任契約は作業工数に対して対価が発生する形態で、成果の保証はありませんが、要件が変化しやすいDR設計の初期段階（要件定義・現状調査）に向いています。

実務上は「要件定義・現状調査フェーズ＝準委任」「設計書・Runbook作成フェーズ＝請負」と分けるケースが多く見られます。外注先との契約交渉時には、フェーズごとの契約形態と成果物の定義を明確にしておくことが、後のトラブル回避につながります。

RTO目標だけ決めてアーキテクチャ未定義のリスク

発注側がよく陥るリスクの一つが、「RTO：1時間以内」という目標だけを提示して、具体的なアーキテクチャ要件を外注先に丸投げするケースです。この状態では、外注先がWarm StandbyとPilot Lightのどちらを提案するかで見積もり額が数倍変わる可能性があります。

また、「DRを構築したが実際に動作するか確認していない」という状態も重大なリスクです。AWS公式は「DR戦略は定期的に評価・テストすることが不可欠」と明記しており^*3、Azure公式も「DRドリルにより、RTO達成の実現可能性を検証できる」と述べています^*1。契約に「年1回以上のDRドリル実施と報告書提出」を盛り込むことが、設計の形骸化を防ぐ実践的な対策になります。

必要スキルの観点では、DR設計を内製で進める場合、クラウドアーキテクト・ネットワークエンジニア・データベース管理者の知識が同時に必要です。加えて、対象クラウドの認定資格（AWS Solutions Architect・Azure Solutions Architect Expert等）レベルの実務経験を持つ人材を複数名確保する必要があります。このレベルの人材を採用で確保するには長期のリードタイムを要することが多く、専門パートナーへの委託が現実的な選択肢となる場合があります。

まとめ：可用性・DR設計外注の3つの判断軸

本稿では、可用性・DR設計の外注について、RTO/RPOの定義から発注ステップ、ベンダー選定まで整理しました。要点を3つに集約すると次の通りです。

第一に、RTO・RPO目標値の設定は外注成功の絶対条件です。数値がなければベンダーも設計方針を決められず、見積もりの精度が下がります。Azureの公式解説が示す通り、RTOとRPOの合意プロセス自体がDR要件書の作成につながります。

第二に、DR戦略の4分類（Backup and Restore・Pilot Light・Warm Standby・Multi-site Active/Active）を理解した上で外注先と議論することが、スコープの共通認識につながります。AWS公式ホワイトペーパーに基づくこの分類は、技術選択とコスト試算の共通言語です。

第三に、DRドリルを契約に組み込むことが設計の形骸化を防ぎます。構築しただけで未テストのDRは、実際の障害時に機能しないリスクがあります。年1回以上のドリル実施と報告書提出を外注契約の成果物に含めることが、長期的な可用性維持につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「ビジネス継続性、高可用性、ディザスターリカバリーとは」（2025年11月更新）
2. *2　出典：Google Cloud「DR計画ガイド」
3. *3　出典：Amazon Web Services「Disaster Recovery of Workloads on AWS（クラウドでのディザスターリカバリーオプション）」

Tweet