ITシステム監視対応のRFPと要件定義書では、監視項目と閾値、SLA（サービス品質保証）を具体的に定めます。
クラウドの責任分界と対応範囲も、契約前に明確にしておく必要があります。まずITシステム監視対応の完全ガイドから読むと、全体の流れがつかめます。
▼全体ガイドの記事
・ITシステム監視対応の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
監視項目と閾値の要件定義
RFPの土台になるのが、「何を監視するか」を決める監視項目です。ここが曖昧だと、ベンダーは標準的な項目だけを提案し、自社固有の重要な監視ポイントが抜け落ちてしまいます。
監視項目は、対象システムの構成要素を洗い出し、それぞれについて「何を・どの間隔で・どの閾値で監視するか」まで具体化するのが理想です。要件定義書でこの一覧と閾値の表を示せば、提案各社が共通の前提で見積もれます。
監視対象の洗い出しと優先度付け
監視対象の洗い出しでは、サーバーやデータベース、外部APIなど、システムを構成する要素を網羅的にリストアップします。
ただし、すべてを同じ重みで扱うと、監視の手厚さが合わなくなります。事業に直結する基幹システムと、停止しても影響の小さい社内ツールでは、求める監視水準が異なるためです。
そこでRFPでは、監視対象を重要度でランク分けし、ランクごとに監視の手厚さを変える方針を示しておきます。方針が明確だと、ベンダーもメリハリのある提案をしやすくなります。
監視項目の要件定義は、技術項目を並べるのではなく、事業影響度から逆算して組み立てるのが本質です。その判断の材料になるのが、事業影響度のアセスメントです。「この業務が止まると、誰がどれだけ困り、いくらの損失が出るか」を整理しておくと、監視水準の妥当性を社内でも説明できます。
たとえば、一次データのダウンタイム損失統計では、金融・医療・EC系で5分以上の停止が1回あたり平均1,200万円の機会損失とされています。こうした数字を自社の業務に当てはめると、監視リソースをどこに集中させるかが見えてきます。
- 対象の区分：事業影響度をもとに、対象を重要度のランクに分ける
- ランク別の監視の手厚さ：ランクごとに求める監視水準の違い
RFPに明記する閾値と通知レベル
監視項目が決まったら、各項目の閾値を設計します。CPU使用率なら何%で警告・何%で重大か、ディスク残量なら何%で通知か、レスポンスタイムなら何秒で異常とするか、といった具体的な数値です。
閾値の適正値はシステムの特性によって異なります。そのためRFPでは、自社の希望値を示しつつ、ベンダーの知見で調整する余地も残しておくと建設的です。
閾値が緩すぎると手遅れになり、厳しすぎるとアラートが鳴りやまず形骸化します。この設計の質が、運用の実効性を左右します。
閾値超過時の通知レベルも、あわせて定義しておきます。同じ異常でも、「警告レベルはチャット通知のみ」「重大レベルは電話で即時連絡」というように、レベルごとに通知の方法を変えておきます。
これをRFPに明記しておくと、ベンダーはアラート対応の体制を具体的に提案でき、見積もりにも反映されます。監視項目・閾値・通知レベルの3点を表にまとめた要件定義書は、提案各社を同じ前提で比べるための共通の土台になります。
- 閾値の一覧：監視項目ごとに、警告と重大の境界を数値で書く
- 通知レベルの区分：異常の深刻さを、警告と重大などの段階で分けた一覧
SLAの数値要件（稼働率・初報応答・復旧時間）
監視対応のRFPで核心になるのが、SLA（サービス品質保証）の数値要件です。稼働率、初報応答時間、復旧時間をどの水準で求めるかによって、提案内容と費用が変わります。
SLAを曖昧にしたまま委託すると、「障害には対応します」という抽象的な約束にとどまり、いざというとき期待した速さで動いてもらえません。そこでRFPでは、これらを具体的な数値で定め、未達のときの扱いまで踏み込んで書いておきます。
稼働率の要件と許容ダウンタイムの考え方
稼働率は、システムが正常に動いている時間の割合です。RFPで稼働率を定めるときは、その数値が許容するダウンタイムを理解しておく必要があります。
一次データによると、稼働率99.9%なら年間で許容される停止は約8.76時間（月43.8分）、99.99%なら年間52.6分（月4.38分）です。
この差は、「9」が一つ増えるごとに運用コストが段階的に跳ね上がる形で表れます。冗長構成や即時切替が必要になるためです。
だからこそ、RFPで稼働率を定める前に、「自社に本当に必要な稼働率はいくつか」を見極めることが欠かせません。すべてのシステムに99.99%を求めると、コストが過大になります。
たとえば、基幹の決済システムには高い稼働率を、社内の情報共有ツールには現実的な水準を求めるように、重要度に応じて出し分けるのが賢明です。そうすれば、提案各社は過不足のない構成を組み立てやすくなります。
- 目標稼働率と根拠：システムごとの数値と、それを裏づける事業影響度
- 許容ダウンタイム：目標稼働率から算出される、年間と月間の停止時間
初報応答時間と復旧目標時間の定義
稼働率と並んで重要なのが、障害発生時の応答と復旧の時間要件です。初報応答時間は「障害を検知してから、ベンダーが状況を一次連絡するまで」の時間で、復旧目標時間は「障害を解消するまで」の時間を指します。
一次データでは、官公庁の仕様例として、1時間以内に現地到着・対処開始、1時間以内に内容と予想作業時間を報告、原則4時間以内に完全復旧という具体例が示されています。
Cloud Naviでは、重大なissue（障害）に15分以内の一次対応を保証する例もあります。こうした水準を、自社の要件に落とし込みます。
RFPでは、これらの応答・復旧時間を障害レベルごとに定義するのが効果的です。たとえば、重大障害は2時間以内に対応を開始し24時間以内に完全解決、軽微な障害は翌営業日に対応する、というように段階を設けます。
過剰な要件は費用にそのまま跳ね返るため、現実的な水準と費用のバランスを取ることが要件定義の要になります。
- 障害の深刻度：重大・軽微などに分け、それぞれの応答と復旧の時間を書く
- SLA未達時の扱い：サービスクレジットや報告義務を、契約条件に含める
クラウド責任共有を前提にした範囲定義
クラウドを使う監視対応のRFPでは、責任共有モデルを前提に範囲を区切る視点が欠かせません。国内エンタープライズ・システム市場のクラウド比率は2022年で約5割（IDC Japan）に達しており、多くのシステムがクラウド上で動いています。
クラウドでは、基盤側はクラウド事業者が、その上に乗せたアプリやデータは利用者が責任を持つという分担があります。この境界を理解しないまま委託範囲を決めると、監視や対応に穴ができます。
要件定義書で明確にする責任分界点
RFPでは、システムの各層について、「どこをクラウド事業者が、どこを監視委託先が、どこを自社が見るのか」という責任分界点を明確にします。
たとえば、仮想マシンのハードウェア障害はクラウド事業者の責任ですが、その上のOSやアプリの異常は利用者側の責任です。
この分界を要件定義書にまとめておくと、各層の監視や対応の抜け漏れを防げ、ベンダーも担当範囲を正確に見積もれます。
注意したいのは、クラウド基盤の障害は利用者側では手出しができない点です。基盤障害が起きても、利用者にできるのは事業者の復旧を待つことと、自社のユーザーへ状況を知らせることくらいです。
そこでRFPには、クラウド基盤の障害時に委託先が何をするかを書いておきます。いざというときの動きが明確になります。責任共有の境界を踏まえた範囲定義が、クラウド時代の監視RFPの要諦です。
- 基盤障害時の動き：状況の把握、利用者への告知支援、代替手段の検討
- 層ごとの担当の図：各層で、クラウド事業者と委託先、自社のどこが監視するかを示す
要件に含める監視ツールの選定基準
監視ツールの方針も、RFPで触れておくべき要件です。OSSのZabbixはライセンス費用が無料ですが、構築と維持に工数がかかります。
クラウド型のDatadogやNew Relicは、ホスト数やメトリクス量に応じた従量課金で、中規模なら月数万〜数十万円という水準です。サーバー監視に特化したMackerelのような選択肢もあります。
自社で運用するのか、委託先のツールに乗るのか、既存ツールを生かすのかを、RFPで方針として示すと提案がぶれにくくなります。
ツール選定で見落としがちなのが、ライセンス費用の従量制によるコスト変動です。クラウド型のツールは監視対象が増えると費用も比例して増えるため、将来の拡張を見込んだ試算が必要です。
RFPでは「どのツールを使うか」を固定せず、「自社の規模・拡張計画・既存資産を踏まえて、最適なツールを提案してほしい」と問う形にすると、ベンダーの知見を引き出せます。ツール選定基準を要件に含めると、初期費用だけでなくランニングコストまで見据えた提案を比べられます。
- 将来の拡張：監視対象が増えた場合のライセンス費用の試算
- 運用の担い手：ツールの管理を、自社と委託先のどちらが受け持つか
隠れコストを潰す対応範囲の定義
監視対応のRFPで最後に詰めたいのが、対応範囲の定義による隠れコストの抑制です。基本料金に何が含まれ、何が追加費用になるのかが曖昧だと、契約後に「それは別料金です」という想定外の請求が続くおそれがあります。
要件定義書で対応範囲を細かく定めておくことが、こうした隠れコストを未然に防ぐ有効な方法です。安く見える見積もりほど、範囲が狭く設定されている可能性がある点にも注意が必要です。
基本料金に含む範囲と追加費用の線引き
対応範囲の定義では、監視や一次対応、原因調査など各工程について、基本料金に含むものと追加費用になるものの線引きを明記します。
一次データでは、運用・監視は月5万〜20万円、障害対応は営業時間内で月3万〜8万円、24時間緊急で月10万〜20万円です。また、スポット1件で3万〜10万円という料金感もあります。
料金の内訳を踏まえ、自社が求める工程が基本料金に含まれているかをRFPで問うと、追加費用を予防できます。
特に注意したいのが、月の工数上限です。月額固定型の契約では「月◯時間まで」という上限が設けられていることが多く、それを超えると追加費用が発生します。障害が多発した月には、想定外の超過費用が請求されるおそれがあります。
対応範囲と工数上限を明確にすると、安すぎる見積もりに潜む隠れコストが表に出てきます。
- 基本料金の対象：監視、一次対応、原因調査などを、含むかどうかで区分する
- 超過時の扱い：月の工数上限と単価、超えそうなときの事前通知ルールを定める
契約形態と引き継ぎ要件
RFPには、契約形態の希望も盛り込みます。月額固定型は予算が読みやすい一方、障害ゼロの月も待機費が無駄に感じられます。実働・従量課金型は使った分だけの支払いで済みますが、障害が多発した月は費用が膨らみます。
稼働量に波がある中小企業では、この選び分けが重要です。RFPで「どちらの契約形態を想定しているか」「余剰工数を改善作業に充てる充填型保守は可能か」を問うておくと、自社の事情に合った提案を引き出せます。
最後に忘れてはならないのが、将来のベンダー切り替えを見据えた引き継ぎ要件です。切り替えを考えたときに困らないよう、契約段階で要件として定めておきます。
これを怠ると、いざ切り替えたいときに情報が抱え込まれ、身動きが取れなくなります。
riplaはフルスクラッチ受託と国内運用保守の立場から、対応範囲・契約形態・引き継ぎまで透明に定義したRFPづくりを重視しています。隠れコストを潰す範囲定義こそ、健全な委託関係の出発点です。
- 契約形態の希望：固定型か従量型か、どちらを想定するか
- 引き継ぎ条件：解約予告の期間や、運用ドキュメントの引き渡し、ソースコードの扱い
まとめ
ITシステム監視対応のRFP・要件定義書は、監視項目と閾値を事業影響度から逆算して定め、SLAを障害レベルごとに数値で示すところから組み立てます。
そのうえで、クラウドの責任共有を前提に範囲を区切り、対応範囲と工数上限を明確にして隠れコストを抑えます。稼働率99.9%なら年8.76時間、99.99%なら年52.6分という許容停止の差や、官公庁仕様の1時間以内の対処・4時間以内の復旧といった一次データを基準に、自社に見合った水準を見極めることが要点です。
RFPでは、立派な要件を並べるより、自社の事業影響度と予算に見合った現実的な要件を数値で示すことが大切です。曖昧さを残さないRFPは、提案の質を上げ、比較を可能にし、契約後のトラブルを防ぎます。
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を創業。