AIエージェント開発の費用はどう決まるか
結論から
AIエージェント開発の費用は「人月単価×工数」で計算されますが、金額の大半を決めるのは人月単価ではなく工数側です。工数は、任せる業務の判断の複雑さ、連携する既存システムの数と素性、間違えたときの損害の大きさ、の3つでほぼ決まります。同じ「AIエージェントを作りたい」でも、この3つが違えば見積は一桁変わります。相場表を探すより、自社の要件をこの3軸で言語化してから複数社に当てるほうが、結果として安く早く着地します。
この記事の要点
- 費用は「人月単価×工数」。比較で差がつくのは単価ではなく工数の見積根拠のほう
- 工数を決める最大の変数は、AIの判断の難しさではなく「既存システムとの接続本数と、その仕様書の有無」
- 見積書では、評価（精度検証）の工数と、リリース後の運用・改善の体制が別項目で立っているかを見る
- 「安い見積」の多くは、評価・データ整備・例外処理・運用監視のいずれかが抜けている
- PoCで終わるプロジェクトの共通点は、着手前に合格ラインの数値が決まっていないこと
「AIエージェントを作りたいのですが、いくらぐらいかかりますか」というご相談を数多くいただきます。正直に言えば、この質問だけで金額をお答えできる開発会社があるとすれば、それは見積ではなく当て推量です。同じ言葉で語られる案件の中身が、あまりにも違いすぎるからです。
この記事では相場表を並べる代わりに、見積がどういう構造で組み上がるのかを分解します。構造がわかれば、他社から出てきた見積書のどこを見ればよいか、なぜA社とB社で金額が3倍違うのかが判断できるようになります。
費用の基本式と、そこに潜む誤解
受託開発の費用は、業界を問わずほぼこの式で決まります。
開発費用 ＝ 人月単価 × 工数（人月） ＋ 外部サービス費用（LLM API・クラウド等）
多くの発注担当者は、この式の左側、つまり人月単価の比較に時間を使います。しかし実務で金額差の大半を生むのは右側の工数です。単価が2割違っても総額は2割しか動きませんが、工数の見立てが違えば総額は簡単に3倍になります。
そして工数の見立ては、発注側が渡した情報の粒度に強く依存します。粗い依頼には、リスク分を厚く積んだ見積が返ってくる。これは開発会社が不誠実だからではなく、わからないものを安く請けると事故になるからです。つまり要件を具体化すること自体が、直接的なコスト削減策になります。
工数を決める7つの変数
「AIエージェントを作る」という同じ依頼が、なぜ数百万円にも数千万円にもなるのか。工数を膨らませる要因は、経験上ほぼこの7つに集約されます。自社の案件がどこに当てはまるかを確認してみてください。
1. 任せる判断の難しさ
「決まった書式のメールから金額と期日を抜き出す」のような抽出タスクと、「見積依頼の内容を読んで、過去案件を参照しながら概算金額を提示する」のような判断タスクでは、必要な作り込みが違います。前者は入出力が明確で検証もしやすい。後者は「何をもって正解とするか」の定義から始まります。
2. 接続する既存システムの数と素性
実務では、ここが最大の変数になります。エージェント本体のロジックより、基幹システム・SFA・グループウェアとの接続のほうが工数を食うのが普通です。特に次のような条件が重なると一気に膨らみます。
- APIが公開されておらず、画面操作の自動化やCSV連携で回避する必要がある
- 仕様書が現存せず、実物のデータを見ながら仕様を復元する必要がある
- ベンダーロックがかかっており、接続の可否確認から交渉が必要になる
- 本番環境に触れず、テスト用のデータも用意できない
見積依頼の段階で「接続先システム名・API有無・仕様書有無・テスト環境有無」の一覧を渡せると、返ってくる金額の精度が大きく上がります。
3. 間違えたときの損害の大きさ
社内の下書き作成を任せるエージェントと、顧客に直接回答するエージェント、あるいは発注を確定させるエージェントでは、求められる安全設計がまったく違います。損害が大きいほど、承認フロー・ログ・巻き戻し・監査の作り込みが必要になり、これらは地味に工数を消費します。
4. 扱うデータの整備状況
社内文書を参照させる場合、その文書が検索可能な状態にあるかどうかで前処理の工数が変わります。紙・スキャンPDF・個人フォルダに散在、といった状態からのスタートは、データ整備だけで独立した工程になります。
5. 例外処理の範囲
「9割のケースを自動化する」と「例外も含めて全件処理する」の差は、体感で2倍以上です。実務上は、例外を人に戻す導線を作るほうが安く、かつ安全です。全件自動化を最初から目指す要件になっていないか確認してください。
6. 精度の合格ライン
合格ラインが決まっていないプロジェクトは、いつまでも終わりません。「なんとなく良さそう」で判断すると、レビューのたびに手直しが発生します。後述のとおり、着手前に数値を決めることが最大のコスト管理です。
7. 誰が運用するか
納品後に社内で改善していく前提なら、管理画面やプロンプトの編集機能、ログの可視化が必要になります。ベンダーが運用を巻き取る前提なら、その分は月額の保守費に乗ります。どちらが安いかは運用年数によって逆転するため、3年程度で比較するのが実務的です。
見積書で必ず確認すべき5項目
複数社から見積を取ったとき、総額だけを並べても比較にはなりません。次の5項目が独立した行として立っているかを見てください。抜けている項目は、消えたのではなく、あとから追加費用として戻ってきます。
| 確認項目 | 抜けているとどうなるか |
|---|---|
| 評価・精度検証の工数 | 「動くけれど使えない」状態で納品され、手直しが追加費用になる |
| データ整備・前処理の工数 | 着手後に「このデータでは精度が出ません」となり、中断か追加見積になる |
| 例外処理・エラー時の挙動 | 想定外の入力で止まり、結局人が全件確認することになる |
| 運用監視・ログの仕組み | 精度が落ちても気づけず、静かに使われなくなる |
| 納品後の改善体制と費用 | リリース直後の微調整すら都度見積になり、改善が止まる |
PoCで終わらせないための発注要件
生成AIの案件で最も多い失敗は、技術的に失敗することではありません。動くものはできたのに、本番で使われないまま終わることです。原因はほぼ一つで、着手前に合格ラインが決まっていないことに尽きます。
着手前に、次の3つを数値で決めてください。開発会社が決めるのではなく、業務を持っている側が決める必要があります。
- 対象業務と件数：どの業務の、月何件を対象にするか（例：見積依頼メールの一次仕分け、月400件）
- 合格ライン：何がどれだけできれば合格か（例：人の修正なしで通る割合が80%以上、致命的な誤りは0件）
- 測り方：誰が、どのデータで、いつ判定するか（例：直近3か月の実データ100件を、担当者2名がブラインドで判定）
この3つが決まっていれば、開発会社は「その基準を満たすには何が必要か」で見積を組めます。決まっていなければ、どこまでやれば終わりかがわからないので、リスク分を積むか、安く受けて後で揉めるかのどちらかになります。
また、合格ラインを決める作業自体が、その業務を自動化すべきかどうかの判断になります。「人がやっても8割しか合わない業務」にAIの精度を求めても意味がありません。ここを一緒に詰める段階から入る進め方については、FDEコンサルティングのページで詳しくご説明しています。
内製・外注・ハイブリッドの判断
近年は「AIエージェントくらいなら自社で作れるのでは」というご相談も増えました。判断軸をまとめます。
| 進め方 | 向いているケース | 注意点 |
|---|---|---|
| 内製 | 対象業務が社内に閉じており、改善を高頻度で回したい。エンジニアが在籍している | 評価設計と運用監視が抜けやすい。担当者の異動でブラックボックス化する |
| 外注 | 既存システムとの接続が多い。品質責任を明確にしたい。社内に開発リソースがない | 改善のたびに発注が必要。仕様が固まらない段階で丸投げすると高くつく |
| ハイブリッド | 最初の設計と接続部分は外部、日々の改善は社内で回したい | 引き継ぎ設計を契約時に握っておかないと、結局どちらも中途半端になる |
実務上おすすめしているのはハイブリッドです。設計と難所の接続は外部の手を借り、プロンプトや業務ルールの調整は社内で回せる形にしておくと、改善のスピードとコストが両立します。社内で回せる状態を先に作りたい場合は、AI内製化研修から入る選択肢もあります。
見積依頼の前に用意しておくと安くなる資料
最後に実務的な話を。次の資料が揃っているだけで、見積の精度が上がり、リスク分の上乗せが減ります。すべて完璧である必要はありません。
- 対象業務の手順（箇条書きで可。誰が何をどの順でやっているか）
- 実際の入力データのサンプル（機密部分はマスクして構いません）
- 接続したいシステムの一覧と、API・仕様書・テスト環境の有無
- 現在その業務にかかっている時間と人数
- いつまでに、どの状態になっていてほしいか
特に3つ目と4つ目は、金額の妥当性を発注側が判断するためにも必要です。月40時間かかっている業務なら、投資回収の目安も計算できます。
よくあるご質問
- AIエージェント開発の費用相場はいくらですか？
- 案件によって一桁変わるため、相場という形でお答えできる数字はありません。費用は「人月単価×工数」で決まり、工数は主に、任せる判断の複雑さ、接続する既存システムの数と仕様書の有無、間違えたときの損害の大きさの3つで決まります。同じ「AIエージェント」でもこの3つが違えば金額はまったく別物になります。自社の要件をこの3軸で整理してから複数社に見積を依頼するのが、最も確実な進め方です。
- 見積が会社によって大きく違うのはなぜですか？
- 多くの場合、単価差ではなく工数の見立ての差です。特に、精度検証（評価）の工数、データ整備の工数、例外処理の範囲、運用監視の仕組みを含めているかどうかで総額が変わります。安い見積はこれらのいずれかが含まれていないことが多く、着手後に追加費用として戻ってきます。総額ではなく工程ごとの内訳で比較してください。
- PoC（実証）で終わってしまうのを防ぐには？
- 着手前に「対象業務と件数」「合格ライン（数値）」「測り方」の3つを決めてください。たとえば「見積依頼メールの一次仕分け、月400件、人の修正なしで通る割合80%以上、直近3か月の実データ100件を担当者2名で判定」といった具体度です。この3つが決まっていないプロジェクトは、完了の定義がないため本番移行の判断ができず、PoCのまま止まります。
- LLMのAPI利用料はどのくらいかかりますか？
- 社内業務向けのエージェントであれば、開発費に対してAPI費用が支配的になることは多くありません。月間処理件数と1件あたりの入出力トークン量から試算できるので、見積時に概算を出してもらってください。一方、顧客向けに大量のトラフィックを処理する用途では設計次第で費用が大きく変わるため、想定件数を早い段階で共有することが重要です。
- 自社で内製するのと外注するのはどちらが安いですか？
- 3年程度の総コストで比較することをおすすめします。内製は改善サイクルが速い一方、評価設計と運用監視が抜けやすく、担当者の異動でブラックボックス化するリスクがあります。外注は品質責任が明確ですが、改善のたびに発注が必要です。実務上は、設計と既存システム接続を外部が担い、日々のプロンプト調整や業務ルールの更新は社内で回すハイブリッドが最もバランスが取れます。
要件が固まっていない段階からご相談ください
「何を自動化すべきか」から一緒に整理します。対象業務と現状の工数さえ分かれば、実現可否と概算の考え方をその場でお伝えできます。初回のご相談は無料です。
開発について相談する