RFP(提案依頼書)と要件定義書は、AIエージェント開発を発注する最初の関門です。前提が曖昧なまま相見積もりを取ると、各社の金額が2〜10倍も違い、比べられなくなります。
業務範囲・連携先・API利用料の前提を明記し、RFPの5項目を押さえれば、比較の精度が上がります。全体像はAIエージェント開発・構築の完全ガイドで先につかめます。
AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
AIエージェント開発で要件定義が最重要な理由

AIエージェント開発では、要件定義の精度が他のシステム開発以上に重要になります。
AIエージェントの費用は、「どこまでの業務をカバーするか」「どのシステムと連携するか」「どれだけのAPI利用料を見込むか」という前提に強く左右されます。そのため、前提が曖昧なまま見積を依頼すると、各社が異なる前提で計算し、金額が食い違って適正価格を判断できなくなります。
スコープ定義の甘さによる見積の2〜10倍差
AIエージェント開発の見積は、要件が曖昧だと2〜10倍もの差が生まれることがあります。たとえば「問い合わせ対応をAI化したい」という一文だけでは、費用を決める要素がまだ定まりません。
実際に、最小構成のシングルエージェントで300万円と見積もるベンダーがいる一方で、将来の拡張を見込んだマルチエージェント構成で3,000万円と見積もるベンダーもあります。
この食い違いには、発注側が前提を示せていない面もあります。各社は前提がなければ、自社の解釈で見積を組むしかないためです。
だからこそ、要件定義書でスコープを明確にすることが、見積のブレを抑える最大の手段になります。シングルエージェントの相場は50万〜500万円、マルチエージェントは300万〜3,000万円以上と幅が広く、どちらを前提にするかで費用は一桁変わります。
スコープを曖昧にしたままでは、コスト管理が難しくなります。要件定義書には、見積の前提になる内容を具体的に書いておくと、各社が同じ条件で見積を組めます。
- 対象範囲:対応する問い合わせの種類と、連携するシステムの数
- 処理量と例外対応:想定する月間処理件数と、例外時に人へ渡す設計
API利用料・運用コストの前提の定義
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利用料の上限や前提条件を要件として明記することが重要です。
運用コストの相場感は、費用面からメリット・デメリットを整理した関連記事を読むと理解が深まります。
- 従量課金:利用量に応じて変わるAPI利用料の部分
- 固定費と維持費:稼働後も毎月続く費用
RFPに必ず記載する5項目

見積のブレを抑え、ベンダーの提案を正しく引き出すには、RFPに最低限5つの項目を記載します。5項目をそろえると、各社が同じ前提で提案でき、比較の精度が一気に上がります。
ここからは、項目ごとに何を書くべきかを具体的に説明します。
業務フロー・役割分担(HITL)と期待ROI基準
1つ目は、業務フローとAI・人間の役割分担です。たとえば「AIが下書きを作り、人が最終承認する」のような分担になります。
この役割分担が曖昧だと、AIに任せすぎて事故が起きたり、逆に人の確認が多すぎて効率化が進まなかったりします。
2つ目は、現状の工数と期待するROIの基準です。対象業務に今どれだけの時間と人員がかかっているかを示し、AIエージェント導入でどこまで削減したいかを数値で記載します。
これにより、ベンダーは効果に見合った提案を組み立てられ、発注側も投資判断の材料を持てます。セブン銀行が月間対応を6万件から26万件へ拡大した例のように、削減だけでなく処理能力の拡張を狙うなら、その目標も明記します。
- 役割と責任の境界:工程ごとに、AIと人のどちらが担うか(Human-in-the-Loop、略してHITL)
- 現状の工数と削減目標:対象業務の今の時間と人員、導入後に減らしたい数値
連携システム一覧・非機能要件・運用保守範囲
3つ目は、連携が必要な既存システムの一覧です。
AIエージェントが操作・参照する社内システム(基幹システム、顧客管理、在庫管理など)を、漏れなく列挙します。
連携先は費用に直結します。一次データでは、連携先が1つ増えるごとに初期費用が1.5〜5%、月額が0.5〜1%加算される傾向があります。
とくに、APIが整備されていない古い基幹システムとの連携は難易度が高く、ここを見落とすと後から費用が膨らみます。
4つ目は非機能要件とガイドライン準拠、5つ目は運用保守の範囲です。
非機能要件には、応答速度、同時処理数、セキュリティ、そしてAI事業者ガイドラインへの準拠などを含めます。
とくに金融や医療では、ガイドライン対応に大きなコストがかかります。
一次データでは、金融(与信)で年6〜24人月=約265万〜1,635万円、医療(診断支援)で年4〜18人月=約180万〜1,226万円が目安とされています。
運用保守では、ハルシネーション(誤った出力)の監視、モデル更新への追従、障害対応などの範囲を定めます。この5項目を書き切れば、ベンダーの技術力と運用力を提案段階で見極められます。
- 連携先の接続:各連携先の接続方法と、APIの有無
- 運用保守の範囲:監視、モデル更新、障害対応まで含めた範囲
優良ベンダーを見抜く相見積もりの正攻法

RFPを整えたら、次は相見積もりです。
ここで大切なのは、ただ複数社から金額を取ることではなく、相場観を持ったうえでTCO(総保有コスト)で比べることです。
AIエージェント開発は、ベンダーごとに価格体系が異なります。そのため、比べ方を誤ると、安く見えて高くつくベンダーを選んでしまいます。
料金公開社と顧問型を混ぜた相場の把握
相見積もりのコツは、性格の異なるベンダーを混ぜることです。具体的には、料金体系をある程度公開している会社と、伴走・顧問型で支援する会社の両方から見積を取ります。
料金公開型は相場の下限を知るのに役立ち、顧問型は自社の業務にどれだけ深く入り込んで設計してくれるかを測る材料になります。両者を比べることで、価格と支援の質のバランスが見えてきます。
人月単価の相場も押さえておくと、見積の妥当性を判断できます。一次データでは、AIエンジニアの人日単価が18〜22万円、PM(プロジェクトマネージャー)が15〜20万円、コンサルティングは年132万円〜が目安です。
提示された金額を工数で割り戻し、この相場と照らし合わせれば、不自然に高い見積や安すぎる見積を見抜けます。ただし、安すぎる見積は必要な工程を省いていたり、運用コストを含んでいなかったりするため、かえって注意が必要です。
- 料金公開型:見積から読み取れる相場の下限
- 顧問型:見積から読み取れる設計の深さ
初期費用だけでなくTCOによる総額の比較
AIエージェントの見積比較で最も陥りやすい誤りは、初期構築費用だけを見て判断することです。
AIエージェントは稼働後にも、API利用料やRAG維持費、保守費が継続してかかります。
RAG維持費は中規模で月約4万円、API利用料は処理件数に比例して増えます。これらを含めた3年程度のTCOで各社を比べることが、本当の意味でのコスト評価です。
一次データでは、内製の場合、採用費50〜100万円に加えて人件費600〜1,000万円がかかり、初年度1人あたり700万〜1,200万円が目安です。
外注より高くつくこともありますが、ノウハウが社内に残る利点があります。「設計は内製・実装は外注」「PoCは外注・運用は内製」といったハイブリッド型も、現実的な選択肢です。
内製と外注の判断軸は、メリット・デメリットを整理した関連記事で詳しく解説しているので、あわせてご覧ください。
- 初期費用と運用コストの総額:3年程度のTCOで比べ、安く見える初期費用が割高にならないかを見る
- 内製・外注・ハイブリッド:それぞれの費用と、社内にノウハウが残るかどうか
まず小さく試すPoCからの発注
要件定義と相見積もりを経ても、いきなり本開発に全額を投じるのはリスクが高すぎます。AIエージェントは、実際に動かしてみないと精度や効果を読みきれない部分があるためです。
推奨されるのは、まずPoC(概念実証)で小さく発注し、実現性と効果を検証してから本開発に進む段階的なアプローチです。
契約前に定めるPoCの合格基準
PoCを発注するときに最も重要なのは、「何が達成できたらPoC成功とみなすか」という合格基準を、契約前に明文化することです。
基準を決めずにPoCを始めると、「なんとなく動いた」だけで本開発に流れ込み、結局成果が出ないまま費用だけがかさみます。
基準の例は、「特定の問い合わせ100件のうち80件を人手を介さず正しく処理できる」「現状の処理時間を半分にできる」といったものです。
この合格基準は、本開発に進むかを見送るかの「撤退ライン」も兼ねます。PoCで基準を満たせなければ、対象業務の選定や設計を見直すか、いったん見送る判断ができます。
AIエージェント開発でよくある失敗が、効果が不確かなままPoCから本番へ進んでしまい、結局使われないシステムに大金を払う「PoC死」です。
合格基準と撤退ラインを契約段階で定めておくことが、この失敗を防ぐうえで最も効く手立てになります。撤退ラインやコスト暴走を止めるキルスイッチの考え方は、失敗・リスクを扱った関連記事で詳しく解説しています。
- 合否の判定基準:契約前に決めておく、具体的な数値
- 撤退ライン:基準を満たせないときに、本開発を見送る判断の線
請負か準委任か、契約形態と責任の所在
AIエージェント開発の発注では、契約形態の選択も見落とせません。契約には大きく分けて、成果物の完成に責任を負う「請負契約」と、作業の遂行に対して対価を払う「準委任契約」があります。
AIエージェントは試行錯誤しながら精度を高めていく性質があるため、要件が固まりきらない探索的な段階では、アジャイル型の準委任契約が適することが多いです。一方で、仕様が確定した本開発では、請負契約で成果物の完成責任を明確にするという使い分けが現実的です。
AIエージェントは、ハルシネーションや誤判断のリスクをゼロにできません。そのため、AIの誤作動で損害が出た場合の責任の所在を、契約で定めておく必要があります。
また、どこまでがベンダーの契約不適合責任で、どこからが発注側の運用責任なのかを、あらかじめ取り決めておくことが求められます。この線引きが曖昧だと、トラブル時に責任の押し付け合いになりかねません。
riplaはフルスクラッチ受託の立場から、PoCの合格基準の設定から契約形態の選定まで、発注者のリスクを抑える進め方を一貫して支援しています。
要件定義を丁寧に行うことが、結果として最も安く、確実な開発につながります。
- 探索段階と本開発:それぞれに合う契約形態を分けて選ぶ
- 損害の責任範囲:AIの誤作動による損害を、ベンダーと発注側のどちらが負うか
まとめ
AIエージェント開発のRFP・要件定義書・提案依頼書を振り返ると、成否の鍵は、スコープとAPI利用料の前提を明確に定義することにあります。そのうえで、業務フロー・役割分担・連携システム・非機能要件・運用保守の5項目を漏れなく書き、TCOで比較してPoCから段階的に発注します。
要件の甘さは見積を2〜10倍ぶれさせ、API利用料やRAG維持費を見落とせば稼働後にコストが膨らみます。だからこそ、発注ドキュメントの精度を高めることが、最も安く確実な開発への近道です。
発注で大切なのは、ベンダーに丸投げせず、自社の業務と役割分担を自らの言葉で定義することです。
発注側がPoCの合格基準と撤退ラインを契約前に定め、効果を検証してから本開発に進めば、大きな失敗を避けられます。
riplaはフルスクラッチ受託の立場から、要件定義から契約形態の選定まで、発注者のリスクを抑える進め方を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
