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

UnsplashのTowfiqu barbhuiyaが撮影した写真

RLO（Recovery Level Objective）は、障害時に「どこまで戻せば再開とみなすか」を決める目標です。RTOが復旧に要する時間、RPOが許容できるデータ損失を表すのに対し、RLOは復旧後の提供レベルを決めます。たとえば「4時間以内に受注登録だけ再開する」「72時間以内に在庫連携まで戻す」といった形で、時間と水準を切り分けて定義します。これを決めていないと、障害時に「全部戻るまで再開しない」のか「最低限で再開する」のかがぶれ、判断と復旧作業が遅れやすくなります。

RLOとは何か

RLOの定義

RLOは、障害発生後の一定時間内に、どの機能・処理能力・品質水準まで戻せば業務やサービスを再開できるかを示す目標です。復旧の成否を「システムが起動したか」だけで見ず、「業務として成立するレベルまで戻ったか」で見るための基準として使います。

用語の使われ方に幅がある点

RLOは文脈によって、復旧後の提供レベルを指す場合と、どの粒度で復旧できるかを指す場合があります。前者は事業継続や段階復旧の判断で使いやすく、後者はデータやシステムをどの単位で戻せるかを見る場面で使われます。どちらの意味で使うかを先にそろえておかないと、関係者の会話がかみ合いません。組織内で使うときは、定義を文書で固定しておいた方が安全です。

RTO・RPOとの違い

RTOとRPOだけでは、「時間内に何ができれば再開とみなすか」が抜け落ちます。RLOを置くと、復旧の優先順位と到達点を明文化しやすくなります。

RLOが必要になる理由

完全復旧を前提にすると再開判断が遅れやすい

障害時に全機能の復旧を前提にすると、重要度の低い機能まで同列に扱うことになり、復旧作業が渋滞しやすくなります。RLOを決めておけば、「まず受注」「次に出荷」「最後に分析系」といった段階復旧へ切り分けられます。

説明責任を果たしやすくなる

顧客、取引先、社内の利用部門へ「いつ」「何が」「どこまで戻るか」を説明するには、時間目標だけでは足りません。RLOがあると、再開時の水準を事前に共有しやすくなります。

投資判断に使いやすい

どの水準まで守るかが決まると、そのために必要な冗長化、手作業の代替策、バックアップ方式、切替手順、訓練範囲が見えてきます。逆にRLOが曖昧なままだと、何に投資すべきかが定まりません。

RLOで決める項目

• 機能範囲：どの機能を先に戻し、どの機能を後回しにするか
• 処理能力：通常時の何％で再開できればよいか
• 品質水準：応答時間や処理遅延をどこまで許容するか
• 運用方式：一時的に手作業や代替手段へ切り替える範囲
• 対象範囲：全社一律ではなく、業務やシステムごとにどこまで戻すか

たとえば、ECなら「注文受付は再開、レコメンドは停止」、基幹業務なら「受注登録は再開、請求確定は手作業で代替」といった形で書けます。ここが曖昧だと、RTOを達成しても「再開と呼べるのか」が揺れます。

RLOの設定プロセス

1. 業務影響度分析で優先順位を決める

まず、どの業務が止まると売上、顧客対応、法令対応、外部連携へ大きな影響が出るかを整理します。BCPやBCMの文脈では、この優先順位付けがないままRLOを決めても機能しません。重要業務から順に、最低限必要な機能と後回しにできる機能を切り分けます。

2. RTOとRPOを仮置きする

RLOは、RTOとRPOの外側に置くと整理しやすくなります。何時間以内に、どこまでのデータを戻し、その時点でどのレベルまで業務を再開するかをセットで見る形です。人員、拠点、回線、バックアップ方式、クラウド契約など、現実の制約を踏まえて仮置きします。

3. 段階復旧のレベルを定義する

実務では、レベルを段階で切ると運用しやすくなります。

• レベル1：最小限の受付や記録だけ再開する
• レベル2：主要処理を再開し、事業継続に必要な流れを戻す
• レベル3：周辺機能や連携も含めて通常運用へ戻す

このとき、「レベル1は4時間以内」「レベル3は72時間以内」という形で、時間と水準を必ずセットで書きます。

4. 業務部門と合意する

IT部門だけで決めると、「システムは復旧したが、業務部門は再開できないと考えている」というずれが起きます。経営層、業務部門、外部委託先を含めて、どの状態を再開とみなすかを文書化します。

RLOを達成するための設計と運用

縮退運転を前提にする

RLOを早く達成したいなら、全機能を一度に戻す設計より、最小構成で再開できる設計の方が有利です。参照系と更新系を分ける、受付だけ先に立ち上げる、後続処理をバッチや手作業へ切り替える、といった縮退運転を用意しておくと、段階復旧へ移りやすくなります。

手作業の代替手順を決めておく

RLOはシステムだけの話ではありません。業務をどのレベルで再開するかという目標なので、一時台帳、電話受付、後追い入力などの手順も対象に含めます。誰が、どの帳票を使い、どこまでの件数を処理するかを決めておくと、障害時の混乱を抑えやすくなります。

外部依存を洗い出す

SaaS、決済代行、配送、認証基盤などへ依存していると、自社だけの復旧ではRLOを満たせない場合があります。連絡経路、契約SLA、切替条件、代替ルートを整理し、どこがボトルネックになるかを先に押さえておく必要があります。

RLOの運用と見直し

訓練で確認する

RLOは机上の目標だけでは閉じません。訓練やテストで、所定の時間内に所定のレベルまで戻せるかを確認します。特に、切替手順、権限、ネットワーク、DNS、証明書、鍵の取り扱いは実機検証をしておかないと、想定どおりに動かないことがあります。

変更のたびに見直す

システム更改、業務変更、委託先変更、組織変更が入ると、RLOの前提も変わります。年1回の定期見直しに加え、大きな変更が入った時点で再評価した方が実態に合います。

コストとのつり合いを見る

短時間で高い復旧レベルを求めるほど、冗長化、監視、訓練、運用の負荷は増えます。逆に低すぎるRLOでは、再開できても事業影響が大きく残ります。どの業務のどのレベルを守るのかを基準に、投資と運用負荷のつり合いを取ります。

まとめ

RLOは、障害時にどのレベルまで戻せば再開とみなすかを決める目標です。RTOが時間、RPOがデータ復旧時点を見るのに対し、RLOは復旧後の提供レベルを決めます。段階復旧や縮退運転を設計したい場面では、RTOとRPOだけでは足りません。業務影響度分析で優先順位を決め、時間と水準をセットで定義し、訓練で検証しながら更新していく形が現実的です。