RFPとは？意味・読み方とRFI・RFQとの違いを図解｜提案依頼書の基本

この記事の要点

• RFPは「提案依頼書」。読み方は「アール・エフ・ピー」。発注側が書き、候補のベンダー（制作会社・開発会社・SaaS提供企業など）に渡して、課題の解き方と費用の提案を求める
• RFI・RFP・RFQは「何を聞き、何が返ってくるか」が違う。RFIは情報、RFPは提案、RFQは見積を求める文書で、一般的にはRFI → RFP → RFQ の順で候補を絞り込む（本文の対応図で一覧できる）
• RFPは要件定義書・提案書・見積書とは別物。誰が書き、誰に渡し、どの時点で使うかが異なる
• 小さな案件ではRFPが要らないこともある。仕様が決まっているなら見積依頼（RFQ）や相見積もりで足りる
• RFPに書くのは7項目（プロジェクト概要・現状課題・要件・予算・提案依頼事項・評価基準・制約条件）。例文つきの書き方は「RFPの書き方完全ガイド」で扱う
• 評価マトリクスで配点と重み付けを先に決めると、選定が属人的にならない
• 受け取った側（受注側）は、評価配点・質問期限・前提条件・対象外の範囲を最初に読む。ここを読み落とすと、契約後の範囲の膨張（スコープクリープ）につながる

「RFPを出してください、と言われたけれど、そもそもRFPって何？」「RFIやRFQとどう違うの？」——情報システムの導入やWebサイト制作、業務委託の発注に関わると、ある日突然この3文字に出会います。発注する側にとっても、RFPを受け取った制作会社・開発会社の側にとっても、意味をあいまいにしたまま進めると、提案のピントがずれたり、比較できない見積が並んだりします。

本記事では、RFPの意味・読み方・目的といった基本から、混同しやすいRFI・RFQとの違い（対応図つき）、要件定義書・提案書・見積書との違い、RFPが要る場面と要らない場面までを先に整理します。そのうえで、RFPに書く7項目の要点、評価マトリクスの作り方、よくある失敗、そしてRFPを受け取った側の読み方までを1本で解説します。テンプレートと例文を使って実際に書きたい方は、要点を押さえたあとで「RFPの書き方完全ガイド」に進んでください。

---

RFP（提案依頼書）とは？意味・読み方をわかりやすく解説

RFPとは、発注側が課題・要件・評価基準を書面で示し、複数のベンダーに解決策と費用の提案を依頼する文書です。

RFP（Request for Proposal）の定義と読み方

RFPとは「Request for Proposal」の略で、読み方は「アール・エフ・ピー」、日本語では「提案依頼書」と訳されます。発注企業がベンダーや提案企業に対して、自社の課題・要件・条件・評価基準を提示し、正式な提案書の提出を依頼するための文書です。

RFPは単なる仕様書や発注書ではありません。「こういう課題を抱えている。どのようなアプローチで、どの程度のコストで解決できるか提案してほしい」という発注側の意思表示であり、公正な比較評価と最適なベンダー選定を実現するための戦略的文書です。

会話では「RFPを出す（発行する）」「RFPを切る」「RFPに回答する」のように使います。「Request for」で始まる依頼文書（RFI・RFP・RFQなど）をまとめて「RFx（アールエフエックス）」と呼ぶこともあります。

RFPは誰が書き、誰に渡す文書か

RFPを書くのは発注側です。情報システム部門だけでなく、実際にその仕組みやサービスを使う事業部門、予算を持つ経営層が加わって作ります。受け取るのは候補のベンダーで、システム開発会社、Web制作会社、SaaSの提供企業、コンサルティング会社、広告代理店などが代表例です。

受け取ったベンダーは、RFPに書かれた課題と条件を読み、提案書と見積を作って返します。つまりRFPは「発注側が書く問い」で、提案書は「ベンダーが返す答え」です。問いの質が低ければ、どれだけ優秀なベンダーでも的外れな答えしか返せません。RFPの品質が、そのまま提案の品質を決めると言われるのはこのためです。

RFPの目的 — なぜ提案依頼書が必要なのか

RFPが必要とされる根本的な理由は、ベンダー選定における情報の非対称性を解消し、複数のベンダーから比較可能な提案を引き出すためです。

RFPがない状態では、発注側の要望が口頭やメールで断片的に伝わるだけで、ベンダーは提案の方向性を見誤ります。結果として「提案のピントがずれた」「見積の粒度がバラバラで比較できない」というトラブルが発生します。RFPを作成することで、以下の効果が得られます。

• 社内の認識統一：課題・要件を整理する過程で関係者の合意形成が進む
• 公平な比較基盤：複数ベンダーに同一情報を提供し、評価の土台を揃える
• 属人的判断の排除：評価基準を事前に設計することで透明性のある選定を実現
• スコープクリープの防止：目的・範囲を文書化し、後工程での範囲膨張を防ぐ
• 契約条件の前段固め：要件と評価基準が文書化されているため、後の契約書交渉がスムーズになる

RFPが使われる場面・業界

RFPが特に有効なのは、金額規模が大きく複数ベンダーの比較が必要な案件です。代表的な対象は次のとおりです。

• システム導入・刷新：基幹システム（ERP・会計・人事）、業務システム、DXプロジェクト
• SaaS選定：CRM、MA、SFA、人事労務、コミュニケーションツール
• 大型コンサルティング案件：経営戦略、業務改善、組織変革
• マーケティング施策の委託：広告運用、PR、コンテンツ制作、SEO
• Webサイト制作・リニューアル：コーポレートサイト、ECサイト、オウンドメディア
• インフラ調達：クラウド移行、データセンター、ネットワーク機器

Gartnerの2025年5月の発表では、B2Bの購買グループは5〜16人で、最大4つの部門にまたがると説明されています（Gartner, 2025年5月7日）。このような複雑な意思決定構造の中で、RFPは関係者間の評価基準を統一するための不可欠なツールとして機能します。

---

RFI・RFQ・RFPの違い【比較表付き】

RFIは「情報」、RFPは「提案」、RFQは「見積」を求める文書で、発行する段階と送る社数の目安が異なります。

3つの文書は混同されやすいですが、目的・タイミング・対象社数がまったく異なります。まずはそれぞれの意味を押さえ、そのうえで対応図と比較表で並べて見ていきます。

RFI（情報提供依頼書）とは

RFI（Request for Information）は、市場調査とベンダーの能力把握を目的とした文書です。読み方は「アール・エフ・アイ」。要件が固まる前の情報収集段階で発行し、候補ベンダーを10〜15社程度に広く募ります。回答は会社概要・実績・対応可能領域・概算費用レンジなど、定性情報が中心です。

RFQ（見積依頼書）とは

RFQ（Request for Quotation）は、仕様が確定した段階で価格・納期を比較するための文書です。読み方は「アール・エフ・キュー」。RFPで提案内容を評価した後、最終候補1〜3社に発行するのが一般的です。要件は固定で、ベンダーが提案するのは価格と納期、保守条件など定量的な項目に絞られます。

対応図で見るRFI・RFP・RFQの違い

3つの文書を「発注側が知りたいこと」「発行する段階」「送る社数の目安」「返ってくるもの」「受け取った側の負担」の5項目で並べると、次のようになります。

← 横スクロールで全体を表示 →

ポイントは**「受け取った側の負担」がRFPで最も大きいことです。RFIは会社案内や実績資料の流用で答えられ、RFQは確定した仕様に沿って積算すれば答えられます。一方RFPは、発注側の課題を読み解き、解決のアプローチ・体制・スケジュール・費用を一から組み立てる必要があります。だからこそ、RFPを出す側は送る社数を絞り、評価基準を明示して、ベンダーが提案に力を注げる条件を整える**ことが大切です。

RFI → RFP → RFQ の活用フローと判断基準

どの文書を使うべきかの判断基準

• 要件が曖昧で市場の選択肢を把握したい → RFIから開始
• 課題と要件が明確で、複数社の提案を比較したい → RFPを発行
• 仕様が確定しており、価格と納期だけを比較したい → RFQで十分

3文書すべてを使う必要はありません。要件の確度に応じて「RFI → RFP → RFQ」のどこから始めるかを判断しましょう。小規模案件や仕様が確定している場合はRFQのみで進めるケースもあります。

各フェーズで「誰に・何社に・何を聞くか」時系列表

実務では「いつ・何社に・どんな質問を投げるか」が分かりにくいため、時系列で整理しておきます。

合計でおおむね11週間〜18週間が標準的なリードタイムです。

RFIだけ・RFQだけで終わることもある

3つの文書は必ずセットで使うものではありません。次のような場合は、途中の文書を省くのが自然です。

• RFIだけで終わる：情報を集めた結果、「今期は見送る」「既存のツールで足りる」と判断した場合。RFIは発注を約束する文書ではないため、ここで止めても問題ありません
• RFPを省いてRFQから始める：買うもの・作るものの仕様がすでに決まっていて、価格と納期だけを比べたい場合。たとえば同じ仕様の機器の購入や、既存サイトと同じ構成の追加ページ制作などです
• RFPのあとRFQを出さない：RFPの段階で見積の粒度が十分にそろい、そのまま契約交渉に入れる場合

迷ったときは「まだ解き方が決まっていない課題か、もう決まっている仕様か」で判断します。解き方をベンダーに考えてほしいならRFP、決まった仕様の値段を知りたいならRFQです。

---

RFPと要件定義書・提案書・見積書の違い

RFPは発注側がベンダー選定のために書く「依頼の文書」で、要件定義書・提案書・見積書とは書く人と使う時点が異なります。

RFPの周りには似た名前の文書がいくつも登場します。混同すると「RFPに要件定義書並みの細かさを求めて作成が止まる」「提案書とRFPの区別がつかず、何を返せばいいか分からない」といった混乱が起きます。役割を整理しておきましょう。

要件定義書との違い — 「選ぶための文書」と「作るための文書」

いちばん混同されやすいのが要件定義書です。RFPにも「要件」の欄がありますが、目的が違います。RFPの要件はベンダーを選ぶために必要な粒度で書けば足り、Must（必須）/ Want（推奨）の区別がついていれば提案を比較できます。一方、要件定義書は作るものを確定させるための文書で、画面・機能・データ・性能などを、設計に進めるだけの細かさで詰めます。

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」（2019年9月公開）は、要件定義をユーザー（発注側）が担う仕事として位置づけ、その進め方で起こりがちな問題と対策をまとめています。RFPの段階で要件定義書の細かさを目指すと作成が止まりがちなので、RFPでは「何に困っていて、何ができれば成功か」を優先して書き、詳細は契約後の要件定義で詰める、という役割分担を意識すると進めやすくなります。要件定義書に何を書き、誰が作り、誰が承認するかは「要件定義書とは？書き方と記載項目、規模別テンプレート」で詳しく解説しています。

提案書・見積書との違い — 「問い」と「答え」

RFPが発注側の「問い」なら、提案書と見積書はベンダーの「答え」です。提案書は課題に対する解決策・体制・スケジュールを、見積書は作業範囲ごとの金額を示します。発注側が見積書のひな形（費用の内訳の分け方）をRFPで指定しておくと、各社の金額を同じ単位で比べられます。見積書の項目の分け方は「見積書テンプレート」、受注側の提案書の組み立て方は「B2B提案書の書き方完全ガイド」で解説しています。

官公庁の「調達仕様書」との関係

官公庁や自治体の情報システム調達では、RFPに近い役割を「調達仕様書」が担います。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」の実践ガイドブック（DS-120）には、要件定義書と調達仕様書の標準テンプレートが関連資料として用意されています。民間企業のRFPでも、項目の抜け漏れ確認の参考になります。

---

RFPが必要な場面・不要な場面

RFPは、解き方が決まっていない課題を複数社に比較提案してもらうときに必要で、仕様が決まった小さな発注では不要なことが多い文書です。

RFPの作成には社内のヒアリングから配布まで数週間かかり、受け取るベンダー側にも大きな負担がかかります。すべての発注でRFPを書く必要はありません。

仕様が決まっている発注で複数社を比べたいなら、RFPよりも相見積もりのほうが早く、ベンダーの負担も小さく済みます。進め方は「相見積もりとは？依頼のマナーと比較の仕方」で詳しく解説しています。また、技術的に実現できるか、効果が出るかがまだ分からない段階でRFPを書くと、要件を書ききれずに曖昧な提案しか集まりません。その場合は先に小さく検証する「PoC（概念実証）」を挟む判断も有効です。

一方、金額が小さくても複数ベンダーの提案を比べる場合は、2〜3ページの簡易版RFPを作る価値があります。「予算レンジ」「Must要件3つ」「評価基準3項目」だけでも明示すれば、口頭依頼に比べて見当違いの提案を防げます。

---

RFPを作成する5つのメリット

1. 要件を正確にベンダーへ伝えられる

RFPで要件を文書化することで、口頭では伝えきれない詳細な条件や背景情報をベンダーに正確に伝えられます。「言った・言わない」のトラブルを未然に防ぎ、提案の精度が大幅に向上します。背景・課題・目的・期待効果まで構造化して伝えることで、ベンダーは表面的な機能要件ではなく「課題解決のアプローチ」を提案できるようになります。

2. 複数社の提案を公平に比較できる

同一のRFPに基づく提案は、フォーマットや回答範囲が揃うため、横並びで比較しやすくなります。Responsive社が2025年にB2Bバイヤー350名を対象に実施した調査によると、B2B購買者の81%がベンダーのRFP回答は最終意思決定に「非常に大きい」または「極めて大きい」影響を与えると回答しています（Responsive, "Inside the Buyer's Mind", 2025年調査）。RFP回答の質が意思決定を左右する以上、回答フォーマットの統一は買い手側にとって必須の前提条件です。

3. プロジェクトのトラブルを未然に防げる

要件・スコープ・予算・スケジュールが文書化されることで、プロジェクト開始後の「聞いていなかった」「想定外だった」という認識の齟齬を大幅に減らせます。RFPはプロジェクト契約の基礎資料としても機能し、後工程での仕様変更による追加見積・スケジュール遅延を抑制します。

4. 自社の課題と要件を客観的に整理できる

RFP作成は、自社の現状課題を言語化し、理想像とのギャップを明確にするプロセスでもあります。このプロセスを通じて「そもそも何を解決したいのか」が組織内で共有され、プロジェクトの方向性が定まります。RFPを書くこと自体が要件定義のリハーサルになるのです。

5. 社内合意形成のツールになる

Gartnerが2024年に632名のB2B購買者を対象に実施した調査では、購買グループ内で合意形成できたチームは高品質な取引を達成する確率が2.5倍という結果が出ています（Gartner, 2025）。RFPは複数部門の関係者が「何を評価し、何を優先するか」を事前に議論するきっかけになり、選定後の社内反対を防ぐ役割を果たします。

---

RFPの構成要素7項目【何を書く欄か】

RFPに書く項目は、プロジェクト概要・現状課題・要件・予算・提案依頼事項・評価基準・制約条件の7つが基本です。

ここでは「それぞれ何を書く欄か」「書き漏れると何が起きるか」を要点だけ整理します。項目ごとの例文と、そのまま埋められるテンプレートは「RFPの書き方完全ガイド｜7項目テンプレ・5ステップ」にまとめています。案件規模や業種に応じて取捨選択してください。

7項目のうち、提案の質を最も左右するのは3の要件の優先度と6の評価基準です。要件は次の3段階で優先順位を明示します。

非機能要件は「高速」「安定」といった曖昧な表現を避け、数値で定義しましょう。予算を完全に非開示にすると、ベンダーが規模感を見誤り、要件に見合わない提案が集まるリスクがあります。評価基準は配点（ウェイト）を事前に設計し、RFP内で公開することを推奨します。配点ロジック・重み付け係数・スコア乖離時の議論プロトコルは、後述の「RFP評価マトリクスの作り方と実テンプレート」で解説します。

---

RFP作成から選定までの流れと期間の目安

RFPは、目的の整理からヒアリング・要件の分類・文書化・配布と質疑応答・評価の順に進め、全体で数週間〜数か月かかります。

各段階の具体的な書き方は「RFPの書き方完全ガイド」で5ステップに分けて解説しています。ここでは、全体の流れと期間の目安、各段階でつまずきやすい点だけを押さえます。

ステークホルダーマップの活用がポイントです。「誰が決裁するか」「誰が実際に使うか」「誰が予算を持つか」を整理し、キーパーソンの要望を漏れなく反映します。BANTフレームワークの考え方は、関係者の予算・決裁権を把握する際にも応用できます。ヒアリングの段取りは営業ヒアリングの極意で扱っている「事前準備→質問設計→記録→分析」のフローがそのまま使えます。

要件の分類では、すべてをMustにすると対応できるベンダーが激減し、見積金額が膨れ上がります。実務では「Mustが20件以内、Wantが30件以内」を目安に絞り込みます。Mustが多すぎるRFPは見積が膨張するか、対応可能ベンダーが1社しか残らず競合性を失います。

Q&Aのベストプラクティス：質問を一定期間に一括収集し、全ベンダーへ同時にQ&Aとして共有します。個別回答は情報格差を生むため避けましょう。Q&A受付期間はRFP配布後7〜10営業日、回答提示はその後3〜5営業日が標準です。

スコアリングの進め方：

1. 各評価者が独立してスコアを付ける（事前にすり合わせない）
2. スコアを集計し、大きく乖離した項目を議論する
3. プレゼン・デモで追加評価し、最終スコアを確定する
4. 上位1〜3社にRFQを発行し、詳細見積を取得する

---

【業種別】RFPで重視される項目の違い

同じRFPでも、Webサイト制作と基幹システム導入では重視すべき項目も予算開示の推奨度も大きく異なります。

Webサイト制作のRFPと基幹システム導入のRFPでは、重視すべき項目も予算開示の推奨度もまったく異なります。代表的な4業種について、記載項目の差を早見表で整理しました。業種ごとのサンプル文は「RFPの書き方完全ガイド」の業種別サンプルで紹介しています。

業種別RFPの違い早見表

業種ごとに押さえたいポイント

• Webサイト制作：機能要件よりもビジュアル・UX・SEO要件と保守体制が重視されます。「モダンなデザイン」のような形容詞ではなく参考サイトのURLと「どこが良いか」を示し、CMSの種類、既存サイトの順位維持、アクセシビリティ（WCAG 2.1 AA準拠の要否）、写真・動画素材の提供範囲を明確にします
• 基幹システム（ERP/会計）：最も慎重に書くべきRFPです。業務プロセスを部署単位ではなく「受注計上→請求→入金消込」のような機能単位で書き出し、フィットギャップ分析の方針（例: 標準機能採用率80%以上）、移行データの範囲、並行稼働期間、J-SOXなどの監査対応、保守体制（24/365か平日日中か、SLAレベル、災害対策）を示します。初期費用だけで判断せず、5年トータルコスト（TCO）の試算を依頼します
• SaaS選定（CRM/MA等）：カスタマイズではなく標準機能のフィットを評価します。SSO（SAML 2.0 / OIDC）やIDプロビジョニング（SCIM）、データ保管リージョン、APIのレートリミット、解約時のデータエクスポートの可否を必須項目にし、価格はライセンス費用だけでなくデータ容量やAPI呼び出し回数の体系まで求めます
• マーケティングツール：チャネル別の配信機能と効果測定の精度が選定基準です。月間配信数やピーク時の同時配信数、CRM・CDPとの連携、A/Bテストやアトリビューションの機能、特定電子メール法などのコンプライアンス対応を確認し、配信単価・保守費・サポート時間を合わせたトータルコストで比べます

---

【2026年版】AI（ChatGPT/Claude）でRFPを作成するワークフロー

2026年現在、RFP作成のあり方は生成AIによって大きく変わりつつあります。調達の現場では生成AIによる草案生成・要件分類・回答評価が標準ワークフローになりつつあります。

生成AI×調達の最新動向

AI at Wharton（ペンシルベニア大学ウォートン校）が2024年に発表した調査によると、調達部門の94%が2024年時点で週次以上の頻度で生成AIを利用しており、2023年の50%から44ポイント増加しています（Art of Procurement「State of AI in Procurement」（AI at Wharton 2024年データを引用））。

さらにDeloitteが実施した2025 Global CPO Surveyでは、最高調達責任者（CPO）の約42%が生成AIの主要ユースケースとしてRFP/RFQ生成を挙げています（Deloitte 2025 Global CPO Survey（Art of Procurement「State of AI in Procurement」より））。

RFPの草案づくりにAIを使うことは、調達の現場で一般的な選択肢になりつつあります。ここでは、ChatGPTやClaudeを使うときの進め方と注意点を整理します。

AIでRFP草案を作る4ステップ

1. インプット整理: 自社の課題、現状業務、関係者リスト、社内用語集をテキストで用意する
2. 草案生成: 「課題整理→要件抽出→Must/Want分類」までをAIに下書きさせる
3. 人間レビュー: 生成結果を関係部署に共有し、業務独自の文脈を補強
4. AIで再構造化: 修正されたRFPをAIで「ベンダー回答テンプレ」と「評価マトリクス」に展開

人間とAIの役割分担として、ファクト判断と固有名詞は人間、構造化と表現整形はAIが原則です。

プロンプト例（短縮版）

社名・人名・金額を伏せた素材を貼り付けて、次のように依頼します。

【例1：ヒアリングメモ → 要件の抽出と分類】
以下は社内ヒアリングのメモです（社名・人名・金額は[企業A][担当者X]に置換済み）。
1. 発言から業務上の課題を箇条書きで抽出してください。
2. 各課題を解決するために必要な要件を書き出し、Must（未対応なら選定対象外）/
   Want（対応すれば加点）/ Nice to Have（提案があれば評価）に分類してください。
3. 分類の理由を1行ずつ添え、判断できないものは「要確認」として質問文を作ってください。
---
（ヒアリングメモを貼り付け）

【例2：RFPドラフトのレビュー】
あなたはベンダー側の提案担当者です。以下のRFPドラフトを読み、
提案書を書くうえで「情報が足りず推測で書くしかない箇所」を指摘してください。
観点：目的とゴール / 対象範囲と対象外 / 予算レンジ / 評価基準と配点 /
質問の受付期限 / 既存システムとの連携条件。
指摘ごとに、発注側が追記すべき一文の案を示してください。
---
（RFPドラフトを貼り付け）

例2のように受け取る側の立場でレビューさせると、評価配点や対象外範囲の書き漏れが見つかりやすくなります。出力はあくまで草案なので、分類の妥当性や数値は必ず関係者が確認してください。

AI活用時の注意点 — 機密情報マスキング・ハルシネーション対策

生成AIを業務に組み込む際の最大のリスクは、機密情報の流出と**事実誤認（ハルシネーション）**です。

• 機密情報マスキング: 社内データを投入する前に、企業名・人名・金額・固有のシステム名を「[企業A]」「[担当者X]」のようなプレースホルダーに置換する。エンタープライズ向けの ChatGPT Team / Claude Enterprise はデータ学習に使われない契約になっているため、契約形態を確認したうえで使うのが望ましい
• ハルシネーション対策: 生成された数値・引用・規格名は必ず一次ソースで再確認する。特に「○○認証を取得している」「業界平均は○○%」など断定的な表現はAIが捏造しやすい
• 業界用語の補正: AIは一般的な業界用語に変換しがち。自社固有の用語集をプロンプトに添付し、表記揺れを防ぐ
• 意思決定はAIに任せない: AIは構造化と要約が得意だが、「どのベンダーを選ぶか」「どの要件をMustにするか」の最終判断は人間が責任を持つ

---

RFP評価マトリクスの作り方と実テンプレート

評価マトリクスは「ベンダー選定の透明性」を担保する最重要ツールです。ここでは配点ロジック・重み付け係数・スコア乖離時の議論プロトコルまで、選定の場でそのまま使える形で整理します。

評価項目の決め方

評価項目は5〜7個に絞ります。10個を超えると評価者の負担が大きくなり、配点も希釈されます。代表的な評価項目:

• 技術力・実現性: 要件の充足度、技術選定の妥当性
• 費用: 初期費用、運用費、5年TCO、コスト構造の透明性
• 実績・信頼性: 同業種・同規模の導入実績、顧客満足度
• 推進体制: PMの経験、担当者のスキル、リソースの厚み
• 提案の独自性: 課題解決の創意工夫、付加価値、業界知見
• 保守・サポート: SLA、対応時間、エスカレーションフロー
• 拡張性・将来性: ロードマップ、技術的負債への対応

配点と重み付け係数の設計

配点を合計100点に揃え、案件の性質に応じて項目間の重みを変えます。

重み付け係数の決め方: 経営層・現場・情シスの三者投票で各項目に「重要度1〜5」を付け、平均値を配点に換算します。

1. 評価項目候補を10個程度リストアップ
2. 経営層・現場代表・情シスの計3〜5名に「重要度1〜5」で評点を依頼
3. 平均点を算出し、合計が100になるよう正規化
4. 全評価者で結果を共有し、納得感がない項目を議論

評価マトリクスの実テンプレート

実際の評価シートはMarkdownでもExcelでも構いません。以下は4社×7項目のサンプル。

| 評価項目 | 配点 | A社 | B社 | C社 | D社 |
|---------|------|-----|-----|-----|-----|
| 技術力・実現性 | 25 | 22 | 18 | 24 | 20 |
| 費用 | 20 | 15 | 19 | 12 | 18 |
| 実績・信頼性 | 20 | 18 | 15 | 19 | 17 |
| 推進体制 | 15 | 13 | 12 | 14 | 11 |
| 提案の独自性 | 10 | 8 | 7 | 9 | 6 |
| 保守・サポート | 5 | 4 | 5 | 4 | 5 |
| 拡張性・将来性 | 5 | 4 | 3 | 5 | 4 |
| **合計** | 100 | 84 | 79 | 87 | 81 |

評価者が3人以上いる場合は、評価者×ベンダーのマトリクスを横展開し、平均値を最終スコアとします。

スコア乖離が大きい項目の議論プロトコル

評価者間でスコアが大きく乖離した項目（例: 評価者Aが25点、評価者Bが10点）は、認識のズレが潜んでいる可能性が高いポイントです。

1. 乖離項目のリスト化: 各項目で最大スコアと最小スコアの差が5点以上の項目を抽出
2. 個別ヒアリング: 最高点と最低点を付けた評価者それぞれに「なぜそのスコアか」を確認
3. 論点整理: 「事実認識のズレ」「重視する観点の違い」「情報量の差」のどれが原因かを分類
4. 追加情報収集: 必要に応じてベンダーへ追加質問を投げる
5. 再採点: 全評価者で同一情報を共有し、再度スコアを付ける

「総合スコア1位が必ず選ばれない」場合の判断基準

総合スコアと最終決定が一致しない場合は、以下のチェックポイントで判断します。

• Must要件の充足度: 総合1位でもMust要件を1つでも欠いていれば失格
• 戦略的フィット: 中長期の事業戦略との整合性（例: グローバル展開予定なら多言語対応が必須）
• リスク評価: 経営危機の懸念、訴訟履歴、データ漏えい事故などの有無
• 既存ベンダー関係: 既存システム保守ベンダーとの相性、引継ぎ難度
• 意思決定者の総合判断: スコアでは数値化できない要素（信頼関係、文化フィット）

総合スコア2位以下を選定する場合は、その判断根拠を社内文書として残すことが説明責任の観点から重要です。

ベンダーへのスコア開示・FBの作法

選定結果を受注ベンダーだけに通知し、落選ベンダーへの連絡を疎かにする企業が多いですが、これは長期的な関係を損ねます。全ベンダーに対して、スコアサマリーと講評を共有するのが望ましい慣習です。次回のRFPでも提案してもらえる関係を維持できます。

---

RFP作成でよくある失敗5パターンと対策

RFP作成の失敗は、プロジェクト全体のコスト超過やスケジュール遅延に直結します。よくある5つの失敗を、Before/After形式と「起こりがちな結果」で整理します。

1. 機能の羅列に終始し「なぜ必要か」が不在

Before：「ダッシュボード機能を有すること」「レポート出力ができること」「API連携が可能であること」と機能だけを列挙。

After：「営業マネージャーが週次会議で受注状況を即座に確認できるよう、リアルタイムダッシュボードを提供すること。現状は週3時間かけてExcelを集計しており、この工数を80%削減したい」と課題と目的をセットで記載。

ベンダーは「なぜ必要か」がわかれば、機能だけでなく課題解決のアプローチを提案できます。「課題→アプローチ→機能」の順で書くと、自然と「なぜ」が伝わります。

起こりがちな結果: 機能の羅列だけでRFPを出すと、各社が「機能を満たす最小構成」を提案しがちです。導入後に経営層の期待とずれていることが分かり、スコープ外の追加開発でコストが膨らみがちです。

2. 予算を非開示にして非現実的な提案が集まる

Before：予算を一切記載しない。結果として「100万円の案件に5,000万円の提案」が届き、時間を浪費する。

After：「予算の目安は初期費用500〜1,000万円、月額運用費50万円以内」とレンジで記載。完全な非開示よりも、ベンダーが規模感を把握でき、現実的な提案が集まります。

起こりがちな結果: 予算を伏せたままRFPを出すと、想定を大きく上回る見積が並び、社内承認や再RFPで選定が遅れがちです。予算レンジを示すほうが、各社の提案を同じ土俵で比べやすくなります。

3. 評価基準が不明確で選定が恣意的になる

Before：「総合的に判断します」とだけ記載。選定後にベンダーから「何で落とされたのかわからない」と不信感を持たれる。

After：評価マトリクス（技術力30点・費用25点・実績20点・体制15点・独自性10点）を事前に公開。ベンダーは配点が高い項目に注力でき、発注側も一貫性のある評価ができます。

起こりがちな結果: 評価基準を後から決めると、ベンダーから選定プロセスの公平性を問われ、説明に追われることになりがちです。RFP配布時点で評価基準を確定させておくことが、後のトラブル防止につながります。

4. 情シス単独で作成し現場ニーズが反映されない

Before：IT部門だけでRFPを作成。導入後に営業部門から「使いにくい」「必要な機能がない」と不満が噴出。

After：プロジェクトチームに事業部門・経営層・現場代表を含め、各部門のヒアリング結果をRFPに反映。特に「実際に毎日使う人」の声を要件に組み込むことで、導入後の定着率が大きく変わります。

現場参加の目安: 主要部署から最低1名ずつ、合計5〜10名で構成する。役職別では「マネージャー1〜2名 + メンバー2〜3名 + 経営層1名」のミックスが理想的です。

起こりがちな結果: IT部門だけでRFPを作ると、現場の業務フローに合わない製品を選んでしまうことがあります。導入後に使われず、追加のカスタマイズや再教育で当初の予算を超える原因になります。

5. RFP提出後に要件を追加してしまう

Before：提案書提出後に「やっぱりこの機能も必要」と追加要件を出す。ベンダーは再見積が必要になり、スケジュールが崩壊。

After：要件フリーズのタイミングを事前に設計します。「RFP配布日をもって要件を確定とし、以降の変更はRFP改訂として全ベンダーに同時通知する」とルール化しましょう。Q&A期間中に出てきた新たなニーズは「次フェーズ要件」として切り分けます。

起こりがちな結果: RFPを出した後に要件を追加すると、対応工数が読めないベンダーが辞退し、残った少数の会社としか交渉できず、価格交渉力を失います。

---

RFP作成・配布チェックリスト（発注側）

ここまでの内容を、発注側の行動チェックリストに落とし込みます。

作成前

• プロジェクトの目的・背景を経営課題と紐づけて言語化した
• ステークホルダーマップを作成し、関係者を漏れなく洗い出した
• 関係部署のヒアリングが完了している（情シス単独で作成していない）

作成中

• 課題を「現状→理想→ギャップ」で言語化した
• 要件を「Must / Want / Nice to Have」の3段階に分類した
• Must要件が20件以下に絞り込まれている
• 非機能要件を数値で定義した（曖昧表現の排除）

配布前

• 評価基準に配点（ウェイト）を明示した
• 予算の開示範囲を社内で合意した
• 業務担当・IT・法務・経営の社内レビューが完了している
• 提案書フォーマット・ページ数・提出方法を明示した

質疑応答

• Q&Aのスケジュールと回答方法を設計した
• 質問は一括収集・一斉回答を徹底している
• 個別ベンダーへの追加情報提供は行っていない

評価

• 評価者を複数人で構成し、独立して採点する仕組みを準備した
• スコア乖離項目の議論プロトコルを定めた
• 落選ベンダーへの結果通知・フィードバックを準備した
• 要件フリーズのタイミングを明記した

---

RFPを受け取った側（受注側）の読み方

RFPを受け取った制作会社・開発会社は、提案を書く前に「出るかどうか」を判断し、評価配点・質問期限・前提条件・対象外の範囲を読み取ります。

ここからは、RFPを受け取ったベンダー（制作会社・開発会社・コンサルティング会社など）の視点です。RFPを出す側にとっても、受け取った側がどこを読むかを知っておくと、伝わるRFPを書きやすくなります。

最初に確認する5つの欄

RFPを受け取ったら、本文を頭から読む前に次の5つを確認します。ここを読み落とすと、提案の方向がずれるだけでなく、受注後に「それも含まれていると思っていた」という範囲の食い違いが起きます。

特に重要なのが対象範囲と対象外の範囲です。RFPに「対象外」が書かれていない場合は、質問期間のうちに「この作業は範囲に含まれますか」と確認し、回答を提案書の前提条件に書き写しておきます。契約後に依頼が少しずつ広がっていく現象は「スコープクリープ」と呼ばれ、受託側の採算を大きく崩します。線引きの方法は「スコープクリープとは？意味・原因と、受託案件で追加依頼を線引きする方法」で文例つきで解説しています。

Bid / No-Bid 判断の5軸

すべてのRFPに対応する必要はありません。Loopio社のRFP対応ベンチマークによると、チームの平均RFP勝率は39%、2019〜2026年の実績データでは45%とされています（Loopio, RFP Statistics & Win Rates）。半分以上は勝てない前提で、限られたリソースを勝率の高い案件に集中させるため、以下の5軸で対応可否を判断しましょう。

MarketingProfsが紹介したResponsive社の調査（2025年、B2B購買者350名）によると、B2B購買者の16%は「どの結果になってもこのベンダーを選ぶ」と決めた状態でRFPを発行しています（MarketingProfs, 2026）。要件が特定ベンダーの仕様に偏っている、Q&Aへの回答が形式的、選定スケジュールが不自然に短い場合はアリバイRFPの可能性があります。

RFP行間の読み解き方

• 評価基準の配点を読む：技術力の配点が高ければ革新的なアプローチを、費用の配点が高ければコスト最適化を軸に提案する
• 課題の背景を推測する：「現状のシステムを刷新したい」とあれば、なぜ今なのか（経営方針の変更？トラブル発生？競合の動き？）を考える
• 除外条件から読む：「クラウドのみ」と書かれていればオンプレは除外。制約条件の裏には必ず理由がある

エンタープライズ案件ではMEDDICフレームワークを活用し、意思決定プロセス・経済的購買者・決定基準を把握した上で提案を組み立てると勝率が上がります。ソリューション営業のアプローチも、RFPの要件を顧客の商談プロセスと紐づけて理解する際に有効です。

提案書のフレームワーク

1. 要件対応表を作成する：RFPの要件を一覧化し、「対応可能 / 条件付き対応可能 / 対応不可 / 代替提案あり」の4段階で回答
2. 課題→アプローチ→成果のストーリーを構築する：発注企業の課題を起点に、自社のソリューションがどう解決し、どんな成果をもたらすかを論理的に展開
3. 類似実績を具体的に示す：同業種・同規模の実績を「課題→導入→成果」のフレームで提示

詳細はB2B提案書の書き方完全ガイドと営業提案書テンプレート20選で扱っています。RFP回答の書き方（要件対応表の4段階回答、価格提示の作法、Q&A戦略）は「RFPの書き方完全ガイド」の受注側パートにまとめています。RFP対応が多い組織では、過去の回答を再利用できるRFP対応・管理ソフトの活用も選択肢です。

RFP対応の資料とQ&Aを1か所にまとめる

メールにファイルを添付する従来のRFP対応では、版管理が煩雑になり、「古い版の提案書を評価された」「添付ファイルの容量制限で送信できない」といった問題が起きがちです。RFP原本・要件対応表・提案書・参考事例・Q&Aを1つのURLにまとめ、常に最新版を参照してもらう方法があります。売り手と買い手が資料や検討状況を1つのオンライン空間で共有する考え方は「デジタルセールスルーム」とも呼ばれ、「デジタルセールスルームとは」で詳しく解説しています。ツール選定の観点はデジタルセールスルーム比較と提案書共有ツール選定ガイドで解説しています。

受注した後も、RFPで約束した範囲・Q&Aでの回答・キックオフで決めたことを顧客と同じ場所で見られるようにしておくと、「言った言わない」や手戻りを防げます。立ち上がりで決めておく項目は「キックオフミーティングの進め方」で整理しています。

---

よくある質問（FAQ）

---

まとめ：RFPの意味と、次に読む記事

RFP（アール・エフ・ピー）は、発注側が課題・要件・評価基準を示し、ベンダーに解決策と費用の提案を求める「提案依頼書」です。RFIは情報、RFPは提案、RFQは見積を求める文書で、一般的にはRFI → RFP → RFQ の順に候補を絞り込みます。RFPはベンダーを選ぶための「問い」であり、契約後に作るものを確定させる要件定義書や、ベンダーが返す提案書・見積書とは役割が異なります。

仕様が決まった小さな発注ならRFQや相見積もりで足り、実現できるかどうかが分からない段階なら先に小さく検証するのが近道です。RFPを書くと決めたら、7項目のうち評価基準の配点と予算レンジを先に社内で合意し、評価マトリクスで選定の透明性を確保しましょう。受け取る側は、提案を書く前に評価配点・質問期限・前提条件・対象外の範囲を確認することで、受注後の範囲の食い違いを防げます。

状況別に次に読む記事

質の高いRFPは、プロジェクトの成否を左右するだけでなく、関わる人全員の認識を揃え、ベンダーとの長期的な信頼関係を築く起点になります。まずは「何に困っていて、何ができれば成功か」を1文で書くことから始めてみてください。