【プロンプト付き】RFPを受け取ったら、提案書より先に作るもの。AI要求整理の3ステップ

「RFPが届いたので、AIに提案書を作らせよう」

締切が近いと、すぐに資料を作り始めたくなります。

RFPをAIへ入れて、「この内容に沿った提案書を作ってください」と頼む。数分後には、きれいな章立てと、それらしい回答が並びます。

ところが、読み返すと問題があります。

必須要件への回答が、提案の魅力に埋もれている。
「対応可能」と書いてあるのに、標準機能なのか、追加開発なのか分からない。
質問すべき曖昧な条件を、AIが自然な前提で補っている。

提案書はできた。でも、要求に答えられているかは分からない。

今回は、RFPを受け取った直後に、AIと一緒に「要求分解表」を作る方法を整理します。

対象は、顧客から提案依頼書や要件一覧を受け取り、社内の技術担当者や上司と回答をまとめるBtoB営業担当者です。

RFPは、提案書の目次ではない

RFPは、顧客が知りたいことを一冊にまとめた資料です。
ただし、すべての要求が質問文で並んでいるとは限りません。

ある要求は本文に書かれ、別の条件は要件一覧にあり、評価される観点は審査基準に置かれます。提出期限やファイル形式は、提出要領に分かれていることもあります。

デジタル庁の調達手続マニュアルでは、提案者による調達仕様書の理解、業務目的・効果への理解、機能・非機能要件の実現方法などが評価基準の例として示されています。

標準ガイドライン解説書でも、評価事項には提案書に求める内容や評価の観点を記載し、提案内容の実現性の根拠や具体的な実現方法が分かるようにする考え方が示されています。

つまり、提案側が読むべきものは「機能一覧」だけではありません。

顧客が何を実現したいのか。
何が必須なのか。
何を比較するのか。
どんな根拠を求めているのか。

これらを分けて、初めて回答の設計ができます。

AIへ最初に頼むのは、提案書ではなく要求の分解

AIにいきなり提案書を書かせると、文章を完成させる方向に働きます。

空欄があれば補い、曖昧な要求には妥当そうな回答を置き、前後の文章を自然につなぎます。

提案書の下書きでは便利です。しかし、確認できていないことまで整って見える危険があります。

最初に作るのは、完成した文章ではありません。

「何に答える必要があるか」を管理する表です。

要求分解表は、七つの欄で作る

RFPの内容を、次の七つへ分けます。

1．ID・出典

要求ごとに番号を付け、元資料のファイル名、章、ページ、項番を残します。

「セキュリティ要件に書いてあったはず」では、後から根拠へ戻れません。資料が更新された場合に備え、版数や受領日も記録します。

2．要求原文

顧客の記載を、まず原文のまま残します。

短く要約した内容だけを管理すると、「望ましい」が「必須」に変わったり、「検討すること」が「実装すること」に変わったりします。
要約欄を作る場合も、原文は消しません。

3．種別

要求を、たとえば次のように分類します。

• 必須要件

• 加点・評価要件

• 契約・参加条件

• 提出条件

• 顧客の背景・目的

• 質問が必要な事項

必須要件と加点要件では、提案書での扱いが変わります。
提出条件は製品機能ではありませんが、守らなければ提案自体が受理されない可能性があります。

4．対応状態

対応状態は、「○」「×」だけにしません。

• 対応可

• 条件付き

• 要確認

• 非対応

標準機能で満たせるなら「対応可」。設定、追加開発、他サービス、顧客側作業などの条件があるなら「条件付き」です。

判断材料が足りなければ「要確認」。要件を満たせないと確認できたものは「非対応」とします。
分からないものを、提案期限が近いという理由で「対応可」に寄せないことです。

5．回答の根拠

製品仕様書、契約条件、検証結果、技術担当者の確認、類似構成の設計資料など、回答を支える根拠を置きます。

「たぶんできる」「過去に似た案件があった」は、顧客へ示せる根拠ではありません。
根拠資料には、名称、版数、該当箇所を付けます。

6．担当者・確認期限

誰が確認し、いつまでに回答を出すかです。

営業だけでは判断できない要件には、技術、法務、セキュリティ、運用、パートナーなどの担当者を置きます。
RFPの提出期限ではなく、提案書へ反映できる社内期限を設定します。

7．顧客への確認質問

記載だけでは条件が確定しない要求を、質問へ変えます。

たとえば「既存システムからデータを移行すること」だけでは、対象、件数、形式、品質、移行回数、停止可能時間が分かりません。

分からないまま金額や日程を確定すると、提案後に条件が変わります。
質問は、知識不足を見せるものではありません。

提案の前提を合わせる仕事です。

プロンプト1：RFPから要求分解表を作る

AIの出力後、まず必須要件だけを絞り込みます。

対応状態が「対応可」なのに、根拠欄が空いているものがあれば戻します。

次に、提出条件を確認します。ページ数、様式、ファイル名、提出方法、期限、説明会の時間など、製品とは関係ない条件も提案の成立に関わります。

「要確認」は、提案書の弱点ではない

営業は、「要確認」が多いと提案準備が遅れているように感じます。
しかし、確認できていないことを見えるようにした時点で、リスクは管理可能になります。

問題は、未確認があることではありません。未確認のまま、回答と金額とスケジュールを確定することです。

顧客への質問は、次の順番で優先度を付けます。

1. 回答できないと参加・提案の可否が決まらないもの

2. 金額や納期が大きく変わるもの

3. 提案内容の評価に影響するもの

4. 契約後でも確認できるもの

何でも質問すればよいわけではありません。

RFPに書かれていることを聞き直すと、読み込み不足に見えます。質問前に出典へ戻り、自社の前提と顧客の記載のどこに差があるかを明確にします。

プロンプト2：確認質問を、回答しやすい形へ変える

たとえば、「データ移行の詳細を教えてください」では、顧客も何を答えるべきか迷います。

次のように分けます。

質問の目的は、相手を問い詰めることではありません。

提案の条件を、双方が同じ意味で使えるようにすることです。

提案書は、要求と回答を線でつなぐ

要求分解が終わったら、提案書の各ページを要求IDへ結び付けます。

一つの回答は、次の順番で書くと確認しやすくなります。

1. 結論：対応可、条件付き、要確認、非対応

2. 実現方法：何を使い、どう実現するか

3. 根拠：仕様、検証、体制、実績など

4. 前提・条件：顧客作業、追加費用、対象範囲など

5. 残る確認：契約前または導入前に決めること

「対応可能です」だけでは、実現方法が分かりません。
「標準機能で対応可能です」だけでも、どの仕様が要求を満たすのか確認できません。

読み手が、RFPの要求から回答の根拠へ戻れる状態を作ります。

悪い回答と改善例

悪い例

対応製品名、方式、契約条件、顧客の認証基盤との適合が分かりません。

改善例

改善例は長く見えます。
しかし、結論、根拠、条件、未確認が分かれています。

後から条件が変わったときも、どこを見直すか分かります。

プロンプト3：提案書とRFPの対応を監査する

監査結果では、抜け漏れの数だけを見ません。
影響で並べ替えます。

参加資格に関わるもの、必須要件、金額や納期を変えるもの、加点要件、表記上の修正。
この順で対応すると、限られた時間でも判断しやすくなります。

AI、営業、専門担当の役割を分ける

AIに任せやすいのは、資料横断の抽出、分類、矛盾候補の提示、一覧化、質問文や回答文の下書きです。

営業が担うのは、顧客の背景を踏まえた優先順位、質問する論点、提案のメッセージ、社内の確認依頼です。

技術、法務、セキュリティなどの専門担当が確定するのは、実現可否、正式な仕様、契約上の約束、リスクへの対応です。

そして、提出する会社が最終的な責任を持ちます。

AIが「対応可能」と分類しても、それは承認ではありません。

根拠資料と担当者の確認がそろって、初めて提案書へ書けます。

また、RFPには顧客の機密情報が含まれる場合があります。生成AIへ入力する前に、自社と顧客のルール、利用サービスのデータ取り扱い、保存・学習設定、入力してよい情報の範囲を確認します。

匿名化すればよいか、会社が承認した環境だけを使うか、入力自体を避けるか。ここも人が判断する事項です。

今日の一歩は、提案書を一枚作ることではない

次にRFPを受け取ったら、すぐにPowerPointを開かないでください。

まず、RFP、別紙、評価基準、提出要領、質問回答のファイルを一か所へ集めます。

そのうえで、必須要件を一つだけ要求分解表へ置いてみます。

要求原文は何か。
どの資料の、どの項番か。
対応可否を支える根拠はあるか。
条件は何か。
誰に、いつまでに確認するか。
顧客へ聞かなければ決められないことは何か。

この七つが埋まらないまま、きれいな回答文を作っても、提案の確度は上がりません。

AIに任せるのは、要求を探し、並べ、照合する作業。
営業が担うのは、何を約束し、何を確認し、どの条件で提案するかを決めること。

提案書の質は、書き始める前の分解で決まります。

参考資料

• デジタル庁「デジタル庁調達手続マニュアル」

• デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」

• IPA「ユーザのための要件定義ガイド 第2版」

• IPA「IT製品の調達におけるセキュリティ要件リスト活用ガイドブック」