RFP（提案依頼書）は、欲しい機能を並べる資料ではなく、複数の提案を同じ条件で評価するための資料です。AIはヒアリング記録や現行資料から要求候補を整理できますが、特定製品の機能をそのまま必須要件にすると公平な比較ができません。
作成前に決めること
- 導入の背景と解決したい問題
- 利用者と利用場面
- 現行業務と対象範囲
- 必須要件と希望要件
- セキュリティ・法務・運用上の制約
- 想定利用量と期間
- 提案書の回答形式
- 評価基準とスケジュール
要求を成果で書く
製品名や実装方法を指定する前に、「誰が、どの業務を、どの条件で完了できること」のように成果を記載します。実装方式を必須にする場合は、既存環境や規程など理由を明記します。
> 現行業務、課題、利用者、制約からRFP案を作成してください。要求を「必須・希望・提案希望」に分け、各項目に目的、確認方法、回答形式を付けてください。入力にない予算や期限は補完せず、未確認事項として示してください。
比較できる回答形式にする
「対応可能ですか」だけでは、標準機能、追加開発、外部サービス、将来予定が混ざります。標準対応、設定対応、追加費用、開発、非対応、提供予定を分けて回答させます。費用は初期、月額、従量、保守、移行に分けます。
評価基準を先に作る
提案を見てから配点を変えると、公平性が下がります。業務適合、費用、安全性、運用、サポート、導入実績などの重みを募集前に決めます。AIには不足観点を指摘させ、人が最終決定します。
配布前の確認
- 要件が特定製品だけに有利ではない
- 必須と希望が区別されている
- 数値の単位と対象期間がある
- 回答期限と質問方法が明確
- 機密情報の共有条件を定めている
- 契約・法務・セキュリティ担当が確認した
まとめ
AIはRFPの構造化と不足項目の発見に使えます。目的と成果から要求を書き、対応方法、費用、条件を同じ形式で回答させることで、複数提案を公平に評価しやすくなります。
実践確認：この記事を現場で使う手順
RFPの要求事項をAIで整理する方法を実務へ入れるときは、AIに完成品を一度で作らせるより、事実整理・下書き・確認を分けます。確認の中心は根拠資料・数値・承認者・更新責任です。入力資料の責任者と最終承認者を同じ人にせず、根拠をたどれる状態を残します。
入力を4つに分ける
- 確定事実：日時、担当、金額、決定済みの条件
- 引用・根拠：会議記録、規程、見積書、一次資料のURL
- 仮説：まだ確認できていない原因や効果
- 未確認事項：誰にいつ確認するかが必要な項目
この区分を付けてからAIへ渡すと、推測が事実のように混ざる問題を減らせます。個人情報や機密情報は、利用環境と社内規程を確認し、不要な部分を伏せます。
下書き用の指示例
> 次の資料から「RFPの要求事項をAIで整理する方法」の下書きを作ってください。確定事実と仮説を混ぜず、数値には出典を付け、情報が不足する箇所は「要確認」と表示してください。読み手が判断・実行するために必要な項目を先に並べ、表現を整えるのは最後にしてください。
人が確認する順番
- 人名、会社名、日付、金額、単位を元資料と照合する
- 「決定」「予定」「提案」「推測」の区別を確認する
- 担当者と期限が本文のどこにあるか確認する
- 読み手が次に行う操作を一つに絞る
- AIへ入力してはいけない情報が残っていないか確認する
1週間の試行で測る
完成時間だけでなく、修正回数、事実誤り、確認のために戻った資料数、読み手からの質問数を記録します。根拠資料・数値・承認者・更新責任の抜けが続く場合は、プロンプトを長くするのではなく、入力テンプレートへ必須欄を追加します。効果が確認できるまでは、AI出力を自動送信・自動承認しない運用が安全です。
