AI 開発の RFP(提案依頼書)の書き方|発注者向けテンプレート付き

結論: RFP の精度が、提案と見積もりの精度を決める

AI 開発を外部に発注するとき、最初に頭を悩ませるのが「どう声をかければ、まともな提案と見積もりが返ってくるのか」という点です。結論から言えば、返ってくる提案の質は RFP(提案依頼書)の質でほぼ決まります。曖昧な依頼には曖昧な提案しか返ってこず、各社の見積もりがバラバラで比較できない、という事態は RFP の作り込み不足から生まれます。

これは AI 案件でも変わりません。むしろ AI 開発は「精度はどこまで出るのか」「データは誰が用意するのか」「モデルが古くなったら誰が面倒を見るのか」といった、従来のシステム開発にはなかった論点が増えるため、RFP で前提を揃えておく価値が一段と大きくなります。前提が揃っていなければ、ある会社は高精度なモデルを前提に高い見積もりを出し、別の会社は割り切った仕組みで安く出す、という比較不能な状況に陥ります。

この記事では、発注者が良い提案を引き出すための RFP の書き方を、AI 駆動開発を前提に整理します。盛り込むべき必須項目、AI 案件特有の記載ポイント、そのまま使えるテンプレート、提案を比較するスコアリングの作り方まで一通り扱います。最後に「そもそも RFP を書かずに相談から始める」という選択肢にも触れます。

RFP(提案依頼書)とは何か — RFI・要件定義書との違い

RFP は Request for Proposal の略で、日本語では提案依頼書と呼びます。発注者が「こういう課題があり、こういうものを作りたい。提案と見積もりをください」と開発の委託先候補へ投げかける文書です。提案を依頼する文書なので、解決策そのものを発注者が書ききる必要はなく、目的・制約・評価基準を示して、解き方は提案側に委ねる のが基本的な性格です。

似た文書と混同されやすいので、役割の違いを整理しておきます。

ざっくり言えば、RFI で「この会社は相談できそうか」を見極め、RFP で「では具体的にどう作り、いくらかかるか」を提案してもらい、発注後に要件定義書で「実際に何を作るか」を確定していく、という流れです。

ここで誤解されやすいのが、RFP と要件定義書の関係です。RFP の段階で仕様を細部まで書ききろうとする発注者は少なくありませんが、それは要件定義書の役割であって RFP の役割ではありません。とくに AI 駆動開発では、作りながら仕様を詰めていく進め方が前提になるため、RFP で機能の隅々まで確定させようとすると、かえって柔軟な提案を潰してしまいます。RFP では「達成したい状態」と「守ってほしい制約」を明確にし、具体的な作り方の確定は要件定義フェーズに送る、という割り切りが有効です。

RFP に盛り込むべき必須項目

提案を横並びで比較できる RFP にするには、最低限そろえておきたい項目があります。順番に見ていきます。

1. 背景と目的(なぜ作るのか)

最初に、なぜこのプロジェクトをやるのかを書きます。事業上の課題、現状の困りごと、解決したらどうなってほしいのか。ここが曖昧だと、提案側は機能の要望リストを満たすだけの「言われたものを作る」提案しか出せません。目的が明確であれば、目的に対してより良い手段を逆提案してくれる会社が見えてきます。AI 案件では「業務時間を減らしたい」「問い合わせ対応を自動化したい」といった目的が、本当に AI で解くべきかどうかの判断材料にもなります。

2. スコープ(どこまで作るのか)

作る範囲と、作らない範囲の両方を書きます。「作らない範囲」を明記することが意外と重要で、これがないと提案側が範囲を広めに見積もって金額が膨らんだり、逆に狭く解釈して必要な機能が抜け落ちたりします。対象とする業務、対象ユーザー、対応プラットフォーム(Web のみか、スマホアプリも含むか)、連携が必要な既存システムの有無を具体的に書きます。

3. 予算と支払いの考え方

予算は、可能な範囲で示します。一円単位で決める必要はなく、上限の目安やフェーズごとの区切りで構いません。予算を伏せたまま配ると各社の前提がバラバラになり、比較が成立しません。フェーズ分割(まず要件定義、結果を見て本開発を判断)を前提にするなら、その旨も書いておくと提案の精度が上がります。費用と期間の相場観については AI 駆動開発の費用・期間はいくら?料金相場と見積もりの内訳 に規模別の早見表があるので、予算の目安を決める際の参考になります。

4. スケジュールとマイルストーン

希望する納期と、その理由(法改正への対応、展示会での発表、競合への対抗など)を書きます。理由まで書くと、提案側が「ここは間に合わせるべき」「ここは後回しでよい」と優先順位をつけた提案を返しやすくなります。中間で確認したいマイルストーンがあれば、それも添えます。

5. 評価基準(どう選ぶか)

提案をどんな観点で評価するのかを、配点とともに開示します。価格だけで選ぶのか、技術力や体制も見るのか。評価基準を事前に示すと、提案側はそこに沿って訴求してくれるため、比較がしやすくなります。スコアリングの作り方は後の章で詳しく扱います。

6. 提案してほしい内容と提出形式

提案書に何を含めてほしいか(体制図、見積もり内訳、開発の進め方、想定リスク、過去の類似実績)を箇条書きで指定します。提出期限、提出形式、質問の受付方法、選定スケジュールもここに書きます。会社選びそのものの判断軸については AI 受託開発の会社を選ぶときの 5 つのチェックポイント に発注者目線のチェック項目をまとめています。

AI 案件特有の記載ポイント

ここまでは一般的なシステム開発の RFP にも共通する項目でした。AI を含む開発では、これに加えて押さえておきたい論点があります。ここを書いておくかどうかで、提案の現実味が大きく変わります。

成功指標(精度ではなく業務の成果で定義する)

AI 案件で最もずれやすいのが「どうなったら成功か」の定義です。「精度 95% を目指す」といった指標を単独で置くと、何の精度なのか、その値で業務が回るのかが曖昧なまま進みます。おすすめは、業務の成果で成功を定義する ことです。たとえば「問い合わせの一次対応の 7 割を自動化し、人手の対応時間を従来の半分にする」といった形です。そのうえで、技術的な指標(分類の正解率、検索の再現率など)は補助指標として置きます。業務の成果で語ると、AI で解くべきか、ルールベースで十分かの判断も提案側がしやすくなります。

データ(誰が、何を、どこまで用意するか)

AI 開発はデータがなければ始まりません。RFP には、学習や検証に使えるデータが現時点でどれだけあるのか、品質はどうか(整っているのか、手作業の整備が必要か)、個人情報や機密情報が含まれるか、データの持ち出しは可能かを書きます。「データは社内にあるが整っていない」「これから集める必要がある」といった実態を正直に書くことが大切です。データ整備にかかる工数は AI 案件の費用を大きく左右する変数なので、ここを曖昧にすると見積もりが現実と乖離します。

モデル方針(API 利用か、自前構築か)

AI の中身をどう実現するかには方針の幅があります。外部の生成 AI を API として利用するのか、オープンソースのモデルを自社環境で動かすのか、独自にモデルを構築・学習するのか。それぞれコストも運用負荷も大きく異なります。発注者がここを決めきれないことは多いので、無理に指定する必要はありません。むしろ「方針の選択肢とそれぞれの利点・欠点を提案に含めてほしい」と書くほうが、各社の知見を引き出せます。あわせて、外部 API を使う場合の従量課金がランニングコストに乗る点も論点として挙げておくと、運用費の見積もりが揃います。

運用範囲(作った後、誰が面倒を見るか)

AI を含むシステムは、作って終わりにはなりません。モデルの精度は時間とともに劣化することがあり、外部 API のバージョンが変われば挙動も変わります。RFP には、運用フェーズで誰が何を担うのか(監視、再学習、精度の継続評価、外部サービスの変更追従)、保守の体制と費用を含めて提案してほしいことを書きます。ハルシネーション(もっともらしい誤りの出力)への対処や、誤った出力が業務に与える影響をどう抑えるかも、運用設計の一部として提案に含めてもらうとよいでしょう。

契約形態の希望

AI 案件は仕様を作りながら詰める進め方が多いため、成果物を固定して請け負う請負契約より、工数に応じて支払う準委任契約が向く局面が多くあります。一方で、仕様が確定した部分は請負で固定したい場合もあります。RFP に希望する契約形態を書いておくと、提案の前提が揃います。契約形態の選び方は AI 開発は準委任契約と請負契約のどちらが向くか で、フェーズごとの使い分けを整理しています。

そのまま使える RFP テンプレート(章立てと記入例)

ここまでの内容を、実際の章立てに落とし込んだテンプレートを示します。コピーして見出しを残し、各項目に自社の情報を埋めていけば、AI 案件の RFP として成立します。記入例は架空の社内ナレッジ検索ツールを題材にしています。

1. プロジェクト概要
   - プロジェクト名: 社内ナレッジ検索ツールの開発
   - 発注者: 株式会社○○(従業員 約 200 名・製造業)
   - 提出期限: 20XX 年 X 月 X 日
   - 選定スケジュール: 一次選考(書類)→ 二次選考(面談)→ 決定
 
2. 背景と目的
   - 背景: 社内ドキュメントが複数システムに散在し、必要な情報を探すのに時間がかかっている
   - 目的: 自然文の質問で社内ドキュメントを横断検索し、調べ物にかかる時間を半減させる
 
3. スコープ
   - 対象: 社内マニュアル・議事録・規程(約 3 万件)の検索
   - 対象外: 外部公開用 FAQ、ドキュメントの作成・編集機能
   - 対象ユーザー: 社内従業員(Web ブラウザ利用、約 200 名)
   - 既存システム連携: 社内ストレージからの定期取り込みが必要
 
4. 成功指標
   - 業務指標: 調べ物にかかる平均時間を従来の 50% に削減
   - 補助指標: 検索結果の上位に正解が含まれる割合(社内評価データで測定)
 
5. データ
   - 保有データ: 社内ドキュメント約 3 万件(形式はばらつきあり、整備未了)
   - 機密区分: 一部に人事・機密情報を含む。社外持ち出し不可
   - 整備の想定: テキスト抽出と前処理が必要(範囲は提案に含めてほしい)
 
6. モデル・実現方針
   - 方針: 未定。API 利用 / 自社環境での構築の選択肢と利点・欠点を提案に含めてほしい
   - 制約: 機密データを外部に送信できない場合の構成も検討してほしい
 
7. 運用範囲
   - 想定する運用: ドキュメントの定期取り込み、精度の継続評価、外部サービスの変更追従
   - 保守体制と月額費用を含めて提案してほしい
 
8. 予算
   - 概算上限: ○○○ 万円(税抜)を想定
   - フェーズ分割: 要件定義 → 本開発の二段階を希望
 
9. スケジュール
   - 希望納期: 初回リリースを ○ か月以内
   - 理由: 下期の業務改善施策に間に合わせたい
 
10. 契約形態
   - 希望: 要件定義は準委任、本開発は工程に応じて協議
 
11. 提案してほしい内容
   - 体制図 / 開発の進め方 / 見積もり内訳 / 想定リスクと対策 / 類似実績
 
12. 評価基準
   - 価格 30 / 技術と実現性 30 / 体制と進め方 20 / AI 運用の現実味 20
 
13. 連絡・質問
   - 質問受付期限と窓口、NDA の要否

このテンプレートのまま全社に配ると、提案が同じ章立てで返ってくるため、横並びで比較しやすくなります。AI 案件らしさは 4〜7 章(成功指標・データ・モデル方針・運用範囲)に凝縮されています。ここを空欄のまま配らないことが、現実的な見積もりを引き出すコツです。

提案を比較評価するスコアリングの作り方

複数社から提案が返ってきたら、印象ではなく基準で比較します。RFP に書いた評価基準を、そのまま採点表に落とし込みます。

評価軸は、価格・技術と実現性・体制と進め方・AI 運用の現実味の 4 つを基本に置くとバランスが取れます。それぞれに配点を決め、提案ごとに点をつけて合算します。配点は案件の性格で変えてかまいませんが、AI 案件では「AI 運用の現実味」を独立した軸として置くことをおすすめします。動くものを作る提案は出せても、運用フェーズの設計まで踏み込んでいる提案は意外と少ないからです。

採点で気をつけたいのは、価格の安さに引きずられないことです。極端に安い見積もりは、スコープを狭く解釈しているか、運用やデータ整備の工数を見込んでいない可能性があります。前提条件が箇条書きで明記されているか、何が含まれて何が含まれないかが読み取れるかを、価格の点数とは別に確認します。「一式」とだけ書かれた見積もりは、後から増えても根拠を検証できないため評価を下げる対象です。

面談では、提案書に書かれた成功指標を「どうやって達成するのか」「達成できなかったらどう軌道修正するのか」と具体的に聞きます。AI 案件では精度が事前に保証できないことも多く、達成できなかったときの進め方まで考えている会社のほうが、結果的に信頼できます。

RFP を書かずに、相談から始める選択肢

ここまで RFP の書き方を詳しく説明してきましたが、すべての発注に RFP が必要なわけではありません。むしろ AI 駆動開発では、要件が固まりきっていない段階で発注を検討することが多く、その場合は RFP を書く前に相談(壁打ち)から始める ほうが結果的に早いこともあります。

壁打ちとは、課題と打ち手を一緒に整理しながら、何を作るべきかを言語化していく場のことです。「業務を効率化したいが何から手をつければよいか分からない」「AI で解けるのか、そもそも AI を使うべきなのか判断がつかない」といった段階では、RFP を無理に書こうとすると、未定の部分を憶測で埋めてしまい、その憶測に提案が引きずられてしまいます。

相談から始める進め方では、まず目的と制約だけを共有し、AI で解くべき課題か、どこから着手するのが投資対効果が高いかを一緒に整理します。そのうえで、要件定義や PoC(技術検証)だけを小さく切り出して始め、手応えを見てから本開発の規模を判断します。短いサイクルで作って確かめる進め方は AI 駆動開発と相性が良く、初期予算を抑えながら、的外れな機能に投資してしまうリスクを下げられます。

RFP は、要件と評価軸がある程度固まっていて、複数社を横並びで比較したいときに最も力を発揮します。逆に、何を作るかがまだ見えていない段階なら、信頼できる一社と相談から始め、整理が進んだ段階で改めて RFP を書く、という順序も十分に現実的です。

まとめ

AI 開発の RFP は、目的・スコープ・予算・スケジュール・評価基準という必須項目に加えて、成功指標・データ・モデル方針・運用範囲という AI 案件特有の論点を書き込むことで、現実的な提案と比較可能な見積もりを引き出せます。仕様を細部まで固めるのは要件定義フェーズの役割と割り切り、RFP では「達成したい状態」と「守ってほしい制約」を明確にするのが、良い提案への近道です。提案は印象ではなくスコアリングで比較し、価格の安さに引きずられず前提条件まで読み込むことが、後悔しない発注につながります。そして、要件がまだ固まっていないなら、RFP を書く前に相談から始める選択肢も忘れないでください。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、RFP の作成段階からの壁打ちや、要件の整理を無料でご相談いただけます。何を作るべきか迷っている段階でも構いません。お問い合わせ からお気軽にご連絡ください。