RFP（提案依頼書）は、ベンダーに「何を解決したいか・どう評価して選ぶか」を伝える文書です。AI案件のRFPは、普通のシステム開発のRFPをそのまま流用するとうまくいきません。仕上がりが事前に読みにくく、ベンダーごとに実力差が大きく、料金や精度が「やってみないと分からない」要素を多く含むからです。本稿は、初めてAI導入のRFPを書く人が、曖昧さを残さず・公平に比較でき・後で揉めない依頼書を作るための実務ガイドです。
FIG.1 曖昧なRFPは曖昧な提案を呼ぶ。入口の明確さが結果の質を決める
01AI案件のRFPは普通のRFPと何が違うか
通常のシステム開発は、要件が固まれば成果物がほぼ確定します。AI案件はそうはいきません。精度は実データを入れてみるまで読めず、同じ課題でもアプローチ（既製AIの利用／検索拡張／追加学習）でコストも品質も大きく変わります。だからRFPでは「手段」を縛りすぎず、「解きたい課題と合格条件」を厳密に書くのがコツです。
| 通常のシステムRFP | AI案件のRFP |
|---|---|
| 要件が固まれば成果が確定 | 精度は実データ検証まで不確実 |
| 機能の有無で評価しやすい | 「どの指標で何%」を定義しないと比較できない |
| 固定価格になじみやすい | PoC→本契約の段階契約が向くことが多い |
| 納品で完了に近い | 運用後の精度劣化・モデル更新まで見る |
回答期間も違います。複雑なAI案件で「2週間で提案を」は短すぎます。アーキテクチャや検証計画まで書いてもらうなら、3〜4週間を確保するのが現実的です。提案の分量も、ページ数の目安（例：15〜25ページ）を示すと比較しやすくなります。
02RFPに必ず入れる7項目
まずは案件の種類を問わず必要な土台です。AIに限らず、この7つが抜けると提案がばらつきます。
背景と目的
なぜやるのか、解きたい課題は何か。「AIを導入する」ではなく「問い合わせ一次対応の工数を減らす」のように、手段でなく目的で書く。
スコープ
対象業務と対象外を明記。曖昧だと後から「これも込みのはず」と揉める。
要件
機能要件と非機能要件（精度・応答速度・可用性・セキュリティ）。AIでは非機能、特に精度の定義が要。
データ条件
提供できるデータ、学習・追加学習への利用可否、保管場所と消去条件。後述するように最重要項目の一つ。
評価基準と配点
価格・精度・体制・実績の重みを事前に公開する。何を重視するか伝えると、的を射た提案が集まる。
体制とスケジュール
マイルストーン、役割分担、そして「実際に誰が担当するか」。AIは個人の力量差が大きい。
契約条件
知的財産（出力物の権利）・解約・SLA・責任範囲。雛形任せにせず自社で確認する。
03評価基準は「先に・数値で・公開して」
RFPで最も差が出るのが評価基準の書き方です。原則は三つ。提案を募る前に決める／測れる形にする／ベンダーに公開する。配点を伏せると、ベンダーは何が重要か分からず無関係な情報で水増しした提案を出し、比較が難しくなります。配点を見せれば、各社があなたの重視点に正面から答えてくれます。
評価基準を隠すと、提案は「比較できないカタログ」の山になる。先に見せるほど、答えは鋭くなる。
FIG.2 重み付きスコアシートを先に共有し、全社を同じ軸で採点する
採点は関係者を早めに巻き込んで合意しておきます。現場・情シス・法務・調達が後出しで重みを変えると、選定の公平性が崩れます。配点の表は提案受領「前」に固めるのが鉄則です。
04AI案件で必ず追記する確認項目
ここからがAIならではの肝です。次の項目を書き落とすと、後から費用や責任で必ず揉めます。
精度は「指標・データ・合格ライン」で定義する
「高精度」という言葉はRFPに書いてはいけません。比較も検収もできないからです。代わりに、どの指標（正解率・適合率・再現率など）で・どの評価データに対して・何%を合格とするかを明記します。評価用のデータセット（自社の実例に近いQ&Aや判定例）を誰が用意するかも決めておきます。
注意したいのは、ベンダーのデモ環境での好成績ではなく、あなたの環境・あなたのデータで動かしたときの精度を尋ねること。そのために次のPoC条項が効きます。
PoC（小さく試す）を本契約の前に挟む
AIは実データを入れてみないと本当の精度が読めません。本契約の前に、自社データで一定期間検証するPoC（概念実証）条項を入れ、「合格ラインに届いたら本契約に進む／届かなければ撤退できる」段階契約にしておくと、不確実性を費用で抱え込まずに済みます。
FIG.3 PoCの合格判定をゲートにし、不確実性を本契約前で見極める
データの取り扱いと学習利用の可否
近年のAIベンダー契約で特に重視されるのが、自社のデータや入力（プロンプト）をベンダーがモデルの学習・追加学習に使わないことを明文化する点です。原則は「書面の同意なしに学習・転用しない」。あわせて、データの保管場所・暗号化・保持期間・契約終了時の削除、第三者（再委託先や基盤モデル提供元）へどう渡るかも書面で確認します。AIの利用そのものを事前開示させる条項を入れる企業も増えています。
モデル更新と追従の費用
裏側の基盤モデルは頻繁に更新・置き換えが起きます。更新でアプリの挙動が変わる可能性があるため、モデル変更時の再検証・追従作業と、その費用を誰が負担するかを取り決めておきます。「更新したら勝手に精度が落ちていた」を防ぐ条項です。
ハルシネーション（誤出力）と責任分界点
AIは事実でないことをもっともらしく出力することがあります。RFP・契約では、誤出力が起きたときの責任の線引きを決めます。実務では「合意した精度ライン（例：正解率◯%）を下回った分はベンダー側の責任、上回る範囲のばらつきは運用上の変動として扱う」といった、精度しきい値に紐づく分担が用いられます。同時に、重要な判断には人間の確認（ヒューマン・イン・ザ・ループ）を必須にし、出力をそのまま自動実行しない運用を前提に書きます。
出力物の権利（IP）
AIが生成した成果物の権利は、契約次第でベンダー側に広く残ることがあります。自社が成果物を所有する／自由に利用・改変・他社移管できるライセンスを得るのか、RFP段階で明示しておきます。
Compliance & Templates
規制と公開テンプレートを「ゼロから書かない」
AIの契約条項は、もはや手書きで一から起こすものではありません。たとえばEUは2025年3月に、公共機関向けのAI調達モデル契約条項（MCC-AI）の改訂版を公開しています。リスクの高い用途向けの「フル版」と、それ以外向けの「ライト版」があり、透明性・リスク管理・データガバナンス・人間による監督・セキュリティなどの供給者義務を雛形として提供します。自社がEU域でなくても、抜け漏れのチェックリストとして極めて有用です。
FIG.4 ゼロから書かず、公開モデル条項を土台に自社事情で補正する
規制動向も追っておきます。米国でも州レベルでAIの透明性・データ保護の法整備が進んでおり、対象によっては契約上の要求事項が課されます。自社の業種・地域に効く規制を法務と確認し、RFPの「契約条件」へ反映してください。
05運用後まで見据えた要求を書く
AIは「納品して終わり」ではありません。RFPの段階で、運用フェーズの監視を要求しておきます。ベンダーには、デプロイ後に精度の劣化（ドリフト）・応答速度・エラー率をどう計測し、しきい値を割ったらどう対応するかを提案させます。あわせて、誰が何を聞き何が返ったかのログ基盤も要件に入れます。
精度ドリフト
本番データの傾向変化で精度が下がっていないか。定点で再評価する仕組みを要求。
速度・エラー率
応答時間と失敗率を継続監視。閾値超過時の通知と対応手順を提案させる。
監査ログ
入力・検索・出力・コストを記録。問題発生時の追跡と改善の材料にする。
06避けたい3つの失敗
- 技術を指定しすぎる：「◯◯モデルを微調整した構成で」と書くと、専門家であるベンダーがより良い設計を提案できなくなる。手段ではなく課題と合格条件で書く。
- 「高精度」など測れない言葉：指標・評価データ・合格ラインに置き換える。
- 料金・リスクの断定：プランや単価は頻繁に変わる。RFPでは固定額を前提にせず、段階契約と「公式の最新条件を確認」を前提に書く。
07AIを使ってRFPの下書きを作る
RFP自体の作成をAIに手伝わせるのも有効です。たたき台を作らせ、人間が自社事情で補正するのが最速です。ただし固有名詞・機密はマスキングしてから渡すこと、そして出力はそのまま使わず必ず人間がレビューすることが前提です。
業務［◯◯］をAIで効率化するためのRFP草案を作ってください。評価基準は精度・コスト・運用体制・セキュリティを重視し、配点案も付けてください。AI案件特有の確認項目（精度の指標と合格ライン、PoC条項、自社データの学習利用可否、モデル更新時の費用負担、誤出力の責任分界点、出力物の権利、運用後の監視）を必ず章立てに含めてください。
生成された草案は出発点にすぎません。スコープと合格ラインは自社の実情に合わせて書き換え、契約条件は法務に確認したうえで確定させましょう。良いRFPは、解きたい課題を明確にし、測れる合格条件を示し、AI特有のリスクを先回りで線引きする——この3点に尽きます。
