生成AI受託開発の見積もりは何で決まるか｜費用の内訳を6項目で分解
生成AI受託開発の見積もりが「なぜその金額になるのか」を、要件定義・データ整備・実装・評価・運用の6項目に分解して解説。相場が読みにくい理由と、発注側が見積書で確認すべき点をまとめました。
「生成AIで社内の問い合わせ対応を自動化したい」と複数社に相談したら、200万円の見積もりと1,500万円の見積もりが並んで出てきた——こうした話は珍しくありません。同じように見える依頼でも、金額が数倍違うことがあります。
この記事は、生成AIの受託開発を検討していて「見積書の金額の根拠がわからない」「妥当性を判断できない」と感じている企業の担当者・経営者に向けたものです。私たちが日々見積書を作る側として、どの作業にどれだけの工数がかかり、何が金額を押し上げるのかを分解して説明します。
特定の相場表を提示することはしません。後述の通り、要件次第で幅が大きすぎて、相場表はかえって判断を誤らせるからです。代わりに「何を聞けば見積もりの中身がわかるか」を持ち帰っていただくことを目指します。
生成AI開発の見積もりが読みにくい3つの理由
理由1：完成の定義が曖昧なまま発注されやすい
従来の業務システム開発なら「この画面でこの項目を登録でき、この帳票が出力できる」と完成条件を書けます。生成AIの場合、「社内文書について質問に答えられる」という要件は、一見明確に見えて実はまったく確定していません。
何%の質問に正しく答えられれば完成なのか。答えられない質問にどう振る舞うべきか。回答の根拠は示すのか。これらが決まっていないと、開発側は「どこまでやれば終わりか」がわからず、リスクを見込んだ金額を置くか、逆に楽観的に安く見積もって後で揉めるかのどちらかになります。
理由2：精度の最後の20%にコストの大半がかかる
生成AIを使ったプロトタイプは、驚くほど早くできます。社内文書を読み込ませて質問に答えるだけの仕組みなら、数日で「それらしく動くもの」が用意できてしまう。ここが誤解を生みます。
実務で使えるレベルにするには、答えられないケースの洗い出し、検索対象データの整理、プロンプトの調整、評価の仕組みづくりが必要です。私たちの実感として、体感で8割動くところまでは全体工数の一部にすぎず、残りの詰めのほうが時間を要します。安い見積もりが「プロトタイプまで」の範囲を指していることは、よくあります。
理由3：発注側のデータ状態が金額を左右する
生成AIの出力品質は、参照するデータの整い方に強く依存します。同じRAG（社内文書を検索して回答生成する仕組み）でも、PDFとWordが整理された共有フォルダにある会社と、10年分の文書がファイル名「最新版_修正2_final.pdf」で散在している会社では、前処理の工数がまったく違います。
このデータ整備コストが、発注側からは見えにくい。見積もりの差が「開発会社の単価の差」ではなく「見込んでいるデータ整備量の差」であることは相当あります。
費用の内訳を6つに分解する
生成AI受託開発の見積もりは、おおむね次の6項目に分解できます。プロジェクトの性質によって比重は変わりますが、どれかがゼロになることは基本的にありません。
1. 要件定義・PoC設計
業務のどこにAIを入れるか、成功をどう測るかを決める工程です。生成AI案件ではここが従来開発より重くなります。理由は、業務側が「AIに何ができるか」を、開発側が「その業務の実態」を、それぞれ知らない状態から始まるためです。
具体例を挙げます。ある製造業の技術サポート部門で、過去の問い合わせ履歴をAIに検索させたいという相談を受けたとします。ここで確認すべきは、履歴が何件あるか、だけではありません。回答者によって記述の粒度が違わないか、社外に出せない顧客固有情報が混ざっていないか、そもそも回答者が本当に参照したいのは履歴なのか設計図面なのか。この整理をせずに実装に入ると、動くものはできても使われないシステムになります。
この工程を「無料でやります」と言う会社には注意が必要です。無料の分は別のどこかに乗っているか、十分な時間をかけない前提になっています。
2. データ整備・前処理
見積もりの変動幅が最も大きい項目です。含まれる作業は概ね以下です。
- 対象ドキュメントの棚卸しと、最新版の特定
- PDF・スキャン画像からのテキスト抽出（表や図が多いと難易度が上がる）
- 文書の分割方法の設計（章単位か、一定文字数かで検索精度が変わる）
- 機密情報・個人情報のマスキング方針の適用
- 既存システムからのデータ連携
スキャンされた紙の図面や、Excelに手作業で積み上げられた台帳が対象に入ると、この工程だけで全体の三分の一以上を占めることもあります。見積もりを依頼する際、対象データのサンプルを数点渡せるかどうかで、見積もり精度は大きく変わります。
3. AI部分の実装
プロンプト設計、モデルの選定、検索の仕組み（RAG）の構築、外部ツール連携などです。ここは「生成AI開発」と聞いて多くの方が想像する部分ですが、金額全体に占める比率は思ったほど高くないことが多い。
API経由でモデルを使う場合、モデルそのものを作るわけではないためです。逆に、独自モデルの追加学習（ファインチューニング）や、社内環境で完結させるオープンモデルの運用を求めると、この項目は跳ね上がります。要件として本当に必要かは、要件定義段階で詰めるべき論点です。
4. 評価・チューニング
生成AI案件で見落とされやすく、かつ削ると後で必ず困る項目です。
必要なのは、評価用の質問と期待される回答のセット（評価データセット）を業務側と一緒に作り、変更のたびに精度を測れるようにすることです。これがないと、プロンプトを直したときに「よくなった気がする」以上のことが言えません。50〜100件程度の評価セットを業務担当者と作る作業は、地味ですが確実に工数を消費します。
見積書にこの項目がまったく現れない場合、「どうやって品質を確認しますか」と聞いてみてください。答えが「動かしてみて確認します」だけなら、リスクがあります。
5. UI・既存システム連携
チャット画面を作るのか、既存の社内ポータルに埋め込むのか、Microsoft TeamsやSlackから使うのか。認証を社内のIDと連携させるか、権限によって参照できる文書を分けるか。
権限管理は特に注意が必要です。「人事部の文書は人事部のメンバーだけが検索結果に出る」といった要件は、後から追加すると検索の仕組み自体の作り直しになりかねません。初期の要件確認に必ず含めてください。
6. 運用・保守
開発費とは別枠で、月額で発生します。内訳は主に、モデル利用料（APIの従量課金）、インフラ費用、監視・障害対応、そしてモデル更新への追随です。
最後の項目が生成AI特有です。利用しているモデルにはバージョンの更新や提供終了があり、切り替えの際には出力の傾向が変わることがあります。そのたびに評価をやり直す必要があり、これは「バグがなければ何もしない」種類の保守ではありません。年間の保守費を見積もる際は、この分を織り込んでいるか確認する価値があります。
金額を大きく動かす要因
同じような依頼でも、次の条件が入ると見積もりは上がります。発注前に自社の要件を照らしてみてください。
求める精度の水準：社内での参考情報として使うのか、顧客に直接提示するのかで、必要な検証量が変わります。誤りが直接損害につながる領域では、人間の確認を組み込む設計が必須になり、その分の設計工数が乗ります。
データの機密性：一般的なクラウドAPIが使えず、閉じたネットワーク内での構築が必要になると、インフラ構築の工数が加わります。
対象業務の幅：「経理の問い合わせ対応」と「全社の問い合わせ対応」では、扱う文書の種類も評価の手間も別物です。最初は範囲を絞ることを強くおすすめします。
社内の意思決定者の数：技術的な話ではありませんが、実務では効きます。仕様の判断者が明確でないプロジェクトは、確認待ちと手戻りで工数が膨らみます。
見積書で確認したい5つの質問
複数社から見積もりを取ったら、金額の大小を比べる前に次を聞いてください。
- この見積もりのゴールは「試作」か「本番運用」か
- データの前処理はどこまで含まれ、どこからが追加費用か
- 精度をどう測定し、どの水準を満たせば納品完了とするか
- 発注側が用意すべきもの（データ、確認の工数、担当者の時間）は何か
- 運用開始後の月額費用の内訳と、想定利用量が変わった場合の変動幅
特に4番目は見落とされがちです。生成AI案件は、業務を知る人の関与なしには品質が上がりません。「発注側の作業がほぼ不要」という提案は、むしろ内容を疑ったほうがよいと私たちは考えています。
受託開発が向かないケース
正直に書きます。以下に当てはまる場合、外部への受託発注は最善ではないかもしれません。
汎用ツールで足りる場合：文章の要約や翻訳、議事録作成など、既製のAIサービスで済む用途に独自開発は割に合いません。まず既製ツールを試し、それで届かない部分を明確にしてから相談するほうが、結果的に費用対効果は高くなります。
課題が特定されていない場合：「AIで何かできないか」という段階での開発発注は、要件定義で迷走しがちです。この段階なら、開発ではなく短期の調査・整理から始めるほうが妥当です。
業務プロセス自体が固まっていない場合：AIは既存業務の一部を担う道具です。業務手順が人によってバラバラな状態でAIを入れても、何を自動化しているのかが定まりません。
まとめ
生成AI受託開発の見積もりは、モデルの高度さよりも、要件の明確さ・データの状態・求める精度の水準で決まります。金額の差は多くの場合、技術力の差ではなく、見込んでいる作業範囲の差です。
だからこそ、比較すべきは総額ではなく内訳です。「何が含まれ、何が含まれないか」を6項目に沿って確認すれば、安すぎる見積もりの危うさも、高い見積もりの合理性も見えてきます。
私たちも見積もりを作る際は、この分解を発注者と共有したうえで、範囲を一緒に決めるようにしています。金額の妥当性は、単価ではなく範囲の合意から生まれると考えているためです。