AI開発RFPの書き方｜必須項目11点とテンプレ構成

AI開発のRFPは、業務システム開発のテンプレートをそのまま流用してもうまく機能しない発注書です。
要件定義で機能仕様を固定しやすい業務システムと違い、AI開発は学習と評価を回してみるまで精度が読めず、提供データの質と量にも結果が左右されます。
IT人材のマッチングとSES・業務委託の契約設計に長く携わる現場でも、精度の確約を求めたRFPほど提案が集まらず、見積もりだけが跳ね上がる場面を何度も見てきました。
だからこそ、AI案件では既存の作法を捨てるのではなく、提供データの条件、精度目標と評価方法、成果物と権利帰属の3項目を足し、予算もフェーズ別に書き分ける発想が役立ちます。

AI開発のRFPが通常のシステム開発と違う3つの理由

AI開発のRFPは、通常の業務システム開発と同じ型では書けません。
業務要件を積み上げて機能仕様を固める前提が崩れるうえ、成果物の品質が発注側のデータ条件に左右されるためです。
さらに、工程を分けずに一括請負を求めると、提案が集まりにくくなり、集まっても価格に不確実性の上乗せが起きやすくなります。
だからこそ、AI開発ではRFPの役割そのものを見直しておく必要があります。

仕様が固まらない前提で発注する難しさ

業務システム開発では、要件定義で画面、処理、例外分岐までかなりの精度で仕様を確定できます。
これに対してAI開発は、学習と評価を回してみるまで到達精度が読めません。
RFPの段階で固定できるのは、どの業務課題を解きたいのか、何をもって良しとするのかという評価指標までであり、機能仕様の粒度まで先に書き切ろうとすると、現実の開発プロセスとずれた要求になりがちです。

人材マッチングの現場でも、発注側が業務システムの感覚で「納品物＝完成したAI」を想定してRFPを書き、提案を受けた後で初めて「精度は約束できない」と説明されて計画が止まる場面が繰り返し起きています。
契約形態の前提が共有されていないことが原因で、RFPの段階で工程分割を明示していれば防げたケースは少なくありません。
AI開発では、最初から完成形を断定するより、探索の余地を残したまま進める設計のほうが実務に合います。

品質が発注側の提供データに左右される

学習済みモデルの品質は、ベンダーの実装力だけでは決まりません。
発注側が提供するデータの質、量、ラベル精度に強く依存するため、同じ手法でも結果が大きく変わります。
つまり、ベンダー単独では品質を保証しきれない構造があるのです。
RFPで一方的に高い品質責任を負わせる書き方をすると、提案側はリスクを見込んで慎重になり、提案の具体性が落ちます。

この構造を踏まえると、RFPでは「適合率90%以上を保証すること」のように確約を求めるより、評価指標、評価用データセットの合意方法、打ち切り基準を提案してもらう形が現実的です。
あわせて、学習データ欄には提供時期、件数、形式、ラベル有無、アノテーション分担、社外持ち出し可否を明記しておくべきです。
おすすめです。
ここが曖昧だと、提案段階で比較していた条件が崩れます。

一括請負を求めるRFPが提案を減らす理由

実務では、構想、PoC、実装、運用を分割し、段階ごとに契約する探索的段階型の進め方が標準になっています。
探索が目的の構想・PoCは準委任、要件が固まった実装工程は請負または成果完成型準委任が現実的です。
契約の前提を工程ごとに分けて考えるだけで、RFPの要求水準は落ち着き、提案の粒度もそろいやすくなります。

逆に、全工程を一括請負で発注するRFPは、参加を検討していたベンダーの辞退を招きやすいです。
不確実性を吸収するために高額なリスクプレミアムを上乗せした見積もりが返ってくるため、比較検討できる提案が少数しか集まらない展開も珍しくありません。
AI開発のRFPは、仕様を確定して守らせる文書ではなく、課題と評価軸を示して解き方の提案を引き出す文書として組み立てましょう。
おすすめです。
ここを外すと、汎用テンプレートの流用がそのまま失敗につながります。

RFPを書く前に社内で固める4つの前提

RFPは、社内で前提が固まっているかどうかで出来がほぼ決まります。
業務KPI、データ棚卸し、予算と決裁ルート、横断ヒアリング、提案期間の確保がそろっていれば、ベンダーは技術提案を具体化しやすくなります。
逆にこの前提が曖昧だと、提案は広がるのに比較はしづらいという、使いにくいRFPになります。

業務KPIから逆算して目的を定義する

最初に固めるべきなのは、AIで何を良くしたいかを業務の言葉で言い切ることです。
たとえば「検品工数を月200時間削減」のように、現場の負担や処理量、リードタイムの短縮といった形で目的を定義すると、提案の評価軸がぶれません。
精度○%は手段であって目的ではないため、ここを先に置くと提案側も「何をどこまで実現すべきか」を組み立てやすくなります。

業務KPIが未定のままRFPを出すと、提案の方向性は発散します。
あるベンダーは精度向上を前面に出し、別のベンダーは運用省力化を優先し、さらに別の提案は分析基盤の整備に寄る、という具合に比較不能になりやすいのです。
RFPの段階で「現場のどの手間を、どの水準まで減らすのか」を決めておくと、PoC止まりを避けやすくなり、構想・PoC・実装・運用を分ける進め方でも筋道が通ります。

保有データを5つの観点で棚卸しする

AI案件では、データの所在と形式が社内で把握されていないまま相談が進み、ベンダーからの質問に答えられず提案期間だけが延びるケースが目立ちます。
そこで、保有データは「どのシステムに・何年分・何件・どの形式で・ラベル付きか」の5観点で棚卸ししておく必要があります。
RFP作成前にここを済ませた案件ほど、提案書の具体度が上がりやすいのが実務上の実感です。

とくにラベルなしデータしかない場合は、アノテーション工数が別途発生します。
これは費用だけでなく、期間や体制にも直結する論点です。
学習データ欄には提供時期、件数、形式、ラベル有無、アノテーション分担、社外持ち出し可否まで書き分けておくと、提案側は学習のやり方と評価方法を現実的に組み立てられます。
RFPの6〜8番目にあたる提供データの条件、精度目標と評価方法、成果物と権利帰属は、AI固有の要点としてまとめて記載しておくと整理しやすいでしょう。

部署横断ヒアリングと提案期間の確保

ヒアリングは現場部門、情報システム部門、法務/購買を横断して行うのが基本です。
現場は業務課題を、情報システムは既存環境や接続制約を、法務/購買は契約や持ち出し条件を持っています。
特にデータの社外持ち出し可否は法務確認が必須で、RFP送付後に「そのデータはクラウドに出せない」と判明すると、提案構成をやり直すことになります。
クラウド利用の可否も同時に確認しておくと、後戻りを減らせます。

提案期間も社内で先に決めておくべき前提です。
RFP送付から提案書締め切りまでは最低2週間、データ確認を伴うAI案件では3〜4週間を確保したいところです。
短すぎるとテンプレートを流用した浅い提案しか集まらず、比較検討の意味が薄れます。
フェーズ別に発注するなら、PoCと実装で稟議が分かれる前提まで見ておくと、決裁ルートで詰まりにくくなります。
予算の上限と決裁単位を早めに確認しておくのも、実務ではおすすめです。

AI開発RFPの必須項目11点とテンプレート構成

AI開発RFPでは、目次の段階で勝負の半分が決まります。
まず概要、要求事項、選定の進め方の3ブロックに整理しておくと、発注側が伝えたいことと提案側が知りたいことがずれにくくなります。
さらに必須項目11点を先に並べて粒度をそろえると、ベンダー間の比較がしやすくなり、書けない項目は「提案を求める」と明記する運用まで含めて、RFP全体が実務で使える形になります。

3ブロックに整理する目次の作り方

RFPの章立ては、①概要ブロック、②要求事項ブロック、③選定の進め方ブロックの3つに分けると崩れません。
概要ブロックでは会社概要、背景、課題、目的、スコープを置き、要求事項ブロックでは機能要件、非機能要件、データ、成果物、予算、スケジュール、体制をまとめ、選定の進め方ブロックで提出要領、評価基準、契約条件を示します。
この順番は、提案側が読む順番とも自然に一致します。

この並べ方が効くのは、提案書を読むときの思考順序がそのまま反映されるからです。
最初に案件の背景をつかみ、次に実装条件と制約を確認し、最後に選定方法を見れば、どの論点を深掘りすべきかが見えます。
逆に、要求事項だけを細かく並べると、何のための開発かが見えず、提案の評価軸もぶれやすくなります。
章立ては単なる整理ではなく、比較可能性を作る設計です。

必須項目11点と記載粒度の早見表

必須項目は11点あります。
1.プロジェクト概要と背景、2.現状課題と業務KPI、3.スコープ、4.機能要件、5.非機能要件、6.提供データの条件、7.精度目標と評価方法、8.成果物と権利帰属、9.予算、10.スケジュールと体制、11.提案・選定要領です。
6〜8はAI固有の論点で、汎用的なシステム開発テンプレートでは抜けやすい部分になります。

この11点は、書く順番もそのまま重要度の順番に近いと考えてよいでしょう。
とくにAI案件では、精度目標と評価方法、提供データの条件、成果物と権利帰属が曖昧だと、提案の質よりも前提条件の差が結果を左右します。
提案を受ける側は、比較したい論点を先に定義しておくのが。

スコープは「やらないこと」を書く

スコープ欄は、「やること」より「やらないこと」を明記したほうが効きます。
既存システム改修、データ基盤構築、アノテーション作業、現場教育を含むのか、含まないのかを1行ずつ分けて書くと、見積もりの前提差が消えます。
実務では、この1行が抜けただけで各社の見積もりが数百万円単位でばらつき、同一条件での再見積もりを依頼し直すことがあります。
手戻りは、ここでかなり減らせます。

AI開発では、スコープの曖昧さがそのまま比較不能につながります。
たとえばアノテーション作業を発注側が持つのか、ベンダーに含めるのかで、必要工数も責任範囲も変わります。
だからこそ「対象外」を書くことが有効です。
対象業務と対象外業務を分けておくと、各社の提案が同じ土俵に乗ります。
書けるところから整理してみてください。

また、発注側で確定できない項目は空欄にせず、「提案を求める」と明記します。
手法、モデル構成、評価設計のように、ベンダーの知見を引き出したほうが良い部分は、むしろ提案に委ねたほうが選定しやすくなります。
この書き方をすると、ベンダーごとの技術的な考え方の違いが提案書に表れやすく、判断材料が増えます。
全項目を発注側で埋め切ったRFPは、どの社も似た提案になりやすいものです。
提案の差を見たいなら、あえて余白を残しましょう。

精度目標・学習データ・権利帰属をどう書くか

AI案件のRFPでは、精度を「保証」させるより、何をどう測るかを設計してもらう書き方のほうが通りやすいです。
学習データの出し方と権利の切り分けも先に示しておくと、提案の粒度がそろい、契約交渉の手戻りが減ります。
構想・PoCと実装工程で契約形態を分ける前提まで書いておくと、ベンダー側も見積りを組み立てやすくなるでしょう。

精度は「確約」でなく「評価設計」を求める

「適合率90%以上を保証すること」と書くより、「評価指標（適合率・再現率・F値等）と評価用データセットの合意方法、目標水準に届かない場合の打ち切り基準をPoC計画として提案すること」としたほうが、提案の質は上がりやすいです。
特定データでの水準確約を求めると、提案辞退か、安全側に倒した低い数値の提示につながりがちだからです。
実際、精度の確約を外し、評価指標と打ち切り基準の提案を求める形に変えた案件では、提案社数と具体度がともに上がる傾向が見られます。
発注側がリスクを一方的に押し付けていないことが伝わるからです。

評価指標は業務KPIと結び付けて書くと、ベンダーが根拠を持って提案しやすくなります。
見逃しが致命的な検査業務なら再現率、誤検知の再確認コストが高いなら適合率を重視する、といった形です。
どちらの誤りが業務上痛いのかを明示しておけば、指標の優先順位がぶれません。
構想・PoCは準委任で探索を重ね、要件が固まった実装工程は請負または成果完成型準委任に切り替える、という前提とも相性がよい考え方です。

学習データの提供条件と分担を明記する

学習データ欄には、提供時期・件数・形式・ラベルの有無・アノテーションの分担・社外持ち出し可否・秘密保持の条件まで書くのが実務的です。
ここを曖昧にすると、ベンダー側は前提を置いたまま見積りを出すしかなくなり、後で「そのデータはいつ渡されるのか」「誰がラベルを付けるのか」で止まりやすくなります。
データ提供の遅延はプロジェクト遅延の典型要因なので、提供責任が発注側にあることも明記しておくべきです。
RFPにそのまま書けるだけで、準備の抜け漏れはかなり減ります。

条件を書くときは、量だけでなく質も見せるのが。
たとえば件数だけがあっても、ラベル付きが何件で、現場で追加注釈が必要なのかが見えなければ、PoCの設計は固まりません。
秘密保持や社外持ち出し可否も、運用ルールとセットで示しましょう。
構想やPoCでは準委任が現実的ですが、その場合でも「どのデータを、誰が、いつまでに出すか」が曖昧だと、評価設計そのものが進まなくなります。

モデル・データ・ノウハウの権利を分けて書く

権利帰属は、学習済みモデル・生成物・学習用データセット・ノウハウの4つに分けて論点化したほうがです。
まとめて「成果物の権利は発注者に帰属」と書くと、ベンダーの汎用ノウハウまで縛る形になり、価格上昇や提案辞退の要因になります。
実務では、権利を一括で発注者帰属としたRFPに対し、ベンダーが汎用ノウハウの扱いを理由に条件交渉を持ち込み、契約締結が後ろ倒しになる展開がよくあります。
最初から4分類で書き分けておけば、提案段階で論点を処理できます。

あわせて、ベンダーが他社案件でモデルを再学習・転用できる範囲も、発注側の希望として先に示しましょう。
転用不可を広く求めるほど、条件は価格に反映されます。
たとえば競合他社への転用のみ制限するのか、同業他社への横展開まで止めるのかで、提案の幅は変わります。
構想・PoCは準委任、要件が固まった実装工程は請負または成果完成型準委任という切り分けと並べて書けば、各社の提案粒度がそろい、比較もしやすくなります。

予算とスケジュールをフェーズ別に示す

AI開発の予算は、構想、PoC、実装、運用で性質がまったく変わります。
総額だけを置くと、短期の検証費と長期の保守費が混ざり、見積もりの妥当性を検算しにくくなるからです。
まずは各フェーズを切り分け、期間と人月の前提まで含めてレンジで示しましょう。

4フェーズで費用の性質を分ける

構想フェーズは40〜200万円、PoCフェーズは100〜500万円、実装フェーズは500〜5,000万円、運用フェーズは月額50〜200万円の保守・再学習費が継続発生します。
ここでのポイントは、同じAI開発でも、構想は要件整理と仮説設計、PoCは検証、実装は本番化、運用は改善のための継続投資であり、費用の性質が別物だという点です。
総額一本で書くと、この違いが見えなくなります。

期間の目安もセットで考えると、PoCは1〜3ヶ月、本番化判断を経た実装は2〜12ヶ月が相場観です。
ラボ型で体制を組む本開発では月額100〜250万円×人月を基準にし、体制規模と期間から概算を検算すると、提案の過不足を見抜きやすくなります。
金額だけでなく、何人を何ヶ月置くのかまで並べるのが実務上の筋でしょう。

運用・再学習費を初年度から見込む

AIモデルは作って終わりではありません。
市場環境やユーザー行動が変われば、入力データも判断基準も古くなるため、定期的なデータ更新と再学習が必要になります。
だからこそ、運用フェーズの月額50〜200万円は、単なる保守費ではなく、計算リソースと技術者工数を含んだ継続前提の費用として扱うべきです。

PoC段階では全体予算の10〜15%しか使わないことが多く、手応えが出たあとに本番化へ進んだ結果、実装・運用コストが想定の3〜5倍に膨らむケースがあります。
PoC予算だけを確保して発注し、良好な結果が出たのに本番化の予算が通らず止まる案件は繰り返し起きます。
初年度予算に運用・再学習費を入れておけば、社内の期待値調整が先に済み、移行も進めやすくなります。

予算レンジを開示する判断

予算を完全非公開にすると、ベンダーは自社の標準構成で見積もるため、提案の粒度がばらつきます。
上限額を示すか、「初年度○百万円規模を想定」とレンジで伝えるだけでも、各社が同じ土俵で構成を出しやすくなり、比較可能な提案が集まりやすくなります。
非公開のまま提案を募ると、金額差が構成差なのか単価差なのか判別しにくく、再ヒアリングの工数が増えます。

RFP段階で本番化まで含む総投資レンジを書いておくと、PoC後に話が止まりにくくなります。
最初から総額の上振れ余地を共有しておけば、社内承認も取りやすく、ベンダー側もどこまで提案すべきかを読み違えません。
フェーズ別の予算開示は、単なる情報公開ではなく、見積もり崩壊を防ぐための設計そのものです。

評価基準と選定プロセスをRFPに明記する

RFPに評価基準と配点を先に書き込んでおくと、提案書が届いてから評価軸を作り直す手戻りを防げます。
とくにAI案件では、要求事項への対応度や価格だけでなく、MLOpsの実装経験や本番運用後の保守体制まで最初から点数化しておくことで、PoC止まりの提案と運用まで見据えた提案を同じ土俵で比べやすくなります。
評価者、評価方法、配点、提出要領、プレゼンの位置付けまでRFP段階で揃えておくことが、選定のぶれを減らす近道です。

評価6項目＋AI案件の追加2項目

評価の土台は、①要求事項への対応度、②プロジェクトの進め方・スケジュール・体制、③プレゼン時の対応（PM・メンバーのスキルと経験）、④見積価格、⑤ベンダーとしての実績と信頼性、⑥将来の拡張性の6項目です。
ここにAI案件では、MLOpsの実装経験と本番運用後の保守体制を加えるのが実務上は有効です。
PoCでは動いても、本番移行でレイテンシやスケーラビリティ、再学習頻度の設計が甘いと運用で詰まりやすいからです。
技術が優れている提案でも、保守の見通しが弱ければ採用後の負荷が増えます。

この8項目を最初から並べておくと、提案の「見栄え」に引っ張られにくくなります。
たとえばプレゼンが上手でも、体制が薄くてスケジュールが曖昧なら点は伸びませんし、逆に価格が安くても拡張性や実績が弱ければ長期運用では不安が残ります。
評価項目を増やす目的は、厳しくすることではなく、何を重視して選ぶのかを言語化することにあります。

配点は差がつく傾斜をつける

採点は項目ごとの5段階評価が一般的ですが、差がつきにくい案件では〇=5点・△=1点・×=0点のような傾斜をつけると順位が明確になります。
全社が横並びで似た点数になる配点では、最終的に何を根拠に選んだのかを説明しづらくなります。
配点の狙いは、僅差を無理に均すことではなく、判断材料に優先順位を与えることです。

実際には、提案を受けてから評価軸を作り始めた案件ほど、各社が異なる前提で書いた提案書を横並びにできず、最後は価格と担当者の印象で決まりがちです。
RFP作成時点で配点表を用意していた案件は、どの項目で差がついたかを数値で示せるため、稟議の説明が通しやすくなります。
評価者の主観を消すことはできませんが、主観が入り込む場所を限定することはできます。

選定プロセスは6ステップで進めます。
評価者の決定、評価方法の決定、評価項目の決定、配点の決定、提案の点数化、評価結果の比較です。
評価者を先に決めないと、点数化の段階で観点が食い違い、調整に時間を取られます。
先に誰が何をどう見るかを固めるだけで、後工程の摩擦はかなり減ります。

評価基準を事前開示する効果

評価項目と配点はRFP作成時点で策定し、そのまま明記して事前開示します。
開示すると、ベンダーは重視軸に沿って提案を組み立てるため、発注側が知りたい論点が揃いやすくなります。
開示しない場合は、各社の得意分野の話が前面に出やすく、比較したい軸の情報が抜けた提案になりがちです。
土俵をそろえる効果は、比較のしやすさだけではありません。

提出要領に、提案書の様式、ページ数上限、質疑応答の期限と方法、提出期限、プレゼンの有無と時間を書いておくと、評価の前提がぶれません。
様式を指定すると比較はしやすくなりますが、細かく縛りすぎると各社の強みが見えなくなるため、必須記載項目だけを指定する運用が現実的です。
デモやプレゼンは、資料だけでは見えないPMの受け答えやメンバーの理解度を確かめる場として位置づけると、評価6項目に自然につながります。

AI開発RFPでよくある失敗と回避策

AI開発RFPで失敗が起きやすいのは、要件定義不足、PoC止まり、データ権利の曖昧さという3類型にほぼ集約できます。
どれも契約後に詰めるほど修正コストが高く、RFPの段階でどこまで言語化できるかが成否を分けます。
なかでも多いのは、精度だけを先に求めてしまい、業務KPIや本番化の条件が空欄のまま進むケースでしょう。

要件定義不足とPoC止まり

要件定義不足の失敗は、業務KPIと評価指標が未定のまま発注してしまうところから始まります。
AI開発では、モデルの精度が高くても、誰の業務がどれだけ短縮されるのか、誤判定をどこまで許容するのかが決まっていなければ、提案の良し悪しを判断できません。
RFPの冒頭に課題と成功指標を置き、確定できない技術要件は「提案を求める」と書き分けると、発注側の期待値が揃いやすくなります。
全項目を埋めることが目的ではなく、判断軸を先に定めることが要点です。

PoC止まりも、AI案件で最も頻繁に観察される失敗パターンです。
PoC単体で発注すると、良い結果が出ても本番化の判断基準が事前に定義されていないため、社内で結論が出ず、そのままモデルが使われないまま終わります。
本番化の判断基準として、業務KPIへの寄与、目標精度、投資回収の見通しをRFPに明記し、PoC後の実装フェーズの概算見積もりも併せて提案することを書いておくと、ベンダー側も最初から本番前提で設計できます。

データ権利の曖昧さが招く手戻り

データ権利の曖昧さは、学習用データセットと学習済みモデルの権利を分けずに書くことで起きます。
実務では、どこまでが発注側の資産で、どこからがベンダーの知見なのかが曖昧だと、納品後に再学習や転用の可否で揉めやすいのです。
RFPでは、モデル、生成物、データセット、ノウハウの4分類を先に置き、さらにベンダーの再学習・転用範囲を論点化しておくと、契約書の文言調整が後回しになりません。
ここを曖昧にしたまま進めると、技術より先に権利関係の調整で止まります。

精度の一括請負要求による提案辞退も見落としやすい失敗です。
実務上は、成果物の性能を単独の数値だけで約束させるより、入力データの準備条件や評価方法を含めて設計したほうが、提案の質が上がります。
ベンダーからの質疑が特定の項目に集中する場合、その項目の記載が曖昧であることが多く、逆に言えば改善の余地がはっきり見えています。
質疑内容をRFPのテンプレートに反映していく運用を続けた組織は、回を重ねるごとに提案の質が上がる傾向があります。

RFP段階で予防できることの整理

外注が成功する条件は、定量的な成功指標の事前合意、データ準備の並行進行、本番運用を見据えた設計の3点です。
この3点はいずれもRFPの記載項目に落とし込めるため、RFPの品質がプロジェクトの成否をほぼ決めると言ってよいでしょう。
つまり、失敗の多くは技術力不足ではなく、発注前の設計不足として現れます。
だからこそ、課題、評価指標、データ、運用の順に書き分けていきましょう。

RFPは一度書いて終わりではありません。
質疑応答でベンダーから出た質問は、自社の説明不足を示す指標であり、次回のRFPに反映するほど発注ノウハウとして蓄積されます。
精度を求めるなら、まず比較可能な物差しを作ることです。
そうしておけば、PoCで止めず、本番までつなぐための会話がしやすくなります。