RFP(Request For Proposal)が届いた瞬間、提案チームの空気が重くなる。要求項目を読み込み、過去提案を漁り、骨子を作り、差別化要素を考える。気づけば徹夜で骨子を書き、肝心の差別化議論に時間を割けないまま提出日を迎える——SI・受託開発の現場でよく見る景色です。
「AIで提案書を書かせる」は危険な近道です。RFPごとに要求項目の構造が違い、自社の強みも案件ごとに当てはめ方が違う。本当に効くのは、RFP要求項目をSkillで分解し、過去提案を参照しながら骨子を作り、差別化要素にPMが時間を使う運用です。
この記事では、Claude CodeでRFP対応・提案書ドラフトを2倍速で組み立てる実装を、現場で動かせる粒度で解説します。
なぜRFP対応は徹夜になるのか
RFP対応が時間を食うのは、PMの能力ではなく構造的な問題です。
- 要求項目の漏れチェックが目視:RFPのPDFを読みながらExcelに転記するだけで2時間
- 過去提案の検索が困難:類似案件の提案書がどこにあるか分からず、結局ゼロから書く
- 差別化議論の時間が取れない:骨子作成で疲弊し、肝心の戦略議論が後回しになる
Claude Codeは、SkillでRFP要求項目を構造化し、過去提案レポジトリを参照しながら骨子を作る運用を素直に組めます。
Claude Codeを「提案書ドラフト生成器」にする全体像
必要な要素は次の3つです。
- RFP取り込みSkill:PDFやWordから要求項目を抽出し、構造化YAMLに整形
- 提案書骨子Skill:過去提案レポジトリを参照しながら章立てと初稿を生成
- CLAUDE.md提案運用ルール:自社の提案構成、差別化要素のテンプレ、AIに書かせない章を明記
これが揃うと、PMはRFPを受領した日に「要求項目構造化」「骨子ドラフト」までを終え、翌日以降を「差別化議論」に充てられます。
ステップ1:RFP取り込みSkillを作る
.claude/skills/rfp-ingest/SKILL.md を用意します。
---
name: rfp-ingest
description: docs/rfp/{rfp-id}/source/ 配下のPDF/Wordから要求項目を抽出し、tmp/rfp/{rfp-id}/requirements.yaml に構造化する
disable-model-invocation: true
allowed-tools: Read, Write, Bash
---
# RFP要求項目構造化Skill
## 入力
- `docs/rfp/{rfp-id}/source/` 配下のRFP原本(PDF/Word/Markdown)
## 処理
1. RFP原本を読み、章単位で要求項目を抽出
2. 各要求項目に次のメタ情報を付与
- id(自動採番:RFP-XX-YYY)
- category(機能要件 / 非機能要件 / 体制 / スケジュール / 商務)
- priority(必須 / 推奨 / 任意)
- source_section(原本での章番号)
3. 同じ要求が複数章で言及されている場合、cross_referenceで紐づけ
## 出力フォーマット
- ファイル:`tmp/rfp/{rfp-id}/requirements.yaml`
- 構造:requirements: [{id, title, body, category, priority, source_section, cross_reference}]
## 厳守
- 要求項目の解釈は変えない(原文に忠実に転記)
- 「想定」「察するに」など推測表現を提案書に持ち込まない
- 不明確な要求はclarification_needed: true でフラグ付け
「原文に忠実に転記」が最大のポイント。RFP要求項目をAIが要約・意訳すると、後工程で齟齬が発生します。
ステップ2:提案書骨子Skillを作る
.claude/skills/proposal-draft/SKILL.md を用意します。
---
name: proposal-draft
description: tmp/rfp/{rfp-id}/requirements.yaml と docs/proposals-archive/ を参照し、提案書骨子を tmp/proposals/{rfp-id}/draft.md に出力する
disable-model-invocation: true
allowed-tools: Read, Write, Glob
---
# 提案書骨子生成Skill
## 入力
- `tmp/rfp/{rfp-id}/requirements.yaml`
- `docs/proposals-archive/`:過去提案レポジトリ
## 処理
1. 要求項目をカテゴリ別に集約
2. 過去提案から「業界・規模・スコープ」が近い提案を3件以内で選定
3. 自社共通の章立てテンプレ(CLAUDE.mdに記載)に従い骨子を生成
4. 各章で「過去提案を参照したフレーズ」と「新規執筆が必要なフレーズ」を分離表示
5. 差別化要素の章は **空欄** で出力(PMが手で書く)
## 出力フォーマット
- ファイル:`tmp/proposals/{rfp-id}/draft.md`
- 章立て:①サマリー ②理解と課題認識 ③提案範囲 ④実施体制 ⑤スケジュール ⑥見積(根拠別Skill参照)⑦差別化要素(**空欄**)⑧リスクと前提
## 厳守
- 差別化要素章はAIが書かない
- 過去提案の文章を流用する場合「参照元提案ID」を必ず記載
- 要求項目の取りこぼしチェックを最終章で実行
「差別化要素は空欄」が運用の鍵。提案の競争力はそこに集約されるため、AIに書かせると平均的な提案にしかなりません。
ステップ3:CLAUDE.mdに提案運用ルールを書く
## 提案書運用ルール
### 自社共通の章立てテンプレ
1. サマリー(A4 1枚)
2. 貴社業務の理解と課題認識
3. 提案範囲(スコープ・除外)
4. 実施体制
5. スケジュール
6. 見積
7. 差別化要素(自社固有)
8. リスクと前提
### AIに書かせる章・書かせない章
- AIが書く:①サマリー ②課題認識 ③提案範囲 ④実施体制 ⑤スケジュール ⑥見積根拠
- AIが書かない:⑦差別化要素 ⑧リスクと前提(事業判断のため)
### 過去提案の参照ルール
- 業界・規模・スコープの3軸で類似案件を選ぶ
- 流用する場合は必ず「参照元提案ID」を提案書ドラフトに記載
- クライアント固有名・案件固有数値は流用しない(必ず置換)
「AIに書かせない章」を明示するのが運用の核心です。差別化要素とリスクは事業判断であり、ここをAIに書かせると平均的な提案になります。
ステップ4:実際の運用フロー
RFPが届いた当日からの動きは次の通りです。
- 当日:
docs/rfp/{rfp-id}/source/にRFP原本を配置 →/rfp-ingestで要求項目構造化(30分) - 翌日朝:
/proposal-draftで骨子生成(30分)→ 取りこぼしチェックリストを朝会で確認 - 翌日午後〜:差別化要素の議論に集中。骨子はすでに揃っているため、戦略議論にフルで時間を使える
- 3日目以降:差別化要素を反映、社内レビュー、最終化
慣れれば、提出までの工数を従来比で半減できます。重要なのは、**「差別化を考える時間が確保される」**こと。
期待効果と運用上の注意点
導入チームから報告される効果は3点です。
- RFP対応の初動が3日→半日:要求項目構造化と骨子生成が自動化される
- 要求項目の取りこぼしが激減:構造化YAMLで漏れ確認が容易になる
- 差別化議論に時間を使える:骨子作成の徹夜が消えるため、戦略思考にリソースを振れる
落とし穴は3つ。
- 過去提案レポジトリのメンテを怠らない:四半期ごとに整理し、廃案件を退避する
- AIで「差別化要素」を書かせない:競争力を失う最大の落とし穴
- クライアント固有情報の流用に注意:数値・固有名は必ず置換、機密情報は流用しない
まとめ
- RFP対応の徹夜は要求項目転記と過去提案検索が原因
- Skillで構造化と骨子生成を自動化すれば、差別化議論に時間を使えるようになる
- 「AIに書かせない章」を明示することで、提案の競争力を維持できる
- 過去提案レポジトリの整備が、AI活用の前提条件
ここまでで「動く提案書ドラフト生成器」は手に入ります。実務でこれを“受注に繋がる提案運用”に育てるには、提案戦略の設計、価格戦略、競合分析、クロージングまでの動線設計が必要です。
SLS-102『IT営業の提案設計』 と AIX-104『AIで進める提案フェーズ』 を組み合わせると、本記事のSkillをベースに、RFP対応〜受注までを通したPM・プリセールス運用を体系で学べます。「RFPが来るたびに徹夜になる」プリセールス・PMが、最短で“仕組みで対応する運用”に到達するための導線です。