ITシステムの保守監視を外部に委託するとき、見積もりの妥当性や対応範囲のズレで悩むことの多くは、RFP（提案依頼書）や要件定義書の作り込みが甘いことに起因します。「監視してくれると思っていた項目が対象外だった」「SLAの数値が曖昧で、いざ障害が起きたときに責任の所在が揉めた」といったトラブルは、要件を数値で定義しきれていないことから生まれます。逆に言えば、監視項目・閾値・SLAをきちんと数値で要件化できれば、ベンダーから比較可能な提案を引き出し、安すぎる見積もりの落とし穴も見抜けます。
本記事は、ITシステム保守監視のRFP・要件定義書・提案依頼書を、発注企業の視点で作り込むための「要件定義特化」の解説です。監視項目と閾値の数値要件、稼働率・初報応答・復旧時間といったSLAの数値要件、クラウドの責任共有モデルを前提にした要件、監視ツールの選定基準、そして隠れコストを潰すための対応範囲の定義まで、一次データとあわせて具体的に整理します。なお、費用相場や契約形態を含む全体像をまだ把握していない方は、まずITシステム保守監視の完全ガイドから読むことをおすすめします。読み終えるころには、ベンダーに渡すRFPの骨子を自力で組める状態を目指します。
▼全体ガイドの記事
・ITシステム保守監視の完全ガイド
監視項目と閾値の数値要件を定義する
RFPの土台になるのが、「何を・どの閾値で監視するか」という監視項目の数値要件です。ここを「サーバーを監視すること」といった曖昧な表現にとどめると、ベンダーごとに監視の粒度がばらつき、提案の比較ができなくなります。監視項目を具体的な指標と閾値で定義することが、後の対応範囲の明確化にもつながります。
監視項目リストと閾値の書き方
監視項目は、対象（サーバー・ネットワーク・アプリケーション・データベースなど）ごとに、監視する指標と閾値、監視間隔を一覧で定義します。たとえば「CPU使用率：警告80%・危険90%、5分間隔」「ディスク使用率：警告85%・危険95%」「HTTP応答：3秒以内、1分間隔」「プロセス死活：30秒間隔」といった形です。死活監視・性能監視・ログ監視・サーバー監視のそれぞれについて、この粒度で要件を書き出すと、ベンダーは何を実装すればよいかを正確に把握でき、見積もりの精度が上がります。
閾値を定めるときは、「アラートが上がったら誰が・いつまでに・どう動くか」をセットで考えることが重要です。閾値を低く設定しすぎると、些細な変動でアラートが頻発する「アラート過多」を招き、本当に重要な予兆が埋もれます。逆に高すぎると、障害が顕在化してからしか気づけません。RFPの段階で「警告レベルは記録のみ、危険レベルは即時通知と一次対応」といった対応レベルと閾値を紐づけて定義しておくと、ベンダーから運用の前提を踏まえた提案が出てきます。
通知・エスカレーションのフローを要件化する
監視項目と閾値を決めたら、検知したアラートを「誰に・どの手段で・どの順番で」通知するかのフローも要件に含めます。一次受けはベンダーの監視オペレーター、重大障害は自社の情シス責任者へ電話、業務影響が大きい場合は経営層と業務部門へも報告、といった連絡経路を明文化します。このエスカレーションの設計が曖昧だと、障害発生時に「誰が判断するのか」で時間を浪費し、復旧が遅れます。
特に発注者（情シス）側は、ベンダーへ丸投げにせず、自社内のエスカレーションも要件として整理しておくべきです。重大障害時に経営層や業務部門へどう状況を報告するか、BCP（事業継続計画）とどう連動させるかを、RFPの段階で社内の運用ルールとして固めておくと、いざというときの初動が安定します。ベンダーが担う範囲と自社が担う範囲の境界を明確にすることが、要件定義の質を決めます。
SLAの数値要件（稼働率・初報応答・復旧時間）
RFPでもっとも費用を左右するのが、SLA（サービスレベル合意）の数値要件です。稼働率・初報の応答時間・復旧目標時間をどの水準で求めるかが、そのまま運用体制とコストに直結します。SLAは高ければ高いほど良いわけではなく、自社の事業実態に見合った水準を数値で定義することが、過剰な費用を避ける鍵になります。
稼働率の数値が許容ダウンタイムに直結する
稼働率の要件は、許容できるダウンタイムから逆算して決めます。稼働率99.9%なら、許容ダウンタイムは年間8.76時間・月43.8分・日7.3分です。これを99.99%にすると、年52.6分・月4.38分・日4.4秒まで縮まります。「9」が一つ増えるだけで、許される停止時間は約10分の1になり、その分だけ冗長構成や即応体制が必要になって運用コストが段階的に跳ね上がります。RFPでは、自社のシステムが「年間で何分までの停止なら事業に支障がないか」を業務部門と合意したうえで、稼働率を数値で指定します。
この数値を決める根拠として、ダウンタイムの損失額を添えると説得力が増します。総務省の2025年版の統計では、金融・医療・EC系で5分以上の停止1回あたり平均1,200万円の機会損失とされ、Gartnerの2024年の指標ではダウンタイム1分あたり約5,600米ドルの損失とされています。停止が事業にどれだけの金額インパクトを与えるかを示せば、「この稼働率が必要だ」あるいは「ここまでの稼働率は不要だ」という判断を、根拠を持ってRFPに書き込めます。
初報応答・復旧目標時間とペナルティの要件
稼働率と並んで重要なのが、障害発生時の応答と復旧の時間要件です。具体的には、「障害を検知してから何分以内に第一報を入れるか（初報応答）」と「何時間以内に復旧させるか（復旧目標時間）」を数値で定めます。実例として、重大インシデントに15分以内の一次対応を保証するサービスや、検知から60分以内に通知して12時間以内に復旧するサービスがあります。官公庁の仕様では、1時間以内に内容と予想作業時間を報告し、原則4時間以内に完全復旧、といった水準が示されることもあります。
SLAを要件化するときは、未達だった場合の扱いも定義しておくことが望ましいです。サービスクレジット（料金の一部返金）の有無、損害賠償の上限、間接損害の免責条項などは、契約上・法的なリスク管理に直結します。一方で、ベンダーが「保証型」のSLAを提示できない場合、「努力目標型」にとどまることもあります。RFPでは「保証型を求めるのか、努力目標型でよいのか」を明示し、保証型を求めるなら未達時のペナルティ条項までセットで要件に含めると、責任の所在が明確になります。これにより、障害時の「言った・言わない」のトラブルを未然に防げます。
クラウド責任共有と監視ツールの選定要件
近年は多くのシステムがクラウド上で動いており、RFPでもクラウド特有の前提を要件に織り込む必要があります。国内エンタープライズ・システム市場のクラウド比率は、IDC Japanの調査で2022年時点で約5割に達しており、オンプレミス前提の要件定義のままでは実態に合いません。クラウドの責任共有モデルと、それを前提とした監視ツールの選定基準を要件に含めることが、抜け漏れのないRFPの条件になります。
責任共有モデルを前提に監視範囲を線引きする
クラウドの責任共有モデルでは、クラウド基盤そのもの（データセンター・物理サーバー・ネットワーク）はクラウド事業者の責任範囲で、その上で動くOS・ミドルウェア・アプリケーション・データは利用者の責任範囲になります。つまり、クラウド基盤の障害は利用者側では手出しができず、補償もサービスクレジットの範囲にとどまるのが一般的です。RFPでは、「どこまでが監視対象で、どこからがクラウド事業者の責任か」を明確に線引きし、利用者責任の範囲についてどう監視・対応するかを要件化します。
あわせて、クラウド基盤の障害に備えた自衛策も要件に検討します。マルチリージョン化や冗長構成を要件に含めるかどうかは、事業影響度とコストのバランスで決めます。クラウドだから安心と考えて監視を手薄にすると、「クラウド基盤の障害でサービスが止まったが、自社では検知すらできなかった」という事態を招きます。責任共有の前提を理解したうえで、利用者責任の範囲をしっかり監視し、基盤障害時にも被害を最小化するアーキテクチャを要件に盛り込むことが、クラウド時代のRFPでは欠かせません。
監視ツールの選定基準を要件に明記する
監視ツールをベンダー任せにせず、選定基準を要件に書いておくと、コスト構造の透明性が高まります。OSSのZabbixはライセンス無料で導入できますが、構築と維持に工数がかかるため、その工数を誰が負担するかを明確にする必要があります。一方、クラウド型のDatadogやNew Relicは、ホスト数やメトリクス量に応じた従量課金で、中規模なら月数万〜数十万円が目安です。サーバー監視に強いMackerelのような選択肢もあります。これらの特性を踏まえ、「ライセンス費は誰が持つか」「ツールの所有権はどちらか」を要件に含めます。
セキュリティ監視まで求める場合は、SOC（セキュリティ監視）の運用対象として、SIEM（Splunk Cloudなど）やEDR（CrowdStrike、Microsoft Defender for Endpoint、ApexOneなど）への対応可否も選定基準に加えます。ツールを要件で縛りすぎると提案の幅が狭まりますが、最低限「自社が既に使っているツールに対応できるか」「ベンダー独自ツールを使う場合、契約終了後も監視を引き継げるか」は確認しておくべきです。ツールがベンダーロックインの要因にならないよう、要件段階で出口戦略まで意識しておくことが、長期的な運用の自由度を守ります。
対応範囲を定義して隠れコストを潰す
RFPの仕上げとして欠かせないのが、対応範囲の徹底的な定義です。保守監視の見積もりトラブルの多くは、「基本料金に含まれると思っていた作業が、実は追加費用だった」という対応範囲の認識のズレから生まれます。要件定義の段階で範囲を細かく定義しておけば、後から発生する隠れコストを未然に潰せます。
含む作業・含まない作業を明示する
対応範囲は、「基本料金に含む作業」と「含まない（追加費用となる）作業」を明確に分けて記述します。たとえば、監視と定型的な一次対応は基本料金に含むが、原因調査の深掘り・恒久対応のバグ修正・大規模な復旧作業は別途見積もり、といった具合です。費用の目安として、運用・監視は月5万〜20万円、営業時間内の障害対応は月3万〜8万円、24時間の緊急対応は月10万〜20万円、スポットの障害対応は1件3万〜10万円という相場があります。これらのどこまでを定額に含めるかを、RFPで明示します。
あわせて、月あたりの工数上限や、対応回数の上限があるかどうかも確認すべきポイントです。「月◯時間まで」「月◯件まで」という上限を超えた分が追加費用になる契約は多く、ここを見落とすと、障害が頻発した月に想定外の請求が来ます。RFPで「上限を超えた場合の単価」まで提示を求めておくと、ベンダー間の比較がしやすく、運用が始まってからの費用の見通しも立てやすくなります。
安すぎる見積もりの見抜き方と出口戦略
RFPで複数のベンダーから提案を集めると、極端に安い見積もりが混じることがあります。注意すべきは、安さの裏に「対応範囲が狭い」「SLAが定められていない」「工数上限が低い」といった落とし穴が隠れていないかです。監視はするが障害対応は含まない、SLAの保証がなく未達でもペナルティがない、といった見積もりは、いざ障害が起きたときに役に立ちません。要件を数値で揃えておけば、安すぎる見積もりが何を削って安くなっているのかを見抜けます。
最後に、RFPには契約終了時の出口戦略も要件として含めておきましょう。解約予告の期間、運用ドキュメントや監視設定の引き渡し、ソースコードやアカウントの返却手順を明文化しておくと、将来ベンダーを切り替える際にスムーズに移行できます。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした要件定義の段階で「作った後の運用と、いざというときの引き継ぎ」まで見据えた設計を一貫して重視しています。要件を数値と範囲で固めることが、妥当な見積もりと健全な運用を引き出す出発点になります。
まとめ
ITシステム保守監視のRFP・要件定義書を作り込むうえで核心になるのは、「監視項目・閾値・SLAをすべて数値で定義し、対応範囲を含む作業・含まない作業まで明示する」ことです。監視項目は指標と閾値・監視間隔で具体化し、SLAは稼働率（99.9%なら年8.76時間の停止許容）・初報応答（15分や60分以内）・復旧目標時間（4時間や12時間以内）を未達時のペナルティとセットで定義します。クラウドの責任共有を前提に監視範囲を線引きし、監視ツールの選定基準と出口戦略まで要件に含めることで、安すぎる見積もりの落とし穴を見抜けます。
要件定義で大切なのは、ベンダーに丸投げせず、自社のエスカレーションやBCP連動まで含めて発注者側が主導することです。数値と範囲で要件を固めれば、ベンダーから比較可能な提案を引き出し、隠れコストを未然に潰せます。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を創業。