IT運用保守のRFP（提案依頼書）と要件定義書は、ベンダーとの成否を左右する土台です。責任分界点、契約形態、SLAの数値、提案の評価軸、契約終了時の出口を決めておくと、発注側が主導権を保ちやすくなります。決めずに進めると、契約後に「これは範囲外です」というトラブルが頻発します。
費用相場や契約形態を含む全体像は、IT運用保守の完全ガイドで先に確認できます。
▼全体ガイドの記事
・IT運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFPでの責任分界点の定義（クラウド責任共有前提）
現代のIT運用保守RFPでは、最も重要でありながら最も抜けやすいのが「責任分界点」の定義です。システムがAWSやSaaS、外部APIの上に成り立っている以上、すべての障害を保守ベンダーがコントロールできるわけではありません。
クラウド側の障害、連携SaaSの仕様変更、AIの誤動作といった「ベンダーのコントロール外」で起きる事象の責任と費用を、RFPで明確にしておく必要があります。そうしないと、いざというときに誰も責任を取らない空白地帯が生まれます。
クラウド・SaaS障害の責任と費用のRFPへの明記
クラウドの責任共有モデルでは、インフラの可用性はクラウド事業者が、その上のアプリケーションやデータは利用者側が責任を持ちます。
RFPでは、「AWSのリージョン障害が起きたとき、保守ベンダーはどこまで対応するのか」「連携SaaSがAPI仕様を変更して連携が止まったとき、その改修費用は誰が負担するのか」を具体的に書き込む必要があります。
責任の範囲を曖昧にしたままだと、クラウド側起因の障害で稼働率SLAを割っても「うちのせいではない」と責任を回避され、発注側だけが損害を被ることになります。
実務的には、RFPに「想定される障害の発生源（自社アプリ／クラウド基盤／連携SaaS／ネットワーク等）ごとに、保守ベンダーの対応範囲と費用区分を提案で明示すること」という要求を入れるのが有効です。責任分界点をRFPの段階で言語化させることは、後の想定外費用をめぐる泥沼を防ぐ最大の予防策になります。
RFPでは、コントロール外の事象についても、ベンダーが担う最低限の役割を決めておくと、空白地帯が埋まります。
- 一次切り分けと状況報告：コントロール外の障害でも、まず原因の見当をつけて、発注側に状況を伝える
- クラウド事業者への問い合わせ代行：発注側に代わって、保守ベンダーがクラウド事業者へ問い合わせる
契約形態（準委任か請負か）の要件指定
RFPでは、業務ごとに想定する契約形態も指定しておくと、提案の前提が揃います。ベンダーは「どこまでが月額の準委任で、どこからが別見積の請負か」を明確に提案でき、発注側も費用の見通しを立てやすくなります。
契約形態を要件として整理しないまま発注すると、本来は請負で別見積になるはずの大きな改修まで「保守の範囲でしょう」と期待してしまい、認識のズレからトラブルになります。
RFPの段階で「定常運用は準委任、◯時間を超える改修や機能追加は請負で別途見積」という枠組みを示しておけば、双方の期待値が揃います。
契約形態は法務リスクにも直結するため、運用保守のRFPでは技術要件と並んで明記すべき重要項目です。
- 定常運用：日々の監視、障害対応、問い合わせ対応は、成果物が定義しにくいため準委任契約が基本です（出典：ripla）
- まとまった改修：「完成すべき成果物」が明確なバージョンアップや改修は、請負契約として個別に発注するのが適しています
あわせてRFPでは、契約期間と更新条件、解約の予告期間も要件として示しておく必要があります。
運用保守は長期契約になりやすく、不満が出ても解約しづらい構造に陥りがちです。そのため、最低契約期間が長すぎないか、自動更新の条件は妥当か、解約時にデータやドキュメントを確実に返してもらえるかを、契約の入り口で定義しておくことが、後のベンダーロックインを防ぐ布石になります。
責任分界点と契約形態、そして出口の条件まで含めてRFPで言語化することが、発注側が主導権を保ち続けるための土台です。
SLAと非機能要件の数値化
運用保守のRFPで提案を正しく比べるには、SLA（サービス品質保証）と非機能要件を数値で示すことが欠かせません。
「安定して動かしてほしい」「障害には早く対応してほしい」といった定性的な表現では、各社が思い思いの前提で見積を出すため、横並びの比較ができません。
稼働率・応答時間・復旧時間といった指標を具体的な数値で示すと、提案を同じ条件で比べられるようになります。
稼働率・応答時間・復旧時間の数値要件
SLAの数値要件は、一次データの実値を参考に設定すると現実的です。RFPには、事業重要度に合わせた目標値を記載し、「提案ではこの目標を満たせるか、満たすための体制をどう構築するか」を問います。
非機能要件としては、処理速度の数値も欠かせません。実際のRFP例では「全画面を3秒以内で表示」といった性能要件が定められることがあります（出典：ripla）。
運用保守のRFPでは、こうした性能を「維持し続ける」ことを要件に含め、性能が劣化したときの対応も範囲に入れます。数値で要件化しておけば、SLA未達時のペナルティ（月額の何%減額か）も具体的に議論でき、努力目標型ではなく実効性のある保証型のSLAを引き出せます。
曖昧な期待を数値の約束へ変換することが、RFPの中核的な役割です。
稼働率と障害対応の目標は、数値で区分して示すと、提案を同じ基準で比べやすくなります。
- 稼働率とエスカレーション：稼働率は99.9%（月の許容停止時間が約43分）か99.5%、エスカレーションは30分以内
- 初報応答と復旧時間：初報応答は重大障害で15分・通常で2時間、暫定復旧は重大で4時間・通常で8時間、恒久対応は5営業日以内（出典：ripla）
現場の曖昧な要望の測定可能な要件への翻訳
要件定義の難所は、現場から上がってくる曖昧な要望を、測定可能な要件へ翻訳することです。「もっと早く対応してほしい」という声を、そのままRFPに書いても意味がありません。
「もっと早く対応してほしい」を「重大障害は15分以内に第一報を入れる」という測定可能な基準へ翻訳して初めて、提案の比較ができ、達成・未達も判定できる要件になります。
この翻訳作業こそが、発注側が運用保守の要件定義で果たすべき本質的な役割です。
曖昧な要望を放置したままRFPを出すと、提案は各社まちまちになり、契約後も「思っていたのと違う」が続きます。要望を要件へ翻訳する力が、RFPの質を左右します。
翻訳の進め方は、順を追って二つの作業に分けると整理しやすくなります。
- 現場のヒアリング：「どんなときに、何に困っているか」を集める
- 指標への落とし込み：頻度・時間・件数・割合で表す。たとえば「問い合わせの返事が遅い」は「問い合わせへの回答は24時間以内」とする（出典：ripla）
提案評価軸の設計（価格偏重の回避）
RFPで最後に決めるのは、提案をどう評価するかという評価軸の設計です。運用保守は長く付き合う相手を選ぶ行為であり、目先の価格だけで決めると、安かろう悪かろうのベンダーを引き当ててしまいます。
その結果、障害対応の遅さや改修費の上振れで、結局は高くつくことになります。評価軸を事前に設計し、価格配点を意図的に抑えることが、長く付き合える相手を選ぶコツです。
価格配点の抑制と、体制・実績・SLA順守力の重視
評価軸を設計するときは、価格の配点を全体の3〜4割程度に抑え、残りを体制・実績・SLA順守力・コミュニケーションといった非価格要素に振り分けるのが定石です。
運用保守は人月単価60万〜150万円の専門人材が継続的に関わる業務であり（出典：ripla）、極端に安い提案は、待機要員を薄くしているか、多重下請けで品質管理が行き届いていない可能性があります。
価格だけで選ぶと、いざ障害が起きたときに対応できる人がいない、という事態を招きかねません。
とくに、責任分界点や想定外費用の扱いをどれだけ誠実に提案に書き込んでいるかは、そのベンダーの信頼性を測る良い指標になります。
価格の安さに目を奪われず、「長期で安心して任せられるか」という観点で評価軸を組むことが、運用保守のRFPでは決定的に重要です。
具体的な評価項目は、体制と実績・SLA順守の二つの面に分けて配点します。
- 体制：24時間対応の体制があるか、障害時のエスカレーション体制が明確か
- 実績とSLA順守：類似システムの運用保守実績があるか、SLA未達時のペナルティを受け入れる姿勢があるか
提案での想定外費用の扱いの明示
RFPで意図的に問うべきなのが、想定外費用の扱いです。契約時には想定しきれない事象が、必ず発生します。
たとえば、OSSの脆弱性対応、緊急のデータ復旧、クラウド事業者の障害に伴う臨時対応などがあります。これらをどう扱うかを提案で明示させることで、契約後の費用トラブルを大幅に減らせます。
逆に、想定外費用について何も触れない提案は、契約後に高額な追加請求を出してくるリスクがあります。
想定外費用の扱いをどう示すかは、ベンダーが運用の実態を理解しているかを映す鏡でもあります。
riplaはフルスクラッチ受託と国内運用保守の立場から、責任分界点と想定外費用を最初に正直に整理し、発注側が安心して長期委託できるRFP対応を重視しています。
評価軸に想定外費用の扱いを入れておくと、RFPの完成度が高まります。
提案の中身は、費用の扱いと事前の見通しの二つで比べると整理しやすくなります。
- 費用の扱い：月額に含めるのか、都度見積とするのか、上限を設けるのか
- 事前の見通し：都度見積の場合は概算レンジを事前に示す、年間で一定の予備工数枠を確保する
移管・出口を見据えた要件のRFPへの織り込み
運用保守のRFPで、もう一つ忘れてはならないのが、契約の「出口」を見据えた要件です。運用保守は長期にわたるため、いつかはベンダーを乗り換える可能性があります。
そのときに困らないよう、ドキュメントの整備義務やソースコードの著作権、移管支援の条件をRFPの段階で要件化しておくことが、将来のベンダーロックインを防ぐ布石になります。
多くの発注側は入口の品質ばかりに目を奪われ、出口の設計を後回しにした結果、抜け出せなくなります。
出口の要件は、いざ乗り換えるときだけでなく、現ベンダーとの日常的な交渉力にも効いてきます。移管できる選択肢を発注側が確保していると分かっているベンダーは、保守費の値上げや改修の引き延ばしに対しても誠実に向き合わざるを得ません。
逆に、出口を設計していない発注側は、不満があっても抜け出せず、言い値で契約を続けることになります。出口の要件化は、移管のためというより、長く対等な関係を保つための備えなのです。
ドキュメント整備と著作権の帰属の要件化
RFPには、運用保守の過程で発生するドキュメントの整備と納品を要件として明記します。
これらが揃っていれば、いざ別のベンダーに移管するときも、新ベンダーが短期間でキャッチアップでき、二重コストや移管期間の長期化を防げます。
逆にドキュメントを要件化していないと、運用の実態がベンダーの頭の中だけに蓄積され、社内はブラックボックス状態になります。
あわせて、ソースコードや成果物の著作権の帰属も要件として示しておくことが重要です。
著作権がベンダー側に残る契約だと、移管時に「これは当社の著作物だから渡せない」と主張され、乗り換えが法的な泥沼に発展します。
RFPの段階で著作権の条件を提示しておけば、後の法的なロックインを構造的に防げます。
出口の自由度を入口で確保することが、長期の運用保守で発注側が交渉力を保つ唯一の方法です。
RFPに書く条件は、ドキュメントと著作権の二つに分けて示します。
- ドキュメント：設計書や運用手順書、監視設定などを、定められた頻度で最新化し、求めに応じて開示する
- 著作権：ソースコードの著作権は発注側に帰属させる、または少なくとも移管に必要な範囲で開示させる
移管支援と引き継ぎ期間のRFPでの担保
RFPには、契約終了時の移管支援についても要件を盛り込みます。
これを契約に含めておかないと、いざ乗り換えるときに現ベンダーが非協力的になり、引き継ぎが進まなくなります。その結果、旧ベンダーへの保守費と新ベンダーのキャッチアップ費用が重なる二重コストが発生します。
移管支援の有無は、長期の運用保守コストを左右します。
さらに、最低契約期間と解約予告期間、自動更新の条件もRFPで確認しておくべき項目です。最低契約期間が長すぎたり、解約予告が半年前などと厳しすぎたりすると、不満があっても身動きが取れなくなります。
出口の条件を入口のRFPで定義しておくことが、運用保守における発注側の自由度を守ります。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、作った後も継続して伴走する立場から、ソースコードや成果物の権利関係を明確にし、移管時にも発注側が困らない誠実なRFP対応を重視しています。
入口と出口の両方を要件化してこそ、RFPは長期にわたって発注側を守る道具になります。
移管支援の条件は、引き継ぎへの協力と、そのための工数に分けて書きます。
- 引き継ぎへの協力：契約終了の◯か月前から、新ベンダーへの引き継ぎに協力する
- 引き継ぎの資料と工数：引き継ぎに必要な資料を提供し、質疑対応の工数を確保する
想定外費用と予備工数枠の要件化
移管・出口の要件と並んで先回りしておきたいのが、想定外費用への備えです。OSSの脆弱性対応、データ復旧、クラウド側の障害に伴う臨時対応などは、契約時には金額を見積もりきれませんが、確実に発生します。
RFPで扱いを提案に明示させておけば、運用開始後に高額な追加請求で慌てる事態を防げます。
想定外費用をどこまで具体的に示せるかは、ベンダーが運用の実態を理解しているかを測る材料にもなります。
軽微改修が保守費の10〜15%、障害対応が25〜35%という内訳の目安（出典：ripla）を踏まえ、これらを超える緊急対応の精算方法も要件として固めておきます。
入口の品質・出口の自由度・想定外費用の三つを要件で先回りすることで、RFPは契約後の不意打ちを構造的に減らし、発注側が予算と主導権の両方を守れる設計になります。
RFPには、予備工数枠と超過時の扱いを盛り込むよう求めます。
- 予備工数枠：年間で一定の工数枠を確保し、想定外の緊急対応はその枠から充当する
- 超過時の扱い：枠を超える場合は、事前に概算レンジを提示する
まとめ
IT運用保守のRFP・要件定義書で押さえるべきは、四つの柱です。
第一に、クラウド・SaaS・AIの責任共有を前提とした責任分界点の定義と、契約形態（準委任／請負）の指定です。
第二に、稼働率99.9%・初報応答15分・全画面3秒以内といったSLAと非機能要件の数値化です。
第三に、現場の曖昧な要望を測定可能な要件へ翻訳することです。
第四に、価格配点を抑えて体制・実績・SLA順守力・想定外費用の扱いを重視する評価軸の設計です。
これらをRFPに盛り込めば、提案が横並びで比較でき、契約後のトラブルを構造的に減らせます。
運用保守のRFPは、発注側が主導権を握って数値と責任範囲を定義してこそ、実効性を持ちます。
責任分界点と想定外費用を最初に正直に言語化させ、SLAを努力目標ではなく保証として引き出すことが、長く安心して任せられる委託の出発点です。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、開発した後も継続して伴走する立場から、こうした現実的なRFP・要件定義づくりを支援します。
費用相場や契約形態の詳細は、あらためて完全ガイドをご確認ください。
▼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を創業。