AI開発のRFP・提案依頼書の作り方｜そのまま検討に使える12項目

RFPは仕様をすべて決める書類ではない

RFPは、候補となる開発会社へ提案を依頼するための資料です。AI開発では、データを試さないと品質や費用を見通せない箇所があります。すべてを確定したふりをせず、決定済みの条件、仮定、検証が必要な点を分けて提示します。

たとえば「問い合わせを自動化したい」だけでなく、受付から分類・回答案・承認・送信のどこまでが対象かを書きます。完全自動返信を必須にする前に、対象の問い合わせの種類や、人の確認を残す条件を示す方が現実的な提案を受けやすくなります。

以下は当社が提案する検討用テンプレートです。契約書や法的な雛形ではなく、個別案件の要件を代替するものでもありません。契約条件は自社の法務・購買担当と別途確認してください。

提案依頼に入れる12項目と記入例

機密情報を含むデータをいきなり添付する必要はありません。まず項目一覧と匿名化サンプルを共有し、実データを渡す条件と管理方法を合意します。「必要な情報が揃っていないこと」も、調査工程の工数を左右する重要な情報です。

必要機能に、確かめ方を添える

「高精度」「使いやすい」といった表現だけでは、発注者と開発者の認識がずれます。回答品質なら、誰が用意した何種類の問題を、誰が、どんな基準で評価するかを書きます。合格値が未定なら、検証工程で合意する成果物にします。

たとえば社内検索では、答えがある質問だけでなく、資料に答えがない質問や、閲覧権限の異なる質問を含めます。業務登録では、正常完了だけでなく、途中失敗からの再開と二重登録防止を試します。実際に担当者が確認にかける時間も測定対象にします。

NISTのAI RMF Playbookは、AIのリスクを把握・測定・管理するための自主的な指針です。RFPでも、開発時の性能に限らず、導入後に誰が問題を検知して判断するかを考える参考になります。

各社の提案を比べる回答欄を用意する

候補各社には、必須項目ごとに「対応する方法」「前提」「含まれる費用」「別途費用」「確認が必要な点」を答えてもらいます。総額だけでなく、どこまで含まれているかを比較できる表にします。モデルや基盤を指定しない場合も、採用理由と変更時の影響を尋ねます。

試作、限定運用、本番化を分けて依頼すると、未検証の前提を含む一括見積もりと、調査後の見積もりを混同せずに済みます。各段階で何が手元に残るか、次へ進まない場合の扱いも確認します。

金額の大小だけで採点せず、自社担当者に必要な作業も比べます。データ整備を全部自社で行う案と、開発会社が支援する案では、社内負担が異なります。比較の詳細はAI開発の見積もり比較で整理しています。

依頼文の例：機能指定を検証可能な問いに変える

「社内の質問に何でも答えるAIを作ってほしい」という依頼は、範囲も評価も広すぎます。代わりに「総務への問い合わせのうち、公開済み社内規程で答えられる手続き案内を対象にする。個別の人事情報と例外承認は対象外」と書くと、提案の前提が揃いやすくなります。

続けて「回答に参照箇所を付け、根拠がない場合は担当窓口を示す。閲覧権限の異なる利用者で確認する。資料の更新時に誰が何をするかを提案に含める」と記載します。ここまであれば、画面だけでなく運用も含めた回答を求められます。

予算やデータの状態が未確定なら、未確定のまま明示します。たとえば「資料の重複や旧版の混在は未調査。調査方法と工数を別項目で提示してほしい」と書きます。前提を隠して安い見積もりを集めるより、追加作業が発生する条件を比較できます。

この依頼文は記入例です。自社の対象部署と資料へ置き換え、業務担当者が読んで実態と一致するか確認してから配布してください。

まだ業務範囲が決まらない場合の依頼方法

現場の困りごとは見えているのに、対象業務の境界や例外が分からない場合、開発一式のRFPより先に業務調査・試作の依頼を作る方法があります。求める成果物を、業務フロー、課題一覧、試作画面、実装候補、次段階の概算条件として指定します。

調査の依頼でも「いい感じにAI化」では判断できません。対象部署、参加できる担当者、確認できる資料、意思決定の会議を明記します。調査の終了時に、何を決められる状態へ進みたいかを合意してください。

FDEの導入計画も、そのような進め方の選択肢です。仕様が固まっていないこと自体より、誰がいつ何を決めるかが曖昧なまま進むことを避けましょう。