AI開発の見積書で「別途」になりやすい費用10個。依頼時に含めさせる書き方

見積書の金額が 3 社で割れるとき、原因の多くは単価ではない。同じ作業が、ある社では本体に入っていて、ある社では「別途」に置かれていることである。「別途」は嘘ではない。ただし別途に置かれた作業は、いずれ誰かがやることになる。やるのが自社なら人件費として、開発会社なら追加契約として、必ず後から出てくる。

ここでは、AI 開発の見積書で「別途」「本見積に含まず」「お客様ご手配」と書かれやすい費用を 10 個挙げる。それぞれ、なぜ別途になるのか、金額の目安、そして見積依頼の時点で含めさせるための書き方を並べる。

仕切りのある整理箱と、外に置かれた札

1. データ整備

社内文書の収集、形式の統一、不要ページの除去、権限情報の付与。RAG でも OCR でも、ここが精度を決める。別途になりやすいのは、着手前に量も状態も分からないからである。

目安: 開発費の 10〜30%。文書が紙・画像・複数システムに散っている場合はこれを超える 依頼文: 「対象データは◯◯形式で約◯件です。前処理・形式統一を含めた工数を見積もりに計上してください。含めない場合は、前提となるデータの状態を明記してください」

2. 評価データの作成

精度を測るには、正解付きの問いと答えの組が要る。100〜300 件を業務担当者と一緒に作る作業で、多くの見積書では暗黙に発注側の仕事になっている。

目安: 数十万円規模。件数と業務の複雑さに比例する 依頼文: 「精度の評価に使うデータは、どちらが何件作成する想定か記載してください」

3. API 実費

LLM の利用料。テスト期間中の分と、本番稼働後の分の両方が抜けやすい。単価はモデルと提供区分で大きく変わる（OpenAIがGPT-6 Sol・Lunaを公開）。

目安: 案件差が最も大きい。月数千円から月数十万円まで 依頼文: 「開発期間中の API 利用料の負担者と、本番稼働後の月額試算（モデル名・提供区分・月間トークン量の前提つき）を記載してください」

4. 既存システム側の改修

AI 側は作れても、つなぐ相手（基幹システム・グループウェア・CRM）に手を入れないと動かないことがある。この改修は多くの場合、別のベンダーの担当になる。

目安: 相手側ベンダーの見積もり次第。AI 側の開発費と同規模になることもある 依頼文: 「連携先は◯◯（ベンダー: ◯◯）です。連携に必要な相手側の改修内容を洗い出し、必要な作業を文章で列挙してください」

5. データ移行・初期投入

既存の問い合わせ履歴、過去の帳票、旧システムのマスタを新しい仕組みに入れる作業。一度きりの作業なので「本体」から外れやすい。

目安: データ量と変換の複雑さ次第。数十万円から 依頼文: 「初期投入するデータの件数は◯件です。投入作業と、投入後の確認作業を見積もりに含めてください」

6. 社内教育・マニュアル

AI は「入れれば使われる」ものではない。使い方の説明会、業務手順の書き換え、質問の書き方の指導が要る。ここを飛ばした案件は稼働率が上がらない。

目安: 説明会と手順書で数十万円規模 依頼文: 「利用者は◯部門・約◯名です。操作説明会と利用手順書の作成を含めてください」

7. 監視の仕組み

エラー率、応答時間、コストの推移、おかしな出力の検知。本番で動かす以上は必要だが、「運用」の話なので初期見積もりから外れやすい。

目安: 初期構築で数十万円、月額の監視費は保守に含まれることが多い 依頼文: 「監視する項目、通知の宛先、異常時の一次対応の範囲を記載してください」

8. 稼働後の改善

AI システムは公開時点が完成ではない。想定外の質問、精度の落ちる領域、業務側の変更に合わせてプロンプトとデータを直し続ける必要がある。

目安: 月額保守の範囲に入るか、別途の改善枠を月◯時間で確保するかで分かれる 依頼文: 「稼働後 6 か月の改善対応について、保守に含まれる範囲と、別枠で確保する工数を分けて記載してください」

9. セキュリティ審査への対応

情報システム部門やグループ本社の審査、チェックシートへの回答、脆弱性診断、外部 API のリスク評価。社数と回数が読めないため、まず別途になる。

目安: 回答作業だけなら数十万円。診断を入れるとさらに乗る 依頼文: 「当社のセキュリティチェックシート（◯項目）への回答と、必要な場合の追加説明会への同席を見積もりに含めてください」

10. 追加の PoC・再検証

最初の PoC で判断がつかず、条件を変えてもう一度試す場面がある。これは「予定外」なので当然どの見積書にも入っていない。

目安: 初回 PoC と同規模か、それ以下 依頼文: 「PoC の結果が基準に届かなかった場合の追加検証について、実施可否の判断時期と概算費用の考え方を記載してください」

「別途」を消すのではなく、可視化する

10 個すべてを本体に押し込ませるのが正解ではない。データ整備のように、着手前に量が分からないものを無理に定額にさせると、金額に余裕を乗せられるか、範囲を狭く切られるかのどちらかになる。どちらも発注側の損になる。

やるべきことは 2 つである。

別途のままでよいものは、「別途」と書かせたうえで前提条件を文章にさせる。 「データは整形済みであることを前提とする」と書いてあれば、整形が必要だと分かった時点で誰の作業かがはっきりする
別途の項目にも概算のレンジを出させる。 「実費精算」だけでは予算が組めない。幅でよいので数字を置かせる

この 2 つをやると、見積書の総額は上がって見える。しかしそれは、これまで見えていなかった費用が表に出ただけである。稟議では、後から増えるより最初から入っているほうが通りやすい。

3 社に同じ条件で聞く

上の 10 項目は、各社に同じ文面で投げて初めて比較になる。1 社ずつ口頭で聞くと、聞き方の差がそのまま回答の差になってしまう。

無料の相見積もりでは、案件票に条件を書き込むと同じ内容が各社に渡る。データの状態、連携先、利用部門、セキュリティ要件の欄がそのまま上の 10 項目の前提になるので、返ってくる見積書の「別途」欄を横並びで読める。

見積書そのものの読み方は AI開発の見積書の読み方、返ってきた 3 社分を同じ土俵に乗せる手順は AI開発の相見積もりを比較する方法、揃えるべき条件の一覧は条件を揃える12項目にそれぞれまとめてある。