当ページは検証・整備中のドラフトです。
内容は実環境での検証や追加調査により変更される予定です。
参照：ページ公開・更新ポリシー
概要
RTO（Recovery Time Objective）、RPO（Recovery Point Objective）とは、事業継続計画（BCP）やシステムのバックアップ設計において最も基本となる、要件定義のための指標である。
データ消失やシステム停止のインシデント（災害、ハードウェア故障、ランサムウェア感染など）が発生した際に、どの程度許容するかを事前に定義しておく。
- RTO：どれだけの時間内に復旧させるべきか（＝最大で何時間停止してよいか）
- RPO：どの時点まで巻き戻せればよいか（＝最大でどれだけデータを失ってよいか）
これらの目標値を事前に定めることで、具体的なバックアップ方式、冗長化技術、あるいは代替機材の選定といった構成を、過不足無く適切に定めることができる。
技術的背景と仕組み
なぜ目標値が必要なのか
セキュリティ製品の導入・バックアップ体制の構築などでは、具体的な目標値が存在しないと過剰な投資（オーバースペック）による予算の浪費か、逆に不十分な対策（アンダースペック）による致命的な事業停止のいずれかを招くリスクが高まる。
例えば、オフィスの基幹NASが全損した場合
- 「いつまでに」 NASを再稼働させ、全社員が業務を再開できるようにすべきか。
- 「どの時点までの」 データの損失であれば、手動での再入力や取引先との調整によって実務上カバーできるか。
これらの限界値を事前に定義しなければ、毎日バックアップを取るべきか、1時間おきにスナップショットを取得すべきか、あるいは完全に別のNASを常時同期（レプリケーション）させるべきかという、最適な防御・復旧レベルを論理的に選定できない。
RTO（Recovery Time Objective：目標復旧時間）
RTOとは、災害や障害の発生によってシステムがダウンした瞬間から、必要な業務が復旧完了（利用者が再びアクセスできる状態に復元）するまでの、ビジネス上「許容される最大猶予時間」を指す。
- 指標の具体例：
- RTO 1時間： 決済システムやECサイトの管理画面など、1時間の停止が大きな機会損失や信用失墜に直結するインフラ。
- RTO 4時間： 社内のファイル共有や社内メールなど、数時間程度の停止であれば代替手段（チャットや電話など）で一時的にしのげるインフラ。
- RTO 24時間（1日）： 過去のアーカイブデータや、使用頻度の低い検証用サーバーなど、翌営業日の復旧でも事業継続に大きな影響を与えないインフラ。
RPO（Recovery Point Objective：目標復旧時点）
RPOとは、障害が発生した際に、過去の「どの時点」までのデータであれば喪失しても許容できるかという、データの鮮度に関する基準を指す。実質的には、バックアップを取得する頻度（間隔）を決定する物差しとなる。
- 指標の具体例：
- RPO 0分：銀行の取引ログなど、データ損失が金銭的な損失や法的トラブルに直結する領域。データを失わないことが求められるため、同期レプリケーションやリアルタイムなデータ保護が必要となる。SOHOでは過剰な目標数値であることが多い。
- RPO 1時間：ECサイトの受注データやリアルタイム性の高い業務資料や顧客対応履歴など、当日中の数時間分が消滅した場合の影響が比較的大きい領域。重要なデータはこの程度を目標にしたい。
- RPO 1日（24時間）： 通常のオフィス業務データなど、最悪の場合「昨日の夜のバックアップ時点」まで戻っても、本日分の業務（数時間〜1日分）を人間の手で再入力・復元することでカバー可能な領域。
RTOとRPOの違い
RTOとRPOは密接に関連しているが、防御・対策の対象となる技術レイヤーが明確に異なる。
| 比較項目 | RTO（Recovery Time Objective） | RPO（Recovery Point Objective） |
|---|---|---|
| 日本語訳 | 目標復旧時間 | 目標復旧時点 |
| 本質的な意味 | システムがダウンしてから「復旧するまでに要する時間」の許容値 | 障害発生により「失われるデータの最大量（過去への遡り幅）」の許容値 |
| 対策の主な対象 | 可用性： システムの復旧速度、機器の冗長化、運用手順、人的リソース | データ保護： バックアップの取得頻度、同期のタイミング、世代管理 |
| 指標の単位 | 時間（分、時間、日） | 時間（分、時間、日） |
| 表現の具体例 | 「システムが停止しても、4時間以内に全稼働状態へ戻す」 | 「システムが破損した場合、最大でも4時間前のバックアップデータへ戻す（過去4時間分のデータ消失は許容する）」 |
RTO・RPOを定めるメリット
- 論理的なバックアップ・冗長化方式の決定： 経営陣や現場が求めるRTO/RPOの数字から逆算することで、テープメディアへの保存、NASによる日次増分、あるいはクラウドへのリアルタイム同期など、技術選定の根拠が明確になる。
- IT投資の優先順位の明確化： 全てのシステムを最高水準にするのではなく、影響の大きいコアインフラのみRTO/RPOを極小化し、他はある程度まで許容するといった優先度を決定できる。
- 過剰投資・予算不足の防止： 必要性の薄いシステムに対して、24時間常時同期の高額なシステムを導入してしまうといったコストのミスマッチを防ぐ。
- 具体的かつ実効性のある復旧計画の策定： 復旧手順書や代替機材の手配プロセス、担当者のアサイン方針を「目標時間（RTO）」の枠内に収まるよう現実的にデザインできる。
RTO・RPOから決まること
RTOおよびRPOを明確に設定することで、組織に必要なセキュリティおよびインフラの以下の条件が可視化される。
- インシデント発生時に求められる、現場・ベンダー側の具体的な復旧作業のスピード感（復旧レベル）。
- ストレージ容量の設計に直結する、バックアップの適切な実行頻度（日次、時間次など）。
- 目標を達成するために投入すべき適切なインフラ予算の目安（予算感）。
- ハードウェアの予備（コールドスタンバイ、ホットスタンバイなど）をどの程度オフィスやクラウドに配置すべきかという冗長化レベル。
RTO・RPOでは分からないこと
これらはあくまでBCP（事業継続計画）における経営上・管理上の「目標値」であり、以下のようなことは保証できない。
- 「実際の被災時に、その想定時間内で復旧できるという確証」： 機材の手配遅れや回線切断、現場の混乱により、実際の復旧時間（RTA：Recovery Time Actual）がRTOを大幅に超過するケースがある。
- 「復旧作業中における人的ミスの発生リスク」： 手順の間違いや、焦りによるデータの二次災害（バックアップデータの誤削除など）の発生。
- 「用意された復旧手順書の品質や実効性」： 手順書が古く、最新のOS環境に対応していないといったドキュメントの形骸化は、目標値の設定だけでは検知できない。
- 「大規模災害の具体的な被災規模」： 地域全体の停電や物理的なオフィス損壊など、インフラそのものが完全に消滅した際の例外的なタイムラインはカバーしきれない。
限界と注意点
RTO・RPOとコストのトレードオフ（急峻なコスト増）
技術的に「RTO 0分」「RPO 0分（システムを1秒も止めず、データも1文字も失わない）」に近づけることは可能だが、それを達成するためには、メイン機材と完全に同一の構成を別拠点に構築して常時ミリ秒単位で同期させ、回線や電源を完全に二重化するなどの大規模なインフラ（ホットスタンバイ環境等）が必要となる。目標値を小さくすればするほど、機材代やクラウド維持費は指数関数的に急増するため、ビジネス上の損失額と対策コストのバランスを客観的に評価しなければならない。
バックアップデータだけではRTOは改善しない事実
バックアップデータが存在することは「RPO（データ損失量）」の担保にはなる。しかし、システムが稼働するPCやNASの本体が物理的に故障していた場合、代替機材の発注・納品、OSの再インストール、ネットワークの再設定、データの書き戻しにかかる時間はすべて「RTO」として消費される。
また、ランサムウェア被害では、復元前にバックアップデータ自体の安全性確認（いつ時点のデータなら感染していないか？）が必要となるため、実際の復旧時間がRTOを超える場合がある。
定期的な復旧訓練（リストアテスト）の不可欠性
設定したRTOが「4時間」であっても、実際にデータを外付けHDDからNASへ書き戻すテストを行ってみると、データ転送速度の物理的な限界により書き戻しだけで12時間以上かかることが判明する、といった事態もありえる。
机上の目標値と現場の実態（物理的な限界値）を一致させるためには、年に1回以上の復旧訓練と、実測値に基づくRTO/RPOの見直しが不可欠である。
まとめ
RTOはシステムダウンから業務を再開させるまでの「許容停止時間」であり、RPOは過去のどの時点まで巻き戻ることを許容するかという「許容データ損失量」である。
これらは、どのようなバックアップ製品やクラウドサービスを調達すべきかという「技術選定」を行うより先に、ビジネスの継続性という観点から経営層や業務責任者が決定すべき根本となる指標である。
目標値を決定した後は、コストとのトレードオフを評価し、実際の復旧テストを通じて手順や機材の調達スピードを目標の枠内に収めるための運用管理が、BCPを破綻させないための絶対条件である。