「複数社にAI導入の提案をもらおうとRFPを作ったが、各社の提案がバラバラで比べられない」「機能を細かく書いたのに、出てきた提案は似たり寄ったりだった」——生成AI導入の依頼先選びで起きやすい失敗です。結論から言うと、生成AI導入のRFPは、機能の一覧を書くのではなく、「解決したい業務課題」「成功の判定方法」「使えるデータと制約」「進め方」の4つを書くと、提案が比較できるようになります。 生成AIは、従来のシステム開発のように仕様を最初に確定しにくいため、仕様の書き込みよりも「何をもって成功とするか」を揃えるほうが比較の精度が上がります。
この記事では、従来型のRFPが生成AIと合いにくい理由、RFPに盛り込む8項目、提案を比べる評価軸、良い例・悪い例までを、AI導入を現場で実装・運用まで伴走する FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア） サービスの DeploAI が解説します。依頼先のタイプの違いは生成AI導入支援の選び方、要件の固め方は生成AIの要件定義はどう進める？、契約は準委任か請負かもあわせてご覧ください。
そもそもRFPとは？——RFIとの違いは
RFP（Request for Proposal：提案依頼書）とは、依頼先の候補に対して、解決したい課題や条件を示し、具体的な提案と見積もりを求める文書です。 複数社に同じ条件で提案を出してもらうことで、比較の土台をそろえるのが目的です。
似た言葉にRFI（Request for Information：情報提供依頼）があります。
| RFI | RFP | |
|---|---|---|
| 目的 | どんな解決策・依頼先があるかを広く集める | 絞り込んだ候補に、具体的な提案と見積もりを求める |
| 出す相手 | 幅広い候補 | 絞り込んだ数社 |
| 使う場面 | 課題や選択肢がまだ整理しきれていない段階 | 課題・条件を示せる段階 |
生成AIのように選択肢が多く変化も速い領域では、先にRFIや相談で課題と選択肢を整理し、そのうえでRFPで条件をそろえて比べる流れが現実的です。
なぜ従来型のRFPは生成AIと相性が悪いことがあるのか？
従来型のRFPは、機能要件を細かく列挙して見積もりを比べる形式ですが、生成AIは仕様と精度を着手前に固定しにくいため、機能の列挙だけでは比較の軸になりにくいことがあります。 機能を細かく書くほど、各社は「書かれた機能を作る前提」で見積もり、肝心の「業務で成果が出るか」は比べられなくなります。
生成AIのRFPは「何を作るか」より「何をもって成功とするか」をそろえる。成果が出ずに止まる問題はAI導入がPoC止まりになる理由でも扱っている。
生成AIのRFPに盛り込む8項目は？
生成AIのRFPに盛り込むのは、背景と課題・対象業務と現状・成功指標・データと制約・セキュリティ要件・システム連携・体制と引き継ぎ・進め方と予算の8項目です。 機能要件の細かな一覧は、この8項目の後ろに回して構いません。
| # | 項目 | 何を書くか | 関連する詳しい記事 |
|---|---|---|---|
| 1 | 背景と解決したい課題 | 何が困っていて、なぜ今やるのか | AI導入の費用対効果 |
| 2 | 対象業務と現状 | 対象の業務の流れ、件数、かかっている時間など現状の数字 | 業務棚卸し |
| 3 | 成功の判定方法 | 何をどう測って「成功」とするか。評価データ・基準 | 生成AIの評価（Evals） |
| 4 | 使えるデータと制約 | データの所在・形式・質、機密度、使えない情報 | RAGの精度改善 |
| 5 | セキュリティ・ガバナンス要件 | 入力情報の扱い、権限、ログ、社内ルール | 生成AIのセキュリティ |
| 6 | システム連携 | 連携したい社内システム・SaaS | システム・SaaS連携 |
| 7 | 体制と引き継ぎ | 自社側の担当、運用の担い手、内製化の想定 | AI内製化ロードマップ |
| 8 | 進め方・契約・予算枠 | 段階の切り方、契約形態の希望、予算の目安 | 導入費用の考え方 |
特に効くのは3つ目の成功の判定方法です。ここが曖昧だと、各社は「良さそうな提案」を出すだけになり、提案の良し悪しを見分けられません。
良いRFPと悪いRFPは何が違う？——社内問い合わせAIの例
同じ「社内問い合わせAIを導入したい」でも、書き方で集まる提案の質が変わります。 以下は説明用の仮の例です。
| 悪い例 | 良い例 | |
|---|---|---|
| 課題 | 「社内問い合わせをAIで自動化したい」 | 「情シスへの問い合わせが月あたり仮に400件あり、うち定型の質問が多く、担当者の対応時間を圧迫している」 |
| 成功の定義 | （書かれていない） | 「過去半年の実際の問い合わせから抽出した評価用の質問セットで、担当者が『そのまま回答に使える』と判定した割合を測る」 |
| データ | 「社内ドキュメントを使う」 | 「規程集・マニュアル（PDF・社内Wiki）が対象。一部に古い版が混在し、更新は情シスが担当」 |
| 制約 | 「セキュリティに配慮すること」 | 「個人情報を含む問い合わせは対象外とし、回答の根拠となった文書を表示する」 |
| 依頼する提案 | 「機能一覧と見積もり」 | 「評価方法の提案・段階の切り方（PoC→本開発）・運用の担い手・費用の内訳」 |
悪い例では、各社が「一般的な問い合わせAI」を前提に提案するため、違いが金額しか残りません。良い例では、評価方法・進め方・運用の担い手という、成果を左右する違いが提案に表れます。この背景にある問い合わせAIの作り方は社内問い合わせ対応AIの作り方で解説しています。
提案は何で比べる？——6つの評価軸
提案を比べる評価軸は、課題の理解度・評価の設計・運用と引き継ぎ・データとセキュリティの扱い・費用の内訳・体制の6つが基本です。 金額だけで比べると、AIの成果を左右する部分が見えなくなります。
- 課題の理解度：RFPに書いていない前提（業務の実態、例外処理）を、質問して確認しようとしているか。
- 評価の設計：成功をどう測るか、事前にデータを見て目標を置く（またはPoCで確定する）提案になっているか。
- 運用と引き継ぎ：本番後の監視・改善、社内で運用できる状態にする計画があるか。
- データとセキュリティの扱い：入力情報の扱い、権限、ログを具体的に説明しているか。
- 費用の内訳：初期・運用・見直しの費用が分かれているか。何が含まれ、何が別かが明確か。
- 体制：誰が現場に入り、自社側に何を求めているか。
たとえば、評価軸ごとに5点満点で採点し、重みを仮に「課題の理解度25・評価の設計25・運用と引き継ぎ20・データとセキュリティ15・費用10・体制5」などと決めておくと、社内の稟議で選定理由を説明しやすくなります（配点は説明用の仮の値で、自社の重視点に合わせて変えます）。稟議の通し方は生成AI導入の社内稟議はどう通す？も参考になります。
RFPで注意したい3つの落とし穴は？
- 精度の保証を鵜呑みにする：生成AIの出力は確率的なため、前提（評価データ・測り方）を示さずに「精度◯%保証」とする提案は、条件を確認したほうがよいでしょう。
- RFPづくりに時間をかけすぎる：細部まで作り込むうちに、構想が古くなります。課題・成功・制約の骨子が書ければ、まず出して質疑で補うほうが進みます。
- 一括で丸ごと依頼する：最初から全部を1本の契約にすると、仕様が動いたときに巻き直しが起きます。段階（構想・PoC→本開発→運用）に分けて提案を求めるほうが安全です。契約形態は準委任か請負かで整理しています。
FDEはRFPの前後でどう関われるか
DeploAI の FDE（Forward Deployed Engineer）は、助言で終わらず、御社のデータ・権限・業務フローの中で実際に動くコードを書き、成果が出るまで伴走するサービスです。「AIで解くべき課題が整理できていない」「RFPに何を書けばよいか分からない」という段階から、無料ヒアリングで相談を受け付けています（課題の整理だけでも可能です）。契約形態は、個別契約に定めがない場合は準委任を基本とし、仕様が確定した開発業務は契約で定めたうえで請負とすることもできます。詳しい条件は利用規約、料金の考え方は料金ページをご覧ください。
まとめ
- 生成AIのRFPは、機能の列挙ではなく、解決したい課題・成功の判定方法・使えるデータと制約・進め方を書くと、提案が比べられる。
- 盛り込むのは、背景と課題／対象業務と現状／成功の判定方法／データと制約／セキュリティ／連携／体制と引き継ぎ／進め方と予算の8項目。
- 提案は金額だけでなく、課題の理解度・評価の設計・運用と引き継ぎなどの6軸で比べる。
- 精度の無条件な保証、作り込みすぎ、一括発注の3つに注意する。
RFPを出す前の課題整理や、提案の比べ方に迷う場合は、無料相談からお気軽にご相談ください。関連記事：生成AI導入支援の選び方／生成AIの要件定義はどう進める？／生成AI開発の契約は準委任か請負か。
