サーバーではなく業務プロセスとサービスから分ける

RTOとRPOを決める作業は、「バックアップを何時間ごとに取るか」や「待機リージョンを運用するか」から選ぶことではありません。まずどの業務がどれだけ長く止まってよいのか、そしてどの時点以降のデータ損失から受け入れられないのかを定めます。そのうえで初めて、復旧環境を平常時からどこまで準備するか、データをどれだけ頻繁に保護するか、自動化と運用人員にいくら投じるかを比べられます。

同じ1時間のRTOでも、障害範囲とデータ規模、自動化の水準、外部依存、復旧要員によって必要な構造は変わります。だからRTOとRPOは、インフラ商品の仕様というより、業務の許容限界を技術設計と予算へ移した目標に近いものです。バックアップ処理が成功したという記録だけでは目標の達成を判定できません。実際の復旧経路を最後まで実行し、サービスとデータが使える状態かを確認しなければなりません。[1]

災害復旧の目標を「本番サーバーのRTO 4時間」のようにインフラ単位だけで定めると、何を4時間以内に復旧するのかが曖昧になります。一つのアプリケーションの中でも業務の重要度は違います。注文受付は即時の復旧が要りますが、過去の統計レポートは後で計算し直せます。顧客の新規要求を受ける機能は維持しつつ、管理者向けの推薦機能やバッチ分析は一時的に止める縮退運用も選択肢です。

復旧目標の最初の単位は三つのいずれかであるべきです。顧客や職員が終えるべき重要な業務プロセス、ログイン・注文・決済・受付・承認のように終了条件が明確なサービスの流れ、独自のOwnerと復旧優先度を持てるワークロードです。AWSはワークロードごとに復旧目標を定義し、上流と下流の依存とデータの再構成可否を併せて検討するよう勧めます。[4]Microsoftの指針も、一つのシステム全体に単一の目標を付けるより、重要な流れと構成要素ごとの要求を分けるよう促します。[2]

ここで必ず決めるべきものが最小許容復旧状態です。すべての機能と過去データが完全に正常化した状態だけを復旧完了と見るのか、中核取引だけ可能な縮退状態も暫定復旧として認めるのかによって、必要な投資の水準が大きく変わります。

MTD、RTO、RPOは同じ数字ではない

NIST SP 800-34 Rev.1は、業務が耐えられる最大の停止時間をMTDと呼びます。RTOはその内側で停止したサービスや資源を戻す目標であり、RPOはどの時点のデータ状態まで戻すかを示します。三つの指標の意味は次のとおりです。[1]

実務では、目標RTOにデータの再構成と整合性確認の時間、滞留業務の処理と正常化の時間を足した値がMTD以下かを点検します。この式は標準に定義された計算式ではなく、RTOをMTDと混同しないための計画用の検証式です。サービスが技術的に起動した後、業務を正常に行えるまでにさらに3時間が要るなら、RTOをMTDと同じ値に置いてはいけません。

RPOが30分という言葉は、原則として最大30分前の時点へ戻れるという時間目標であり、実際に何件の注文やいくらの金額を失うという意味ではありません。データの変更速度と業務価値が違えば、同じ30分でもまったく違う損失になります。[3]

したがってRPOを承認するときは、時間とともに六つを書きます。その時間に見込まれる取引・ファイル・作業量、失われうる金額や顧客への影響、外部システムから再取得できるか、ログや原始データから再生成できるか、人が再入力するなら必要な時間と人員、そして再構成が不可能なデータかどうかです。

MTD
MTDとは、業務プロセスが止まった状態とその影響を組織が受け入れられる最大の総時間です。システム一台の障害時間ではありません。
RTO
RTOとは、停止したサービスや資源をどの時間内に復旧するかを定めた目標です。一般にMTDより短くなければなりません。
RPO
RPOとは、障害前のどの時点のデータ状態まで戻すかを示す時間目標です。何件や何円を失うかを意味しません。
サービスの仕組み

監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。

RTOは復旧作業全体の時間予算である

RTOを現実的に定めるには、復旧の過程を一つの数字にまとめず、時間予算へ分解します。障害の検知、影響の確認と復旧の宣言、担当者の集結と権限の確保、復旧環境の活性化、データの復元または同期、依存サービスの復旧、アプリケーションの起動、機能とデータの検証、トラフィックの切替と利用者の再開の合計が、目標RTO以下でなければなりません。

これも特定の標準の公式ではなく、公式指針に散らばる復旧の段階を一つの測定経路へまとめたものです。NISTは通知、活性化、復旧、再構成と検証を別の段階として扱い、Azureの指針は人の意思決定とRunbook、連絡体系、実際のFailover・Restoreの時間を目標の内側で検討させます。[1]

RTOの時計の開始と終了も明示しなければなりません。この記事では、利用者に実際の影響が始まった時点から、合意した最小復旧状態が検証された時点までをビジネスRTOとして測ることを勧めます。障害宣言の後から自動化の実行完了までしか測らないと、検知の遅れと意思決定、資格情報の確保、検証の時間が数字の外へ抜けます。

運用の改善のためには内部の区間も別に測ります。利用者影響の開始から検知まで、検知から障害宣言まで、宣言から復旧作業の開始まで、作業開始からインフラ・データの復元まで、復元から機能検証の完了まで、検証完了から利用者トラフィックの再開までです。こうして初めて、どこへ投資すればRTOが実際に縮むかが見えます。待機サーバーを足すより、宣言の権限を明確にしたり資格情報のアクセスを整理したりするほうが、大きな改善につながることもあります。

RPOはデータごとに違えて定められる

一つのサービスにあるすべてのデータを同じRPOで守る必要はありません。まずデータを五つに分けます。

AWS Well-Architectedは、データが他の原始から作り直せるか、その原始のRPOは何かまで確認させます。再生成できるデータなら保存の複製水準を下げる余地があります。ただし再生成にかかる時間と原始への依存が、RTOとMTDの内側に入らなければなりません。[2]

検索インデックスをすべて失っても元のデータベースから作り直せるなら、インデックス自体のRPOは比較的緩く置けます。しかし再生成に10時間かかり、検索機能のRTOが2時間なら、その設計は目標を満たしません。このとき必要な投資はデータの複製かもしれませんし、インデックス再生成の速度改善や縮退した検索機能かもしれません。

データ分類
例
確認する問い
目標への影響
原始の取引データ注文、決済状態、承認記録他の場所から再取得できるか損失の許容幅が小さく、整合性の検証が重要になる
外部から再収集できるデータ外部APIの応答、受信メッセージ提供元が再送または再照会するか外部システムの保存期間とRPOが依存条件になる
派生データ検索インデックス、キャッシュ、統計集計原始から作り直せるかデータのRPOより再生成時間がRTOを制約する
人が再構成するデータ一部の承認メモ、業務の状態誰がどの根拠で再入力するか人員と誤り、再処理の時間がMTDを消費する
再構成できないデータアップロードの原本、一度限りの入力複製や原本が他の場所にあるかより厳しい保護目標が必要になる
データの五分類 — 再構成の可否がRPOとRTOに与える影響

依存の復旧目標がサービスより遅ければ目標は達成できない

サービスの復旧はアプリケーションとデータベースだけの問題ではありません。Identity Providerと管理者認証、DNSとネットワーク、証明書とファイアウォール規則、暗号鍵とSecret、メッセージキューとイベントストリーム、外部の決済・メッセージング・地図・認証API、データ提供者、監視とログ、配備ツールとコードリポジトリ、顧客告知の経路、クラウド・通信事業者・外部運用会社の支援、復旧を承認し実行する人のうち一つでも整っていなければ、全体の経路が止まります。

AWSとAzureの復旧指針は、上流と下流の依存、認証・ネットワーク・監視、外部サービスと復旧担当者を併せて確認させます。個々の構成要素の目標が全体のサービス目標と合わなければ、復旧計画は文書上の数字にとどまります。[2]

各Dependencyには少なくとも七項目を記します。Dependencyの名称、Owner、支える業務、自身のRTO・RPOまたは復旧の約束、実際に確認された復旧能力、代替経路、そして自社サービスの目標との差です。

外部APIが24時間以内に復旧するという条件なのに、自社サービスのRTOを1時間で承認するなら、そのAPIなしでも動く縮退モードか代替の提供者が要ります。そうでなければ1時間という数字は実現可能な目標ではありません。

人と手順も復旧アーキテクチャである

復旧環境が自動で整っていても、人が七つの問いに答えられなければRTOは伸びます。誰が災害を宣言するのか。勤務時間外は誰が決めるのか。復旧環境のアカウントと鍵に到達できるのか。どの順序でサービスを立ち上げるのか。データの衝突が起きたら誰が基準状態を決めるのか。顧客と経営陣と外部の供給者へ誰が知らせるのか。Failoverの後に元の環境へ戻る条件は何か、です。

NISTは復旧計画に役割と連絡体系、通知、訓練と演習を含め、実際のテストで計画の欠陥を見つけるよう求めます。AzureもRunbookと意思決定者、コミュニケーション計画と人による統制を復旧能力の一部として扱います。[1]

Runbookや連絡先が障害を起こした主システムの中にしかないなら、実際の災害中には開けません。復旧の手順、資格情報の取得方法、担当者の連絡先、状態告知の手段は、主たる障害ドメインから離れた場所から到達できなければなりません。

復旧環境は「存在」より「現在の状態」を確認する

復旧用の環境が作られているという事実だけでは、使える状態とは言えません。平常時に使わない環境ではDriftが生じやすいです。アプリケーションのバージョン差、本番と異なる設定、期限切れの証明書、欠落したSecretと権限、誤ったDNS・ファイアウォール規則、不足するインスタンス・ストレージ・APIの割り当て、異なるデータベーススキーマ、接続されていないログと監視、実トラフィックを捌けない容量です。

AWSとAzureの現行の指針は、復旧環境の構成とデータ整合性、割り当て、ネットワーク・Identity・監視と実際の復旧Drillを併せて検証させます。[2][5]

復旧環境の準備状態は「ある・ない」より五段階で記すほうが良いです。コードと設定で再構築可能、中核の基盤環境だけ常時準備、縮退容量の待機環境を準備、本番水準の待機環境を準備、複数環境が同時に実トラフィックを処理、です。この状態は復旧Patternを説明するだけで、特定のRTOへ自動的にはつながりません。自動化の質とデータ量、障害範囲、チームの習熟度によって、同じPatternでも実際の復旧時間は変わります。

Service Recovery Objective Worksheet

次のワークシートは、サービスごとにRTO・RPOの目標と投資の根拠を併せて記すための雛形です。四つのブロックに分かれます。業務と許容影響、RTO・RPOとデータの再構成、依存と環境・人・コミュニケーション、検証と投資の決定です。

各サービスの目標には証跡の状態を一つ付けます。推定値を検証済みのように報告しないことが肝心です。テストしていない1時間のRTOは約束ではなく仮説です。

検証済み
代表的な障害範囲とデータ規模で全経路を実行し、目標の内側で復旧した状態です。
推定値
設計とRunbookはあるが、Dependencyを含む全体の復旧Drillがまだない状態です。
未達
実測結果が目標を超えるか、必要な復旧経路が存在しない状態です。
ブロック
フィールド
記入内容
完了基準
1. 業務と許容影響Service / Process ID復旧目標を所有するサービス・業務の名称サーバー名やDB名ではなく業務成果が現れる
1. 業務と許容影響Critical Flow利用者が完了すべき中核の流れ開始と終了の条件が明確である
1. 業務と許容影響Business Owner業務影響と目標を承認する人技術チームだけでなく業務責任者が含まれる
1. 業務と許容影響Recovery Decision Authority復旧とFailoverを宣言する人と代理者勤務時間外の代理権限まである
1. 業務と許容影響Users / Deadline影響を受ける利用者、締切、繁忙期時間帯で影響が変わるかを記す
1. 業務と許容影響Failure Scenarios in Scopeインスタンス、データ破損、アカウント喪失、ネットワーク、リージョンなど今回の目標が扱う障害範囲が明確である
1. 業務と許容影響Impact Timeline停止15分・1時間・4時間・1日など時点別の影響金額・顧客・規制・安全・運用の影響を分ける
1. 業務と許容影響MTD業務が耐えられる最大の総停止時間根拠と承認者がある
1. 業務と許容影響Minimum Recovery State全体・縮退・手動代替のうち許容できる状態復旧完了の機能・容量の条件が測れる
2. RTO・RPOと再構成Target RTO目標の復旧時間開始・終了の時点と障害範囲が併せて定義される
2. RTO・RPOと再構成RTO Time Budget検知、宣言、アクセス、環境、データ、Dependency、検証、トラフィックごとの予算各区間にOwnerがある
2. RTO・RPOと再構成Data Setsサービスが必要とするデータの一覧原始・派生・外部・手動再構成の別が分かれる
2. RTO・RPOと再構成Target RPO by Data Setデータごとの許容損失時間サービス全体に同じ値を無条件に当てない
2. RTO・RPOと再構成Loss at RPOその時間に見込まれる取引・金額・作業量時間目標が業務影響へ翻訳される
2. RTO・RPOと再構成Reconstruction Source原始ログ、外部システム、利用者の原本など実際のアクセス可否と保存期間が確認される
2. RTO・RPOと再構成Reconstruction Effort自動・手動の手順、人員、想定所要時間MTDの計算に含まれる
2. RTO・RPOと再構成Reconciliation / Catch-up重複排除、再処理、滞留作業、顧客調整技術的な起動後の業務正常化が含まれる
2. RTO・RPOと再構成MTD Consistency CheckRTOに再構成・正常化の時間を足した値がMTD以下か超える場合は目標・設計・業務代替のいずれかを直す
3. 依存・環境・人Upstream DependenciesIdentity、DNS、ネットワーク、鍵、外部API、原始データOwnerと復旧能力、代替経路が記される
3. 依存・環境・人Downstream Dependenciesこのサービスを待つ他の業務とシステム復旧の順序と影響が整理される
3. 依存・環境・人Dependency Objective Gap各Dependencyの目標とサービス目標の差遅いDependencyには迂回手段がある
3. 依存・環境・人Recovery Environment再構築・基盤準備・待機・同時運用など現在の状態容量と設定、割り当てが検証される
3. 依存・環境・人Configuration ControlIaC、設定のバージョン、Secretと証明書の管理本番環境とのDriftを見つけられる
3. 依存・環境・人People and RolesIncident Lead、技術担当、業務承認者、コミュニケーション担当代理者と勤務時間外の連絡体系がある
3. 依存・環境・人Credential Accessアカウント・鍵・Break-glassのアクセス手順主環境の障害中でもアクセスできる
3. 依存・環境・人Runbook宣言から復旧・検証・復帰までの順序実行コマンドだけでなく判断条件を含む
3. 依存・環境・人Communication社内報告、顧客告知、Vendor Escalation、更新周期主システムから独立した連絡手段がある
4. 検証と投資Test Scenario実際に検証した障害範囲目標のScopeと同じである
4. 検証と投資Validation Criteria中核の流れ、データ整合性、権限、セキュリティ、監視、容量サーバーの起動可否だけで終えない
4. 検証と投資Last Exercise最後の復旧Drillの日付と環境代表的なデータ規模とDependencyを含む
4. 検証と投資Measured Recovery Duration影響開始から検証完了までの実測時間目標RTOとそのまま比較できる
4. 検証と投資Actual Data Loss Window復旧後に確認された実際のデータ損失区間目標RPOとそのまま比較できる
4. 検証と投資Reconstruction Duration損失データと滞留作業を正常化した時間MTDの検証に使う
4. 検証と投資Current Gap目標に届かない区間とその原因インフラ・自動化・人・Dependencyに分解される
4. 検証と投資Improvement Option目標を改善する設計・運用の代替案特定の商品名より必要な能力が書かれる
4. 検証と投資Incremental Annual Cost追加の資源・ツール・開発・訓練・支援の費用既存費用と分けられる
4. 検証と投資Expected Benefit減る停止影響とデータ損失金額化が難しければ影響等級と根拠を記す
4. 検証と投資Approval目標・予算・残余リスクの承認者Business Ownerと技術Ownerが共に承認する
4. 検証と投資Next Review次のDrillと目標の再検討日サービスとDependencyの変更に連動する
Service Recovery Objective Worksheet — 四ブロックの記入項目と完了基準（IXC復旧目標様式、2026-08改訂）
サービスの仕組み

費用の要因から継続的な管理へ — 支出を業務とリソース単位に分け、影響を確認した対策と予算管理を運用につなげます。

復旧Patternは目標時間に固定して対応させない

復旧環境をどの水準まで前もって準備するかは四つに分けて比べます。下の分類はVendorの商品等級ではなく、準備状態を比べるための抽象化です。

公式のクラウド指針も、事業目標と障害範囲、Dependencyと費用を先に確認したうえで復旧の構造を選ぶよう促します。Patternの名前や例示の時間は、組織の自動化水準とシステム構造の代わりにはなりません。[2]

「RTOが1時間なら必ずMulti-Region」といった規則は成り立ちません。単一インスタンスの障害だけがScopeに入り、環境を速く再構成できるなら、他の構造でも目標に届きます。逆にリージョン全体の喪失、アカウントへのアクセス不能、外部Identityの障害までScopeに入れるなら、単純な待機サーバーだけでは足りません。データ破損や誤った配備のように複数環境へ同時に影響する事象も別に考慮しなければなりません。[6]

目標時間一つがアーキテクチャを決めるのではありません。許容停止・データ損失、扱う障害範囲、データとDependencyの性質、自動化・人・手順の現在の能力、検証された復旧結果、支払える費用の組み合わせが決めます。

コードで再構築しデータを復元
障害前の準備状態: 本番以外の環境はほとんどない / 主な遅延要因: 資源の作成、設定、大容量データの復元、検証 / 主な費用・運用負担: 平常時の資源費は低いが自動化と復元速度への依存が大きい / 適合性を検討する条件: 停止の許容時間が比較的長く、環境を一貫して再構築できるとき
基盤環境を常時準備し拡張
障害前の準備状態: ネットワーク・Identity・中核データ経路が準備済み / 主な遅延要因: 容量の拡張、アプリケーションの配備、最新データの適用 / 主な費用・運用負担: 基盤資源、Drift管理、拡張の自動化 / 適合性を検討する条件: 一部の基盤要素の準備が復旧時間を大きく縮めるとき
待機環境を常時維持
障害前の準備状態: アプリケーションとデータが縮退または本番水準で準備済み / 主な遅延要因: 切替の判断、データの収束、検証、トラフィックの変更 / 主な費用・運用負担: 重複資源、継続同期、パッチ・セキュリティ・Drill / 適合性を検討する条件: 再構築時間が目標の主なボトルネックであるとき
複数環境で同時にサービス
障害前の準備状態: 二つ以上の環境が実トラフィックを処理する / 主な遅延要因: 障害の隔離、書き込み整合性、部分障害の判定 / 主な費用・運用負担: 最も高い設計・データ・運用の複雑さと継続的な容量 / 適合性を検討する条件: 特定の障害ドメインの停止をサービスが吸収すべきとき

目標を強めるほど何に費用がかかるか

RTOとRPOが短くなるほど、費用はバックアップの保存領域だけが増える形では大きくなりません。ある地点を越えると新しい復旧環境と継続的な複製、自動化、人員と運用統制が要り、費用は階段状に上がります。NISTと主要クラウドの公式指針も、短い目標がより高い費用と管理の複雑さを求め、適切な均衡点は組織ごとに違うと説明します。[1]

RTOを縮めると、前もって用意したCompute・Network・Databaseの容量、環境の作成と配備の自動化、設定・Secret・証明書・割り当ての継続的な整合性管理、速い障害検知と宣言の体系、勤務時間外の対応要員、繰り返しのFailover・Failback Drill、Dependencyのより強い支援契約や代替経路、縮退運用機能の開発に費用が付きます。

RPOを縮めると、より頻繁なデータ保護とログの保存、継続的な複製とネットワーク使用量、書き込み整合性・重複・順序の問題を扱う設計、より多くの復旧地点と保存の管理、データ整合性の確認とReconciliation、原始データと外部システムの保存・再送の能力に費用が付きます。

二つの目標を同時に強めると、速く準備された環境と最新のデータが同時に要ります。そこにFailover後の整合性、元の環境へ戻るFailback、複数環境のパッチとセキュリティ、継続的な検証の負担が加わります。予算の検討では「上位のDR等級へ移行」と書くより、増分の能力を並べて比べるほうが良いです。

先にボトルネックを見つけ、その区間へ投資しなければなりません。データの復元に20分しかかからないのに障害の宣言に2時間かかるなら、より高価な複製技術を足してもRTOはほとんど縮みません。

代替案
改善する区間
追加する能力
年間の増分費用
目標達成の根拠
A障害宣言の時間当直・権限・Runbookの改善記入Drillの結果
B環境準備の時間自動化された再構築と基盤環境の準備記入再構築テスト
Cデータ復旧の時間より短い保護周期、複製、再生成の改善記入実データ規模での復元
DDependencyの遅延代替経路、支援契約、縮退運用記入統合障害テスト
増分能力の比較 — 上位等級への移行ではなく、どの区間をいくらで縮めるか

Restore Testは業務が再び可能かを確認したときに終わる

復旧完了の時点を「インスタンスが実行中」や「データベース接続に成功」と置くと、実際の業務復旧の時間より短く測られます。復旧の検証には少なくとも十が入らなければなりません。中核の利用者の流れの成功、データ整合性と基準時点の確認、認証・権限と暗号鍵、外部Dependencyの接続、十分な処理容量、ログ・監視・通知、セキュリティ統制、新しいデータの書き込みと後続処理、顧客と業務担当者のAcceptance、滞留作業とデータ再構成の手順です。

NISTは機能・回帰・データの検証が終わった後にシステムを復旧済みと宣言させます。Googleの公式指針も、復元テストをデータファイルの確認に限らず、アプリケーションのスタックと中核インフラを復元したデータで検証させます。[1][3]

バックアップ作成の記録は入力の証跡にすぎません。RTOとRPOを満たしたという証跡は、合意した障害範囲で全体の復旧経路を実行した結果です。

よく起きる誤った判断

八つが繰り返し現れます。各項目は、なぜ問題になるのかと何に置き換えるのかを併せて見ます。

誤った判断
問題になる理由
直し方
会社全体にRTO・RPOを一つ当てる業務の重要度とデータの性質が違うサービス・Critical Flow・データごとに分ける
バックアップ周期がそのまま達成RPOだと見る失敗・遅延・破損・復元不可を反映できない実際に復旧した時点とデータ損失区間を測る
サーバーが起動すればRTOを達成したと見るDependency・データ・業務機能・検証が抜ける最小許容復旧状態とAcceptanceを定義する
Vendor SLAやMTTRを自社のRTOとして使う提供者の資源水準と業務復旧の完了は違うサービス全経路の目標と実測値を管理する
Dependencyの目標を確認しない最も遅い依存が全体の復旧を制限するDependencyごとの目標・実測・迂回経路を記す
人と連絡の時間を計算しない宣言・アクセス・承認の遅れがRTOの外に隠れる人・手順・コミュニケーションを時間予算に入れる
特定のRTOを特定のPatternに自動で結びつける障害範囲・データ・自動化・チームの能力が違う復旧経路を設計しDrillで証明する
一度成功したテストで恒久的に承認するデータ規模・構成・Dependencyが変わり続ける変更と定期Drillに合わせて目標を見直す
よくある八つの誤った判断と直し方

目標は合意し、設計し、測ったうえで再交渉する

RTOとRPOを決める順序はこうです。業務プロセスとOwnerを定義します。時間に沿った停止影響とMTDを確認したうえで、最小許容復旧状態を定義します。次にデータごとのRPOと再構成の可否を確認します。そのうえでDependencyと人、復旧環境を入れてRTOを分解します。復旧Patternと増分費用を比べ、全体の経路をDrillで回し、実測と目標の差を確認して、投資・縮退運用・目標の調整のいずれかを承認します。

目標に届かないなら選択肢は三つです。復旧環境とデータ保護、自動化、人へさらに投じるか、中核機能だけ先に戻す縮退運用や手動の代替手順を設計するか、業務責任者と許容停止・データ損失の目標を再交渉するかです。してはならない選択は、検証していない数字をそのまま残すことです。

RTOとRPOは短いほど良い点数ではありません。業務が実際に必要とする水準であるときに有効です。Dependencyと人を含む全経路で検証され、組織がその費用と残余リスクを承認して初めて、復旧目標になります。