ClaudeでRFPの回答ドラフトを過去回答から組み立てる手順
過去のRFP回答集をClaudeのProjectに置き、設問ごとに回答を転用します。出典のない断言を洗い出す検査パスまでの手順をまとめます。
RFP(提案依頼書)への回答は、設問の半分以上が過去案件と似ています。会社概要、セキュリティ体制、導入実績、サポート体制、料金の考え方などです。ClaudeのProjectに過去の回答集を置いておくと、設問ごとに使える回答を探して転用した下書きを作らせ、さらに「裏付けのない断言」を別のパスで洗い出せます。
RFP回答で怖いのは、遅さよりも、過去回答の古い数字や取得していない認証を、そのまま提出してしまうことです。この記事では、回答集の整え方、Projectの指示文、設問ごとの転用手順、検査パスの順に進めます。
過去回答集をProjectに置くと何が変わるか
Projectは、専用のチャット履歴とナレッジ(知識ベース)を持つ作業スペースです。ナレッジに置いた文書は、そのProject内のすべてのチャットで文脈として使われます。ここに過去のRFP回答を置いておけば、毎回ファイルを添付し直さなくても、新しい案件の設問を貼るだけで「過去に似た設問へどう答えたか」を参照させられます。
変わるのは作業の順序です。ゼロから書く代わりに、次の流れになります。
RFP回答ドラフトの流れ
- 1
回答集を整える
過去回答を設問と回答の対で読める形にして、Projectのナレッジに置きます。
- 2
指示文で規則を固定する
転用の優先順位と、出典を必ず付けるルールをProject指示に書きます。
- 3
設問ごとに転用する
新しいRFPの設問を番号付きで渡し、設問ごとに回答案と出典ファイルを返させます。
- 4
検査パスで断言を洗う
出来上がった下書き全体を、別の依頼で「根拠のない断言」だけに絞って点検させます。
- 5
担当者が裏取りして提出する
数字、認証、契約条件は、社内の一次資料と突き合わせてから出します。
ProjectはFreeプランを含む全ユーザーが使えます。ただしFreeで作れるProjectは最大5つです。大量の回答集を載せる運用は、RAGが自動で働く有料プラン(Pro、Max、Team、Enterprise)のほうが現実的です。
回答集に入れる素材とファイルの整え方
素材は「過去に提出した回答」だけでは足りません。回答の根拠になる一次資料も一緒に置くと、後の検査パスで照合できます。
| 素材 | 役割 | 整え方 |
|---|---|---|
| 過去のRFP回答(設問と回答の対) | 役割転用元 | 整え方案件ごとに1ファイル。設問番号と設問文を残す |
| 会社概要・サービス紹介 | 役割基礎情報 | 整え方最新版1本にまとめ、旧版は入れない |
| セキュリティ・個人情報の方針文書 | 役割認証や体制の根拠 | 整え方取得済みの認証名と日付を明記 |
| 導入事例・実績表 | 役割実績の根拠 | 整え方公開可否の区分を列に持たせる |
| 料金表・SLAの定義 | 役割数値の根拠 | 整え方改定日を先頭に書く |
| 落選・失注時の講評 | 役割改善材料 | 整え方あれば案件ファイルの末尾に付ける |
ファイル名と中身で気をつけること
ファイル名は、見ただけで中身が分かる形にします。ヘルプセンターのRAG解説は、分かりやすいファイル名を使うこと、関連する文書を同じProjectにまとめること、質問でファイル名を指定して検索を絞ることを勧めています。
rfp_2025-11_製造A社_回答.docx
rfp_2026-03_小売B社_回答.docx
evidence_security-policy_2026-04.pdf
evidence_sla-definition_2026-02.pdfアップロードの条件も押さえておきます。
- Projectのファイルは1ファイル30MBまでで、数に上限はないものの、合計がコンテキストウィンドウに収まる必要があります
- Projectでは基本的にテキスト抽出だけが使われます(マルチモーダルPDFは例外)。図表の中にしか書かれていない情報は、本文にも文字で書き起こしておくと確実です
- XLSXをアップロードするには、アカウントでコード実行とファイル作成を有効にする必要があります
- 100ページ以下のPDFは図や表の視覚要素も解析されます。101〜1,000ページのPDFはテキストのみです
顧客名と機密情報を先に処理する
過去回答には、他社の社名、金額、担当者名が含まれています。回答集に入れる前に、次の2点を決めておきます。
- 他社名は「製造業A社」のように置き換えるか、転用の対象から外す
- 秘密保持契約で開示が制限されている案件は、そもそも入れない
転用の段階でClaudeが他社の固有名詞を新しい回答へ持ち込むと、提出前に気づけなければ事故になります。指示文でもこれを禁じておきます(次節)。
Project指示に書く3つのルール
Projectには、そこでのチャット全体に効く指示文を設定できます。画面の「Set project instructions」から書き込み、保存します。RFP用には、次の3つを入れると下書きの質が揃います。
あなたはRFP回答の下書きを作る担当です。
ナレッジにある過去回答と根拠資料だけを材料にします。
1. 転用ルール
- 設問ごとに、最も近い過去回答を1〜2件選び、
回答案を作る。選んだファイル名と設問番号を必ず添える。
- 近い過去回答がない設問は「新規」と明記し、
推測で埋めない。
2. 出典ルール
- 数値、認証名、実績社数、SLAの値、日付には、
根拠資料のファイル名を括弧書きで付ける。
- 根拠資料に見つからない場合は、その箇所を
[要確認:根拠なし] と書く。
3. 混入防止ルール
- 過去案件の社名、金額、担当者名は新しい回答に
持ち込まない。必要なら「他社事例」と書く。ここで効くのは「近い回答がないときは新規と書く」と「根拠が見つからない箇所に印を付ける」の2点です。これを書いておかないと、設問に何か答えるという方向に引っ張られて、それらしい文章で空白を埋めがちです。
ヘルプセンターの説明では、Project内のチャットの文脈はチャット同士では共有されず、共有したい情報はナレッジに追加する必要があります。「このRFPでは○○を強調する」のような案件固有の方針は、チャットごとに伝えるか、案件用のメモファイルとしてナレッジに入れます。
設問ごとに回答を転用する手順
新しいRFPが届いたら、設問を番号付きの一覧にして貼ります。まとめて貼って一度に全問を作らせるより、10問前後ずつ区切るほうが、出典の対応を人間が追いやすくなります。
次のRFPの設問3-1〜3-8について回答案を作ってください。
出力は表形式で、列は次の4つです。
設問番号 / 回答案 / 出典(ファイル名と設問番号) / 区分
区分は「そのまま転用」「要調整」「新規」のいずれかにします。
貴社が重視している点: クラウド移行の経験と、情報漏えい対策の体制。
---
3-1 貴社の情報セキュリティ体制を説明してください。
3-2 過去3年間の同種案件の実績を記載してください。
(以下略)返ってくる表は、例えば次のような形になります(以下は形式の例示です)。
| 設問番号 | 回答案 | 出典 | 区分 |
|---|---|---|---|
| 3-1 | 回答案情報セキュリティ方針に基づく管理体制を…(以下略) | 出典evidence_security-policy / rfp_2026-03設問4 | 区分要調整 |
| 3-2 | 回答案製造業A社でのクラウド移行など…(以下略) | 出典rfp_2025-11設問6 | 区分要調整 |
| 3-5 | 回答案(近い過去回答なし) | 出典なし | 区分新規 |
区分の列が検査の入口になります。「そのまま転用」は日付と数字の鮮度を、「要調整」は書き換えた差分を、「新規」は担当者が書く内容を、それぞれ見る場所です。人が見るべき箇所に優先順位が付きます。
設問の意図を取り違えさせない
似た設問でも、聞かれている範囲が違うことがあります。「過去3年の実績」と「同種案件の実績」では、数える対象が変わります。転用する前に、設問の要求(件数、期間、記載形式、文字数制限)を一覧にさせると取り違えが減ります。
各設問の要求条件(件数・期間・文字数・必須記載項目)を
先に一覧化してください。回答案はその後に作ります。回答集のどの回答が、要求条件を満たしているかも合わせて見させます。
根拠のない断言を洗い出す検査パス
下書きができたら、書いたチャットとは別の依頼として検査を行います。書かせた同じ流れで「間違いはないか」と聞くより、点検だけを目的にした依頼のほうが、見る対象が絞れます。
下書き全体を点検してください。
文章の改善は不要です。次に当てはまる記述だけを一覧にします。
- 数値(社数、件数、率、金額、期間)
- 認証・資格・法令対応の名称
- 「業界No.1」「100%」などの最上級・断定表現
- 将来の約束(対応予定、開発予定)
- 他社の固有名詞
各項目に、ナレッジ内の根拠ファイルと該当箇所を付けてください。
見つからないものは「根拠なし」と書いてください。出てきた一覧を、断言の種類ごとに人が裏取りします。
断言の種類と裏取り先
数値(社数・率・金額)
過去回答の値は、その時点のものです。直近の実績表や料金表で更新日を確かめます。
認証・資格・法令対応
取得済みか、更新期限内かを、認証の写しや登録簿で突き合わせます。
最上級・全数の断言
調査主体と時期が示せない「No.1」「100%」は、書き換えるか削ります。
将来の約束
開発や対応の予定は、契約上の義務として読まれ得ます。担当部門の承認を取ります。
検査の限界を知っておく
この検査は、見落としの数を減らす手段であって、正しさの保証ではありません。Claudeが「根拠あり」と付けた出典が、実際にはその主張を支えていないことがあります。仕組みと減らし方は、Claudeの間違った回答はなぜ起きるのかにまとめています。
実務では、次の二段構えが無理がありません。
- Claudeに「根拠あり」と答えた箇所は、出典のファイルを開いて該当文を人が確かめる
- 「根拠なし」と答えた箇所は、担当者が根拠資料を探すか、記述を落とす
数字と認証名は全件を確かめ、文章表現の部分は抜き取りで足ります。
回答集を育てるときの落とし穴
回答集が大きくなるとRAGに切り替わる
有料プランでは、ナレッジがコンテキストウィンドウの上限に近づくと、RAGモードが自動で有効になります。容量は最大10倍に広がり、画面には視覚的な表示が出ます。このとき、Claudeはナレッジ全体を読み込む代わりに、検索ツールで関連箇所を取り出して答えます。
RFPの文脈で意味があるのは、検索で取り出せなかった過去回答は、回答案に反映されない可能性があることです。「近い回答がない」と返ってきても、検索が拾えていないだけのことがあります。そのときはファイル名を指定して聞き直します。
rfp_2026-03_小売B社_回答.docx の設問4を読んで、
今回の設問3-1と照らしてください。RAGの仕組みはClaude ProjectsのRAG検索の仕組みと全文投入との違いで詳しく扱っています。
共有範囲を決めてから過去回答を入れる
Team・Enterpriseプランでは、Projectを組織内の特定のメンバーや組織全体に共有できます。「Can view」の権限でも、メンバーはProjectの内容、ナレッジ、指示を見て、Project内でチャットできます。過去のRFP回答には他社の事情や価格が含まれるため、共有先を営業部門の限定メンバーに絞る形から始める選択肢があります。
作成時の公開範囲は、非公開(自分と招待したメンバーのみ)か、組織全体かを選びます。なお、公開Projectの機能をOwnerが無効にしている組織では、組織全体への共有は選べません。
既存チャットの過去回答をProjectへ移す
すでにチャットで作った回答をナレッジ代わりに使いたいときは、チャット名の横のドロップダウンから「Add to project」で移せます。ヘルプセンターの説明では、チャット間で文脈は共有されず、共有したい情報はナレッジに追加する必要があります。残したい回答は、ファイルとしてナレッジへ書き出しておきます。
Projectsの新しい版との関係
ヘルプセンターには、Projectsの新版(ベータ)が段階的に提供されると書かれています。新版は、まず一部のPro・MaxのClaude Code利用者に出ています。チャットとCoworkにある既存のProjectは、これまでどおり動きます。この記事の手順は既存のProjectを前提にしています。新版の位置づけはClaude CodeのProjectsが刷新を参照してください。
隣接する用途との使い分け
同じ「過去の文書を材料に新しい文書を作る」作業でも、向く手順が異なります。
| 場面 | 向く進め方 |
|---|---|
| 助成金・補助金の申請書 | 向く進め方採択実績をモジュール化して組み替える(助成金提案書の組み立てライン) |
| RFPの設問ごとの回答 | 向く進め方本記事。設問と過去回答を対応づけ、出典を付ける |
| 提案書・見積もり全般 | 向く進め方営業の流れの中で下書きを任せる範囲を決める(Cowork営業の提案書と見積もり) |
| 契約書のレビュー基準 | 向く進め方基準をナレッジと指示に落とす(法務レビューのプレイブック) |
見積書や提案書の作成と署名追跡を外部サービスと連携させたい場合は、ClaudeとPandaDocの連携が材料になります。
まとめ
RFP回答の下書きは、過去回答の検索と、出典の確認の2つに分けると進みます。前者はProjectの指示文と回答集の整備で任せやすく、後者は検査パスで候補を絞ったうえで、人が数字と認証を一次資料に当てる作業です。
最初は直近の案件1本で試し、区分の列(そのまま転用、要調整、新規)の割合を見ると、回答集の弱い領域が分かります。「新規」が多い設問分野は、次に回答集へ足す資料の候補です。