ITシステムのサーバー監視を外部に委託したり、新たに監視基盤を構築したりするとき、成否を分けるのがRFP（提案依頼書）と要件定義の精度です。「サーバーを監視してほしい」という曖昧な依頼では、ベンダーごとに想定する監視範囲やSLA（サービス品質保証）がばらばらになり、提案を横並びで比較できません。さらに、対応範囲を明文化しないまま契約すると、いざ障害が起きたときに「それは契約外です」と言われ、想定外の追加費用や対応遅れに直面します。だからこそ、何を・どの水準で監視し、異常時に誰が何をするかを、要件として言語化することが重要です。
本記事は、ITシステムのサーバー監視に関するRFP・要件定義書・提案依頼書の作り方を、発注企業（情報システム部門）の視点で具体的に解説する「要件定義特化」の記事です。監視項目としきい値の定義、稼働率や初報応答・復旧時間といったSLAの数値要件、クラウドの責任共有を前提とした範囲の切り分け、監視ツールの選定基準、そして隠れコストを潰す対応範囲の明文化まで、一次データとあわせて整理します。なお、費用相場や契約形態を含む全体像をまだ把握していない方は、まずITシステムサーバー監視の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステムサーバー監視の完全ガイド
監視項目としきい値の要件定義
サーバー監視の要件定義は、「何を監視するか」を具体的な項目に落とし込むことから始まります。死活監視、CPU・メモリ・ディスク・ネットワークのリソース監視、ログ監視、外形監視といった監視の種別ごとに、対象サーバーと監視間隔、そしてアラートを上げるしきい値を定義します。ここが曖昧だと、ベンダーは自社の標準メニューを当てはめるしかなく、自社にとって本当に必要な監視が抜け落ちる危険があります。要件定義書は、この監視の設計図に当たります。
対象サーバーごとに監視項目を一覧化する
要件定義の第一歩は、監視対象となるサーバーをすべて棚卸しし、それぞれに必要な監視項目を一覧化することです。Webサーバー、データベースサーバー、バッチ処理サーバーでは、見るべき指標が異なります。Webサーバーなら同時接続数やレスポンスタイム、データベースサーバーならディスクI/Oやクエリ待ち時間、バッチサーバーなら処理の正常終了といった具合に、サーバーの役割に応じて監視項目を割り当てます。この一覧が、RFPに添付する監視要件の核になります。
一覧化の際は、各サーバーの重要度も併記します。停止が事業に直結する基幹サーバーと、停止しても影響が小さい検証サーバーでは、求める監視の手厚さが違うからです。重要度に応じて監視間隔やアラートの優先度を変えることで、過剰な監視によるコスト増を避けられます。サーバー1台あたりの監視費用は、監視のみで5,000円/台、障害対応込みで10,000円/台、フルマネージドで20,000円/台といった台数課金が一般的なため、重要度の切り分けはそのまま費用設計に直結します。
しきい値とアラート条件を数値で定義する
監視項目を決めたら、次は「どの値を超えたらアラートを上げるか」というしきい値を数値で定義します。CPU使用率が何%を何分継続したら通知するのか、ディスク空き容量が何%を切ったら警告するのか。これらを要件として明記することで、ベンダーの提案を同じ土俵で比較できます。瞬間的なスパイクで誤検知が起きないよう、「継続時間」の条件まで含めて定義するのが実務上のポイントです。
しきい値の定義では、警告レベルと重大レベルを分けることも重要です。たとえばディスク空き容量が20%で「警告」、5%で「重大」というように段階を設ければ、余裕を持って対処できます。すべてを一律のしきい値にすると、本当に緊急の異常とそうでないものの区別がつかず、アラート疲れの原因になります。なお、運用開始時点で完璧なしきい値を決め切るのは難しいため、要件定義書には「運用データに基づきしきい値を定期的に見直す」というチューニングの取り決めも含めておくべきです。
SLAの数値要件をどう設定するか
RFPでもっとも費用に影響するのが、SLA（サービス品質保証）の数値要件です。稼働率を何%とするか、障害発生時の初報応答を何分以内とするか、完全復旧を何時間以内とするか。これらの数値が高ければ高いほど、求められる体制も手厚くなり、費用は跳ね上がります。要件定義では、事業影響度に見合った現実的な水準を設定することが、無駄なコストを避ける鍵になります。
稼働率の数値と許容ダウンタイムを理解する
稼働率の要件を決めるには、その数値が許容する停止時間を具体的に把握する必要があります。稼働率99.9%は年間8.76時間、月43.8分、日7.3分の停止を許容します。これを99.99%にすると、年52.6分、月4.38分、日4.4秒まで縮みます。「9」が1つ増えるごとに、冗長構成や監視頻度のコストは段階的に跳ね上がります。要件定義では、この差を理解したうえで、自社が本当に必要とする水準を選ぶことが重要です。
過剰な稼働率要件は、最大のコスト浪費要因になりかねません。社内向けの業務システムであれば、夜間に数十分停止しても実害が小さいケースは多く、99.99%まで求める必然性は薄いものです。RFPを作る前に、システムごとに「停止が何分続いたらどの業務にどんな影響が出るか」を整理した事業影響度アセスメントを行い、その結果を稼働率要件の根拠とするのが望ましい進め方です。数値だけが一人歩きしないよう、根拠とセットで要件化してください。
初報応答と復旧時間を要件に明記する
稼働率と並んで重要なのが、障害発生時の応答・復旧に関する数値要件です。参考になる実例として、官公庁の仕様では「1時間以内に現地到着・対処を開始」「1時間以内に障害内容と予想作業時間を報告」「原則4時間以内に完全復旧」といった水準が示されています。サービス会社の例では、重大インシデントを15分以内に一次対応する保証や、検知から60分以内に通知し12時間で復旧する水準を掲げる事業者もあります。
要件定義書では、これらを参考に「初報応答は何分以内」「一次対応開始は何時間以内」「完全復旧は何時間以内」を自社の事業影響度に合わせて明記します。一般的な目標としては、重大障害は2時間以内に対応を開始し、原則24時間以内に完全解決するという水準が一つの基準です。あわせて、SLA未達時のサービスクレジット（料金減額）の扱いも要件に含めておくと、契約後のトラブルを防げます。応答・復旧の数値は、停止損失を抑える生命線であり、曖昧にしてはいけない要件です。
クラウド責任共有を前提にした範囲定義
サーバーがクラウドに移ると、要件定義で意識すべきなのが責任共有モデルです。物理層やハードウェアの監視はクラウド事業者の責任範囲ですが、その上で動くOS・ミドルウェア・アプリケーションは利用者側の責任になります。国内エンタープライズ・システム市場のクラウド比率は2022年で約5割（IDC Japan）に達しており、クラウド前提のサーバー監視要件をどう定義するかは避けて通れません。境界を曖昧にすると、障害時の責任の所在が宙に浮きます。
監視範囲と責任分界点を明文化する
要件定義では、どこまでを委託先が監視し、どこからがクラウド事業者の領域なのかという責任分界点を明文化します。たとえば、OS以上のリソース監視とアプリケーションの死活監視は委託先、物理基盤はクラウド事業者、という切り分けを文書化しておけば、障害時に「どちらの責任か」で揉めずに済みます。RFPの段階でこの分界点を示し、各ベンダーがどこまで対応するのかを提案で明確にしてもらうことが重要です。
クラウド基盤の障害は、利用者側で手出しできず、補償もサービスクレジットの範囲にとどまるのが一般的です。だからこそ、基盤障害をいち早く検知する外形監視を要件に含め、検知後に「ユーザー側で何ができるか・何ができないか」を整理しておく必要があります。監視の責任範囲を明文化することは、いざというときに自社が取れる行動と取れない行動を、あらかじめ理解しておくことでもあるのです。
自衛アーキテクチャを要件に織り込む
クラウドの基盤障害に備える自衛策として、重要サーバーの冗長化を要件に織り込むことも検討に値します。マルチリージョン・マルチアベイラビリティゾーンでの冗長構成を求めるかどうかは、停止許容度との兼ね合いで判断します。冗長化はサーバー台数を増やすため、台数課金の監視費用や運用工数という隠れコストも伴います。すべてを冗長化するのではなく、停止が事業に直結する部分に絞るのが現実的です。
要件定義書には、こうしたアーキテクチャ上の前提も明記しておきます。「重要サーバーは冗長構成とし、両系統を監視対象とする」「片系障害時もサービスを継続できること」といった要件を示せば、ベンダーはそれを満たす提案を持ってきます。逆にこうした前提を伝えないと、安価だが単一構成の提案ばかりが集まり、結果として基盤障害に弱い構成を掴まされかねません。自衛のアーキテクチャは、要件定義の段階で意図的に組み込むものだと理解してください。
監視ツール選定基準と対応範囲の明文化
要件定義の仕上げとして、監視ツールの選定基準と、委託先の対応範囲を明文化します。どの監視ツールを使うか、そして「基本料金にどこまで含まれ、どこからが追加費用か」を曖昧にしたまま契約すると、安すぎる見積もりに飛びついた結果、肝心な対応が範囲外だったという事態に陥ります。隠れコストを潰すには、対応範囲の線引きを要件として徹底的に詰めることが欠かせません。
監視ツールの選定基準を要件に含める
監視ツールには、OSSのZabbix、クラウド型のDatadogやNew Relic、サーバー監視特化のMackerelなど、複数の選択肢があります。Zabbixはライセンス無料ですが構築・維持の工数を自社で負担し、クラウド型はホスト数やメトリクス量に応じた従量課金で中規模なら月数万〜数十万円が目安です。要件定義では、「自社で運用するか、委託先のツールに乗るか」「将来のサーバー増減にどう対応するか」を選定基準として整理します。
選定基準には、自社が使うクラウドやセキュリティ製品への対応可否も含めます。たとえばSOC運用を視野に入れるなら、SIEMのSplunk CloudやEDRのCrowdStrike、Microsoft Defender for Endpointといった製品への対応可否が判断材料になります。ツールを特定の製品に固定するか、ベンダーの提案に委ねるかは方針次第ですが、いずれにせよ「何を基準に選ぶか」をRFPで示すことで、提案の質が揃い、比較がしやすくなります。
対応範囲を定義して隠れコストを潰す
RFPでもっとも見落とされがちなのが、対応範囲の明文化です。「監視は含むが障害対応は別料金」「営業時間内は対応するが夜間は追加費用」「一次対応はするが原因調査は範囲外」といった線引きが曖昧だと、契約後に想定外の請求が発生します。費用の目安として、運用・監視は月5万〜20万円、営業時間内の障害対応は月3万〜8万円、24時間の緊急障害対応は月10万〜20万円、スポット対応は1件3万〜10万円という水準があり、何がどこに含まれるかを要件で確定させる必要があります。
対応範囲の定義では、月あたりの作業工数の上限も確認しておきます。安価な見積もりの多くは、工数上限が低く設定されており、それを超えると追加費用が発生する仕組みです。要件定義書に「月次メンテナンスの作業時間」「スポット対応の単価」「工数超過時の扱い」を盛り込み、見積もりにこれらを反映してもらうことで、隠れコストを事前に可視化できます。安すぎる見積もりは、SLAや監視範囲が抜けている可能性が高いため、対応範囲の網羅性で各社を比較する姿勢が、発注側の身を守ります。
まとめ
ITシステムのサーバー監視に関するRFP・要件定義書は、監視項目としきい値の具体化、稼働率や初報応答・復旧時間といったSLAの数値要件、クラウド責任共有を前提とした範囲定義、監視ツールの選定基準と対応範囲の明文化という4つの軸で組み立てると、抜け漏れなく作れます。稼働率99.9%と99.99%の差、官公庁仕様の応答・復旧水準といった一次データを根拠に数値を定め、隠れコストを潰す対応範囲の線引きまで詰めることで、ベンダー提案を同じ土俵で比較でき、安すぎる見積もりの落とし穴も避けられます。
要件定義で大切なのは、ベンダーに丸投げせず、自社の事業影響度を起点に「何を・どの水準で監視し、異常時に誰が何をするか」を言語化することです。まずは監視対象の棚卸しと重要度の整理から始め、事業影響度に見合ったSLAと対応範囲を要件に落とし込んでください。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を創業。