RTOとは？RPO・RLOとの違いや適切な目標設定方法を解説
RTOとは？RPO・RLOとの違いや適切な目標設定方法を解説
公開日
最終更新日
RTOは業務再開までの時間目標、RPOは許容できるデータ損失時点の目標です。障害、災害、ランサムウェア被害が起きたとき、情シス担当者は「何時間で業務を再開するか」と「何時間前のデータまで失ってよいか」を別々に決めなければなりません。
RTOを短く設定するだけでは、実際の復旧力は高まりません。復旧対象、代替業務、バックアップの取得間隔、担当者の連絡体制、復旧テストの結果までそろって初めて目標が機能します。BCPにおけるRTOの位置付けと、目標値を実現するための復旧方式・検証方法を、情シスの実務に沿って整理します。
RTO（目標復旧時間）とは
RTOとは、障害発生から、あらかじめ定めた業務またはサービスの水準で再開するまでの目標時間です。
本記事のポイント
RTOは「いつ業務を再開するか」、RPOは「どこまでデータ損失を許容するか」を示す別の指標です。
RTOはシステム単位ではなく、業務影響と復旧優先順位から設定します。
バックアップがあっても、復元手順とテストがなければRTOを達成したとはいえません。
短いRTOほど、冗長化・自動切替・運用体制への投資が増えます。
BCPにおける位置付け
BCPでは、システムを起動できた時点ではなく、受注、顧客対応、会計処理などの優先業務を再開できた時点を復旧完了として定義します。IPAは、情報システムの復旧目標としてRLO、RTO、RPOの3種類を決定すると整理しています。したがって、情シスだけで時間を決めず、業務部門と復旧対象・再開条件を合意する設計が必要です。
障害発生後のタイムライン
障害発生を起点に、RPOは過去方向のデータ損失許容範囲、RTOは未来方向の停止許容時間を示します。例えばRTOが4時間なら、障害の検知、原因の切り分け、環境復旧、データ復元、業務確認までを4時間以内に終える計画です。復旧作業だけに4時間を割り当てると、連絡や動作確認の時間が不足します。
▶ 関連記事: リスクアセスメントとは？手順や目的・評価方法を簡単に解説
▲ 障害発生時を中心としたRPO・RTO・MTPDの時間軸上の関係
RTOとRPO・RLO・MTPDとの違い
RTO、RPO、RLO、MTPDは、停止時間、データ、復旧水準、事業継続の限界をそれぞれ管理する指標です。
RPOが4時間の場合、障害時には原則として最大4時間分の更新データを失う可能性があります。これは「最長でも4時間前のデータに戻すことが必要です」という意味ではなく、4時間以内のデータ損失を許容範囲として復旧時点を設計する考え方です。
指標 | 意味 | 判断する内容 | 例 |
|---|---|---|---|
RTO | 目標復旧時間 | いつ業務を再開するか | 4時間以内に受注業務を再開 |
RPO | 目標復旧時点 | どこまでのデータ損失を許容するか | 最大1時間分の更新損失を許容 |
RLO | どの業務水準まで戻すか | 受注のみ先行し、分析機能は後回し | |
MTPD | 許容限界停止時間 | 事業継続が困難になる限界 | 24時間を超える停止は契約違反につながる |
指標間の整合性
MTPDより短いRTOを置き、RTO達成時に必要なRLOを明文化します。そのうえで、RPOに見合うバックアップ間隔またはレプリケーション間隔を決めます。RTOが2時間でも、復旧後に必要な受注データが失われていれば業務は再開できないため、RTOとRPOは必ず組み合わせて判断します。
BCPにおけるRTOの具体的な設定手順
BCPのRTOは、業務影響を数値化し、現行環境で実現可能かを検証してから確定します。
業務影響分析から目標合意までの5ステップ
次の順序で進めると、希望的な目標値だけが先行する失敗を防げます。
優先業務の特定：停止時に売上、契約、法令対応、顧客安全へ影響する業務を洗い出します。
影響の算定：停止後1時間、4時間、1日などの時点ごとに、未処理件数、契約上の期限、手作業で代替できる範囲を記録します。
MTPDとRLOの決定：業務部門と、停止できる限界と最低限再開すべき機能を合意します。
RTO・RPOの設定：業務の限界値より余裕を持たせたRTOと、許容損失に対応するRPOを決めます。
実現性の評価：復元時間、ネットワーク帯域、依存システム、担当者の参集時間を測定し、目標未達なら方式か目標を見直します。
現行のITインフラを評価する際は、サーバー単体の復旧時間ではなく、認証基盤、DNS、ネットワーク、SaaS連携、業務確認までを合算します。RTOを24時間と設定する場合は、障害後24時間以内に復旧させることが目標になります。
設定値の具体例
例えば、受注業務のMTPDが8時間で、4時間以内に受注入力だけを再開できれば契約上の影響を抑えられる場合、RLOを「受注入力と参照」に設定し、RTOを4時間とします。直近1時間の受注データを手入力で補完できるならRPOは1時間、補完できないならRPOを短縮し、取得間隔を見直します。
業務部門との合意形成では、次の項目を業務ごとに確認すると判断の根拠を揃えやすくなります。
下表は業務部門と情シスが共同で埋めるワークシートです。各セルに具体的な数値・条件・担当部門のコメントを記入し、BCP文書に添付して使います。
確認項目 | 1時間停止 | 4時間停止 | 24時間停止 |
|---|---|---|---|
発生する損失・違約リスク | 例：未対応問い合わせ件数、SLA違約金の発生有無 | 例：売上機会損失額の試算、顧客通知の要否 | 例：契約解除リスク、行政報告義務の発生 |
契約・法令上の期限 | 例：当日中に処理が必要な法定申告の有無 | 例：SLA応答時間の超過タイミング | 例：法定保存データの提出期限 |
手作業で代替できる範囲 | 例：電話受付・紙台帳での受注記録が可能 | 例：手作業での処理件数の上限（〇件/時） | 例：手作業での継続が困難になる時点 |
最低限必要な機能（RLO） | 例：受注入力と在庫参照のみ | 例：受注・出荷指示のみ、分析機能は不要 | 例：外部顧客向け機能のみ先行復旧 |
許容できるデータ損失量 | 例：直近30分の更新は手入力で補完可能 | 例：1時間分までは補完可、それ以上は要再設計 | 例：補完不可のため、RPO短縮を前提とする |
各セルを業務部門と情シスが共同で埋めることで、MTPDとRTOの根拠が記録に残り、復旧方式の選定や予算判断に使えます。
▲ 絵に描いた餅を防ぐRTO設定の5ステップ手順
RTO目標に応じた復旧方式の比較
復旧方式は、求めるRTOとRPOに対して必要十分なものを選び、過剰な冗長化を避けます。下表の時間帯はシステム規模、データ量、依存関係、復旧環境の有無により大幅に変動する設計上の仮説値です。実際に採用した方式では必ず復旧テストで実測し、表の数値との乖離を記録します。
復旧方式 | RTO・RPOの目安（設計仮説値） | 主な運用 | 注意点 |
|---|---|---|---|
日次バックアップと手動復元 | 両方とも24時間程度（データ量・担当者参集時間により延長する場合あり） | バックアップ、手順書、復元訓練 | 復元速度と担当者依存を実測する |
遠隔地バックアップ | 数時間から1日程度（ネットワーク帯域・転送データ量で変動） | 別拠点への転送、復元環境の確保 | 転送完了と保管データの整合性を確認する |
レプリケーションとDRサイト | RPOは数分、RTOは数十分から1時間程度（ランサムウェア被害時は隔離・クリーン環境構築で大幅に延伸する場合あり） | 複製、自動化、切替訓練 | 依存先を含む切替手順を検証する |
Futureの解説では、RTO・RPOがともに24時間程度なら日次バックアップと手動復元、RPOが数分かつRTOが数十分から1時間程度ならDRサイト、マルチゾーン、自動切替が対策例として示されています。
国内事例による到達水準
BIPROGYは2026年公表の災害対策切替検証で、切替処理を11分で完了し、データベースのデータ損失をゼロ、業務ファイルの損失を最大9分の更新分と確認しました。この数値は、同社が構築・事前設定した特定のDRサイト構成と切替手順を前提とした検証結果であり、対象範囲や事前構成が異なれば実測値は変わります。詳細はBIPROGYが公表する一次資料で確認してください（本記事執筆時点では同社公式サイトに掲載）。新小山市民病院は電子カルテのRTOを12時間以内に設定し、Rubrikを使う復元テストで約11時間ですべてのデータを復元できることを確認しています。この結果は電子カルテシステム単体の復元時間であり、認証基盤や周辺システムを含む業務全体の再開時間とは異なる場合があります。詳細はRubrikが公開するケーススタディで確認できます。いずれの事例も、自社のシステム構成・データ量・依存関係をそのまま反映した数値ではないため、参考水準として扱い、目標値は自社環境で実測した結果で評価します。
▲ 求められるRTO・RPO目標レベルに応じた3つの復旧方式比較
RTOの検証と見直し運用
RTOは文書上の宣言ではなく、定期テストで実測し、未達要因を是正して維持する運用指標です。
RTO設定・検証チェックリスト
テスト前後に次の項目を記録すると、次回の改善判断に使えます。
優先業務、復旧対象、RLO、RTO、RPOを業務部門と合意したか
バックアップの最終成功時刻と、復元可能な時点を確認したか
検知、連絡、復旧、業務確認を分けて所要時間を測定したか
認証、ネットワーク、外部連携を含めて業務再開を確認したか
未達の原因を、手順・権限・容量・体制のいずれかに分類したか
変更後の構成で再テストする日時と責任者を決めたか
AWSはResilience Hubのドキュメント「AWS Well-Architected フレームワーク ― データの定期バックアップとリカバリのテスト」、で、アプリケーション構成を回復力ポリシーに照らして評価し、RTO・RPO目標を満たせるか報告するアセスメントをResilience Hubで実行できると説明しています。クラウド構成を利用している場合、構成評価で候補を絞り、実際の復旧テストで業務再開まで測定する二段階にします。
RTO設定で起きやすい失敗パターン
最も多い失敗は、バックアップの取得成功を復旧成功とみなし、業務再開までの時間を測っていないことです。
目標値だけを短くする設計
短いRTOを先に掲げても、復元用アカウント、手順書、帯域、依存サービスがそろわなければ達成できません。復旧テストで実測値がRTOを超えた場合は、復旧対象をRLOに合わせて絞る、手順を自動化する、または復旧方式を変更するという順で対応します。リスク管理では、停止による影響と対策費用を同じ表で比較すると判断しやすくなります。
バックアップを過信する運用
IPAはランサムウェア被害事例として、発覚5日後にバックアップから基幹システムを再稼働した一方、社内システムの利用再開には41日、リモートアクセス再開には4か月を要し、社内ファイルの2割強を失った事例を紹介しています。復元データの有無だけでなく、隔離、端末再展開、認証基盤の復旧、業務部門の受入確認までを訓練範囲に含めます。
まとめ
RTOは業務・サービスを再開するまでの目標時間であり、RPOは許容できるデータ損失の目標時点です。BCPでは、RLOで再開時の業務水準を定め、MTPDを超えないRTOを設定します。明日から着手するなら、最優先業務を1つ選び、障害検知から業務確認までの復旧時間を実測してください。実測値と目標値の差分を記録すれば、バックアップ、体制、復旧方式のどこを改めるべきか判断できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
