ディザスタリカバリ（DR）を設計するうえで、最も根幹となる指標がRPO（Recovery Point Objective：復旧目標時点）とRTO（Recovery Time Objective：復旧目標時間）です。
この2つの値を正確に理解し、適切に設定することなしに、実効性のあるDR計画を構築することはできません。
しかし実際の現場では「RPOとRTOの違いがわかりにくい」「どうやって数値を決めればいいかわからない」という声もよく聞かれます。
本記事では、RPOとRTOの基本概念から、目標値の設定方法・計算の考え方・SLAとの関係まで、初心者にもわかりやすく体系的に解説していきます。
DR計画の見直しを検討している方や、これからDR設計に取り組む方にとって、確かな道標となる内容です。
RPOとRTOはDR設計の出発点となる最重要指標である
それではまず、RPOとRTOがなぜDR設計において不可欠な指標であるかについて解説していきます。
RPOとRTOは、システム障害が発生した際にどの程度のデータ損失とダウンタイムを許容できるかを定量的に示したものです。
この2つの数値を明確に定めることが、DR方式の選定・システム設計・コスト計画すべての基準となります。
RPO（復旧目標時点）の定義と意味
RPO（Recovery Point Objective）とは、障害が発生した際に「どの時点のデータまで戻ることを許容するか」を表す指標です。
わかりやすく言えば、「最大でどれだけのデータが失われてもよいか」を時間軸で表したものです。
RPO＝0であれば、データ損失はゼロを目標とすることを意味し、RPO＝4時間であれば最大4時間分のデータ損失を許容することになります。
RPOが短ければ短いほど、より頻繁なバックアップやリアルタイムのデータ同期が必要になります。
金融取引システムや医療記録システムのような、常にデータが更新され続けるシステムではRPOをできる限りゼロに近づけることが求められる場面も多いでしょう。
RTO（復旧目標時間）の定義と意味
RTO（Recovery Time Objective）とは、障害発生から業務が再開できる状態になるまでの時間の目標値です。
「いつまでにシステムを復旧させなければならないか」を示す指標であり、ダウンタイムの上限を意味します。
RTO＝1時間であれば、障害から1時間以内にシステムを稼働状態に戻すことが目標となります。
RTOが短いほど、より高度なフェイルオーバー技術と充実したDRインフラが必要になります。
RTOはユーザーや顧客が感じる「サービスの止まっていた時間」に直結するため、ビジネスへの影響を計る直接的な指標でもあります。
RPOとRTOの関係とトレードオフ
RPOとRTOはどちらも「小さいほどよい」指標ですが、その実現コストは指数的に増大します。
RPOとRTOを極限まで小さくしようとすれば、リアルタイムレプリケーション・ホットスタンバイ構成・高帯域ネットワークなど、非常に高コストなインフラが必要になります。
逆にRPO・RTOの許容値を大きくすれば、定期バックアップ＋コールドサイト構成でも対応できるため、コストを大幅に抑えることが可能です。
ビジネスの要件と投資予算のバランスを考慮したうえで、現実的な目標値を設定することが最も重要です。
RPOとRTOの目標値の設定方法
続いては、RPOとRTOの具体的な目標値をどのように設定すればよいかを確認していきます。
目標値は感覚や慣例で決めるのではなく、ビジネスインパクト分析（BIA）に基づいて定量的に算出することが推奨されています。
ビジネスインパクト分析（BIA）とは何か
BIA（Business Impact Analysis：事業影響度分析）とは、システム停止がビジネスに与える影響を金銭的・業務的に定量化する分析手法です。
たとえば「1時間のシステム停止によって売上機会損失が100万円発生する」「4時間以上停止すると顧客への補償が必要になる」といった形で影響を数値化します。
BIAの結果をもとにRTO・RPOを設定することで、DR投資の優先順位と適切なコスト配分を合理的に決定できます。
BIAは一度実施すれば終わりではなく、業務内容や組織の変化に合わせて定期的に見直すことが重要です。
業務の重要度に応じたRPO・RTOの分類
すべてのシステムに同じRPO・RTOを設定する必要はありません。
業務の重要度と停止時の影響に応じて、システムをいくつかの層（ティア）に分類し、それぞれ異なる目標値を設定するアプローチが実用的です。
| ティア | 対象システムの例 | RPOの目安 | RTOの目安 |
|---|---|---|---|
| ティア1（最重要） | 基幹業務・決済・医療記録 | 0〜15分 | 15分〜1時間 |
| ティア2（重要） | 社内ポータル・在庫管理 | 1〜4時間 | 4〜8時間 |
| ティア3（通常） | 社内掲示板・統計レポート | 4〜24時間 | 24〜72時間 |
| ティア4（低優先） | アーカイブ・社内ブログ | 24時間以上 | 72時間以上 |
このようにシステムを分類することで、限られた予算の中でDR投資の優先順位を適切に設定できます。
ステークホルダーとのRPO・RTO合意形成
RPOとRTOは技術部門だけで決めるものではなく、経営層・事業部門・IT部門が協議のうえで合意することが不可欠です。
事業部門は「できるだけ早く、データ損失なく復旧してほしい」と考えますが、IT部門は実現可能なコストと技術的制約を考慮する必要があります。
経営層の最終承認のもとで目標値を確定させることで、DR計画全体の実行力と組織的なコミットメントが高まります。
RPOとRTOの計算方法と実際の例
続いては、RPOとRTOの計算・評価に使われる考え方について解説していきます。
数値として目標を定めたら、現状のシステムがその目標を達成できているかを検証する作業が必要です。
現状のRPOを評価するバックアップ頻度との照合
現状のRPOは、バックアップや同期の頻度から概算することができます。
例：毎晩23時にバックアップを取得する場合
翌日の22時50分に障害が発生すると、直近のバックアップは前日の23時のものになります。
この場合、最大で約23時間50分分のデータが失われる可能性があるため、現状のRPOは約24時間と評価できます。
この評価を通じて、目標とするRPOと現実のギャップを把握し、改善策を検討します。
現状のRTOをテストで測定する方法
RTOの現状値を把握するためには、実際にDRテスト（フェイルオーバーテスト）を実施し、復旧にかかった時間を計測することが最も確実な方法です。
テストなしに「おそらく2時間で復旧できる」と見積もっていた場合でも、実際には6時間以上かかるケースが珍しくありません。
定期的なDRテストによって実際のRTOを把握しておくことが、信頼性の高いDR計画の前提条件です。
SLAとRPO・RTOの関係を整理する
SLA（Service Level Agreement：サービスレベル合意書）は、サービス提供者と利用者の間でシステムの可用性や復旧時間について合意した文書です。
SLAには「稼働率99.9%以上」「障害対応開始まで1時間以内」「復旧完了まで4時間以内」といった形で具体的な指標が盛り込まれます。
SLAで定めたRTO・RPOの基準を、DR計画の設計目標に落とし込むことで、SLA遵守とDR整備が一体化した取り組みとなります。
クラウドサービスや外部委託のシステムについては、ベンダーのSLAが自社のRTO・RPO要件を満たしているかを契約前に確認することが重要です。
RPO・RTO目標達成のための技術的アプローチ
続いては、設定したRPO・RTO目標を実際に達成するためにはどのような技術的手段があるかを整理していきます。
技術の選択はRPO・RTOの要求水準と予算によって大きく変わります。
同期レプリケーションによるRPO＝0の実現
RPOをゼロにするためには、プライマリとセカンダリのデータを常に一致させる同期レプリケーションが必要です。
書き込みがプライマリとセカンダリの両方に完了してから処理が完結するため、データ損失が発生しません。
ただし、遠距離間での同期レプリケーションはネットワーク遅延（レイテンシ）の影響を受けるため、物理的な距離にも限界がある点に注意が必要です。
非同期レプリケーションによるRPO短縮
完全同期が難しい場合は、非同期レプリケーションでRPOをできる限り短縮するアプローチが現実的です。
数分〜数十分ごとにデータを同期することで、RPOを数十分以内に抑えることができます。
クラウドDRサービスの多くはこの非同期レプリケーションを採用しており、コストと性能のバランスが取りやすい方式です。
自動フェイルオーバーによるRTO短縮
RTOを最小化するためには、障害検知から復旧までの手順を可能な限り自動化することが有効です。
監視システムが障害を自動検知し、あらかじめ定義されたシナリオに従って自動でフェイルオーバーを実行する仕組みを構築することで、人的判断を待たずに復旧プロセスを開始できます。
RTOを劇的に短縮するためのポイントは「障害検知の自動化」「フェイルオーバーの自動化」「復旧手順の事前定義・文書化」「定期的なDRテストによる手順の習熟」の4つに集約されます。
このいずれかが欠けても、目標RTOを安定して達成することは困難になります。
まとめ
ディザスタリカバリにおけるRPOとRTOの定義・設定方法・計算の考え方・達成技術について体系的に解説してきました。
RPOは「どれだけのデータ損失を許容するか」、RTOは「どれだけのダウンタイムを許容するか」を示す指標であり、DR設計のすべての判断はこの2つの数値から始まります。
BIAを通じてシステムの重要度と業務影響を定量化し、経営層とステークホルダーが合意したうえでRPO・RTOを設定することが、実効性あるDR計画への第一歩です。
そして設定した目標値は、定期的なDRテストによって達成可能かどうかを継続的に検証していきましょう。
