ITシステムのアラート対応をベンダーへ委託したり、監視の仕組みを新たに構築したりするとき、避けて通れないのがRFP（提案依頼書）と要件定義です。ところが、アラート対応のRFPは「24時間監視してほしい」「障害が起きたらすぐ対応してほしい」といった曖昧な表現になりがちで、これでは各社の提案を正しく比較できず、契約後に「思っていた対応範囲と違う」というトラブルに直結します。重要なのは、監視項目・閾値・SLA・対応範囲を数値とともに明文化することです。
本記事は、ITシステムのアラート対応に関するRFP・要件定義書・提案依頼書の書き方を、発注企業（情シス）の視点から実務的に解説する「要件定義特化」の解説です。何を・どの閾値で監視するかの定義、SLAの数値要件（稼働率・初報応答・復旧時間）の決め方、クラウドの責任共有を前提とした監視範囲、そして隠れコストを潰す対応範囲の記述方法まで、一次データとあわせて具体的に解説します。なお、アラート対応の全体像をまだ把握していない方は、まずITシステムアラート対応の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステムアラート対応の完全ガイド
監視項目と閾値を定義する要件の書き方
アラート対応のRFPで最初に明文化すべきは、「何を、どの値で監視し、どうなったらアラートとするか」という監視項目と閾値です。ここが曖昧だと、ベンダーは自社の標準パッケージに当てはめて提案するため、自社にとって本当に重要な監視が抜け落ちることがあります。要件定義の段階で、監視対象を具体的に列挙することが出発点になります。
監視対象とアラート条件を一覧化する
監視対象は、サーバーの死活、CPU・メモリ・ディスクのリソース、ネットワーク疎通、アプリケーションのレスポンス時間、エラーログ、特定プロセスの稼働状況などに分けて一覧化します。それぞれについて「どの閾値を超えたらアラートとするか」「瞬間値か、何分継続したらか」を明記します。たとえば「CPU使用率が90%を5分間継続したら警告、95%を5分間継続したら重大」というように、条件を数値で書き切ることが、提案のばらつきを防ぎます。
この一覧化には、自社のシステム構成図を添付するのが効果的です。どのサーバーが、どのサービスを支え、どこと連携しているかをベンダーが理解できれば、提案の精度が上がります。逆に、構成情報を伏せたまま「よしなに監視してほしい」と依頼すると、ベンダーは安全側に倒して過剰な監視を提案するか、リスクを取らずに最低限の監視にとどめるか、どちらかに偏ります。監視項目と閾値の一覧化は、RFPの土台であり、ここが固まらないとSLAも対応範囲も定まりません。
監視ツールの選定基準を要件に含める
RFPでは、監視ツールの前提条件も要件に含めると、提案の比較がしやすくなります。既存でZabbixを使っているなら「Zabbixの運用を引き継げること」、新規ならクラウド型のDatadogやNew Relic、Mackerelといった選択肢のうち、どの方向性を想定しているかを示します。ツールによって費用構造が大きく異なるため、ここを明示しないと見積もりの前提がそろいません。
たとえばZabbixはライセンスが無料ですが、構築と維持に工数がかかるため、その工数を誰が負担するのかを要件で確認する必要があります。一方、DatadogやNew Relicはホスト数やメトリクス量に応じた従量課金で、中規模なら月数万円から数十万円が目安です。要件定義では「ツールのライセンス費は発注者と受注者のどちらが負担するか」「将来の監視対象増加に伴う費用増の試算」まで踏み込んで記載すると、後の隠れコストを防げます。ツール選定基準を要件に組み込むことは、技術選択であると同時にコスト管理の手段でもあります。
SLAの数値要件を定義する
アラート対応のRFPで最も重要かつ、費用に直結するのがSLA（サービス品質保証）の数値要件です。SLAは「どれだけの品質で対応するか」を約束する指標であり、稼働率・初報応答時間・復旧時間といった数値で定義します。ここを曖昧にすると、いざ障害が起きたときに「いつまでに対応してくれるのか」が宙に浮き、トラブルになります。
稼働率と許容ダウンタイムの定義
稼働率は「99.9%」「99.99%」といった形で定義しますが、この数値の意味を正確に理解しておく必要があります。稼働率99.9%は、年間で約8.76時間、月では約43.8分、日では約7.3分のダウンタイムを許容することを意味します。一方、99.99%にすると、年間約52.6分、月約4.38分、日約4.4秒まで許容ダウンタイムが縮まります。「9」が一つ増えるだけで、許容できる停止時間は劇的に短くなります。
注意すべきは、稼働率の「9」を一つ増やすごとに、運用コストが段階的に跳ね上がる点です。99.99%を実現するには冗長構成や即時復旧の体制が必要になり、待機人員や設備への投資が膨らみます。要件定義では「とにかく高い稼働率を」と求めるのではなく、自社のシステムが本当にその水準を必要としているかを、事業影響度から逆算して決めることが肝心です。すべてを99.99%にすると過剰投資になり、本当に守るべきシステムに資源を集中できなくなります。稼働率の要件は、安全と費用のバランスを示す最も重要な数値です。
初報応答時間と復旧目標時間の数値設定
稼働率と並んで定義すべきが、アラート発生から対応開始・復旧までの時間です。具体的には「アラート検知から何分以内に第一報（初報）を入れるか」「何時間以内に完全復旧を目指すか」を数値で定めます。参考として、官公庁の仕様例では、障害発生から1時間以内に現地到着・対処開始、1時間以内に内容と予想作業時間を報告、原則4時間以内に完全復旧、といった目標が示されています。クラウド事業者では重大issueに15分以内の一次対応を保証する例、検知から60分以内に通知し12時間以内に復旧する例もあります。
これらの数値を要件として定めるとき、重要なのが「努力目標型」か「保証型」かを区別することです。努力目標型は「○分以内を目指す」という努力義務にとどまり、未達でも責任は問われません。保証型は未達の場合にサービスクレジット（料金の減額）などのペナルティを伴います。一般的な目標としては、重大障害は2時間以内に対応開始、完全解決は24時間以内とする例があります。要件定義では、自社にとってどの時間目標が必要で、それを保証型にするのか努力目標型にするのかを、費用とのバランスで決めることが求められます。この区別を曖昧にすると、いざというとき「目標は書いてあったが保証ではなかった」という事態を招きます。
クラウド責任共有を前提にした監視範囲の定義
現在、国内エンタープライズ・システム市場のクラウド比率は約5割に達しており（IDC Japan、2022年）、アラート対応の要件定義でもクラウド前提が当たり前になっています。クラウドでは「責任共有モデル」という考え方があり、どこまでがクラウド事業者の責任で、どこからが利用者側の責任かを正しく切り分けたうえで、監視範囲を定義する必要があります。
クラウド事業者と利用者の監視責任の境界
クラウドの責任共有モデルでは、物理サーバーやネットワークなどの基盤はクラウド事業者が責任を持ち、その上で動くOS・ミドルウェア・アプリケーションは利用者側の責任になるのが一般的です。要件定義では、この境界を踏まえて「自社で監視すべき範囲」を明確にします。クラウド基盤そのものの障害は利用者側では手出しができず、事業者からの情報提供を待つしかありません。だからこそ、利用者責任の範囲をきちんと監視する体制が、アラート対応の前提になります。
注意すべきは、クラウド基盤の障害が起きたとき、事業者側の補償はサービスクレジット（料金の一部返金）にとどまり、それ以上の損害賠償は期待できないのが通例だという点です。つまり、クラウド基盤の障害による事業損失は、最終的に利用者が負うことになります。要件定義では、この前提を踏まえ、クラウド基盤障害時の自社の対応手順や、後述する自衛策まで含めて記述することが重要です。「クラウドだから安心」と監視範囲を曖昧にすると、いざ基盤障害が起きたときに何もできず、状況把握すらできない事態に陥ります。
監視のブラックボックス化を防ぐ自衛策の要件
クラウド化で見落とされがちなのが、「監視のブラックボックス化」というリスクです。クラウド基盤の内部は利用者から見えないため、障害の原因がクラウド側にあるのか自社側にあるのかを切り分けられず、対応が滞ることがあります。要件定義では、こうしたブラックボックス化を緩和する自衛策を盛り込みます。たとえば、外部からサービスの応答を定期的に監視する外形監視を併用し、クラウド側に依存しない形でサービスの生死を把握できるようにします。
さらに踏み込んだ自衛策として、マルチリージョン化などのアーキテクチャ設計を要件に含めることも検討に値します。一つのリージョンが障害を起こしても別のリージョンでサービスを継続できる構成にすれば、クラウド基盤障害の影響を局所化できます。ただし、これらの自衛策は隠れコストになりやすいため、要件定義の段階でコストと効果を天秤にかけ、本当に必要なシステムに限定して適用することが重要です。riplaはフルスクラッチ受託の立場から、クラウドの責任境界を踏まえた監視範囲の整理と、過不足のない自衛アーキテクチャの設計を支援しています。
隠れコストを潰す対応範囲の定義
アラート対応のRFPで最後に詰めるべきが、対応範囲の定義です。「アラートに対応する」という言葉の中身は幅広く、どこまでを基本料金に含み、どこからを追加費用とするかを曖昧にすると、契約後に想定外の請求が発生します。隠れコストを潰すには、対応範囲を細かく書き分けることが欠かせません。
一次対応・原因調査・復旧の線引きを明記する
アラート対応は、検知後の一次対応（再起動やプロセス復旧などの定型対処）、原因調査、根本的な復旧、再発防止策の実施、という複数の段階に分かれます。RFPでは、このうちどこまでが月額の基本料金に含まれ、どこからがスポット対応（追加費用）になるのかを明記します。一次対応のみが基本料金で、原因調査や復旧はスポット扱い、という契約は珍しくありません。この線引きが曖昧だと、障害のたびに想定外の費用が積み上がります。
費用の目安として、運用・監視（24時間365日の死活・リソース監視）は月5万〜20万円、障害対応は営業時間内なら月3万〜8万円、24時間緊急対応を含めると月10万〜20万円、スポット対応は1件3万〜10万円が一般的な水準です。サービス会社の例では、監視5,000円/台、障害対応10,000円/台、フルマネージド20,000円/台といった台数課金もあります。RFPでこれらの料金体系を明示的に問うことで、各社の対応範囲と費用構造を横並びで比較できるようになります。対応範囲の線引きは、見積もりの妥当性を判断する基準そのものです。
「安すぎる見積もり」を見抜く要件チェック
RFPで複数社から提案を集めると、際立って安い見積もりが出てくることがあります。しかし、安さの裏には必ず理由があります。多くの場合、対応範囲が狭い、SLAが努力目標型でしかない、工数の上限が低く設定されている、といった「削られた部分」が隠れています。要件定義の段階で対応範囲とSLAを数値で固めておけば、安すぎる見積もりがどこを削っているかを見抜けます。
具体的なチェックポイントは、SLAが保証型か努力目標型か、月内の対応工数に上限があるか、24時間対応が本当に含まれるか、原因調査や復旧が基本料金に入るか、ツールのライセンス費が別途請求されないか、です。これらを要件として明記し、提案書での回答を求めることで、見かけの安さに惑わされず、実質的なコストパフォーマンスで比較できます。riplaはフルスクラッチ受託と国内運用保守の立場から、対応範囲を曖昧にしない要件定義の整理を支援し、契約後の隠れコストを未然に防ぐお手伝いをしています。要件定義の精度こそが、健全なベンダー選定の前提条件です。
まとめ
ITシステムのアラート対応に関するRFP・要件定義は、監視項目と閾値の一覧化、稼働率・初報応答・復旧時間というSLAの数値定義、クラウド責任共有を前提とした監視範囲、そして一次対応から復旧までの対応範囲の線引き、という4つの軸で組み立てると過不足がなくなります。稼働率99.9%と99.99%の許容ダウンタイムの違い、官公庁仕様の1時間以内報告・4時間以内復旧といった具体例、月5万〜20万円といった費用相場を数値で押さえることで、各社の提案を同じ土俵で比較できるようになります。
要件定義で大切なのは、「とにかく手厚く」と求めることではなく、自社のシステムの事業影響度に照らして必要な水準を数値で見極めることです。過剰なSLAは過剰なコストを生み、曖昧な対応範囲は隠れコストを生みます。まずは監視項目の一覧化から着手し、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を創業。