1 RTOの基本
1.1 定義と目的
1.1.1 目標復旧時間の意味
RTO（Recovery Time Objective、目標復旧時間）は、障害や災害が発生した後に、業務に必要なシステムまたはサービスを、あらかじめ定めた時点までに復旧させるべきだとする時間目標である。時間目標は、復旧作業の開始からサービス提供の再開、あるいは利用可能状態の確立までを含むのが一般的であり、組織の復旧計画の基準点となる。
1.1.2 事業継続との関係
RTOは、事業継続（BCP）やディザスタリカバリ（DR）の計画において、停止がもたらす損失や業務停止の許容範囲を時間軸で具体化する。これにより、どの業務を優先して復旧するか、どの復旧手段を用いるか、復旧に必要な体制や投資をどこまで用意するかといった意思決定が整理される。結果として、単なる技術指標ではなく、経営・業務側の要求と技術側の設計をつなぐ役割を持つ。
1.2 表記と単位
1.2.1 時間（分・時間・日など）の扱い
RTOは通常、分、時間、日などの時間単位で表現される。短いRTOは即時復旧に近い運用を想定しやすく、長いRTOは段階的な復旧や縮退運転を前提に設定されることが多い。設定時には、時間の数え方（例：障害検知から開始するのか、復旧作業着手まで含むのか、利用者が機能を使える状態まで含むのか）を明確にしておく必要がある。
1.2.2 「復旧」の到達条件
「復旧」と見なす条件は、サービスの提供形態に依存する。完全復旧として本番同等の性能・機能を求める場合もあれば、最低限の業務継続を目的に縮退状態（限定機能、限定性能、段階的なデータ反映）で合格とする場合もある。到達条件が曖昧だと、検証時に達成判定が揺らぎ、設計の妥当性評価や改善サイクルが機能しにくくなる。
1.3 RTOが扱う対象範囲
1.3.1 アプリケーション
アプリケーションのRTOは、復旧後に利用可能な状態へ到達するための時間目標として設定される。構成要素（依存するミドルウェア、認証基盤、外部連携、バッチ処理など）が複数ある場合は、それらの復旧順序や待ち条件がRTOに影響する。特に外部サービスとの連携がある場合、システム側の復旧だけでは到達できない時間が発生し得るため、境界条件の定義が重要になる。
1.3.2 データベース
データベースのRTOでは、復元手順（バックアップからの復旧、ログ適用、整合性チェックなど）に必要な時間を反映する。さらに、復旧後に整合性が確立されてからアプリケーションが読み書き可能になるまでの時間、必要なマイグレーションや再構成がある場合の所要も考慮対象となる。データ量、バックアップ方式、復元の並列性などの要因で達成可能性が大きく変わる。
1.3.3 インフラ（サーバ・ネットワーク）
サーバやネットワークのRTOは、仮想化やクラウド利用の有無、冗長構成、ルーティング切替の手順、証明書や鍵の再発行などに左右される。ネットワークでは経路切替だけでなく、到達性確認や監視復旧、ファイアウォール設定反映なども含めた運用時間が該当し得る。インフラ領域のRTOが長いと、上位のアプリケーション復旧まで波及するため、全体設計として整合を取る必要がある。
2 他指標との関係
2.1 RTOとRPOの違い
2.1.1 復旧時点と復旧時間の整理
RTOは「復旧までの時間」を示し、RPO（Recovery Point Objective、目標復旧時点）は「復旧時点として許容されるデータ損失の最大量（または最も古い許容状態）」を示す指標である。つまり、RTOは止まっていた期間に対する時間目標、RPOはその間に失われる可能性のある情報に対する許容範囲を扱う。両者は別の次元であり、同じ停止時間であっても、必要なデータ鮮度が異なれば設計は変化する。
2.1.2 バックアップ設計への影響
RPOはバックアップ頻度や世代管理、ログの保存期間、復旧手順の細分化に直結する。RTOが短い場合、バックアップからの復元そのものを短時間で完了できる構成（レストア時間の短縮、差分やスナップショット活用、復元の並列化など）が必要になる。一方、RPOが厳しい場合はログや差分の管理が重くなり、復旧手順や保管コストに影響が出る。結果として、RTOとRPOを同時に満たすための設計バランスが求められる。
2.2 可用性指標との関連
2.2.1 アベイラビリティと停止許容
可用性（アベイラビリティ）は、ある期間において利用可能である度合いを表す概念であり、RTOは「復旧に要する時間」という切り口で可用性の成立に影響する。停止が発生しても、許容される時間内に復旧できるならサービスの利用可能性は保たれやすい。したがって、可用性目標を達成するために、RTOを現実的な水準で設定し、復旧のボトルネックを取り除く必要がある。
2.2.2 SLA・SLOとの整合
SLA（サービスレベル契約）やSLO（サービスレベル目標）は、提供品質を数値化して契約・運用に落とし込む枠組みである。RTOはSLA/SLOのうち、特に障害時の復旧に関する要件として参照されることが多い。整合が取れていない場合、契約上の義務と現場の復旧能力に食い違いが生じ、運用での説明責任や再設計が発生しやすい。目標値の粒度と測定方法を合わせることが実務上の要点となる。
2.3 リスクとコストのトレードオフ
2.3.1 復旧短縮に伴う費用
RTOを短くするには、冗長構成、専用設備、より高頻度のバックアップ、フェイルオーバー自動化、復旧手順の最適化などが必要になりがちである。これらは設備投資だけでなく、運用の人員、監視・テストの負荷、変更管理の複雑化として現れる。さらに、短縮により復旧検証の回数を増やす必要が出る場合もあり、間接コストが膨らむことがある。
2.3.2 投資判断の考え方
投資判断では、「停止した場合の損失」と「目標短縮に必要な追加費用」を比較し、合理的な水準を選ぶことが基本となる。重要度分類ごとにRTOを段階設定し、全システムを一律に短くしない設計が採られることが多い。加えて、技術的な上限（復旧可能な手段、復元速度の限界）と運用体制の成熟度（手順の再現性、演習の質）を踏まえ、現実的な目標値へ落とし込むアプローチが有効である。
3 RTO設定の進め方
3.1 重要業務の特定
3.1.1 業務・システムの重要度分類
RTO設定の前提として、業務やシステムを重要度で分類する。分類は、顧客影響、売上やコストへの影響、法令・監査要件、代替手段の有無、復旧後の影響波及（後工程の停止など）を考慮して行う。ここでの重要度は組織内の合意が重要であり、技術者の見立てだけで決めると後工程で不整合が生じやすい。
3.1.2 影響範囲の見積り
各システムが停止した場合に、どの業務がどの程度止まるのか、あるいは遅延するのかを見積もる。影響範囲には、直接的な利用者だけでなく、連携先や下流工程、問い合わせ対応などの運用負荷も含まれる。停止時間が延びるほど損失が増える性質の業務では、RTOの差が意思決定に与える効果が大きくなるため、見積りの精度がRTOの妥当性に直結する。
3.2 現状評価とギャップ分析
3.2.1 現行の復旧能力の把握
現状評価では、実際にどれだけの時間で復旧できるかを把握する。過去のインシデント記録、復旧手順書の実測、バックアップのレストアに要する時間、フェイルオーバーの切替時間などを基に現実的な復旧能力を整理する。机上の理屈だけでは、手順の習熟度や検証環境との差、待機状態の存在などが反映されないため、測定と確認が重要になる。
3.2.2 達成に必要な改善領域
ギャップ分析では、目標RTOと現状能力の差を埋めるための改善点を特定する。改善は技術要素（冗長化の追加、復元方式の変更、自動化範囲の拡張）と運用要素（連絡体制、役割分担、判断基準、演習による手順の再現性向上）に分けて整理すると、優先順位付けがしやすい。費用対効果の観点から、効果が大きい箇所から段階的に着手する設計が採られる。
3.3 計画策定と合意形成
3.3.1 関係者（IT・業務部門）の役割分担
合意形成では、IT部門が技術的な達成可能性と手段を提示し、業務部門が許容される停止条件や優先度を示す形が一般的である。加えて、経営層やリスク管理部門が投資方針を含む意思決定に関与する場合が多い。役割分担が明確でないと、目標が決まっても実行段階で条件が変わり、計画が破綻しやすい。
3.3.2 RTOの承認プロセス
承認プロセスでは、目標値が現場の能力と照合され、達成手段、検証計画、運用前提（体制・権限・連絡経路）が伴っているかを確認する。承認後は、変更管理の対象としてRTOを扱い、システム更新や運用方針変更に応じて見直す運用が望ましい。結果として、目標が静的な数字に留まるのではなく、継続的に現実と整合する状態が保たれる。
4 RTO達成のための設計・運用
4.1 復旧方式の選択
4.1.1 バックアップ・リストア
バックアップ・リストアは、比較的標準的で広く採用される復旧方式である。RTOを短縮するには、バックアップの取得時間、世代数、復元の方式（全体復元か、差分やスナップショットを用いた短縮か）、復元先の性能（計算資源やストレージ速度）を調整することが必要になる。特にリストアの所要がRTOを律速するため、実測にもとづいた評価が重要となる。
4.1.2 冗長化・フェイルオーバー
冗長化・フェイルオーバーでは、障害発生時に別の経路や設備へ切り替えることで、停止時間を抑える。同期・非同期などの複製方式により復旧後のデータ鮮度が変化し、RPOにも影響する。加えて、切替の判断基準や切替手順の安全性確保が欠かせない。誤切替や回復不能状態を防ぐため、運用設計と検証の質がRTO達成に直結する。
4.1.3 マルチリージョン・高可用化
マルチリージョン構成や高可用化は、サイト単位の障害に備える方策である。通常運用では、可用性を高めるための監視、レプリケーション、切替の自動化が組み合わされる。RTOを短くするほど切替の確実性が問われるため、ネットワーク遅延や整合性の扱い、証明書や設定の同期など、複数領域の整合まで含めて設計する必要がある。
4.2 手順と自動化
4.2.1 プレイブック化（手順の標準化）
プレイブック化は、復旧手順を標準化し、担当者によるばらつきを減らす取り組みである。手順には、実施条件、必要な権限、チェックポイント、ロールバック方針、確認手段（ログ確認、疎通テスト、性能目標の検証など）を含める。標準化により、インシデント時の判断を速め、結果として目標復旧時間に収まりやすくなる。
4.2.2 オーケストレーションと自動復旧
オーケストレーションと自動復旧では、複数のタスクを連動させ、手作業を減らして復旧を加速する。例として、検知から切替判断、資源の起動、サービス再登録、監視の復旧までを段階的に実行する。自動化は誤作動リスクも伴うため、段階実行、承認付きフロー、例外系の定義、監査ログの確保などを含めて設計されるのが一般的である。
4.3 テストと改善
4.3.1 計画的な復旧テスト
復旧テストは、机上の想定を実地で検証し、RTOの実現可能性を確認する活動である。テストは全面復旧から部分的な確認まで段階があり、復元時間、依存関係の解消、利用可能状態の判定の妥当性を評価する。外部環境の条件（回線、認証、DNS、参照先データ）も結果に影響するため、テスト環境と本番環境の差異は記録しておくことが望ましい。
4.3.2 記録・学習によるRTO見直し
テストや実事案では、所要時間の内訳、手戻りの発生点、判断に迷った箇所を記録し、改善へつなげる。学習の成果は手順の改訂、構成の変更、自動化の追加、責任分界の調整として反映される。RTOは固定値ではなく、技術更新や組織体制の変化に合わせて定期的に見直す運用が、長期的な有効性を支える。
4.4 運用体制と演習
4.4.1 役割・連絡体制
運用体制では、インシデント指揮、実行担当、連絡担当、関係部門との調整役を明確に定める。連絡体制は、優先度や連絡手段、対応時間帯、代替連絡先まで含めて整備する。復旧の速度は技術だけでなく、意思決定や情報共有の遅延に左右されるため、事前に連絡経路と権限を整えておくことが重要になる。
4.4.2 インシデント演習（机上・実地）
インシデント演習は、机上演習と実地演習を組み合わせることで効果を高める。机上演習では判断や連絡手順、優先順位の整合性を確認し、実地演習では実際の復旧手順が時間目標に収まるかを検証する。演習の結果は、手順書やプレイブックの修正、担当者の習熟、運用ツールの改善へ反映され、次回の達成可能性を押し上げる役割を担う。