クラウドサービスの営業資料に「自動バックアップ」「高可用性」「災害対策済み」と書いてあっても、障害が起きたとき何時間で使える状態に戻るのか、どこまでのデータを取り戻せるのかは分かりません。
企業がBtoB SaaSやクラウドシステムの導入を検討するとき、この二つを整理する指標がRTO（Recovery Time Objective）とRPO（Recovery Point Objective）です。似た用語ですが、前者はサービス復旧までの時間、後者は復旧可能なデータの時点を扱います。今回はAWS、Google Cloud、NISTの公開資料をもとに、意味、限界、提案書での説明方法を整理します。
RTOとは？復旧までに許される時間
RTOは、障害によりサービスが中断してから、必要な機能を復旧するまでの最大許容時間を表す目標です。AWS Well-Architectedの信頼性の柱では、サービス中断から復旧までに許容できる最大の遅れと説明しています。
たとえばある業務サービスのRTOを「4時間以内」と決めた場合、それは対象とする障害のもとで、4時間以内の復旧を目指すという意味です。実際の復旧所要時間が常に4時間以内だった証明でも、すべての種類の障害に対する契約上の保証でもありません。
どこまで戻れば「復旧」とみなすかも重要です。ログイン画面が表示された時点なのか、重要なAPIが使えることなのか、顧客の処理が正常に完了できることなのかで、完了時刻が変わります。
RPOとは？どの時点までのデータを取り戻すか
RPOは、障害前のどの時点のデータまで復旧できる必要があるかを表す目標です。AWSの定義では、最後の復旧地点からサービス中断までに許容する時間の長さを指します。Google Cloudも、大きなインシデントの際に許容できるデータ損失期間として説明しています。
つまりRPOが1時間なら、最大で直近1時間分に相当する更新を失うリスクを想定した復旧設計を考えます。ただし、これは実際のデータ損失が必ず1時間分生じる、あるいは1時間以内なら損失が軽微という意味ではありません。
RPOはデータの件数や金額ではなく、時間で表す目標です。1時間の間に更新されたレコード数や業務への影響は、サービスの利用状況によって異なります。
具体例：7時に停止、5時のバックアップから復元したら
以下は実在の障害事例ではない、説明のための架空例です。
- 午前5時：正常なバックアップを取得した。
- 午前7時：業務システムが停止した。
- 午前9時：バックアップから必要な機能の復旧が完了した。
この例では、障害発生から復旧までの実績時間は2時間、復元したデータが停止時点より2時間古いため、失われる可能性があるデータの更新期間は2時間です。
ここでの2時間は「実際に起きたケースの測定値」という設定であり、そのシステムのRTO・RPOとして事前に定めた目標とは別です。また、バックアップが正しく復旧でき、復旧地点までのデータを利用できるという仮定を置いています。バックアップが破損していれば、この計算どおりにはなりません。
可用性、SLA、MTTRとどう違う？
RTO・RPOは災害復旧（DR）の計画で使われる目標です。稼働率は一定の期間にサービスを利用できた割合などを示す指標で、必ずしも個別の大規模障害での復旧時間やデータ復元能力を示しません。
またMTTR（平均復旧時間）は、複数の障害から算出する平均値として使われる指標です。AWSの公式解説は、単一の中断について設定する最大許容時間のRTOとは区別しています。平均が短くても、一部の障害だけ復旧が非常に長い場合があります。
SLAはサービス水準に関する合意で、対象、計測、補償、責任などは契約ごとに異なります。RTO・RPOの目標が資料に記されていても、それがすべて顧客への法的保証になるわけではありません。SLA・SLO・SLIの全体像はSLA・SLO・SLIの違いの記事で扱っています。
バックアップを取っていれば、RTO・RPOを達成できる？
バックアップは重要な構成要素ですが、保存しているという事実だけでは目標達成を確認できません。復旧時にバックアップへアクセスできるか、データは正常か、必要なアプリケーションや認証基盤が動くか、復元に何時間かかるかを確認する必要があります。
例えば毎日バックアップしていても、データベースの容量が大きければ復元に時間がかかる場合があります。バックアップの時間間隔が短くても、認証や外部接続が復旧できず業務を再開できなければ、RTOは満たせません。
一方、複製をリアルタイムに近づけても、誤操作や悪意ある改ざんがコピー先へ伝播してしまう可能性があります。削除・改ざんからの回復、バックアップの保護、復旧可能な時点の管理は、単純な同期速度とは別に設計する必要があります。
目標は製品の性能表からではなく、業務への影響から決める
Google CloudのDR計画ガイドは、復旧計画を事業継続の一部として捉え、ビジネス影響分析からRTO・RPOを考えることを説明しています。業務が停止することによる影響、失われたデータを再入力できるか、顧客や取引先への影響などを確認します。
同じ企業でも、受発注を処理する基幹機能と、数日前の集計を表示する社内ダッシュボードでは、必要な復旧目標が異なるかもしれません。
- 停止時の影響：業務が止まると、何ができなくなり、誰に影響するか。
- データの重要性：最後の正常な記録が古い場合、再入力や検証が可能か。
- 依存関係：認証、ネットワーク、外部API、サポートなど何が必要か。
- 必要な体制：復旧操作、連絡、意思決定、切替を誰が行うか。
- 費用と複雑性：目標を短くするための冗長化や運用コストは妥当か。
Google Cloudは一般に、より短いRTO・RPOを求めるほど費用や運用の複雑性が増す傾向にも言及しています。したがって、どのシステムにも「RTOゼロ・RPOゼロ」を要求するのではなく、重要度に合わせて必要条件を決めます。
BtoB SaaSの提案資料で、確認したい7項目
営業やマーケティングがRTO・RPOを説明する場合、技術担当から数字を受け取るだけでは不十分です。どの範囲に対する値か、顧客側でも必要な作業があるかを確認しましょう。
- 1. 対象：製品全体、特定の機能、API、保存データのどれに適用されるか。
- 2. 障害の範囲：単一機器、ゾーン、リージョン、誤操作、サイバー攻撃のどれを想定するか。
- 3. 目標値：時間の数値は社内目標か、契約条件か、過去の実績か。
- 4. 復旧完了：ログイン可能、重要APIの応答、業務処理の再開など、何をもって完了とするか。
- 5. データの扱い：バックアップの間隔、整合性、復旧可能な時点、顧客の再入力の必要性。
- 6. 責任分界：ベンダー、顧客、外部連携先それぞれが何を行うか。
- 7. 検証：復旧訓練をいつ、どの条件で行い、未確認事項が残っているか。
これらは当サイトの編集上のチェック項目です。特定の業法・契約が同じ7項目を必須と定めるという意味ではありません。
DR計画とBCPの関係
DR（Disaster Recovery）は主にシステムやデータの復旧を扱います。一方、BCP（事業継続計画）は、情報システムだけでなく、人員、拠点、代替業務、取引先や顧客との連絡も含む広い問題です。Google CloudのDR計画ガイドでも、DRを事業継続計画の一部と位置づけています。
例えばSaaSが復旧しても、顧客側の担当者が不在で業務を再開できなければ、企業全体の事業が直ちに平常化するとは限りません。復旧目標を顧客へ説明するときは、ベンダーが責任を持つ範囲と、顧客側で必要となる手順を区別します。
障害発生中の顧客への告知や復旧後の説明については、BtoBサービス障害時の案内方法で別途整理しています。
復旧目標を「検証済み」と呼ぶために必要なこと
復旧手順の文書があるだけで、設定された時間内に本番相当のデータと機能を戻せるとは限りません。AWS Well-Architectedは、復旧目標を決めるだけでなく、戦略の実装・テスト・検証を推奨しています。
復旧訓練では、手順が実行可能か、担当者が必要な権限を持つか、別の環境で動かせるか、依存サービスが停止したときの対応はあるか、といったことを確かめます。結果を記録し、目標との差がある場合は運用と設計へ戻します。
訓練結果を営業資料へ使う場合にも、いつ、どんな障害を模して、何を成功と見なしたかを明記する必要があります。「訓練で成功した」ことをすべての障害に対する保証へ広げてはいけません。
架空例：導入検討の途中で「データは戻せるか」と質問された
ある会社がクラウド型の業務サービスを検討しているという架空例です。営業が「当社は自動バックアップ済みなので大丈夫です」と説明しましたが、顧客の情報システム担当は、障害時にどこまでの記録が戻るか、重要な処理をいつ再開できるか知りたがっています。
そこで営業は、技術部門・サポート・法務とともに、対象機能、RTO、RPO、訓練結果、契約上の保証の範囲を確認します。まだ測定できていない項目は「未検証」と明示し、追加の調査が必要な点を残します。
この進め方は受注率を高める万能な手法ではありません。しかし顧客が利用条件を自分で確かめられることは、誤解を避けるうえで重要です。
まとめ：戻るまでの時間と、戻るデータを分ける
RTOはサービスや業務が復旧するまでの許容時間、RPOはどの時点までのデータを復旧する必要があるかを示す目標です。二つは異なる問いに答えており、高い稼働率や自動バックアップだけでは両方の達成を保証できません。
何が、どの障害条件で、いつ、どこまで回復するのか。 数値を比較する前にその定義と測定の範囲を揃えることが、BtoB SaaSの信頼性を正しく説明する第一歩です。
関連する品質指標やデータ管理はSLA・SLO・SLIの違いとCRM・MAのデータ連携と安全な運用設計でも解説しています。
参考資料・出典
- AWS Well-Architected Framework「ディザスタリカバリの目標」：RTO・RPOとMTTRの違いに関する公式定義。
- AWS「復旧目標を定義する」：障害時の目標、事業上の影響と検証の重要性。
- Google Cloud「Disaster recovery planning guide」：事業継続、RTO・RPOの意味、費用・複雑性との関係。
- Google Cloud「Architecting disaster recovery for cloud infrastructure outages」：障害範囲と回復アーキテクチャの関係。
- NIST Glossary「Recovery Time Objective」：RTOの出典を示す用語定義。
- NIST Glossary「Recovery Point Objective」：RPOの出典を示す用語定義。
記事中のシステム停止例・顧客案件は架空の説明例です。7項目の確認表や資料の作り方は当サイトの編集上の実務提案で、上記資料が同じ手順の営業成果を実証したものではありません。法的な保証範囲は実際の契約文書で確認してください。