RPO / RTOを経営層に説明する：IT部門が作るビジネス継続計画の1枚資料
結論: RPO・RTOは技術指標のままでは経営層に届きません。「1時間止まると自社はいくら損するか」という金額に置き換えた瞬間に、予算承認のための会話が始まります。この記事では、その翻訳作業と、経営層に渡す1枚資料の4ブロック構造を具体的に示します。
「RTO 24時間に設定しました」と報告したとき、役員室が静まり返った経験はないでしょうか。
悪い報告をしたわけではありません。数値は適切に算出されていたかもしれない。それでも、経営層は何も返せなかった。なぜかというと、「24時間」が何を意味するのか、彼らの言語に翻訳されていなかったからです。
RTO（Recovery Time Objective：目標復旧時間）とRPO（Recovery Point Objective：目標復旧時点）は、DR（Disaster Recovery：災害復旧）設計の中核をなす指標です。この2つを理解している情シス担当者が、なぜ役員会で詰まるのか。答えは単純で、技術指標と経営判断の言語は別物だからです。
この記事は、その翻訳を一度完成させることを目標にしています。
「RTO 24時間に設定しました」── なぜ役員はポカンとするのか
RPO・RTOを定義から確認します。
RPOは「どこまで遡ってデータを失っても許容できるか」の上限です。RPO 12時間であれば、12時間前の状態に戻ることを前提にシステムを設計します。日次バックアップが走っている環境では、最悪の場合24時間分のデータが失われる可能性があります。
RTOは「障害発生から業務再開まで、最長何時間かかってよいか」の上限です。RTO 24時間と設定した場合、翌日中に復旧できれば許容範囲とみなします。
技術担当者からすれば、これは明確な合意事項です。しかし役員が聞いた瞬間に頭に浮かぶ質問は、「それで何が起きるのか」ではなく「何円の問題なのか」です。
KENTEM社のブログが例示している数値があります（同社独自の試算であり、実測値ではありません）。業務停止1時間で100万円、12時間で1,200万円、24時間で3,000万円、72時間で1億円という水準です。
この数値が自社に当てはまるかどうかは別として、「RTO 24時間」は経営層の耳に「最悪3,000万円規模の損失リスクを許容する設計です」と聞こえる可能性があります。そう言い換えた瞬間に、役員室の空気は変わります。
まず「1時間止まると、いくらの損か」を計算する
経営層向けの説明資料を作る前に、自社の数字を持つことが必要です。ここを飛ばして資料を作っても、最初の質問で止まります。
ダウンタイムコストの基本式
ダウンタイムの損失を大まかに見積もる際、次の要素を積み上げます。
- 機会損失: 時間あたり売上 × 停止時間 × 影響範囲（全体 or 一部）
- 従業員コスト: 関係する人数 × 平均時給 × 停止時間（何もできない状態の人件費）
- 復旧作業コスト: 対応に動く技術者・管理者の工数
- 信用コスト: 顧客離れ・問い合わせ対応・ブランドへの影響（定量化しにくいが存在する）
企業規模や業種によって数値は大きく変わります。Erwood Group（2025年）がまとめた調査では、小売・サービス業の中小企業で1時間あたり5万〜10万ドル、製造業の大企業では230万ドル以上という事例が報告されています。いずれも海外・大企業の数値であり、日本の中小企業にそのまま適用はできませんが、「業種と規模で桁が変わる」という感覚を掴む参考にはなります。
自社試算は粗くてよいです。重要なのは、「私たちは経営判断に必要な数字を把握している」という姿勢を見せることです。
業種別の感度差
TrustCloudがまとめた業種別の目安では、医療・金融系は数分〜十数分単位、製造・小売では数時間単位のRTO/RPO設定が広く採用されている（出典：TrustCloud）。
CTTメディアがまとめているティア分類も参考になります。
- ティア1（最重要）: RPO 0〜15分 / RTO 15分〜1時間。金融・医療・EC基幹系が該当。
- ティア2（重要）: RPO 1〜4時間 / RTO 2〜4時間。
- ティア3（準重要）: RPO 4〜12時間 / RTO 8〜24時間。
- ティア4（標準）: RPO 12〜24時間 / RTO 24〜72時間。
自社の主要システムがどのティアに収まるかを分類しておくと、経営層に「何を守るための投資か」が伝わりやすくなります。
「今のバックアップ体制、RPOは何時間ですか」── 現状診断フロー
資料を作る前に、現状を正確に把握する必要があります。意外と答えられない担当者が多い問いです。
現状のRPOを確認するフローを示します。
- バックアップの最終取得タイミングを確認する。「毎日深夜2時にフルバックアップ」なら、最悪の場合は約24時間分のデータが失われうる。つまりRPO = 24時間。
- バックアップの保存場所を確認する。同一サーバーに保存している場合、サーバー本体が壊れた時点でバックアップも消える。これはRPOの問題ではなく設計上の欠陥です。
- バックアップからの復旧を試したことがあるか確認する。ここで止まる担当者は少なくありません。
フェイルオーバーテスト（実際に切り替えを行う訓練）を定期的に実施していない組織は少なくなく、実際の障害時に計画通り動かないケースが報告されている。CTTメディアも「テストなしでは復旧2時間のつもりが実際には6時間以上かかるケースが珍しくない」と指摘しています。
「RTOを2時間と設定した」と言えても、「2時間で復旧できることを確認した」と言えなければ、それは目標値であって達成保証ではありません。
経営層に渡す1枚資料の構造
技術情報を経営判断の言語に変換するための4ブロック構造を示します。スライドのデザインではなく、論理の骨格です。
ブロック1: 現状リスク
「現在の構成では、障害発生時に最大〇時間のシステム停止・〇時間分のデータ消失が発生しうる」という事実を、数値で示します。ここは主観を入れず、ファクトだけです。
ブロック2: 損失試算
ブロック1の「最大〇時間」に、先ほど算出した「1時間あたりのダウンタイムコスト」を掛けます。「この構成を続けた場合、最悪シナリオで〇〇万円規模の損失が発生しうる」という形で示します。
試算は粗くても問題ありません。経営層が求めるのは精度ではなく、判断の根拠になるオーダー感です。
ブロック3: 現状とのギャップ
「業界標準のティア2に合わせるとすれば、RTOは〇時間、RPOは〇時間が目安です。現状はその〇倍の水準にあります」という比較です。ここで初めて「なぜ投資が必要か」が伝わります。
ブロック4: 改善オプション
3つ程度の選択肢を、コスト・効果・期間のセットで示します。詳細は次のセクションで触れます。重要なのは、「1つの正解」を押し付けず、経営層が選択できる形に整えることです。
DR構成の現実的なコスト感（コールドからホットまで）
率直に言います。DR対策はコストが指数的に増大します。RTOを半分にするためには、コストが2倍では済まないケースが大半です。この前提を先に伝えておかないと、後で「なぜこんなに高いのか」という話になります。
予算申請に使える3段階の価格地図です。
コールドバックアップ（最小構成）
障害発生後に手動でリストアする構成です。AWSの公式DR事例では、この構成（コールドバックアップのみ）でRPO 12時間・RTO 数時間程度の場合、月額19.50ドル（約3,000円、2026年6月時点）という試算例があります。
さくらのクラウドでの参考値としては、Futureメディアの記事（2026年5月時点）によれば、1コア/1GBで月額1,540円、4コア/8GBで月額9,240円です。小規模なWeb構成では約3,080円/月という水準です（実際の構成と料金は公式サイトでご確認ください）。
コールドバックアップは初期コストが最も低い反面、RTOが長くなります。「最低限バックアップがある」という状態です。
ウォームスタンバイ（中間構成）
縮小した構成を別環境に常時稼働させておき、障害時に本番規模にスケールアップする方法です。コールドより復旧は速く、コストはホットより低い。
コストはホットスタンバイより抑えられるが、本番環境に対して一定のリソース追加が必要になる（規模・構成により変動。要見積もり）。
ホットスタンバイ（完全冗長）
本番と同等の環境を常時別系統で稼働させ、障害発生とほぼ同時に切り替える構成です。RTOは分単位・秒単位に短縮できます。
コストは本番環境のほぼ2倍です。中小企業にとっては通常オーバースペックですが、金融系・医療系の一部システムでは現実的な選択肢になります。
やってしまいがちな3つの失敗
DR設計で繰り返し出てくるパターンを先に示します。
1. 全システムに同じRPO・RTOを設定する
受発注システムと社内掲示板を同じティアで管理する必要はありません。優先度の高いシステムに集中投資し、低いシステムは最低限の対応にとどめる方が、コスト効率が高くなります。
2. 経営層の承認なしにRPO・RTOを決める
RPO・RTOは技術的な設定値ではなく、経営判断です。「最大1日分のデータが失われうる」という判断は、情シス部門が単独で行えるものではありません。承認なしで設定した場合、インシデント発生時に責任の所在が曖昧になります。
3. 設定したRTO・RPOをテストしない
テストなしのDR計画は、作った段階では「仮説」のままです。実際に切り替えてみると、想定外の依存関係や設定漏れが出てきます。フェイルオーバーテストを定期的に実施していない組織は少なくなく、実際の障害時に計画通り動かないケースが報告されている。
DR設計の相談を社内で動かすための次の一手
「DR対策が必要なのはわかった。では社内でどう動かすか」という段階で止まるケースがあります。
外部のDR設計支援・BCP策定支援の費用感を参考として示します。Jackery社がまとめた情報によれば、中小企業診断士・個人コンサルタントで30万〜80万円程度、大手コンサルファームで100万〜200万円程度が目安です。従業員150名規模の製造業では80万〜150万円程度という例も示されています（IT/DR特化の単体価格は公開情報として未確認のため、個別見積もりが必要です）。
自社でDR設計を進める場合、まず「現状のバックアップ構成とRTO・RPO試算値を整理した資料」を作ることから始めるのが現実的です。この資料があれば、予算申請にも外部への相談にも使えます。
経営層に承認を取り付けるためにも、補助金の活用を検討する価値があります。IT導入補助金・事業継続力強化計画（経産省）などがDR関連投資の対象になりうるため、導入前に確認しておくとよいでしょう。
まずは「現状の構成でRPOとRTOが何時間になるか」を数値として押さえることが、最初の一手です。ここが曖昧なまま経営層に相談しても、承認には至りません。
DR設計・RPO/RTO設定の支援を行っています
RPO・RTOの試算から経営層向け資料の構造化、クラウドDR構成の設計まで、InfraDBでは個別相談を受け付けています。
「現状把握から始めたい」「経営層向けの説明資料を一緒に整理したい」という段階からでも対応可能です。