連載「システム見積書を読む技術」の第13回である。これまで一式見積、人月単価、要件定義費、保守費、追加費用などを扱ってきたが、本回はAI開発に特有の見積の読み方を整理する。生成AIや機械学習を組み込む案件が増えるなかで、従来のシステム開発と同じ感覚で見積を読むと、前提の違いを見落としやすい。
AI開発の見積が通常の開発と異なるのは、「機能が動くかどうか」だけでなく、「どのデータを使い」「どの程度の精度を目指し」「検証(PoC)をどこまで行うか」で費用が大きく変わる点である。これらは見積書の費目には表れにくく、本文の前提や但し書きに埋もれていることが多い。本記事は、AI開発の見積で確認すべき固有の費目と、抜けやすい項目を整理する。
結論:AI開発の見積は「データ・精度・PoC」の前提で読む
- AI開発の見積は、機能の有無よりも、学習データ整備、目標とする精度の扱い、PoCと本番の境界で内容が決まる。
- 「AI機能 一式」とだけ書かれた見積は、データ整備が含まれるか、精度をどう合意するか、PoC費が別途かを分けて確認する。
- 相見積もりは、データ、精度の前提、PoCの範囲をそろえて初めて比較できる。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| データ整備 | 収集・前処理・アノテーションの扱い | 発注側作業か開発側作業か |
| 精度の扱い | 目標値と未達時の対応 | 保証か努力目標かを確認 |
| PoC費 | 検証段階の費用と位置づけ | 本番開発と分かれているか |
この連載での位置づけ
- 前に読む記事:連載第12回:開発会社への20問
- 関連して読む記事:連載第8回:クラウド・API費用
- 比較表で整理する:連載第11回:比較表
なぜAI開発の見積は通常の開発と読み方が変わるのか
通常のシステム開発では、要件が決まれば「画面を何枚作るか」「帳票を何種類出すか」といった単位で工数を見積もりやすい。完成すれば、決められた通りに動くかどうかで検収を判断できる。
一方でAI開発は、「決められた通りに動く」という考え方だけでは捉えきれない。AIの出力は入力データの質に左右され、同じ仕組みでもデータが変われば結果が変わる。さらに、AIの「精度」は0か100かではなく、幅を持った結果になる。そのため、見積の前提として「どのデータで」「どの程度の出力品質を目指し」「それをどう確認するか」を決めておかないと、完成の基準そのものが曖昧になる。
この違いを理解せずに見積金額だけを比較すると、安く見えた見積が「データ整備は発注側で行う前提」だったり、「PoCまでの費用しか含まれていない」だったりして、後から前提のずれが表面化しやすい。
AI開発に特有の費目を分けて読む
AI開発の見積を読むときは、次の費目を分けて確認すると、前提のずれに気づきやすい。
| 費目 | 主な内容 | 確認したいこと |
|---|---|---|
| データ整備 | 収集、前処理、ラベル付け(アノテーション) | 誰が担うか、件数の前提は |
| モデル構築・検証 | 学習・調整、評価 | 評価の基準と回数 |
| PoC(実証) | 小規模での効果検証 | 本番開発と分かれているか |
| 本番実装・統合 | 既存システムとの連携 | 連携先と本数の前提 |
| 運用・再学習 | 稼働後の監視、精度維持 | 保守費に含まれるか別途か |
これらは一体で「AI開発一式」と書かれることもあれば、フェーズごとに分かれていることもある。どちらの場合も、各費目に「何が含まれ、何が発注側作業か」を確認することが、前提をそろえる出発点になる。
学習データの整備は誰が担うのか
AI開発の費用で見落とされやすいのが、学習・検証に使うデータの整備である。AIは、与えられたデータをもとに判断や生成を行う仕組みであるため、データの質と量が出力品質を大きく左右する。このデータ整備には、一般に次のような作業が含まれる。
- 既存の業務データやドキュメントの収集・抽出
- 表記ゆれや欠損の補正などの前処理(クレンジング)
- 正解づけ(アノテーション、ラベル付け)
- 個人情報・機密情報の扱いの整理
これらを開発会社が担うのか、発注側が担うのかで、費用も期間も変わる。見積に「データは貴社からご提供ください」と但し書きがある場合、データの抽出や整形の負担は発注側に残る。逆に開発側で整備する場合は、その工数が見積に反映されているはずである。「データ整備は誰が、どの粒度で行うのか」を発注前に確認しておくと、相見積もりの前提がそろう。
「精度」をどう見積に書くか
AI開発で最も誤解が生じやすいのが「精度」の扱いである。発注側は「精度◯%を保証してほしい」と考えがちだが、精度はデータや運用条件に依存するため、開発前の段階で具体的な数値を断定的に保証することは難しい場合が多い。
そこで見積や提案では、精度を次のいずれの位置づけで扱っているかを確認したい。
| 位置づけ | 意味 | 注意点 |
|---|---|---|
| 目標値(努力目標) | この水準を目指して開発する | 未達時の扱いを別途決める必要がある |
| 評価基準 | どう測るかの取り決め | 評価データと指標の合意が前提 |
| 検収条件 | 検収に用いる合格ライン | 評価方法とセットで合意する |
重要なのは、精度の「数値」だけでなく、「どのデータで」「どの指標で」「何回測って」判断するかという評価の枠組みである。これが曖昧なまま「精度◯%」とだけ書かれた見積は、達成・未達の判断でずれが生じやすい。未達だった場合の追加調整が、見積の範囲内か別途費用かも、発注前に確認しておきたい。
PoC費は本番開発と分けて読む
AI開発では、いきなり本番システムを作るのではなく、小規模で効果を検証するPoC(Proof of Concept、概念実証)を先に行うことが多い。PoCは「この課題にAIが有効か」「目指す品質に届きそうか」を、限定したデータと範囲で確かめる段階である。
見積を読むときは、提示された金額がPoCまでなのか、本番開発・運用まで含むのかを必ず分けて確認したい。PoCと本番では、対象データの範囲、統合する既存システム、運用の作り込みが大きく異なるため、費用の桁が変わることもある。
- PoCの見積:限定データ・限定範囲での検証費用
- 本番開発の見積:実データ、既存システム連携、運用設計を含む費用
PoCの結果次第で本番開発に進むかを判断する、という段階的な進め方をとる場合、PoCの見積と本番の概算を分けて提示してもらうと、投資判断がしやすい。PoCから本番へ移す際の論点は、AI開発のPoCから本番運用への移行でも整理している。
運用・再学習の費用は保守費に含まれるか
AIは、本番稼働後も「作って終わり」にはなりにくい。利用が進むとデータの傾向が変わったり、業務が変化したりして、出力の品質が当初の想定とずれていくことがある。これに対応するため、稼働後に出力を監視し、必要に応じてデータを追加して再学習・再調整する運用が発生することがある。
この運用・再学習の費用が、保守費に含まれるのか、別途なのかは見積で割れやすい。連載第4回で扱った保守費の考え方と同様に、AI開発でも「稼働後に何をどこまで対応するか」を範囲として確認したい。とくに、クラウド上のAIサービスや外部APIを使う場合、その利用料は連載第8回で扱ったように月額で継続的に発生する。費用全体のROIの見方は、AIエージェント導入の費用とROIも参考になる。
AI開発の見積で抜けやすい項目
AI開発の見積では、従来の開発と同じ感覚で読むと見落としやすい費目がいくつかある。これらは「開発費」にも「AI機能 一式」にも含まれないことがあるため、項目として押さえておきたい。
- データの収集・前処理・ラベル付け(アノテーション)の工数
- 学習・検証に使うデータの個人情報・機密情報の取り扱い整理
- モデルの評価に用いる評価用データの準備
- 生成AIや機械学習のクラウドサービス・API利用料(月額で継続)
- 稼働後の出力監視と、品質がずれたときの再調整・再学習
- 不適切な出力を防ぐためのガードレールや確認の仕組み
これらが見積のどこにも見当たらない場合は、「この作業は誰が、どの費目で担うのか」を確認しておきたい。とくにデータ整備と稼働後の再学習は、AI開発の費用に占める割合が小さくないため、含む・含まないを明確にしておくと、相見積もりの前提がそろう。
相見積もりをAI開発でそろえるときの注意
AI開発で相見積もりを取る場合、各社の前提がいっそうばらつきやすい。同じ「AIで問い合わせ対応を自動化したい」という依頼でも、A社はPoCまで、B社は本番運用まで、C社はデータ整備を発注側作業として見積もる、というずれが起きる。これを金額だけで並べると、安い見積が「含む範囲が狭いだけ」のことがある。
AI開発の相見積もりをそろえるには、最低限、次の前提を共通で示しておきたい。
| そろえる前提 | 示しておきたいこと |
|---|---|
| データ | 提供できるデータの有無・件数・整備の担い手 |
| 精度 | 目指す出力品質と、どう測るかの考え方 |
| 段階 | PoCまでか、本番運用まで含むか |
| 連携 | 既存システムとの連携の要否と本数 |
| 運用 | 稼働後の監視・再学習を誰が担うか |
これらを文章で共通に渡すと、各社の見積が同じ土俵に乗りやすくなる。前提のそろえ方は、連載第16回でも扱う。
GXOに相談する前に整理するとよい情報
- AIで解決したい課題と、対象とする業務・判断の範囲
- 学習・検証に使えるデータの有無、件数、フォーマット、機密度
- 期待する出力品質と、「どうなれば成功とみなすか」の基準案
- PoCで確かめたいことと、本番化を判断する条件
- 連携したい既存システムと、稼働後の運用を担う社内体制
これらを整理してから見積を取ると、データ整備・精度・PoCの前提がそろい、各社の比較がしやすくなる。完璧な要件は不要だが、データの状況と「成功の基準」の素案だけは持っておきたい。
参考にした外部観点
見積を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してほしい。AI開発では、契約形態や責任分界に加えて、データの扱いと安全性の前提を見積金額より前にそろえる必要がある。
- IPA「情報システム・モデル取引・契約書」:請負・準委任、成果物、検収、責任分界を確認する際の参考になる。AIのように完成の基準が定めにくい案件ほど、契約形態の整理が前提になる。
- 経済産業省「AI事業者ガイドライン」:AIを開発・利用する際に配慮すべき観点を確認する際の参考になる。データの扱いや安全性を見積条件に反映する土台になる。
- 独立行政法人情報処理推進機構(IPA):情報セキュリティやシステム開発に関する公的資料を確認する際の参考になる。
- 自社の見積比較では、PoC費と本番費の分離、学習データ件数、評価指標、再学習の頻度、クラウド・API月額、連携システム本数など、仮でも数字や前提を置いて各社の条件をそろえる。
関連記事
よくある質問
Q1. AI開発の見積で「AI機能 一式」とだけ書かれていたら、どう読めばよいか。
A. 金額の前に範囲を分解する。データ整備が含まれるか(発注側作業か)、精度をどの基準で合意するか、PoCまでなのか本番運用まで含むのか、再学習が保守に入るのか別途か、を確認する。これらが但し書きや前提に埋もれていることが多いため、項目ごとに「含む・含まない」を聞き出すとよい。
Q2. 「精度◯%を保証」と書かれた見積は信頼できるか。
A. 数値そのものより、その精度を「どのデータで」「どの指標で」「何回測って」判断するかという評価の枠組みがあるかを見る。精度は運用条件やデータに依存するため、評価方法とセットで合意されていない数値は、達成・未達の判断でずれが生じやすい。未達時の対応が見積の範囲内かも確認したい。
Q3. PoCはやらずに、いきなり本番開発を依頼してもよいか。
A. データの状況や課題によっては可能だが、AIが有効かを確かめないまま本番規模で投資すると、後戻りの負担が大きくなることがある。限定範囲で効果と品質を確かめてから本番判断に進むほうが、投資の見通しを立てやすい。PoC費と本番概算を分けて提示してもらうとよい。
Q4. 稼働後に精度が落ちた場合、追加費用はかかるか。
A. データの傾向や業務の変化により、稼働後に出力品質が当初の想定とずれることはある。その際の監視・再学習・再調整が保守に含まれるか別途かは会社によって異なる。発注前に「稼働後の精度維持をどこまで対応するか」を範囲として確認しておくと、運用後の費用感が明確になる。
AI開発の見積・相見積もりを整理しませんか
GXOでは、AI開発を含むシステム開発の見積書、相見積もり、PoCの進め方について、発注前の整理をご支援します。学習データの扱い、精度の合意方法、PoCと本番の境界、運用・再学習の費用まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。
