ITシステムのログ監視を外部に委託したり、監視基盤を新たに構築したりするとき、最初の関門になるのがRFP（提案依頼書）や要件定義書の作成です。「どのログを、どの閾値で、どこまで監視してほしいのか」を発注側が言語化できないと、ベンダーから出てくる見積もりは曖昧になり、後から「その対応は範囲外です」というトラブルに直結します。ログ監視は対応範囲の線引きが特に難しい領域であり、要件を数値で固めておくことが、適正な費用と確実な対応を引き出す鍵になります。
本記事は、ITシステムのログ監視のRFP・要件定義書・提案依頼書の作り方を、発注企業の視点で具体的に解説する「要件定義特化」の内容です。監視対象ログと閾値の数値要件、SLA（稼働率・初報応答・復旧時間）の定め方、クラウドの責任共有を前提とした監視範囲の定義、隠れコストを潰す対応範囲の明文化まで、一次データの数値を交えて整理します。なお、ログ監視の全体像をまだ把握していない方は、まずITシステムログ監視の完全ガイドから読むことをおすすめします。読み終えるころには、ブレない要件定義書の骨格が描けるはずです。
▼全体ガイドの記事
・ITシステムログ監視の完全ガイド
監視対象ログと閾値の数値要件を定義する
ログ監視の要件定義で最初に固めるべきは「何を監視するか」です。対象を曖昧にしたまま発注すると、ベンダーは無難に広く見積もるか、逆に狭く解釈して必要なログが監視されないかのどちらかになります。監視対象のログと、異常と判断する閾値を数値で明記することが、要件定義書の土台になります。ここではその具体的な書き方を見ていきます。
監視対象ログの一覧と優先度を明記する
要件定義書には、監視対象とするログを一覧で列挙します。アプリケーションのエラーログ、Webサーバーのアクセスログ、OSのシステムログ、データベースのスロークエリログ、認証ログといった具合に、どのサーバーのどのログを対象にするかを具体的に書き出します。あわせて、それぞれに事業影響度に基づく優先度を付けると、ベンダーが対応のメリハリを設計しやすくなります。
このとき有効なのが、事業影響度アセスメントの考え方です。すべてのログを同じ重さで24時間監視すると費用がかさみます。売上に直結する基幹システムのエラーログは最優先で即時通知、社内向けツールのログは翌営業日確認で十分、といった具合に、影響度で監視レベルを分けると、限られた予算を効果的に配分できます。要件定義の段階で「どのログが止まると事業にいくらの損失が出るか」を整理しておくと、過剰監視も過少監視も避けられます。
閾値と検知条件を数値で書き切る
監視対象を決めたら、次は異常と判断する閾値を数値で定義します。「エラーログが5分間に50回以上出たら通知」「特定の致命的キーワードは1回でも即時通知」「ディスク使用率90%超で警告、95%超で重大通知」といった具合に、条件を曖昧さなく書き切ることが重要です。閾値が文章で曖昧に書かれていると、ベンダーごとに解釈が割れ、見積もりの比較もできません。
とはいえ、初期の閾値を発注側が完璧に決め切るのは困難です。そこで要件定義書には「運用開始後、3カ月間はチューニング期間とし、誤検知や検知漏れを踏まえて閾値を見直す」というプロセスも盛り込んでおくと現実的です。閾値はベースラインを観測しながら最適化していくものだという前提を、発注側とベンダーで共有しておくことが、アラート疲れと検知漏れの両方を防ぎます。要件定義は固定の仕様書ではなく、改善を織り込んだ設計だと捉えるのが成功のコツです。
SLAを数値で定める
ログ監視の要件定義で費用を最も大きく左右するのが、SLA（サービス品質保証）の設定です。稼働率、異常検知後の初報応答時間、復旧目標時間といった数値を、どの水準で求めるかが、そのまま監視体制の規模とコストに跳ね返ります。過剰なSLAは無駄なコストを生み、過少なSLAはいざというとき機能しません。一次データの実値をもとに、適正な水準を見ていきます。
稼働率99.9%と99.99%の差を理解して設定する
稼働率の目標は、要件定義で最も慎重に決めるべき数値です。稼働率99.9%は年間8.76時間・月43.8分・日7.3分のダウンタイムを許容します。これが99.99%になると年間52.6分・月4.38分・日4.4秒まで縮まります。一見わずかな差ですが、「9」が一つ増えるごとに運用コストは段階的に跳ね上がります。99.99%を求めるなら冗長構成や即時対応体制が必要になり、費用が大きく変わるのです。
要件定義では、自社のシステムが本当に99.99%を必要とするかを冷静に見極めることが大切です。深夜に数分停止しても事業影響が小さいシステムに、最高水準のSLAを求めるのは過剰投資です。情シスがビジネス部門に対し「99.99%にすると費用が何倍になるか」を示し、許容できるダウンタイムを合意形成することが、現実的なSLA設定につながります。要件定義書には、この合意した稼働率の根拠も併記しておくと、後の社内調整がスムーズになります。
初報応答・復旧目標時間を具体的に定める
稼働率と並んで重要なのが、異常検知後の初報応答時間と復旧目標時間です。一次データの実値を参考にすると、官公庁仕様では「1時間以内に現地到着・対処開始」「1時間以内に内容と予想作業時間を報告」「原則4時間以内に完全復旧」といった水準が定められています。民間ではCloud Naviが重大issueに15分以内の一次対応を保証し、シーズホスティングが検知から60分以内に通知・12時間で復旧を掲げています。
要件定義書では、これらの実値を参考に「重大障害は検知後何分以内に一次対応を開始するか」「何時間以内に復旧を目指すか」を明記します。あわせて重要なのが、この時間が「努力目標」なのか「保証」なのかの区別です。保証型は未達時にサービスクレジット（料金減額）が発生しますが、その分費用は高くなります。一般的な目標である「重大障害2時間以内対応開始・完全解決24時間以内」を一つの基準に、自社の事業影響度に見合う水準を設定してください。
クラウドの責任共有を前提に監視範囲を定義する
クラウド環境のログ監視では、責任共有モデルを前提に監視範囲を定義する必要があります。IDC Japanの調査では、国内エンタープライズ・システム市場のクラウド比率は2022年で約5割に達しており、いまや多くのシステムがクラウド上で動いています。クラウドでは「どこまでが自社の責任で、どこからがクラウド事業者の領域か」を踏まえないと、監視の抜け漏れや無意味な要求が生じます。
責任共有モデルでの監視範囲の線引き
クラウドの責任共有モデルでは、物理インフラやハイパーバイザーはクラウド事業者の責任、その上で動くOSやアプリケーション、データは利用者の責任となるのが一般的です。ログ監視の要件定義では、自社が監視すべきレイヤー、つまりアプリケーションログやOSのログ、クラウドが提供する監査ログのどこを対象にするかを明記します。クラウド基盤そのものの障害は利用者側で手出しできないため、監視の対象外として扱うのが現実的です。
ここで注意したいのが、クラウド基盤障害の「監視のブラックボックス化」です。クラウド事業者側で障害が起きても、利用者はサービスクレジット以上の補償を受けられないことが一般的です。要件定義では、この前提を踏まえ、クラウドの稼働状況を示すステータスページの監視や、マルチリージョン構成による自衛策を盛り込むかどうかを検討します。クラウドだから安心と丸投げするのではなく、利用者側で取れる監視と自衛の範囲を明確にすることが大切です。
監視ツール選定の評価基準を要件に含める
RFPには、どの監視ツールを使うかの評価基準も含めると、提案の質が上がります。OSSのZabbixはライセンス無料ですが構築・維持の工数がかかり、クラウド型のDatadogやNew Relicはホスト数やメトリクス量に応じた従量課金で中規模なら月数万〜数十万円かかります。サーバー監視にはMackerel、SIEM用途にはSplunk Cloudといった具合に、ツールには得意領域があります。
要件定義書では、ツールを名指しで指定するより「自社のクラウド環境に対応していること」「ログ量の増加に応じた料金体系が見通せること」「既存システムと連携できること」といった評価基準を示すほうが、ベンダーの提案の幅が広がります。とくにクラウド型は従量課金のため、ログ量が増えると費用が膨らむ「隠れコスト」に注意が必要です。要件には、想定するログ量と将来の増加を見越した費用シミュレーションの提示を求める一文を入れておくとよいでしょう。
対応範囲を明文化し隠れコストを潰す
ログ監視の委託で最もトラブルになりやすいのが、対応範囲の認識ズレです。「監視」という言葉には、ログを見るだけなのか、異常時に対応まで行うのか、原因調査まで含むのか、幅があります。要件定義書で対応範囲を曖昧にしたまま発注すると、いざというときに「それは範囲外」と言われ、追加費用や対応遅延に苦しみます。ここでは隠れコストを潰す対応範囲の書き方を見ていきます。
監視・一次対応・原因調査の線引きを明記する
対応範囲を明文化する際は、業務を段階に分けて、それぞれが基本料金に含まれるか追加費用かを定義します。具体的には、ログの監視・検知、アラートの一次対応（切り分けと暫定処置）、原因調査、恒久対応、報告という流れを段階化し、どこまでを委託するかを書き切ります。一次データでは、運用・監視（24/365の死活・リソース監視）が月5万〜20万円、24時間緊急の障害対応が月10万〜20万円、スポット対応が1件3万〜10万円といった相場感があります。
この線引きを明確にすることで、見積もりの妥当性も判断できるようになります。たとえば「監視のみ月3万円」という安い提案は、障害時の対応が含まれていない可能性が高く、いざというとき自社で深夜対応する羽目になります。要件定義書で「重大障害時は一次対応と原因調査まで含む」と明記しておけば、各社の提案を同じ土俵で比較できます。安すぎる見積もりの罠を避けるには、対応範囲の定義こそが最大の防御になります。
報告体制とベンダー切り替え条項を盛り込む
要件定義書には、定常的な報告体制も明記します。月次でどんなレポートを提出するか、ログの傾向分析や改善提案を含むか、インシデント時の報告フォーマットはどうするかを定めておくと、運用が形骸化しません。情シスは経営層や業務部門へ状況を報告する立場にあるため、ベンダーからの報告がそのまま社内報告に使える品質であることが望ましいのです。
あわせて、将来のベンダー切り替えを見据えた条項も入れておくと安心です。解約時の予告期間、監視設定や閾値設計のドキュメント引き渡し、監視アカウントの移管手順を要件に含めておけば、特定ベンダーへのロックインを防げます。ログ監視は一度委託すると設定がブラックボックス化しやすいため、引き継ぎの取り決めは最初の契約で押さえておくことが重要です。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした要件整理から監視設計まで、システムの作り手として一貫して伴走しています。
まとめ
ITシステムのログ監視のRFP・要件定義書を振り返ると、成功の鍵は「監視対象と閾値・SLA・対応範囲のすべてを数値と文章で曖昧さなく定義する」ことに尽きます。監視対象ログを事業影響度で優先度付けし、閾値を数値で書き切り、稼働率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を創業。