😖

AIエージェント開発の見積もりは、なぜこんなに難しいのか

に公開

株式会社StoreHero CTO 鳥居です。

「この要件で、いくら・いつまでに作れますか?」

従来のWeb開発なら経験則で答えられたこの質問が、AIエージェント開発ではとても恐ろしい問いに変わります。
見積もりを出して外れる。バッファを積んでも外れる。「やってみないとわからない」が正直なところですが、それではビジネスが進みません。

この記事では、なぜAIエージェントの見積もりがこれほど難しいのか、そして不確実性をどう管理すればよいのかを整理します。


なぜ見積もりが「外れる」のか

従来のシステム開発が 「決定論的」 だったのに対し、AI開発は 「確率論的」 だからです。

従来のシステムは「Aボタンを押せばB画面に行く」という挙動が保証されていました。しかしLLMを核とするAIエージェントは、同じ指示を与えても毎回異なる挙動をする可能性があります。バグがあっても再現が難しく、直すと別の箇所が壊れる。

この違いを理解していないと、見積もりは必ず甘くなります。


AI開発における2つの見積もり

AIエージェント開発の見積もりには、大きく2種類があります。

種類 内容 性質
工数見積もり 作るのにどれくらい時間(人月)がかかるか 初期投資(一時費用)
コスト見積もり 運用にどれくらい費用(API料金等)がかかるか 運用費(継続費用)

どちらも従来の開発とは異なる難しさがあります。


工数見積もりが難しい理由

1. 自律的なループがブラックボックス化する

AIエージェント、特に「Agentic Workflow」と呼ばれるものは、単に質問に答えるだけでなく、自律的に考え、行動します。代表的なReAct(Reasoning + Acting)パターンでは、以下のループを回します。

  1. 思考(Thought): 今のタスクを解決するには何が必要か?
  2. 行動(Action): 適切なツール(検索、API等)を選んで実行
  3. 観察(Observation): 実行結果を見て、次の行動を決める

この「AIが自分で判断して行動を選ぶ」プロセスが見積もりを困難にします。何回ループを回せば正解に辿り着くのか、事前に予測することは困難です。


2. 「80%の罠」に陥る

「プロトタイプで精度80%が出たから、あと2割の工数で完成だ」

これはAI開発における死亡フラグです💀

精度を80%から実用レベル(95%以上)に引き上げる「ラストワンマイル」には、0%→80%と同等以上の工数がかかります。残り2割はエッジケースの集合体であり、一つ直すと別が壊れる「回帰」が頻発します。

経営層への説明:

「8割動いている」は「8割完成」ではありません。残りの精度向上に、これまでと同じ期間がかかる可能性があります。


3. データ整備コストの見落とし

「社内ドキュメントを検索させたい」という要件はシンプルに見えますが、そのドキュメントはAIが読める状態でしょうか?

データの状態 工数への影響
構造化されたDB・きれいなMarkdown 基準
テキスト抽出可能なPDF 1.5〜2倍
スキャン画像のPDF(OCR必要) 2〜3倍
表・図表を含む複雑なPDF 3〜5倍

「全部PDFです」と言われて蓋を開けたら、半分が画像スキャンだった、というケースは珍しくありません。データクレンジングと前処理に想定の倍以上かかることはよくあります。


4. 開発プロセス自体が未確立

従来のシステム開発には「要件定義→設計→実装→テスト」という型があります。AI開発には、この型がまだありません。

プロセスが曖昧なまま始めると、以下の問題が発生します。

決まっていないこと 起きる問題
AIと人間の役割分担 スコープが際限なく膨らむ
精度の合格ライン 「もう少し改善」が永遠に続く
実装方針(自前 or ツール活用) 最初から作り込んで工数爆発
ステークホルダーの関与タイミング 完成後に「これじゃない」

コスト見積もりが難しい理由

トークン消費が二次関数的に増大する

従来のシステムはリクエスト数に比例してコストが増えます(線形)。AIエージェントでは、複雑さによってコストが急増します。

RAGの場合:

  • ユーザーの質問:10トークン
  • 検索結果を含めた実際の入力:3,000〜5,000トークン
  • → 見かけの300〜500倍のトークンを消費

自律型エージェントの場合:

ステップ数 入力トークン 備考
1 500 初期プロンプト
10 5,000 履歴が蓄積
20 10,000 雪だるま式に増加

結果として、シンプルなQ&Aボットなら1回答あたり数円で済むものが、複雑なエージェントでは1タスクあたり500〜1,000円になることもあります。同じ「AI」でも10〜50倍のコスト差が生じます。

モデル選択で3〜40倍のコスト差

2026年1月現在、主要モデルの価格は以下の通りです(1Mトークンあたり)。

モデル 入力 出力 特徴
GPT-5.1 $1.25 $10.00 OpenAIの主力モデル
GPT-5-mini $0.25 $2.00 軽量・高速・低コスト
Claude Sonnet 4.5 $3.00 $15.00 Anthropicの主力モデル
Claude Haiku 4.5 $1.00 $5.00 軽量・高速・低コスト
Gemini 2.5 Pro $1.25 $10.00 Googleの主力モデル
Gemini 2.5 Flash $0.15 $0.60 軽量・高速・低コスト
Gemini 2.5 Flash-Lite $0.10 $0.40 最軽量・最安価

※最新の価格は公式ページを参照:OpenAI / Anthropic / Google AI

同じ「主力モデル」でもClaude Sonnet 4.5はGPT-5.1やGemini 2.5 Proの約2.4倍のコストがかかります。軽量モデルではGemini 2.5 Flash-Liteが最も安価で、Claude Sonnet 4.5と比較すると出力で約40倍の差があります。月間50万クエリの高負荷システムでは、モデル選択だけで月額数万ドルの差になりえます [1]

多くのチームはこの変数をテストしないまま高性能モデルを選択しがちですが、用途によっては軽量モデルで十分なケースも多いです。まずは安価なモデルで検証し、精度が不足する場合にのみ上位モデルへ切り替える戦略が有効です。

推論コストは「最大のコスト」ではない

RAGシステムにおいて、LLMの推論コストは目立ちますが、実際には最大のコストではありません。ストレージ、ベクトル検索の計算コスト、開発工数、継続的なメンテナンスを含めると、当初想定の数倍になることがあります。

ある試算では、月額1〜3千ドル程度に見えたプロジェクトが、インフラ・開発・運用を含めると年間50万ドル規模に膨らむケースも報告されています。


不確実性を管理する戦略

「わからない」で済ませるのではなく、不確実性を前提としたアプローチに変える必要があります。

戦略1:開発プロセスを先に合意する

見積もりを出す前に、以下を合意しておきます。

観点 決めるべき内容
AI/人間の境界 どこまでをAIに任せ、どこで人間が介入するか
精度の合格ライン 「90%正確なら本番投入OK」など具体的な数字
実装方針 自前実装か、Dify・n8n等のツールで代用できないか
ステークホルダー巻き込み 精度判定はビジネス側でないとできない。いつ関与してもらうか

戦略2:三点見積もりでリスクを可視化する

単一の数字ではなく、3パターンで提示します。

シナリオ 前提条件 工数目安
楽観 データがきれい、要件がシンプル 400時間
標準 一般的なデータ品質、中程度の複雑さ 700時間
悲観 データ整備が必要、高い精度要求 1,200時間

「どのシナリオになるかは、調査フェーズ完了まで確定しません」と明示し、リスクを共有します。

見積もりの2倍を想定せよ

海外のAI開発コンサルタントは、「ベンダーが提示する初期見積もりの2倍を想定せよ」とアドバイスしています。隠れたコスト(インフラ、モニタリング、再学習、統合)を含めると、12〜18ヶ月後には当初見積もりの2倍以上になることが多いためです。


戦略3:フェーズを細かく切る

いきなり本番開発の見積もりを出そうとしないこと。

フェーズ 期間 目的
PoC(概念実証) 2〜4週間 技術的な実現可能性を検証。リスクを洗い出す
MVP 8〜16週間 最小限の機能で本番投入。フィードバックを得る
本番拡張 継続 精度向上、機能追加

「まずPoCに投資いただき、その結果をもって本開発の見積もりを提示します」というアプローチが双方のリスクを下げます。

PoCでは、モデルの挙動、ツール連携の可否、処理速度などを最小限のコストで検証できます [2]。この段階で「データが使い物にならない」「現在のモデルでは精度が出ない」といったリスクを洗い出せれば、本開発での手戻りを大幅に減らせます。


APIコスト見積もりの考え方

工数見積もりについて: 本記事では工数(人月・時間)の具体的な目安は掲載していません。工数はデータ品質、要件の複雑さ、チームのスキルセット、既存システムとの連携有無など、各社固有の条件に大きく依存するため、汎用的な数値を示すことが困難なためです。工数見積もりについては、PoCを通じて自社の条件で検証することを推奨します。

一方、APIコストは計算式で試算可能です。以下の計算例を参考に、自社の条件で試算してください。

計算に必要な変数

変数 内容
クエリ数/月 ユーザー数 × 1日あたりの利用回数 × 営業日数 500人 × 2回 × 20日 = 20,000
入力トークン/クエリ システムプロンプト + 検索結果 + ユーザー入力 RAGの場合:3,000〜5,000
出力トークン/クエリ AIの応答長 回答:300〜800
モデル単価 選択するモデルの料金 本記事の価格表を参照

計算例1:社内ナレッジ検索(500人規模)

前提条件:

  • 月間20,000クエリ(500人 × 1日2クエリ × 20営業日)
  • 1クエリあたり:入力3,000トークン、出力500トークン
  • 月間消費:入力60Mトークン、出力10Mトークン

LLMコスト試算(月額):

GPT-5-mini(入力$0.25/M、出力$2.00/M)で計算した場合:

  • 入力: 60M × $0.25/M = $15
  • 出力: 10M × $2.00/M = $20
  • 合計: 約$35/月(約5,400円)

※モデル選択により大きく変動。Gemini 2.5 Flashなら約$15/月、Claude Sonnet 4.5なら約$330/月と、同じ処理でも20倍以上の差が生じる。

※上記はLLM API料金のみ。ベクトルDB($50〜100/月)、エンベディングAPI($5〜10/月)等が別途必要。


計算例2:カスタマーサポートBot(月5万件)

前提条件:

  • 月間50,000クエリ
  • 1クエリあたり:入力4,000トークン、出力800トークン
  • 月間消費:入力200Mトークン、出力40Mトークン

LLMコスト試算(月額):

GPT-5-mini(入力$0.25/M、出力$2.00/M)で計算した場合:

  • 入力: 200M × $0.25/M = $50
  • 出力: 40M × $2.00/M = $80
  • 合計: 約$130/月(約2万円)

※モデル選択により大きく変動。Gemini 2.5 Flashなら約$54/月、Claude Sonnet 4.5なら約$1,200/月。

ポイント: 同じ「サポートBot」でも、モデル選択で20倍以上のコスト差が生じる。まずは軽量モデルで検証し、精度不足の場合のみ上位モデルへ切り替える戦略が有効。


見落とされがちなコスト

LLM API以外にも、以下のコストを考慮する必要があります。

項目 目安
ベクトルDB(Pinecone等) $50〜500/月(データ量・クエリ数で変動)
エンベディングAPI $5〜50/月
評価基盤構築(テストデータ作成等) 開発工数の15〜20%
セキュリティテスト 開発工数の10〜15%
年間保守(モデル更新対応等) 初期開発費の15〜20%/年 [3]

特に年間保守は重要です。AIエージェントは「作って終わり」ではなく、データドリフト、モデルの劣化、ユーザーニーズの変化に対応し続ける必要があります [2:1]


まとめ:マインドセットの転換を

AIエージェント開発の見積もりが難しいのは、技術者の能力不足ではありません。確率的に動くシステムを扱う以上、従来の見積もり手法がそのまま使えないという構造的な問題です。

見積もりは「工数」と「コスト」の2種類があり、それぞれに固有の難しさがあります。

  • 工数見積もり:自律ループのブラックボックス化、80%の罠、データ依存、プロセス未確立
  • コスト見積もり:トークン消費の二次関数的増大、モデル選択による3〜40倍の差、隠れたインフラコスト

AIエージェント開発における見積もりは、単なる「コスト計算」ではなく「不確実性の管理計画」です。その難しさをPMや経営層と早期に共有し、フェーズごとに見積もりを精緻化していくアプローチが、プロジェクト成功の鍵になります。


参考文献


関連リンク

RAG実装コストの詳細

脚注
  1. The Real Cost of Enterprise RAG: Budget Estimation You Can Actually Trust - RAG About It ↩︎

  2. The Complete AI Agent Development Cost Guide for 2026 - Cleveroad ↩︎ ↩︎

  3. Costs of Building AI Agents: What Decision Makers Need to Know - Symphonize ↩︎

株式会社StoreHero

Discussion