ITシステムの死活監視を外部に委託したり、運用保守の契約に組み込んだりするとき、避けて通れないのがRFP（提案依頼書）と要件定義です。「死活監視をお願いします」とだけ伝えても、監視の対象・間隔・閾値・通知先・SLA（稼働率や復旧時間の約束）が曖昧なままでは、ベンダーごとに前提がバラバラの見積もりが返ってきて比較できません。さらに、対応範囲が曖昧なまま契約すると、いざ障害が起きたときに「それは契約範囲外です」「追加費用になります」というトラブルに直結します。
本記事は、ITシステム死活監視のRFP・要件定義書・提案依頼書を、発注企業（情シス）の視点から「要件定義特化」で整理する解説です。監視対象と項目をどう定義するか、SLAの数値要件をどう書くか、クラウドの責任共有モデルをどう前提に織り込むか、そして隠れコストを潰す対応範囲の定義の仕方まで、具体的な要件の書き方を掘り下げます。安すぎる見積もりに惑わされず、適正な提案を引き出すためのRFP設計図として使える内容です。死活監視の費用相場やSLAの全体像をまだ把握していない方は、まずITシステム死活監視の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム死活監視の完全ガイド
監視対象と監視項目を定義する要件
RFPの出発点は、「何を・どこまで・どの粒度で監視してほしいか」を明確に定義することです。ここが曖昧だと、ベンダーは自社に都合のよい範囲で見積もるため、提案を横並びで比較できなくなります。監視対象の一覧と、それぞれに対する監視項目・間隔・閾値を、発注者側があらかじめ整理しておくことが、適正な提案を引き出す前提になります。
監視対象一覧と優先度を明記する
まず、監視対象となるサーバー・サービス・ネットワーク機器を一覧化します。Webサーバー、アプリケーションサーバー、データベース、外形監視するURL、といった単位で列挙し、それぞれの台数や構成を明記します。あわせて、各対象の「事業上の重要度（優先度）」を付けておくことが重要です。止まると即売上に響く受注系は最優先、社内向けの参照系は中優先、といった区分です。
優先度を明記する理由は、それがそのまま監視間隔やSLAの強弱、ひいては費用に直結するからです。すべてを最優先・即応で監視すれば費用は跳ね上がりますし、逆に全部を低優先にすれば重要システムの停止に気づけません。リサーチでも、稼働率の「9」が1つ増えるごとに運用コストは段階的に跳ね上がるとされており、対象ごとに優先度を付けて監視水準にメリハリをつけることが、コストの最適化に直結します。RFPの冒頭で、この監視対象一覧と優先度を発注者の意思として示しておきましょう。
監視項目・間隔・閾値の数値要件を書く
対象ごとに、どの監視項目を・どの間隔で・どの閾値で見るかを数値で定義します。死活監視であれば、ping応答、指定ポートの応答、HTTPステータス200の確認、といった項目を挙げ、監視間隔（例：1分間隔）と、何回連続で異常なら停止と判定するか（例：3回連続）を明記します。この数値があるかないかで、提案の精度と比較可能性が大きく変わります。
ここで注意したいのが、死活監視と性能監視・ログ監視の線引きです。RFPでは「死活（生死の判定）」を主としつつ、CPUやメモリ使用率といったリソースの閾値監視を含めるのか、ログの異常検知まで求めるのかを切り分けて書きます。範囲を曖昧にすると、安いベンダーは死活だけ、高いベンダーはすべて込み、という形でまた比較不能になります。発注者が「死活はここまで、性能監視は別オプション」と線引きして示すことで、各社が同じ土俵で見積もれるようになり、安すぎる見積もりが何を省いているかも見抜けるようになります。
SLAの数値要件を定義する
RFPで最も曖昧になりやすく、かつ費用と法的リスクを左右するのがSLA（サービスレベル合意）です。稼働率、初報の応答時間、復旧目標時間という3つの数値を、対象の優先度に応じて定義することが、死活監視の要件定義の核心になります。ここを甘く書くと、停止時に「努力目標だったので責任は負えません」となりかねません。
稼働率と許容ダウンタイムを対象別に定める
稼働率は、許容できるダウンタイムから逆算して定義します。稼働率99.9%は年間8.76時間・月43.8分・日7.3分の停止を許容し、99.99%は年52.6分・月4.38分・日4.4秒まで、という具体的な数値があります。「9」が1つ増えるごとに必要な監視・即応体制が重くなり、運用コストは段階的に跳ね上がります。だからこそ、対象の事業影響度に応じて稼働率を割り当てることが要件定義の肝です。
RFPには、「受注系サーバーは99.99%、社内参照系は99.9%」というように対象別の稼働率目標を明記します。あわせて、この稼働率がどの期間（月次・年次）で測定され、計画停止（メンテナンス）を分母から除外するのかも定義します。測定方法が曖昧だと、達成・未達の判断でもめます。発注者が稼働率の定義と測定方法まで踏み込んで書くことで、過剰な水準を避けつつ、必要な水準は確実に約束させることができます。
初報応答時間と復旧目標時間を明記する
稼働率と並んで重要なのが、停止を検知してから「いつまでに連絡し、いつまでに直すか」という応答・復旧の数値要件です。リサーチの官公庁仕様例では、「1時間以内に現地到着・対処開始」「1時間以内に内容と予想作業時間を報告」「原則4時間以内に完全復旧」といった目標が示されています。また、Cloud Naviは重大インシデントに15分以内の一次対応を保証し、別のサービスは検知から60分以内に通知・12時間で復旧、といった例があります。
RFPには、これらを参考に「重大障害は検知後15分以内に一次連絡、2時間以内に対応開始、24時間以内に完全復旧」というように、重大度別の応答・復旧時間を明記します。そして決定的に重要なのが、これらが「保証型（未達時にサービスクレジットなどのペナルティがある）」なのか「努力目標型（最善を尽くすが責任は負わない）」なのかを問う項目を入れることです。安すぎる見積もりは、たいていSLAが努力目標型か、そもそもSLA自体がありません。応答・復旧の数値とその保証区分をRFPで問うことが、見積もりの質を見抜く決め手になります。
クラウド責任共有を前提にした要件
現在のシステムはクラウド基盤で動くものが多く、死活監視のRFPでも責任共有モデルを前提にした要件定義が欠かせません。国内エンタープライズ・システム市場のクラウド比率は2022年時点で約5割（IDC Japan）とされ、もはや前提条件です。クラウドでは「どこまでがクラウド事業者の責任で、どこからが利用者・運用ベンダーの責任か」が分かれており、ここを要件で整理しないと監視の穴が生まれます。
監視の責任範囲をクラウド層ごとに切り分ける
クラウド環境では、物理基盤やネットワークはクラウド事業者が監視・維持しますが、その上で動くOS・ミドルウェア・アプリケーションの死活は利用者側の責任になることが一般的です。RFPでは、「どの層を監視ベンダーが見るのか」を明確に定義します。クラウド基盤そのものの障害は利用者側で手出しできず、サービスクレジット以上の補償は基本的に受けられないため、利用者が監視・自衛すべきはアプリケーション層やサービス応答の死活だと整理しておく必要があります。
この切り分けを怠ると、「クラウドが落ちたのにベンダーは何もしてくれなかった」「アプリのエラーをクラウドのせいにされた」といった責任の押し付け合いが起こります。RFPには、クラウド事業者・運用ベンダー・自社の三者の監視責任を表で示し、特に「クラウド基盤障害が起きたとき、ベンダーは何を検知し、どう連絡し、どんな代替策を取るのか」を問う項目を入れます。クラウドの監視はブラックボックスになりがちなので、要件で可視化することが自衛の第一歩です。
監視ツールの選定基準を要件に含める
RFPでは、どの監視ツールを使うかの選定基準も要件として示すか、ベンダーに提案させます。OSSのZabbixはライセンス無料ですが、自社環境に構築・維持する工数が発生します。クラウド型のDatadog・New Relic・Mackerelは、ホスト数やメトリクス量に応じた従量課金で、中規模だと月数万〜数十万円が目安です。どちらが適するかは、監視対象の数や将来の拡張性、社内の運用力によって変わります。
要件定義の段階で「ツールのライセンス費は誰が負担するのか」「ツールが従量課金の場合、対象が増えたときの費用はどう変動するのか」を明確にしておくことが、後の費用トラブルを防ぎます。ツールの選定をベンダー任せにすると、契約後に「監視対象を増やすたびにツール費用が上がる」という隠れコストが顕在化することがあります。RFPでツールの選定基準と費用負担・変動条件まで問うことで、総額での比較が可能になります。
隠れコストを潰す対応範囲の定義
死活監視のRFPで最後に詰めるべきは、「監視で異常を検知した後、どこまで対応してくれるのか」という対応範囲の定義です。ここが曖昧だと、基本料金に含まれると思っていた対応が追加費用になり、見積もりが安く見えても実際の支払いは膨らむ、という事態が起こります。隠れコストを潰すには、対応範囲を工程ごとに線引きすることが不可欠です。
基本料金に含む範囲と追加費用の線引き
RFPには、検知・一次連絡・一次切り分け・原因調査・復旧作業・恒久対策、という工程ごとに「どこまでが月額の基本料金に含まれ、どこからが追加費用か」を問う項目を設けます。リサーチでは、運用・監視（24/365の死活・リソース監視）が月5万〜20万円、障害対応は営業時間内で月3万〜8万円、24時間緊急対応で月10万〜20万円、スポット対応1件3万〜10万円、といった相場があります。これらが基本料金に込みなのか別建てなのかで、総額は大きく変わります。
たとえば「死活監視と一次連絡までは月額に含むが、原因調査と復旧作業は1件ごとのスポット費用」という契約は珍しくありません。これ自体は妥当ですが、それを知らずに「監視を頼めば直してくれる」と思い込むと、障害のたびに想定外の請求が来ます。RFPで工程別に範囲と単価を問い、月の障害が一定回数を超えた場合の費用の上限や見込みも確認しておくことで、年間の総コストを現実的に見積もれます。安すぎる見積もりは、たいていこの対応範囲が極端に狭いことを、線引きの質問で見抜けます。
契約形態と契約上のリスク条項を要件に入れる
対応範囲と並んで、契約形態の選択もRFPで示すべき要件です。月額固定型は待機費を含むため安定して即応してもらえる一方、障害が少ない月は割高に感じられます。実働・従量課金型は稼働量に波がある中小企業に向きますが、繁忙時に費用が読みにくくなります。RFPでは自社の停止傾向を踏まえ、どちらの契約形態を希望するか、あるいは両方の提案を求めるかを示します。
さらに、契約上のリスク条項として、SLA未達時のサービスクレジット（料金減額）、損害賠償の上限、間接損害（機会損失など）の免責の有無を問う項目を入れます。多くの契約では賠償は支払い済み料金の範囲に上限が設けられ、間接損害は免責とされます。ダウンタイムの損失は、総務省の例で5分以上の停止1回あたり平均1,200万円、Gartnerで1分あたり5,600米ドルとされますが、こうした機会損失は通常ベンダーから補償されません。だからこそ、補償に過度に依存せず、自社のBCP（事業継続計画）と組み合わせて備える前提でRFPを設計することが、発注者の賢明な姿勢です。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした要件整理から契約設計までを伴走します。
まとめ
ITシステム死活監視のRFP・要件定義は、(1)監視対象一覧と優先度・監視項目/間隔/閾値の定義、(2)対象別の稼働率・初報応答・復旧時間というSLAの数値要件とその保証区分、(3)クラウド責任共有を前提にした監視責任の切り分けとツール選定基準、(4)工程別の対応範囲と契約形態・リスク条項、という4点を押さえることで、比較可能で穴のない提案を引き出せます。発注者が数値で要件を示すほど、各社は同じ土俵で見積もり、安すぎる見積もりが何を省いているかも見抜けます。
要件定義で大切なのは、すべてを最高水準で求めることではなく、事業影響度に応じて監視とSLAにメリハリをつけ、対応範囲とリスク条項を明文化することです。ダウンタイム損失や機会損失は基本的にベンダーから補償されないため、SLAとBCPを組み合わせて備える前提でRFPを設計しましょう。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、死活監視の要件整理から契約設計、運用までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。