AI開発を3回に分けて発注すると安くなるか。分割のたびに二重に乗る4つの費用
分割が下げるのは単価ではなく中止したときの損失です。立ち上げ・読み直し・契約事務・短期契約の厚みという二重費用と、成果物や評価データを自社に残す4条件、総額も併せて聞く方法を解説します。
「まず PoC だけでお願いします。本番は改めて見積もってください」
AI 開発でよく選ばれる進め方である。一度に大きな金額を決めなくて済み、効果が出なければ止められる。方向としては正しい。
ただし、分割すれば総額が下がると考えて分けると、逆の結果になることがある。分割が費用を下げる仕組みと、分割のたびに二重に乗る費用を分けて見ておく必要がある。
1. 分割が安くする仕組みは「単価」ではなく「やめられること」
まず誤解を外しておく。分割しても、1 つ 1 つの作業の単価は下がらない。要件定義の工数も、データ整備の工数も、分けたから安くなるものではない。
分割が効くのは別の経路である。
| 分割で下がるもの | 下がる理由 |
|---|---|
| 中止したときの損失 | 残りのフェーズに払わずに済む |
| 手戻りの量 | 前段の結果を見てから次の範囲を決められる |
| 社内の意思決定の重さ | 1 回あたりの決裁額が下がる |
つまり分割の価値は「安く作る」ではなく、**「間違っていたと分かったときに、そこで止まれる」**ことにある。止まる可能性が低い案件では、この価値は小さい。
2. 二重に乗る費用 1：立ち上げ
契約が分かれると、立ち上げの作業がその回数だけ発生する。
- キックオフと体制の確認
- 開発環境・検証環境の構築、アカウントの発行
- 発注側の担当者への説明、情報共有の場の設定
- 終了時の報告書と引き渡し
1 回目で作った環境がそのまま 2 回目に使えるとは限らない。PoC を開発会社側のアカウントで動かしていた場合、本番フェーズでは自社アカウントに作り直すことになる。この作り直しは、どちらの見積書にも「環境構築」として 1 回ずつ載る。
3. 二重に乗る費用 2：要件の再説明と読み直し
同じ会社が続けて担当する場合でも、間が空けば担当者が変わる。別の会社になれば、業務の説明は最初からになる。
読み直しの対象は 3 つある。
| 対象 | 読み直しが要る理由 |
|---|---|
| 業務の前提 | 口頭で共有された判断基準は文書に残っていない |
| 既存コード | 書いた人以外には、なぜそう書いたかが分からない |
| 検証結果 | 数字は残っていても、測った条件が残っていないことがある |
ここは成果物の作り方しだいで大きく変えられる費用である。後述する 10 節の条件が満たされていれば、読み直しは短く済む。満たされていないと、2 回目の見積もりの先頭に「現行調査」という行が立つ。
4. 二重に乗る費用 3：契約と審査の事務
これは開発会社の見積書に出てこない、発注側の中で発生する費用である。
- NDA の締結・更新
- 社内稟議と決裁
- 購買手続き、取引先登録
- セキュリティ審査、情報システム部門の確認
金額には出ないが、時間には確実に出る。審査に 1 か月かかる会社なら、3 分割は 3 か月の待ちを生む。待っている間、業務側の課題は解決しないままである。
分割の回数を決めるとき、この事務の重さは社内でしか分からない。開発会社は提案してくれない。
5. 二重に乗る費用 4：期間が短い契約に乗るリスク料
ここは見えにくいが実在する。
開発会社から見ると、短い契約は次が続く保証が無い仕事である。要員を長期で押さえられず、立ち上げコストを短い期間で回収する必要がある。結果として、同じ作業でも短期契約のほうが見積もりが厚くなる方向に働くと考えられる。
逆に、継続が前提だと伝えられている案件では、この厚みは乗りにくい。値引き交渉より、継続の見通しを伝えるほうが効くのはこのためである。条件提示で金額を動かす考え方はAI開発費の交渉。値引きより効く5つの条件提示で整理した。
6. どちらが得かの判断は、1 本の式で足りる
厳密な計算は要らない。次の 2 つを比べればよい。
- 分割で守れる金額 ＝ 中止する確率 × 中止した場合に払わずに済む残額
- 分割で増える金額 ＝ 立ち上げの重複 ＋ 読み直し ＋ 事務の負荷 ＋ 短期契約の厚み
中止する確率が高い案件（前例が無い、データの品質が分からない、社内の合意が取れていない）では左が大きくなる。確率が低い案件（既存 API の標準的な使い方で、似た事例が多い）では右が大きくなる。
前例の少ない AI 案件ほど分割が効き、やることが決まっている案件ほど分割が損になる、というのが結論である。どちらに寄っているかの判断材料はPoCから始めるか、直接開発するかのチェックリストが使える。
7. 分割の境目は「期間」ではなく「成果物」で切る
「3 か月ずつ 3 回」のように期間で切ると、区切りの時点で何が終わっているかが決まらない。結果として、次の契約の範囲を決めるための打ち合わせが追加で発生する。
区切りは次の判断に必要な成果物で切る。
| 区切り | その時点で手元にあるべきもの |
|---|---|
| 検証フェーズの終わり | 評価データ、測定結果、達成しなかった項目の一覧、本番開発の概算 |
| 開発フェーズの終わり | 動くシステム、設計書、テスト結果、運用手順 |
| 本番移行の終わり | 監視の設定、障害時の連絡経路、改善の進め方 |
この一覧を契約前に納品物として書かせる。書けない区切り方は、区切る意味が無い。
8. 分割しても二重にしないための 4 条件
二重の費用は、契約の書き方でかなり減らせる。
- 成果物を次フェーズで使える形で受け取る。検証コードと設定、実行手順、使ったデータの加工手順まで含める
- 評価データを自社の資産にする。精度を測るための正解データは、作った会社ではなく発注側に残す。これが無いと、次の会社は精度を比較できない
- 実行環境を自社アカウントに置く。クラウドの契約を開発会社名義にしない。作り直しが消える
- 権利の帰属を 1 回目の契約で決める。コード・プロンプト・評価データ・ログの 4 つを個別に書く。項目ごとの決め方はソースコードとプロンプトは誰のものかにまとめた
この 4 つが入っていれば、2 回目を別の会社に頼むこともできる。入っていないと、実質的に 1 社に固定されたうえで分割している状態になり、分割の最大の利点（止まれること・比べられること）が消える。
9. 分割前提の見積もりは、総額も併せて出させる
相見積もりを取るとき、「PoC だけの金額」を聞くと各社ともその金額を小さく出してくる。小さく出す方法はいくらでもあり、そこで比べても意味が無い。
聞き方を 2 本立てにする。
- フェーズ 1 の金額と範囲
- フェーズ 1 の結果が想定どおりだった場合の、最終までの概算総額
2 本目は確定金額ではない。幅でよい。それでも、フェーズ 1 を安く見せて後で回収する構造かどうかは見える。1 本目が安く 2 本目が極端に高い会社と、両方が中位の会社では、総額の意味が変わる。
無料で相見積もりの案件票では、フェーズ（PoC / MVP / 本番 / 運用）と予算・納期を選択式で揃えるので、各社が同じ区切りで金額を出したかを横並びで確認できる。すでにフェーズ分割の見積書を受け取っているなら、見積書チェックで次フェーズに持ち越される前提が書かれているかを確認できる。分野別・フェーズ別の金額の目安はAI開発の費用相場にある。
10. 分けすぎのサイン
次のどれかに当てはまったら、分割の回数が多すぎる可能性がある。
- 1 回あたりの契約金額より、社内手続きの手間のほうが重く感じる
- 各フェーズの最初の 2 週間が、毎回「現状確認」で終わっている
- フェーズの区切りで、何を判断するのかが決まっていない
- 止める判断を一度もしていない（止める気が無いなら、分ける理由が薄い）
最後の 1 つが重要である。分割は止めるための仕組みなので、止める条件を決めていない分割は、事務手続きを増やしただけになる。やめる条件の決め方はPoCを安く実施する方法で扱った。
11. まとめ
分割発注は、不確実性が高い案件の損失を減らす手段であって、値段を下げる手段ではない。
判断は 3 行で足りる。
- この案件を途中で止める可能性が本当にあるか。無いなら分けない理由が立つ
- 分けるなら、区切りを成果物で定義し、納品物として書かせる
- 成果物・評価データ・環境・権利の 4 つを自社に残す条件を 1 回目の契約に入れる
この 3 行が満たされていれば、分割しても二重の費用はかなり抑えられる。満たされないまま回数だけ増やすと、総額は上がり、しかも 1 社から動けなくなる。分けることと、比べられることは別の話である。
AI開発の見積もりを、同じ条件で比べる。
条件を整理した 1 枚の案件票で複数のAI開発会社に依頼。初期費用だけでなく、データ整備・API 費・精度検証・保守・権利まで同じ列で比較できます。