AIエージェント開発の費用の決まり方｜初期と月額の内訳と、見積のあとで増えやすい項目

「いくらかかりますか」に一律の答えが出ない理由

AIエージェントの開発費は、同じ業務名でも数倍の幅が出ます。「請求書処理のエージェント」と一言で言っても、扱う書式が3種類か30種類か、承認の経路が1段か3段か、つなぐシステムが1つか4つかで、作る量が変わるためです。相場として出回る金額を先に置いてしまうと、自社の条件と合わない数字を基準に交渉することになります。

代わりに使えるのは、費用が何で動くかを知っておいて、届いた見積の数字を自社の条件で検算することです。件数と接続先と例外の数が分かっていれば、「この金額はどの前提で計算されているか」を質問できます。この記事では金額の目安は示さず、費用の決まり方と、見積を比べるときの形を扱います。開発そのものの進め方は AIエージェント開発の進め方にまとめています。

費用を動かす5つの要素

見積の金額は、次の5つでほぼ決まります。どれも発注側が事前に数えられるものです。

動かす要素	費用が増える条件	見積を頼む前に自社で数えること
対象業務の数	判定の分かれ道が業務ごとに別にある	対象業務ごとの分岐と例外の種類
つなぐシステムの数	接続先が多い、書き込みを伴う	システム名と、読み取りか書き込みかの別
権限の扱い	部門ごとに見える範囲が違う	誰の名義で動かすか、記録を残す範囲
評価と改修の頻度	書式や規程が頻繁に変わる	直近1年で仕様が変わった回数
運用の当番	夜間・休日も動かす、応答時間が短い	稼働させたい時間帯と、一次受けの担当

対象業務の数は、業務の個数よりも判定の分かれ道の数で効きます。2業務目からは共通の仕組みを流用できますが、判定基準と例外の扱いは業務ごとに作り直しになるためです。1つの業務でも、部門ごとに判断が違えば実質的に複数業務分の作業になります。

つなぐシステムの数は、接続1つごとに認証、データ形式の変換、相手側が止まったときの扱いが必要になります。データを読むだけの接続と、システムへ書き込む接続では、確認と戻し方の設計が入る分だけ後者が重くなります。APIが用意されているか、CSVの受け渡しになるかでも工数が変わります。

権限の扱いは、全社共通の1アカウントで足りるなら小さく収まります。部門ごとに見える範囲を再現する、操作の記録を残して後から追えるようにする、といった条件が入ると、設計と検証の両方が増えます。この条件は情報システム部門の審査で後から出てくることが多く、見積の段階で聞いておく項目です。

評価と改修の頻度は、稼働後の費用に直結します。書式や社内規程が年に何度も変わる業務では、改修の依頼が定期的に発生します。直近1年で仕様が何回変わったかを数えておくと、月額をどう組むかの判断材料になります。

運用の当番は、平日の日中だけ動かすのか、夜間や休日も含むのかで体制が変わります。止まったときに何分以内に気づき、誰が一次対応するかを決めると、その分が月額に入ります。

初期費用の内訳

初期費用は、実装だけでなく次の4つに分かれます。実装以外の割合が大きいことが多く、そこが薄い見積は着手後に増えます。

工程	含まれる作業	社内から出るもの
要件定義	手順の言語化、対象範囲の確定、承認経路の決定	業務担当者の打ち合わせ時間
接続	認証の設定、データ形式の変換、権限の割り当て	接続先の仕様確認と、アカウントの発行
評価用データの用意	正解の形の定義、判定の集計	過去の処理結果を集めて正解を付ける作業
業務側の受け入れ確認	実際の処理での試行、修正の反映	現場の担当者が実データで確かめる時間

要件定義と接続は、外から見えにくい分だけ見積で圧縮されがちです。要件定義が薄いと、実装が始まってから「この場合はどう扱うか」を決める打ち合わせが増えます。接続は、既存システムの仕様書と実際の挙動が違うことがあり、調べる工数が別に必要になります。

評価用データの用意は、社内でしか行えない作業が含まれます。過去の処理結果を集め、どれが正しい出力かを付ける作業は、業務を知っている人の手が要ります。ここを誰が担当するかが見積に書かれていないと、着手後に社内の予定外の作業として出てきます。

業務側の受け入れ確認は、開発側のテストとは別です。開発側が用意したデータでは通っても、現場が持ち込む実際のデータで止まることがあります。この工程を見積に入れていない場合、稼働の判断が誰にもできないまま納品を迎えます。

月額の内訳

稼働してからは、次の4つが毎月かかります。開発費とは別の予算として立てておく項目です。

費目	何で金額が決まるか	契約前に確認すること
モデルの利用料	処理件数と、1件あたりに渡す情報量	誰の名義の契約で、誰が支払うか
監視	見る対象の数と、気づくまでの時間の条件	止まったとき誰にどう通知が届くか
改修	依頼の頻度と、1回あたりの作業量	月額に含む作業時間と、超過分の単価
問い合わせ対応	利用者の人数と、受け付ける時間帯	一次受けが自社か委託先か

モデルの利用料は件数に比例します。検証のあいだに1件あたりいくらだったかを記録しておくと、対象を広げたときの金額を自分で計算できます。契約の名義は確認しておく項目で、委託先の名義でまとめられていると、契約が終わるときに移す作業が発生します。

改修の費目は、月額に一定時間を含める形と、都度見積の形に分かれます。仕様が頻繁に変わる業務では、都度見積だと1回ごとに見積と承認と着手待ちの時間が挟まります。この手続き分の時間が費用に見えないまま積み上がる点は、AI開発は外注か内製かで工程ごとに分解しています。

初期費用は4工程で一度だけ、月額は4費目が稼働後にかかり続ける。色は社内の時間が入るかどうかで分けている。

見積のあとで増えやすい項目

金額が動くのは、見積書の欄の外にある作業です。次の5つは、着手してから「これは範囲外です」と確認されることが多い項目です。

増えやすい項目	どこで表に出るか	発注前に決めておくこと
既存システム側の改修	必要なデータが今の形では取り出せないと分かったとき	改修が要る場合の担当と費用の出どころ
権限とアカウントの設計	情報システム部門の審査に入ったとき	審査の項目と、資料を誰が書くか
例外処理の作り込み	実データを流し始めたとき	対象外にする条件と、人へ回す手順
元データの整備	参照する資料が古い、形式がばらばらだと分かったとき	整える範囲と、担当する部署
担当者の教育	稼働の直前に、使う人への説明が必要になったとき	説明会と手順書を誰が用意するか

既存システム側の改修は、エージェントの費用としては見積に出てきません。必要なデータが画面にしか出ない、出力形式が固定で変えられない、といった制約が分かった時点で、既存システムの保守を請けている別の会社への依頼になることがあります。この場合は費用も期間も別で動きます。

権限とアカウントの設計は、情報システム部門の審査で条件が追加されると作業が増えます。接続に使うアカウントの分け方、操作の記録の残し方、外部へ出るデータの範囲が典型です。審査の存在自体を見積の前提に入れていない提案もあるため、社内の手順を先に伝えておきます。

例外処理の作り込みは、実データを流してから件数が見えます。想定より例外が多い場合、すべてを自動で処理しようとすると作業量が膨らみます。対象外にする条件を決めておき、そこに当たったら人へ回す形にすると、追加分を抑えられます。

元データの整備は、参照する資料の状態で決まります。判断の根拠になる規程や台帳が古いままだと、エージェントの出力もそれに従います。整える作業は社内でしか行えないため、範囲と担当を決めておきます。

担当者の教育は、稼働の直前に浮上します。エージェントの出力をどこまで信用してよいか、おかしいと思ったときにどうするかを、使う人が分かっていないと運用が止まります。手順書と説明の場を誰が用意するかを決めておきます。

複数社の見積を比べる形

金額の総額だけが並んだ見積は比べられません。依頼する段階で、次の3つの形を全社に指定すると、同じ枠で並べられます。

工程ごとに分けてもらう。 要件定義、実装、接続、評価と受け入れ確認の4区分で、それぞれ何人が何か月かかる想定かを出してもらいます。一式の金額だけの見積は、どこを削れば安くなるかも、どこが薄いかも判断できません。区分に分かれていれば、要件定義が極端に短い提案や、接続の調査工数が入っていない提案が見えます。

改修の単価と依頼手順を契約前に決める。 稼働後の改修は、月額に含む作業時間、超過分の時間単価、依頼してから着手までの目安の3点で書いてもらいます。単価だけ決めても、依頼から着手までが数週間かかる形では、業務の変更に追いつきません。

運用の当番と対応時間を書いてもらう。 対応する時間帯、止まったときの連絡先、一次対応を自社と委託先のどちらが持つかを明示してもらいます。ここが空欄のまま安く見える見積は、稼働後に社内の誰かが当番を持つ前提になっています。

そのうえで、自社で作るか既製ツールを使うかをまだ決めていない場合は、AIエージェントは自作か既製ツールかで先に線を引いてから見積を集めると、比較の枠が揃います。

判断は12か月の合計で行う

初期費用の安い提案が、社内から出す時間と月額を足すと高くなることがあります。逆に初期の金額が大きい提案に、要件定義と接続の作業が十分に含まれていて、社内の負担が小さいこともあります。

比べるのは、初期費用、12か月分の月額、そしてその期間に社内から出す時間の合計です。社内の時間は、打ち合わせ、評価用データの用意、受け入れ確認、稼働後の問い合わせ対応を時間で見積もり、社内の単価を掛けて金額に直します。この合計と、同じ業務を今のやり方で処理し続けた場合の費用を並べると、投資として成立するかを判断できます。削減額の出し方と判断の基準は AI導入の効果測定と効果検証で扱っています。

金額が見合わないときは、対象業務の範囲を狭めてもう一度見積を取り直す方法があります。件数の多い上位の処理だけを対象にすると、初期費用と評価の作業がまとめて減ります。範囲を狭めた案と元の案を並べて、どちらが合計で成立するかを見ます。

まとめ：金額の決まり方から見積を検算する

同じ業務名でも作る量が違うため、相場の金額を基準に置かない。費用の決まり方から自分で検算する
費用は対象業務の数、つなぐシステムの数、権限の扱い、評価と改修の頻度、運用の当番の5つで動く
初期費用は要件定義、接続、評価用データの用意、業務側の受け入れ確認に分かれる。実装以外が薄い見積は着手後に増える
月額はモデルの利用料、監視、改修、問い合わせ対応の4費目。改修は月額に含む時間と超過の単価を分けて確認する
見積の外で増えるのは、既存システム側の改修、権限とアカウントの設計、例外処理、元データの整備、担当者の教育
比べるときは工程ごとの区分、改修の単価と依頼手順、運用の当番と対応時間を全社に同じ形で出してもらう
判断は初期費用と12か月分の月額に、社内から出す時間を金額へ直して足した合計で行う

Augueでは、AIエージェントの開発と、稼働後に社内の担当者が改修を続けられる状態までの支援を行っており、対象業務の絞り込みや工程ごとの工数の見立てから一緒に整理しています。自社の条件で費用がどう決まるかを相談したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

検証（PoC）だけを先に依頼する場合、費用はどう見ればよいですか？

検証費が本番の開発費に充当されるのか、別枠で消えるのかを先に確認します。充当されない形でも問題はありませんが、その前提で本番の金額を足して判断する必要があります。あわせて、検証で作ったものを本番でそのまま使うのか作り直すのかを聞きます。作り直す前提なら、検証費は判断材料を買う費用として扱います。

既製のAIツールの月額と、開発した場合の費用はどう比べればよいですか？

既製ツール側の金額に、初期設定の作業、既存システムとつなぐための作業、利用人数が増えたときの追加分を足してから比べます。開発側は初期費用を利用予定の月数で割り、月額に足した金額で並べます。どちらも社内から出す確認作業の時間を同じ単位で足さないと、月額の安いほうが有利に見えます。

費用を抑えたいとき、最初に削ってよいのはどこですか？

対象業務の範囲です。扱う書式や申請の種類を件数の多い上位に絞ると、実装と評価の両方が減ります。逆に削らないほうがよいのは、評価用データの用意と、業務側が実際の処理で確かめる工程です。ここを省くと稼働してから誤りが見つかり、修正の費用と手戻りの時間が後から出ます。

支払いの時期はどう決まりますか？

着手時と検収時に分ける形が一般的で、工程が長い場合は工程ごとの分割になります。確認しておくのは、何をもって検収とするかです。合格ラインの判定結果を検収の条件にしておくと、基準に届かないまま支払いだけが進む状態を避けられます。月額の費用がいつから発生するかも同時に決めます。