丸投げ禁止！AI導入RFP（提案依頼書）の書き方と必須項目

2026-08-14

AI導入をベンダー任せにしたまま進めていいのか不安がある
要件をきちんと詰めないまま商談が進み、完成後に「思っていたものと違う」と言われそうで怖い
複数社から提案をもらっても、何を基準に比較すればいいかわからない
見積もりの妥当性を判断できないまま、言われた金額で契約してしまいそう

こうした不安を放置したまま契約に進むと、完成後の手戻りや想定外の追加費用だけでなく、ベンダーへの依存が深まり、次のシステム更新でも自社が主導権を握れなくなりかねません。この記事では、AI導入における提案依頼書（RFP）の役割と、丸投げにしないための必須記載項目をまとめました。

読み終える頃には、自社の要件をRFPとして言語化し、ベンダーの提案を対等な立場で比較検討できるようになります。発注側が要件定義の主導権を握ることが、質の高い提案を引き出す一番の近道です。

「丸投げ」が招く落とし穴とは？発注側が要件定義を放棄するとどうなるか

AI導入をベンダーに丸投げすると、同じような失敗パターンが繰り返し指摘されています。発注側が要件定義を放棄すると、主導権も一緒に手放すことになるためです。導入を急ぐあまり、要件を詰める作業を後回しにしてしまう担当者も少なくありません。

まず起きやすいのが期待値のズレです。要件を詰めないままベンダーに任せると、相手は独自の解釈で仕様を決めてしまいます。完成後に「思っていたものと違う」という不一致が生じやすくなります。

評価基準の不在も見過ごせない問題です。何をもって良い提案とするかが決まっていないと、提案の比較は主観頼みになります。選定後の成果物についても、合否の判断基準がないまま進んでしまいます。

さらに、スコープが曖昧なままだと解釈の違いが生まれ、後から追加費用を請求されるケースも指摘されています。仕様・データ・運用ノウハウがベンダー側に偏れば、乗り換えコストが高くなるベンダーロックインのリスクも高まります。

要件定義の段階から自社が関与しないと、AI活用の知見が社内に残らないまま契約が終わってしまう失敗パターンも、複数の専門サイトで共通して紹介されています。

自社の業務フローへの理解が浅いまま外部に要件定義を丸投げすると、完成後に「この機能が足りない」「現場の運用と合っていない」と判明するケースも紹介されています。業務を最もよく知るのは発注側の自社であり、その理解を提案に反映させる責任もまた発注側にあります。

こうした落とし穴を避けるカギは、発注側が要件定義の主導権を握ることです。次章からは、RFP（提案依頼書）という具体的な手段を解説していきます。

そもそもRFP（提案依頼書）とは何か

RFP（Request For Proposal、提案依頼書）とは、発注側が抱える課題や要求をベンダーに明確に伝え、最適な解決策の提案と見積もりを引き出すための文書です。目的・スコープ・予算・スケジュール・評価基準を示す一方、実現方法そのものはベンダー側の創意工夫に委ねる点が特徴です。

口頭の相談だけで発注先を決めるより、書面で要求を揃えるほうが、複数社の提案を公平に比較できます。

似た文書との違いを整理すると、位置づけの理解が深まります。

RFI（Request For Information、情報提供依頼書）は、どこから手をつければよいか分からない段階で、製品やサービスの情報を幅広く集める目的で使う文書です。RFP作成前の市場調査フェーズで用いられることが多くなります。

RFQ（Request For Quotation、見積依頼書）は、仕様がほぼ固まっている場合に価格の見積もりだけを求める文書です。要件定義書は、RFPでベンダーを選定した後、選定ベンダーと共同で詳細化していく設計文書という位置づけになります。

つまりRFPは「選定前」、要件定義書は「選定後」の文書という違いがあります。一般的な流れとしては、必要に応じてRFIで情報収集を行い、RFPを発出し、提案を受領・評価してベンダーを選定した後、契約を経て詳細な要件定義へ進むという順序が基本です。

すべての段階を必ず踏む必要はありません。一方、複数社を同じ条件で比較したい案件では、簡易版でもRFPを用意すると要求をそろえやすくなります。名称は難しく見えても、中身は自社の要求を整理した文書です。

通常のIT・システム開発RFPと「AI導入RFP」は何が違うのか

通常のシステム開発RFPは、機能要件・非機能要件・予算・スケジュール・評価基準を中心に構成されます。AI導入RFPでは、これに加えてAI特有の論点を明記する必要があるという指摘が、複数の専門サイトで共通して見られます。

理由は、AIを含むシステムでは、導入後の監視や見直しが重要になる場合があるためです。性能の変化や想定外の出力に備え、監視方法、人が介入する条件、必要に応じた更新・再学習の判断方法を検討します。要求すべき水準やチェックすべき項目も、案件の用途とリスクに合わせて設計します。

具体的に確認すべき論点は、次のようなものです。

学習データの扱いとして、保有データの形式・量・機密区分・整備状況を明記します。データ整備の工数は見積もりの費用に大きく影響するとされています
精度目標・評価基準として、正答率などの技術指標だけでなく、業務時間の削減といった業務成果指標もあわせて定義することが望ましいとされています
ハルシネーション対策として、誤出力が業務に与える影響を抑える運用設計を提案に含めてもらいます
継続監視・更新・再学習の要否として、誰が性能を監視し、どの条件で改善や更新を行うかを運用体制に含めます
モデル方針として、既存のAPI（ChatGPTなど）を利用するか、自前でモデルを構築するかの選択肢を提案に含めてもらいます。API利用の場合は、従量課金が運用コストに乗る点も見積もりに含めてもらう必要があります
人間の関与とKill Switch（緊急停止の仕組み）として、AIエージェントを使う場合はどの判断ステップで人間の承認を必須にするか、異常時に即座に停止できる仕組みがあるかを確認します
契約形態として、仕事の完成を目的とする請負契約か、委任事務の遂行を目的とする準委任契約かといった選択肢を検討します。名称だけで決めず、求める成果の内容・水準、検収、責任分担を契約で明確にすることが重要です

こうした論点を最初からRFPに盛り込んでおけば、ベンダー側も的確な提案を作りやすくなります。特にモデル方針や人間の関与のあり方は、通常のシステム開発ではあまり問われない、AI導入RFPならではの確認項目です。次章では、AI特有の論点を踏まえた必須項目を具体的に紹介します。

AI導入RFPに書くべき必須項目一覧

AI導入RFPには、ここまで触れてきたAI特有の論点も含め、記載すべき項目が数多くあります。ここでは代表的な12項目を、内容ごとに5つのグループへ整理しました。まずは、配下に挙げた項目群を確認してください。

プロジェクトの背景・目的を伝える項目（背景・現状課題／目的・ゴール）
スコープと規模を伝える項目（対象業務範囲・スコープ／想定ユーザー数・利用規模）
機能・性能に関する項目（必須機能要件／精度・性能要件）
AI特有のデータ・セキュリティ・連携に関する項目（データの取り扱い／セキュリティ要件／既存システムとの連携）
予算・選定・契約に関する項目（予算感・予算上限／選定スケジュール・評価基準／契約条件・保守運用体制）

プロジェクトの背景・目的を伝える項目（背景・現状課題／目的・ゴール）

RFPの冒頭には、背景・現状課題と目的・ゴールを明記します。ベンダーが提案の前提を正しく理解するための土台になるためです。

背景・現状課題では、なぜこのプロジェクトが必要か、現状のどんな業務課題を解決したいかを記載します。数値や具体的なエピソードを添えると、ベンダーが課題を実感しやすくなるはずです。目的・ゴールでは、業務時間の削減や精度向上など、AI導入で達成したいことを明確にします。

技術指標ではなく業務成果ベースで目的を書くと、ベンダーの提案の方向性がぶれにくくなります。背景・目的の2項目が曖昧なまま進むと、後続のすべての項目も的外れになりやすい点に注意してください。逆に、この2項目さえしっかり固まっていれば、以降の項目は書きやすくなります。

スコープと規模を伝える項目（対象業務範囲・スコープ／想定ユーザー数・利用規模）

続いて、対象業務範囲・スコープと、想定ユーザー数・利用規模を伝えます。範囲と規模の認識がずれると、費用や提案内容の前提そのものが変わってしまうためです。

対象業務範囲・スコープでは、AIに任せる業務範囲、対象部門、対象ユーザーに加えて、対象外とする範囲も明記します。スコープを明確にすることで、追加費用や後々の認識齟齬を防げるとされています。

想定ユーザー数・利用規模では、利用人数、利用頻度、想定データ量など規模感を伝えます。規模とかみ合わない過大・過小な提案を避けるうえで欠かせない項目です。小規模な部署導入と全社導入では、必要な提案の中身が大きく変わる点も意識してください。

機能・性能に関する項目（必須機能要件／精度・性能要件）

機能・性能に関する項目では、必須機能要件と精度・性能要件をあわせて記載します。AI案件では、機能だけでなく精度の定義がベンダー選定の分かれ目になるためです。

必須機能要件は、実現してほしい機能を業務課題ベースで箇条書きにします。技術仕様まで細かく縛りすぎると、ベンダーの創意工夫の余地を狭めてしまう点には注意が必要です。優先度の高い機能と、あれば嬉しい機能を分けて書くと、提案の比較がしやすくなります。

精度・性能要件は、AI案件ならではの項目です。精度目標は技術指標だけでなく、調査時間の削減といった業務成果指標とあわせて示すことが望ましいとされています。評価基準・改善サイクル・誤回答時のガードレールも、あわせて求めておくと安心です。

AI特有のデータ・セキュリティ・連携に関する項目（データの取り扱い／セキュリティ要件／既存システムとの連携）

ここからはAI案件特有の項目です。データの取り扱い、セキュリティ要件、既存システムとの連携という3項目を明記します。AIは扱うデータの質と量が成果を大きく左右するためです。

データの取り扱いでは、保有データの形式・量・機密区分・整備状況を明記し、学習利用や外部送信の可否を伝えます。データ整備の工数は費用に直結するため、現状のデータ状態を正直に開示することが重要とされています。

セキュリティ要件では、機密情報の外部送信可否、アクセス制御、監査ログの取得方法などを明記してください。入力データの保存期間、モデル改善への利用、学習利用の初期設定、管理機能はサービスや契約プランによって異なります。導入時は候補サービスの現行規約と設定を確認しましょう。

既存システムとの連携では、接続予定のシステムとAPI仕様の有無、連携方式を記載します。連携範囲が曖昧だと、ベンダーごとに見積もりの前提がばらつく原因になりやすい点に注意が必要です。

予算・選定・契約に関する項目（予算感・予算上限／選定スケジュール・評価基準／契約条件・保守運用体制）

最後のグループは、予算感・予算上限、選定スケジュール・評価基準、契約条件・保守運用体制という3項目です。ここが曖昧だと、選定プロセス全体の公正さが揺らいでしまいます。

予算感・予算上限は、目安となる予算レンジを示す項目です。企画から運用保守まで含めると、案件の規模によって金額の幅は大きく変わるとされています。断定的な数字にこだわりすぎず、運用フェーズのランニングコスト（API従量課金など）も含めて聞く姿勢が望ましいといえます。

選定スケジュール・評価基準では、提案期限、選定プロセス、評価項目と配点をRFP発出前に決めておきます。ベンダーの提案を見た後に基準を作ると、比較の公正性が失われやすいためです。

契約条件・保守運用体制では、準委任か請負かという名称だけでなく、求める成果の内容・水準、検収方法、責任分担を明確にします。あわせて、運用開始後の監視、改善・更新、必要に応じた再学習の判断者と費用負担も確認してください。

RFP作成からベンダー選定までの進め方（スケジュール感）

RFP作成からベンダー選定までは、いくつかの段階を順番に踏んで進めます。段階を飛ばすと、比較検討の材料が不足したまま契約に進んでしまうためです。全体の流れを事前に把握しておくと、社内調整のスケジュールも立てやすくなるでしょう。

一般的な流れは、次のとおりです。まず社内で現状課題を整理し、目的を設定します。必要に応じてRFIで情報収集・市場調査を行い、必須項目を盛り込んだRFPを作成してください。

RFPを発出した後は、説明会を実施したりベンダーからの質問に対応したりしながら、提案書と見積もりを受け取ります。質問対応の窓口は一本化しておくと、ベンダーごとの解釈のずれを防ぎやすくなるはずです。

受け取った提案は評価・比較を行い、プレゼンを経てベンダーを選定します。その後は契約交渉と契約締結に進み、詳細な要件定義や開発・導入へと移っていく流れです。

必要な期間は、システム構築の規模、対象業務の複雑さ、社内体制、意思決定の手順、候補ベンダー数によって大きく変わります。固定的な期間を前提にせず、社内検討、質問受付、提案準備、評価、契約交渉に必要な日程を順に積み上げて計画してください。

AI案件ではPoC（概念実証）フェーズを挟むこともあり、その場合はさらに期間が延びる可能性も見込んでおくとよいでしょう。逆算すると、ベンダー選定を急ぎたいときほど、社内の現状整理を早く終わらせることが近道になります。

提案を正しく比較するための評価基準・スコアリングの作り方

提案を正しく比較するには、評価項目と配点をRFP発出前に決めておくことが欠かせません。基準がないまま提案を受け取ると、比較が印象頼みになってしまうためです。声の大きい提案や見栄えのよい資料に、判断が引っ張られてしまう危険もあります。

評価基準は、大きく分けて業務成果指標と技術指標の2種類を用意します。業務成果指標は、業務時間の削減や対応品質の向上など、実際の効果に直結する指標です。技術指標は、精度や応答速度など、システムそのものの性能を示す指標になります。

AI案件では、技術指標だけで評価すると、業務に結びつかない提案を高く評価してしまうリスクがあります。業務成果指標と技術指標をセットで評価する考え方は、複数の専門サイトでも推奨されています。

具体的な方法としては、価格・技術力・実績・サポート体制といった項目ごとに配点を割り振り、合計点でベンダーを比較するやり方もよく使われます。項目ごとの重みづけは、プロジェクトの性質に応じて変えて構いません。

例えば精度がそのまま事業成果に直結する案件なら、技術力の配点を高めに設定するといった調整が考えられます。配点は事前に社内で合意しておき、提案受領後に変更しないことが、選定プロセスの公正性を保つコツです。

中小企業がRFP作成でやりがちな失敗と回避策

中小企業のRFP作成では、人手が限られる中で項目を埋めるため、記載の粒度や評価方法が偏らないよう注意が必要です。ここでは代表的な5つの落とし穴と、その回避策を紹介します。

1つ目は、詳細すぎるRFPです。技術仕様まで細かく指定しすぎると、ベンダー側の提案余地がなくなるだけでなく、社内の誰も回答できない項目が残り、RFP自体が形骸化しかねません。回避策は、技術仕様ではなく業務課題ベースで要件を書くことです。

2つ目は、曖昧すぎるRFPです。抽象的すぎると、各社の提案の粒度や前提条件がばらばらになり、比較そのものが難しくなります。RFPは詳細さよりも網羅性を優先すべきという指摘もあり、必須項目を漏れなく埋めることが優先されます。

3つ目は、評価基準を後から決めてしまうことです。ベンダーの提案を見てから基準を作ると、特定ベンダーに有利な基準になりがちで、選定プロセスの説得力が失われます。評価基準・配点は、提案受領前に固めておく必要があります。

4つ目は、AIの成功指標を精度だけで語ってしまうことです。正答率などの精度だけを指標にすると、業務成果に結びつかない提案を高く評価してしまうおそれがあります。

工数削減や対応時間短縮といった業務指標とセットで定義することが望ましいとされています。

5つ目は、対象外とする範囲を書かないことです。「今回はやらないこと」まで明記しておくと、後から追加費用をめぐる認識のずれが生じるリスクを下げられます。

5つの失敗パターンに共通するのは、書く量ではなく網羅性を意識できているかという点です。細かさより漏れのなさを優先する姿勢が、結果として質の高い比較検討につながります。

まずは無料テンプレートで「主導権を握るRFP」を作ってみる

ここまで紹介した必須項目を、一から自分で書き出すのは決して簡単ではありません。項目の抜け漏れがあると、比較検討の材料が不足したまま進んでしまうためです。フォーマットを考える手間だけでも、担当者の負担は小さくありません。

そこでおすすめなのが、必須項目があらかじめ整理されたテンプレートを土台にする方法です。ゼロから作るより、項目を埋めていく形の方が、社内の検討もスムーズに進みます。抜け漏れを防ぎながら、短時間でRFPの土台を用意できる点も利点です。

AI現場ログでは、【無料DL】AI導入RFP（提案依頼書）テンプレート｜必須項目入りを無料で配布しています。

本記事で解説した背景・目的からセキュリティ要件、評価基準まで、必須項目をあらかじめ書式に落とし込んだWord形式の雛形です。

丸投げにしないための第一歩は、発注側が主導権を持って項目を埋めていくことです。テンプレートを土台に、自社の言葉でRFPを書き上げてみてください。

よくある質問（FAQ）

RFP作成にあたっては、細かい疑問が次々と出てくるものです。ここでは、中小企業の担当者からよく寄せられる疑問を6つ選び、Q&A形式で簡潔に答えていきます。

Q1. RFPとRFIの違いは何ですか？
Q2. RFP作成にはどれくらいの期間がかかりますか？
Q3. 中小企業でもRFPは必要ですか？
Q4. RFPを書かずにベンダーに相談してもいいですか？
Q5. AI導入のRFPで学習データについては何を書けばいいですか？
Q6. RFPの評価基準はいつ決めればいいですか？

Q1. RFPとRFIの違いは何ですか？

RFI（情報提供依頼書）は、どこから手をつければよいか分からない段階で、製品やサービスの情報を幅広く集めるための文書です。RFP（提案依頼書）は、課題や要求を明確にし、具体的な解決策の提案と見積もりを求める文書という違いがあります。RFP作成前の市場調査でRFIを使うケースが多く見られます。