ベンダー提案書は構成や用語が異なるため、ページを順番に読むだけでは比較しにくい資料です。AIを使うと、要求事項への回答、費用、条件、未回答を共通表へ整理できます。ただし、魅力的な文章を高評価にしないよう、評価基準を先に固定します。
比較前に用意するもの
- 最終版RFP
- 質問回答と追加条件
- 評価項目と配点
- 全ベンダーの提案書・見積書
- 必須要件の判定基準
版が違う資料を混ぜないよう、受領日とファイル名を管理します。
共通表へ抽出する
| 項目 | 確認内容 |
|---|---|
| 要件対応 | 標準、設定、開発、非対応 |
| 費用 | 初期、固定、従量、保守、移行 |
| 日程 | 前提、期間、顧客側作業 |
| 体制 | 担当、支援、問い合わせ |
| リスク | 制約、依存、例外 |
| 契約 | 最低期間、解約、データ返却 |
> 各提案書をRFPの要求IDごとに整理し、回答、対応方法、追加費用、前提条件、根拠ページ、未回答を表にしてください。提案書に書かれていない内容は推測せず「記載なし」としてください。評価点は付けないでください。
総費用を同じ期間で見る
初期費用が安くても、従量課金や運用工数で総額が変わります。利用量と期間を同じ条件にし、税、更新、超過、追加アカウント、サポートを確認します。AIの計算結果は見積書と計算式で照合します。
未回答を質問へ変える
記載なしを非対応と決めつけず、追加質問を作ります。質問は全ベンダーへ公平に提示し、回答期限と反映方法を統一します。回答後に評価を更新した人と理由を記録します。
最終判断
採点だけでなく、必須要件の不適合、重大リスク、契約条件を別に確認します。デモや検証を行う場合は、同じシナリオとデータを使います。AIの推薦文ではなく、根拠表と評価委員の合意で決めます。
まとめ
AIでベンダー提案を比較するときは、RFPと評価基準を先に固定し、要求IDごとに対応、費用、条件、根拠を抽出します。未回答を見える化し、人が正式資料と検証結果を確認することで、公平な選定につながります。
実践確認:この記事を現場で使う手順
ベンダー提案書をAIで比較する方法を実務へ入れるときは、AIに完成品を一度で作らせるより、事実整理・下書き・確認を分けます。確認の中心は根拠資料・数値・承認者・更新責任です。入力資料の責任者と最終承認者を同じ人にせず、根拠をたどれる状態を残します。
入力を4つに分ける
- 確定事実:日時、担当、金額、決定済みの条件
- 引用・根拠:会議記録、規程、見積書、一次資料のURL
- 仮説:まだ確認できていない原因や効果
- 未確認事項:誰にいつ確認するかが必要な項目
この区分を付けてからAIへ渡すと、推測が事実のように混ざる問題を減らせます。個人情報や機密情報は、利用環境と社内規程を確認し、不要な部分を伏せます。
下書き用の指示例
> 次の資料から「ベンダー提案書をAIで比較する方法」の下書きを作ってください。確定事実と仮説を混ぜず、数値には出典を付け、情報が不足する箇所は「要確認」と表示してください。読み手が判断・実行するために必要な項目を先に並べ、表現を整えるのは最後にしてください。
人が確認する順番
- 人名、会社名、日付、金額、単位を元資料と照合する
- 「決定」「予定」「提案」「推測」の区別を確認する
- 担当者と期限が本文のどこにあるか確認する
- 読み手が次に行う操作を一つに絞る
- AIへ入力してはいけない情報が残っていないか確認する
1週間の試行で測る
完成時間だけでなく、修正回数、事実誤り、確認のために戻った資料数、読み手からの質問数を記録します。根拠資料・数値・承認者・更新責任の抜けが続く場合は、プロンプトを長くするのではなく、入力テンプレートへ必須欄を追加します。効果が確認できるまでは、AI出力を自動送信・自動承認しない運用が安全です。
