RTOとは？ わかりやすく10分で解説

はじめに

RTOとは？

RTO（Recovery Time Objective：目標復旧時間）とは、事故・障害・災害などでITシステムやサービスが停止した場合に、事業として許容できる範囲のサービス状態まで復旧させるための目標時間を指します。ポイントは「元の状態に完全に戻す」ではなく、まずは業務継続に必要な水準へいつまでに戻すべきかを定義することです。

RTOは、事業継続計画（BCP）やディザスタリカバリ（DR）計画の中核となる指標であり、重要なシステムがどれほど迅速に復旧する必要があるかを、合意された目標として明文化します。RTOが短いほど復旧体制・冗長構成・運用自動化などへの投資が必要になり、逆にRTOが長いほど停止影響（売上、信用、業務停滞など）を許容する判断になります。

そのためRTOは、「短くすべき」という一方向の話ではなく、停止による損失（ダウンタイムコスト）と、復旧を速めるためのコスト（設備・クラウド・人員・訓練）を天秤にかけて決めるのが実務的です。

RTOが必要なケース

RTOが重要になるのは、単に「サーバが落ちる」ケースだけではありません。実務で想定される代表例は次の通りです。

• 機器故障：ストレージ障害、ネットワーク機器故障、電源障害など
• 災害・広域障害：データセンター停止、拠点停電、回線断など
• サイバーインシデント：ランサムウェア、侵害疑いによる隔離、改ざん調査のための停止
• 運用起因：設定ミス、アップデート失敗、証明書期限切れ、DNS誤設定など
• 依存サービスの停止：認証基盤、決済、外部API、クラウド障害の波及

これらのケースでは、「どの機能を」「どの順序で」「どの体制で」復旧するかが勝負になります。RTOを決めていないと、障害発生時に優先順位が曖昧になり、復旧が遅れやすくなります。

RTOの考え方（算出の手順）

RTOは数式で一発計算するものではなく、業務影響と復旧現実性を突き合わせて決める指標です。一般的な考え方は次の流れになります。

1. 業務影響の整理（BIA）
   停止すると何が止まり、どんな損失が出るか（売上、顧客対応、法令・契約、社内業務）を洗い出します。
2. 優先順位付け
   全システムを同じRTOにするとコストが爆発しやすいため、重要度に応じて階層化します（例：最重要は2時間、重要は24時間、その他は72時間など）。
3. 依存関係の確認
   アプリ→DB→認証→DNS→ネットワークのように、復旧順序に影響する依存関係を整理します。
4. 復旧手順の分解
   切替判断、復旧環境起動、データ復元、設定投入、疎通確認、業務再開連絡などを工程化し、所要時間を見積もります。
5. 目標（RTO）と実力のギャップ確認
   現状の手順で何時間かかるかをテストし、目標に足りない分は、冗長化・自動化・体制・訓練で埋めます。

ここで重要なのは、復旧時間には「技術的な復旧」だけでなく、切替判断や連絡、復旧後の検証など運用要素が必ず乗る点です。手順の棚卸しなしに短いRTOだけ決めても、実運用では達成できません。

RTOと故障復旧（運用上の意味）

RTOは、障害発生時に「この時間内に、サービスを業務継続可能な水準へ戻す」という合意です。言い換えると、RTOは復旧の優先順位と投資判断を固定するための基準でもあります。

RTOを設定すると、次のような運用設計が具体化します。

• 復旧の順番：どのシステムから先に戻すか
• 復旧方式：手動復旧か、自動フェイルオーバーか、DRサイト切替か
• 体制：誰が判断し、誰が作業し、誰が顧客連絡するか
• 訓練・検証：定期テストで「本当にRTO内に戻るか」を測定する

結果として、復旧が属人化しにくくなり、障害時の混乱や時間ロスを抑えやすくなります。

RTOと事業継続の関係性

RTOは技術指標に見えますが、実態は事業がどれだけ止まっても耐えられるかという意思決定に直結します。ここでは、BCP/DRとの関係を整理します。

ビジネスコンティニュイティとは

ビジネスコンティニュイティ（事業継続）とは、災害・事故・サイバー攻撃・障害などの有事においても、重要業務を止めない、または止まっても早期に再開するための計画と準備を指します。対象はITだけでなく、人員・拠点・サプライチェーン・手作業代替なども含みます。

その中でITは「止まると業務が止まる」ことが多いため、BCP/DRではRTO（時間）とRPO（データ）を中心に、復旧水準を合意していきます。

RTOと事業継続計画の関係

BCP/DRにおいてRTOが重要なのは、RTOが「停止をどこまで許容しないか」を時間で表現できるからです。重要システムほどRTOは短くなり、短いRTOを達成するために、冗長構成や自動切替、24/7監視、復旧演習などの対策が具体的に必要になります。

また、RTOは単体システムではなく、業務（業務プロセス）単位で考えるのが安全です。業務が成立するために必要な複数システムがある場合、どれか一つでも復旧が遅れると業務は再開できません。

RTOがビジネスに与える影響

RTOが長い場合、停止期間が長引き、売上機会の逸失、顧客対応の遅延、SLA違反、信用毀損などの影響が拡大しやすくなります。逆にRTOを短く設定すると、復旧の速さは上がりますが、冗長化や運用体制などのコストが増えます。

つまりRTOは、「停止リスクをどれだけ許容するか」と「復旧投資をどれだけ行うか」の折衷点です。最適なRTOは、業務の性質や顧客への影響、契約要件、規制要件、競争環境によって変わります。

RTOとダウンタイムコスト

ダウンタイムコストは、単に売上だけではありません。代表的には次の要素が積み上がります。

• 直接損失：取引停止、受注停止、決済停止など
• 間接損失：問い合わせ増、現場の手戻り、担当者の残業・緊急対応
• 信用コスト：解約、評価低下、再発防止要求、説明対応の負荷
• 契約・規制リスク：SLA違反、監査指摘、罰則や是正命令のリスク

RTOは、このコスト増をどこで止めるかの目標であり、BCP/DR投資の根拠として使われます。

RTOの設定

RTO設定は「短く決める」ではなく、「達成できる状態を作る」までがセットです。ここでは、設定手順と落とし穴、実務上のベストプラクティスをまとめます。

RTO設定のための手順

1. 対象の棚卸し
   業務とシステムを紐づけ、重要業務に必要な構成要素（アプリ、DB、認証、ネットワーク、運用手順）を洗い出します。
2. 重要度の分類
   全てを最短RTOにしないために、業務重要度でグルーピングします。
3. 復旧方式の選定
   バックアップ復元、スタンバイ環境切替、アクティブ-アクティブなど、方式によって達成可能なRTOは大きく変わります。
4. 体制・手順の整備
   復旧Runbook、判断権限、連絡網、切替条件、検証手順まで整備します。
5. 訓練・測定・見直し
   机上ではなく、演習で所要時間を測り、RTOに合わせて改善します。

留意すべきRTO設定の落とし穴

• 過度に短いRTOを「目標だけ」決める
  実現手段（冗長化、自動化、体制）が伴わないと、障害時に形骸化します。
• 冗長化＝RTO短縮だと誤解する
  冗長化は停止確率を下げますが、切替が手動だったり、データ整合や検証が重いとRTOは短くなりません。
• 依存関係を見落とす
  アプリだけ復旧しても、認証、DNS、外部API、証明書、ネットワークが戻らなければ業務は再開できません。
• 「復旧完了」の定義が曖昧
  どの機能が動けば復旧とみなすか、受け入れ基準（疎通・性能・整合性）を合意しておかないと混乱します。

RTO設定時の業界ガイドラインとベストプラクティス

業界によっては規制や契約要件が強く、短いRTOが前提になることがあります。ただし、一般論としては、「必要な短さ」と「実現コスト」を一致させることがベストプラクティスです。

実務上は、次の考え方が安定します。

• 重要業務は“最短”ではなく“必要十分”を狙う
• 復旧方式を先に決め、達成可能なRTOを現実に落とす
• RTOは定期演習で測定し、数値として更新する

RTO設定とリソースの管理

短いRTOを達成するには、技術だけでは足りません。人・権限・手順・演習がそろって初めて実現します。たとえば24/7対応が必要ならオンコール体制、切替判断が必要なら権限委譲、復旧作業が複雑なら自動化が必要です。

RTOは「数字」ですが、その裏側には「現場の運用設計」があります。RTO設定は、リソース（予算・人員・スキル）と切り離せないテーマです。

RTOとその他の復旧指標との違い

復旧指標は似た言葉が多いため、混ざると設計が崩れます。ここでは、混同しやすい指標を整理します。

RTOとRPOの違い

RTOは「どれだけ早くサービスを戻すか（時間）」の目標です。一方、RPO（Recovery Point Objective：目標復旧時点）は「どれだけのデータ損失を許容するか（データの戻し先）」を時間で表します。

• RTO：サービス停止から復旧までの目標時間
• RPO：障害時に、過去のどの時点までデータを戻せればよいか（例：最大15分のデータ損失まで許容）

短いRTOを狙うほど復旧方式は高度化しやすく、短いRPOを狙うほどレプリケーションやログ転送などが必要になります。両者は連動しますが、同じ指標ではありません。

RTOとMTOの違い

MTO（Maximum Tolerable Outage：最大許容停止時間）は、ビジネスとして「止まっても耐えられる上限」を示す考え方で、事業目線の限界値です。RTOは「それより前に戻すための目標（技術・運用計画）」として置かれます。

一般に、設計としてはRTOはMTOを超えない（RTO ≤ MTO）関係になるように調整します。MTOが先にあり、RTOはそれを満たすために現実的に設定する、という順序が分かりやすいです。

RTOとMTPDの違い

MTPD（Maximum Tolerable Period of Disruption：最大許容中断期間）は、事業（業務）として許容できる中断期間を示します。MTPDは「業務が成立しない状態」を前提にするため、IT以外の要素（人員、拠点、手作業代替）も含めた観点になります。

整理すると、RTOはシステム復旧の目標、MTPDは事業中断の限界という位置づけです。業務側の限界（MTPD）を満たすように、システム側のRTOを設計します。

RTOとWRTの違い

WRT（Work Recovery Time：業務復旧時間）は、システムが復旧した後に、業務を平常運転へ戻すまでの時間を指します。たとえばシステム復旧後のデータ整合確認、手作業で溜めた処理の投入、業務部門の再開準備などが含まれます。

そのため、完全な業務復旧までの時間は、概念としては次のように見なせます。

RTOだけ短くしても、WRTが長いと「業務が戻らない」状態が続きます。復旧設計は、RTOとWRTの両方を見て成立させることが重要です。

RTOの業界事例

RTOは業界ごとに要求水準が変わります。ここでは「短い／長い」の一般論ではなく、なぜその傾向が生まれるかを、業務特性に紐づけて整理します。

金融業

金融は取引停止が直接的な損失や信用問題につながりやすく、また規制・監査要件も厳しいため、短いRTOが求められやすい業界です。取引系・決済系・認証基盤などは、切替の自動化や冗長化、演習の継続によって、短いRTOを現実の運用に落とし込む必要があります。

エネルギー業

供給の継続性が社会インフラに直結するため、停止時間が長いほど影響が大きくなりやすい領域です。制御系・監視系などは安全面の要件も強く、復旧だけでなく「安全に再開できること」を条件にした復旧設計が求められます。

IT業

オンラインサービスを提供する企業では、停止は売上・解約・評価に直結しやすいため、重要系は短いRTOが求められます。ただし「RTOをゼロにする」という表現は現実には難しく、実務では、自動フェイルオーバーやマルチAZ/マルチリージョンなどにより、停止を極小化して「限りなく短くする」設計を目指します。

製造業

生産ラインや受発注が止まると、機会損失だけでなく、物流・在庫・取引先にも影響が波及します。製造業では、現場の制御系と基幹系が絡むことが多く、どこまで止めずに運転継続できるか（手作業代替含む）と、どこまでを短いRTOで戻すかを分けて設計するのが現実的です。

RTOとテクノロジー

RTOを短縮する鍵は、(1)停止を起こしにくくする、(2)起きてもすぐ切替できる、(3)復旧作業を速く正確に行う、の3点です。テクノロジーはこの3点を支えます。

テクノロジーがRTOをどのように改善するか

テクノロジーは、復旧の「速度」と「再現性」を改善します。たとえば監視とアラートで検知を早め、構成管理で復旧手順を標準化し、自動化で作業時間とミスを減らします。結果として、RTO達成の確度が上がります。

また、障害対応で見落とされがちなのが「判断と連絡」です。技術的な復旧が速くても、切替判断が遅れるとRTOは達成できません。検知→判断→切替→検証→再開の一連を通して短縮する設計が必要です。

RTOとクラウドコンピューティング

クラウドは、復旧環境の準備を迅速化しやすく、RTO短縮に寄与します。代表的には、代替環境の立ち上げ、スケール、地理分散、バックアップ保管などを、オンプレミスより機動的に設計できる場合があります。

ただし、クラウドを使えば自動的にRTOが短くなるわけではありません。マルチAZ/リージョン設計、切替方式、DNS/認証など依存関係の設計、復旧手順の演習が伴って初めて、短いRTOが現実になります。

RTOとデータレプリケーション

データレプリケーションは、復旧時に「最新に近いデータを素早く使える」状態を作りやすく、RTO短縮に有効です。復旧で時間を食うポイントは、しばしばデータ復元と整合性確認にあります。レプリケーションにより復元工程を軽くできれば、復旧時間を縮めやすくなります。

一方で、レプリケーションはRPOにも影響し、方式（同期/非同期）によっては遅延やコスト、障害時の整合性設計が課題になります。RTOだけでなくRPOと合わせて設計することが重要です。

RTOと自動化

復旧プロセスの自動化は、RTO短縮の王道です。具体的には、フェイルオーバーの自動実行、IaCによる環境再構築、復旧手順のRunbook自動化、監視からチケット発行までの連携などが該当します。

自動化の価値は「速い」だけでなく、「人による手順差やミスを減らし、毎回同じ手順で復旧できる」点にあります。短いRTOほど、属人対応では達成が難しくなるため、標準化と自動化が効果を発揮します。

FAQ