AI PoCはいくらかかる？人月よりデータ準備・評価・連携で分解

AI PoCの費用は、公開例だけでも月額15万円の小規模支援から、300万円からの開発型PoCまで幅がある。ただし、この両者を平均して「相場は150万円前後」とするのは誤りだ。課金単位も、含まれる作業も違う。

予算を作るときは、データ準備、試作、評価、既存システム連携、進行管理、外部サービス実費へ分ける。画面数やエンジニアの人月だけで比べると、AI特有の評価とデータ作業が後から追加されやすい。

公開価格は範囲を付けて読む

2026年9月13日に確認した公開例は次の通りだ。

公開サービス例	表示価格	公開されている主な範囲	同じ表へ平均できない理由
株式会社SOARIG「AI推進室」スタンダード	15万円／月	月20ポイント、小規模PoCを含む伴走支援	月額・ポイント制で、完成したPoC一式の固定価格ではない
AI革命株式会社「AI・システム受託開発」PoC	300万円から（税別）	課題と検証内容、簡易要件、設計・開発、検証環境、結果整理、本開発提案	開発型の開始価格で、クラウドや外部API等は別途になり得る
特許庁のAI PoCモデル契約	金額例なし	固定額または人月・工数による算定方法、支払、データ関連費用	契約ひな形の空欄は実際の市場価格ではない

公開価格は「安い会社」「高い会社」を決める資料ではない。月額支援で何ポイント使えるか、固定価格にどの成果物が含まれるか、外部実費が別かを確認するための例だ。

AI革命の公開価格にはPoCの設計・開発と結果整理が含まれる一方、本番開発は個別見積もりとされる。SOARIGの月額プランは、ヒアリング、PoC、プロンプト作成などをポイントで依頼する仕組みである。どちらが得かは、必要な成果物を決めるまで比較できない。

PoC費用を6つに分ける

見積依頼の前に、次の表へ数量と単価を入れる。金額が分からない行は0円にせず、見積回答待ちとする。

費目	数量の例	単価・実費	小計	成果物・完了条件
1. 課題と検証範囲	ヒアリング回数、対象業務数			検証仮説、対象外、成功・中止条件
2. データ準備	文書数、ページ数、正解データ件数			利用可能なデータ、加工結果、版
3. 試作	画面、API、処理フロー、モデル候補			動く試作、ソース、設定、設計メモ
4. 評価	テスト件数、反復回数、人の確認件数			指標、閾値、全結果、失敗例
5. 既存システム連携	認証、DB、API、ログの接続数			接続範囲、権限、エラー処理
6. 進行管理と実費	会議、レビュー、クラウド、外部API			議事、課題、利用量、請求根拠

PoC予算 = 1〜6の小計 + 予備費 とする。予備費は不明な費目を隠すためではなく、合意した変更へ使う。見積回答待ちの行を予備費へまとめない。

データ準備は「提供するだけ」では終わらない

特許庁のAI PoCモデル契約は、検証前の作業として、生データの取得方法を試すことや、正解データを作ることがあり、役割と費用を契約で明確にする必要があると説明している。データの種類や量によってサーバー費用が増える場合も挙げる。

発注側が「社内文書はある」と考えていても、そのまま評価や検索へ使えるとは限らない。重複、古い版、個人情報、画像PDF、表、アクセス権限を確認し、PoCへ入れる範囲を決める作業が発生する。

見積では、誰が次を行うかを分ける。

• データの抽出と利用許可の確認
• 個人情報や機密情報の除去
• 文字抽出、分割、形式変換
• 正解または許容回答の作成
• テスト用と調整用データの分離
• PoC終了時の返却・削除

自社でできる作業は外注費を減らせるが、社内工数が0になるわけではない。担当者の時間も予算表の数量へ入れる。

評価費用は試作回数と別に置く

生成AIの試作は、一度動いた後にプロンプト、検索方法、モデル、データを変えて評価を繰り返す。AWSの評価パイプライン例は、少数例の手動確認と、正解データを使うオフライン評価を分け、出力、応答時間、費用を記録する。

評価費用を決める主な数量は、テスト件数、モデル候補数、設定候補数、反復回数、人の確認件数だ。たとえば100件のテストを3モデル、2設定で試せば、少なくとも600件の出力が生じる。これは算術上の実行件数であり、必要な回数の推奨値ではない。

全出力を人が読むのか、一部だけ読むのか。自動採点を使うなら、その採点が人の判断と合うかを誰が確認するのか。ここが未定だと、試作費は決まっても合否判定の費用が決まらない。

既存システム連携をPoCへどこまで入れるか

PoCで技術的な可能性だけを見るなら、既存の認証、業務DB、監査ログを接続しない方法もある。短期間で仮説を確かめやすい反面、本番移行時の難所は残る。

AWSのPath-to-Valueは、PoCから本番へ進む際に、データアクセス、既存システム連携、セキュリティ、監視、拡張性、回復性が過小評価されやすいと整理している。PoCへ全部入れる必要はないが、入れない項目は「本番化で追加になる作業」として別表に残す。

連携を一つ入れるなら、接続先、認証、権限、テスト環境、異常時の動作、ログ、担当部署までが費用に関わる。APIを1本つなぐ、という数え方だけでは範囲がそろわない。

PoCの削りすぎと作りすぎを避ける

安く抑えすぎると、数件のきれいなサンプルだけでデモを作り、実データで判断できないPoCになる。反対に、本番用の認証、監視、冗長化、全データ移行まで最初から作れば、まだ捨てる可能性のある仮説へ投資しすぎる。

PoCへ入れるのは、次の投資判断に必要な最小範囲だ。技術的に動くか、業務上役立つか、安全に扱えるか、費用が許容できるか。そのうち今回決める問いを明示し、答えに不要な本番機能は外す。

費用表の空欄を埋め、成果物と完了条件がそろった段階で、複数社へ同じ条件を渡す。公開価格から相場を決めるのではなく、同じ数量、同じ成果物、同じ評価条件で戻ってきた見積を比較する。それがこのPoCに必要な予算になる。