なぜ見積もりは待たされ、そして高くなるのか
AIを使った業務システムの開発を外部に頼もうとして、「見積もりが出てくるまで3週間かかった」「出てきたら想定の倍だった」という経験はないでしょうか。このとき、発注側は「要件をもっと詳しく書くべきだったのか」と考えがちです。しかし開発会社の側から見ると、止まっている理由は要件の詳しさではなく、判断材料がないことであることが多いのです。
見積もりとは、工数の予測に「わからない部分のリスク」を上乗せした金額です。わからない部分が多いほど、開発会社は保険をかけます。つまり発注側が事前に情報を出すほど、保険の幅は小さくなり、金額は下がり、提示も速くなる。これは駆け引きではなく、単純な構造です。
この記事では、すでに社内にあるのに出されていない資料を中心に、見積もり依頼の前に何を揃えると開発が速く進むのかを整理します。新しく作文する必要があるものは最小限です。
最優先で揃える5つの資料
まず、業種を問わず効く基本の5点です。完璧でなくてかまいません。「今ある状態のまま出す」ことに意味があります。
| 資料 | 中身 | これがないと起きること |
|---|---|---|
| 1. 現状の業務フロー | 誰が、何を受け取り、何をして、誰に渡すか。手書きのメモや既存のマニュアルで可 | 開発会社がヒアリングだけで想像し、後で「そんな例外作業があったのか」と手戻りする |
| 2. 実際の入力・出力サンプル | 処理対象の帳票、メール、PDF、CSVの実物（マスキング済み）を各5〜10件 | データの汚れ方が読めず、前処理工数を多めに見積もられる |
| 3. 処理件数と繁閑 | 月あたり何件、ピーク時は何件、1件あたり現在何分 | インフラ構成とAPI費用の試算ができず、保守的（=高め）な構成を提案される |
| 4. 使っている既存システムの一覧 | 名称、バージョン、API連携の可否、社内のどこが管理しているか | 連携工数が「不明」として大きく計上される、または後から追加費用になる |
| 5. 予算レンジと時期 | 「300万〜500万」「第3四半期に本番」程度の幅で可 | 提案が過剰になるか過小になり、提案し直しで2〜3週間失う |
特に効くのは2番です。AIが絡む開発では、入力データの実物を見た瞬間に見積もりの精度が跳ね上がります。たとえば次のような場面です。「請求書をAIで読み取りたい」という依頼で、サンプルを見たら8割が自社フォーマットで、残り2割が取引先ごとにバラバラの手書きだった――この構成比がわかるかどうかで、見積もりは数十万円単位で変わります。
なお「予算を先に言うと足元を見られる」という懸念はよく聞きます。しかし予算レンジを伏せたまま進むと、開発会社は当て推量で提案を作り、ずれていればやり直しになります。上限だけでも伝えたほうが、結果として得られる提案の質は上がります。
AI案件で追加すべき3つの資料
ここからはAI特有の話です。通常のシステム開発と違い、AIは「動く／動かない」ではなく「どれくらい当たるか」で評価されます。そのため、精度に関する合意がないまま進むと、検収の段階で揉めます。
正解データ（教師データ）
「正解データ」とは、AIに判断させたい内容について、人間が出した正しい答えの例のことです。請求書読み取りなら「この画像からは、この金額とこの日付が取れるのが正解」という対応表です。
これを事前に数十件分つくっておくと、開発会社は精度の目処を立てやすくなります。業務に詳しい人が1〜2時間、Excelに打ち込むだけでも十分な出発点になります。
受け入れ基準（どこまで当たれば合格か）
「精度95%以上」とだけ書かれた要件は、実はほとんど機能しません。何を分母にした95%なのか、間違えたときに誰がどう気づくのか、までセットでないと検証できないからです。次のように書き分けると設計が進みます。
| 観点 | 曖昧な書き方 | 見積もりが進む書き方 |
|---|---|---|
| 対象 | 請求書を読み取る | 自社フォーマットの請求書（月800件）の金額・日付・取引先名の3項目 |
| 合格ライン | 精度95% | 3項目すべて正しい件数が、全体の90%以上 |
| 外れたとき | （記載なし） | 自信度が低い件は人が確認する画面に回す。確認対象は全体の15%以内 |
右の列まで書けていると、開発会社は「人が確認する画面」の工数も最初から見積もりに入れられます。逆にこれがないと、本番直前に「チェック画面が必要だった」と判明し、追加開発になります。
失敗したときの業務影響
AIが間違えたときに何が起きるかを、1行でいいので書いておきます。「社内資料の下書きがずれる程度」なのか「顧客への請求額が狂う」なのかで、必要な検証の厚みはまったく変わります。前者ならシンプルな構成で早く安く作れますし、後者なら二重チェックの仕組みが要ります。この一文があるだけで、過剰品質も品質不足も避けられます。
法務・セキュリティは「先に社内で決めておく」が最速
AI開発で見積もりが止まる典型的な原因が、データの扱いに関する社内承認です。開発会社は待つしかないので、ここは発注側が先に動くほど速くなります。
確認しておきたい主な論点は次のとおりです。
- 社外のAIサービスに業務データを送ってよいか：情報システム部門やセキュリティ規程で、生成AIの利用可否がどう定められているかを先に確認します。クラウド事業者のリージョン（データの保管国）指定が必要かも含めて
- 個人情報が含まれるか：含まれる場合、第三者提供や委託の扱いをどう整理するか。個人情報保護法（2020年改正・2022年4月全面施行）では委託先の監督が求められるため、委託という整理にするのか匿名化して渡すのかを先に決めておくと設計が速くなります
- 成果物とデータの権利：経済産業省の「AI・データの利用に関する契約ガイドライン」（2018年公表、2019年に1.1版）では、学習用データや学習済みモデルの権利帰属を契約で明確にする考え方が示されています。契約書を一から考えるより、この枠組みを土台にしたほうが早く合意できます
- 社内のAI利用方針：総務省・経済産業省の「AI事業者ガイドライン」（2024年4月公表）には、AIを利用する事業者が留意すべき事項が整理されています。自社に方針がない場合、ここを参照して暫定方針を作っておくと、プロジェクトごとの議論を省けます
いずれも詳細は原典の確認が必要ですが、「どの論点を誰が決めるのか」を先に割り振っておくだけでも、見積もり段階の往復は大きく減ります。
明日からできる、2時間の準備セット
すべてを揃えてから相談しよう、と考えると永遠に着手できません。現実的には、次の順で2時間ほど手を動かせば、見積もり依頼の質は十分変わります。
- （20分）処理対象のデータを10件、フォルダにまとめる。きれいなものだけでなく、例外的なものを必ず混ぜる
- （20分）現在の作業手順を、箇条書き10行で書く。「誰が」を各行に入れる
- （20分）月間件数と1件あたりの所要時間を、担当者に聞いて数字で書く
- （30分）「このAIが間違えたら誰が困るか」「どこまで当たれば現場は使うか」を現場担当者と5分ずつ話し、メモにする
- （30分）社外クラウドにデータを出してよいか、情報システム担当に口頭で確認し、回答を1行で記録する
この5点をまとめた数ページのメモを添えて相談すると、開発会社は初回の打ち合わせで具体的な構成案を出せます。逆にこれがないと、初回はヒアリングだけで終わり、見積もりは早くても2回目以降になります。
まとめ
見積もりのスピードと精度は、発注側が出した情報量にほぼ比例します。しかも必要なのは、立派なRFP（提案依頼書。発注側が要件と条件をまとめ、提案を募るための文書）ではなく、すでに社内にある生のデータと数字です。
押さえどころを再掲します。
- 基本5点（業務フロー、データ実物、件数、既存システム、予算レンジ）は、今ある状態のまま出す
- AI案件では、正解データ・受け入れ基準・失敗時の影響の3点を足す
- 精度は「分母」と「外れたときの運用」までセットで書く
- データの社外持ち出し可否と権利の整理は、発注側が先に社内で決めておく
- 完璧を待たず、2時間分の準備で一度相談する
開発会社に渡す資料は、相手のためだけのものではありません。これらを書き出す過程で、「そもそもAIでやるべきか」「どこまで自動化すれば現場が楽になるか」が社内で言語化されます。見積もり依頼の準備は、実はプロジェクトの要件定義の第一歩そのものです。まずはサンプルデータを10件、フォルダに集めるところから始めてみてください。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
