RFP（提案依頼書）とは？書き方・7項目テンプレと評価マトリクス【2026年版】

この記事の要点

• RFPは発注側と受注側の「共通言語」——要件・評価基準を文書化することで認識のズレを防ぎ、公正なベンダー選定を実現する
• RFI → RFP → RFQ の順で候補を絞り込む。要件の確度に応じて使い分ける
• 構成要素は7項目（プロジェクト概要・現状課題・要件・予算・提案依頼・評価基準・制約条件）
• 業種別に重視項目が異なる（Webサイト制作 / 基幹システム / SaaS選定 / マーケティングツール選定）
• 2026年は生成AIの活用が標準化。CPO（最高調達責任者）の約42%がRFP/RFQ生成にAIを使っている（Deloitte 2025 Global CPO Survey）
• 評価マトリクスで配点と重み付けを設計することで属人的な選定を排除できる
• **DSR（デジタルセールスルーム）**でRFP関連資料の一元管理・閲覧分析・Q&A管理を効率化できる

「RFPを出したいが何を書けばいいかわからない」「テンプレートだけほしい」「業種が違うと書き方も違うのか」——B2B購買の現場ではこうした声が絶えません。本記事では、RFPの定義と書き方の王道を押さえたうえで、**他のRFP解説記事ではほぼ触れられていない「業種別の書き方の違い」「AI活用ワークフロー」「評価マトリクスの実テンプレート」**まで、20,000字超で網羅的に解説します。

なお、ベンダー（受注側）の営業担当者向け対応ガイドは記事末尾の補足セクションにまとめました。発注側の方は本文のSTEP1〜評価マトリクスを順にお読みください。

---

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

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

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

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

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

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

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

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

RFPが使われる場面・業界

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

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

Gartnerの調査によると、B2B購買の意思決定に関わるステークホルダーは平均6〜10人に上り、複数部門にまたがる5つ以上のビジネス機能から構成されます（Gartner, The B2B Buying Journey）。このような複雑な意思決定構造の中で、RFPは関係者間の評価基準を統一するための不可欠なツールとして機能します。

---

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

3つの文書は混同されやすいですが、目的・タイミング・対象社数がまったく異なります。

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

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

RFQ（見積依頼書）とは

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

RFPの構成要素7項目【テンプレート付き】

RFPに含めるべき7つの構成要素を、記載例とNG例を交えて解説します。案件規模や業種に応じて取捨選択してください。

1. プロジェクト概要（背景・目的・ゴール）

プロジェクトの「Why（なぜ）」を明確にするセクションです。ベンダーがこのセクションを読んだ瞬間に「なぜこのプロジェクトが必要なのか」を理解できる粒度で記述します。

【良い例】
目的：受注管理のリアルタイム化により、営業部門の週次報告作成工数を80%削減し、
データに基づく迅速な経営判断を可能にする。

背景：現状は受注情報をExcelで管理しているため、週次会議の前に
担当者3名が合計9時間をかけて集計している。
2026年下期の上場準備に向けて、IR向けの月次クロージング期間を
5営業日以内に短縮する経営目標があり、その制約条件として
リアルタイム集計の仕組みが必要。

【NG例】
目的：受注管理システムの導入。
→ 「なぜ導入するのか」が不明で、ベンダーは提案の方向性を判断できない。

2. 現状の課題と理想像（As Is / To Be）

「現状→理想→ギャップ」のフレームで記載すると、ベンダーが課題の本質を理解しやすくなります。

【現状（As Is）】
受注管理をExcelで行っており、週次更新に担当者が3時間かけている。
データの属人化が進み、担当者不在時に最新情報を確認できない。
営業マネージャーが個別に「最新の数字は？」と確認する電話・チャットが
1日10件以上発生している。

【理想（To Be）】
リアルタイムで受注状況が全社から閲覧でき、営業全員が最新データに
アクセスできる。マネージャーは個別確認なしに会議で意思決定ができる。

【ギャップ】
リアルタイム更新の仕組みがなく、データの鮮度・アクセス性に課題がある。
属人化を解消するため、誰でも編集・閲覧できる権限管理も必要。

3. 機能要件・非機能要件

要件はMust（必須）/ Want（推奨）/ Nice to Have（任意） の3段階で優先順位を明示します。

非機能要件（レスポンスタイム、稼働率、セキュリティ基準など）も数値で定義しましょう。「高速」「安定」といった曖昧な表現は避け、「ページ表示3秒以内」「稼働率99.9%以上」と具体化します。セキュリティ要件は ISMS（ISO 27001）認証や Pマーク、SOC2 Type 2 など、保有を求める認証を具体的に指定します。

4. 予算・スケジュール・体制

予算はレンジ表記でも構いません。予算を完全に非開示にすると、ベンダーが規模感を見誤り、要件に見合わない提案が集まるリスクがあります。

• 費用の記載形式：初期費用／月額費用／保守費用を分離して記載を依頼
• スケジュール：RFP提出期限・Q&A回答期日・選定完了予定日・プロジェクト開始日を逆算で設計
• 体制：発注側のプロジェクトオーナー・PM・各部門代表を明記

5. 提案依頼事項（提案書に含めてほしい内容）

提案書の提出形式、必須記載事項、ページ数の目安、提出期限と提出先を明示します。フォーマットを指定することで、比較の手間を大幅に減らせます。記載例:

• 提案書のページ数: 30〜50ページ
• 必須記載事項: ソリューション概要 / 機能対応表 / 推進体制 / スケジュール / 見積（初期・月額・5年トータル） / 類似実績3件以上
• 提案書フォーマット: PDF（Word / PowerPoint 添付可）
• 提出先と提出方法: プロジェクト事務局（メール添付 or DSRリンク）

6. 評価基準と選考プロセス

RFPで最も重要なのが評価基準の明示です。配点（ウェイト）を事前に設計し、RFP内で公開することを推奨します。配点ロジック・重み付け係数・スコア乖離時の議論プロトコルなど詳細は、後述の「RFP評価マトリクスの作り方と実テンプレート」セクションで解説しているため、本項では押さえておくべき記載要素のみ提示します。

• 評価項目と配点（例: 技術力30 / 費用25 / 実績20 / 体制15 / 独自性10 = 合計100点）
• 選考プロセス（書類評価→プレゼン→デモ→最終選定）
• 評価者の構成（人数・部署・経営層の関与）
• 結果通知方法と落選ベンダーへのフィードバック方針

7. 制約条件・前提条件

既存システムとの連携要件、セキュリティ基準、社内規定による制約（特定クラウドの利用不可など）、NDAの要否を明記します。制約条件を事前に共有することで、対応不可能なベンダーの工数を無駄にしません。

代表的な制約条件:

• データ保管場所: 国内リージョン限定 / 海外リージョン可
• 連携必須システム: SalesforceとのAPI連携必須、Slack通知必須
• 社内承認体制: 取締役会承認が必要なため、契約締結まで2か月の社内手続き
• 法規制: 個人情報保護法、GDPR、業界特有のガイドライン

【DL】Markdown形式のRFPテンプレート

以下をコピーして自社用にカスタマイズしてください。発注側はこのテンプレに沿って記入し、ベンダーへ展開できます。

# RFP（提案依頼書）

## 1. プロジェクト概要
- プロジェクト名:
- 発注組織:
- プロジェクトオーナー:
- 背景:
- 目的:
- 期待効果（KPI）:

## 2. 現状の課題と理想像
- As Is（現状）:
- To Be（理想）:
- ギャップ（課題）:

## 3. 機能要件・非機能要件
### Must（必須）
-
### Want（推奨）
-
### Nice to Have（任意）
-
### 非機能要件
- 稼働率:
- レスポンスタイム:
- セキュリティ基準:
- データ保管場所:

## 4. 予算・スケジュール・体制
- 予算レンジ: 初期 ___万円 / 月額 ___万円
- スケジュール:
  - RFP提出期限:
  - Q&A回答期日:
  - プレゼン審査:
  - 選定完了:
  - 契約締結:
  - プロジェクト開始:
- 体制（発注側）:
- 体制（ベンダー要望）:

## 5. 提案依頼事項
- 提案書ページ数:
- 必須記載事項:
- 提出形式:
- 提出先:

## 6. 評価基準と選考プロセス
- 評価項目と配点:
- 選考プロセス:
- 結果通知:

## 7. 制約条件・前提条件
- 既存システム連携:
- 法規制対応:
- NDA:
- その他:

このMarkdownテンプレートはGoogleDocs / Notion / Confluence のいずれにもそのまま貼り付けて利用できます。

---

RFP作成の手順【7ステップで解説】

Step 1. プロジェクトの目的と背景を整理する

「なぜこのプロジェクトが必要か」を経営課題と紐づけて言語化します。前述の「現状→理想→ギャップ」フレームで整理すると、関係者間の認識が揃いやすくなります。所要日数の目安は3〜5営業日。経営層の意思確認を含めると2週間かかることもあります。

Step 2. 関係部署へのヒアリングで現状課題を洗い出す

情シス単独ではなく、事業部門・経営層・現場担当者を含むプロジェクトチームを結成します。各部署の課題・要望を構造化して整理し、優先順位を付けましょう。

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

ヒアリング所要日数の目安は7〜10営業日（部署数×2営業日が目安）。

Step 3. 要件を定義する（Must / Want / Nice to Have）

ヒアリング結果を基に、要件を3段階に分類します。すべてをMustにすると対応できるベンダーが激減し、見積金額が膨れ上がります。本当に譲れない要件だけをMustにする勇気が重要です。

実務では「Mustが20件以内、Wantが30件以内」を目安に絞り込みます。Mustが多すぎるRFPは見積が膨張するか、対応可能ベンダーが1社しか残らず競合性を失います。

Step 4. RFIで市場調査・候補ベンダーを絞り込む

要件が広範な場合は、まずRFIで10〜15社から情報を収集し、対応可能なベンダーを3〜5社に絞り込んでからRFPを発行します。すでに候補が明確な場合はこのステップを省略できます。RFI実施から回答受領まで2〜3週間が目安です。

Step 5. RFP文書を作成する

前述の7つの構成要素に沿って作成します。業務担当者・IT部門・法務部門・経営層のレビューと承認を得ましょう。特に「予算の開示範囲」と「評価基準の配点」は社内で合意しておく必要があります。

ドラフト作成は3〜5営業日、社内レビューと修正で5〜10営業日が一般的です。

Step 6. ベンダーへ配布し、質疑応答期間を設ける

RFPの配布は**クローズド（招待制）**が一般的です。配布から提出期限までは最低2〜3週間を確保します。

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

Step 7. 提案書を評価マトリクスでスコアリングする

Step 6で設計した評価基準に基づき、各提案にスコアを付けます。評価者は複数人で行い、個人の主観を平均化することで公正性を担保します。

スコアリングの進め方：

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

評価期間は提案受領から2〜3週間、プレゼン審査を含めると4週間が目安です。

---

【業種別】RFPの記載項目マトリクス

RFP解説記事の多くは「一般論」のみで、業種ごとの違いに踏み込みません。しかしWebサイト制作のRFPと基幹システム導入のRFPでは、重視すべき項目も予算開示の推奨度もまったく異なります。代表的な4業種について、記載項目の差を整理しました。

業種別RFPの違い早見表

まずは4業種の主要差を一覧で把握してください。各業種の詳細解説は早見表の下に続きます。早見表で全体像を掴んでから、自社案件に該当する業種のセクションだけを読み込めば効率的です。

以降の業種別セクションでは、上記早見表を踏まえて「具体的にどんな項目を書けばよいか」「どんな観点で判断すべきか」を解説します。早見表の数値・推奨度は重複して列挙せず、書くべき項目と注意点に絞っています。

Webサイト制作のRFP — 重視すべき項目

Webサイト制作のRFPでは、機能要件よりもビジュアル・UX・SEO要件と保守体制が重視されます。

必須記載項目

• 制作対象: コーポレートサイト全面リニューアル / ランディングページ / ECサイト
• デザイン要件: ブランドガイドラインの有無、デザインの方向性（参考サイト3〜5本）
• CMS要件: WordPress / Headless CMS / フルスクラッチ、編集者の習熟度
• SEO要件: 既存サイトの順位維持、Core Web Vitalsの基準値
• アクセシビリティ: WCAG 2.1 AA準拠の必須・推奨
• 多言語対応: 対象言語数、翻訳の発注先
• 制作後の保守: 月次更新の規模、運用ドキュメントの整備
• 既存システム連携: 顧客管理、フォーム連携、解析ツール

注意点

• 「モダンなデザイン」「使いやすい」など曖昧な形容詞を避け、参考サイトのURLと「ここが良い」のポイントを具体的に
• 公開日から逆算したマイルストーン（要件定義 / デザインカンプ / コーディング / テスト / 公開）を提示
• 写真・動画素材の提供範囲を明確化（自社提供 / 制作会社手配 / ストック素材活用）

基幹システム（ERP/会計）導入のRFP — 重視すべき項目

最も慎重に書くべきRFPです。業務プロセスを100+の粒度で書き出し、各機能の対応可否を求めます。

必須記載項目

• 対象業務: 会計 / 販売管理 / 購買管理 / 在庫管理 / 人事給与 / 生産管理
• 現状の業務フロー: As Is業務フロー図、業務量（取引数 / 月、ユーザー数）
• フィットギャップ分析の方針: 標準機能採用率の目標（例: 80%以上）
• カスタマイズ方針: アドオン許容 / 標準機能で吸収する方針
• 移行データ: 過去何年分を移行するか、移行方法（CSV / API）
• 並行稼働期間: 旧システムと新システムの並行稼働の有無
• セキュリティ: ISMS、Pマーク、SOC2、業界別ガイドライン（金融・医療等）
• 監査対応: J-SOX、内部統制対応の有無
• 保守体制: 24/365 / 平日日中、SLAレベル、災害対策

注意点

• 業務プロセスは部署単位ではなく「機能単位」で記載する（「営業部」ではなく「受注計上→請求→入金消込」）
• 5年トータルコスト（TCO）の試算を依頼。初期費用だけで判断しない
• 並行稼働期間中の二重コストと、ベンダー側のサポート体制を必ず確認する

SaaS選定（CRM/MA等）のRFP — 重視すべき項目

SaaSは標準機能の充実度が高いため、カスタマイズではなく標準機能のフィットを評価します。

必須記載項目

• 対象SaaS分類: CRM / SFA / MA / カスタマーサポート / 名刺管理
• 想定ユーザー数: ライセンス購入数、ロール別ユーザー数
• 必須連携: SSO（SAML 2.0 / OIDC）、IDプロビジョニング（SCIM）、Slack、メール、SFA連携
• データ保管要件: 国内リージョン必須 / 海外リージョン可、データ削除のSLA
• API要件: REST / GraphQLの提供有無、レートリミット、Webhookの種類
• セキュリティ認証: SOC2 Type 2、ISMS、Pマーク
• 拡張性: カスタムオブジェクト、Workflow、AppExchange的なエコシステム
• データポータビリティ: 解約時のデータエクスポート、料金、フォーマット
• AI機能: 標準提供AI機能の評価、データ学習の有無

注意点

• SaaSは「導入してから3か月で評価」が現実的。導入後の伴走支援（カスタマーサクセス）の体制を明示的に依頼
• 既存顧客の継続率（NRR）、ARR成長率、IRレポートなどから企業の安定性を評価
• 価格はライセンス費用だけでなく、データ容量、API呼び出し回数、追加モジュールの体系を求める

マーケティングツール選定のRFP — 重視すべき項目

マーケティングツールはチャネル別の配信機能と効果測定の精度が選定基準です。

必須記載項目

• ツール分類: メール / SMS / プッシュ通知 / 広告 / SNS / コンテンツ管理
• 配信規模: 月間配信数、ピーク時の同時配信数、対象顧客数
• セグメント条件: RFM、行動履歴、属性、外部データ連携
• 連携必須システム: CRM（Salesforce、HubSpot）、CDP、データウェアハウス
• 効果測定: A/Bテスト、コンバージョン計測、UTM管理、アトリビューション
• 配信品質: 到達率、開封率の業界平均と保証値
• コンプライアンス: 特定電子メール法、特定商取引法、GDPR
• AI機能: 件名最適化、配信時間最適化、レコメンドAI
• 担当者教育: 操作研修、認定資格制度の有無

注意点

• 配信数が多い場合は「配信単価」「保守費」「サポート対応時間」のトータルコストで評価
• 競合のマーケティングツールとの連携可否（例: Adobe Experience CloudとSalesforce Marketing Cloud）も確認
• 成果報酬型と固定料金型の見積を並行で取得して比較

---

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

2026年現在、RFP作成のあり方は生成AIによって大きく変わりつつあります。多くのRFP解説記事はこの変化に触れていませんが、調達現場では生成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」より））。Gartnerも2025年10月に公開した「Top Predictions for IT Organizations and Users in 2026 and Beyond」の中で、エージェント型AIがITソーシング・調達・ベンダー管理を変革していくと予測しています（Gartner, 2026年予測プレスリリース, 2025年10月21日）。

つまり「AI抜きでRFPを書く」のはもはや少数派になりつつあるのです。本セクションでは、ChatGPTやClaudeで活用できる実用的なプロンプトを紹介します。

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

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

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

【プロンプト例1】課題整理 → 要件抽出

あなたはB2B調達のシニアコンサルタントです。以下の社内ヒアリングメモから、
新システム導入の要件を抽出し、Must/Want/Nice to Haveの3段階に分類してください。

【ヒアリングメモ】
{ヒアリングの議事録テキスト}

【出力フォーマット】
1. 解決すべき課題（3〜5個、優先度順）
2. 機能要件
   - Must: 業務継続に不可欠な機能
   - Want: 効率化に効く機能
   - Nice to Have: 将来検討してもよい機能
3. 非機能要件（稼働率・レスポンス・セキュリティ）
4. 隠れた要件・前提条件（メモから読み取れる暗黙の前提）

ヒアリングメモの代わりに、社内Wiki・既存業務マニュアル・経営計画書を投入することもできます。

【プロンプト例2】要件を Must/Want/Nice to Have に分類

以下の機能要件リストを、Must/Want/Nice to Haveの3段階に再分類してください。
判断基準は次の通り:
- Must: 未対応なら選定対象外。業務が継続できない or 法規制違反になる
- Want: あれば加点。生産性が大きく向上するが、なくても運用可能
- Nice to Have: 将来検討してもよい。今期は必須ではない

【機能要件リスト】
{要件リスト（箇条書き）}

【出力】
| 要件 | 分類 | 判断理由 |
|------|------|---------|

Mustが20件を超える場合は、Mustの中で更に優先度をつけて上位20件を選んでください。

要件のMust肥大化を抑える「Must上限20件ルール」を AIに守らせるのがポイントです。

【プロンプト例3】ベンダー回答を評価マトリクスへ変換

以下のベンダー提案書（4社分）を、評価マトリクスとしてMarkdownの表形式に
変換してください。評価項目と配点は次の通りです。

【評価項目と配点】
- 技術力・実現性: 30点
- 費用: 25点
- 実績・信頼性: 20点
- 推進体制: 15点
- 提案の独自性: 10点

【ベンダー提案テキスト】
- A社: {提案テキスト}
- B社: {提案テキスト}
- C社: {提案テキスト}
- D社: {提案テキスト}

【出力フォーマット】
| 評価項目 | 配点 | A社 | B社 | C社 | D社 |
|---------|------|-----|-----|-----|-----|

スコア下に「採点根拠（30字以内）」も併記してください。

提案書がPDFの場合は、テキスト抽出してから AIに渡します。Claude や ChatGPT のファイル添付機能でも処理可能ですが、機密情報の取り扱いには注意が必要です。

【プロンプト例4】RFPレビューチェックリスト生成

以下のRFPドラフトをレビューしてください。次の観点でチェックリストを生成し、
それぞれ「OK」「要改善」「致命的」の3段階で評価してください。

【観点】
1. 目的が経営課題と紐づいているか
2. 課題がAs Is / To Beで構造化されているか
3. 要件がMust/Want/Nice to Haveに分類されているか
4. 評価基準に配点が明示されているか
5. 予算レンジが提示されているか（または非開示の理由が明確か）
6. 非機能要件が数値化されているか
7. Q&Aと提出のスケジュールが提示されているか
8. 制約条件（既存システム、法規制）が明示されているか
9. 提案書のフォーマットとページ数が指定されているか
10. 評価結果のFB方法が記載されているか

【RFPドラフト】
{RFPドラフト全文}

レビュー結果が「要改善」「致命的」を含む場合は、AIに具体的な修正提案を依頼します。

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

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

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

---

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

評価マトリクスは「ベンダー選定の透明性」を担保する最重要ツールです。Must/Want/Nice to Have の概念は多くの記事で紹介されますが、配点ロジック・重み付け係数・スコア乖離時の議論プロトコルまで踏み込んで解説する記事はまだ少数です。

評価項目の決め方

評価項目は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作成の失敗は、プロジェクト全体のコスト超過やスケジュール遅延に直結します。競合上位記事では失敗パターンの具体的な解説が不足しているため、Before/After形式に加え数値の被害例を示します。

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

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

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

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

典型的な被害例: 機能の羅列だけでRFPを発行した結果、全ベンダーが「機能を満たす最小構成」を提案。導入後に経営層から「これでは経営判断に使えない」と指摘され、初期スコープ外の追加開発で初年度コストが約30%増加した、というケースが報告されています。

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

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

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

典型的な被害例: 中堅製造業A社では、予算非開示でRFPを発行した結果、想定の1.8倍に相当する見積が複数社から提示されました。社内承認に時間を要し、再RFPで実質的に3か月遅延。最終的に予算レンジを開示した再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部門単独でSaaS選定のRFPを作成した結果、現場の業務フローと合わない製品を導入。半年後の利用率が想定の3割程度に留まり、追加カスタマイズと再教育のコストが当初予算の1.5倍に膨らんだ、というケースが調達担当者の体験談として共有されています。

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

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

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

典型的な被害例: 大企業B社では、RFP提出後に要件を3回追加した結果、5社にRFPを出したうち4社が「対応工数が見えない」と辞退。残る1社の独占交渉になり、価格交渉力を失いました。要件の後出しは、調達における最大級の悪手とされます。

---

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

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

作成前

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

作成中

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

配布前

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

質疑応答

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

評価

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

---

よくある質問（FAQ）

---

【補足】ベンダー（受注側）がRFPを受け取ったら

ここからは受注側（営業担当者）の視点で、RFPへの対応の要点を簡潔にまとめます。詳細は専用記事を別途用意していますので、本記事ではエッセンスのみご紹介します。

Bid / No-Bid 判断の5軸

すべてのRFPに対応する必要はありません。Loopio社の2025年調査によると、**一般的なチームの平均RFP勝率は39%**で、長期ベンチマーク（2019〜2026年の累積）では45%とされています（Loopio, RFP Statistics & Win Rates）。限られたリソースを勝率の高い案件に集中させるため、以下の5軸で対応可否を判断しましょう。

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

RFP行間の読み解き方

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

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

提案書のフレームワーク

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

詳細はB2B提案書の書き方完全ガイドと営業提案書テンプレート20選で扱っています。

DSRでRFP対応資料を一元管理

メールにファイルを添付する従来のRFP対応では、版管理が煩雑になり、「古い版の提案書を評価された」「添付ファイルの容量制限で送信できない」といった問題が起きがちです。デジタルセールスルーム（DSR）を活用すると、RFP原本・要件対応表・提案書・参考事例・Q&Aをすべて1つのURLに集約でき、常に最新版が参照されます。閲覧トラッキング機能で発注側の検討状況も可視化できます。ツール選定の観点はデジタルセールスルーム比較と提案書共有ツール選定ガイドで解説しています。

---

まとめ：今日からRFPを動かすための次の一歩

ここまで20,000字超にわたってRFPの全体像を解説してきました。最後に「明日から何をするか」を具体的なアクションに落とし込みます。冒頭の「この記事の要点」と重複する論点には触れず、読了後すぐ動くためのチェックリストとして活用してください。

今週やる: 自社の状況に当てはめて準備する

1. プロジェクト関係者を5〜10名特定し、ステークホルダーマップを作成する
2. 自社案件の業種を「Webサイト制作 / 基幹システム / SaaS選定 / マーケツール選定」のいずれかに分類し、対応するセクションを再読する
3. 本記事内のMarkdown版RFPテンプレートを GoogleDocs / Notion / Confluence にコピーし、目次だけ仮で埋める

今月やる: ドラフト作成と社内合意

1. ヒアリングを部署単位で実施し、要件をMust/Want/Nice to Haveの3分類で記録する
2. 評価マトリクスを「経営層・現場・情シスの三者投票」で組み立てる
3. AIプロンプト例1〜4を使ってドラフトをレビューし、抜け漏れを補強する
4. 法務・経営の承認を得たうえで配布先ベンダー3〜5社を確定する

配布前の最終チェック

• 「RFP作成・配布チェックリスト（発注側）」の全項目をクリアしているか
• 失敗5パターン（機能羅列 / 予算非開示 / 評価基準曖昧 / 情シス単独 / 要件後出し）の罠を踏んでいないか
• 受注側からの「課題理解の質問」を歓迎できるよう、Q&A窓口とスケジュールを公開しているか

さらに学ぶ

• 関係者ヒアリングの質を上げる → 営業ヒアリングの極意 / BANTフレームワーク
• 受注側として勝率を上げる → B2B提案書の書き方完全ガイド / MEDDICフレームワーク / ソリューション営業
• 提案書共有とトラッキングを効率化 → デジタルセールスルームとは / DSR比較 / 提案書共有ツール選定

質の高いRFPは、プロジェクトの成否を左右するだけでなく、関わる人全員の認識を揃え、ベンダーとの長期的な信頼関係を築く起点になります。本記事のテンプレートとプロンプトを起点に、まずは1案件、書いてみてください。