評価項目から逆算するRFP回答書プロンプト｜抜け漏れを防ぐ構成テンプレート
RFP（提案依頼書）への回答書を作るとき、AIに最初から本文を書かせる必要はありません。先に作るべきなのは、RFPの評価項目と回答書の各章を対応させた構成案です。
このプロンプトは、提案営業、入札対応、プリセールスなどで回答書の骨組みを作る人向けです。RFP本文と自社情報を入力すると、章立て、各章で答える内容、必要な根拠、未確認事項を整理できます。
この記事で分かることは次のとおりです。
- RFP回答書の構成を作るコピペ用プロンプト
- 入力前に整理する情報と、変更する箇所
- 評価項目と回答箇所を対応させる方法
- AIが要件や実績を補ってしまう失敗の防ぎ方
- 短納期案件や複数人での執筆に応用する方法
ここがポイント: AIに「魅力的な提案書を書いて」と頼むのではなく、RFPの要求事項を分解し、「どの章で、何を、どの根拠で答えるか」を設計させます。
このプロンプトで作るのは「目次」ではなく回答設計図
良い構成案は、各評価項目に回答場所と根拠資料が割り当てられています。 章タイトルだけを並べた目次では、必須要件の見落としや、評価されない会社紹介へのページ配分を防げません。
RFPには、一般に次のような情報が含まれます。
- 調達の目的と背景
- 業務範囲や要求仕様
- 必須条件
- 提出方法、期限、ページ数などの制約
- 評価項目と配点・重要度
- 契約条件
- 質問や確認の手続き
たとえば米国連邦調達規則のRFPに関する規定では、要求内容、契約条件、提案書に必要な情報、評価要素とその相対的重要性が最低限の項目として挙げられています。また、提案は募集文書に示された評価要素に基づいて評価されます。これは日本の民間案件へそのまま適用するルールではありませんが、回答書を評価項目から逆算する考え方を理解するうえで参考になります。
完成イメージは、次の4点がそろった構成案です。
- 推奨する章立て
- 各章で答えるRFP要件
- 記載に必要な実績・数値・資料
- 不明点、確認質問、担当者
コピペ用：RFP回答書の構成作成プロンプト
以下のテンプレートをコピーし、{}で囲んだ部分を案件に合わせて変更してください。RFPが長い場合は、全文を一度に貼らず、章ごとに入力して統合する方法もあります。
あなたは、法人向け提案書の構成を設計する編集者です。
以下のRFPと提案情報を読み、評価者が要求事項への回答箇所を確認しやすい「RFP回答書の構成案」を作成してください。
# 目的
- RFPの必須要件、評価項目、提出条件の抜け漏れを防ぐ
- 評価項目と回答書の章を対応させる
- 未確認の情報を推測で埋めず、確認事項として残す
# 入力情報
## 案件概要
- 案件名: {案件名}
- 発注者: {発注者名または業種}
- 提案する製品・サービス: {提案内容}
- 回答書の主な読者: {経営層／調達部門／情報システム部門／現場責任者など}
- 提出期限: {提出期限}
## RFP本文
{RFPの本文を貼り付ける}
## 自社から提供できる情報
- 提案方針: {解決方針}
- 対応可能な要件: {確認済みの対応内容}
- 制約・前提: {対応範囲、除外事項、顧客側の作業など}
- 実績・事例: {提示可能な事実のみ}
- 体制: {役割、人数、責任者など}
- スケジュール案: {工程と期間}
- 価格情報: {記載可能な範囲}
# 作業手順
1. RFPから、目的、必須要件、評価項目、提出条件、契約上の制約、質問が必要な事項を抽出する
2. 各項目に識別番号を付ける
3. 必須要件と評価項目を優先して回答書の章立てを作る
4. 各章について「答える問い」「記載内容」「必要な根拠」「対応するRFP項目」を示す
5. 入力にない実績、機能、数値、認証、体制、価格は作らない
6. 情報が不足する箇所は「要確認」とし、発注者への質問と社内確認に分ける
7. 同じ説明の重複を避け、詳細を別紙へ分けた方がよい項目を示す
8. 最後に、RFP項目と回答箇所の対応を点検する
# 推奨する基本章
案件に合わない章は調整してよい。ただし、削除理由を明記すること。
- エグゼクティブサマリー
- RFPへの理解
- 提案方針と全体像
- 要求事項への回答
- 導入・移行計画
- 実施体制と役割分担
- 品質管理、セキュリティ、リスク対応
- 運用・保守・サポート
- 実績・類似事例
- スケジュール
- 価格・前提条件
- 付録・証憑
# 出力形式
次の順番でMarkdown形式で出力する。
## 1. RFPの要点
- 調達目的
- 重要な必須要件
- 評価項目と配点・重要度
- 提出条件
- 契約・運用上の主な制約
## 2. 推奨構成
各章を次の形式で記載する。
- 章番号・章タイトル
- この章の目的
- 評価者の問い
- 記載する内容
- 必要な根拠・資料
- 対応するRFP項目番号
- 推奨ページ配分: 多め／標準／少なめ
## 3. 要件対応マトリクス
- RFP項目番号
- 要求内容
- 区分: 必須／評価対象／提出条件／契約条件
- 回答する章
- 対応状況: 対応可能／条件付き／要確認／対象外
- 必要な根拠
## 4. 確認事項
- 発注者へ質問する事項
- 社内で確認する事項
- 回答書へ明記すべき前提条件
## 5. 構成上の注意点
- 抜け漏れの可能性
- 重複している説明
- 別紙へ分ける候補
- ページ制限に合わせて削る場合の優先順位
# 制約
- RFPにない評価基準を、正式な基準として追加しない
- 対応可否が不明な要件を「対応可能」と断定しない
- 実績や数値を創作しない
- 法務、価格、セキュリティ、契約条件は担当者の確認が必要だと明示する
- 原文の意味を変えない。解釈が分かれる場合は複数の読み方を示す
入力時に変える部分と、固定したい条件
案件ごとに変える情報と、毎回守らせるルールを分けると出力が安定します。 前者は提案内容を具体化し、後者はAIの推測や要件漏れを抑えます。
案件ごとに変更する項目
最低限、次の項目を埋めます。
{案件名}：社内で案件を識別できる名称{発注者名または業種}：固有名詞を入力できない場合は業種と組織規模{提案内容}：製品名だけでなく、何をどこまで提供するか{主な読者}：技術担当者、調達担当者、経営層など{RFP本文}：要求仕様だけでなく、評価基準と提出要領も含める{対応可能な要件}：社内で確認済みの事実{制約・前提}：対象外作業、顧客側の役割、外部サービスへの依存{実績・事例}：公開・提出してよい情報だけを記載
RFP全文を入力できない場合は、少なくとも「要求事項」「評価項目」「提出条件」の3つを渡します。評価項目がないまま構成を作ると、AIは一般的な提案書の型を返せても、案件固有の採点軸には合わせられません。
固定した方がよい条件
次の指示は案件を問わず残すのがおすすめです。
- 入力にない機能、実績、数値を作らない
- 不足情報は「要確認」と表示する
- RFP項目ごとに識別番号を付ける
- 各章に対応するRFP項目番号を示す
- 「対応可能」「条件付き」「要確認」「対象外」を区別する
- 最後に要件対応マトリクスを出す
とくに重要なのが、「要確認」を許可することです。空欄を埋めることだけを求めると、AIがもっともらしい内容で不足情報を補う危険が高まります。
NG例：魅力的な提案書を丸ごと頼まない
曖昧な依頼では、案件固有の評価基準より一般的な提案書の型が優先されます。 その結果、読みやすくても採点しにくい回答書になりがちです。
NGプロンプト
以下のRFPを読んで、競合に勝てる魅力的な提案書を作ってください。
当社の強みが伝わるプロフェッショナルな内容にしてください。
{RFP本文}
この指示には、次の問題があります。
- 「競合に勝てる」「魅力的」の判断基準がない
- 必須要件と加点要素を区別していない
- 回答書の構成と完成原稿を同時に求めている
- 自社情報が不足しており、強みや実績を補完されやすい
- ページ数、様式、提出ファイルなどの制約を点検できない
改善プロンプト
以下のRFPから、必須要件、評価項目、提出条件を原文の意味を保って抽出してください。
その後、評価項目ごとに回答場所が一意に分かる構成案を作成してください。
各章には、次の情報を付けてください。
- 評価者が確認したい問い
- 回答に必要な事実・数値・証憑
- 対応するRFP項目番号
- 情報不足の場合の確認質問
入力にない実績、機能、数値は作らず「要確認」と表示してください。
本文はまだ執筆せず、構成案と要件対応マトリクスだけを出力してください。
{RFP本文}
{確認済みの自社情報}
改善点は、AIの役割を「文章の生成」から「要求事項と回答箇所の整理」に絞ったことです。完成原稿へ進む前に、人が構成案と対応可否を確認できます。
出力を安定させる3つのコツ
出力形式、事実の境界、確認手順を明記すると、担当者がレビューしやすい構成になります。
1. 評価項目と章を一対一で追跡できるようにする
各要件へ REQ-01、SEC-03、EVAL-02 などの番号を付け、構成案にも同じ番号を出させます。これにより、「セキュリティ要件は第何章で答えるのか」を検索できます。
評価項目が複数の章にまたがる場合は、主回答の場所を1つ決め、ほかの章から参照します。同じ主張を何度も書くと、修正漏れによる矛盾が起きやすいためです。
2. 要求、提案、根拠を分離する
回答書の各項目を、次の3層で整理させます。
- 要求：発注者が求めている結果や条件
- 提案：自社が実施する方法と役割分担
- 根拠：実績、仕様書、体制図、工程表、証明書など
業務の要求は、作業方法だけでなく、期待する結果や測定可能な基準で示される場合があります。そのため構成案でも、「何をするか」に加えて「どう完了を判断するか」「何で裏付けるか」まで置くことが重要です。
3. AIの出力後に機械的な再点検を行う
構成案ができたら、同じ会話で次の追加指示を実行します。
作成した構成案を監査してください。
次の観点ごとに、問題箇所、理由、修正案を示してください。
- 回答先がないRFP項目
- 根拠資料がない主張
- 「対応可能」と「要確認」の矛盾
- 複数章で重複する内容
- ページ数や提出様式に反する構成
- 発注者への確認が必要な曖昧な要件
問題がない項目も「確認済み」と明記してください。
AIによる監査は、人による営業判断、技術確認、法務確認の代わりにはなりません。見落とし候補を早く洗い出す一次点検として使います。
活用例：構成案をチームの執筆計画へ変える
構成案に担当者と完了条件を加えれば、そのまま回答書作成の進行表に展開できます。
複数人で執筆する場合
構成作成後、次の列を追加するよう指示します。
- 執筆担当
- 技術確認者
- 営業確認者
- 法務・契約確認の要否
- 必要資料
- 初稿期限
- ステータス
章単位ではなく、RFP項目単位で担当を割り当てるのがポイントです。1章に複数の専門領域が含まれていても、誰がどの要件に責任を持つかが明確になります。
ページ制限が厳しい場合
ページ数を削るときは、すべての章を均等に短くするのではなく、配点と必須性から優先順位を決めます。
回答書は本文{上限ページ数}ページ以内です。
必須要件と配点の高い評価項目を優先し、章ごとの推奨ページ数を示してください。
削減する場合は、本文に残す情報、付録へ移す情報、削除候補を分けてください。
RFPが分割ファイルになっている場合
本文、仕様書、評価基準、契約書案が別ファイルなら、先にファイルごとの抽出結果を作り、最後に統合します。ファイル名とページ番号を要件IDへ付けると、原文へ戻りやすくなります。
ただし、機密情報、個人情報、価格情報、顧客固有のセキュリティ情報を外部AIへ入力してよいとは限りません。所属組織の利用規程、契約、利用するAIサービスのデータ取扱条件を確認し、必要に応じて匿名化や承認済み環境を使ってください。
実行前チェックリスト
最後に、次の項目を確認してからプロンプトを実行します。
- [ ] RFP本文だけでなく、評価項目と提出要領も入力した
- [ ] 自社の対応可能範囲と対象外を分けた
- [ ] 実績や数値は確認済みの事実だけを入力した
- [ ] AIへ創作禁止と「要確認」の表示を指示した
- [ ] RFP項目番号と回答章を対応させた
- [ ] ページ数、ファイル形式、締切などの制約を含めた
- [ ] 機密情報を入力できる環境か確認した
- [ ] 技術、価格、法務、セキュリティの担当者が確認する工程を残した
RFP回答書で最初に見るべき分岐点は、文章の美しさではありません。評価項目ごとに、回答場所、対応可否、根拠、確認担当が埋まっているかです。ここに空欄が残るなら、本文生成へ進む前に質問票と社内確認リストを完成させる必要があります。