見積書の作成をAIに手伝わせたい、という相談で最初に確認するのは、AIの性能ではなく単価表と過去案件のデータがどう保管されているかです。結論から言えば、単価表が「条件つきの金額」まで表現できていて、過去の見積が検索できる形で残っていれば、AIは十分に役に立ちます。逆に、単価が担当者の頭の中にあり、過去の見積がメールの添付ファイルに散っている状態では、どんなモデルを選んでも精度は上がりません。この記事では、整えるべきデータの粒度、実装で詰まりやすい箇所、そして「どこまでAIに任せ、どこから人が判断するか」の線引きを順に説明します。
見積AIは具体的に何をしてくれる？
「AIが見積書を作る」と聞くと、要望を入力すれば完成した見積書が出てくる姿を想像しがちですが、実務で安定して動くのはもっと手前の工程です。受注開発の現場で成立しやすいのは、おおむね次の4つに分かれます。
| 役割 | AIがやること | 人が残す判断 |
|---|---|---|
| 引き当て | 問い合わせ文や仕様書から、該当しそうな単価表の品目を候補として挙げる | 候補の採否、品目の過不足 |
| 類似案件の提示 | 過去の見積から条件が近いものを探して並べる | どの案件を基準にするか |
| 数量・工数の下書き | 類似案件の数量を参考に初期値を埋める | 今回固有の条件による増減 |
| 文章の生成 | 備考欄、前提条件、除外事項の文面を整える | 約束してよい内容かの確認 |
重要なのは、金額を決めるのはAIではないという点です。AIは「過去にこういう条件でこの金額を出していました」と材料を並べる役であり、最終的な単価や値引きは人が確定させます。この線引きを曖昧にしたまま導入すると、出てきた数字の根拠を誰も説明できない見積が社外に出ることになります。
単価表はどこまで整えれば使える？
多くの中小企業の単価表は、表計算ソフトで「品目名」と「単価」の2列になっています。これだけでは、AIは条件の違いを区別できません。実際の現場では、同じ品目でも数量帯、納期、客先区分、オプションの有無で金額が変わるはずです。その条件を列として明示することが、整備作業の中心になります。
最低限そろえたい列
- 品目コード：名称の表記ゆれ（「設置工事」「据付工事」など）を吸収する鍵になる
- 品目名と別名：客先が使う呼び方、社内の略称を別名列にまとめて入れておく
- 単位：式、台、m、人日など。単位が混在すると数量の下書きが破綻する
- 適用条件：数量の下限・上限、対象となる客先区分、繁忙期かどうか
- 有効期間：いつからいつまでの単価か。改定の履歴を上書きで消さない
- 備考：条件を文章で補足する欄。AIはここを読んで候補の説明文を作れる
このうち、見落とされやすいのが有効期間です。単価表を上書き更新していると、半年前の案件を参照したときに現在の単価が適用され、過去の見積と数字が合わなくなります。古い情報が混ざって回答が狂う問題は見積に限らず起きるもので、社内文書検索AIが古い規程を答える原因は更新設計にあるという話と構造は同じです。履歴を残し、「いつ時点の単価か」を指定して引ける形にしておきます。
「担当者の頭の中」をどう列にするか
整備で一番時間がかかるのは、ベテランが暗黙に調整している部分の言語化です。たとえば次のような場面を想定してください。遠方の現場は移動分を上乗せする、長年の取引先には端数を丸める、急ぎの案件は割増を入れる——こうした調整は単価表に書かれていないことが多いものです。
全部を一度に数式化しようとすると止まります。おすすめは、まず「調整ルールの一覧」を文章で書き出すことです。10〜20項目も挙げれば主要なものは出そろいます。そのうえで、金額への影響が大きく、条件がはっきりしているものから列に落としていきます。残りは備考欄に文章のまま置き、AIには「この条件に該当するので確認してください」と注意喚起させる形で十分機能します。
過去の案件データは何件あれば参考になる？
「何件必要か」に一律の答えはありませんが、判断の目安は件数より条件の広がりです。同じような案件が500件あっても、新しい引き合いが過去に例のない条件なら役に立ちません。逆に、扱う案件の型が5種類なら、各型について数件ずつでも「似た案件」を示す役には立ちます。
過去案件を使える形にするために、最低限そろえたいのは次の情報です。
- 引き合い時の元の要望文（メール本文、仕様書、聞き取りメモ）
- そこから作った見積の明細（品目、数量、単価、金額）
- 受注したかどうかと、失注した場合の理由
- 最終的な実績（かかった工数、追加費用の有無）
このうち「元の要望文」が最も重要で、かつ最も失われやすい情報です。見積の明細だけが残っていても、AIは「どんな文章が来たらこの明細になるのか」を学べません。逆に言えば、要望文と明細が対になって残っているなら、件数が少なくても引き当ての精度はかなり上がります。
そして失注理由は、価格の妥当性を考える材料になります。高くて負けたのか、納期で負けたのか、そもそも条件が合わなかったのか。これを記録していない会社は多いのですが、記録を始めるだけで次の見積の判断材料が増えます。AI導入の前に、まずこの1列を追加するところから着手するのも現実的です。
実装で詰まりやすいのはどこ？
設計の段階で先に手を打っておきたい箇所を挙げます。いずれも、動き始めてから気づくと手戻りが大きいものです。
| 詰まる箇所 | 起きること | 先に決めること |
|---|---|---|
| 表記ゆれ | 同じ品目が別物として扱われ、候補に出ない | 品目コードを主キーにし、別名を登録する仕組み |
| 単位の混在 | 「1式」と「10台」が比較できず数量が狂う | 単位の正規化ルールと、換算できない組み合わせの扱い |
| 端数処理 | 人が作った見積と1円ずれ、信頼を失う | 切り上げ・切り捨て・四捨五入をどの段階で行うか |
| 税の扱い | 税抜・税込が混在し、合計が合わない | 内部は税抜で統一し、表示時に計算する設計 |
| 値引きの入れ方 | 明細値引きと合計値引きが二重に効く | 値引きを適用できる階層を1つに限定する |
| 帳票の体裁 | 既存のフォーマットと項目が合わず、再入力が発生 | 既存の見積書テンプレートを出発点にする |
特に端数と税は軽視されがちですが、見積の信頼を一番手早く壊します。金額計算そのものはAIに任せず、確定したロジックを通常のプログラムで実装するのが安全です。AIが出すのはあくまで「品目と数量の候補」であり、計算は毎回同じ結果になる仕組みに乗せる。この分担の考え方は、表計算AIと分析ツールを再現性で選ぶという観点と共通しています。
なお、見積書そのものの保存方法については、電子帳簿保存法や、適格請求書等保存方式（いわゆるインボイス制度）に関連して社内の運用ルールが定められている場合があります。システムの保存先や出力形式を決める前に、自社の経理担当や顧問税理士に、現行の運用と照らして確認しておくことをおすすめします。制度の要件は改正されることがあるため、構築時点の最新の内容を確認してください。
精度はどう確かめて、どう運用する？
「だいたい合っている気がする」で導入を判断すると、後から揉めます。先に評価用のデータを用意するのが確実です。やり方はシンプルで、過去案件から20〜50件を選び、要望文だけをAIに渡して、人が作った実際の見積とどれだけ一致するかを見ます。
見るべき指標は、金額の一致率よりも次の2つです。
- 品目の抜け漏れ：本来必要な品目が候補に出てこなかった件数。これが多いと、担当者は結局ゼロから作り直すことになり、使われなくなります
- 余分な品目：不要な品目が混ざった件数。こちらは削除で済むため、抜け漏れより軽い問題として扱えます
この評価は一度きりではなく、単価表を改定したとき、裏側のAIモデルが更新されたときにも回します。同じ入力で同じ品質が出るかを継続的に確認する仕組みづくりについては、評価データセットの作り方と運用で詳しく扱っています。
運用面では、AIの提案に必ず「根拠」を添えさせる設計にしてください。「過去案件Aの明細を参照」「単価表の品目コードXを適用」といった形で出典を示せば、担当者は確認が早くなり、間違いにも気づけます。根拠が示せない提案は採用しない、というルールを最初に決めておくと、現場の信頼が保たれます。
まとめ
見積AIの成否は、モデル選定ではなくデータ整備で8割方決まります。着手の順番として現実的なのは次の流れです。
- 単価表に適用条件と有効期間の列を足し、履歴を上書きしない形にする
- 過去案件の要望文と見積明細を対で残す。失注理由の記録を始める
- ベテランの調整ルールをまず文章で書き出し、効きの大きいものから列に落とす
- 金額計算と端数・税の処理はAIではなく確定ロジックに任せる
- 過去案件20〜50件で品目の抜け漏れを測り、改定のたびに測り直す
この整備は、AIを入れなくても単独で価値があります。単価の根拠が可視化され、見積のばらつきが減り、担当者が替わっても同じ水準の見積が出せるようになる。AIはその整った土台の上で、候補出しと下書きを速くする道具として効いてきます。逆の順番——先にツールを選んでからデータを合わせにいく——は、たいてい途中で止まります。まずは手元の単価表を開いて、条件を表す列がいくつあるかを数えるところから始めてください。