RPO・RTOとは？意味・違いと目標値の決め方

RPO・RTOとは

RPO（目標復旧時点）とは、障害や災害でデータが失われたときに「どの時点の状態まで戻せれば業務上許容できるか」を表す目標値です。RTO（目標復旧時間）とは、障害が起きてから「どのくらいの時間でシステムを使える状態に戻すか」を表す目標値です。

平易に言えば、RPOは「失ってもよいデータの量（時間の幅）」、RTOは「止まっていてもよい時間」です。たとえばRPOが1時間なら、障害の直前1時間分のデータは失われても仕方ないと合意していることになります。RTOが4時間なら、障害発生から4時間以内に業務を再開できる状態に戻すことが目標です。

RPOは Recovery Point Objective、RTOは Recovery Time Objective の頭文字です。システムのバックアップやDR（ディザスタリカバリ）を設計するときの出発点になる考え方です。

RPOとRTOは、時間軸の上で障害発生時点を挟んで向き合う関係にあります。

項目	見ている方向	問い	主に左右する仕組み
RPO	障害発生より過去	どこまで巻き戻ってよいか	バックアップの頻度、データの複製方式
RTO	障害発生より未来	いつまでに戻すか	予備環境の有無、復旧手順、体制

RPOを短くしたい場合は、バックアップを頻繁に取る、データを常時別の場所へ複製し続けるといった仕組みが必要です。RTOを短くしたい場合は、待機用の環境をあらかじめ用意しておく、切り替えを自動化する、夜間休日も対応できる体制を整えるといった備えが必要です。

どちらも短くするほど費用と運用の手間は増えます。そのため「とにかくゼロに近く」ではなく、業務への影響と費用のバランスで決めることが重要です。

なお、RTOとは別に、目標どおりに戻せなかった場合にどこまで業務を続けられるかを考える「業務継続」の観点もあります。システムが戻るまでの間、紙や電話で代替できるかどうかも、目標値の決め方に影響します。

ある会社が、ECサイト、社内の在庫管理システム、経営ダッシュボードの三つのシステムを運用している場面を考えます。それぞれ止まったときの影響が違うため、目標値も変えるのが合理的です（以下は架空の設定例です）。

システム	止まったときの影響	RPOの考え方	RTOの考え方
ECサイト	売上が止まり、注文データの消失は顧客対応に直結	ごく短く（注文を失わない）	短く（数時間以内を目指す）
在庫管理	出荷が遅れるが、一時的には紙で代替可能	数時間程度は許容	半日程度
経営ダッシュボード	意思決定が少し遅れる程度	前日分まで戻れればよい	翌営業日でよい

決め方の手順は次のとおりです。

目標値は保守契約にも関わります。開発会社や保守会社に運用を委託している場合、夜間や休日に誰が対応するのか、復旧作業の開始までにどれだけ時間がかかるのかによって、実現できるRTOは変わります。契約上の対応時間と目標値が食い違っていないかを確認しておきます。

この過程で大切なのは、システム担当者だけで決めないことです。データの消失や停止の影響を最もよく知っているのは業務部門であり、費用を判断するのは経営層です。三者で合意した数字であれば、障害が起きたときの判断や説明もぶれません。

目標値を決めただけで満足する：実際に復元を試さないと、目標を達成できるかは分かりません。訓練で測った実績と目標を比べます。
すべてのシステムを同じ水準にする：重要度の低いシステムまで厳しい目標にすると、費用が膨らみます。濃淡を付けます。
RTOに含める範囲があいまい：システムが起動した時点か、データの整合性を確認して業務を再開できた時点かで、必要な時間は大きく変わります。終わりの定義を決めておきます。
データの整合性を見落とす：RPOの時点まで戻したあと、その後に外部へ送った請求や通知とのずれが生じます。戻した後に何を確認・再送するかも手順に含めます。
外部サービスを考慮していない：決済や認証など外部サービスの復旧時間は自社では制御できません。依存しているサービスの公表情報も確認します。

RPO・RTOをどう決めればよいか分からない、決めた目標値に今の構成が見合っているか確かめたい、といったご相談に対応しています。業務部門へのヒアリングから目標値の整理、構成と費用の試算、復旧訓練の実施まで一緒に進めます。詳しくは保守・運用をご覧ください。

30分の無料相談で、運用中のシステムと現在の備えを伺います。

執筆：Otsumu株式会社／編集日 2026.10.01