ClaudeでRFPを作成する発注側の手順 — 要件の優先度から提案の採点表まで

システム導入のRFP(提案依頼書)を発注側で作る仕事は、書く量より「何を必須とし、何を加点にするか」を決める量のほうが重い作業です。Claudeには、現行業務フローと要件メモから要件の一覧を起こし、優先度の案を付けるところまでを任せられます。届いた各社の提案を同じ観点で採点する表も、同じ要件表から作れます。

この記事では、要件を一つの表に集約し、その表からRFP本文と採点表の両方を派生させる手順をまとめます。優先度の最終決定と、ベンダーの選定そのものは発注側の担当者の仕事として残ります。

要件表を中心に置くと、RFPと採点表がずれない

RFPの作成と提案の比較でよく起きるのは、RFPに書いた要件と、評価のときに見ている観点が別物になることです。RFPを書いた人と評価する人が違うと、さらにずれます。

ずれを防ぐ方法は、要件表を1枚だけ持ち、RFPの要件章と採点表をその表から作ることです。表の1行が、RFPの1項目であり、採点表の1行になります。

要件表の列は次の6つに絞ります。

「根拠」の列が、後で効きます。根拠のない要件は、現場の要望をそのまま写しただけのことが多く、優先度を下げる候補になります。

Projectsに、案件の材料を置く

材料はProjectsのナレッジに置くと、同じ案件の複数のチャットで共通に使えます。公式ヘルプでは、Projectsは独自のチャット履歴とナレッジベースを持つ作業スペースで、文書や文脈をアップロードして使うものと説明されています。無料プランでも使えますが、作れるプロジェクトは最大5つです。

プロジェクトの作成手順は次のとおりです。

置く材料と、置く前の確認は次のとおりです。

• 現行業務フロー。工程ごとの担当、使っている帳票、例外処理が分かる形にします。フロー図が手元になければ、ヒアリングメモから起こす手順がClaudeで業務フロー図を作成する手順にあります
• 要件メモ。現場の要望、経営層の要請、法令・社内規程による制約を、出所が分かるように並べたものです
• 予算と導入時期の制約。RFPに書く範囲は、社内の決裁状況で決まります
• 過去のRFPや契約書の雛形。社内に様式があるなら、必ず入れます。様式に従う指示は、プロジェクト指示に書きます

ファイルの扱いには上限があります。公式ヘルプでは、プロジェクトのファイルは1ファイル30MBまで、数は無制限ですが、全体がClaudeのコンテキストウィンドウに収まる必要があるとされています。プロジェクトの内容は文章として取り出されるのが基本で、PDF以外の画像は読まれません。業務フローが画像で貼られたWordやPowerPointの場合は、文章に直してから入れます。有料プランでは、ナレッジが上限に近づくとClaudeが自動でRAGモードに切り替わり、容量が最大10倍まで広がります。

もう一つの注意は、チャットの間でコンテキストが共有されないことです。公式ヘルプには、プロジェクトのナレッジに入れない限り、同じプロジェクト内でも別のチャットに情報は引き継がれないとあります。チャットで決めた優先度は、決めるたびにナレッジのファイルへ書き戻します。

入力してよい情報かどうかは、各社の情報取扱い規程で決まります。他社の見積もりや、社外秘の業務データを含む場合は、社内の規程を確かめてから入れます。

プロジェクト指示に書く規則

プロジェクト指示は、すべてのチャットに効きます。RFPの作成では、次のような内容を書いておくと、出力の形が揃います。以下は書き方の一例です。

あなたは、システム導入の調達を担当する発注側の担当者を補助します。
- 要件は必ず「要件ID / 要件の内容 / 根拠 / 優先度 / 確認方法」の表で出す
- 優先度は「必須 / 重要 / あれば加点」の3段階。案として出し、確定はしない
- 「根拠」には、ナレッジのどのファイルのどの記述かを書く。見つからない要件は「根拠なし」と書く
- 要件の内容は、提案書で満たしているかを第三者が判定できる書き方にする
- 推測で要件を足さない。足したい場合は「追加の提案」として別表にする

「根拠なし」と書かせる規則が要です。この指示がないと、業種で一般的な要件が、それらしく足されることがあります。足されたものが本当に必要かは、発注側が判断することです。

手順1:要件を拾い出し、優先度の案を付ける

最初のチャットでは、ナレッジの材料だけから要件を拾わせます。依頼文の例は次のとおりです。

ナレッジの現行業務フローと要件メモから、新システムへの要件を拾い出してください。
工程ごとに、現行のやり方・困りごと・新システムに求めることを分けて、
要件表の形式で出してください。優先度は案で構いません。
メモに矛盾する要望があれば、表とは別に「矛盾・未決事項」としてまとめてください。

返ってきた表で、確認するのは3点です。

1. 根拠のない行。現場の要望として実在するかを、担当者に聞いて確かめます
2. 「必須」が多すぎないか。必須は合否の条件になるため、多いと有力な候補が条件で落ちます。必須は、満たさなければ業務が成立しないものに絞ります
3. 矛盾・未決事項。ここに挙がったものは、RFPを出す前に社内で決める項目です。ベンダーに決めさせるものではありません

優先度の決定には、経営層や現場の責任者の合意が要ります。Claudeの案は議論のたたき台です。会議で決めた結果は、要件表のファイルに書き戻します。

手順2:要件表からRFP本文を組み立てる

要件表が固まったら、RFP本文を派生させます。章立ては社内の様式を優先します。様式がなければ、次の構成が一般的な形です。

• 調達の目的と背景
• 現行業務の概要
• 提案を求める範囲
• 要件(必須要件、重要要件、加点要件)
• 提案書に記載してほしい事項
• 評価の方法と選定のスケジュール
• 契約の条件、守秘義務、問い合わせ窓口

依頼文には、要件表のIDをRFPの項目番号に使う指示を入れます。

要件表から、RFPの「要件」章を作ってください。
必須は合否の条件として、重要と加点は評価の対象として、章を分けます。
各項目の末尾に要件IDを括弧で付けてください。
「確認方法」の列は、「提案書に記載してほしい事項」の章に移して、
どの要件IDに答える記述かが分かるようにしてください。

ここで効くのが、「確認方法」の列です。提案書にどう書いてほしいかを、RFPで先に指定しておくと、各社の提案が同じ並びで届きます。後の採点が楽になります。

契約条件、守秘義務、再委託の可否のような法務の章は、Claudeの下書きを出発点にしても、確定は法務部門か弁護士が行います。

要件表をExcelで持つ場合、公式ヘルプではXLSXのアップロードにコード実行とファイル作成の有効化が必要とされています。無効のままだと表を取り込めないので、CSVに書き出して入れる方法もあります。

手順3:採点表を同じ要件表から作る

採点表は、RFPを出す前に作ります。提案が届いてから観点を決めると、見た目の印象に引きずられるためです。

採点表の形は、次のようにします。

ポイントは「評価の基準」の列です。点数ごとの目安を、提案を見る前に決めておきます。基準が曖昧だと、同じ回答でも評価者によって点がぶれます。

依頼文の例は次のとおりです。

要件表から採点表のExcelを作ってください。
列は、要件ID、区分、配点、評価の基準、各社の根拠箇所、各社の点数にします。
重要と加点の項目には、点数ごとの評価の基準を案として書いてください。
配点の合計と、区分ごとの小計を出す行も入れてください。

案として出てきた基準は、評価者全員で読み合わせます。点数の幅が妥当か、重要度の差が配点に反映されているかは、人が決めます。配点の枠組みの考え方は、自治体の総合評価を例にした入札仕様書と総合評価の審査項目案をClaudeで作る手順が参考になります。民間の調達でも、価格と技術の配点比を事前に決めておく点は同じです。

手順4:届いた提案を、同じ観点で採点する

提案が届いたら、各社の提案書をナレッジに追加し、採点表の列を1社ずつ埋めます。1つのチャットに複数社を混ぜず、1社ごとにチャットを分けると、他社の記述が混ざりにくくなります。依頼文の例は次のとおりです。

ナレッジの採点表に従い、提案Aの提案書を採点してください。
各要件IDについて、根拠とする記述の箇所(章・ページ)を引用し、点数の案を付けてください。
提案書に記述がない要件は「記述なし」とし、点数は0としてください。
推測で「対応していると思われる」とは書かないでください。

採点の途中で確かめることは3つあります。

• 引用の実在。Claudeが示した章・ページが、提案書に実際にあるかを、担当者が抜き取りで開いて確かめます
• 記述なしの扱い。記述がないだけで、実際には対応している場合があります。点数を確定する前に、ベンダーへ質問票を出して確認します
• PDFの読み取り。公式ヘルプによると、PDFは100ページ以下なら図表も解析され、101〜1000ページはテキストのみです。図で示された構成図や画面は、長い提案書だと読まれていない可能性があります。図の内容は、人が見て補います

採点結果は表にまとまりますが、それは合計点の比較のための材料です。価格、ベンダーの財務や体制、デモや面談での印象は、別の観点として総合判断に加えます。見積もりを横並びに揃える作業は、Claudeでベンダー見積もりを比較・正規化する方法で扱っています。

チームで使うときの共有

Team・Enterpriseプランでは、プロジェクトをメンバーに共有できます。権限は「Can view」と「Can edit」の2段階です。前者は内容を見てチャットできますが、編集はできません。後者は指示とナレッジの変更、メンバーの追加ができます。

調達の現場では、次のように分けると事故が減ります。

• RFPを作る担当者と、法務・情報システム部門の確認者は「Can edit」
• 評価委員は、採点表とRFPを見るだけなら「Can view」

提案書には、ベンダーの機密情報が含まれます。評価委員でない人まで見られる状態にならないよう、組織全体への共有は選びません。管理者がプロジェクトの共有を無効にしている場合は、共有そのものができません。

なお、公式ヘルプには、Projectsの新しいバージョンがベータとして段階的に提供されているという記載があります。チャットとCoworkの既存のプロジェクトは従来どおり動くとされています。この記事の画面の呼び方は、従来のプロジェクトのものです。

人が持つ判断

Claudeに任せる範囲と、発注側が持つ範囲を分けておくと、RFPの品質が安定します。

特に、配点と優先度は「何を大事にする会社か」の表明です。Claudeの案をそのまま使うと、自社の事情と合わない配点になります。

つまずきやすい点

要件の粒度がそろわない。「操作が分かりやすいこと」のような曖昧な要件は、提案側が何を書けば満たすのか分かりません。「初めて使う担当者が、マニュアルなしで受注登録まで操作できること。デモで確認する」のように、確認方法とセットで書き直します。

必須要件が機能の羅列になる。機能名で縛ると、別の方法で同じ業務を実現する提案を弾いてしまいます。業務上の成果の形で書くと、提案の幅が残ります。

採点表の後出し。提案を見てから基準を直すと、公平さを説明できません。基準を変える場合は、変更の理由と日付を表に残します。

チャットで決めたことが消える。チャットの内容は別のチャットに引き継がれません。決定事項は、そのつどナレッジのファイルに書き戻します。

RFPの発行後の変更。要件を変更すると、すでに回答中のベンダーへの通知が必要になります。要件表にバージョンの番号と日付を付け、RFPと採点表も同じ版で揃えておきます。

まとめ

発注側のRFPは、要件表を1枚持ち、そこからRFP本文と採点表を派生させると、書いたことと評価することがずれません。Claudeは、要件の拾い出し、書式の統一、基準の案、提案の根拠箇所の抜き出しに向いています。優先度と配点の決定、契約条件の確認、ベンダーの総合判断は、発注側が担う部分です。

提案する側の立場で同じ要件の対応づけを進める手順は、ClaudeでRFPの要件を提案書の章立てに対応づける手順に書かれています。発注側は、その相手方が見る表を先に作る立場だと考えると、要件の書き方の基準が見えてきます。