ClaudeでRFPの要件を提案書の章立てに対応づける手順
RFPの必須要件と配点を拾い、提案書の章と根拠資料に割り当てる対応表をClaude Projectsで作る手順です。質疑回答の反映と要件抜けの検算まで扱います。
RFP(提案依頼書)への提案で一番痛いのは、書いた内容の出来ではなく、必須要件を一つ落として失格になることです。文章を速く書くより先に、要件・配点・提案書の章・根拠資料を一枚の対応表に結ぶと、抜けが書き始める前に見つかります。この記事では、その対応表をClaudeのProjectsで作り、提案書の骨子に落とすまでの手順をまとめます。
営業が提案書と見積もりの下書きを作る流れはCowork営業で提案書と見積もりの下書きをどこまで任せるかで扱っています。ここで扱うのは、その前段にあたる「RFPの要件を取りこぼさない」作業です。
対応表が提案書づくりの土台になる理由
対応表は、RFPの一文一文を「提案書のどの章で、どの資料を根拠に答えるか」に結びつけた一覧です。官公庁や大企業の調達では、評価委員が配点表に沿って提案書を採点します。章立てが配点の並びとずれていると、良い内容でも評価者が探しにくくなります。
対応表に持たせる列は次の7つです。
| 列 | 中身 |
|---|---|
| 要件ID | 中身R-001のように、RFPの出現順に振る番号 |
| 原文 | 中身要件の文言をそのまま写したもの |
| 区分 | 中身必須・任意・参考のどれか |
| 配点 | 中身評価基準書にある点数。記載がなければ空欄 |
| 提案書の章 | 中身答えを書く章と節の番号 |
| 根拠資料 | 中身過去提案書・実績資料・見積根拠など、答えの裏づけになるファイル |
| 状態 | 中身未着手・下書き済み・確認済み |
「原文」を要約せず写す列にしておくのが肝です。要約を挟むと、Claudeが言い換えた時点で条件が一つ消えることがあります。原文が残っていれば、人が後から突き合わせられます。
Projectsに材料を置く
Projectsは、独自のチャット履歴とナレッジ(知識ベース)を持つ作業スペースです。ナレッジに置いた文書は、そのプロジェクト内のすべてのチャットで使われます。RFPのように何度も読み返す資料を毎回貼り直さずに済みます。
置く資料とファイル名
次の4種類を、プロジェクトの「ナレッジ」に追加します。
- RFP本文(仕様書・要求事項の別紙を含む)
- 評価基準書または配点表
- 質疑回答書(公示後に出た補足・訂正)
- 自社の過去提案書と実績資料
ヘルプセンターのRAG解説には、ファイル名を内容が分かる名前にしておくと検索が当たりやすいとあります。「RFP本文_第1版」「質疑回答書_第2回」「過去提案書_A社保守運用」のように、種類と版が読み取れる名前にします。質疑回答は回ごとに別ファイルにして、日付を名前に入れておくと、後の矛盾解消が楽になります。設問ごとの回答文を過去提案から起こす作業は、RFPの回答ドラフトを過去回答から組み立てる手順で扱っています。
資料の形式で気をつける点
プロジェクトのファイルは1つ30MBまでです。ファイル数に上限はありませんが、内容全体がコンテキストウィンドウに収まる必要があります。
PDFの扱いには差があります。100ページ以下のPDFは、本文に加えて図や表の画像も読まれます。101〜1000ページのPDFは本文テキストだけで、視覚要素は分析されません。1000ページを超えるPDFはアップロードできません。
RFPの配点表が画像として貼られたPDFだと、ページ数が多い場合に読まれない恐れがあります。そのときは、配点表の部分だけを別ファイルに切り出すか、表をテキストで書き起こしたファイルを足します。
PDF以外の文書は、テキストだけが抽出されます。埋め込まれた画像はClaudeに読めません。Excelの配点表を渡すなら、XLSXのアップロードにはコード実行とファイル作成の機能を有効にしておく必要があります。
プロジェクトの設定
プロジェクトの作成時に入力する名前と説明には、Claudeはアクセスできません。案件名や発注者名を書いても、Claudeは読みません。基準や前提は、ナレッジかプロジェクト指示に書きます。
Team・Enterpriseプランでは、作成時に公開範囲を選べます。「Keep it private」なら自分と招待したメンバーだけが使えます。提案チームで共有する場合は、メンバーごとに「Can view」と「Can edit」を割り当てます。RFPには発注者の機密が含まれることが多いので、案件の守秘条件を確かめてから共有範囲を決めます。
Freeプランで作れるプロジェクトは5件までです。案件ごとにプロジェクトを分ける運用は、Pro以上のほうが現実的です。
プロジェクト指示に、対応表のルールを書く
「プロジェクト指示」は、そのプロジェクトのすべてのチャットでClaudeが従う指示です。毎回のプロンプトに書くと抜けるので、対応表のルールはここに固定します。
例えば次のような内容を登録します。
あなたは提案書の編集担当です。
RFPと評価基準書、質疑回答書、過去提案書がナレッジにあります。
ルール:
1. 要件は、RFPと質疑回答書の原文から拾う。推測で補わない。
2. 対応表の「原文」列は要約せず、原文のまま写す。
3. 質疑回答書がRFP本文と食い違う場合は、質疑回答書を優先し、
どのファイルのどの箇所かを併記する。
4. 配点が資料に無い要件は、配点欄を「記載なし」にする。
5. 根拠資料は、ナレッジに実在するファイル名だけを書く。
該当する資料が無ければ「根拠資料なし」と書く。5番が効きます。根拠資料の欄に実在しないファイル名が書かれると、後で誰も検証できません。「根拠資料なし」と明記させれば、それ自体が未対応の洗い出しになります。
なお、プロジェクト内のチャット同士はコンテキストを共有しません。チャットAで作った対応表は、ナレッジに追加しない限り、チャットBでは見えません。完成した表はファイルとして保存し、ナレッジに戻します。
要件を拾って対応表の下書きを作る
材料とルールが揃ったら、チャットで対応表を作らせます。一度に全部ではなく、RFPの章ごとに区切ると、取りこぼしが減ります。
RFP本文の「3. 要求事項」を対象に、要件を1件ずつ拾ってください。
次の列の表で出力します。
要件ID / 原文 / 区分(必須・任意・参考)/ 配点 / 提案書の章 / 根拠資料
要件IDはR-001から、RFPの出現順に振ります。
「提案書の章」は、評価基準書の項目の並びに合わせた案を書きます。
拾い終わったら、拾った件数を最後に1行で書いてください。出力の最後に件数を書かせるのは、後で人が数え直すための手がかりです。RFP側の要件数を人が先に数えておけば、件数が合わない時点で抜けが分かります。
章立ての案を評価基準から逆算する
「提案書の章」の列は、いきなり提案書の自然な構成で決めず、評価基準書の項目に合わせた案にします。評価項目が「技術力30点・体制20点・価格30点・実績20点」なら、章も同じ4本柱を軸にします。配点の大きい項目は、章の中でも節を分けて厚く書く場所になります。
評価基準書の項目と配点を一覧にし、提案書の章立て案を出してください。
配点が大きい項目ほど、節を細かく分けます。
各章に、その章が答える要件IDを紐づけてください。返ってきた章立て案は、そのまま採用せず、発注者の様式指定(章番号や分量の指定)と照らします。様式が決まっているRFPでは、指定が優先です。
質疑回答と版の違いを反映する
RFPは公示後に質疑回答で条件が変わります。ここが取りこぼしの典型です。質疑回答書を1回分でも読み込み忘れると、古い条件の対応表ができます。
質疑回答書をナレッジに追加したら、対応表を更新させます。
質疑回答書_第2回をナレッジに追加しました。
RFP本文と食い違う箇所を、要件IDごとに洗い出してください。
- 変更された要件: 旧・新の原文を並べる
- 新しく加わった要件: 新しいIDを振る
- 取り消された要件: 状態を「取消」にする
対応表の該当行を更新した版を出力してください。更新後の表は、ファイル名に版を入れて保存し、ナレッジに追加します。古い版は、ナレッジから外すか、名前に「旧」を付けて残します。古い版が残ったままだと、検索で古い行が拾われる恐れがあります。
ナレッジが大きくなって文書全体が文脈に収まらなくなると、有料プラン(Pro・Max・Team・Enterprise)ではClaudeがRAGモードに切り替えます。RAGはプロジェクトナレッジの検索ツールで必要な箇所だけを引くので、容量は最大10倍に広がります。ただし、検索で当たらなかった箇所は答えに入りません。仕組みの詳細はClaude ProjectsのRAG検索の仕組みにあります。長いRFPを扱うときは、質問に文書名と章番号を入れて検索の的を絞ります。
根拠資料の割り当てと、過去提案書の使い方
対応表の「根拠資料」には、過去提案書の該当箇所や実績資料を割り当てます。ここでClaudeに任せられるのは、関連しそうな箇所の候補出しです。割り当てが正しいかは、人が現物で確かめます。
R-014(24時間365日の監視体制)について、
過去提案書と実績資料から、根拠にできる記述を探してください。
ファイル名と該当箇所を書き、原文を引用してください。
見つからなければ「根拠資料なし」と書いてください。過去提案書の記述は、案件の条件が違えば使えません。「監視体制は24時間」と書かれた過去提案書があっても、今回の要件が別の稼働時間なら、そのまま流用できません。Claudeが挙げた候補には、必ず今回の条件との違いを確認する手順を挟みます。
助成金の提案書で、過去の採択実績を部品に分けて組み直す運用はClaudeでNPOの助成金提案書を量産する仕組みを作るに詳しくあります。過去資料のライブラリ化を進めるなら参考になります。
完成前の検算を二方向でかける
対応表ができたら、抜けと過剰の両方をClaudeに検算させます。
対応表の検算
- 1
要件から章へ
必須要件の全件に、提案書の章が割り当てられているかを確かめます。章が空の行は、答える場所が無い要件です。
- 2
章から要件へ
提案書の各章が、どの要件に答えているかを確かめます。要件に結びつかない章は、評価されない文章になっている可能性があります。
- 3
根拠資料の実在確認
根拠資料の欄にあるファイル名が、ナレッジに実在するかを確かめます。「根拠資料なし」の行は、資料の用意か、書き下ろしが必要です。
対応表を次の観点で検算し、問題のある行だけを一覧にしてください。
1. 区分が「必須」で、提案書の章が空欄の行
2. 同じ要件IDが複数あるか、IDが飛んでいる箇所
3. 根拠資料がナレッジに実在しないファイル名の行
4. 提案書の章のうち、要件IDが1件も紐づいていない章
問題が無い観点は「該当なし」と書いてください。出てきた指摘を鵜呑みにせず、RFP原本に戻って確認します。Claudeが検算でも見落とす可能性はあるので、必須要件の件数だけは人が数えた数字と一致させます。
よくあるつまずき
- 要件が分割されずに1行にまとまる。1つの条文に「および」で複数の義務が並ぶと、1要件として拾われがちです。「条文中に複数の義務があるときは、義務ごとに行を分ける」とルールに加えます
- 別紙の表が読まれていない。別紙が画像のPDFだと、ページ数によっては読まれません。表だけテキスト化して追加します
- 古い質疑回答のまま作業が進む。ファイル名に版と日付を入れ、更新のたびに旧版をナレッジから外します
- 別のチャットで作った表が見えない。チャット間でコンテキストは共有されません。表は保存してナレッジに戻します
- 配点が書かれていない要件に点数が付く。ルール4で「記載なし」と明示させます
新バージョンのProjectsとの関係
Claude Codeを使うProとMaxの一部の利用者には、Projectsの新バージョン(ベータ)が段階的に展開されています。新しい方式では、1つのプロジェクトが1つの会話になり、Claudeが作業を並列のスレッドに分けてクラウドで進めます。既存のチャットとCoworkのプロジェクトは従来どおり動くので、この記事の手順は現行のProjectsにそのまま使えます。
まとめ
RFP対応で守るべき線は「原文を残す」「版を管理する」「根拠資料を実在のファイルに限る」の3つです。対応表そのものはClaudeが速く作れても、必須要件の件数照合と発注者の様式確認は人が持つ作業として残ります。法務文書の基準を同じ仕組みで運用する例はClaude Projectsで法務レビューのプレイブックを標準化する方法で、Projectsのファイル容量の違いはClaudeファイル上限の一覧で確かめられます。