RFP（提案依頼書）の書き方：システム開発向けテンプレートとベンダー選定までの流れ

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo）

RFP（Request for Proposal：提案依頼書）とは、システム開発の発注先候補に「何を・なぜ・どんな条件で」開発してほしいかを伝え、提案を依頼する文書です。発注側が先に決めておく必要があるのは、依頼範囲の境界・必須と希望の線引き・予算の幅・稼働時期・評価基準の5つで、ここが空欄のまま出したRFPは、各社が想像で前提を埋めるため提案を並べて比較できません。

RFPで難しいのは文書の書式ではなく、書くために発注側が決めなければならない判断のほうです。テンプレートの空欄は一般論でも埋まりますが、範囲の境界と優先順位が決まっていないRFPは、提案の金額差が何の差なのか読み取れない状態を招きます。

この記事では、RFPを出す前に決める5つのこと、コピーして使える記載項目のテンプレート、比較できるRFPと比較できないRFPの分かれ目、官公庁の調達基準を踏まえた評価配点の決め方、発出からベンダー選定までの流れ、提案が集まらないときの原因、RFI・RFQとの違い、AI駆動開発の発注で加える確認項目、そしてRFPの作成をどこまで外部に相談してよいかを、発注側の視点で整理します。

RFPを出す前に決める5つのこと

この5つが決まっていれば、返ってきた提案を同じ基準で比較できます。逆に1つでも空欄のまま発出すると、各社が異なる前提で見積もるため、金額の差が「範囲の差」なのか「単価の差」なのか判別できなくなります。

1. 依頼範囲の境界を決める：「今回依頼する範囲」と同じ分量で「今回は対象外とする範囲」を書きます。既存システムの改修は含むのか、データ移行は誰がやるのか、マスタ整備は自社で行うのか。境界が書かれていないRFPは、提案のたびに範囲が違う見積もりが返ってきます
2. 必須の要求と希望の要求を分ける：満たされなければ導入しない条件だけを必須にし、残りは希望として提案に委ねます。すべてを必須にすると、各社は最大構成で見積もるしかなく、「この予算ならここまで」という段階的な提案を引き出せません
3. 予算の幅を決める：確定額は不要ですが、投じられる範囲は決めてください。金額を伏せると、各社は規模感を仮定で置くしかありません（詳細は次項）
4. 稼働を希望する時期と理由を決める：「4月の新年度から使いたい」「法改正の施行に間に合わせる必要がある」など、理由まで書きます。理由があると、間に合わない場合に「先に必須機能だけ稼働させる」といった代替案が提案に含まれます
5. 評価基準と配点を、提案を受け取る前に決める：何を何点で見るかを先に固めます。提案が出揃ってから基準を考えると、印象の強い1社に引きずられた判断になりやすく、社内の合意形成にも時間がかかります

抜けやすいのは1と5です。特に「今回やらないこと」を書く作業は、社内の期待値を揃える工程を兼ねています。利用部門が当然含まれると思っていた範囲が対象外だと分かるのは、提案が出てからではなく、RFPを書いている段階であるべきです。関係部門との擦り合わせを含めた発注準備の全体像はシステム開発の流れ（工程と発注側の役割）で整理しています。

予算はRFPに書くべきか

少なくとも幅は書くことを推奨します。予算を伏せる理由としてよく挙がるのは「金額を先に見せると、そこまで使い切る提案になる」という懸念です。しかし予算が見えない場合、各社は規模感を仮定で置くしかなく、返ってくる提案は前提のばらばらな比較不能なものになります。幅で示せば、各社はその範囲での最適配分を提案でき、「この予算ならここまで、これを足せばここまで」という段階提案も引き出せます。使い切りが心配なら、評価基準に費用対効果の観点を明記するほうが有効です。

幅の置き方が分からない場合は、市場一般の相場から当たりをつけてください。以下は受託開発の一般的な目安で、特定の会社の見積もりを示すものではありません。

予算の幅を出すときは、初期開発費だけで組まないでください。要件定義には全体費用の10〜15%程度がかかり、稼働後の保守運用は月額で継続して発生します。種類別の内訳や見積もりの読み方はシステム開発の費用相場と見積もりガイド、業務システムに絞った費用構造は業務システム開発の費用相場と発注ガイドにまとめています。基幹システムのリプレイスのように既存資産の調査から始まる案件は、費用の構造そのものが異なるため基幹システムのリプレイスを参照してください。

RFPに書くべき項目【コピーして使えるテンプレート】

システム開発のRFPに標準的に盛り込む項目を、そのままコピーして使える形でまとめました。社内の文書ツールに貼り付けて、◯◯を自社の内容に置き換えてください。

■ 1. 依頼の背景と目的
・自社の事業概要：◯◯
・本プロジェクトの背景（現状の課題）：◯◯
・システム化の目的（達成したい状態）：◯◯

■ 2. 現状の業務とシステム
・対象業務の流れ：◯◯（業務フロー図を別添）
・現行システム／ツール：◯◯（画面・帳票サンプルを別添）
・現状の課題と発生頻度：◯◯

■ 3. 依頼範囲（スコープ）
・今回依頼する範囲：◯◯
・今回は対象外とする範囲：◯◯
・将来の拡張構想（参考情報）：◯◯

■ 4. 要求事項
・必須の要求（満たされなければ導入しない）：◯◯
・希望の要求（提案に委ねる）：◯◯
・想定利用者数・データ量・稼働時間などの前提：◯◯
・データ・セキュリティに関する条件：◯◯

■ 5. 予算・スケジュール
・予算の幅：◯◯
・希望する稼働時期とその理由：◯◯

■ 6. 提案してほしい内容
・実現方式と概算見積もり（内訳つき）
・体制と類似案件の実績
・開発の進め方（工程・会議体・生成AIの利用方針を含む）
・運用保守の内容と条件

■ 7. 選定の進め方
・提案書の提出期限／形式：◯◯
・質疑応答の窓口と期間：◯◯
・評価の観点と配点：◯◯
・選定までのスケジュール：◯◯

■ 8. 貸与資料・その他
・貸与できる資料：◯◯
・秘密保持の取り扱い：◯◯
・問い合わせ窓口：◯◯

ただし、テンプレートをそのまま埋めただけのRFPは機能しません。項目を埋めること自体が目的化すると、どの欄も一般論で埋まった「どの会社に出しても同じ」文書になります。自社にとって重要な項目（多くの場合、2の現状課題と4の要求事項）に分量を割き、該当しない項目は削ってください。分量の偏りこそが、そのRFPの個性であり情報です。

要求事項に書く「前提」の決め方

4の要求事項では、使い勝手や画面の要望より先に、利用者数・データ量・稼働時間・応答速度・障害時の許容停止時間といった前提を書いてください。この前提が抜けたRFPは、機能一覧が同じでも各社の想定するシステム構成が変わり、金額が大きくずれます。逆に、ここが具体的に書かれていれば、返ってくる提案の構成が妥当かを発注側でも判断できます。

この種の要求（非機能要求）を自力で洗い出すのは難しいため、既存の枠組みを使うのが早いです。IPA（情報処理推進機構）が公開している「非機能要求グレード」は、非機能要求についての発注者と開発者の認識の行き違いを防ぐことを目的に、要求項目を網羅的に分類し、要求レベルを段階で示した資料です。最新版は非機能要求グレード2018で、無償で公開されています。使い方は次の3段階です。

1. 開発するシステムに最も近いモデルシステムを1つ選ぶ（3つの典型モデルが用意されています）
2. 樹系図で全体を俯瞰し、重要な項目のレベルをグレード表で決める
3. 残りの項目のレベルを項目一覧で決める

全項目を一度に埋める必要はありません。重要な項目だけレベルを決めてRFPに転記し、残りは「提案時に前提を明記してください」と書けば十分です。プロジェクトに応じて編集できる活用シートも公開されているため、社内の合意形成の材料にも使えます。

新規事業やアプリ開発で社内向けの企画書を先に作っている場合、その企画書はRFPの素材になります。背景・目的・ターゲット・ビジネスモデルは企画書から転記し、RFPでは開発の要求と条件を肉付けする、という分担です。企画書の作り方はアプリ開発の企画書の作り方で解説しています。

提案を比較できるRFPと、比較できないRFPの分かれ目

分かれ目は文書の長さではなく、記述が検証できる形になっているかどうかです。NTTデータ経営研究所が2023年に公開したレポート「大規模システム調達成功に向けて」は、RFPの要点として、要件の決定には調達部門・ユーザー部門・システム部門の合意形成が不可欠であること、抽象的な記載は調達の競争性を下げること、評価基準は提案を受け取る前に固めておくことを挙げています。「抽象的な記載が競争性を下げる」とは、要求が曖昧なほど各社はリスクを織り込んだ安全側の提案・見積もりに寄るため、提案の幅も質も縮む、という構造です。

官公庁向けの文書ですが、デジタル庁が2024年に公開した「調達手続マニュアル」も、要件の決定を発注者側の責任として位置づけ、提案を評価する基準を事前に作成する手順を示しています。民間のRFPにもそのまま転用できる考え方です。

これらを裏返すと、比較できないRFPの症状は次のように整理できます。

• 「使いやすい」「柔軟な」「なるべく安く」など、検証できない抽象語で要求が書かれている
• 予算が幅の提示すらなく伏せられており、各社が規模感を想像で決めている
• 依頼範囲の境界（今回やらないこと）が書かれていない
• 要求のすべてが必須扱いで、優先順位がない
• 評価基準が決まっておらず、提案が出揃ってから「どう選ぶか」を考え始める

抽象語を検証できる言葉に直す作業は、機械的にできます。「検索が速いこと」なら「1万件のデータで検索結果が3秒以内に表示されること」、「使いやすいこと」なら「受注登録を現行の12画面から3画面以内で完了できること」。数えられる形に置き換えられない要求は、まだ社内で言語化が終わっていないと判断して、RFPに書く前に整理してください。

提案の評価基準と配点の決め方

評価基準はRFPと同時に作り、RFP本文にも観点を書いてください。各社は評価される観点に沿って提案を書くため、観点を先に伝えるほど、比較したい部分が揃った提案が返ってきます。以下は配点の一例です。

費用と提案内容にどれだけの重みを置くかで迷ったら、官公庁の調達基準が当たりになります。デジタル庁の「調達手続マニュアル概要」（令和4年7月）は、情報システムの総合評価落札方式における配分割合を「価格点1：技術点1、または価格点1：技術点3以内」と定めています。1：3を使えるのは、対象業務の実施方法や内容が複雑かつ多岐にわたる、技術的構造の異なる複数システムと連携する、頻繁な機能改修を伴う——といった要件をすべて満たす場合です。裏返すと、標準的な案件は費用と提案内容を同じ重みで見て、複雑な案件ほど提案内容の側に重みを寄せる、という考え方になります。

同じマニュアル本編は、実績項目への配点を「技術点全体の20%以内を目途」としています。実績を見ないのではなく、実績に引っ張られすぎないための上限です。上の配点例は、この2つの基準に沿って組んでいます（費用25：提案内容75＝1：3、実績15点＝技術点75点の20%）。案件が単純なら費用の比重を上げ、連携や改修が多いなら提案内容側を厚くしてください。

運び方のこつは3つあります。

• 必須要求は配点に混ぜない：満たさなければ導入しない条件は、合否の判定として先に通します。ここを点数に混ぜると、必須を満たさない安価な提案が高得点になることがあります
• 費用は総額で見る：初期費用だけで比べると、保守費や追加開発の単価が高い提案が有利に見えます。稼働後の運用費を含めた期間の総額で並べてください
• 複数人で採点し、点数を出してから議論する：先に議論すると、発言力の強い意見に点数が寄ります。各自が採点したうえで、差が大きかった観点だけを話し合うほうが早く決まります

提案書の内容とは別に、会社そのものを見極める観点（体制の継続性・得意な領域・契約条件）もあります。こちらはシステム開発会社の選び方と比較で整理しています。委託範囲をどう切るかで評価の観点自体が変わるため、範囲の設計はシステム開発の外注ガイドも参考にしてください。

RFP発出からベンダー選定までの流れ

RFPを書き上げてから契約までは、おおむね次の5段階で進みます。発注側の作業量が最も多いのは1と4で、ここに人を割けるかが選定の質を決めます。

1. 配布先の選定と発出：提案を依頼する会社を選び、RFPを送付します。多すぎると評価の負担で1社あたりの検討が浅くなるため、2〜5社程度が現実的です。得意領域が近い会社を選ぶために、先に会社情報を集める場合はRFI（情報提供依頼書。RFPとの違いは後述）を使います
2. 質疑応答：各社からの質問に回答します。公平性を保つため、1社からの質問と回答は全社に共有するのが原則です。質問の質は各社の理解度と経験を映すため、それ自体が評価材料になります。窓口と受付期間をRFPに明記しておかないと、質問が来ないまま前提の違う提案が返ってきます
3. 提案受領・プレゼン：提案書を受け取り、必要に応じて説明の場を設けます。書面で分からない点は、実際にプロジェクトを担当する予定のメンバーに質問してください。営業担当のみが同席する提案では、進行時の実像が分かりません
4. 評価：事前に固めた評価基準で採点します。必須要求の合否を先に判定し、通った提案を配点で採点します。複数人で評価すると、声の大きい意見に引きずられにくくなります
5. 選定と条件調整：選定先と契約条件（スコープ・体制・スケジュール・検収条件）を詰めます。選定に至らなかった会社への連絡も忘れずに行います

5の条件調整では、契約形態も論点になります。要件が固まっている範囲は請負、要件定義や検証のように成果物を先に確定できない工程は準委任、という組み方が実務的です。使い分けはシステム開発の契約ガイドで解説しています。

契約後は、選定したベンダーとともに要件定義の工程に入ります。RFPに書いた要求がそのまま要件になるわけではなく、要件定義でのヒアリングと精査を経て確定していきます。この工程の運び方は要件定義の進め方（発注者とベンダーの役割分担）で詳しく解説しています。

提案が集まらない・比較できない4つの原因

RFPを出したのに提案が2社しか返ってこない、返ってきても比較できない。この状態の原因は、文書の書式よりも配布と運営の設計にあります。

1. 配布先の得意領域と案件が合っていない：規模も技術領域も違う会社に送ると、辞退か、当たり障りのない提案が返ってきます。会社ごとの得意な規模帯・領域を先に確認してください。判断材料がない場合はRFIで情報提供を依頼するか、公開されている実績の傾向から絞ります
2. 要求が機能の一覧だけで、解決したい課題が書かれていない：機能を指定するほど提案の余地は狭まり、各社は言われた通りの見積もりを出すだけになります。「どの業務の、何に、どれだけ困っているか」が書かれていると、想定より安く済む代替案や、既製サービスとの組み合わせが提案に出てきます
3. 質疑応答の窓口と期間が用意されていない：質問できないまま提出期限が来ると、各社は不明点を安全側の仮定で埋めます。結果として全社の見積もりが膨らみ、前提もばらつきます
4. 提出期限が短すぎる：概算でも見積もるには、構成の検討と社内の見積もり承認が必要です。期限が極端に短いと（目安として2週間を下回ると）、精度の低い提案か辞退のどちらかが増えます

もう1つ、RFP以前の問題として多いのが「そもそも開発が最適な手段ではない」ケースです。既製のSaaSで足りる業務に個社開発のRFPを出しても、各社からSaaS導入を提案されて比較が成立しません。既製品で足りない理由を一文で書けるかを、発出前に確認してください。開発案件がつまずく典型的なパターンはシステム開発の失敗事例と原因に、進行中の案件を立て直す観点は開発の引き継ぎ・レスキューにまとめています。

AI駆動開発の発注でRFPに加える確認項目

生成AIを開発工程に組み込むAI駆動開発が受託開発でも広がり、「どの会社に頼むか」に加えて「どんな作り方をする会社か」を確かめる項目が必要になりました。開発の速度とコスト構造が作り方によって変わるため、同じ要求に対する提案の内容が以前より大きく分かれます。

「AIで効率化します」の一文だけの提案と、工程ごとの使い分けと検証手順を説明できる提案とでは、実務の成熟度が違います。特に成果物の範囲は確認しておいてください。開発が速く進むほど、後に残る文書の品質差が、その後の改修コストと引き継ぎのしやすさを分けます。

そしてAI駆動開発の本質的な影響は、RFPの重要度がむしろ上がることです。作る速度が上がるほど、間違ったものも速く出来上がります。「何を作るか」を決める発注側の準備と、その最初の成果物であるRFPの精度が、これまで以上に結果を左右します。前提となる考え方はAI駆動開発とは、同じ構造の変化が起きている上流工程については要件定義の進め方のAI駆動開発の章で解説しています。

RFP・RFI・RFQの違い

3つは役割と使う時期が異なります。候補を広く知りたいならRFI、実現方法ごと提案を受けたいならRFP、仕様が固まって価格だけを比べたいならRFQです。

システム開発の発注では、発注側だけで仕様を確定させることが難しいため、RFQ単独ではなくRFPで実現方法ごと提案を受けるのが一般的です。候補が多い場合は、RFIで情報収集をしてからRFPの配布先を数社に絞ると、双方の負担を抑えられます。

技術的に成立するかどうかが読めない案件では、RFPで本開発を一括して依頼する前に、小さく作って確かめる段階を挟む選択もあります。この場合はPoCを別の依頼として切り出し、結果を踏まえて本開発のRFPを書きます（PoC開発の費用相場と進め方）。事業として成立するかを確かめたい新規事業なら、MVP開発から入るほうが早い場合があります。

RFPの作成を外部に相談してよいか

相談してかまいません。RFPを完璧に書き上げてからでないと候補会社に声をかけられない、と考える必要はありません。発注側だけで書き切ろうとすると、分からない部分を推測や一般論で埋めることになり、かえって提案の精度が下がります。分からない項目は「未定」「提案に委ねたい」と正直に書いてください。それ自体が受け手にとって有益な情報です。

外部に相談できる範囲と、発注側に残すべき範囲は次のように分かれます。

線引きの理由は公平性です。RFPの作成を提案を受ける予定の1社に任せきると、その会社の得意な方式に有利な条件が入り込む余地が生まれます。必須要求と評価基準を発注側で持っておけば、作成の作業は手伝ってもらっても、比較の土俵は保てます。複数社に声をかける前提であることを最初に伝えておくのも有効です。

相談の時期は、RFPがたたき台の段階が適しています。質疑を通じて要求を磨いていく進め方は、発注側・受託側の双方にとって合理的です。Swoooでも、RFPが固まる前の「この構想は成立するか」「この予算の幅で何ができるか」という段階からのご相談をお受けしています。

RFPのよくある質問

RFPとプロポーザル（提案書）の違いは何ですか？

発注側が出すのがRFP（提案依頼書）、それに応えて受託側が出すのがプロポーザル（提案書）です。対になる文書であり、提案書の質を引き出すための入力がRFPだと考えると、関係が分かりやすくなります。

RFPは何社に送るべきですか？

2〜5社程度を推奨します。1社では比較ができず、多すぎると質疑応答と評価の負担が増えて検討が浅くなります。候補が多い場合は、RFIによる情報収集で先に絞り込んでください。

小規模な開発でもRFPは必要ですか？

何十ページもの文書は不要ですが、背景・課題・要求・条件を数ページにまとめる作業は、規模を問わず有効です。分量よりも、各社に同じ情報を渡して比較できる状態を作ることに意味があります。

RFPの作成にはどのくらいの期間がかかりますか？

社内の合意形成を含めると、数週間から2ヶ月程度を見込むのが現実的です。書く作業そのものより、課題の言語化と関係部門の調整に時間がかかります。ここを省略して発出を急ぐと、質疑応答と選定後の工程で、その分の時間を余計に払うことになります。

RFPの作成を開発会社に手伝ってもらってもよいですか？

課題の整理・記載項目の抜け漏れの指摘・実現方式の選択肢の提示までは手伝ってもらってかまいません。一方で、必須要求の線引きと評価基準・配点は発注側で決めてください。この2つを提案を受ける予定の会社に決めてもらうと利益相反が生まれ、比較の土俵が崩れます。

提案の評価はどう配点すればよいですか？

実現方式・進め方と体制・実績・運用保守・費用の5観点に割り振る形が扱いやすいです。費用と提案内容の重みは、デジタル庁の調達手続マニュアルが情報システムについて示す「価格点1：技術点1、または価格点1：技術点3以内」が目安になります。複数システムとの連携や頻繁な改修がある案件ほど提案内容側を厚くし、実績への配点は技術点全体の20%以内に抑えます。必須要求は配点に混ぜず合否で先に判定し、配点はRFPを出す前に決めてください。

RFPを出さずに1社と進めても問題ありませんか？

既に信頼している会社があり、規模も小さい案件なら、複数社の比較を省く判断はあり得ます。ただしその場合も、依頼範囲の境界・必須要求・予算の幅・稼働時期を文書にしてから見積もりを依頼してください。比較のためではなく、範囲の認識を揃えて後の追加費用の議論を避けるためです。

まとめ

• RFPを出す前に、①依頼範囲の境界（今回やらないこと）②必須と希望の線引き ③予算の幅 ④稼働時期とその理由 ⑤評価基準と配点 を決める
• 予算は少なくとも幅を書く。伏せるより、費用対効果を評価基準に明記するほうが有効
• 記載項目はテンプレートを土台に、自社の課題に合わせて増減する。項目を埋めること自体を目的にしない
• 抽象語は数えられる形に置き換える。置き換えられない要求は、社内の言語化が終わっていない
• 利用者数・データ量・稼働時間などの前提はIPAの「非機能要求グレード」を使って洗い出す。重要な項目だけ決めてRFPに転記すれば足りる
• 評価基準はRFPと同時に作り、観点はRFP本文にも書く。費用と提案内容の重みはデジタル庁の基準（価格点1：技術点1〜3以内）を当たりにし、必須要求は配点に混ぜず合否で判定する
• 提案が集まらない原因は、配布先のミスマッチ・課題の欠落・質疑窓口の不在・短すぎる提出期限
• AI駆動開発の発注では、AIの使いどころ・検証体制・データの扱い・成果物の範囲・提案段階でのプロトタイプ提示を確認する項目を加える
• RFPの作成は相談してよい。ただし必須要求の線引きと評価基準は発注側で持つ

本メディアを運営するSwooo（東証グロース上場・株式会社アイビス、証券コード9343）は、AI駆動開発とノーコード開発を組み合わせた受託開発を累計50件以上手がけてきました。RFPが固まる前の構想段階からのご相談に対応しており、要求の整理やたたき台へのフィードバックを通じて、比較検討しやすい発注準備をお手伝いします。

→ システム開発の発注準備を相談する（無料）

あわせて読む：システム開発の費用相場と見積もりガイド／要件定義の進め方（発注者とベンダーの役割分担）／システム開発会社の選び方と比較／システム開発の契約ガイド