「AIで安くできます」の見積書を点検する5工程。削られやすい行と質問文

3 社に相見積もりを取ったら、1 社だけ他社の半額だった。提案書には「AI 駆動開発により工数を大幅に削減」と書いてある。この見積書をどう点検すればよいか、という話である。

安いこと自体は疑う理由にならない。実際に短縮できる工程はあるし、そこで浮いた分を価格に反映している会社は誠実である。点検すべきなのは価格ではなく、**「その工程の行が見積書から消えているとき、その作業を誰がやることになっているか」**のほうだ。行が無い作業は、消えたのではなく、発注側に移っているか、後から追加で請求されるか、そもそも実施されないかのどれかである。

この記事は、どの工程が短縮できるかの一般論ではなく（それはAI駆動開発で工数が下がる工程、下がりにくい工程にまとめた）、手元にある見積書を 1 枚ずつめくって確認する手順に絞る。

点検の前に：安い理由は 3 種類しかない

見積書が安いとき、理由は次の 3 つのどれかに分類できる。

種類	中身	判断
A. 生産性で安い	同じ成果物を、少ない工数で作れる	望ましい。根拠を聞く
B. 範囲で安い	作るものが小さい、作業の一部が対象外	条件を揃えれば正当
C. 工程を飛ばして安い	やるべき作業を計上していない	後から費用か品質の問題になる

3 社の見積書が割れているとき、多くは A と B と C が混ざっている。点検の目的は、C を見つけて A・B に変換することである。C を責める必要はない。「この作業は誰がやりますか」と聞けば、大抵は B（発注側でやる）か A（含まれている）に書き直される。

点検 1. 要件定義の行があるか

見る場所：見積書の最初のほう。「要件定義」「要件整理」「業務ヒアリング」といった名前の行。

削られたときの見え方：「設計・実装」と 1 行にまとまっている。あるいは「提案書の内容で着手」と書かれている。

AI を使った開発で短縮されにくい筆頭がここである。何を作るかを決める作業は、業務を知っている人の時間を使うしかない。行が無いなら、発注側が仕様を固めて渡す前提になっている可能性が高い。

質問文：「要件定義の工程が見積書に見当たりません。要件は弊社が確定させて渡す前提でしょうか。その場合、どの粒度まで書いて渡せばよいか教えてください。」

点検 2. データ整備の行があるか

見る場所：「データ準備」「前処理」「教師データ作成」「文書登録」など。RAG なら「文書の収集・クレンジング」。

削られたときの見え方：行が無い。または「既存データを利用」とだけ書かれている。

ここは金額が大きくなりやすいので、削ると効果が大きい。そして削っても着手直後は問題が出ない。問題が出るのは精度が上がらないと分かったあと、つまり工程の後半である。

質問文：「学習・検索に使うデータの整備はどちらの担当でしょうか。弊社で行う場合、必要な形式と件数、いつまでに用意すればよいかを教えてください。」

点検 3. 精度検証の行と、合格ラインが書かれているか

見る場所：「評価」「精度検証」「テストデータ作成」。あわせて、提案書に**合格ライン（何%、どの条件で）**が書かれているか。

削られたときの見え方：「テスト」の行はあるが、それはソフトウェアとしての動作テストで、AI の出力が業務で使える水準かを測る工程ではない。この 2 つは別物である。

AI 開発でいちばん揉めるのは検収である。「思ったほど精度が出ない」と言っても、何%なら合格かを契約前に決めていなければ、水掛け論になる。評価データを作る作業（正解付きのデータを人手で用意する）は、それ自体が独立した費用のかかる工程で、AI では短縮できない。

質問文：「精度の合格ラインと、それを判定する評価データについて、見積書のどの行に含まれるか教えてください。評価データの作成はどちらの担当でしょうか。」

点検 4. 業務側の受入テストの行があるか

見る場所：「受入テスト」「業務検証」「試験運用」。

削られたときの見え方：「結合テスト」までで見積書が終わっている。

実際の業務データを流して、現場の担当者が使えるか確かめる工程である。ここで見つかる修正は、必ず一定量ある。この期間と修正回数が見積書に無いと、リリース直後の修正がすべて追加請求になる。

質問文：「受入テストの期間と、そこで出た指摘の修正は見積書に含まれますか。含まれる場合、何回までの修正を想定していますか。」

点検 5. 保守・運用の行と、その中身

見る場所：見積書の最後。「保守」「運用サポート」の月額。

削られたときの見え方：月額の行はあるが、中身の内訳が無い。あるいは「障害対応のみ」と小さく書かれている。

AI を使ったシステムの月額には、性質の違うものが 3 つ混ざる。API の実費（使った分だけ増える）、監視（止まっていないか、おかしな出力を出していないか）、改善（精度が落ちてきたときの調整）である。安い月額は、たいてい 3 つ目が入っていない。

質問文：「月額の内訳を、API 実費・監視・改善の 3 つに分けて教えてください。API 実費は想定件数と単価の計算根拠もお願いします。」

なお、こうした「別途」になりやすい費目は他にもある。まとめて確認したい場合はAI開発の見積書で「別途」になりやすい費用10個を使うとよい。

行が無いときの聞き方

5 つの点検で足りない行が見つかったら、値引きの交渉ではなく、範囲の確認として聞く。安くしろと言うと、さらに別の工程が消えるだけである。

そのまま使える文面を置いておく。

お見積もりありがとうございます。内容を比較するにあたり、範囲の確認をさせてください。

1. 要件定義（要件を確定させる作業）はどちらの担当でしょうか
2. 学習・検索に使うデータの整備はどちらの担当でしょうか
3. 精度の合格ラインと、判定に使う評価データの作成はどこに含まれますか
4. 受入テストの期間と、そこで出た指摘の修正は含まれますか
5. 月額の内訳（API 実費・監視・改善）を分けて教えてください

弊社で担当する前提の作業があれば、必要な作業量の目安も併せていただけると助かります。

「弊社で担当する前提のものがあれば教えてください」を必ず添えるのが要点である。これがあると、相手は工程を隠すより明示するほうが自然になる。

3 社の回答が揃ってから比べる

この 5 点への回答が出揃うと、最初に半額に見えた見積書の位置づけが変わる。よくあるのは、A（生産性）で 2 割、B（範囲）で 3 割安く、残りが C（未計上）だったという形である。C の分を発注側の作業として見積もり直せば、社内工数を含めた総額で比較できる。

そもそも各社に同じ条件が渡っていなければ、この比較は成立しない。条件を揃えて複数社に依頼する方法は無料で相見積もりにまとめてある。案件票として目的・データ・精度・保守・権利の条件を先に確定させ、同じものを各社へ渡す形にしているので、回答が割れたときに原因が範囲なのか単価なのかを切り分けやすい。

すでに見積書を受け取っている場合は、見積書チェックに項目を入力すると、上に挙げた抜けやすい費目が埋まっているかを機械的に判定できる。

まとめ

• 安い見積書を疑う必要はない。確認するのは消えた行の作業を誰がやるかだけである
• 点検する順番は、要件定義 → データ整備 → 精度検証と合格ライン → 受入テスト → 保守の内訳
• 聞き方は値引き交渉ではなく範囲の確認にする。「弊社で担当する前提があれば教えてください」を添える
• 比較は、発注側の社内工数を足した総額で行う。見積書の金額だけを並べても判断できない