ITシステムの障害対応を外部に委託しようとするとき、最初の関門になるのが「何を、どこまで、どんな品質で対応してほしいか」をRFP（提案依頼書）や要件定義書にどう書き起こすかです。ここが曖昧なまま見積もりを取ると、各社の提案がバラバラになって比較できず、契約後に「それは対応範囲外です」「それは追加費用です」というトラブルが噴出します。障害対応の品質は、契約前に要件をどれだけ数値で固めたかでほぼ決まると言っても過言ではありません。
本記事は、ITシステム障害対応のRFP・要件定義書・提案依頼書の書き方を、発注者の視点から具体的に解説する「要件定義特化」の内容です。監視項目と閾値、SLA（稼働率・初報応答・復旧時間）の数値要件、クラウドの責任共有を前提とした範囲定義、監視ツールの選定基準、そして隠れコストを潰す対応範囲の明文化まで、一次データのSLA実値や費用相場を交えて整理します。障害対応・監視の全体像をまだ把握していない方は、まずITシステム障害対応の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム障害対応の完全ガイド
監視項目と閾値の要件を定義する
RFPで最初に固めるべきは、「何を、どの閾値で監視するか」という監視項目の要件です。ここを「サーバーを監視してください」とだけ書くと、ベンダーごとに想定する監視の粒度が異なり、見積もりも品質も揃いません。監視対象・監視指標・閾値・監視間隔を具体的に書き下すことで、初めて各社が同じ前提で提案でき、比較が成立します。
監視対象・指標・閾値を具体的に書き下す
監視項目の要件は、対象ごとに表形式で整理すると漏れがなくなります。Webサーバー・アプリケーションサーバー・データベース・ネットワーク機器といった対象ごとに、死活（応答の有無）、CPU・メモリ・ディスク使用率、応答時間、エラーログの発生といった指標を割り当て、それぞれに「使用率80%で警告、90%で重大」といった閾値を設定します。この粒度まで書けば、ベンダーは必要な監視ツールの構成や工数を正確に見積もれます。
閾値を決めるときは、過去の障害の振り返りが役に立ちます。これまでどんな指標がどの水準に達したときに障害が起きたかを洗い出し、その手前で警告が出るように閾値を逆算します。閾値の根拠が示せると、ベンダーとの認識合わせもスムーズです。要件定義の段階で「なぜこの閾値なのか」まで言語化しておくと、運用開始後に誤検知や見逃しが起きたときの調整も論理的に進められます。監視項目の精度は、障害対応全体の精度の出発点になります。
通知・報告の要件と頻度を定める
監視で異常を検知した後、誰に・どの経路で・どのくらいの速さで通知するかも、要件として明記すべき項目です。重大度ごとに通知先を分け、重大障害は電話で即時、軽微なものはメールやチャットで集約、といった通知ルールを定義します。あわせて、平常時の定期報告の頻度（月次レポートの有無や内容）も要件に含めておくと、運用の透明性が確保されます。報告がない委託は、何が起きているか分からないブラックボックスになりがちです。
報告の要件には、障害発生時の初報・中間報・終報の様式も含めると効果的です。官公庁の仕様例では「1時間以内に内容と予想作業時間を報告」というルールが定められており、こうした初報のタイミングを要件として明示すれば、ベンダーは報告体制を込みで提案してくれます。通知と報告の要件を曖昧にしておくと、障害が起きても自社に連絡が来ない、あるいは経緯が分からない、という事態になります。コミュニケーションの要件こそ、後で揉めやすいポイントだと心得ておきましょう。
月次の定期報告については、報告書に何を載せてほしいかまで要件化すると、運用がブラックボックス化しません。具体的には、当月の障害件数と内訳、各障害のMTTR、SLAの達成状況、リソース使用率の推移、改善提案といった項目を例示します。こうした定型レポートがあれば、情シスは経営層へ運用状況を説明しやすくなり、保守費の妥当性も社内に示せます。報告は単なる事務ではなく、委託の成果を可視化し、次の改善につなげるための重要な要件だと位置づけることが大切です。
SLAの数値要件を設計する
障害対応のRFPでもっとも重要なのが、SLA（サービス品質保証）の数値要件です。稼働率・初報応答時間・復旧目標時間という三つの数値を、感覚ではなく事業影響度から逆算して定めます。この数値が費用に直結するため、要件として正確に固めることが、過剰投資も過少投資も避ける鍵になります。
稼働率は事業影響度から逆算して決める
稼働率の要件を決めるときは、「9」の数が一つ増えるごとに許容停止時間が桁違いに縮むことを理解しておく必要があります。稼働率99.9%なら年間8.76時間・月43.8分・日7.3分の停止が許容されますが、99.99%にすると年52.6分・月4.38分・日4.4秒まで縮みます。この差を実現するには、冗長構成や監視体制を一段強化する必要があり、運用コストは段階的に跳ね上がります。だからこそ、稼働率は「念のため高めに」ではなく、停止が事業にいくらの損失を与えるかから逆算して決めるべきです。
事業影響度の評価には、システムごとに「停止したときに止まる業務・売上・社会的信用」を点数化する方法が有効です。総務省2025年版の調査では、金融・医療・EC系で5分以上の停止1回あたり平均1,200万円の機会損失が生じるとされており、こうした損失額を基準にすれば、どこまでの稼働率に投資する価値があるかが見えてきます。社内の業務システムで半日止まっても支障が小さいものに99.99%を求めるのは過剰投資です。要件定義では、システムを重要度で仕分け、それぞれに見合った稼働率を割り当てることが肝心です。
初報応答時間と復旧目標時間を数値で固める
稼働率と並んで定めるべきが、初報応答時間（障害連絡から最初の応答までの時間）と復旧目標時間です。実在する基準を参考にすると、官公庁の仕様例では「1時間以内に現地到着・対処開始」「原則4時間以内に完全復旧」、Cloud Naviでは重大インシデントに15分以内の一次対応保証、シーズホスティングでは検知から60分以内の通知・12時間で復旧、といった水準が示されています。一般的な目標としては重大障害2時間以内の対応開始・完全解決24時間以内という例もあります。
これらの数値を要件にする際は、重大度のランク分けとセットにすることが重要です。「最重要システムは15分以内に一次対応・4時間以内に復旧」「通常システムは1時間以内に一次対応・翌営業日までに復旧」というように、影響度に応じて応答・復旧の目標を変えます。すべてに最速の数値を求めると費用が跳ね上がるため、メリハリが欠かせません。また、これらが「努力目標」なのか「保証」なのかも明記します。保証型は未達時にサービスクレジット等のペナルティが伴うため費用が上がる一方、実効性は高まります。数値と保証の有無をセットで要件化することが、SLA設計の核心です。
SLA未達時の取り扱いも、要件で踏み込んでおきたい論点です。保証型のSLAでは、未達時にサービスクレジット（料金の一部返金）が設定されることが一般的ですが、その算定方法や上限、間接損害が免責される範囲までは見落とされがちです。要件として「未達時のサービスクレジットの算定基準」「損害賠償の上限」「免責される損害の範囲」を確認しておけば、いざというときの認識齟齬を防げます。SLAは品質の約束であると同時に、約束が守られなかったときの取り決めでもあります。守れたときと守れなかったときの両方を要件化することで、契約は実効性を持つのです。
クラウド責任共有を前提に範囲を定義する
近年のシステムはクラウド上で動くことが多く、要件定義では「どこまでが委託先の責任で、どこからがクラウド事業者の責任か」を明確にする必要があります。国内エンタープライズ・システム市場のクラウド比率は2022年で約5割（IDC Japan）に達しており、責任共有モデルを前提にしない要件定義は現実離れしています。この線引きを曖昧にすると、いざ障害が起きたときに責任の押し付け合いが起きます。
責任分界点を明文化する要件
クラウドの責任共有モデルでは、物理基盤やハイパーバイザーまではクラウド事業者の責任、その上のOS・ミドルウェア・アプリケーション・データは利用者側の責任、というように層で責任が分かれます。要件定義では、委託先がこのどの層を監視・対応するのかを明文化します。たとえば「OSより上のレイヤーの監視・障害対応は委託先が担い、クラウド基盤側の障害については委託先が一次切り分けと事業者への報告までを行う」といった形で、責任分界点をはっきりさせます。
クラウド基盤の障害は利用者側からは手出しができず、補償もサービスクレジット止まりで実損はカバーされません。だからこそ要件定義では、基盤障害が疑われる場合の委託先の動き、つまりクラウド事業者のステータス確認、自社への報告、代替手段への切り替え支援までを範囲に含めるかどうかを定めます。クラウドだから委託先は何もできない、と切り捨てるのではなく、ブラックボックスの外側でできる対応を要件として明確にすることが、クラウド時代の障害対応RFPの肝になります。
監視ツールの選定基準を要件に含める
監視ツールをどうするかも、要件定義で方針を示しておくべき項目です。OSSのZabbixはライセンス無料ですが構築・維持の工数がかかり、Datadog・New Relic・Mackerelといったクラウド型はホスト数やメトリクス量に応じた従量課金で、中規模なら月数万円から数十万円が目安です。要件では「既存のツールを使うのか、委託先のツールに乗るのか」「ツールのライセンス費用は誰が負担するのか」を明確にします。これを曖昧にすると、後でツール費用が想定外の追加コストになります。
ツール選定の基準には、自社の技術スタックとの相性も含めます。クラウドネイティブな構成ならクラウド型監視と親和性が高く、オンプレミス中心ならZabbixのような柔軟なOSSが適することもあります。また、委託先を将来切り替える可能性を考えると、特定ベンダー専用のツールに過度に依存しない構成を要件にしておくと、ロックインを避けられます。監視ツールは長く使う基盤なので、要件定義の段階で選定基準と費用負担を明確にしておくことが、後悔しない委託につながります。
監視データの所有権も、要件で押さえておきたいポイントです。委託先のツールで集めた監視ログやメトリクスが、契約終了後に自社へ引き渡されるのか、それとも委託先のものとして消えてしまうのかは、後の運用に大きく影響します。過去の監視データは原因調査や傾向分析の貴重な資産なので、「監視データは自社に帰属し、契約終了時にエクスポートして引き渡す」といった条項を要件に含めておくと安心です。ツールそのものだけでなく、ツールが生み出すデータの扱いまで要件化することが、長期的な運用の自由度を守ります。
隠れコストを潰す対応範囲の要件
要件定義の最後の仕上げが、「基本料金に何が含まれ、何が追加費用になるか」という対応範囲の明確化です。ここが曖昧だと、契約後に「それは範囲外」「それはスポット対応で別料金」と次々に追加請求が発生し、当初の見積もりが意味をなさなくなります。隠れコストを契約前に潰すことが、要件定義の最大の防御策です。
基本料金の範囲内・範囲外を線引きする
対応範囲の要件では、監視・一次対応・原因調査・復旧・パッチ適用といった作業ごとに、基本料金に含むか追加費用かを明記します。運用・監視の費用相場は月5万〜20万円、障害対応は営業時間内で月3万〜8万円、24時間緊急で月10万〜20万円、スポット1件で3万〜10万円が目安です。たとえば「月次の定常監視と営業時間内の一次対応は基本料金、深夜の緊急出動と原因調査の工数はスポット課金」というように、線引きを数値とともに固めます。
あわせて、月あたりの工数上限を要件に含めることも有効です。基本料金に「月◯時間まで」という上限がある場合、それを超えた分の単価を事前に確認しておかないと、繁忙月に想定外の請求が来ます。人月単価は監視オペレーターで60万〜80万円、運用設計・インシデント分析で80万〜120万円が目安なので、超過時の時間単価もこの水準から逆算できます。範囲内・範囲外と超過単価を要件で固めておけば、各社の見積もりを同じ土俵で比較でき、安すぎる見積もりに潜む「範囲の狭さ」も見抜けます。
安すぎる見積もりには、対応範囲が極端に狭い、SLAが努力目標止まりで保証がない、深夜の対応が含まれていない、といった落とし穴が潜んでいることが少なくありません。要件で範囲・SLA・時間帯を数値化しておけば、各社が同じ条件で見積もるため、極端に安い提案は「何かが抜けている」と判断できます。逆に、要件が曖昧なまま金額だけで選ぶと、契約後に追加費用が積み上がり、結局は高くつくことになります。要件定義は、見積もり比較の物差しを自分の手で作る作業だと考えると、その重要性が腹落ちするはずです。
契約終了時の引き継ぎ要件を盛り込む
見落としがちですが、契約終了時の引き継ぎ要件も最初のRFPに入れておくべきです。委託先を将来切り替えるとき、監視設定・手順書・障害履歴・アカウント情報がスムーズに引き渡されなければ、移行に多大な時間とコストがかかります。要件として「解約予告期間」「ドキュメント・設定の引き渡し範囲」「移行支援の有無と費用」を定めておけば、特定ベンダーへのロックインを避けられます。
引き継ぎ要件を最初に盛り込むことは、ベンダーに対する健全な牽制にもなります。出口が明確に設計されていれば、委託先も「囲い込み」ではなく品質で評価される前提に立ち、サービスの質を保ち続ける動機になります。逆に、入口だけ決めて出口を決めない契約は、いざ不満が生じても乗り換えにくく、足元を見られかねません。要件定義は、契約の始まりだけでなく終わりまでを見据えて書くことで、長期的に主導権を握れます。隠れコストと出口の要件を固めることが、賢い障害対応の委託の土台になります。
引き渡しの具体的な範囲としては、監視ツールの設定一式、障害対応の手順書、過去の障害履歴とその対応記録、サーバーやアカウントのアクセス情報、構成図やネットワーク図などが挙げられます。これらを「いつまでに、どの形式で、誰に」引き渡すかまで要件に書いておくと、移行作業が滞りません。委託先が変わるたびにゼロから運用を作り直すのは大きな無駄なので、要件定義の段階で引き継ぎの作法を決めておくことが、長く付き合うほど効いてきます。
まとめ
ITシステム障害対応のRFP・要件定義書は、監視項目と閾値、SLAの数値要件、クラウドの責任分界点、監視ツールの選定基準、そして対応範囲と引き継ぎの明文化という五つの柱で構成されます。監視は対象・指標・閾値まで具体化し、SLAは稼働率・初報応答・復旧時間を事業影響度から逆算して数値で固め、クラウドは責任共有を前提に範囲を線引きし、対応範囲は基本料金と追加費用の境界を一次データの相場とともに明記します。これらを数値で固めることで、各社の見積もりが同じ土俵に乗り、安すぎる見積もりの落とし穴も見抜けるようになります。
要件定義の良し悪しは、契約後の障害対応の品質とコストをほぼ決定づけます。曖昧な一行が、後の追加請求や責任の押し付け合いを生む種になります。逆に、数値と範囲を丁寧に固めたRFPは、ベンダーとの認識齟齬を防ぎ、長期的に主導権を握る武器になります。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を創業。