AI開発の見積比較は金額より先に、前提・範囲・費用体系・契約の4分類12項目を横並びにする。相見積もりの依頼方法、内訳と除外事項の読み方、安い見積の落とし穴、聞き直す質問テンプレまで実務順に整理した。
AI開発の見積を比べるときは、総額を並べる前に前提・範囲・費用体系・契約の4分類12項目を1枚の表にそろえる。それぞれの会社の見積書は前提条件や除外範囲の書き方がばらばらで、そのまま金額を比べると判断を誤りやすい。安く見えた見積が、あとから追加費用で逆転することもある。この記事では、届いた見積を同じ軸で並べるチェックリストと、聞き直すための質問テンプレを比較の実務順に整理する。
AI開発の見積比較チェックリストとは？
AI開発の見積比較チェックリストとは、複数社の見積書を前提・範囲・費用体系・契約の4分類で同じ表に並べ、抜けとあいまいな記載を洗い出す確認項目の一覧である。
要件を整理してRFPを書く段階とは目的が違う。RFPは何を頼むかを決める文書であり、このチェックリストは届いた回答が同じ条件で書かれているかを確かめる道具である。AI開発は、データの質や精度の到達度に不確実性が残る。そのためふつうのシステム開発より、前提条件の差が金額に表れやすい。
4分類12項目はこの記事独自の整理であり、業界標準の枠組みではない。自社の案件に合わせて、項目を足し引きして使う前提である。
AI開発の見積を比較するとき、どの項目を横並びで見ればよいか？
横並びで見るのは、前提・範囲・費用体系・契約の4分類にまたがる12項目である。総額は最後に見る。12項目のうち1つでも空欄の会社があれば、その時点では金額を比べる条件がまだそろっていない。
| 分類 | 確認項目 | 見積書で見る箇所 | 空欄やあいまいなときの扱い |
|---|---|---|---|
| 前提 | 目的と成功の定義 | 提案概要、前提条件 | 精度目標や業務指標を聞き直す |
| 前提 | PoCのみか本番までか | 工程表、フェーズ区分 | 本番移行の扱いを聞き直す |
| 前提 | データ準備と前処理の担当 | 前提条件、発注する側の作業 | 誰が何件を整えるかを確かめる |
| 範囲 | 除外事項 | 対象外の記載、注記 | 除外の理由と別見積の有無を聞く |
| 範囲 | 既存システムや外部APIとの連携 | 機能一覧、構成図 | 連携先ごとの工数を確かめる |
| 範囲 | 成果物の一覧 | 納品物一覧 | ソースコードや学習済みモデルの有無を確かめる |
| 費用 | 費用体系（請負か準委任か） | 契約形態、支払条件 | 精算方法と上限の有無を確かめる |
| 費用 | ランニング費用 | 月額費用、運用費 | API利用料とクラウド費の見込みを聞く |
| 費用 | 追加開発と仕様変更の単価 | 単価表、変更手続き | 変更時の算定方法を確かめる |
| 契約 | 成果物とデータの権利帰属 | 契約書案、特記事項 | 学習データの再利用の扱いを確かめる |
| 契約 | 受入基準と検収 | 検収条件 | 精度が目標に届かないときの扱いを確かめる |
| 契約 | 保守と運用の範囲 | 保守内容、SLA | 対応時間とモデル更新の扱いを確かめる |
使い方はかんたんである。表の右側に会社ごとの列を足し、各セルに見積書の記載をそのまま転記する。要約せずに転記すると、空欄とあいまいな表現がひと目でわかる。前提と範囲の6項目が埋まってから、費用と契約の比較に進む順番がよい。
同じ条件で相見積もりを依頼するにはどうするか？
同じ条件で依頼するには、すべての会社に同一の依頼文と回答様式を渡し、12項目を回答欄として指定する。依頼先は3社前後に絞り、1社から出た質問とその回答はすべての会社に共有する。
相見積もりの比較が崩れる原因の多くは、依頼の段階で条件がそろっていないことにある。口頭の打ち合わせで会社ごとに補足を変えると、その差がそのまま見積の前提に入り込む。次の5つの手順で条件をそろえる。
- 依頼文を1本にまとめる。目的、対象業務、使えるデータの種類と量、希望時期を書く。
- 回答様式を指定する。12項目の欄を設け、該当しない項目には「対象外」と書いてもらう。
- 質疑の窓口と期限を決める。1社から出た質問と回答は、すべての会社に同じ文面で共有する。
- PoCと本番を分けた見積を求める。本番移行の条件と、移行しないときの扱いも書いてもらう。
- 回答期限をそろえる。締切後にまとめて比較表へ転記し、途中で届いた分から評価を始めない。
依頼先を増やしすぎると、質疑の対応と比較表づくりで手が回らなくなる。各社の提案も浅くなりやすい。逆に2社だと、比較の基準は片方に寄りやすい。扱いやすいのは3社前後である。
依頼文の段階で要件が固まらないなら、比較の前に要件の整理へ戻る。そのほうが手戻りは少ない。
見積書の内訳で何を確認すべきか？
内訳では、工程ごとの工数と人員構成、PoCと本番の切り分け、ランニング費用の3点を確かめる。「一式」とまとめた行が全体の何割を占めるかも見る。一式の割合が大きいほど、あとから範囲の解釈がずれやすい。
| 内訳の行 | 確かめること |
|---|---|
| 要件定義・設計 | 業務フローの整理や画面設計まで含むか |
| データ準備・前処理 | 件数の前提、クレンジングとラベル付けの担当 |
| モデル構築・評価 | 評価データの用意と、評価の回数 |
| アプリ・連携の実装 | 画面、API、既存システム側の改修の有無 |
| テスト・受入支援 | 受入テストへの立ち会いと修正の範囲 |
| 運用移行・保守 | 監視、問い合わせ対応、モデル更新の頻度 |
AI開発に特有なのは、データ準備と評価の行である。この2行が無い見積は、作業が発注する側に回されているか、モデル構築の工数に埋もれているかのどちらかである。どちらなのかを確かめないと、ほかの会社と同じ土俵で比べられない。
人員構成は、役割と稼働率を見る。同じ工数でも、設計から運用までを同じチームが担うか、工程ごとに担当が替わるかで、引き継ぎの手間が変わる。少人数で企画から運用までを担う体制の考え方は、少人数で一気通貫の開発体制をつくる方法で整理している。
ランニング費用は、月額の見込みに加えて、その前提となる利用量を書いてもらう。生成AIのAPI利用料は利用量に応じて変わる。利用者数や処理件数の想定が会社ごとに違うと、月額も比べられない。
前提条件と除外事項はどう読めばよいか？
前提条件と除外事項は、それぞれの会社の金額差を説明する手がかりになる。除外が多い見積ほど安く見えやすいため、除外された作業を発注する側で担うか別見積にするかを、1項目ずつ決めてから比べる。
見積書の注記には、範囲をあとから決める表現が出てきやすい。代表的な表現と、確かめる点は次のとおりである。
- 「データは発注者にてご用意いただく前提」は、前処理やラベル付けまで発注者の作業かを確かめる。
- 「既存システム側の改修は含まない」は、連携に必要な改修を誰がいつ担うかを確かめる。
- 「精度は検証結果に基づき別途協議」は、受入の基準をどの時点で決めるかを確かめる。
- 「インフラ費用は別途」は、構築作業と月額の利用料のどちらを指すかを確かめる。
- 「本番環境への移行は別フェーズ」は、移行の作業と費用の見込みを先に聞く。
除外事項そのものが悪いわけではない。発注する側で担える作業を外して費用を抑える判断は合理的である。問題は、除外の内容を知らないまま総額を比べることにある。除外を確認したら、比較表の範囲の行に「発注者が担う」「別見積」「含む」のいずれかを書き込む。
安い見積の落とし穴も、多くはこの除外と前提から生じる。本番費用が書かれていない場合もあり、総額はあとから逆転しうる。
- 除外された作業。データの前処理、既存システムの改修、受入テストの支援が外れていると、その作業は発注する側か別見積に回る。
- 楽観的な前提。データが整っている、連携先の仕様が変わらないといった前提が崩れると、追加費用の根拠になる。
- 本番費用の未記載。PoCの金額だけが書かれ、本番化の工数やランニング費用が空欄だと、総額の比較ができない。
逆に、高い見積にも理由を聞く価値がある。リスクへの対応工数や予備の期間を含めているときは、ほかの会社が書いていない作業が見えてくる。金額の高低ではなく、差の内訳を説明できるかどうかで評価する。
費用体系（固定・準委任）の違いをどう比較するか？
比べる軸は2つ、範囲変更と期間延長の費用を誰が負うかである。固定額は範囲変更で追加費用が出やすく、準委任は期間が延びると総額が膨らむ。
IPAのモデル契約書には、受託開発などを対象とする第二版がある。これとは別に、アジャイル開発版も公開されている。アジャイル開発版は、請負ではなく準委任契約を前提にしている（出典：IPA『情報システム・モデル取引・契約書（アジャイル開発版）』2020年3月、IPAの公開ページ）。機能の追加や優先順位の変更に柔軟に対応する進め方では、成果物を最初に固定しにくいためである。
AI開発は、データを見るまで精度の到達度が読めない工程を含む。このため、PoCは準委任とし、範囲が固まった本番開発は請負とする組み合わせが選ばれることもある。比較するときは、次の観点を表に足す。
| 観点 | 請負（固定額） | 準委任（月額・時間単価） |
|---|---|---|
| 対価の対象 | 成果物の完成 | 業務の遂行 |
| 範囲変更の扱い | 追加見積になりやすい | 期間内で優先順位を入れ替えやすい |
| 総額の読みやすさ | 契約時に確定しやすい | 期間と稼働率で変動する |
| 確かめる条件 | 変更手続きと追加単価 | 月額の上限、終了条件、報告の頻度 |
準委任の見積を請負と並べるときは、月額に想定期間を掛けた額を基準にする。そのうえで、期間が延びたときの上限と、途中で範囲を見直す手続きを確かめる。請負の見積では、変更の手続きと追加開発の単価が書かれているかを見る。
契約・データ権利・保守の範囲をどう見比べるか？
契約面で差が出やすいのは、成果物とデータの権利帰属と、受入基準の2点である。保守の範囲も合わせ、見積と同時に契約書案の提出を求めて見比べる。
これらは見積書の本体より、契約書案や特記事項に書かれやすい。
権利帰属は、ソースコードや学習済みモデルなど成果物の種類ごとに分けて確かめる。発注者が渡したデータを、開発会社がほかの目的の学習に使えるかどうかも並べておく。内製化や別の会社への引き継ぎを考えるなら、ソースコードと設計文書の納品が範囲に入っているかが比較のわかれ目になる。
受入基準では、精度の目標値と、判定に使う評価データを確かめる。目標未達のときは追加作業で対応するのか、その時点で契約を終えるのかも見ておく。IPAの第二版も、この点に関わる。請負契約における契約不適合責任を、見直しの論点に挙げている（出典：IPA『情報システム・モデル取引・契約書（第二版）』2020年12月、IPAの公開ページ）。
保守で並べるのは、対応時間帯と障害時の初動である。見落としやすいのは、モデルやAPIの更新への追随だ。外部のAPIは提供元の都合で仕様や提供モデルが変わることがある。その追随を保守に含めるかどうかで、月額の意味が変わる。
契約条項の解釈は、請負か準委任かによって責任の範囲が変わる。この記事は比較の観点を整理したものであり、法的な助言ではない。条項の判断は、社内の法務担当や弁護士に確認してほしい。
聞き直したほうがよい回答の見分け方は？
聞き直すめやすは、数字・担当・条件のいずれかが欠けた回答である。「別途協議」「状況に応じて」「一式」のように範囲や金額をあとから決める表現が残る項目は、まだ比較できる状態にない。
| 聞き直す回答 | 比べられる回答の形 | 質問テンプレ |
|---|---|---|
| 精度は検証後に協議 | 評価データと合格とみなす指標の値 | 受入の判定に使う評価データと、合格とみなす値を示してほしい |
| データ前処理は別途 | 作業範囲、件数の前提、発注者の作業 | 前処理の作業範囲と件数の前提、発注する側の作業を一覧にしてほしい |
| 保守は一式 | 対応時間、作業内容、更新の扱い | 保守に含む作業と含まない作業、対応時間帯を分けて示してほしい |
| 追加開発は都度見積 | 単価と算定の方法 | 仕様変更が出たときの単価と、工数の算定方法を示してほしい |
| 権利は契約時に協議 | 成果物ごとの帰属と利用範囲 | ソースコード、学習済みモデル、評価データの帰属をそれぞれ示してほしい |
質問は文書で送り、回答も文書でもらう。同じ質問をすべての会社に送れば、回答の具体性そのものが比較の材料になる。聞き直した後に回答が具体的になった会社と、表現が変わらない会社の差は、契約後のやり取りを見通す手がかりにもなる。
比較結果をどう点数化して候補を絞るか？
4分類に重みを付け、12項目を3段階で採点して合計点を出す。前提と契約を各30点、範囲と費用を各20点とする100点満点にすると、総額の安さだけで決める判断を避けやすい。
| 分類 | 重みの例 | 3段階の採点 |
|---|---|---|
| 前提 | 30点 | 具体的な記載は3、あいまいな記載は2、記載なしは1 |
| 範囲 | 20点 | 前提と同じ基準で採点する |
| 費用 | 20点 | 前提と同じ基準で採点する |
| 契約 | 30点 | 前提と同じ基準で採点する |
各分類の3項目の得点を合計し、満点の9に対する割合に重みを掛けて分類の点数にする。たとえば前提の3項目が3、2、3なら、8÷9×30で約27点になる。重みはこの記事独自の例であり、自社の優先度に合わせて変えてよい。
点数が出たら、判断は3つに分かれる。
- 絞る。合計点の上位2社ほどを残し、総額と照らして最終候補にする。
- 聞き直す。あいまいな記載が残る項目は、質問テンプレで回答をもらってから再採点する。
- 見送る。契約の分類に記載なしが2項目以上あり、聞き直しても埋まらない会社は候補から外す。
Web3のように専門性の見極めが要る領域では、採点に加える判断軸が変わる。その観点はWeb3受託開発会社の選び方で整理している。
Farleapのサービス定義にみる範囲の区切り方（一次情報）
※ご提案です。当社の実施実績ではありません。
株式会社ファーリープ（Farleap）は、プロダクト開発のサービス定義で、含む範囲を4つ、別になる範囲を2つ明記している。見積の範囲と除外事項を読むときの見本として、その構造を示す。
| 区分 | 記載の内容 |
|---|---|
| 含む範囲 | 要件定義・設計・UI/UX |
| 含む範囲 | フロント・バック・インフラの実装 |
| 含む範囲 | スマートコントラクト（Web3）の実装 |
| 含む範囲 | 検証PoC〜本番〜運用保守 |
| 別になる範囲 | 開発を伴わない助言のみは顧問として扱う |
| 別になる範囲 | 全社的な研修は別のサービスとして扱う |
同じサービス定義は、要件があいまいなら整理から、予算が限られるなら検証PoCから始める形も示している。
含む範囲と別になる範囲を対で書く。この形は、比較表の範囲の行を埋めるのに向く。各社には、含む作業と別契約になる作業の一覧を対で求めるとよい。
PoCから運用保守までを1つの範囲で書く会社もあれば、段階ごとに区切る会社もある。後者からは、次の段階へ進む条件を聞いておく。進まなかった場合、何が成果物として残るかも確かめたい。
まとめ
AI開発の見積は、総額を並べる前に、前提・範囲・費用体系・契約の4分類12項目を1枚の表にそろえて比べる。相見積もりは同一の依頼文と回答様式で3社前後に依頼し、除外事項と追加費用の条件、成果物の権利と保守範囲を確かめる。あいまいな回答は質問テンプレで聞き直し、重み付けの点数で上位2社ほどに絞る。体制の見極めには少人数で一気通貫の開発体制をつくる方法が、ほかの領域の選定軸にはWeb3受託開発会社の選び方が参考になる。開発の相談はプロダクト開発で受け付けている。
よくある質問
AI開発の相見積もりは何社に依頼すればよいか？
3社前後がめやすである。2社だと比較の基準は片方に寄りやすい。5社を超えると質疑の対応と比較表の作成で手が回らず、各社の提案も浅くなりやすい。同じ依頼文と回答様式を渡し、質疑の回答をすべての会社に共有できる数に収めるとよい。
見積の総額が大きく違うとき、まず何を確かめるか？
総額を比べる前に、前提条件と除外事項を確かめる。金額の差は、データ準備や既存システムとの連携、本番運用を範囲に含めているかどうかの違いから生じることが多い。12項目の比較表に転記し、空欄になった項目からそれぞれの会社に聞き直す。
PoCの見積だけで依頼先を決めてもよいか？
PoCの見積だけで決めるのは避けたい。PoCの金額が近くても、本番化の工数やランニング費用、追加開発の単価で総額は大きく変わる。PoCと本番を分けた見積を求め、本番移行の条件まで並べてから判断する。
準委任契約の見積は総額をどう見ればよいか？
月額や時間単価に想定期間を掛けた額を基準にし、期間が延びたときの上限と、途中で範囲を見直す手続きを確かめる。準委任は成果物の完成ではなく業務の遂行に対価を払う形であり、終了条件を決めておかないと総額が読みにくくなる。
更新履歴
2026-10-08 初稿公開。
