AIエージェントの開発見積もりで確認したい6仕様

はじめに

AIエージェントの相談で、早い段階から聞かれる質問がある。

「いくらで作れますか？」

当然の質問だ。ところが、チャット画面のデモだけを見て金額を比べると、見積もりの前提が揃わない。片方は文章を作るだけ。もう片方は社内データを読み、承認を挟み、業務システムへ登録し、失敗時に担当者へ戻す。見た目が似ていても、開発と運用の仕事量は別物である。

AIエージェントの開発見積もりを比べるなら、機能一覧より先に6つの仕様を並べたい。業務範囲、実行権限、システム連携、評価条件、監視と復旧、継続改善だ。この分け方なら、PoCでは省ける項目と、本番運用で外せない項目が見える。

以下の6仕様は、公的な標準価格表ではない。株式会社Atsumellが、要件を設計・実装・テスト・運用の工数へ変換するために使う見積整理の枠組みである。外部資料は、本番運用でセキュリティや統制、監視が必要になる背景の確認に使う。

AIエージェントの開発見積もりは「画面数」では読めない

従来の業務システムでは、画面数、帳票数、API本数が見積もりの基準になりやすかった。AIエージェントでは、それだけでは足りない。

同じ「問い合わせメールへの返信案を作る」機能でも、次の条件で費用は変わる。

• 公開情報だけを使うか、顧客別の契約情報まで読むか
• 下書きで止めるか、承認後に送信まで行うか
• Gmailだけを見るか、CRMやDriveとも照合するか
• 回答の良し悪しを誰が、何件のテストで判定するか
• 誤送信や連携失敗をどう検知し、どこから再開するか

要するに、AIエージェントは「生成する機能」より「判断して動く範囲」が費用を左右する。Microsoftの組織向けの導入ガイダンスも、導入を計画、管理とセキュリティ、構築、運用管理の領域に分けている。実装だけを見積もっても、本番で必要な仕事は収まらない。

見積額は、各仕様について発生する設計、実装、テスト、運用準備の工数と、モデル・外部サービスの利用料で構成される。人月単価を先に掛けるのではなく、必要な成果物と担当者を先に出す。

この表がない提案は、初期構築費が安く見えても比較できない。運用設計やテスト作成が別契約になっている可能性があるからだ。

仕様1：対象業務を「開始から完了」まで切る

最初に決めるのは、AIに使うモデルではない。対象業務の開始条件と完了条件だ。

たとえば営業支援なら、「商談後のメールを作る」だけでは曖昧である。商談記録が保存されたら開始するのか。顧客名と次のアクションを抽出し、既存メールスレッドを探し、返信案を作り、人間の承認で完了とするのか。CRMへの活動登録まで含めるのか。

業務範囲は次の5点で書くと見積もりやすい。

対象業務が途中で切れていると、人間の後処理が残る。反対に、一度に端から端まで自動化しようとすると例外が増える。最初は一つの判断単位に絞り、手前と後ろの受け渡しを明記する方がよい。AIエージェントの入力設計も、入力の発生源と鮮度を先に揃える考え方を扱っている。

仕様2：権限を「読む・提案・書く・送る」に分ける

費用差が大きく出る二つ目の要因は権限だ。

情報を読むだけのエージェントと、外部へメールを送り、CRMを更新するエージェントでは、安全設計が違う。権限をまとめて「操作可能」と書かず、少なくとも4段階に分けたい。

1. 読む：データを取得し、要約や照合に使う
2. 提案する：更新案や送信文を下書きする
3. 書く：承認後に社内システムへ登録する
4. 送る：顧客や外部サービスへ確定情報を送信する

段階が上がるほど、承認画面、操作ログ、重複防止、取り消し手段が必要になる。とくに「書く」と「送る」の間には、人間の確認を置くべき業務が多い。

権限を絞ることは、単なる安全策ではない。初期費用を抑える方法でもある。PoCでは「読む・提案する」までに限定し、品質と利用頻度を確かめる。その後、安定した操作だけを承認付きで「書く」へ進める。社内AIエージェントの権限設計では、許可範囲と停止条件をもう少し詳しく整理している。

仕様3：システム連携はAPI本数より例外で数える

AIエージェントの開発費用では、連携先の数が目立つ。だが、APIが1本増えることより、連携時の例外が増える方が重い。

たとえばCRMへ会社を登録する処理では、同名会社、略称、メールドメインの共有、既存担当者、必須項目不足が起きる。正常系の登録APIだけなら短く作れる。しかし、誤った会社へ顧客情報を結び付けないためには、候補が複数なら止め、人間へ確認を返す必要がある。

見積もり前に、連携ごとに次を数える。

• 認証方式と権限単位
• 読み取りと書き込みのAPI
• 重複判定のキー
• 必須項目が欠けた場合の処理
• タイムアウトや回数制限への対応
• 再実行しても二重登録しない仕組み
• APIが利用できない場合の代替手段

Google Cloudも、本番対応のAIエージェントには長時間状態、セキュリティ、統制、監視まで含む基盤が必要だと本番運用ガイドで整理している。連携本数だけの見積もりは、この周辺作業を落としやすい。

仕様4：評価を「正解率」ではなく業務テストにする

AIの回答品質を「精度が高いこと」とだけ書くと、検収条件が決まらない。何を入力し、何を出せば合格なのか。誤りが許されない項目はどれか。判断が難しい場合に止まれるか。これらをテストケースにする。

営業メールの下書きなら、評価項目は文章の自然さだけではない。

• 宛先と会社の取り違えがない
• 既存スレッドへ返信できる
• 約束した資料と日程を漏らさない
• 未確定事項を断定しない
• 機密情報を本文へ出さない
• 根拠がない場合は確認待ちにできる

テストデータを30件作るのか、300件作るのかでも費用は変わる。正常例だけでなく、入力不足、矛盾、権限不足、外部サービス停止といった例外を含めたい。

AIエージェントの評価設計で扱っているように、評価は開発の最後に足す工程ではない。要件を合否へ変換する工程である。検収条件を先に作れば、「動いたが業務では使えない」というPoCを減らせる。

仕様5：監視と復旧を本番費用へ入れる

デモでは、成功した一回を見せればよい。本番では、失敗した一回を見つけて戻せなければならない。

監視には、少なくとも次の観点がある。

• いつ、誰の依頼で動いたか
• どのデータとツールを使ったか
• どの判断で止まり、どの操作を実行したか
• 処理時間と利用量が想定内か
• 失敗時に再実行できるか
• 同じ依頼を二重に処理していないか

さらに、モデルや外部APIの仕様は変わる。正常率、承認却下率、手戻り件数、1件当たりの利用量を追い、異常があれば通知する仕組みが必要だ。MicrosoftのAIエージェント成熟度モデルも、技術だけでなくガバナンス、価値測定、運用、組織能力を段階的に整える考え方を示している。

監視を省いた見積もりは安く見える。ただし、障害の発見と原因調査を人手へ移しただけかもしれない。本番比較では、構築費と一緒に保守範囲、一次対応時間、ログ保存期間を確認したい。

仕様6：改善サイクルと変更管理を決める

AIエージェントは、公開して終わりではない。業務ルール、参照資料、連携API、モデルが変われば、振る舞いも見直す。

継続改善の費用は、次の問いで変わる。

• 誰が失敗例と改善要望を集めるか
• 何件たまったら仕様を見直すか
• プロンプト、検索データ、処理コードを誰が更新するか
• 変更前後を同じテストセットで比較するか
• 本番へ戻す手順と承認者は誰か
• 月次の固定保守か、都度見積もりか

ここで避けたいのは、すべての不満をプロンプト修正で解決しようとすることだ。入力データの鮮度が原因かもしれない。業務ルールの矛盾かもしれない。UIで確認しにくいだけかもしれない。原因を分類し、仕様、データ、実装、運用のどこを直すか決める。

同じ業務でも見積もりが変わる例

商談後メールの支援を例にすると、PoC案は「議事録を手動で渡し、返信案を作る」までにできる。必要なのはプロンプト、限定した参照資料、代表テスト、簡単な利用画面だ。

本番案では、カレンダーや議事録の取得、顧客・案件の照合、既存メールスレッドの検索、添付資料の確認、承認、送信、CRM登録、失敗通知まで扱う。ここでは認証、名寄せ、権限、重複防止、操作ログ、復旧試験が追加される。

両者の違いは「AIの性能」ではない。成果物と責任範囲である。見積書では、次のように作業単位を分けるとよい。

• 業務フローと例外一覧の作成
• 権限表と承認フローの合意
• 外部連携ごとの設計・実装・結合試験
• 受け入れテストセットの作成と実施
• 監視、通知、復旧手順の構築
• 本番移行、利用者教育、初期運用支援

各作業に担当、前提、納品物、検収条件を付ける。これで発注者、元請け、開発会社の責任分界が見える。見積変更が必要になる条件も、曖昧な「仕様変更」ではなく、対象業務・権限・連携・評価の変更として扱える。

PoCと本番で見積もりを分ける

AIエージェントの開発費を一つの総額で比較すると、PoCと本番の境界が曖昧になる。二段階に分けた方が判断しやすい。

PoCの目的は「作れるか」だけではない。対象業務で契約判断に足る価値が出るか、どの条件を満たせば本番へ進むかを確かめることだ。最終決裁者と合格条件が不在のPoCは、技術的に成功しても次の予算へつながりにくい。

見積書で確認したい7つの項目

複数社の提案を比べるときは、金額の横に次の7項目を置く。

1. 対象業務の開始・完了条件
2. AIが実行できる権限と承認点
3. 連携先、例外、重複防止の範囲
4. テストデータの件数と検収基準
5. 監視、障害対応、復旧の範囲
6. 利用量に応じて増える費用
7. 公開後の改善回数と変更管理

「一式」の中身をこの粒度まで分ければ、安い見積もりに何が含まれていないかが分かる。反対に、初期段階で不要な本番要件も見つけやすい。

AIエージェントの開発費用を下げる一番の近道は、単価交渉ではない。最初の業務範囲を狭くし、権限を低く保ち、合格条件を明確にすることだ。そのうえで、価値が確認できた部分だけ本番仕様へ進める。

株式会社Atsumellでは、対象業務の分解から権限、連携、評価、運用までを整理し、AIエージェントの要件定義と開発を支援している。見積もりの前提を揃えたい場合は、お問い合わせフォームから相談してほしい。

関連記事

• AIエージェントの開発現場から見えた「動くもの」の条件
• AIエージェントの導入、最初の一歩はどこから？
• AI開発で要件のトレーサビリティを始める