RFPを読み込ませて提案書の初稿を自動生成する

RFPを受領してから提案書を提出するまでには、要求事項の読み込み、提案方針の整理、プロジェクト体制の検討、スケジュール作成、見積算出、提案書の編集など、多くの作業が発生します。複数の担当者が並行して作業する場合、同じ要求事項の解釈が分かれたり、過去の提案ノウハウを十分に活用できなかったりすることがあります。

業務AIエージェント Jiteraを活用する場合、利用を許可されたRFP、社内の見積実績、提案書の構成パターン、プロジェクト体制やWBSのひな型をコンテキストとして整理し、要求事項の一覧化、提案方針の整理、見積・体制のたたき台、提案書の初稿用の骨子作成を支援できます。参照できる情報や利用できる機能は、製品の機能、環境設定、契約条件、対象データ、社内ルールによって異なります。

Jiteraが作成する内容は、入力情報に基づく提案書のドラフトです。要件への適合性、見積金額、実現可能性、契約条件、導入効果、顧客への説明内容を自動的に確定・保証するものではありません。営業、プリセールス、PMO、技術、法務、品質などの担当者がレビューし、組織の承認手続きに従って確定してください。

提案スピードがボトルネックになる理由

RFP受領から提案完了までの確認事項が多い

RFPには、顧客の背景、業務要件、機能要件、非機能要件、移行条件、体制要件、評価項目、提出形式などが含まれます。内容を読み込んで提案方針を整理するだけでも、多くの確認作業が必要です。章ごとに担当者が分かれると、同じ要求事項を別々に解釈したり、必須要件や提出条件を見落としたりする可能性があります。

要件整理、体制、スケジュール、見積は相互に影響する

提案では、価格と実現方法を別々に決めることはできません。要件整理の結果が体制やスケジュールに影響し、体制やスケジュールが見積金額や作業範囲に影響します。過去案件の数字やWBSをそのまま転用すると、案件固有の規模、納期、顧客側の分担、技術上の制約が反映されないおそれがあります。

提案品質が担当者の経験に左右される

次のような情報を、利用を許可された範囲で整理しておくと、担当者の経験や過去案件の知見を提案活動に活かしやすくなります。

• 顧客課題から提案方針へつなげる考え方
• 要件の優先度を判断する基準
• 類似案件の見積前提と実績との差分
• 提案書でよく使う章立てと説明の順序
• 受注後に判明した見積差異や追加作業
• 過去レビューで指摘された事項と再発防止策

Jiteraに登録するコンテキストの設計

社内の見積実績・スケジュールテンプレート

見積実績には、金額だけでなく、対象範囲、前提条件、顧客側の分担、体制、期間、見積と実績の差分を記録します。顧客名、契約上の機密情報、個人情報などはそのまま登録せず、利用が許可された範囲で匿名化または除外してください。登録可否、アクセス権限、マスキング、保持期間は、契約条件と社内規程に従って確認します。

過去提案書のパターン

過去提案書は、個別案件の内容をそのまま再利用するのではなく、構成や説明方法を整理するために登録します。顧客名、担当者名、固有の価格、契約条件、未公開情報、承認されていない実績は、利用ルールに従って匿名化または除外してください。古い提案書を参照する場合は、現行の製品機能、認証、契約条件、組織方針と一致するかを確認します。

プロジェクト体制・WBSのひな型

プロジェクト体制とWBSのひな型には、役割、成果物、工程間の関係を含めます。WBSのひな型は、RFPに記載された納期、工程、顧客側の作業、承認手順を無視して適用するものではありません。ひな型をたたき台にしながら、案件固有の要件と制約を反映します。

RFPから提案書ドラフトを作成する手順

Step 1：RFPと関連資料を整理する

取り込み前に、RFPの版と受領日、提案対象となる業務とシステムの範囲、必須要件と任意要件、評価項目、提出期限と形式、顧客へ確認すべき不明点を整理します。RFPだけでなく、別紙、質問回答、訂正版、提出様式などの関連資料がある場合は、どの版を正とするか確認します。

いきなり提案書を作成するのではなく、まず要求事項の一覧を作成し、各要求事項の根拠、対応方針、確認事項、担当者を整理することが重要です。

Step 2：提案方針、体制、進め方、見積内訳のたたき台を作る

金額や期間は、過去案件の数字をそのまま転用せず、RFPの規模、要件、納期、顧客側の分担、前提条件を反映して担当者が確認します。RFPや登録資料に根拠がない内容、確定していない金額・期間・実績は推測で補わず、「要確認」として出力させます。

体制とスケジュールは、必要な役割、工程ごとの成果物、顧客との確認・承認の節目、前後関係、リスクや予備期間を含めて確認します。見積内訳は、作業範囲と対応関係が分かるように整理し、対象外作業や顧客側の作業も明記します。

Step 3：提案書のスライド構成の骨子を作る

提案書の初稿では、完成した文章よりも、全体の論理と情報の不足を確認できる骨子を先に作ります。各ページについて、伝える主張、根拠となるRFPの記載、参照資料、掲載する図表、確認が必要な事項を付けると、担当者が編集・レビューしやすくなります。

プロンプト例

架空の企業「朝霞情報サービス株式会社」が受領した、架空の「青葉市民サービス基盤刷新」RFPを対象にしてください。

登録済みのRFP、社内の匿名化された見積実績、提案書の構成パターン、プロジェクト体制とWBSのひな型だけを参照して、提案書の初稿用の骨子を作成してください。

出力する内容：
1. RFPの要求事項一覧と根拠
2. 要求事項ごとの対応方針
3. プロジェクト体制と役割分担
4. 工程別の進め方と成果物
5. スケジュールのたたき台と前提条件
6. 見積内訳の項目と算出前提
7. 提案書のスライド構成
8. 顧客への確認事項
9. 社内レビューが必要な事項

RFPに根拠がない内容、登録資料から確認できない実績、確定していない金額や期間は推測で補わず、「要確認」と記載してください。
製品機能、認証、導入効果、契約条件を、登録資料から確認できない場合は断定しないでください。

Step 4：人によるレビューを前提に初稿を仕上げる

• 営業担当者：顧客の背景、課題、評価項目、提出条件、顧客への約束が正しく反映されているかを確認します。
• プリセールス・技術担当者：対応方針、システム構成、技術上の前提、非機能要件、実現可能性を確認します。
• PMO担当者：体制、WBS、スケジュール、成果物、顧客側との分担の整合性を確認します。
• 法務・セキュリティ・品質担当者：契約、機密情報、セキュリティ、品質、法令・社内規程に関する表現を確認します。
• 責任者：提案内容、見積金額、契約上の条件、リスク、提出可否が社内承認済みかを確認します。

運用上のポイント

提案書の最終品質チェックは人が担う

提出前には、少なくとも次の観点を確認します。

• RFPの必須要件、評価項目、提出形式に漏れなく対応しているか
• 要件への対応方針に根拠があるか
• 不明点、前提条件、対象外範囲、顧客側の作業が明記されているか
• 見積金額と作業範囲、体制、スケジュールが一致しているか
• 実績、製品機能、認証、数値に誤りや未承認の表現がないか
• 契約、機密情報、セキュリティに関する表現が承認済みか
• 提案内容が顧客の評価基準と提出条件に沿っているか

AIの出力だけで、未承認の金額、実績、製品機能、認証、契約条件、導入効果を顧客へ提示しないでください。生成された文章や図表が整っていても、内容の正確性や実現可能性を意味するとは限りません。

受注後の実績と振り返りを次の提案に活かす

提案活動の知識を継続的に活用するには、受注できたかどうかだけでなく、受注後に何が起きたかを記録します。

記録を次の提案へ再利用する際は、対象案件、適用範囲、更新日、確認者を管理します。古い前提や終了した製品機能、過去の契約条件を現行情報として参照しないよう、版管理と利用停止の手順も定めてください。

まとめ

RFPから提案書の初稿を効率よく作成するには、RFPだけを参照するのではなく、利用を許可された見積実績、過去提案書の構成、プロジェクト体制、WBSのひな型を整理して活用します。

1. RFPの版、対象範囲、提出条件、機密情報を確認する
2. 要求事項、根拠、対応方針、確認事項を整理する
3. 見積実績、スケジュール、体制、WBSのひな型を前提条件付きで参照する
4. プロジェクト体制、進め方、見積内訳のたたき台を作成する
5. 提案書のスライド構成と各ページの要点を整理する
6. 営業、プリセールス、PMO、技術、法務、品質担当者が分担してレビューする
7. 見積、体制、スケジュール、契約条件、顧客への約束を承認する
8. 受注後の実績と振り返りを、確認者と版を管理しながらコンテキストへ反映する