止められないプロダクトのためのバックアップ／復旧戦略：RPOとRTOの決め方（計算・設計・テストまで）

障害、誤操作、クラウド障害、ランサムウェア――「いつか起きる」を前提にしたとき、復旧の成否を左右するのはツール名ではなくRPOとRTOの合意です。RPO（目標復旧時点／Recovery Point Objective）は「どこまでデータを失ってよいか」、RTO（目標復旧時間／Recovery Time Objective）は「どれだけ止めてよいか」を示します。つまりRPOとRTOは、バックアップ／復旧戦略を“技術の話”から“事業の数字”に変換する共通言語です。

本記事はPM・管理職・QAエンジニア向けに、RPO/RTOを決める手順、バックアップ／復旧戦略の選び方、実際にRPOとRTOを満たすための運用・テストまでを、現場でそのまま使える粒度でまとめます。読み終えたときに「自社のRPOとRTOは何分／何時間で、なぜそう言えるのか」、そして「そのRPO/RTOを満たすバックアップ／復旧戦略がどれか」を説明できる状態を目標にします。

1. なぜRPO／RTOは「経営の数字」になるのか

RPOとRTOは、技術部門だけで完結しません。RPOは「失ってよい取引・作業・信用」の上限であり、RTOは「止まってよい時間」の上限だからです。たとえばECでRPOが1時間なら、最悪で直近1時間分の注文や在庫更新が失われます。これを補正できるのか、顧客に説明できるのか、返金や再決済が発生するのか――それはPMと管理職が判断すべき領域です。一方、RTOが4時間なら、4時間の停止中に問い合わせがどれだけ増えるか、出荷やCSがどこまで詰まるか、SLAやSLOにどう響くかを含めて説明が必要です。ここでRPOとRTOが曖昧だと、バックアップ／復旧戦略の投資判断も、障害時の意思決定も迷走します。

重要なのは、RPOとRTOが「絶対値」ではなく「業務プロセスの許容範囲」だという点です。RPOを短くすればするほど、バックアップ／復旧戦略は高コストになりがちです（頻繁なバックアップ、レプリケーション、ログの保管、運用の複雑化）。RTOを短くすればするほど、待機系のコストや運用体制（当番、Runbook、権限）が必要になります。だからこそ、RPOとRTOは“技術的にできるか”ではなく“事業として払う価値があるか”で決めます。この翻訳ができると、管理職は投資対効果で判断でき、PMは要件として落とせ、QAは復旧後の品質条件（受入基準）を定義できます。RPOとRTOとバックアップ／復旧戦略が同じ地図に載る瞬間です。

2. 決める前にやること：対象データと業務影響の棚卸し

RPO/RTOの議論が噛み合わない最大の理由は、対象が曖昧なまま「短くしたい」「高いのは嫌だ」と話し始めることです。まずは棚卸しで、何を守るのかを明確にします。ポイントは、システムではなくデータと業務プロセスに分けることです。RPOはデータの指標、RTOは業務の指標です。例えば「注文DB」はデータ、「受注→決済→出荷」は業務です。RPOとRTOとバックアップ／復旧戦略を揃えるには、ここを分離して可視化します。

棚卸しの成果物は、①重要度クラス（A/B/Cなど）と、②依存関係図です。依存関係図は、認証・DB・キュー・ストレージ・外部SaaS・バッチ・監視・通知といった要素を矢印でつなぎます。RTOが伸びる典型は「復旧順序が違う」ケースで、例えば認証が戻っていないのにアプリを上げてもログインできず、RTOは達成できません。逆に、顧客影響の大きい経路だけ先に復旧する設計にすれば、RTOを短縮できます。ここでPMは“顧客に見える価値の最小単位”を定義し、QAは“復旧後に最低限通すべきシナリオ”を定義し、管理職は“停止時の事業影響”を定義します。これがRPO/RTO合意の土台になります。

3. RPOの決め方：許容できる「データ損失」をコストに翻訳する

RPOを決める最短ルートは、RPOを「時間」ではなく「失われる業務量」に翻訳することです。例えば、平均で1分あたり10件の注文更新があるなら、RPO=15分は最大150件の欠損を意味します。この欠損を後から再入力できるのか、決済や在庫と整合が取れるのか、顧客に“注文が消えた”と説明しなくて済むのか。ここを具体的に議論すると、管理職は許容損失として判断でき、PMは要件として合意でき、QAは欠損時の受入条件としてテスト設計に落とせます。RPOとRTOとバックアップ／復旧戦略を同時に前に進めるコツです。

RPOの議論で必ず出るのが「その欠損、取り戻せる？」という問いです。ここでは補正できる欠損と補正できない欠損を分けます。補正できる欠損は、後から再計算・再取り込み・再実行できるもの（例：集計、ログの再集約、キューの再送）です。補正できない欠損は、顧客の入力や外部決済など“一度しか発生しない”ものです。補正できない領域に対してはRPOを短くする必要があり、そのためのバックアップ／復旧戦略（ログ配送、継続レプリケーション、書き込みの二重化など）が候補になります。一方、補正できる領域は、RPOを少し長めにしても業務上の致命傷になりにくく、バックアップ／復旧戦略のコストを抑えられます。RPO/RTOを「全部短く」で考えないことが、現実的なバックアップ／復旧戦略への第一歩です。

次に、RPOを満たすバックアップ／復旧戦略の候補を並べます。スナップショット型はシンプルですが、取得間隔がRPOの下限になります。更新頻度が高いDBでは、ログ配送や継続レプリケーションを組み合わせてRPOを縮めます。ここで注意したいのは、RPOは「取れた」ではなく「戻せた」で測る点です。スナップショットが成功しても、復元したデータがアプリ整合（参照整合、二重書き、トランザクション境界）を満たさなければ、実質RPOは守れていません。RPOを短縮するほど、バックアップ／復旧戦略は“整合性の設計”が重要になります。

実務では、RPOをクラスごとに決めるのが現実的です。例えば重要度A（売上・顧客影響が大きい）はRPOを数分〜数十分、重要度Bは数時間、重要度Cは1日、という形です。ここで「ゼロRPO（完全に失わない）」を目標に掲げると、コストだけでなく運用リスクも増えます。ゼロRPOが必要なのは本当に一部で、多くは“欠損しても回復できるプロセス”を作る方が健全です。RPO、RTO、バックアップ／復旧戦略を「守る領域」「許容する領域」「後で補正する領域」に分ける発想が、投資最適化に直結します。

4. RTOの決め方：復旧工程を分解し、ボトルネックを潰す

RTOを短くできない理由の多くは、インフラではなく工程にあります。RTOは「復旧の開始」から「業務が回る」までの時間で、検知、意思決定、切替、データ復元、アプリ起動、動作確認、告知までの合計です。つまりRTOは、バックアップ／復旧戦略だけでなく、運用設計とQAの受入基準が決める数字です。ここでおすすめなのが、RTOを工程ごとに分解して“積み上げで見積もる”ことです。例えば「検知10分、判断20分、切替15分、復元60分、確認30分、告知10分」など、現実の組織に合わせて積み上げます。RTO、RPO、バックアップ／復旧戦略が机上から実測に近づきます。

バックアップ／復旧戦略の代表パターンは、コールド（必要時に構築）、ウォーム（縮小稼働の待機系）、ホット（常時稼働の待機系）に整理できます。コールドはコストが低い一方、構築と復旧に時間がかかりRTOは伸びます。ウォームは待機系があるためRTOを縮められますが、データ同期（RPO要求）と運用の複雑さが増えます。ホットはRTOを最短にできますが、コストと運用（監視、同期、フェイルオーバー訓練）が重くなります。ここでPMは「顧客に提供する最小機能（最小復旧）」を定義し、管理職は「その機能が止まる損失」を定義し、QAは「最小復旧の受入テスト」を定義します。これがRTOを現実にするバックアップ／復旧戦略の要件になります。

RTOを議論するときは「完全復旧までのRTO」と「暫定復旧までのRTO」を分けると合意しやすくなります。例えば、決済は停止しても注文の受付だけは継続する設計にすると、暫定復旧のRTOは短くできます。これはバックアップ／復旧戦略だけでなく、機能分割・機能フラグ・キューイングなどアプリ設計の論点でもあります。PMが優先度を決め、QAが暫定復旧の品質条件を決め、管理職が顧客対応方針（告知・補償）を決めることで、RTOは現実の数字になります。RPOとRTOとバックアップ／復旧戦略は、ここで初めて一枚の設計になります。

5. 「取っているのに戻せない」を防ぐ：運用・テスト・セキュリティ

バックアップ／復旧戦略の失敗は、設計ではなく運用で起きます。典型は「バックアップは成功しているが、復元したら動かない」です。ランサムウェアではバックアップ自体が攻撃対象になるため、3-2-1（媒体を分け、オフサイトを持ち、複数世代を保持）に加え、イミュータブル（改ざん不能）やオフライン保管を検討します。さらに重要なのは“復旧テスト”です。RPOとRTOは設計値ではなく実測値で管理します。毎回フル復旧が難しい場合でも、サンプリング復元、整合性チェック、演習（GameDay）などで「RPOの実測」「RTOの実測」を取りに行きます。RPO/RTOとバックアップ／復旧戦略を現場で機能させる唯一の方法です。

QAが強い組織ほど、復旧の“ゴール定義”が明確です。例えば「ログインと注文作成ができる」「管理画面で受注一覧が見える」「決済連携は停止しても受注はキューに溜める」など、復旧後に成立させるべきシナリオを事前に決めます。これがRTOに直結します。RTOを短くしたいのに、復旧後の確認が属人化していると、実測RTOは伸びます。逆に、最小受入テストをRunbookに埋め込めば、RTOは安定します。RPOの観点でも「欠損時の補正手順」（再実行、再取り込み、手動補正）があると、RPOを過剰に短くしなくて済み、バックアップ／復旧戦略のコストを抑えられます。

最後に、責任分界の整理です。クラウドやSaaSは「サービス自体の可用性」は提供しても、「あなたのデータをあなたのRPO/RTOで守る」ことは別問題です。契約上のSLAと、自社のRPO/RTO、そしてバックアップ／復旧戦略（誰がどこまで復旧するか）を同じ表に並べ、ギャップを埋めます。ここを曖昧にすると、障害時に“誰も決められず”RTOが伸び、最終的にRPOの損失も拡大します。PMは契約と要件、管理職はリスクと投資、QAは手順と検証を担当し、RPO/RTOとバックアップ／復旧戦略を運用に落とし込みます。

6. 最短ロードマップ：RPO/RTOを合意し、バックアップ／復旧戦略を“動く形”にする

実務で最も再現性が高い進め方は、①棚卸し、②暫定RPOと暫定RTO、③バックアップ／復旧戦略の候補比較、④Runbook化、⑤復旧テストで実測、という順番です。いきなり最適解を目指すと、議論が抽象化し、RPOもRTOも決まらず、バックアップ／復旧戦略の導入だけが先行します。まずは“暫定”で良いので、RPOとRTOを数字にします。その上で「このRPO/RTOならこのバックアップ／復旧戦略」「このバックアップ／復旧戦略ならこのRPO/RTOが現実的」という往復で精度を上げます。

もし「自社のRPOとRTOが妥当か分からない」「バックアップ／復旧戦略はあるが復旧できる自信がない」という状態なら、まずは現状のRPO/RTOを“実測”し、ギャップを見える化するのが近道です。RPOとRTOとバックアップ／復旧戦略を一体で見直すと、コストを上げずにRTOだけ短縮できるケースも多くあります。例えばRunbook整備と訓練でRTOが半減する、欠損補正の設計でRPOの要求が緩む、といった改善が典型です。バックアップ／復旧戦略の投資は、RPOとRTOを“達成できる運用”まで含めて初めて価値になります。

まとめ

RPOは「失ってよいデータ（業務量）」、RTOは「止めてよい時間」です。RPOとRTOを決めると、バックアップ／復旧戦略は“手段”として選べるようになります。逆に、RPOとRTOが曖昧なままバックアップ／復旧戦略だけ導入すると、復旧できない・復旧が遅い・責任が曖昧という事故が起きます。まずは棚卸しで対象を明確にし、暫定RPO/RTOを置き、バックアップ／復旧戦略と運用（Runbook・権限・テスト）を揃えて実測し、少しずつ精度を上げてください。RPOとRTOは一度決めて終わりではなく、プロダクトと組織の変化に合わせて更新し続ける運用項目です。RPOとRTOとバックアップ／復旧戦略を“毎年の見直し項目”として扱うと、いざという時に強い組織になります。