AIエージェント開発・構築のRFP/要件定義書/提案依頼書について

AIエージェントの開発を外部のベンダーに発注しようとするとき、最初の関門になるのがRFP（提案依頼書）と要件定義書の作成です。ところが「何を、どこまで書けばいいのか分からない」「曖昧なまま相見積もりを取ったら、各社の金額が2〜10倍も違って比較できなかった」という声は後を絶ちません。AIエージェント開発は、扱う業務範囲や連携先、API利用料の前提が少し変わるだけで費用が大きく動くため、発注側のドキュメントの精度がプロジェクトの成否とコストを左右します。

本記事は、AIエージェント開発・構築のRFP・要件定義書・提案依頼書を、発注者の実務に特化して解説する「要件定義特化」の解説です。要件定義がなぜ最重要なのか、RFPに必ず記載すべき5項目、優良ベンダーを見抜く相見積もりの正攻法、そしていきなり本開発に走らずPoC（概念実証）から小さく発注する進め方までを、一次データとあわせて具体的に解説します。読み終えるころには、ベンダーの技術力と運用力を「丸裸にする」RFPの書き方が分かり、見積のブレを抑えて優良パートナーを選べるようになるはずです。なお、AIエージェント開発・構築の全体像をまだ把握していない方は、まずAIエージェント開発・構築の完全ガイドから読むことをおすすめします。

要件定義がAIエージェント開発で最重要な理由

AIエージェント開発では、要件定義の精度が他のシステム開発以上に重要です。理由は、AIエージェントの費用が「どこまでの業務をカバーするか」「どのシステムと連携するか」「どれだけのAPI利用料を見込むか」といった前提に強く依存するからです。これらの前提が曖昧なまま見積を依頼すると、各社が異なる前提で計算するため、金額が大きく食い違い、適正価格の判断ができなくなります。

AIエージェント開発の見積は、要件が曖昧だと2〜10倍もの差が生まれることがあります。たとえば「問い合わせ対応をAI化したい」という一文だけでは、対応する問い合わせの種類、連携するシステムの数、想定する月間処理件数、例外時の人へのエスカレーション設計など、費用を決める要素がまったく定まりません。あるベンダーは最小構成のシングルエージェントで300万円と見積もり、別のベンダーは将来の拡張を見込んだマルチエージェント構成で3,000万円と見積もる、ということが現実に起こります。

この食い違いの責任は、必ずしもベンダーにあるわけではありません。発注側が前提を示さなければ、各社は自社の解釈で見積を組むしかないからです。だからこそ、要件定義書でスコープを明確にすることが、見積のブレを抑える最大の手段になります。シングルエージェントの相場は50万〜500万円、マルチエージェントは300万〜3,000万円以上と幅が広く、どちらを前提にするかで費用は一桁変わります。スコープを曖昧にしたまま発注することが、いかにコスト管理を難しくするかが分かります。

AIエージェント特有の落とし穴が、API利用料（LLMの従量課金）と運用コストです。これは初期の構築費用とは別に、稼働後も継続的にかかる費用で、利用量に応じて変動します。一次データでは、CrewAIとGPT-4oの組み合わせで3,000字の記事を生成する場合、実行180秒で約$0.12（約18円）/記事、入力15kトークン・出力4kトークンが目安とされています。1件あたりは小さく見えても、月数万件を処理するなら無視できない金額になります。

さらに、RAG（検索拡張生成）を使う場合の維持費もあります。中規模（5,000ファイル）のシステムで、固定費約2.5万円＋API約1.5万円＝月約4万円が目安です。要件定義の段階で、想定処理件数を示し、初期費用だけでなく月々の運用コストまで見積もるよう依頼することが、稼働後の「思ったより高い」を防ぎます。とくに、後述するコスト暴走のリスクを避けるためにも、API利用料の上限や前提条件を要件として明記しておくことが重要です。これらの運用コストの相場感は、メリット・デメリットを費用面から整理した関連記事もあわせて参照すると理解が深まります。

RFPに必ず記載する5項目

見積のブレを抑え、ベンダーの提案を正しく引き出すために、RFPには最低限5つの項目を記載します。この5項目を押さえるだけで、各社が同じ前提で提案できるようになり、比較の精度が一気に上がります。ここでは、それぞれの項目で何を書くべきかを具体的に解説します。

1つ目は、業務フローとAI/人間の役割分担です。対象業務の流れを示したうえで、どの工程をAIエージェントに任せ、どの工程で人が介在するか（Human-in-the-Loop、略してHITL）を明確にします。たとえば「AIが下書きを作り、人が最終承認する」のように、AIと人の責任の境界を定めます。この役割分担が曖昧だと、AIに任せすぎて事故が起きたり、逆に人の確認が多すぎて効率化されなかったりします。

2つ目は、現状の工数と期待するROIの基準です。対象業務に現在どれだけの時間・人員がかかっているかを示し、AIエージェント導入でどこまで削減したいかを数値で記載します。これにより、ベンダーは効果に見合った提案ができ、発注側も投資判断の物差しを持てます。前述のセブン銀行が月間対応を6万件から26万件へ拡大した例のように、削減だけでなく処理能力の拡張を狙うなら、その目標も明記します。現状工数とROI基準を示すことが、提案の質を大きく高めます。

3つ目は、連携が必要な既存システムの一覧です。AIエージェントが操作・参照する社内システム（基幹システム、顧客管理、在庫管理など）を漏れなく列挙します。連携先は費用に直結し、一次データでは連携先が1つ増えるごとに初期費用が1.5〜5%、月額が0.5〜1%加算される傾向があります。とくにAPIが整備されていない古い基幹システムとの連携は難易度が高く、ここを見落とすと後から費用が膨らみます。連携先と、その接続方法（APIの有無）まで示すことが大切です。

4つ目は非機能要件とガイドライン準拠、5つ目は運用保守の範囲です。非機能要件には、応答速度、同時処理数、セキュリティ、そしてAI事業者ガイドラインへの準拠などを含めます。とくに金融や医療では、ガイドライン対応に大きなコストがかかり、一次データでは金融（与信）で年6〜24人月＝約265万〜1,635万円、医療（診断支援）で年4〜18人月＝約180万〜1,226万円の追加負担が目安とされています。運用保守については、ハルシネーション（誤った出力）の監視、モデル更新への追従、障害対応などの範囲を定めます。これら5項目を書き切れば、ベンダーの技術力と運用力を提案段階で見極められます。

優良ベンダーを見抜く相見積もりの正攻法

RFPを整えたら、次は相見積もりです。ここで重要なのは、ただ複数社から金額を取るのではなく、相場観を持ったうえでTCO（総保有コスト）で比較することです。AIエージェント開発はベンダーによって価格体系が大きく異なるため、比較の仕方を間違えると、安く見えて高くつくベンダーを選んでしまいます。ここでは、優良ベンダーを見抜く相見積もりの進め方を解説します。

相見積もりのコツは、性格の異なるベンダーを混ぜることです。具体的には、料金体系をある程度公開している会社と、伴走・顧問型で支援する会社の両方から見積を取ります。料金公開型は相場の下限を知るのに役立ち、顧問型は自社の業務にどれだけ深く入り込んで設計してくれるかを測る材料になります。両者を比べることで、価格と支援の質のバランスが見えてきます。

人月単価の相場も押さえておくと、見積の妥当性を判断できます。一次データでは、AIエンジニアの人日単価が18〜22万円、PM（プロジェクトマネージャー）が15〜20万円、コンサルティングは年132万円〜が目安です。提示された金額を工数で割り戻し、この相場と照らせば、不自然に高い、あるいは安すぎる見積を見抜けます。安すぎる見積は、必要な工程を省いていたり、運用コストを含んでいなかったりするため、かえって注意が必要です。

AIエージェントの見積比較で最も陥りやすい誤りが、初期構築費用だけを見て判断することです。AIエージェントは稼働後にもAPI利用料、RAG維持費、保守費が継続的にかかるため、初期費用が安くても運用コストが高ければ、数年単位の総額（TCO）では割高になります。前述のとおり、RAG維持費は中規模で月約4万円、API利用料は処理件数に比例して増えます。これらを含めた3年程度のTCOで各社を比較することが、本当の意味でのコスト評価です。

TCO比較では、内製と外注、ハイブリッドの選択肢も視野に入れると判断が深まります。一次データでは、内製の場合、採用費50〜100万円に加え人件費600〜1,000万円で、初年度1人あたり700万〜1,200万円が目安です。外注より高くつくこともありますが、ノウハウが社内に残る利点があります。「設計は内製・実装は外注」「PoCは外注・運用は内製」といったハイブリッド型も現実的な選択肢です。この内製vs外注の判断軸は、メリット・デメリットを整理した関連記事で詳しく解説しているので、あわせてご覧ください。

まず小さく試すPoCから発注する

要件定義と相見積もりを経ても、いきなり本開発に全額を投じるのはリスクが高すぎます。AIエージェントは、実際に動かしてみないと精度や効果が読みきれない部分があるためです。そこで推奨されるのが、まずPoC（概念実証）で小さく発注し、実現性と効果を検証してから本開発に進む段階的なアプローチです。ここでは、PoCを起点にした発注の進め方を解説します。

PoCを発注するときに最も重要なのは、「何が達成できたらPoC成功とみなすか」という合格基準を、契約前に明文化することです。基準を決めずにPoCを始めると、「なんとなく動いた」だけで本開発に流れ込み、結局成果が出ないまま費用だけがかさみます。たとえば「特定の問い合わせ100件のうち80件を人手を介さず正しく処理できる」「現状の処理時間を半分にできる」といった、合否を判定できる具体的な数値を設定します。

この合格基準は、本開発に進むかを見送るかの「撤退ライン」も兼ねます。PoCで基準を満たせなければ、対象業務の選定や設計を見直すか、いったん見送る判断ができます。AIエージェント開発でよくある失敗が、効果が不確かなままPoCから本番へなだれ込み、結局使われないシステムに大金を払う「PoC死」です。合格基準と撤退ラインを契約段階で定めておくことが、この失敗を防ぐ最大の保険になります。撤退ラインやコスト暴走を止めるキルスイッチの考え方は、失敗・リスクを扱った関連記事で詳しく解説しています。

AIエージェント開発の発注では、契約形態の選択も見落とせません。大きく分けて、成果物の完成に責任を負う「請負契約」と、作業の遂行に対して対価を払う「準委任契約」があります。AIエージェントは、試行錯誤しながら精度を高めていく性質があるため、要件が固まりきらない探索的な段階では、アジャイル型の準委任契約が適することが多いです。一方、仕様が確定した本開発では請負契約で成果物の完成責任を明確にする、という使い分けが現実的です。

あわせて、AIの誤作動で損害が出た場合の責任の所在も、契約で定めておくべき重要事項です。AIエージェントはハルシネーションや誤判断のリスクをゼロにはできないため、どこまでがベンダーの契約不適合責任で、どこからが発注側の運用責任なのかを、あらかじめ取り決めておく必要があります。この線引きが曖昧だと、トラブル時に責任の押し付け合いになりかねません。riplaはフルスクラッチ受託の立場から、PoCの合格基準設定から契約形態の選定まで、発注者のリスクを抑える進め方を一貫して支援しています。要件定義を丁寧に行うことが、結果として最も安く、確実な開発につながります。

まとめ

AIエージェント開発のRFP・要件定義書・提案依頼書を振り返ると、成否の鍵は「スコープとAPI利用料の前提を明確に定義し、業務フロー・役割分担・連携システム・非機能要件・運用保守の5項目を漏れなく書き、TCOで比較してPoCから段階的に発注する」という一点に集約されます。要件の甘さは見積を2〜10倍ぶれさせ、API利用料やRAG維持費を見落とせば稼働後にコストが膨らみます。だからこそ、発注ドキュメントの精度を高めることが、最も安く確実な開発への近道です。

発注で大切なのは、ベンダーに丸投げせず、自社の業務と役割分担を自らの言葉で定義することです。そのうえでPoCの合格基準と撤退ラインを契約前に定め、効果を検証してから本開発に進めば、大きな失敗を避けられます。riplaはフルスクラッチ受託の立場から、要件定義から契約形態の選定まで、発注者のリスクを抑える進め方を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。