RFP（提案依頼書）の書き方｜見積もりの精度を決める7項目とテンプレート

RFP（提案依頼書）の書き方を調べている方の多くは、「項目の抜けをなくしたい」と考えています。ただ、発注側にとってRFPの本当の役割は、項目を埋めることではありません。RFPに何をどこまで書いたかが、ベンダーから返ってくる見積もりの精度を決めます。 この記事は、その因果関係を一次資料で確認しながら、実際に書けるところまで進めるための手順書です。

この記事の結論｜RFPの完成度と、返ってくる見積もりの種類は連動している

先に結論を書きます。

同じRFPを出しても、書かれている内容の詳しさによって、ベンダーが出せる見積もりの種類が変わります。 そして、どの段階でどの見積もりが出るかは、感覚論ではなく公的なモデル契約書に明記されています。

IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」〈第二版〉は、開発の見積もりを次の4段階に整理しています。この記事の出発点はここです。

出典は後述の「根拠資料と適用条件」にまとめていますが、モデル契約書は明確にこう書いています。「システム化の方向性、システム化計画、要件定義の各フェーズにおけるシステム開発の見積は、『確定見積』ではない」。

この一文が、RFP実務でいちばん誤解されている点です。要件定義書を添えてRFPを出しても、返ってくるのは「概算見積」であって「確定見積」ではありません。 原典の表現では「研究会では、画面や帳票などのインターフェースを決定する外部設計のフェーズで『確定見積』が可能と考え」たとされます。確定見積が成り立つのは、この外部設計のフェーズです。

外部設計が発注側の承認を受けた後は、要件追加・仕様変更・未確定事項の確定が生じた場合に、変更管理手続に沿って「追加・再見積」を含む契約変更を行う、というのが原典の建て付けです。承認は「確定見積が出せるようになる条件」ではなく、「ここから先の変更は手続に乗せる」という境界線だと理解してください。

したがって、RFPを書くときの目標は「1回で確定金額を引き出すこと」ではありません。いま自分がどの段階にいるかを自覚したうえで、その段階で出せる最良の精度の見積もりを、全社から同じ条件で引き出すことです。この記事はそのための書き方を扱います。

この記事が扱う範囲と、扱わない範囲

RFPは前後の工程と地続きなので、役割分担を先に示しておきます。

• 本記事が扱うのは、発注前にベンダーへ渡す文書を書き、見積もりを受け取るまでです。RFPの記載事項、項目テンプレート、RFPの書き方が見積もり精度に及ぼす影響、提案書を受け取った後の確認質問までを扱います。
• 要件定義そのものの進め方（誰が何を決め、どう合意形成するか）は本記事の範囲外です。AI・生成AIを含む要件定義の手順はAIシステム開発の要件定義ガイドにまとめています。
• 複数社から届いた見積書を横並びで比較する手順も範囲外です。比較表テンプレートや赤旗の見分け方は開発会社の見積もり比較ガイドが担当します。
• 金額レンジそのもの（この規模ならいくらか）はシステム開発の費用相場と見積もり妥当性の判断にあります。

本記事は「書いて、渡して、返ってきた見積もりの前提を読む」ところに絞ります。

RFPとは何か｜提案依頼書・RFI・要件定義書・調達仕様書の違い

RFPは Request For Proposal の略で、日本語では提案依頼書と呼ばれます。システム開発や業務委託を外部に依頼するとき、発注側が書いて、発注先候補のベンダーへ渡す文書です。ベンダーが書く「提案書（プロポーザル）」とは向きが逆であることが出発点になります。

混同されやすい4つの文書を、誰が書き、何のために使うかで整理します。

RFIで何を聞けるか

デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（DS-100）は、RFIを要件定義の準備に位置づけ、「要件定義の検討に際し、専門的な知見を広く取得するため、必要に応じて」実施するものとしています。説明書に書く事項は4つです。

1. 調達の概要
2. その時点における検討内容、要件定義案の概要等
3. 資料提供を求める内容等
4. 提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等

発注側にとって重要なのは3つ目です。DS-100はここに「要件定義案の実現性、実現方法、それらの要件を実現するために必要な経費及び要員の見込み、要件定義案への修正事項（開発方式、開発手法）」を求めると書いています。要件が固まる前でも、費用と要員の見込みは聞いてよいということです。予算枠を置く段階でいきなりRFPを出す必要はありません。

RFPは1回とは限らない

モデル契約書は、RFPを次の2種類に分けています。「RFPは、大きく分けて、①システム化の方向性、システム化計画を実施するためのものと、②要件定義以降に実施するものの2つに分類される」。

①は要件が固まりきる前に出すRFPで、原典も「未確定の事項があるかもしれない」と認めています。②は要件定義以降のRFPで、こちらには「ユーザがどのようなシステム、何ができるシステムを作りたいかを明確にした要件定義をRFPに表現する必要」があるとされます。

つまり、要件が固まっていないからRFPを出せない、という理解は正しくありません。 ①の段階のRFPを出し、返ってきた仮試算見積や試算見積を使って社内の意思決定を進め、要件定義を経て②のRFPを出し直す——これが原典の想定する流れです。1本のRFPで最初から最後まで進めようとするから、精度の合わない見積もりが返ってきます。

政府調達では「調達仕様書」と「提案依頼書」が別々の文書になる

民間のRFP解説記事があまり触れない構造があります。DS-100では、総合評価落札方式による調達を行うとき、発注側が作る文書が2つに分かれます。

調達仕様書側の11項目は、ア 調達案件の概要／イ 調達単位・調達の方式／ウ 情報システムに求める要件／エ 作業の実施内容／オ 作業の実施体制・方法／カ 遵守事項／キ 成果物の取扱い／ク 入札参加資格／ケ 再委託／コ その他特記事項／サ 附属文書です。提案依頼書側の4項目は、ア RFPの内容／イ 提案手続／ウ 評価基準／エ 審査手法です。

このうち「ウ 評価基準」について、DS-100は「例えば、次の[1]から[8]までに掲げる事項について的確に評価ができ」るよう評価事項を定めるとして、8つを例示しています。[1] 制度、業務及び情報システムに対する理解度／[2] 要件定義の理解度／[3] 任意で提案を求める事項に対する充足度／[4] プロジェクトの計画能力／[5] プロジェクトの管理能力／[6] 設計・開発等に関する技術的能力／[7] 設計・開発等の実績／[8] 組織的対応力。あくまで例示であって、この8つに限定する趣旨ではありません。

民間企業が「RFP」と呼んでいる1冊は、この2つを束ねたものです。ここが実務上の落とし穴になります。多くのRFPは前者（何を作ってほしいか）だけを厚く書き、後者（どう評価するか、何を提出してほしいか）が薄い。すると各社が別々のフォーマット・別々の粒度で提案書と見積書を出してくるため、届いた時点で横並びにできません。比較できない見積もりが集まるのは、要件の書き方ではなく評価基準の書き忘れが原因であることが多いという点は、発注側が最初に押さえるべきことです。

なお、DS-100は政府情報システムの整備・管理に関するルールとして定められた文書です。入札参加資格や意見招請といった手続そのものは民間企業に適用されるものではありません。ここでは「発注文書の設計として真似できる部分」を取り出しています。適用条件は後述します。

実際のRFPには、こう書かれている

理想の項目リストの前に、現実のRFPがどう書かれているかを見ておきます。RFPで金額差を生んでいるのは、たいてい「書いていない項目」ではなく、書いてあるのに解釈が割れる1行です。

実務でよく見かける4つの書き方と、各社がそれをどう読むかを並べます。4行のうち「セキュリティには万全を期すること」はモデル契約書の別紙2が実際に挙げている例で、残る3行と読み方の列は本記事の作例です。

どの行も、RFPとしては「書いてある」状態です。それでも金額が揃わないのは、その語が指す作業範囲を決めていないからです。モデル契約書の別紙2が、「セキュリティには万全を期すること。」という条件をベンダーに示すだけでは、発注側のセキュリティ基本方針や他システムのセキュリティ環境を明示しない限り「当該システムのセキュリティの確保は出来ない」と、まさにこの例を挙げて注意しているのは示唆的です。

RFPの項目を「埋める欄」ではなく「見積もりの変数」として見る——次のセクションからは、この視点で7項目を順に見ていきます。

RFPの記載事項7項目｜モデル契約書の別紙が定める骨格

IPAのモデル契約書は、別紙で「提案依頼書（RFP）の詳細」を定義しており、記載すべき基本項目を7つに整理しています。解説メディアが挙げる項目数は各社の整理でばらつきますが、こちらは公的なモデル契約書に紐づく骨格です。

ここでは7項目それぞれについて、その項目が見積もりのどこを決めるのかを添えます。

(1) システムの概要（基本方針）

システム化の目標・方針、狙いとする効果、運用対象者、既存システムとの関連を書きます。

原典が特に強調しているのは運用対象者です。「システムを運用管理する人やシステムを日常的に利用し操作する人が専任なのか、不慣れな人なのか、また同時に何人がこのシステムを利用するのか等を明示する」とあります。

見積もりへの影響：利用者が不慣れかどうかは、画面設計の作り込み・マニュアル・教育の工数に直結します。ここが空欄だと、A社は「情シスが使う前提」で薄く、B社は「現場のパート社員が使う前提」で厚く見積もります。結果として金額が大きく開いても、それが提案力の差なのか前提の差なのか判別できません。同時利用者数は性能要件とインフラ費に直結します。

(2) 提案依頼手続き

説明会の日程、対応窓口、提供する資料、参加資格条件、提案手続き、ベンダー選定方法の6つです。

ここでいう提案手続きとは、今回の提案書や見積書の提出によって即刻業者選定を実施するのか、まず第1次審査で提案の意志や技術を確認し、提案要求をさらに詳細にしたうえで再度提案依頼を出すのか——という段取りのことです。原典もこの2通りを並べています。

見積もりへの影響：1回で決めると宣言されたRFPと、2段階で絞ると宣言されたRFPでは、ベンダーが1次提案にかける工数が変わります。前者では各社が保守的にバッファを積み、後者では概略に留めます。段取りを書かないと、この差が金額に紛れ込みます。

(3) 依頼事項

原典は「RFPの中核をなすもので、ベンダが責任を持って見積りを出すのに十分な要件として、機能要件だけでなく非機能要件も明らかにする必要がある」と位置づけています。

機能要件は3つの切り口で整理されます。

• プロセス：機能情報関連図、業務流れ図、業務処理定義書、システム機能関連図
• データ：概念ER図、データ項目定義書
• インターフェース：システム間関連図、システム間インターフェース定義書、画面・帳票一覧表、画面・帳票レイアウト

非機能要件は6分類です。①品質要件 ②技術要件 ③運用・操作要件（SLA・BCPを含む）④移行要件 ⑤付帯作業 ⑥その他（電力量、作業環境、フロア面積など）。

なお、この機能要件3分類・非機能要件6分類は、モデル契約書が『経営者が参画する要求品質の確保〜超上流から攻めるIT化の勘所〜』（編者：IPA）から引いたものである旨が、別紙2に明記されています。後述する原理原則17ヶ条と同じ書籍が出所です。

加えて、依頼事項には次の個別項目が並びます。システム化の依頼範囲／依頼内容・業務の詳細／システム構成／納期／必要な技術・技術者の資格／成果物・納入物／修整プロセスへの参加（企画から保守までのプロセスの共通枠組みである「共通フレーム」を、自社の案件に合わせて取捨選択・調整する作業にベンダーが加わるかどうか。工程の抜けや過剰がここで決まり、見積もりの工程数に出ます）／共同レビュー／工程計画／開発推進体制。

このうち「システム化の依頼範囲」について、原典は「特に、範囲外の部分については詳細を明示する」と書いています。含むものより、含まないものを書けという指示です。

見積もりへの影響：範囲外を書かないと、各社が自社に有利な線引きで見積もります。データ移行を範囲外と解釈した会社だけが安く見え、契約後に移行費が追加で乗ります。「含むもの」を10行書くより、「含まないもの」を3行書くほうが金額差は縮みます。

(4) 開発体制・開発環境

役割分担、作業場所、開発機器・使用材料費の負担、貸与物件・資料の4つです。

役割分担について原典は、「ユーザとベンダ双方の作業進捗や費用負担の責任を明確にするため、作業推進の工程毎に発生する各種作業のそれぞれの役割や完了時期を明示する」としています。責任者名だけでなく、機能要件・非機能要件それぞれの担当者名まで明示することを求めています。

見積もりへの影響：発注側が受入テストを担うのか、ベンダーが担うのかで、テスト工程の見積額はまったく変わります。ここを書かずに「テスト費が安い会社」を選ぶと、実際には自社の担当者が相当な時間を負担することになります。金額表に現れない費用がここで発生します。

(5) 保証要件

システム、品質保証基準、システムの性能、セキュリティ、デモ・テスト計画の5つです。原典は品質保証基準について「ソフトウェア・ハードウェア・ネットワークの機能や性能の保証基準」に加え、「文書類の記述方法の基準や標準等があれば、それら基準を具体的に明示する」ことまで求めています。

見積もりへの影響：無償保証期間をRFPで指定しないと、各社がそれぞれの標準（1か月／3か月／6か月など）で見積もります。保証が長い会社は、その分の要員待機コストを見積もりに含めています。同じ条件へそろえない限り、総額の比較は成立しません。

品質保証基準を書かないと、検収の場で「どこまで直せば完了か」が決まらず、最後の期間が無償対応の押し付け合いになります。原典は別の項目（成果物・納入物）で「特に文書類は、記述方法・記述の詳細さ・印刷等で作業工程が大きく変わる場合がある」とも書いており、所定の書式かベンダー側の書式で可かによって作業量が動きます。提案時のデモを求めるかどうかも金額に出ます。デモを必須にすると各社の提案工数が上がり、その分が提案価格に乗るか、小規模なベンダーが辞退します。

(6) 契約事項

発注形態と、契約書に盛り込むべき重要事項です。原典は後者について、「契約類型（準委任／請負）、再委託、損害賠償責任（範囲・限度額・期間）、知的財産権の帰属、第三者ソフトウェアの利用、検収・支払い条件等について、これらの条件、あるいは要求について予め明らかにしておく」と列挙しています。

見積もりへの影響：契約類型は見積もりの単位そのものを変えます。請負なら総額、準委任なら単価×期間になるため、契約類型を書かないRFPには、そもそも比較できない形の見積もりが返ってきます。詳しくは請負と準委任の違いは見積書のどこに出るかを参照してください。知的財産権の帰属も同様で、ソースコードと設計書の納品を求めるかどうかは金額に反映されます。将来の保守会社の切り替えを想定するなら、ここは必ず指定してください。

(7) その他

用語、外部委託に関する管理、リスクに対する相互認識、仕様変更・機能追加等の条件の4つです。

原典は仕様変更について、「大きなシステム開発に関しては、開発契約締結後にシステム仕様の補正（機能追加）や仕様変更等が生じるので、これを管理する変更管理プロセスを契約書において明示する」と書いています。変更が起きることを前提にした手続を、RFPの段階から明示しておけという指示です。

見積もりへの影響：変更管理の手続がないRFPには、「変更が起きたら都度相談」という提案が返ってきます。この状態で契約すると、変更のたびに交渉が発生し、そのつど金額が積み上がります。

見積もりの精度を落とすのは、たいてい「書かれなかった非機能要件」

RFPの項目が抜けたとき、金額は必ずしも上がりません。むしろ下がります。 書かれていない要件は、ベンダーの見積もりからも落ちるからです。安い見積もりが届いたときに最初に疑うべきなのは、値引きではなく、要件の脱落です。

デジタル庁のDS-100は、非機能要件をa）からr）までの18分類で定義しています。この18項目は、民間のRFPでも抜けチェックの表としてそのまま使えます。右列は原典の記述ではなく、本記事の実務上の見立てです。

太字にした m〜r の6項目は、開発費の見積もり比較では特に抜けやすく、かつ稼働後の費用に直結します。RFPにこの6項目の記載がないまま届いた見積もりは、安くて当然です。

DS-100は要件定義書について、「定義の時点において、未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにするものとする」と定めています。これはRFPにもそのまま応用できます。未確定の項目を空欄で渡すのではなく、「未確定」と明記して渡す。空欄は各社が黙って補完しますが、「未確定」と書けば、各社は自社の前提を提案書に書かざるを得なくなり、前提の差が読める形で返ってきます。

そのままベンダーへ送れるRFP項目テンプレート

ここまでの7項目と非機能要件18分類を、そのまま送れる形にしたものです。

番号1・2と4〜8がモデル契約書の記載事項7項目に対応します。 3（評価基準）はDS-100の提案依頼書側から、9（提出要件）は本記事の追加です。

記法は3種類です。[ ] は記入欄、☐ は選択肢、〔 〕 は送付前に削除する社内メモです。埋まらない項目は消さずに「未確定」と書いて残してください。

=========================================
提案依頼書（RFP）：[プロジェクト名]
=========================================
〔記法：[ ]＝記入欄／☐＝該当に印／〔 〕＝送付前に削除する社内メモ〕

発行日：[発行日]／発行者：[会社名・部署名]
本RFPの段階：☐ 構想・計画段階（試算見積を依頼）／☐ 要件定義完了後（概算見積を依頼）

-----------------------------------------
1. システムの概要（基本方針）
-----------------------------------------
- システム化の目標・方針：[現状の課題と、何を変えたいか]
- 狙いとする効果：[定量目標があれば数値で]
- 運用対象者：[運用管理する人／日常的に操作する人／専任か兼任か／同時利用者数]
- 既存システムとの関連：[現行機器構成、扱うデータの種類・量・処理サイクル、技術的制約]

-----------------------------------------
2. 提案依頼手続き
-----------------------------------------
- スケジュール：説明会[日時]／質問期限[日時]／提案書提出期限[日時]／
  ヒアリング[日時]／決定[時期]
- 対応窓口：[部署・氏名・連絡先]。質問はすべて書面で受け、
  回答は全社へ同時に共有します
- 提供する資料：[資料名]。機密区分：[社外秘／要返却の有無]
- 参加資格条件：[認証・実績・体制などの要件があれば]
- 提案手続き：☐ 今回の提案書・見積書で選定
              ☐ 第1次審査後に要求を詳細化して再提案を依頼
- ベンダー選定方法：[決定機関、決定までのプロセス]
- 予算の目安：[上限額（税抜／税込を明記）]。この範囲に収める前提での
  機能の優先順位づけを提案に含めてください
  〔モデル契約書の記載事項7項目には含まれない。本記事の推奨として追加〕

-----------------------------------------
3. 評価基準（提案書に必ず反映してください）
-----------------------------------------
〔DS-100が例示する評価事項8つを、民間のRFP向けに翻案したもの。配点は自社で決める〕
| 評価事項 | 配点 | 評価の観点 |
|---|---|---|
| 業務・システムへの理解度 | [配点] | 現状課題の把握と、提案との対応 |
| 要件への充足度 | [配点] | 必須要件の実現方法と根拠 |
| プロジェクトの計画能力 | [配点] | 工程・スケジュール・前提条件の妥当性 |
| プロジェクトの管理能力 | [配点] | 進捗・課題・変更の管理方法 |
| 技術的能力 | [配点] | 採用技術の選定理由 |
| 類似実績 | [配点] | 同規模・同業種の実績 |
| 組織的対応力 | [配点] | 要員構成、再委託の有無、交代時の体制 |
| 価格 | [配点] | 見積根拠の説明可能性を含む |

-----------------------------------------
4. 依頼事項
-----------------------------------------
■ 4-1. システム化の依頼範囲
- 含むもの：[対象業務・対象機能]
- 含まないもの：[範囲外]
  〔含むものより先に書く。ここが空だと各社が自社に有利な線引きで見積もる〕
- 未確定：[この時点で決まっていない範囲]

■ 4-2. 機能要件
- プロセス：[業務の流れ／添付：業務フロー図]
- データ：[扱うデータと項目／添付：データ項目一覧]
- インターフェース：[連携先システムと連携本数／画面・帳票の一覧]

■ 4-3. 非機能要件 〔記入がない項目は空欄にせず「未確定」と書く〕
★は記入が抜けると見積もりからも落ちやすい6項目です。

| 分類 | 当社の要求 |
|---|---|
| ユーザビリティ及びアクセシビリティ | [ ] |
| システム方式（クラウド／自社サーバー） | [ ] |
| 規模（データ量・利用者数） | [ ] |
| 性能（応答時間・同時接続数） | [ ] |
| 信頼性（冗長化の要否） | [ ] |
| 拡張性 | [ ] |
| 上位互換性（OS・ミドルウェア更新） | [ ] |
| 中立性（特定製品への依存） | [ ] |
| 継続性（復旧目標・BCP） | [ ] |
| 情報セキュリティ | [ ] |
| 情報システム稼働環境（サーバー・回線・端末） | [ ] |
| データマネジメント | [ ] |
| ★ テスト（範囲と合格基準） | [ ] |
| ★ 移行（対象・件数・品質・リハーサル） | [ ] |
| ★ 引継ぎ（資料・権限・第三者保守の可否） | [ ] |
| ★ 教育（研修・マニュアル） | [ ] |
| ★ 運用（稼働時間・監視・報告） | [ ] |
| ★ 保守（対応範囲・費用） | [ ] |

■ 4-4. その他の依頼事項
- 納期：[導入時期／試験時期／並行稼働／本番]
- 成果物・納入物：[文書類の書式指定の有無を含む]
- 共同レビュー：[節目と、当社が参加するレビュー]
- 工程計画：[当社側のチェックポイント時期／会議体の頻度と方法]

-----------------------------------------
5. 開発体制・開発環境
-----------------------------------------
- 役割分担：[工程ごとに、当社が行う作業とベンダーが行う作業／各担当者]
- 作業場所：[常駐の要否／会議室・設備の提供可否]
- 開発機器・材料費の負担：[どちらが負担するか]
- 貸与物件・資料：[貸与物と機密保持・返却条件]

-----------------------------------------
6. 保証要件
-----------------------------------------
- 保証期間：[ ]か月（無償保証の範囲を明記）
- 品質保証基準：[受入基準／文書類の記述方法の基準]
- 性能：[応答性・信頼性・安全性の保証水準]
- セキュリティ：[機密性・完全性・可用性の要求と、障害時の対応]
- デモ・テスト計画：[提案時のデモの要否]

-----------------------------------------
7. 契約事項
-----------------------------------------
- 発注形態：[基本契約＋個別契約／一括／分割]
- 契約類型：[請負／準委任]（工程ごとに指定）
- 再委託：[事前承諾の要否]
- 損害賠償責任：[範囲・限度額・期間の考え方]
- 知的財産権の帰属：[ソースコード・設計書の扱い]
- 第三者ソフトウェア・OSSの利用：[許容範囲と、ライセンス条件の開示要求]
- 検収・支払い条件：[検収基準／支払時期]

-----------------------------------------
8. その他
-----------------------------------------
- 用語：[本RFPで用いる用語の定義]
- 外部委託の管理：[再委託先の事前通知の要否]
- リスクに対する相互認識：[新技術の適用、仕様確定の遅れなど、想定するリスク]
- 仕様変更・機能追加の条件：[変更管理の手続と、再見積もりの取り扱い]

-----------------------------------------
9. 提案時に必ず提出してください
-----------------------------------------
1. 見積書（工程別に、工数・役割・単価・金額・成果物を分けて記載）
2. 本見積もりが、仮試算・試算・概算・確定のどの段階にあたるかの明記。
   あわせて、確定見積を提示できるのはどのフェーズの完了後か
3. 見積もりの前提とした条件、および除外した範囲の一覧
4. 本RFPで「未確定」と記載した項目について、貴社が置いた前提
5. 本件の作業のうち、当社（発注側）が実施する前提としている作業の工程別の一覧
6. 想定するリスクと、その対応方針

※ 提案書は、本RFPの項番（1〜8）に対応させて記載してください。
   対応しない項番がある場合はその旨を明記してください。

このテンプレートの「9. 提案時に必ず提出してください」は、後から効いてきます。前提と除外範囲を書面で出させておくと、届いた見積もりの金額差が「提案の差」なのか「前提の差」なのかを、その場で切り分けられます。項番を対応させる指定も同じ狙いで、これがないと各社の提案書が別々の構成で届き、比較の前に整形作業で消耗します。

なお、発注側が書く「含まないもの」（4-1）と、ベンダーが返す「除外した範囲」（9-3）は方向が逆の情報です。この2つを突き合わせて一致しない箇所が、そのまま追加費用の候補になります。

ベンダーが確定額を出さないのは、正当なケースが多い

RFPを送って「現時点では確定額を出せません」と返ってきたとき、それは必ずしも逃げではありません。むしろ原典に沿った回答であることのほうが多い、というのがこの記事の立場です。

• 外部設計より前の段階で確定見積を出せないのは、モデル契約書の建て付けどおりです。前掲のとおり、要件定義フェーズで受け取れるのは概算見積です。この段階で確定額を約束するベンダーは、後で変更管理に持ち込むか、リスク分を厚く積んでいるかのどちらかである可能性が高い、と見ておくのが安全です。
• 概算見積の段階で非機能要件が固まりきらないことにも、原典が理由を挙げています。 「ユーザが提示した要件定義をベンダが外部設計を行っている段階で発生する要件もある」とし、性能要件や運用のSLA要求事項の詳細、セキュリティ・障害対策などが設計の過程で新たに出てくる場合があると書いています。
• 保証期間が長い会社の見積もりが高いのも、多くは正当です。保証は要員の待機コストを伴うため、条件をそろえずに総額だけを比べると、責任範囲を薄くした会社が有利に見えます。

つまり、金額が揃わないとき、それはベンダー側の問題ではなく前提条件が揃っていないことの結果であることが少なくありません。既存の提案が合理的だという結論も、十分にありえます。

RFPに書いただけでは、契約内容にはならない

これはRFP解説記事でほとんど触れられない一方、経営判断としてはもっとも重い論点です。

IPAのモデル契約書は、基本契約と個別契約が当事者間の合意のすべてであるという完全合意の考え方を採ったうえで、解説にこう明記しています。「例えばユーザから提示されたRFPの内容であっても本契約及び個別契約において規定されていない場合、当事者間の契約内容とはならない」。

つまり、RFPにどれだけ丁寧に非機能要件を書いても、それが契約書または個別契約に落ちていなければ、法的には約束されていないということです。「RFPに書いたはずだ」という主張は、契約に反映されていない限り通りません。

では何を契約に落とすのか。モデル契約書は個別契約について、こう定めています。「甲及び乙は、個別業務に着手する前に、甲から乙に提示された提案依頼書（RFP）及び乙から甲に提案した提案書、見積書を基礎として、当該個別業務について以下の各号のうち必要となる取引条件を定め、個別契約を締結する」。

その各号は12あります。

1. 具体的作業内容（範囲、仕様等）
2. 契約類型（請負・準委任）
3. 作業期間又は納期
4. 作業スケジュール
5. 発注者・受注者の役割分担（第8条で定める作業責任分担の詳細）
6. 連絡協議会の運営に関する事項
7. 発注者が受注者に提供する情報、資料、機器、設備等
8. 作業環境
9. 納入物の明細及び納入場所
10. 委託料及びその支払方法
11. 検査又は確認に関する事項
12. その他個別業務遂行に必要な事項

条文が「以下の各号のうち必要となる取引条件」と書いているとおり、工程によって必要な号は異なります。すべてを毎回埋める趣旨ではありません。ただ、RFPに書いた重要事項が、この12号のどこにも入っていないなら、それは合意されていないと考えるのが安全です。

モデル契約書は、一社に全工程を発注する場合も含め、工程ごとに個別契約を締結する多段階契約方式を採っています。解説には「基本契約たる本契約に基づき、各工程別に、ユーザとベンダの責任と役割分担を明確にした個別契約を締結するという多段階契約方式を採用している」とあります。RFPを1本出して全工程の総額を一度に確定させる形は、この建て付けの想定ではありません。

第二版では、プロジェクトマネジメント義務や協力義務を条項として追記することは見送られ、代わりに裁判例で問題となったケースを関連する条項・箇所で紹介して注意喚起する扱いになりました。検討の過程では、役割分担を定めた第8条や連絡協議会を定めた第12条など、各条項のプロセスを適切に運用すれば義務違反が問題となる事案は一定程度防げるのではないかという意見が出されています（これは検討過程で出された意見であり、モデル契約書の結論として断定されているものではありません）。RFPの段階で役割分担と会議体を書いておくことに実務的な意味があるのは、この文脈です。

RFPをベンダーやコンサルに手伝ってもらうときの注意

「自社でRFPを書ける人がいない」という状況は珍しくありません。モデル契約書自身がこの実態を認めています。「中小企業に限らないが、特に中小企業の場合には、ユーザにRFPの作成能力がなく、コンサルタントが作成したり、既存システムを構築したベンダがRFPをユーザに代わって作成したりする場合が多い」。

そのうえで、原典はリスクを具体的に書いています。「この場合、RFPを記述したベンダしか分からないブラックボックスが機能や要求として存在することがあり、異なるベンダがRFPに基づきシステム開発を請け負った場合に、作業の遅延、費用の大幅な増大といった問題が発生する」。

対処として原典が挙げているのは次の2つです。

1. 責任関係を先に決める。 「RFPの作成ベンダとRFPに基づきシステム開発を行うベンダが異なるときには、RFPに重大な問題があった場合も含めユーザはRFP作成ベンダと後工程を請け負ったベンダとの責任関係を明確にしておく必要がある」
2. 上流の担当者をPMOに残す。 「上流工程やRFPを担当したベンダ、コンサルタントと、開発工程を担当するベンダが異なる場合は、上流工程担当者をプロジェクトマネジメント・オフィス（PMO）に参画させ、上流工程における不具合や、開発工程での齟齬を防ぐことを目的とした契約を検討するべきである」

PMOは、開発の進め方そのものを管理・監視する役回りです。RFPを書いた会社をこの立場で残すと別途の契約と費用が発生しますが、要件の解釈違いによる手戻りを止められる可能性があります。開発費とは別枠の投資として、発注前に金額を確認してください。

もうひとつ、公平性の観点があります。DS-100が政府調達で入札制限をかけている相手は、RFPではなく調達仕様書の作成に関与した事業者です。前述のとおり政府調達では要件を書く文書と提案手続を書く文書が分かれており、制限の対象は前者——民間で言えば、RFPの要件部分を書いた会社に相当します。

原典はこう定めています。「各工程の調達仕様書の作成に直接関与した事業者は、透明性及び公正性の確保の観点から、当該調達案件の入札に参加させないものとする」。ただし但し書きがあり、「競争上何ら有利とならないと認められるときはこの限りでない」と続きます。

民間企業にこの入札制限が適用されるわけではありません。しかし考え方は転用できます。RFPの要件を書いた会社がそのまま受注すると、他社は同じ土俵に立てません。 RFP作成を支援してもらう場合は、その会社が開発フェーズの提案に参加するのかを最初に決め、参加させるなら他社へも同等の情報を開示する、という運用が要ります。

もし要件定義の支援そのものを外部に頼むなら、モデル契約書は「企画・要件定義段階と開発段階とは別契約として契約を締結することが望ましい」としています。開発費を早く確定させたいという理由で上流工程から一括発注すると、この分離ができなくなります。

確認が必要なケース｜RFPの完成度を4状態（説明済み・要確認・高リスク・判断不能）で判定する

RFPを送る前、または送った後で提案が返ってきたときに、状況を4つに仕分けます。「良いRFP／悪いRFP」の二択で見ると、次に取るべき行動が決まりません。

「高リスク」と「判断不能」は見た目が似ていますが、対処がまったく違います。高リスクはRFPの記載不足なので、書き足せば解消します。判断不能は社内の意思決定の未了なので、RFPをいくら精緻にしても解決しません。

この違いは、IPAの「超上流から攻めるIT化の原理原則17ヶ条」にも表れています。17の原理原則の下には合計51の行動規範が置かれ、そのうち33項目が発注者に、25項目が受注者に適用されます（うち7項目は双方に適用）。上流工程で守るべき行動の多くは、ベンダーではなく発注側の仕事として整理されているということです。［4］「ステークホルダ（利害関係者）間の合意を得ないまま、次工程に入らない」も、［16］「機能要求は膨張する。コスト、納期が抑制する」も、発注者側の行動規範を伴います。判断不能の状態は、ここで止まっているサインです。

提案書を受け取った後に、そのまま送れる確認質問7

RFP送付時に依頼する事項は、前掲テンプレートの「9. 提案時に必ず提出してください」に含めてあります。テンプレートを使った場合、同じ依頼を二度送る必要はありません。ここは、提案書と見積書が届いてから送る質問です。そのままコピーして使えます。

1. 「テストの範囲と合格基準、および受入テストをどちらが実施する前提かをご教示ください。」
2. 「既存データの移行について、対象データの種類・件数・品質の前提と、移行リハーサルの回数をご教示ください。移行が見積もり範囲外の場合は、その旨を明記してください。」
3. 「稼働後の運用・保守について、月額費用と対応範囲、および費用が変動する条件をご教示ください。」
4. 「本件で作成されるソースコード・設計書の権利の帰属と、当社への納品範囲をご教示ください。将来、他社へ保守を引き継ぐ場合に必要な資料と権限もあわせてご教示ください。」
5. 「本RFPの記載事項のうち、契約書または個別契約に明記される予定の項目と、明記されない項目を区別してご教示ください。」
6. 「RFP『3. 評価基準』の各項目について、貴社提案のどの箇所が該当するかを対応表でご提示ください。」
7. 「仕様変更が生じた場合の再見積もりの手続と、変更作業に適用される単価をご教示ください。」

5番は、前述の完全合意の論点をそのまま質問にしたものです。この質問への回答は、RFPの記載が実際に効力を持つ範囲を示します。

なお、質問と回答の扱いについて、DS-100には参考になる規定があります。政府調達では、事業者からの提案に重要な影響があると認められる応答内容は、関係するすべての事業者に通知するものとされています。原典が定めているのはこの全社通知までで、書面化と同時共有までは書かれていません。ただ、1社からの質問に1社だけへ回答すると、その時点で条件がそろわなくなります。 質問はすべて書面で受け、回答は全社へ同時に共有する——この運用は、原典の趣旨を民間向けに具体化した本記事の提案です。

根拠資料と適用条件

本記事で数値・条文・項目数の根拠に使った資料です。すべて2026年8月31日に原典を取得して照合しました。

格付けの区別：上記4資料に記載された項目数・分類・条文は、いずれも公的機関が公表した文書の記述そのものです。一方、本記事のうち各項目に付した「見積もりへの影響」と、非機能要件18分類の表の「RFPに書かないと起きること」欄、「実際のRFPには、こう書かれている」の作例と読み方、および「ベンダーが確定額を出さないのは、正当なケースが多い」の判断は、原典の項目から導いた本記事の実務上の見解であり、価格相場の根拠ではありません。この2つは混同しないでください。

また、本記事は特定のベンダーの見積もりが不当であると判断するものではありません。RFPの記載が薄いまま金額差が生じている場合、それは多くの場合ベンダーの問題ではなく、前提条件がそろっていないことの結果です。

書いたRFPと、返ってきた見積書を突き合わせる

RFPを送り、見積書が届いたら、次はRFPに書いた要件が見積書のどの行に対応しているかを確認する作業になります。この突き合わせを飛ばすと、金額だけを見て発注先を決めることになります。

koromoの要件・契約範囲チェック（登録不要）では、手元の見積書について、要件・成果物・契約範囲の記載がどこまで揃っているかを点検し、ベンダーへ送る確認質問の作成まで試せます。見積書のテキスト抽出はブラウザ内で行われ、結果の閲覧までメールアドレスの入力は求められません。

診断は見積書1社分ずつ実行する形式です。相見積もりの場合は各社を個別に点検し、本記事のテンプレートで「未確定」とした項目が、各社の見積もりでどう埋められているかを並べてください。埋まり方の違いが、そのまま前提の違いです。

よくある質問

まとめ

RFPの書き方で最も重要なのは、項目の数を増やすことではありません。

• いまどの段階のRFPなのかを自覚する。 構想・計画段階なら試算見積、要件定義後なら概算見積が返ってきます。確定見積は外部設計のフェーズです。
• 記載事項7項目を骨格にする。 システムの概要／提案依頼手続き／依頼事項／開発体制・開発環境／保証要件／契約事項／その他。IPAのモデル契約書が定める構成です。
• 「何を作るか」と同じ重さで「どう評価するか」を書く。 政府調達では、総合評価落札方式のとき調達仕様書と提案依頼書が別文書になります。評価基準と提出要件が薄いRFPには、比較できない見積もりが返ってきます。
• 空欄ではなく「未確定」と書く。 空欄は各社が黙って補完します。未確定と書けば、各社の前提が提案書に現れます。
• 書かれなかった非機能要件は、見積もりからも落ちる。 テスト・移行・引継ぎ・教育・運用・保守の6項目が抜けた見積もりは、安くて当然です。
• RFPに書いただけでは契約内容になりません。 重要事項は契約書か個別契約へ落としてください。

RFPは、ベンダーを試す文書ではなく、発注側が自分の意思決定の解像度を確認するための文書です。書けない項目が見つかったら、それはRFPの不備ではなく、社内でまだ決まっていないことの発見です。そこが分かれば、次に何を決めるべきかも決まります。