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