良いRFPが、良いAI発注を決める ― RFPとベンダー選定

AI開発の外注がうまくいくかどうかは、契約の巧拙よりも前に、RFP(提案依頼書)の質でほぼ決まります。RFPは発注側が自分の課題を言語化した「宿題の提出物」であり、その質が提案の質の上限を決め、選定の質が案件全体の成否を左右するからです。本コラムでは、避けるべき2つの極端、良いRFPに必ず入れる8要素、そして「課題を書き、姿勢で選ぶ」ためのベンダー選定と見積り比較の実務を、発注担当・情シス・購買の視点で整理します。

RFPで避けるべき2つの極端

RFPが失敗するとき、その多くは正反対の2つの方向に振れています。どちらも「良い提案が集まらない」という同じ結果を招きます。

極端	典型的な書き方	何が起きるか
曖昧すぎる(丸投げの1行RFP)	「AIで業務を効率化したい」	ベンダーは推測で提案するしかなく、提案は見栄えの勝負に。選定の根拠が「プレゼンのうまさ」になる
指定しすぎる(過剰な仕様固め)	「モデルXでRAGを構築し…」	発注側の思い込みが解き方を縛り、ベンダーの専門性が活きない。うまくいかない時、責任は指定した側に返る

分担の原則はシンプルです。「何を解決したいか」は発注側にしか書けず、「どう解くか」はベンダーの専門領域。良いRFPは業務課題と制約と成功基準を具体的に書き、実現方式はベンダーの提案に委ねます。丸投げでも仕様固めでもない中間に、良いRFPは位置します。

良いRFPに必ず入れる8要素

良いRFPの条件は「課題を書く。解き方を指定しすぎない」に尽きますが、それを具体化すると次の8つの要素になります。発注前段で目的・オーナー・データの現状・運用の担い手が定まっていれば、この8要素は素直に書けます。

#	要素	書くべき中身
1	背景と業務課題	どの業務の・何が・どう困っているか。可能なら件数・時間・エラー率などの数値で
2	成功の定義と評価基準	評価データと判定基準を、発注側も一緒に作る前提であることを明記する
3	データの現状	種類・量・形式・所在・品質の実態。きれいに見せない
4	機微度と制約	出せる/出せないデータ、リージョンや契約の制約、準拠すべきポリシー
5	利用者と運用の担い手	誰が使い、納品後は誰が運用するか。引き取り物一覧などナレッジ移転の要求
6	体制とSME	発注側が提供できる稼働(SME・データ・意思決定)と、ベンダーへの体制要求
7	スケジュールと予算感	フェーズ分割(PoC→本開発→運用)の想定と、各フェーズの判断ポイント
8	提案してほしいこと(スコープ)	方式・体制・費用(構築費と運用費を必ず分けて)・リスク・類似実績

Point

要素3のデータの現実を隠すと、見積りが狂い、後で全員が不幸になります。旧版の混在、オーナー不明の文書、スキャンPDFの残存 ― こうした「汚さ」を正直に書くことこそが、実は選定の道具になります。正直なRFPには誠実なベンダーが整備込みの現実的な提案を返し、逆に「整備の行がない安い見積り」をこの段階で見分けられるからです。

ベンダー選定 ― 技術は前提、姿勢が予後を決める

良いRFPを出したら、次は選定です。ここで見るべきは技術力だけではありません。技術・実績は前提条件であり、AI開発の成否を最終的に分けるのは進め方と姿勢です。

技術・実績の見極め

実績は「使われ続けているか」で聞く。類似案件を「何を作ったか」ではなく「本番でどれくらい使われ続けているか」で確認する。PoC実績の数は当てにならない。
評価・監視・運用を具体的に語れるか。ゴールデンセット・回帰・段階リリースといった語彙が出てくるか。精度を安請け合いするより「評価基準を一緒に作りましょう」と言うベンダーを信頼する。
セキュリティ・ガバナンスへの姿勢。データの取扱い・学習利用の否定・権限設計を、こちらが聞く前に説明してくるか。

姿勢の見極め ― ここが予後を決める

姿勢は資料では分かりません。質問への反応と提案の中身でしか測れません。次の3点は特に予後を左右します。

ナレッジ移転への態度。ドキュメント・ソース・評価資産の引き渡しや、ペア作業・引き継ぎを渋らず提案に含めるか。渋る姿勢はロックインで儲けるモデルの兆候。
「作らない提案」ができるか。「既製SaaSで足ります」「エージェントでなくワークフローで十分」と言えるベンダーは、顧客の利益で考えている。
発注側への要求を明確に言うか。「御社にはSMEの時間とデータ整備をお願いします」と言うベンダーは成功の条件を理解している。何も求めないベンダーは丸投げを受ける気でいる。

Point

選定に迷ったら「小さく試す発注」が有効です。評価設計やデータ診断など数十万円規模の有償タスクを複数社に出し、仕事ぶりで選びます。実物の仕事は、提案書より雄弁です。

商談で効く15の質問

姿勢は質問への反応に表れます。以下は商談でベンダーに投げたい15の質問と、良い回答・危険な回答の兆候です。尋問ではなく、成功の条件を共有できる相手かどうかの相互確認として使ってください。

#	質問	良い回答の兆候	危険な回答の兆候
1	類似案件は今も使われていますか	利用率・改善サイクルの具体	「納品実績多数」で止まる
2	精度はどのくらい出ますか	「データ次第。評価基準を一緒に」	「95%出ます」と即答
3	当社のデータで何が問題になりますか	旧版・権限・スキャンPDF等を具体指摘	「問題ありません」
4	評価はどう行いますか	評価セット・回帰・安全性テストの語彙	「デモで確認いただきます」
5	本番後の品質劣化にどう気づきますか	監視・定点測定の設計を語る	「劣化はしません」
6	当社に何をお願いしたいですか	SME稼働・データ・意思決定を明確に要求	「お任せください」
7	プロンプトと評価データは納品物ですか	「もちろん。版管理込みで」	「ノウハウなので…」
8	御社が撤退する場合、当社は何を持っていますか	引き渡し一覧を即答	回答が曖昧
9	AIを使わない解決策はありますか	既製品・ルールベース案も比較提示	「AIが最適です」一択
10	運用費はいくらですか	利用量前提つきの内訳	「使い方次第です」のみ
11	どのモデル/基盤を使い、変更時はどうなりますか	切替可能な構成と追従の考え方	特定製品への固定
12	データはどこに保存され、学習に使われますか	聞く前に説明してくる水準	確認しないと答えられない
13	誰が実際に手を動かしますか	実担当者が商談に同席	営業のみで技術者不在
14	途中で前提が崩れたらどうしますか	変更管理・フェーズ出口での判断を語る	「柔軟に対応します」のみ
15	失敗した案件の話を聞かせてください	具体的な失敗と学びを語れる	「失敗はありません」

特に7・8・9・15は効きます。ナレッジ移転、出口(撤退時の引き取り)、「作らない提案」、そして失敗を語れるか ― この4つに姿勢が凝縮されます。質問2に即答するベンダーより、「一緒に作りましょう」と言うベンダーのほうが予後は良い、というのが実務の感触です。

見積り比較 ― 総額でなく内訳と前提を揃える

相見積りは、金額の大小を比べるためではなく、内訳と前提を同じ土俵に並べるために使います。同じ金額でも中身はまるで違い、逆に金額差の正体が「同じ仕事をしていないだけ」であることも珍しくありません。

安すぎる見積りの罠。データ整備・評価構築・ドキュメント・引き継ぎが抜けている可能性が高い。抜けた分は後で追加費用か品質の欠落として必ず戻ってくる。
運用費が別掲されているか。API利用料の見込み(前提利用量とともに)・監視・改善・モデル更新対応。構築費だけの提案は比較対象にしない。
前提条件を読む。「データは整備済みとする」「評価データは貴社支給」といった前提は、そのまま発注側の宿題リスト。現実と合っているかを照合する。
内訳の行で識別する。「データ整備」「評価」「ドキュメント」「移転」「運用」の行があるか ― 行の有無が、そのベンダーの仕事の定義を映します。

正しい手順は、まず不足している行を安いほうのベンダーに質問して埋め、揃えた総額で再比較すること。揃えた結果その会社が誠実に増額してくるなら比較続行、はぐらかすなら離脱のシグナルです。価格比較の前に、土俵を揃える。これが見積りの読み方の要諦です。

RFPで「課題を書き」、選定で「姿勢で選ぶ」。この2つがそろえば、AI発注の成否は始まる前に半ば決まっています。ベンダーを選んだら、次は契約とプロジェクトの進め方 ― 出口まで決めて始める段階へ進みます。

本文中のRFP記入例・企業像・質問への回答例・見積りの数値などは、説明のための架空のモデルケースです。特定の実在企業・製品を指すものではありません。記載内容は2026年7月時点の情報に基づきます。