「AI開発 費用相場」で検索すると、どのページにも表が出てきます。2026年9月時点で各社が公開している相場をいくつか並べてみると、構想・要件定義が40万〜200万円、PoCが100万〜500万円、実装が500万〜5,000万円、運用保守が月額50万〜200万円。数字は媒体によって多少ずれますが、幅の大きさはどこも似ています。

実装だけで10倍の開きがあります。相場が定まっていないから、ではないと思っています。「AI開発」という同じ言葉の下に、10倍違う買い物が並んでいるということです。

だから、同じ要件書を数社に配ると、返ってくる金額はきれいにばらつきます。単価の差ではありません。差の大半は、片方の見積書に項目として立っていて、もう片方には立っていない作業から出ています。

そして、書かれていない作業が消えることはありません。あとから追加見積もりとして戻ってくるか、発注側の工数として自社の誰かの残業に変わるかのどちらかです。金額の大小より先に見る場所は、そこでした。

相場表の幅は、そのまま見積書の幅になっている

公開されている相場記事は、内訳の比率まで書いているものがあります。人件費が全体の40〜50%、データの準備と前処理が20〜30%、GPUやクラウドのインフラ費が15〜25%、テストや文書化が5〜10%、という置き方です。人月単価のほうは、データサイエンティストで月額80万〜150万円、機械学習エンジニアで月額70万〜120万円という数字が出ています。いずれも2026年9月時点の公開情報で、各社が自社の実績として出しているものなので、業種や体制が違えば当然ずれます。

この幅を「相場が分からない」と読むと、たぶん見積書も読めません。桁が動いているのは、中身が桁の分だけ違うからです。既存の生成AIのAPIを業務フローに載せるだけの案件と、自社の実データでモデルを作る案件と、現場の設備や既存の基幹システムに接続する案件。この3つはどれも「AI開発」と呼ばれていますが、必要な作業も、失敗する場所も共通していません。

見積書を読むというのは、相手がこの幅のどこを想定して書いたのかを逆算する作業です。金額そのものではなく、その金額に何の値段が入っているかを見ます。

PoCと本開発と運用は、別の買い物

AI開発をアセスメント、PoC、開発、追加学習の4段階に分け、段階ごとに予算を分けて判断を挟むことを示した流れ図

経済産業省が2018年に公表した「AI・データの利用に関する契約ガイドライン」では、AI開発をアセスメント、PoC、開発、追加学習の4段階に分け、段階ごとに検証と合意を挟みながら進める「探索的段階型」の開発方式が提唱されています。最初に要件を固めきるウォーターフォールとは前提が違います。やってみないと分からない部分があることを、契約の形のほうで受け止める組み立てです。

ところが見積書は、しばしば1本の金額で届きます。PoCから運用開始までが一続きの合計として書かれていて、途中に判断の切れ目がありません。この形の何が危ないかというと、予算が技術検証の側に吸われることです。

PoCで確かめるのは、その処理が実際のデータで成立するかどうか。本開発以降で確かめるのは、それが業務に乗って回るかどうかです。目的が違うのに財布が一つだと、高い確率で前半に寄ります。作る側にとって、技術の検証はそれ自体が面白いからです。半年後に、動くことは分かったが次の予算がない、という報告が上がります。この財布の分け方は、MVP開発で撤退ラインと予算を先に決めるという話と同じところに立っています。

実務的には、PoCの見積書を受け取った時点で「何が確かめられたら合格なのか」を先方と紙に書いておくのがいちばん効きます。合格条件の無いPoCは、期間が来たときに「もう少しやれば伸びそうです」で延長されます。

金額が動くのは、データの手前と既存システムの境目

見積書の中で、あとから膨らむ項目はだいたい決まっています。並べると次のようになります。

見積書の項目

よく書かれている形

その場で聞くこと

データの前処理

「データ整備」一式

どの状態のデータを前提にしているか。整えるのはどちら側か

学習データの用意

記載なし、または発注者支給

必要な件数。アノテーションの単価と担当

既存システムとの接続

「連携開発」一式

接続先の数。仕様書があるか。相手側ベンダーの工数は誰が持つか

精度の合格ライン

記載なし

何の指標で何%か。どの素材で、誰が測るか

クラウド費用

実費精算

学習時と推論時の見込み額。誰の名義で契約するか

運用保守

別途見積

監視の範囲。再学習の頻度。対応時間帯

いちばん読みにくいのが最初の2行です。相場記事でも、データの準備と前処理は開発費の20〜30%を占めるとされ、データクリーニングだけで全工数の30〜40%という記載もあります。画像認識のアノテーションは1枚あたり10〜100円という単価が出ていて、枚数を掛ければそれ単独で数百万円になります。

それでも見積書では一行です。理由は単純で、見積もりの時点では相手もデータを見ていないからです。「データはあります」という発注側の言葉が、実際には部署ごとに書式の違うExcelだったり、命名規則が3回変わっているファイルサーバーだったりする。ここは、見積もりの前に実データを数十件見せて工数を出し直してもらうほうが、結果として安くなります。

接続の側も同じです。既存システムのどこから何を受け取るのかが決まっていないと、後段の設計が固まりません。出力の形が設計に染み出すので、接続先が1つ増えるのと、接続の仕様が途中で変わるのとでは、後者のほうがはるかに高くつきます。

精度の合格ラインが無い見積書は、検収が終わらない

検収の合格ラインを指標、合格値、測る素材、測る人の4つで決めることを示した図

見積書で最も見落とされるのは、書かれていない一行です。何をもって完成とするか。

AI開発では、ここが通常のシステム開発と決定的に違います。契約ガイドラインをめぐる解説では、訓練データに統計的なバイアスが含まれることを避けられないため、未知のデータに対する性能保証は原理的に困難だと指摘されています。仕様どおりに動くかどうかではなく、見たことのない入力にどう振る舞うかが問われるからです。

ただ、その解説は同時に、既知の評価用データに対する性能であれば保証は技術的に可能で、一定の基準への到達を検収項目にできる、とも述べています。つまり合意すべきなのは「あらゆる素材で何%」ではなく、「この評価データで何%」のほうです。

決めるのは4つです。ひとつめは指標で、認識率なのか、再現率なのか、業務上の手直し時間なのか。ふたつめが合格値。みっつめが、それを測る素材を誰がいつ用意するか。よっつめが、測って合否を宣言するのが発注側なのか受注側なのかです。

この4つが決まっていない案件は、検収の場で「体感として使えない」と「仕様は満たしている」が正面からぶつかります。どちらも嘘ではないので、決着しません。そして揉めている間、開発チームは次の工程に進めないまま張り付きます。その滞留は、どこかの見積もりに必ず戻ってきます。

素材の選び方にも注意が要ります。ベンチマークの数字と、実際の業務素材での結果は一致しません。音声認識でいえば、公称スコアの高いエンジンが自社の番組素材ではそのまま使えないことがあります。エンジンごとの得手不得手を実素材で比べた話は別に書きましたが、要点は、検収に使う素材は必ず自分たちの現場から出すということです。

契約の形も連動します。完成義務を負う請負にするのか、成果完成型を含む準委任にするのか。ガイドラインの議論では、段階ごとに契約類型を選び直す前提が置かれています。見積書の表紙に契約類型が書かれていなければ、そこも聞く対象です。

業務ルールを言語化する工数は、どちら側に載っているか

同じ機能でも、業務知識がどちらにあるかで見積もりの前提はまるで変わります。

「字幕を自動生成する」は一行で書けます。実際の納品物は、局ごとの1行あたりの文字数、改行位置の決め方、句読点の扱い、話者が変わるときの記号、画面上のテロップを避ける位置調整まで決まっています。その多くは規格書に載っていません。現場の運用として人の中に溜まっているだけです。私たちが放送局向けの機能を作るときに最も時間を使っているのも、コードではなくここでした。

この言語化には工数がかかります。問題は、それが見積書のどちら側に載っているかです。受注側に載っていれば、ヒアリングとルール整理の工数として金額に出ます。載っていなければ、発注側の担当者が本業の合間に書き出すことになります。書き出せないまま進むと、出てきたものが現場のルールに合わず、作り直しが発生します。

見積書で確かめるのは、ヒアリングとレビューの回数が前提として書かれているかどうか。それと、「発注者にご用意いただくもの」の欄に何が並んでいるかです。ここが空欄の見積書は安く見えますが、抜けているのではなく、発注側に付け替えられているだけのことがあります。やり直しの回数が費用を決めるという構造は、内製でも外注でも変わりません。

運用の費用は、納品の日から始まる

初期開発費だけで予算を組むと、翌年度に困ります。公開されている相場では、運用保守は月額50万〜200万円、あるいは初期開発費の年15〜25%(媒体によっては10〜20%)といった置き方がされています。桁の幅が大きいのは、保守という言葉が指す範囲が会社ごとに違うからです。

AI固有なのは、放っておくと精度が落ちることです。番組のフォーマットが変わる。テロップのデザインが変わる。取り扱う商品の種類が増える。入力側が変わった瞬間、学習時の前提とずれます。監視して気づく仕組みと、気づいたあとに再学習する費用。この2つが保守の範囲に入っているかは、契約前に確かめるところです。

インフラの契約名義も見ておくとよいと思います。クラウドを開発会社の名義で契約したまま運用に入ると、あとで移管の作業が別途発生します。素材そのものが公開前の機密である場合は、オンプレミスで構成する前提が初期の設計判断になるので、これは運用費ではなく最初の見積もりに効いてきます。

見積書を受け取った日に聞くこと

最後に、その日のうちに投げられる質問を並べます。どれも金額を値切る質問ではなく、金額の中身を確定させる質問です。

  • この金額はどの段階までですか。PoCと本開発と運用は、それぞれいくらで、どこで判断を挟みますか
  • PoCは何が確かめられたら合格ですか
  • 前提にしているデータは、どの状態のものですか。整える作業はどちら側の工数ですか
  • 完成の判定は、どの指標で何%ですか。測る素材は誰が用意して、誰が合否を宣言しますか
  • 業務ルールのヒアリングとレビューは、何回分が入っていますか
  • 運用保守の範囲に、監視と再学習は入っていますか。クラウドの契約は誰の名義ですか

この6つに即答が返ってくる見積書は、金額が高くても後から動きにくいはずです。逆に、「そこは要件次第です」が続くなら、その部分はまだ誰も値段を付けていないという意味になります。

冒頭の10倍の幅に戻ります。あの幅は、相場が曖昧だから生まれたものではありませんでした。何を含めるかが案件ごとに違うから生まれています。手元にある見積書は、その幅のどこに置かれているでしょうか。そして、置かれていない作業は、来期の誰の時間として現れるでしょうか。