要点
- RTOは6つの時間の合計です。検知、判断、アクセス情報の確認、技術的な作業、業務上の確認、利用者の復帰です。
- 米国国立標準技術研究所（NIST）は、RTOを最大許容停止時間（MTD）と区別しています。RTOは通常MTDより短くする必要があります。
- RTOはサービスごとに定めます。電話交換機とアーカイブでは、RTOは異なります。
- 文書上のRTOが守られているかを示せるのは、時間を計測したテストだけです。
- サポートの受付時間や待機体制の有無も、実際のRTOに含まれます。
公式な定義
NISTは、RTOを、情報システムの資源が、それが支える業務への影響が許容できなくなる前に利用不能のままでいられる最大の時間と定義しています。また、経営陣がある業務について許容する停止時間の合計である最大許容停止時間（MTD）と区別しています。RTOはMTDを超えないことを保証するものであるため、通常はMTDより短くなります。
フランスの国家サイバーセキュリティ庁であるANSSIは、許容可能な最大中断時間（DMIA）という用語を使っています。ANSSIは、バックアップ戦略において業務上の資産ごとにDMIAを考慮すること、そして依存関係（DNS、ディレクトリなど）やアプリケーションの重要度に応じて、復元の順序をあらかじめ定めることを求めています。
RTOを構成する時間
一般的な復元の場合：
- 障害に気づくまでの時間
- 判断を下し、対応できる担当者に連絡するまでの時間
- キー、パスワード、手順書を探す時間
- コピーまたは起動の技術的な時間
- 業務担当者による確認の時間
- 端末やリモートの利用者がサービスに再接続できるまでの時間（DNS、VPN、IPアドレス）
ソフトウェアがうたう「2時間」のRTOは、多くの場合、検証環境でのステップ4だけを数えたものです。実際のRTOは6つすべての合計です。夜間や週末に待機担当者がいなければ、ステップ2だけで2時間を超えることもあります。
事業継続計画（BCP）では、ステップ4と6は事前に準備されています。残るのは、検知と、誰も切り替えを承認しようとしないというリスクです。
RTOとRPOは一方と引き換えにできるものではない
RPOが短く（コピーが頻繁）、RTOが長い（大容量の復元に時間がかかる）ことがあります。反対に、RTOが短く（代替環境がすでに稼働中）、代替環境が2時間遅れていればRPOは不十分ということもあります。両方の数値をともに明記します。
RPO許容できる最大データ損失
RTO許容できる最大停止時間
過去に向かって測る
未来に向かって測る
インシデント前のデータ
!インシデント
サービスの再開
| RPO | RTO | |
|---|---|---|
| 問い | どれだけの作業を失ってもよいか？ | どれだけの時間停止していてもよいか？ |
| 測り方 | インシデントから過去に向かって | インシデントから未来に向かって |
| 調整する手段 | コピーの頻度 | 代替環境の準備 |
| 確認する方法 | 最後に成功したコピーの日時 | 時間を計測したテスト |
サービスごとのRTO
電話交換機とアーカイブ用の文書管理システムでは、RTOは異なります。会社全体で「RTO 4時間」と書くと、文書管理システムに過剰な費用をかけるか、電話交換機について事実と異なる説明をすることになります。サービスごとに1行あれば十分です。
RTOが守られているかを確かめる方法
テストで時間を計測する以外に方法はありません。テストに6時間かかり、文書上のRTOが2時間であれば、アーキテクチャが変わるまでは文書上のRTOのほうが誤りです。直近の計測で否定されたRTOを「目標」として掲げ続けることはできません。ANSSIもこの点を強調しており、復元手順を文書化し、定期的に実施するよう求めています。テストの頻度についてはDRPはどのくらいの頻度でテストすべき？で解説しています。
WeDoBackの場合
当サイトでは単一のRTOの数値を公表していません。それをでっち上げることは誤解を招きます。RTOは、データ量、回線、インスタンスのサイズ、お客様側の担当者の対応可否によって決まるからです。アーキテクチャによって変わるのは、時間の性質です。単純な復元では、データを戻し、必要に応じて再インストールする必要があります。災害復旧計画（DRP）では、選択したバージョンから代替インスタンス上でサーバーを再起動します。技術的な所要時間はこの再起動の時間であり、サーバーを購入する時間ではありません。起動テストは毎月、本番環境に影響を与えずに実施されます。事業継続計画（BCP）では、クラウドインスタンスが常時稼働しており、お客様のネットワーク上のエージェントを介して、IPアドレスを変更せずに引き継ぎます。残るRTOは主に検知と判断の時間です。BCPインスタンスと元のサーバーとの間のデータのレプリケーションや同期は標準機能ではなく、ニーズに合わせた個別のプロセスが必要です。WeDoBackがお見積もりのうえで構築することができます。いずれの場合も、業務上の確認は計測時間に含まれます。担当者によるサポートの受付時間は、9時～13時および14時～17時30分（パリ時間）です。
よくある質問
RTOとMTDの違いは何ですか？
MTD（Maximum Tolerable Downtime、最大許容停止時間）は、あらゆる影響を含めて、経営陣がある業務について許容する停止時間の合計です。RTOは、IT資源を再稼働させるまでの時間です。米国国立標準技術研究所（NIST）は、他の復旧ステップのための余裕を残すため、RTOは通常MTDより短くするべきだとしています。
あるソフトウェアが数分のRTOをうたっています。現実的ですか？
この数字は通常、検証環境での技術的な起動時間だけを数えたものです。障害の検知、権限を持つ担当者への連絡、利用者による確認の時間は含まれていません。実際のRTOは、前回のテストで、インシデントの宣言から最初の業務操作が成功するまでを実測した時間です。
RTOは法的な義務ですか？
中小企業に具体的な時間を義務付ける法令はありません。ただし、GDPR（第32条）は、インシデント発生時に個人データの可用性とアクセスを「適時に」回復できる手段を求めています。RTOは、この「適時」を具体的に定義する方法です。
関連ガイド
出典
2026年10月に参照した資料です。
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- 情報システムのバックアップ：基本事項（ANSSI-BP-100、v1.1、2025年11月27日、フランス語） — ANSSI
- 第4章：管理者及び処理者（GDPR第32条、フランス語） — CNIL（フランスのデータ保護機関）
- DRPプラン：災害後の業務再開 — WeDoBack