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

災害・大規模障害・サイバー攻撃などで業務が止まったとき、「いつまでに復旧するか」だけでなく、「どのレベルまで戻せば事業が回るのか」まで決めておかないと、現場は判断に迷い、復旧が遅れがちです。本記事では、復旧の“水準”を定義する指標であるRLO（Recovery Level Objective）を軸に、RTO/RPOとの違い、設定の進め方、運用・改善のポイントまでを整理します。

RLOとは何か

RLOの定義

RLO（Recovery Level Objective）は、障害発生後の一定の時間枠の中で「どのレベルまで」システムや業務を復旧させ、操業・サービスを再開するかを定める目標値です。RTOが“時間”、RPOが“データの復旧時点”に焦点を当てるのに対し、RLOは“復旧後の提供レベル（処理能力・品質・機能範囲など）”を明確にします。

RLOが必要とされる背景

近年は、自然災害だけでなく、クラウド障害、サプライチェーン要因、ランサムウェアなど、復旧プロセスが複雑になりやすい事象が増えています。復旧手順や代替策が用意されていても、「全機能を元通りにするまでサービス再開できない」と考えてしまうと、再開判断が遅れます。そこでRLOを定義し、最低限の提供レベル（段階復旧）を決めておくことが実務上の効果につながります。

RLOとRTOとRPOの違い

RLOで決める復旧レベルの例

• 機能範囲：重要機能だけ先に復旧し、周辺機能は後で戻す（例：決済は復旧、レコメンドは停止）
• 処理能力：通常時の何％で再開するか（例：ピーク時の30％で再開し、段階的に増強）
• 品質レベル：性能・応答時間・SLAを一時的に緩和する（例：応答遅延を許容して再開）
• 運用方式：手作業・代替手段でしのぐ範囲を決める（例：請求書発行は一時的に手動）

RLOの重要性

事業継続における役割

RLOは、復旧のゴールを「完全復旧」から「事業が回る最低ライン」へ落とし込み、意思決定を早める役割を持ちます。復旧時間（RTO）だけを短く設定しても、再開水準が曖昧だと、結局は“何をもって復旧とするか”で揉めてしまい、現場の動きが止まります。

RLOが曖昧なままのリスク

• 再開判断が遅れる：安全側に倒して「全部戻るまで待つ」判断になりやすい
• 復旧作業が渋滞する：重要度の低い機能まで同列に復旧対象となり、資源が分散する
• ステークホルダー説明が難しい：いつ、何が、どこまで戻るかを合意形成できない

RLO設定がもたらすメリット

• 復旧の段取りが明確になる：優先機能・段階復旧が前提となり、手順が設計しやすい
• 投資判断がしやすい：どの水準を守るために何が必要か（冗長化/代替/訓練）が整理できる
• 説明責任を果たしやすい：顧客・取引先・社内に「復旧の見通し」を示しやすい

RLOの設定プロセス

業務影響度分析で重要業務を特定する

RLOの前提は、重要業務と許容できない影響を言語化することです。業務影響度分析（BIA）により、停止による財務影響、顧客影響、法令・規制、代替可否、他業務への波及を整理し、優先順位を確定します。

RTOとRPOを先に仮置きする

RLOは「RTOの時間枠の中で、どのレベルまで復旧するか」を決める考え方と相性が良いため、まずはRTOとRPOを業務単位で仮置きします。ここで重要なのは、現実に達成可能な前提（人員、拠点、ネットワーク、クラウド契約、バックアップ方式）を置いた上で、無理のない目標を設定することです。

復旧レベルを段階で定義する

次に、各業務・システムについて「段階復旧」のレベルを定義します。例えば、次のように“レベル”を用意しておくと、障害時の判断が速くなります。

• レベル1：最小限の受付・記録ができる（受注登録のみ、参照系のみなど）
• レベル2：主要処理が回る（請求・決済・出荷など、事業の核）
• レベル3：通常運用へ復帰（周辺機能・分析・連携の回復）

このとき、「レベル1をRTO内に達成する」「レベル3は72時間以内に戻す」など、時間（RTO）と水準（RLO）をセットで書き分けると実装に落ちやすくなります。

文書化と合意形成を行う

RLOはIT部門だけで決めると、業務側が期待する“再開”とズレることがあります。BCP/BCMS文書に明記し、業務部門・経営層・外部委託先（運用、SaaS、配送、決済など）と合意形成しておくことが重要です。外部依存がある場合は、契約SLAやサポート条件がRLO達成の前提になるため、前提条件も併記します。

RLOを達成するための対策

アーキテクチャと手順をRLOに合わせて設計する

RLOは“目標”なので、達成手段が必要です。例えば、レベル1を優先するなら、参照系や受付系を分離し、最小構成で立ち上がる設計（縮退運転）を取り入れます。逆に、全機能を一度に戻す設計は、復旧が遅れやすい傾向があります。

代替手段と手作業運用を定義する

RLOはシステムだけでなく業務の復旧レベルでもあるため、手作業・代替ルートも設計対象です。たとえば「注文は電話/フォームで受け付けて一時台帳に記録」「請求は後追いで確定」など、暫定運用の範囲と責任分界を決めておくと、再開が現実的になります。

外部委託やSaaS利用時の注意点

クラウド/SaaS/外部運用を使っている場合、RLOは自社だけでは完結しません。復旧時に必要な連絡経路、復旧優先度、切替手順、サポート窓口、認証基盤（IdP）の可用性など、依存関係を棚卸しし、RLO達成のボトルネックを先に潰しておくことが重要です。

RLOの運用と改善

訓練とテストで復旧レベルを検証する

RLOは、災害時に“はじめて”試すものではありません。机上訓練と実機テストを組み合わせ、レベル1/2/3に必要な手順が本当に動くかを検証します。特に、縮退運転の切替、権限管理、DNSや証明書、鍵の取り扱いなど、運用上の落とし穴が出やすい箇所は重点的に確認します。

達成状況を可視化し、見直しに反映する

訓練結果、障害対応の実績、外部ベンダーのSLA変更、業務プロセスの改定などをもとに、RLOを定期的に見直します。年1回などの定期見直しに加え、システム更改や大きな組織変更があったタイミングで再評価する運用が現実的です。

コストとのバランスを取りながら継続改善する

復旧水準を高く、早く戻すほど、冗長化・多重化・監視・訓練コストは増えます。一方で、RLOを低くしすぎると、再開はできても事業影響が大きくなる可能性があります。BIAの結果に立ち返り、「どの業務のどのレベルを守るか」を基準に、投資と運用負荷のバランスを取りながら改善サイクルを回すことが重要です。

まとめ

RLO（Recovery Level Objective）は、障害時に「どのレベルで」システムや業務を復旧し、操業・サービスを再開するかを定める指標です。RTO（時間）やRPO（データの復旧時点）とセットで考えることで、段階復旧や縮退運転の設計が現実的になり、再開判断も速くなります。BIAで重要業務を特定し、RTO/RPOを仮置きしたうえで、復旧レベルを段階で定義し、訓練と見直しで継続的に改善していきましょう。