AI活用の相談を外部に持ちかけたものの、返ってきた見積もりが「AI開発一式」の一行で、金額が妥当かどうか社内で判断できない——という声は少なくありません。この記事では、一式計上の見積もりを工程別に分解して読み解く手順と、構想フェーズと開発フェーズを分けて契約する段階発注の進め方、相見積もりを比べる前に揃えるべき前提条件を整理します。
- 一式を工程に分解する 要件定義・開発・連携・テスト・運用に割り振る
- 前提条件を書き出す 業務量、連携先、テスト範囲を文書にする
- 構想フェーズを先に契約する 小さく始めて判断材料を得る
- 継続可否の基準を決める 次に進む条件を着手前に合意する
- 開発フェーズを再見積もりする 構想の結果を反映した金額で契約する
なぜ一式見積もりでは判断できないのか
見積もりが一式で提示されると、比較の軸がなくなります。金額だけを並べても、安い方が「やらない作業が多いだけ」なのか「同じ範囲を効率よくやる」のかが区別できません。
もう一つの問題は、着手後の追加費用です。一式の中に何が含まれているかが曖昧なままだと、「既存システムとの連携は別途」「テストデータの準備は御社で」といった話が後から出てきます。金額の妥当性より先に、範囲の明確さを確認するのが順番です。
AI活用の案件は、通常のシステム開発に加えて「そもそもAIで解けるのか」を確かめる工程が入ります。検証前は必要な作業量を見通しにくいため、不確実な部分を段階発注に分ける方法があります。要件・前提・検収条件・変更時の扱いが明確なら、固定価格で契約する方法も選べます。
一式見積もりでは、総額とあわせて対象範囲・成果物・前提条件を確認します。
工程別に分解して、どこに費用が乗っているかを読む
提示された見積もりを、次の工程に割り振ってもらうよう依頼します。割り振れない項目があれば、そこが定義の曖昧な部分です。
| 工程 | 主な作業 | 確認したいこと |
|---|---|---|
| 活用領域の見極め | 業務の棚卸し、適用候補の絞り込み | 何件の業務を対象に調べるか |
| 構想・ロードマップ | 優先順位付け、実施順の整理 | 成果物は何か(資料・計画書など) |
| PoC設計と効果検証 | 小規模な試行と結果の評価 | 評価の指標と判断の時期 |
| 要件定義 | 画面・処理・データの仕様化 | 誰が仕様を決裁するか |
| 開発 | 実装、単体テスト | 対象機能の数と範囲 |
| 既存環境との連携 | 社内システムやSaaSとの接続 | 連携先の数、仕様書の有無 |
| テスト | 結合テスト、受入テスト | テストケースの作成は誰か |
| 運用改善 | 稼働後の調整、問い合わせ対応 | 期間と対応範囲 |
金額の配分を見ると、相手がその案件をどう捉えているかが分かります。要件定義が極端に薄い見積もりは、仕様が固まらないまま開発に入って手戻りが発生する余地を残しています。逆に連携とテストに厚みがある場合は、既存環境の調査を織り込んだ見方をしていると読めます。
構想と開発を分けて契約する段階発注
AI活用の案件では、最初の時点で最終的な開発規模を確定させることが難しい場合があります。そこで、構想フェーズと開発フェーズを別契約にし、工程の区切りごとに継続可否を判断する進め方が現実的です。
構想フェーズでは、対象業務の見極め、実現方法の整理、小規模な検証を行い、開発に進むかどうかの判断材料を揃えます。ここで「やらない」という結論が出ることもあり、それ自体が費用に見合う成果です。開発フェーズの見積もりは、構想の結果を踏まえてあらためて算出します。
開発フェーズに進む
- 対象業務の処理件数と手順が文書になっている
- 検証で想定した精度・処理時間の水準を確認できた
- 連携先システムの仕様と担当者が特定できている
- 稼働後に運用する担当者が決まっている
構想フェーズに留まる
- 対象業務が複数部署にまたがり、範囲が確定しない
- 検証結果の評価基準を社内で合意できていない
- 連携先の仕様が不明、またはベンダー確認が未着手
- 導入後の運用体制を決める人がいない
継続可否の基準は、構想フェーズに着手する前に決めておきます。結果が出てから基準を作ると、投じた費用が惜しくなって無条件に次へ進みがちです。
構想と開発を分け、次へ進む条件を着手前に合意しておくことが段階発注の要点です。
相見積もりの前に揃える前提条件
複数社に声をかける場合、各社が別々の前提で金額を出すと比較が成立しません。依頼時に次の項目を文書で揃えて渡します。
この条件書を作る過程で、自社でも決まっていない項目が見つかります。そこが見積もりのブレる原因なので、先に社内で詰めるか、構想フェーズで詰める作業として明示的に依頼先へ渡します。
見積もりを受け取った後に確認する5つの問い
工程別の内訳が出てきたら、次の問いを依頼先にぶつけます。回答が曖昧な項目は、契約前に書面で補ってもらいます。
- 各工程の成果物は何で、いつ検収するのか
- 当社側で用意する資料・データ・作業は何か
- 要件が変わった場合、どの手順で金額を見直すのか
- 既存システムとの連携で、相手方ベンダーとの調整は誰が行うのか
- 稼働後の不具合対応は、どの範囲まで費用に含まれるのか
4つ目は見落としやすい項目です。既存環境との接続は、自社と開発会社だけでは完結せず、既存システムの保守ベンダーへの確認が必要になることがあります。この調整工数がどちらの見積もりにも入っていないと、着手後に止まります。
当社のAIコンサルティング・システム開発では、AI活用領域の見極め、構想・ロードマップの作成、PoC設計と効果検証、要件定義、開発、既存環境との連携、運用改善までを工程に分けて支援しています。構想の段階だけを切り出して相談いただくことも可能です。
よくある質問
Q: 構想フェーズだけ依頼して、開発は別の会社に出せますか
A: 構想フェーズの成果物を要件定義に使える形で受け取れるかどうかが分かれ目です。契約前に、成果物の内容と納品形式、第三者への提示が可能かを確認してください。成果物が口頭説明中心だと、別の会社に引き継ぐ際に説明工数が追加で発生します。
Q: 見積もりが他社より大幅に安い場合、どう判断すればよいですか
A: 金額差の理由を工程別に照らし合わせます。要件定義・連携・テストのいずれかが含まれていない、あるいは自社側の作業として外出しされていないか確認します。安い見積もりを基準に、不足している工程を自社で誰がやるのかを書き出すと、実質的な負担が比較できます。
Q: 社内にAIの知見がなくても、見積もりの妥当性を判断できますか
A: 専門知識がなくても、業務範囲や費用の内訳は確認できます。ただし、AIの精度・安全性・個人情報や機密情報の扱い・運用時の制約は、社内の担当者や専門家と評価する必要があります。対象業務の処理件数、連携先、テスト範囲といった前提条件は自社の情報なので、それを文書化して各社に同じ条件で見積もりを依頼すれば、範囲の過不足は比較できます。技術的な選択肢の説明は、依頼先に平易な言葉で求めてください。
まとめ
AI開発の見積もりを判断するには、金額を見る前に範囲を見ます。一式計上を要件定義・開発・連携・テスト・運用改善などの工程に分解し、どこに費用が乗っているかと、各工程の成果物を確認します。
そのうえで、構想フェーズと開発フェーズを分けて契約し、次へ進む条件を着手前に合意しておけば、途中で止める判断もできます。相見積もりを取る際は、対象業務量・連携先・テスト範囲を文書で揃えてから依頼してください。この条件書を作る作業自体が、自社の要件を整理する工程になります。


