要件を勝手に埋めないRFP作成プロンプト｜質問から始める提案依頼書テンプレート
RFP（提案依頼書）のたたき台をAIで作りたいものの、要件漏れや事実ではない記述が心配な担当者向けのテンプレートです。
結論からいえば、AIに最初から完成版を書かせてはいけません。入力情報を点検し、不足項目への質問を出してから本文を作らせるのが重要です。これにより、予算、納期、対象範囲、評価基準などの未確定事項を、AIがもっともらしく補う事故を減らせます。
この記事で扱う内容は次のとおりです。
- RFP作成プロンプトの使いどころ
- そのまま使えるコピペ用テンプレート
- 入力時に変更する項目
- NG指示と改善例
- 出力を安定させる確認手順
- システム開発以外への応用方法
ここがポイント: AIの役割は「要件を決めること」ではなく、担当者が持つ情報を整理し、未決事項を見える状態にすることです。
このプロンプトで作れるもの
発注担当者が集めた情報を、提案企業が判断しやすいRFPの骨格へ変換できます。
RFPは、外部の事業者に提案を依頼するための文書です。単に「新しいシステムを作りたい」と伝えるのではなく、背景、目的、依頼範囲、制約、成果物、提案条件、選定方法などを整理します。
デジタル・ガバメント推進標準ガイドラインの実践ガイドブックでも、調達仕様書は、必要な製品や役務を提供する外部事業者を選ぶために発注者側の条件を示す文書とされています。また、要望だけでなく、実現時に守るべき前提条件や制約条件も記載することが重要だと説明されています。
このテンプレートは、特に次の場面で使えます。
- 社内システムの新規開発や刷新
- Webサイトや業務アプリの制作委託
- SaaSや業務ツールの導入支援
- 調査、コンサルティング、運用支援の委託
- 複数社へ同じ条件で提案を依頼したいとき
完成時の基本構成は次のとおりです。
- 案件の概要
- 背景と現状の課題
- 目的と期待する成果
- 依頼範囲と対象外
- 機能要件
- 非機能要件
- 成果物と受入条件
- 体制と役割分担
- スケジュール
- 予算・契約条件
- 提案書に記載してほしい内容
- 評価基準
- 質疑・提出方法
- 前提条件、未確定事項、確認事項
ただし、案件によって必要な章は変わります。すべてを無理に一つの本文へ詰め込むより、情報量の多い要件定義書、現行業務フロー、データ一覧などは別紙に分けるほうが読みやすくなります。政府の実践ガイドブックでも、情報量や粒度に応じて付属文書に分ける考え方が示されています。
コピペ用RFP作成プロンプト
次のテンプレートは、質問、構成確認、本文作成の3段階で進めます。 最初に入力欄を埋め、AIへ貼り付けてください。
あなたは、発注者側で提案依頼書（RFP）の作成を支援する業務アナリストです。
以下の入力情報を整理し、提案企業が案件の目的、範囲、制約、提出条件を誤解しにくいRFPを作成してください。
【重要なルール】
- 入力にない事実、数値、期限、予算、法令、製品名、体制を推測で補わない
- 不明な内容は「未確定」「要確認」「該当なし」のいずれかで明示する
- 発注者が決める事項と、提案企業に提案を求める事項を分ける
- 必須要件と希望要件を分ける
- 依頼範囲と対象外を明確にする
- 同じ要件を複数の章へ重複して書かない
- 抽象的な表現には、確認可能な受入条件を添える
- 機密情報、個人情報、認証情報は出力しない
【案件情報】
案件名: {案件名}
発注部門: {発注部門}
案件の背景: {背景}
現在の課題: {課題}
達成したい目的: {目的}
期待する成果: {成果}
利用者・対象者: {利用者}
対象業務: {対象業務}
依頼範囲: {依頼範囲}
対象外: {対象外}
現在の環境・既存システム: {現行環境}
必要な機能: {機能要件}
性能・可用性・セキュリティ・運用などの条件: {非機能要件}
連携するシステムやデータ: {連携対象}
想定する成果物: {成果物}
発注者側の体制: {発注者体制}
提案企業に求める体制・経験: {提案企業の条件}
希望スケジュール: {スケジュール}
予算または予算の扱い: {予算}
契約方式・支払条件: {契約条件}
提案書に記載してほしい項目: {提案項目}
評価基準: {評価基準}
質問期限・提出期限・提出方法: {提出条件}
適用すべき規程・法令・社内ルール: {準拠事項}
その他の制約: {制約}
【進め方】
ステップ1:
入力情報を点検し、RFPを作るために不足している重要情報を質問してください。
質問は「回答がないと提案条件が変わるもの」を優先し、最大10問に絞ってください。
各質問に、確認が必要な理由を1文で添えてください。
この段階ではRFP本文を作成せず、質問だけを出力してください。
ステップ2:
私が質問に回答した後、RFPの見出し案を作成してください。
各章について、本文に記載する内容と、別紙へ分ける内容を示してください。
この段階でもRFP本文はまだ作成しないでください。
ステップ3:
私が見出し案を承認した後、次の形式でRFP本文を作成してください。
[出力形式]
# {案件名} 提案依頼書
## 1. 案件概要
## 2. 背景と現状の課題
## 3. 目的と期待する成果
## 4. 依頼範囲
### 4.1 対象範囲
### 4.2 対象外
## 5. 要件
### 5.1 機能要件
### 5.2 非機能要件
### 5.3 データ・外部連携要件
## 6. 成果物と受入条件
## 7. 実施体制と役割分担
## 8. スケジュール
## 9. 予算・契約条件
## 10. 提案書の記載事項
## 11. 評価基準
## 12. 質疑・提出方法
## 13. 前提条件と制約
## 14. 未確定事項・確認事項
## 15. 別紙一覧
[記述方法]
- 本文は簡潔な業務文書として書く
- 要件には「必須」「希望」「提案依頼」の区分を付ける
- 受入条件は、納品物や動作を確認できる表現にする
- 日付、金額、件数、性能値が未確定なら推測せず「未確定」と書く
- 提案企業が回答すべき箇所は「提案を求める内容」として箇条書きにする
- 最後に、未確定事項と本文内の矛盾をセルフチェックして一覧化する
一度の入力で完成版まで出させず、AIがステップ1で止まるように指定している点が重要です。質問への回答後に「ステップ2へ進んでください」、構成を確認した後に「ステップ3へ進んでください」と指示します。
入力時に変える部分
最優先で具体化したいのは、目的、依頼範囲、対象外、受入条件の4点です。 ここが曖昧なままだと、提案企業ごとに見積もる作業や成果物が変わり、価格やスケジュールを同じ基準で比べにくくなります。
必ず変更する項目
{案件名}：社内で通じる略称ではなく、調達内容が伝わる名称にする{背景}：何が起きており、なぜ着手するのかを書く{目的}：導入する製品ではなく、改善したい業務や状態を書く{依頼範囲}：調査、設計、開発、移行、教育、運用などを工程単位で示す{対象外}：既存システム改修、データ入力、機器調達など、今回含めない作業を書く{成果物}：設計書、ソースコード、テスト結果、操作手順書などを列挙する{提案項目}：体制、工程、費用内訳、リスク、前提条件など、回答してほしい内容を示す{評価基準}：価格だけでなく、要件適合性、実施方法、体制などの評価軸を示す
空欄のままにしないほうがよい項目
予算や日程をまだ決めていない場合も、欄を削除するのではなく状態を伝えます。
- 予算未定：
予算は未確定。提案時に初期費用、継続費用、追加費用の条件を分けて提示すること - 納期未定：
開始希望時期のみ確定。実現可能な工程と完了時期の提案を求める - 技術方式未定：
製品や構成は指定せず、要件を満たす方式と選定理由の提案を求める - 移行量未調査：
対象データ量は調査中。見積前提と追加費用が発生する条件を明記すること
「未定」とだけ書くより、誰が何を提案し、どの条件で費用が変わるかまで示したほうが回答を比較しやすくなります。
固定しておきたいルール
次の指示は案件ごとに消さず、基本ルールとして残します。
- 推測で事実や数字を補わない
- 必須要件と希望要件を分ける
- 発注者の決定事項と提案依頼事項を分ける
- 対象範囲と対象外を示す
- 未確定事項を最後に一覧化する
非機能要件は別枠で確認する
機能一覧だけでは、運用できるシステムの条件を十分に伝えられません。 障害時の復旧、アクセス集中時の性能、バックアップ、セキュリティ、保守時間なども確認が必要です。
IPAの「非機能要求グレード」は、発注者と開発者の認識違いを防ぐため、非機能要求を網羅的に分類し、要求レベルを段階的に確認するための資料です。すべての項目をRFPへコピーするのではなく、案件に関係する項目を洗い出すチェック材料として利用できます。
主な確認分野は次のとおりです。
- 可用性：利用時間、停止可能時間、障害からの復旧目標
- 性能・拡張性：利用者数、処理件数、応答時間、将来の増加
- 運用・保守性：監視、バックアップ、問い合わせ、更新作業
- 移行性：移行対象、データ品質、切り替え方法、失敗時の戻し方
- セキュリティ：認証、権限、ログ、暗号化、脆弱性対応
- システム環境：設置場所、クラウド利用条件、機器やネットワークの制約
具体的な数値を決められないときは、AIに決定させず、提案企業へ根拠付きで提案を求めます。例えば「高い可用性を確保すること」ではなく、「想定構成、サービス提供時間、計画停止、障害時の復旧方法と目標値を提案すること」とします。
失敗しやすいNG例と改善例
悪いプロンプトは、AIに不足情報を推測する余地を与えます。 指示を長くすることより、判断主体と不明時の処理を明示することが効果的です。
NG例1：目的だけで完成版を求める
勤怠管理システムを導入したいので、詳しいRFPを作ってください。
この指示では、利用者数、対象拠点、既存データの移行、給与システムとの連携、予算、導入時期が分かりません。AIが一般的な要件を加えても、それが自社に必要とは限りません。
改善するなら、まず質問だけを求めます。
勤怠管理システム導入のRFPを作成します。
本文を書く前に、提案内容と見積額を左右する不足情報を最大10問質問してください。
入力にない事実や数値は補わないでください。
各質問には、確認が必要な理由を添えてください。
NG例2：「適切に」「十分に」で済ませる
使いやすく、安全で、十分な性能を持つシステムを提案してください。
「使いやすい」「安全」「十分な性能」は、確認方法が定まっていません。提案企業ごとに解釈が変わります。
改善例では、確認する対象を示します。
次の項目について、実現方法、前提条件、確認方法を提案してください。
- 利用者が行う主要3業務の操作手順
- 想定同時利用者数に対する応答時間
- 認証方式と権限管理方法
- 操作ログの記録範囲と保存期間
- 障害発生時の連絡、復旧、再発防止の流れ
数値が未確定の項目は、推奨値とその根拠を提案してください。
NG例3：必須条件と提案希望を混ぜる
すべてを「必須」にすると、提案の余地がなくなり、費用が膨らむことがあります。一方、すべてを「提案してください」にすると、必要条件を満たさない提案も残ります。
次の3区分に分けると明確です。
- 必須：満たさなければ採用できない条件
- 希望：優先度は高いが、代替案も検討できる条件
- 提案依頼：実現方法や適切な水準を提案企業に求める項目
出力を安定させる3つのコツ
安定したRFPを得るには、文体よりも作業順序、要件の区分、セルフチェックを固定します。
1. 質問と本文作成を分ける
最初の回答では質問だけを出させます。質問への回答後も、いきなり本文へ進まず、見出しと別紙の構成を確認します。
この順序にすると、不要な章を削り、重要な要件へ情報を集めてから文章化できます。途中で不足が見つかった場合も、長い本文を書き直す必要がありません。
2. 要件ごとに確認可能な条件を付ける
「マニュアルを納品すること」だけでは、内容や完成基準が曖昧です。例えば次のように変えます。
成果物: 管理者向け操作手順書
記載範囲: 利用者登録、権限変更、マスタ更新、ログ確認、障害時の一次対応
納品形式: 編集可能な電子ファイルとPDF
受入条件: 発注者が指定する担当者が、手順書に沿って各操作を完了できること
受入条件は、契約や検収に関係します。AIの文章をそのまま確定せず、調達、法務、情報システム、利用部門などの関係者が確認してください。
3. 最後に矛盾と未確定事項を点検させる
本文作成後は、別の指示で監査役として点検させます。
作成したRFPを、発注前のレビュー担当者として点検してください。
本文は書き換えず、次の項目を一覧化してください。
1. 目的と要件がつながっていない箇所
2. 依頼範囲と対象外の矛盾
3. 必須・希望・提案依頼の区分漏れ
4. 成果物と受入条件の対応漏れ
5. スケジュール上の前後関係の矛盾
6. 見積条件が変わり得る未確定事項
7. 提案企業によって解釈が分かれそうな表現
8. 根拠を確認できない数値・固有名詞・法令名
各項目を「該当箇所」「問題」「確認先」「修正案」の順で示してください。
該当しない項目は「該当なし」と明記してください。
この点検は、人による承認の代わりではありません。AIは入力された資料の正しさや、社内にしかない契約条件まで確認できないためです。
活用例：システム開発以外にも応用する
章構成を変えれば、制作、調査、運用などの業務委託にも使えます。 固定すべきなのはRFPの見出しではなく、「不足情報を質問する」「範囲を分ける」「受入条件を示す」という流れです。
Webサイト制作
機能要件だけでなく、次の情報を入力します。
- 対象ページと想定ページ数
- 原稿、写真、動画を用意する担当者
- デザイン案の提出数と修正回数
- CMSへの移行対象
- 対応ブラウザとアクセシビリティ方針
- 公開後の保守範囲
調査・コンサルティング
成果物のページ数だけでなく、調査方法と判断材料を明確にします。
- 調査対象と除外対象
- 使用可能な情報源
- ヒアリング対象者と実施回数
- 中間報告の時期
- 分析方法と根拠の示し方
- 最終報告後に求める説明や修正
運用・保守委託
平常時と障害時を分けて条件を整理します。
- 対応時間と受付窓口
- 問い合わせの分類
- 障害の重要度と連絡期限
- 定例報告の内容
- 作業記録やログの保存
- 契約終了時の引き継ぎ
利用前チェックリスト
RFPを社外へ出す前に、次の項目を人が確認します。
- [ ] 背景ではなく、達成したい目的が明記されている
- [ ] 依頼範囲と対象外が区別されている
- [ ] 必須、希望、提案依頼が混在していない
- [ ] 成果物ごとに受入条件がある
- [ ] 見積金額が変わる前提条件を示している
- [ ] 非機能要件を確認した
- [ ] 提案書の記載項目と評価基準が対応している
- [ ] 未確定事項の確認担当者と期限を決めた
- [ ] AIが補った可能性のある数値、固有名詞、法令名を原典で確認した
- [ ] 個人情報、認証情報、非公開情報を不用意に入力していない
- [ ] 調達、法務、セキュリティ、利用部門によるレビューを行った
AIで短縮しやすいのは、情報の分類、見出し作成、表現の統一、漏れの候補出しです。一方、予算、契約条件、評価基準、受入条件を決める責任は発注者に残ります。
まず確認すべき次の分岐点は、未確定項目を発注前に社内で決めるのか、提案企業へ根拠付きの提案を求めるのかです。この区別をRFPへ明記できれば、AIが作った文章は単なる長文ではなく、比較可能な提案を集めるための文書になります。