【用語解説】RPOとRTOとは?違いとBCP/DR設計での考え方をわかりやすく解説

更新日:2026-06-26 公開日:2026-06-26 by Bitmoss

目次

【用語解説】RPOとRTOとは?違いとBCP/DR設計での考え方をわかりやすく解説RPO(目標復旧時点)は「どこまでデータを戻せればよいか」、RTO(目標復旧時間)は「どれくらいの時間で業務を再開するか」を示す指標です。この2つはBCPやDRを設計する際に最初に決めるべき復旧要件です。

先に整理しておくことで必要な対策を判断しやすくなりますが、「バックアップを取っているから安心」「クラウドを使っているから大丈夫」と考えていると、障害発生時に想定どおり復旧できないケースも少なくありません。

この記事では、RPOとRTOの意味や違い、BCP・DR設計で重要な理由、中小企業が現実的に復旧要件を決める考え方までまとめて解説します。

RPO(目標復旧時点):どこまでデータを戻せればよいかを示す指標。バックアップ頻度やレプリケーションの必要性を判断する基準になる。

RTO(目標復旧時間):どれくらいの時間で業務を再開するかを示す指標。監視や復旧手順、DR構成を検討する際の基準になる。

RPOとは

RPOは「どこまでデータを失っても許容できるか」を決めるための指標です。

BCPやDRでは、バックアップの取得頻度やレプリケーションの必要性を判断する基準として利用されます。

RPOとは、Recovery Point Objectiveの略で、日本語では「目標復旧時点」と訳されます。障害が発生した際、どの時点までデータを戻せれば業務を継続できるのかを表す指標です。

たとえば、RPOを24時間に設定している場合、障害発生時に最大24時間分のデータ消失を許容するという考え方になります。一方、RPOを1時間に設定すれば、失われるデータは最大1時間分までに抑えることが求められます。

  • RPOが24時間:最大24時間分のデータ損失を許容する
  • RPOが1時間:最大1時間分のデータ損失を許容する
  • RPOが15分:データ損失を15分以内に抑える必要がある
  • RPOが数分:データ損失を極力発生させないことを目指す

例えば、毎日深夜0時にバックアップを取得している環境で、翌日の18時に障害が発生した場合、最後のバックアップ時点までしか復元できない可能性があります。この場合、日中に更新されたデータは失われます。

そのため、RPOを短くしたい場合は、バックアップ頻度を高めるだけでなく、レプリケーションや継続的なデータ保護(CDP)などの仕組みを組み合わせるケースもあります。

つまりRPOは、「どれだけデータを守りたいか」を決めるための指標であり、バックアップやデータ保護方式を選定するうえで重要な役割を果たします。

RTOとは

RTOは「どれくらいの時間で業務を再開するか」を決めるための指標です。

システム停止が売上や顧客対応へどれほど影響するかを考えながら、復旧までに許容できる時間を決めるために利用されます。

RTOとは、Recovery Time Objectiveの略で、日本語では「目標復旧時間」と訳されます。障害発生からシステムや業務を再開するまでに許容できる時間を表す指標です。

例えば、RTOを8時間に設定している場合は、障害発生から8時間以内に業務を再開することが目標になります。一方、RTOが30分であれば、短時間でシステムを切り替えられる仕組みや運用体制が必要になります。

RTOが短いほど、復旧に使える時間は限られます。そのため、単にバックアップを取得するだけではなく、監視、復旧手順、代替環境、DRサイトなどを組み合わせて設計する必要があります。

  • RTOが24時間:翌営業日までの復旧を目指す
  • RTOが8時間:当日中の業務再開を目指す
  • RTOが2時間:短時間での復旧体制が必要になる
  • RTOが30分:自動切り替えや待機環境の検討が必要になる

なお、RTOは「復旧作業そのもの」にかかる時間だけを意味するものではありません。障害の検知、原因の切り分け、システム切り替え、動作確認、利用部門への連絡など、業務を再開できる状態になるまでの一連の時間を含めて考えます。

つまりRTOは、「どれだけ早く業務を再開する必要があるか」を決めるための指標であり、監視や復旧方式、DR構成を検討する際の基準となります。

RPOとRTOの違い

RPOとRTOは時間軸で考えると違いを理解しやすくなります。まずは次の図をご覧ください。futuremedia-309-01

RPOとRTOの違いは、「データ損失をどこまで許容するか」と「業務停止をどこまで許容するか」という、見る対象が異なる点にあります。

どちらもBCP・DR設計では欠かせない指標ですが、それぞれ役割が異なります。RPOはデータ保護の目標を決める指標、RTOは業務復旧の目標を決める指標として考えると理解しやすくなります。

項目 RPO RTO
日本語訳 目標復旧時点 目標復旧時間
意味 どの時点のデータまで戻せればよいか どれくらいの時間で業務を再開するか
対象 データ損失 システム停止・業務停止
主に関係する対策 バックアップ、レプリケーション 監視、復旧手順、DRサイト、切り替え
24時間前、1時間前、15分前まで戻せる 24時間以内、4時間以内、30分以内に業務を再開する

RPOは「データ」、RTOは「時間」を表す指標と覚えると違いを理解しやすくなります。

例えば、RPOが24時間、RTOが2時間という場合は、「最大24時間分のデータ損失は許容できるが、障害発生後2時間以内には業務を再開したい」という意味になります。

このように、RPOとRTOは必ずセットで考えることが重要です。どちらか一方だけでは、必要な復旧対策を判断できません。

RPO/RTOがBCP・DR設計で重要な理由

BCPやDRでは、製品やクラウドサービスを選ぶ前にRPOとRTOを決めることが重要です。

なぜなら、RPOとRTOによって必要なバックアップ方式や監視体制、レプリケーション、DRサイトなどの構成が大きく変わるためです。

例えば、RPOが24時間であれば日次バックアップで対応できる場合があります。一方、RPOを15分以内にしたい場合は、高頻度バックアップやレプリケーションなどを検討する必要があります。

また、RTOが24時間であればバックアップからの復元でも対応できることがありますが、RTOが1時間以内であれば、待機環境やDRサイト、自動切り替えなどの仕組みが必要になるケースもあります。

つまり、RPOとRTOは「どのようなDR対策が必要なのか」を決める設計条件といえます。

DRそのものの考え方について詳しく知りたい方は、「DRとは?災害対策で重要な考え方を解説」もあわせてご覧ください。

RPO/RTOを決めないと起こる問題

RPOとRTOを決めずにDR対策を進めると、必要以上の投資をしてしまったり、逆に十分な復旧ができなかったりする可能性があります。

例えば、「バックアップは取得しているから安心」と考えていても、実際には復元に10時間以上かかるケースがあります。この場合、データは戻せても、RTOが2時間であれば目標を達成できません。

反対に、すべてのシステムに高可用性を求めると、運用コストや構築コストが大きくなります。重要度の低いシステムまで短いRPO・RTOを設定すると、過剰投資につながる可能性があります。

RPO・RTOを整理しないままDR設計を進めると、次のような課題が起こりやすくなります。

  • バックアップはあるが、復旧に時間がかかる
  • 重要なデータが十分に保護されていない
  • システムごとの優先順位が決まっていない
  • 必要以上に高価な構成を選んでしまう
  • 障害時の対応手順が曖昧になり、復旧判断が遅れる

BCP・DRでは、システム単位ではなく「業務を止められる時間」と「失ってよいデータ量」を整理することが重要です。

BCP・DR全体の考え方については、「BCP・DRとは?違い・必要性・クラウド対策までわかりやすく解説」も参考にしてください。

RPO/RTOを満たすための対策

RPOとRTOを実現する方法は1つではありません。

必要な復旧要件に応じて、バックアップ、監視、レプリケーション、DRサイトなどを組み合わせて設計することが一般的です。

例えば、データ損失を抑えたい場合はRPOを意識したバックアップやレプリケーションが重要になります。一方、短時間で業務を再開したい場合は、RTOを意識した監視やDRサイト、復旧手順の整備が必要になります。

重要なのは、「どの対策を導入するか」ではなく、「設定したRPO・RTOを満たせるか」という視点で考えることです。

バックアップだけではRTOを満たせないケース

バックアップはDR対策の重要な要素ですが、バックアップだけではRTOを満たせない場合があります。

バックアップは、主にデータを元の状態へ戻すための仕組みです。そのため、RPOには大きく関係します。一方、RTOを満たすには、データを復元したあとにシステムを起動し、動作確認を行い、利用者が業務を再開できる状態まで戻す必要があります。

例えば、毎日バックアップを取得していても、データ量が多く復元作業に12時間かかる場合があります。このとき、RTOが24時間であれば対応できるかもしれませんが、RTOが2時間であれば要件を満たせません。

特に次のようなケースでは、バックアップだけでは十分とはいえない場合があります。

  • 復元するデータ量が多い
  • 復旧手順が手作業中心になっている
  • 代替サーバーや待機環境を用意していない
  • システム間の依存関係が複雑で復旧順序の確認に時間がかかる
  • 障害発生の検知が遅れ、復旧開始まで時間がかかる

このような場合は、バックアップに加えて監視やレプリケーション、DRサイトなどを組み合わせることで、RTOの短縮を目指します。

バックアップとDRの違いについて詳しく知りたい方は、「DRとバックアップの違い」を解説した記事もご覧ください。

RPO/RTO別の代表的な対策例

RPO・RTOは短くするほど、高度な仕組みや運用が必要になります。

そのため、すべてのシステムで最短のRPO・RTOを目指すのではなく、業務への影響を踏まえて現実的な目標を設定することが重要です。

想定するRPO 想定するRTO 代表的な対策例
24時間程度 24時間程度 日次バックアップ、手動復元、復旧手順書の整備
数時間程度 半日程度 高頻度バックアップ、クラウドバックアップ、復旧テスト
1時間以内 数時間以内 レプリケーション、待機環境、監視強化
数分程度 数十分〜1時間程度 DRサイト、マルチゾーン構成、自動切り替え

これはあくまで代表例です。実際には、システムの重要度、予算、運用体制、利用部門の要件などを踏まえて設計する必要があります。

監視・バックアップ・レプリケーション・DRサイトとの関係

RPO・RTOを満たすには、複数の対策を組み合わせて設計することが一般的です。

対策 主に関係する指標 役割
監視 RTO 障害を早期に検知し、復旧開始までの時間を短縮する
バックアップ RPO 障害発生時にデータを復元できるようにする
レプリケーション RPO・RTO 別環境へデータを複製し、復旧時間とデータ損失を抑える
DRサイト RTO 本番環境が停止した際に代替環境で業務を再開する

RPO・RTOが短くなるほど、バックアップだけではなく、監視やレプリケーション、DRサイトを組み合わせた設計が求められるケースが増えます。

特に、国内DRサイトやマルチゾーン構成を検討する場合は、データ配置やネットワーク構成、運用体制も含めた設計が重要です。詳しくは、「国内DRサイト・マルチゾーン構成」を解説した記事をご覧ください。

中小企業がRPO/RTOを決めるポイント

中小企業では、すべてのシステムに高い復旧要件を設定するのではなく、業務への影響に応じてRPO・RTOを決めることが重要です。

限られた予算や人員でDR対策を進める場合は、「どの業務を優先して守るべきか」を整理することが現実的です。

まずは社内システムを、事業継続への影響度に応じて分類すると考えやすくなります。

業務・システム例 考え方 RPO・RTOの目安例
基幹システム・受発注システム 停止すると売上や顧客対応へ直結するため優先度が高い RPO:短め RTO:短め
ファイルサーバー・社内共有データ 業務影響は大きいが段階的な復旧も検討できる RPO:数時間~24時間 RTO:数時間~翌営業日
社内ポータル・情報共有サイト 代替手段がある場合は復旧優先度を調整できる RPO:24時間程度 RTO:翌営業日以降も検討

RPO・RTOは情報システム部門だけで決めるものではありません。利用部門や経営層と話し合い、「どの業務が止まると困るのか」「どのデータを失うと事業へ影響するのか」を整理することが重要です。

RPO・RTOを決めるときの注意点

RPO・RTOは短く設定するほど、安全性は高まりますが、その分コストや運用負荷も増加します。

例えば、RPOを数分に近づけるにはレプリケーションや継続的なデータ保護が必要になる場合があります。また、RTOを短縮するには待機環境やDRサイト、監視体制、定期的な復旧テストなども必要になります。

そのため、次のような観点でバランスを考えることが大切です。

  • 業務は何時間停止すると大きな影響があるか
  • どのデータが失われると事業へ影響するか
  • 必要なコストを継続して負担できるか
  • 自社の運用体制で維持できるか
  • 障害時に実行できる現実的な復旧手順になっているか

重要なのは、「最も短いRPO・RTO」を目指すことではなく、自社にとって適切な復旧目標を設定することです。

クラウド環境でRPO/RTOを考えるポイント

クラウドを利用していても、RPO・RTOが自動的に満たされるわけではありません。

クラウドはバックアップやレプリケーション、DR環境を柔軟に構築できるというメリットがありますが、それらをどのように設計・運用するかは利用者側で決める必要があります。

例えば、バックアップの取得頻度が少なければRPOは短くできません。また、復旧手順が整備されていなければ、クラウド環境でもRTOは長くなります。

クラウド環境では、次のような観点でRPO・RTOを確認すると整理しやすくなります。

  • バックアップ頻度はRPOを満たしているか
  • 復元時間はRTOを満たしているか
  • 障害を早期に検知できる監視体制があるか
  • DRサイトや別リージョンを利用する必要があるか
  • 復旧手順を定期的に検証しているか

クラウドを活用したBCP・DR対策について詳しく知りたい方は、「クラウドで実現するBCP・DR対策」もあわせてご覧ください。

よくある質問

RPOとRTOはどちらが重要ですか?

どちらも重要です。RPOはデータ損失、RTOは停止時間を表すため、どちらか一方だけでは適切なDR設計はできません。

RPOを0にできますか?

同期レプリケーションなどによって限りなく近づけることは可能ですが、コストや構成が複雑になるため、すべてのシステムで現実的とは限りません。

バックアップだけでDR対策になりますか?

バックアップは重要な対策ですが、復元に時間がかかる場合はRTOを満たせません。必要に応じて監視やレプリケーション、DRサイトなども組み合わせて検討します。

クラウドならRPO・RTOは自動的に満たせますか?

いいえ。クラウドはDR対策を実現しやすい環境ですが、RPO・RTOはバックアップ頻度やシステム構成、運用方法によって決まります。

中小企業でもRPO・RTOを決める必要がありますか?

必要です。限られた予算の中で優先順位を決めるためにも、RPO・RTOを整理しておくことが重要です。

BCP/DRの全体設計やクラウドを活用した対策について詳しく知りたい方は、次の記事もあわせてご覧ください。

まとめ

RPOは「どこまでデータを戻せればよいか」、RTOは「どれくらいの時間で業務を再開するか」を示す指標です。

RPOはデータ損失の許容範囲、RTOは業務停止時間の許容範囲を決めるために利用されます。BCP・DRでは、この2つを整理することで、必要なバックアップ方式やレプリケーション、監視、DRサイトなどの対策を判断しやすくなります。

また、バックアップだけではRTOを満たせないケースもあり、業務重要度や予算に応じて複数の対策を組み合わせることが重要です。

まずは「どの業務をどれくらい止められるか」「どのデータをどこまで守る必要があるか」を整理し、自社に適したRPO・RTOを設定したうえでBCP・DR対策を検討しましょう。

この記事をシェアする

  • 記事をnoteでシェアnote
  • 記事をメールでシェアメール
  • 記事のリンクをコピーリンクをコピー

関連記事