RFP（提案依頼書）の意味とRFI・RFQとの違い、記載項目の一覧と書き方、評価基準の作り方を解説。システム導入でベンダーを選ぶ担当者向け。
RFPはRequest for Proposalの略で、日本語では提案依頼書といいます。システム導入や業務委託の発注先を選ぶときに、目的・要件・予算・スケジュール・評価基準を示して、複数のベンダーに提案と見積を依頼する文書です。全社に同じ前提を渡すことで、提案を同じ条件で比べられるようになります。
RFI（情報提供依頼書）は、要件が固まる前に、ベンダーの製品や実績などの情報を集めるための文書です。RFPは、要件の方向性を固めたうえで、具体的な提案と見積を依頼する文書です。一般的にはRFIで情報を集めてからRFPを出し、仕様が決まった後に価格だけを比べたい場合はRFQ（見積依頼書）を使います。
RFPは「全体の概要」「提案依頼内容」「選定の進め方」の3つのブロックで構成します。全体の概要には目的と背景、現状の課題と目指す姿、対象範囲を、提案依頼内容には機能要件と非機能要件、移行、スケジュール、体制、予算を、選定の進め方には提出物と期限、評価基準を書きます。要件は必須とできればに分けて書くと、提案を比べやすくなります。
提案内容、実績、費用、体制とサポート、セキュリティと運用などの評価項目に配点をつけ、RFPを配る前に決めてベンダーに示します。費用は初期費用だけでなく、月額費用を含めた数年間の総額で比べます。必須要件を満たさない提案は点数にかかわらず対象外にし、評価は複数の部門のメンバーで行うのが基本です。
一般的な項目に加えて、取引先ごとの単価や掛け率、取引先の社内承認フロー、基幹・在庫・会計システムとの連携範囲、FAXや電話からWebへの移行方針、取引先数や注文数などの規模、セキュリティや監視体制などの非機能要件を書いておきます。取引先にも使ってもらう仕組みのため、取引先への説明や操作サポートの範囲も書いておくと、提案を比べやすくなります。
RFP（Request for Proposal／提案依頼書）とは、システム導入や業務委託の発注先を選ぶときに、目的・要件・予算・スケジュール・評価基準を示して、複数のベンダーに提案と見積を依頼する文書です。
本記事では、RFI・RFQ・要件定義書との違いを整理したうえで、RFPに書く項目と記載例、そのまま使える目次テンプレート、評価基準の配点表の作り方を解説します。
あわせて、BtoB ECや受発注システムのベンダー選定でRFPに書いておきたい項目と、RFPでベンダーを選んだ企業の事例も紹介します。
RFP（Request for Proposal／提案依頼書）は、発注する企業が、外部のベンダーやパートナー企業に対して「具体的な提案と見積」を正式に依頼するための文書です。システム開発、ECサイトや受発注システムの構築、業務委託など、発注先を比較して選ぶ場面で使われます。
RFPには、プロジェクトの目的と背景、実現したいこと、必須の要件、予算、納期、提案の評価基準などを記載します。RFPを受け取ったベンダーは、自社の製品やサービスが要件に合うかを判断し、合う場合はRFPの内容に沿って提案書と見積書を作成します。
発注側とベンダーが同じ前提で話を始めるための文書であり、提案を同じ条件で比べられるようにすることが、RFPの最も大きな役割です。
RFPと混同されやすい言葉に、RFI（情報提供依頼書）とRFQ（見積依頼書）があります。一般的には「RFI→RFP→RFQ」の順で使い、検討が進むほど依頼の内容が具体的になります。
| 文書 | 目的 | 使う時期 | 主な記載内容 | 受け取るもの |
| RFI Request for Information 情報提供依頼書 |
ベンダーや製品の情報を集める | 要件が固まる前 | 検討の背景、知りたい情報（製品の特徴、実績、費用の目安、体制） | 会社・製品の情報 |
| RFP Request for Proposal 提案依頼書 |
具体的な提案を受け、発注先を選ぶ | 要件の方向性が固まった後 | 目的、現状の課題、要件、予算、スケジュール、評価基準 | 提案書と見積書 |
| RFQ Request for Quotation 見積依頼書 |
価格や納期を比べる | 仕様が決まった後 | 仕様、数量、納期、支払条件 | 見積書 |
RFIで候補のベンダーを絞り込み、RFPで提案を比べて発注先を決めるのが基本の流れです。RFPの中で見積も依頼することが多いため、システム導入ではRFQを別に出さないケースもあります。一方、仕様が決まっている物品の購入では、RFPを省いてRFQだけを使うこともあります。契約後に正式に発注するときの書類（発注書）については、「PO（Purchase Order）とは？」で解説しています。
RFPと要件定義書は、どちらも「何を実現したいか」を書く文書ですが、作る時期と作る人、詳しさが違います。
| 項目 | RFP（提案依頼書） | 要件定義書 |
| 作る時期 | 発注先を選ぶ前 | 発注先が決まった後 |
| 主に作る人 | 発注する企業 | 発注する企業とベンダーが一緒に作る（ベンダーが主導することが多い） |
| 詳しさ | 目的、課題、必須の要件、優先度など、提案を比べるために必要な範囲 | 画面、機能、データ、外部連携など、設計・開発に必要な範囲 |
| 役割 | 提案を同じ条件で比べ、発注先を選ぶ | 作るものを確定し、設計・開発の土台にする |
RFPの段階で、すべての要件を細部まで決めておく必要はありません。「必ず必要なこと」と「できればほしいこと」を分けて書いておけば、要件定義の段階で詰める余地を残しながら、提案を公平に比べられます。
RFPを作る目的は、自社の課題に最も合う発注先を、同じ条件で比べて選ぶことです。口頭での相談やメールだけで進めると、ベンダーごとに前提が異なる提案が集まり、金額も内容も比べられません。RFPを作ることで、主に次のメリットが得られます。
| メリット | 内容 |
| 要件が整理される | 目的や課題、必要な機能を文書にする過程で、社内の認識のずれや抜け漏れに気づける |
| 提案を同じ条件で比べられる | 全社に同じ前提を渡すため、提案内容・費用・体制を横並びで比べられる |
| 予算に合った提案が集まる | 予算の上限や目安を示すことで、実現できる範囲の現実的な提案を受けやすくなる |
| 選定の理由を説明できる | 評価基準と配点を事前に決めておくと、経営層や関係部門に選定理由を説明しやすい |
| 契約後のトラブルを防げる | 前提条件や範囲を文書で残すため、「言った・言わない」や追加費用の発生を防ぎやすい |
| 自社の業務を見直す機会になる | 現状の業務を棚卸しする中で、システム化の前に見直すべき手順や慣習が見つかる |
RFPは、「全体の概要」「提案依頼内容」「選定の進め方」の3つのブロックで構成すると、読み手のベンダーが迷わず、提案も比べやすくなります。ブロックごとに、書く項目と記載例を紹介します。記載例は、BtoB ECサイトを新しく構築する場合を想定しています。
なぜこのプロジェクトを行うのか、何を変えたいのかを伝えるブロックです。ベンダーが提案の方向性を決める土台になるため、最も時間をかけて書きます。
| 項目 | 書く内容 | 記載例 |
| 本書の目的 | このRFPで何を依頼するのか | BtoB ECサイト構築に関する提案と見積の依頼 |
| 会社概要 | 事業内容、取引先の構成、組織 | 産業資材の卸売。取引先約800社、営業拠点5か所 |
| 背景と現状の課題（As-Is） | いま困っていることを、できるだけ数字で | 注文の7割がFAXと電話で、受注入力に1日あたり延べ20時間かかっている |
| 目指す姿とゴール（To-Be） | 導入後の状態と、測れる目標 | 稼働後1年でWeb経由の注文比率を50%にし、受注入力の工数を半減する |
| 対象範囲 | 依頼に含めるもの・含めないもの | サイト構築、基幹システムとの連携、データ移行、取引先向けマニュアル作成。保守は別途提案 |
| 現行のシステム構成 | いま使っているシステムと、連携の方法 | 販売管理システム（オンプレミス）、会計システム（クラウド）。現在は連携なし |
※記載例は説明のための架空の数値です。
ベンダーに何を提案してほしいかを伝えるブロックです。要件は「必須（Must）」と「できれば（Want）」に分けて書くと、提案の比較と、予算との調整がしやすくなります。
| 項目 | 書く内容 | 記載例 |
| 機能要件 | システムで実現したい業務と機能 | 【必須】取引先ごとの単価表示、発注側の承認フロー 【できれば】見積依頼の受付、過去の注文からの再注文 |
| 非機能要件 | 性能、可用性、セキュリティ、運用など、機能以外の条件 | 月末に注文が集中しても応答が遅くならないこと。第三者認証や24時間監視の体制を示すこと |
| 移行要件 | 既存のデータや業務からの切り替え方 | 商品約3万点、取引先約800社のデータを移行。FAX注文は半年かけて段階的に移行 |
| スケジュール | 稼働の希望時期と、守るべき期限 | 20XX年4月の稼働を希望。3月の決算期は切り替えを避けたい |
| 体制 | 自社側の担当と、ベンダーに期待する役割 | 自社は情報システム部2名、営業部1名。要件の整理から支援してほしい |
| 予算 | 上限や目安。初期費用と月額費用を分ける | 初期費用の上限と、5年間の総額の目安を記載 |
| 保守・運用 | 稼働後のサポートの範囲 | 問い合わせの受付時間、障害時の対応時間、機能追加の進め方 |
予算は書きにくい項目ですが、まったく示さないと、規模感のばらばらな提案が集まり、比較が難しくなります。上限が決まっていない場合も、「初期費用はこの範囲で検討している」といった目安を示すのが現実的です。
いつまでに、何を、どう出せばよいか、どう評価されるのかを伝えるブロックです。ここが曖昧だと、提出物の形式がそろわず、比較に手間がかかります。
| 項目 | 書く内容 |
| 選定スケジュール | RFPの配布日、質問の受付期限、回答日、提案書の提出期限、プレゼン日、結果の通知日 |
| 提出物と形式 | 提案書、見積書（初期・月額を分けた内訳）、体制図、実績、要件ごとの対応可否の一覧 |
| 提出方法と窓口 | 提出先、ファイル形式、問い合わせ窓口と連絡方法 |
| 評価基準 | 評価する項目と配点（次の章で解説） |
| 守秘義務など | RFPの取り扱い、秘密保持契約の締結の要否、提案費用の負担 |
3つのブロックを、そのままRFPの目次として使える形にまとめました。プロジェクトに合わせて、不要な項目は削り、足りない項目は追加してください。
はじめてRFPを作る場合や、小規模なプロジェクトの場合は、1〜5と7・10・12・16だけの「簡易版」から始めても構いません。大切なのは、ベンダー全社に同じ情報を渡すことです。
評価基準は、評価する項目と配点を、RFPを配る前に決めてベンダーに示しておくのが基本です。提案を受け取ってから基準を決めると、印象や価格の安さに引っぱられやすくなります。
| 評価項目 | 配点の例 | 見るポイント |
| 提案内容 | 30点 | 課題の理解、必須要件への対応、標準機能で対応できる範囲とカスタマイズの範囲 |
| 実績 | 20点 | 同じ業種・同じ規模での構築実績、取引先が使い続けている事例 |
| 費用 | 20点 | 初期費用だけでなく、月額費用と改修費を含めた5年間の総額 |
| 体制・サポート | 15点 | 担当者の経験、質問への回答の速さと正確さ、稼働後のサポート範囲 |
| セキュリティ・運用 | 15点 | 第三者認証、監視体制、脆弱性への対応、インフラを誰が運用しているか |
| 合計 | 100点 | 必須要件を満たさない提案は、点数にかかわらず対象外とする |
配点はプロジェクトの性格によって変えます。たとえば、初めてのシステム導入で社内に経験者が少ない場合は「体制・サポート」の配点を、取引先の情報や単価を扱う場合は「セキュリティ・運用」の配点を高めにするのが一般的な考え方です。評価は複数の部門のメンバーで行い、点数の理由を記録しておくと、選定理由の説明にそのまま使えます。
受発注システムを比べるときの具体的な観点や費用の目安は、「受発注システムの比較方法｜費用相場と見るべき指標を解説」で解説しています。
RFPを作成し、提案を受け付けて契約を結ぶまでの流れを、7つの手順に分けて解説します。期間はあくまで目安で、プロジェクトの規模や社内の承認手続きによって変わります。
手順① 目的と要件を整理する（目安：2週間から1か月）
何を達成したいのか、そのためにどんな機能や条件が必要なのかを整理します。利用部門・情報システム部門・経営層の意見を集め、現状の課題を数字で把握しておきます。必要に応じて、この段階でRFIを出してベンダーの情報を集めます。
手順② RFPを作成する（目安：2週間から1か月）
整理した内容を、目次テンプレートに沿って文書にします。作成後は関係部門でレビューし、抜け漏れや部門間の矛盾がないかを確認します。
手順③ 提案を依頼するベンダーを選び、RFPを配布する
RFIの結果や実績をもとに、提案を依頼するベンダーを3から5社程度に絞ってRFPを配布します。秘密保持契約が必要な場合は、配布の前に結んでおきます。
手順④ 質問を受け付けて回答する（目安：1から2週間）
ベンダーからの質問を期限を決めて受け付け、回答します。ある社の質問への回答は、公平性のために全社に共有するのが原則です。質問の内容や鋭さからも、ベンダーの理解度がわかります。
手順⑤ 提案書を受け取り、評価する（目安：2週間から1か月）
提案書と見積書を受け取り、プレゼンや質疑を経て、事前に決めた評価基準で採点します。
手順⑥ ベンダーを決定し、条件を調整する
最も評価の高いベンダーを選び、範囲・費用・スケジュールなどの条件を最終調整します。選ばなかったベンダーにも結果を通知します。
手順⑦ 契約を結び、プロジェクトを開始する
合意した内容で契約を結び、要件定義からプロジェクトを始めます。RFPと提案書は、要件定義で「最初に約束したこと」を確認する資料として残しておきます。
BtoB ECや受発注システムは、自社だけでなく取引先にも使ってもらう仕組みです。一般的な項目に加えて、次の点をRFPに書いておくと、提案の精度が上がり、比べやすくなります。
| 項目 | RFPに書いておきたいこと |
| 取引条件 | 取引先ごとの単価・掛け率、表示する商品の出し分け、締め日と支払条件、与信の扱い |
| 発注側の業務 | 取引先の社内承認フロー、拠点ごとの配送先、見積依頼から注文への流れ |
| システム連携 | 基幹（販売管理）・在庫・会計システムとの連携範囲と方法（API・CSV・手作業）、連携の頻度 |
| 現在の注文方法と移行方針 | FAX・電話・メール・EDIの比率、Webへ移行してもらう方針、取引先向けの説明や操作サポートの範囲 |
| 規模 | 取引先数、利用者数、商品数（SKU）、1日あたりの注文数、注文が集中する時期 |
| 非機能要件（セキュリティ・運用） | 第三者認証（ISMSなど）、24時間の監視、脆弱性への対応、第三者による診断、インフラを誰が運用しているか、障害時の連絡体制 |
| 稼働後の運用 | 商品登録や単価更新を誰が行うか、機能追加の進め方、保守の範囲 |
非機能要件のなかでも、セキュリティは委託先選びで欠かせない観点です。IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」の組織編では、ランサムウェアによる攻撃が1位、サプライチェーンや委託先を狙った攻撃が2位に挙げられています。取引先の情報や取引ごとの単価が集まる受発注の仕組みでは、機能の比較だけでなく、運用を任せるベンダーの体制までRFPで確認することが重要です。
出典：IPA「情報セキュリティ10大脅威 2026」
参考までに、ecbeingが提供するBtoB EC構築プラットフォーム「ecbeing BtoB」は、ecbeingが自社で運用するEC専用インフラで提供しています。2005年からISMS認証（登録番号IS97670）を取得し、NIST CSF 2.0に基づく運用・監査、自社と外部のSOCによる24時間365日の監視、定期・緊急の脆弱性対応、第三者機関による定期的なセキュリティ診断を行っています。詳しくは「ecbeingの強固なセキュリティ対策」をご覧ください。
受発注システムの種類や選び方は「受発注システムとは？メリット・選び方と業種別の比較」、製品のタイプ別の比較は「受発注・Web受注システムのランキング｜タイプ別比較と選び方」で解説しています。BtoC向けのECサイト構築で見積を依頼する場合は、「ECサイト構築の見積もりと作り方」もあわせてご覧ください。
ここでは、BtoB ECの構築でベンダーを選定した企業の事例を2つ紹介します。いずれも、RFPや複数社の比較を通じて、何を決め手に選んだのかがわかる事例です。
情報通信機器・部材の専門商社であるサンテレホン様は、「新規顧客を獲得し、新たな売上の柱を創出すること」を目的に、BtoB ECサイトの構築を決めました。対面営業では接点を持ちきれない顧客に、Eコマースで届くと考えたためです。
パートナーの選定では、RFP（提案依頼書）を使って4社を比較検討し、実績と提案内容が最も優れていた会社としてecbeingを選定しています。2018年にプロジェクトを開始し、2019年に情報通信機材の通販サイト「GOYOU（ゴヨー）」を開設しました。その後、データ活用ツールも導入し、EC経由の売上は前年比で約3倍に伸びています。
RFPで目的（新規顧客の獲得）をはっきり示し、「実績」と「提案内容」という評価の軸で比べた例です。
沖電気工業様は、ビジネスホンの見積と受発注を、販売パートナー向けのBtoB ECで効率化しました。年度内に100社強のパートナー全社へ展開することを目標に、利用経験のあるパートナーから順に導入を進めています。
プロジェクトは、こうしたシステム構築の経験がほとんどないメンバーで進めていました。そのなかで、質問に対して持ち帰りにならず、その場で回答をもらえる点が、他社と比べて大きな差別化ポイントだったと振り返っています。
社内に経験者が少ない場合は、評価基準の「体制・サポート」の配点を高めにし、手順④の質疑応答での回答の速さや正確さも評価に入れるとよい、ということがわかる事例です。
RFP（提案依頼書）を作成する際には、次の点に注意が必要です。
RFP作成はプロジェクト成功の土台です。具体的な手順は企業やプロジェクトの特性、規模などにより異なることもあるので、実際にRFPを作成する際は十分な時間と体制を確保し、社内外の合意形成を意識しましょう。
RFPは、受け取るベンダー側にとっても提案の質を左右する文書です。RFPに回答するときは、次の点を押さえると、発注側が比べやすい提案になります。
・要件ごとに対応方法を明示する：標準機能で対応するのか、カスタマイズが必要か、対応できないのかを一覧にする
・不明点は質問の期限内に確認する：前提を推測で埋めると、見積の金額が他社と比べられなくなる
・見積の前提条件を書く：費用に含む範囲と含まない範囲、追加費用が発生する条件を明記する
・評価基準に沿って構成する：配点の高い項目から読める構成にし、根拠となる実績や体制を示す
RFP（提案依頼書）は、発注先を選ぶ前に、目的・要件・予算・スケジュール・評価基準を示して、複数のベンダーに提案と見積を依頼する文書です。RFIで情報を集め、RFPで提案を比べ、必要に応じてRFQで価格を比べるのが基本の流れです。
RFPは「全体の概要」「提案依頼内容」「選定の進め方」の3つのブロックで構成し、要件には優先度をつけ、評価基準と配点は配布の前に決めておきましょう。BtoB ECや受発注システムでは、取引先ごとの取引条件、基幹システムとの連携、取引先の移行方針、セキュリティを含む非機能要件まで書いておくことで、提案の精度が上がります。
本記事のテンプレートと配点表を参考に、貴社のRFP作成・ベンダー選定・プロジェクト推進をぜひ成功へと導いてください。
copyright © ecbeing corp. all rights reserved.ecbeing.net
