ITシステムの障害復旧をベンダーに委託しようとするとき、多くの情報システム担当者がつまずくのが「RFP（提案依頼書）や要件定義書に、障害復旧について何をどう書けばいいのか」という点です。監視項目や復旧時間、SLA（サービスレベル合意）の数値を曖昧にしたまま発注すると、いざ障害が起きたときに「それは契約範囲外です」と言われ、復旧が止まる事態を招きます。逆に、要件を過剰に盛り込めば見積もりが跳ね上がります。だからこそ、障害復旧のRFP・要件定義書には、必要な数値要件を過不足なく書き込む技術が求められます。
本記事は、ITシステム障害復旧のRFP・要件定義書・提案依頼書に盛り込むべき要件を、発注企業（情シス）の視点から具体的に整理する「要件定義特化」の解説です。監視項目と閾値の定義、稼働率・初報応答・復旧時間といったSLAの数値要件、クラウドの責任共有モデルを前提とした範囲定義、そして安すぎる見積もりに潜む隠れコストを潰す対応範囲の書き方まで、一次データとあわせて具体的に解説します。なお、ITシステム障害復旧の全体像をまだ把握していない方は、まずITシステム障害復旧の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム障害復旧の完全ガイド
監視項目と閾値を定義する要件
障害復旧の要件定義は、まず「何を監視するか」を明確にすることから始まります。監視対象と閾値が曖昧なままだと、復旧の前提となる検知そのものが穴だらけになります。ここでは、RFPに書き込むべき監視項目と閾値の要件を整理します。
監視対象と監視項目を漏れなく列挙する要件
要件定義書には、監視対象を具体的に列挙します。サーバー、ネットワーク機器、データベース、アプリケーション、外形監視（ユーザーから見たサービスの応答）といった層ごとに、何を監視するかを明記します。各対象について、死活監視・リソース監視（CPU・メモリ・ディスク）・プロセス監視・ログ監視のうち、どれを行うかを書き分けます。ここを「サーバーを監視すること」とだけ書くと、ベンダーごとに解釈が異なり、提案の比較もできません。
監視項目を漏れなく列挙するコツは、「障害が起きたとき、どの指標を見れば気づけたか」を過去の障害から逆算することです。過去にディスク満杯でサービスが止まった経験があれば、ディスク使用率の監視は必須要件になります。一次データでは、運用・監視の費用は月額5万〜20万円が相場とされますが、監視対象と項目が増えれば費用も上がります。すべてを最高頻度で監視するのではなく、重要なシステムは手厚く、影響の小さいものは最低限に、とメリハリをつけた要件にすることが、過剰な見積もりを避ける鍵です。
閾値と通知ルールを数値で定義する要件
監視対象を決めたら、各項目の閾値を数値で定義します。「CPU使用率が90%を5分間継続したら警告、95%を超えたら障害として通知」といった形で、具体的な数値と継続時間を書き込みます。この閾値が、検知の精度を決めます。閾値が曖昧だと、ベンダー任せの設定になり、アラートが鳴りすぎたり、逆に重大な障害を見逃したりします。要件定義の段階で、自社の運用実態に合った閾値の考え方を示しておくことが重要です。
あわせて通知ルールも要件化します。検知した異常を、どの重大度のときに・誰に・どの経路（メール・チャット・電話）で・何分以内に通知するかを定義します。重大障害は電話で即時、軽微なものは翌営業日のレポートで、といった出し分けを明記すれば、復旧の初動が設計通りに動きます。監視ツールとしてZabbix（OSS）やDatadog・Mackerelなどが候補になりますが、RFPでは特定ツールを指定するより、満たすべき監視要件と閾値を示し、最適なツール構成をベンダーに提案させるほうが、良い提案を引き出せます。
SLAの数値要件を明記する書き方
障害復旧の要件定義で、もっとも費用と品質に直結するのがSLAの数値要件です。稼働率、初報応答時間、復旧時間といった数値を、根拠とともに明記する必要があります。ここでは、SLAをどう設計し、RFPにどう書くかを整理します。
稼働率を事業影響度から逆算して定義する要件
稼働率は、SLAの中心的な数値です。ただし、要件定義で陥りがちなのが「とにかく高い稼働率を求める」ことです。一次データを見ると、稼働率99.9%は年間許容ダウンタイム8.76時間・月43.8分であるのに対し、99.99%は年52.6分・月4.38分と桁違いに短く、「9」が一つ増えるごとに運用コストが段階的に跳ね上がります。すべてのシステムに99.99%を求めれば、費用は青天井になります。
正しい書き方は、システムごとに事業影響度から稼働率を逆算することです。止まれば売上が直撃するECや基幹系は高い稼働率を、停止しても代替手段で業務が回る社内系は控えめな稼働率を設定します。総務省2025年版の統計では、金融・医療・EC系で5分以上の停止1回あたり平均1,200万円の機会損失とされ、この損失額と稼働率向上のコストを天秤にかければ、各システムに必要な稼働率が論理的に導けます。要件定義書には、稼働率の数値とともに、その根拠となる事業影響度を併記しておくと、ベンダーも提案しやすく、社内の合意形成にも役立ちます。
初報応答時間と復旧時間を保証型で書く要件
稼働率と並んで重要なのが、初報応答時間と復旧時間です。初報応答時間とは「障害発生から、ベンダーが第一報を返すまでの時間」、復旧時間とは「障害発生から、サービスが復旧するまでの目標時間」です。一次データには参考になる実例があります。官公庁仕様では「1時間以内に現地到着・対処開始」「1時間以内に内容と予想作業時間を報告」「原則4時間以内に完全復旧」、Cloud Naviでは「重大issue 15分以内の一次対応保証」、シーズホスティングでは「検知から60分以内通知・12時間で復旧」といった水準です。
要件定義で押さえるべきは、これらの時間が「努力目標」なのか「保証」なのかを明確にすることです。努力目標型は「できる限り早く対応します」という表現にとどまり、未達でもペナルティがありません。保証型は、未達時にサービスクレジット（利用料の返金）などのペナルティを伴います。重要なシステムほど、保証型のSLAをRFPで求めるべきです。あわせて、未達時の補償内容（サービスクレジットの上限、損害賠償の範囲）も要件として書き込み、いざというときに復旧の責任の所在が曖昧にならないようにしておきます。
クラウド責任共有を前提にした範囲要件
クラウド上でシステムを動かすことが当たり前になった今、障害復旧の要件定義ではクラウドの責任共有モデルを前提に範囲を切り分ける必要があります。クラウド比率は2022年で約5割（IDC Japan）に達し、基盤側の障害は自社では復旧できません。ここでは、責任範囲を要件としてどう定義するかを整理します。
クラウド事業者・ベンダー・自社の責任分界を定義する要件
クラウドを使う場合、障害復旧の責任は三者に分かれます。クラウド事業者（基盤の可用性）、運用ベンダー（基盤上で動かすシステムの監視・復旧）、自社（最終的な事業判断とBCP）です。要件定義書では、この三者の責任分界点を明確にします。たとえば「基盤障害はクラウド事業者の責任だが、その障害を検知し、代替リージョンへ切り替える作業は運用ベンダーの範囲」といった形で、誰が何をするかを書き分けます。
この切り分けが曖昧だと、基盤障害が起きたときに「それはクラウド側の問題なので当社は関与しません」とベンダーに言われ、自社だけが取り残されかねません。要件定義では、クラウド基盤障害が発生した際のベンダーの役割（状況把握、自社への報告、代替手段への切り替え支援など）まで含めて範囲を定義しておくことが、復旧の空白を防ぎます。クラウドの障害ではサービスクレジット以上の補償が受けられないことが多いため、自衛のためのアーキテクチャ要件（冗長化やバックアップの取得先分散）も、要件定義の段階で検討しておくべきです。
バックアップ・冗長化の復旧目標を数値で定義する要件
クラウド環境での障害復旧要件では、バックアップと冗長化の目標を数値で定義します。具体的には、RPO（目標復旧時点＝どの時点のデータまで戻せるか）とRTO（目標復旧時間＝どれだけ速く復旧するか）の二つです。たとえば「RPO 1時間（最大1時間分のデータ損失まで許容）」「RTO 4時間（4時間以内に復旧）」のように書きます。この二つの数値が、バックアップの取得頻度や冗長構成の設計を決定づけます。
RPOを短くするほど高頻度のバックアップが必要になり、RTOを短くするほど冗長化やホットスタンバイ構成が求められ、いずれも費用が増えます。だからこそ、これも事業影響度から逆算します。データ損失が許されない決済系はRPOをほぼゼロに、多少の損失と復旧時間が許容できる社内系は緩めに、とメリハリをつけます。要件定義書にRPO・RTOを数値で明記しておけば、ベンダーは必要な構成を正確に提案でき、見積もりの根拠も明快になります。逆にこれを書かないと、ベンダーは安全側に倒した過剰な構成か、逆に不十分な構成を提案し、後でトラブルの種になります。
隠れコストを潰す対応範囲の定義
要件定義の最後の関門が、対応範囲の明確化による隠れコスト対策です。安い見積もりに飛びついた結果、いざ障害が起きたら「それは範囲外で追加費用です」と言われ、想定外の出費がかさむ。この落とし穴を防ぐのが、対応範囲を精密に定義する要件です。ここでは、隠れコストを潰す書き方を整理します。
基本料金に含む範囲と追加費用の線引きを定義する要件
もっとも重要なのが、「基本料金に何が含まれ、どこからが追加費用か」を要件として明文化することです。障害対応には、検知・一次対応・切り分け・原因調査・恒久対策・報告書作成といった工程がありますが、安価なサービスでは一次対応の暫定復旧だけが含まれ、原因調査や恒久対策が別料金、というケースがあります。要件定義書では、これらの工程のうちどこまでを基本料金に含めるかを、具体的に列挙して求めます。
一次データでは、障害対応の費用はスポット対応で1件3万〜10万円が目安とされ、対応範囲外の作業が積み重なると、当初の月額を大きく超える出費になりかねません。あわせて、月間の対応回数や作業時間に上限があるかも確認すべき要件です。「月◯時間まで」「月◯件まで」といった上限が設定されていれば、それを超えた分が追加費用になります。要件定義の段階で、自社の障害発生頻度を踏まえた現実的な範囲と上限を求めておくことが、後の予算超過を防ぎます。
ベンダー切り替えを見据えた引き継ぎ要件
見落とされがちですが、将来のベンダー切り替えを見据えた引き継ぎ要件も、RFPに盛り込んでおくべきです。運用を委託すると、自社システムの構成や運用ノウハウがベンダー側に蓄積されます。いざ別のベンダーに切り替えようとしたとき、引き継ぎがスムーズに行われなければ、復旧体制に空白が生じます。要件定義書では、契約終了時のソースコード・設定情報・運用手順書・監視設定・アカウント情報の引き渡しを明記しておきます。
あわせて、解約予告期間や、引き継ぎにかかる工数の棚卸しについても触れておくと安心です。これらを契約段階で要件化していないと、ベンダーに依存しきった状態（ロックイン）に陥り、不満があっても切り替えられず、言い値の費用を払い続けることになりかねません。障害復旧の要件定義は、目先の監視や対応だけでなく、長期にわたって主導権を握り続けるための条件まで含めて設計することで、本当の意味で隠れコストを潰せます。riplaはフルスクラッチ受託の立場から、こうした引き継ぎ性まで含めた要件整理を重視しています。
まとめ
ITシステム障害復旧のRFP・要件定義書では、(1)監視対象と閾値を漏れなく数値で定義する、(2)稼働率・初報応答・復旧時間のSLAを事業影響度から逆算し保証型で書く、(3)クラウドの責任共有を前提に三者の責任分界とRPO・RTOを定義する、(4)基本料金の範囲と追加費用の線引き、引き継ぎ条件まで明文化する、という四点が要点です。99.9%と99.99%の許容ダウンタイムの差や、停止1回あたり1,200万円という損失統計を根拠に、必要十分な数値要件を組み立てることが、過不足のない発注につながります。
要件定義で大切なのは、「とにかく手厚く」でも「とにかく安く」でもなく、自社の事業影響度から逆算して必要な水準を見極めることです。曖昧な要件は、安すぎる見積もりの隠れコストや、いざというときの責任の空白を招きます。riplaはフルスクラッチ受託と国内運用保守の知見から、監視・SLA・クラウド責任・対応範囲を自社の重要度に合わせて要件化し、作った後も伴走する支援を行っています。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。