見積書の作成をAIで自動化する｜過去案件から価格の根拠を出す手順と、営業が決める値引きの範囲

見積書づくりで時間がかかるのは、書類の体裁ではない

見積書の作成と聞くと、書式へ数字を流し込む作業を思い浮かべます。ですが実際に時間を取られているのは、そこではありません。いくらで出すかを決め、その金額の説明を用意する部分です。

先方から条件を聞いた後、担当者は似た案件を探します。去年の同じような規模の案件はいくらで出したか、そのときに値引きはしたか、結果はどうだったか。過去のファイルや案件管理の記録を開いて回り、価格表の該当箇所を確かめ、少し違う条件をどう反映するかを考える。この探して確かめる部分が、1件あたりの時間の多くを占めます。

そして厄介なのは、この作業が担当者の頭の中で完結することです。出来上がった見積書には金額しか残らないため、なぜその金額になったかは本人以外に分かりません。後から「この案件は安すぎたのでは」と振り返ろうにも、根拠が残っていないので検証できません。

自動化の対象にすべきなのは、この探して確かめて根拠を残す部分です。書式へ流し込む作業は既存の販売管理システムでもできますし、そもそも時間がかかっていません。

工程を分けて、どこまで任せるかを決める

見積の作成をひとかたまりの作業として扱うと、任せる範囲を決められません。先に工程へ割ります。

根拠を組み立てるところまでを機械に置き、値引きと最終金額の決定は営業が持ちます。
根拠が薄い項目は金額を出さずに戻します。

工程1の条件の確定は、思っているより重い作業です。先方からのメールや商談の記録には、数量が書かれていなかったり、期間が「来期から」といった形でしか決まっていなかったりします。この状態のまま先へ進めると、抜けた条件を機械が適当に補って金額が出てきます。足りない条件は埋めずに、足りないものとして返す設計にします。

工程2の分解は、見積の行に当たる単位へ割る作業です。ここが粗いと、過去案件と照合する相手が見つかりません。「一式」でまとめられた過去の見積は、金額は残っていても比較の材料になりにくいためです。

工程3と4が、この記事で扱う中心です。工程5と6は人が持ちます。理由は後述します。

どの工程を通常のプログラムで処理し、どこに生成AIを使い、どこに人の承認を置くかの分け方は「AIエージェントにどこまで任せるか」で扱っています。工程1の条件の抜けの判定や工程4の判定は、生成AIではなく決まった条件の判定で書いたほうが、挙動が安定します。

金額の根拠に何を使うか

金額の根拠には複数の取り方があり、どれを主に使うかで設計が変わります。1つに決めるというより、どの場面でどれを使い、食い違ったらどちらを優先するかを先に決めます。

根拠の種類	使える条件	向いている場面と限界
価格表・標準単価	品目や役務の単価が社内で定義されている	条件が定型に収まる案件ではそのまま使える。表に無い組み合わせが来ると止まる
原価に利益を乗せる	仕入や外注の費用を案件単位で引ける	下限の判定に使える。相場からかけ離れた金額になることがある
投入する時間から積む	作業の種類ごとの単価と、必要な時間の見当が付く	役務が中心の案件で使える。時間の見当そのものが人の判断になる
過去の類似案件の提示額	過去の見積が条件付きで残っている	実際に出した金額なので説明しやすい。当時の事情が見えない
過去の類似案件の決着額	値引き後の金額と結果が残っている	通った金額が分かる。断られた案件が記録に残りにくく、安い側へ偏る
先方の予算・他社の提示	商談の記録に残っている	参考にはなるが根拠にはならない。金額の説明には使わない

価格表を主にし、過去案件を補助にするのが扱いやすい形です。価格表は社内で合意された値なので、そこから外れるときだけ説明が要ります。逆に過去案件を主にすると、過去の判断がそのまま引き継がれ、古い水準のまま出し続けることになります。

原価は、提示額を決めるためではなく下限を確かめるために使います。組み上がった金額が原価を下回っていないかを機械で見て、下回っていれば人へ戻します。ここは判断ではなく計算なので、確実に働かせられます。

過去の決着額を使うときは、偏りに注意が要ります。決着した案件だけを集めると、通った金額ばかりが並びます。断られた見積も同じように残しておくと、どのあたりから通らなくなるかが見えます。案件の記録が担当者の手入力に依存していて欠けが多い場合は、先に記録の埋まり方を確かめます。商談の記録をどこまで自動で埋められるかは「CRMの自動入力・自動記録」で扱っています。

過去案件を根拠に使えるかは、件数とばらつきで見る

過去案件を引いてくる仕組みを作ると、必ず「似ているとは言いがたいものが1件だけ出てくる」場面に当たります。そこで金額を出してしまうと、根拠があるように見えて実際には無い状態になります。

判定は、モデルが返す確からしさではなく、集まった実績の状態で行います。

見る観点	確かめ方	薄いときの扱い
件数	条件の近い過去案件が何件集まったか	1件しか無ければ、その1件として示し金額は確定させない
ばらつき	集まった案件の単価がどれくらい離れているか	大きく離れていれば幅で示し、中央の値を代表として出さない
新しさ	直近の案件が含まれているか	古いものだけなら、価格表の改定があったかを確かめる経路へ回す
条件の一致	数量・期間・対象範囲が揃っているか	ずれている項目を並べ、どこが違うかを見える形にする
価格表との差	過去案件の単価が現在の価格表から離れていないか	離れていれば、当時の特別な事情の有無を人に確かめる
原価との関係	組み上げた金額が原価を下回っていないか	下回れば、金額を出さずに止める

件数は、多ければよいわけではありません。条件を緩めれば件数は増えますが、緩めた分だけ似ていない案件が混ざります。何を緩めて件数を稼いだかを記録に残し、画面に出します。「数量の条件を外して5件」と書かれていれば、読む側はその5件をどう扱うか判断できます。

ばらつきが大きいときに平均や中央値を代表値として出すのは避けます。平均が実際の案件のどれとも一致しない値になり、しかも一見もっともらしく見えるためです。幅で示し、上下の端がどの案件かを併記します。

判定の閾値を最初から細かく決めようとしなくて構いません。まずは件数とばらつきだけで分け、実際に使いながら直します。合格ラインの決め方と本番へ出す前の確認については「AIエージェントの精度をどう評価するか」が参考になります。

根拠が薄いときに、どう出して人へ戻すか

自動化の成否は、根拠が十分なときの挙動より、薄いときの挙動で決まります。薄いときに何らかの金額を出す作りにすると、使う側は表示された数字を疑わなくなります。

戻し方の原則は3つです。

金額の欄を埋めない。 推定値を入れて「参考値」と添えるのではなく、空のまま出します。埋まっていると、そのまま提出される経路が必ず生まれます。空欄なら、誰かが必ず手を入れます。

足りないものを具体的に書く。 「根拠不足」とだけ表示されても、受け取った側は何をすればよいか分かりません。「この仕様に該当する単価が価格表に無い」「条件の近い案件が1件のみ」「直近2年の実績が無い」のように、何が足りないかを書きます。人が次に取る動作が決まる粒度まで落とします。

部分的に埋まった状態で渡す。 見積の全行が根拠不足になることはまれです。根拠のある行は根拠とともに埋め、足りない行だけを空で出します。全部やり直しになるより、残った行だけを埋めるほうが早く終わります。

画面に出す情報は、金額だけにしません。その金額の元になった案件と価格表の該当箇所を、金額の隣に置きます。 担当者が確認するときの動作が、探し直しではなく照合で済むためです。ここを省くと、結局は元のファイルを開いて確かめることになり、作業時間が変わりません。

根拠として示した案件が実在するかは、機械側で確かめます。案件の識別子で引けたものだけを表示し、引けないものは出しません。文章として説明を組み立てる部分に生成AIを使う場合、この確認を挟まないと、もっともらしい案件名が書かれた説明文が出てくることがあります。

値引きと最終金額は営業が持つ

ここまでの工程をすべて自動化しても、値引きと最終金額の確定は人が持ちます。技術的にできないからではなく、判断の材料が仕組みの外にあるためです。

決めること	判断に要るもの	どちらが持つか
標準の金額と、その根拠	価格表、過去案件、原価	機械が組み立てる
原価を下回っていないか	案件単位の原価	機械が確かめて止める
値引きするかどうか	先方との関係、競合の状況、今期の状況	営業が決める
値引きの幅	決裁の範囲、過去の対応との整合	営業が決め、範囲を超えれば上長
提示のタイミングと出し方	商談の進み方	営業が決める
最終金額の確定と提出	上のすべて	営業が決め、社内の承認を通す

値引きの判断材料の多くは、記録に残っていません。取引を続けたい相手かどうか、前回こちらの都合で無理を言ったか、今回は数量が少ないが次につながるか。こうした事情は商談の記録には書かれず、書かれていても後から読んで判断できる形になっていません。

一方で、値引きの範囲を機械で見ることはできます。 決裁の範囲を超えていないか、原価を下回っていないか、同じ相手へ過去に出した条件と食い違わないか。これらは条件の判定で書けます。判断は人、範囲の確認は機械という分け方にすると、承認の手前で気づけます。

値引きの記録は残します。いくら引いたかだけでなく、なぜ引いたかを選択肢から選ぶ形で残しておくと、次に同じ相手や似た案件を扱うときの材料になります。理由の記録が無いと、過去案件を根拠に使う工程が「値引き後の安い金額」だけを学ぶことになります。

どこから着手し、先に何を揃えるか

全工程を一度に対象にすると、価格データの整備が終わるまで何も動きません。順序があります。

根拠を集めて示すところまでを最初の対象にする。 金額を確定させず、価格表の該当箇所と条件の近い過去案件を集めて並べる。担当者が探していた時間がここで短くなり、判断そのものは変わらないため、比較的早く使い始められます。

次に、定型に収まる案件の金額を組み立てる。 価格表だけで金額が出る範囲に限り、下書きまで作ります。例外の多い案件を最初から含めると、ほとんどの案件が人へ戻る状態になります。例外の割合をどう数えるかは「例外処理が多い業務をAIで自動化する」で扱っています。

最後に、対象の幅を広げる。 人が直した箇所の記録を見て、直しがほとんど出ない種類の案件から範囲を広げます。

着手の前に揃えておくものは次の通りです。

揃えるもの	何が必要か	無い場合
価格表	現行版がどれか分かり、改定の履歴が追える	担当者ごとの手元の表になっていないかを先に確かめる
過去の見積	金額だけでなく、そのときの条件が読める	これから出す見積の記録の取り方を先に決める
案件の記録	結果（成立・不成立）と、値引きの有無が分かる	不成立の案件が消えていないかを確かめる
原価の引き方	案件単位で仕入・外注の費用を引ける	下限の確認だけは別の方法を決めておく
決裁の範囲	誰がいくらまで値引きを決められるかが決まっている	文書化されていなければ、自動化の前に決める
直す担当	価格表の改定や条件の変化を反映する人がいる	決まっていないと数か月で使われなくなる

このうち最初に詰まるのは、たいてい価格表です。正式な表はあるが実務では別の表を使っている、あるいは表に無い組み合わせを都度判断している、という状態が珍しくありません。この場合、自動化の前に価格の決め方を整理する作業が先に来ます。それ自体が有用な作業なので、遠回りではありません。

対象業務の選び方や要件の書き方を含む全体の進め方は「AIエージェント開発の進め方」にまとめています。受け取った見積書を読み取ってデータにする側の設計は「見積書の取り込みをAIで自動化する」で扱っています。

まとめ：見積作成を自動化するときの要点

時間がかかっているのは書式へ数字を入れる作業ではなく、過去案件と価格表を探して金額の根拠を組み立てる部分。自動化の対象はここに置く
工程は、条件の確定、構成要素への分解、価格表と過去案件の照合、根拠の強さの判定、値引きと最終金額の決定、承認と発行に分ける。前半4つが任せられる範囲
根拠は価格表を主、過去案件を補助にする。原価は提示額を決めるためではなく、下限を下回っていないかを確かめるために使う
過去案件が使えるかは、モデルが返す確からしさではなく、集まった件数・ばらつき・新しさ・条件の一致で判定する。ばらつきが大きいときに平均を代表値として出さない
根拠が薄いときは金額の欄を埋めず、何が足りないかを人が次に動ける粒度で書く。根拠のある行だけを埋めた状態で渡す
金額の隣に元の案件と価格表の該当箇所を置き、確認が探し直しではなく照合で済むようにする。実在を確かめられない案件は表示しない
値引きと最終金額は営業が持つ。判断材料が記録の外にあるため。ただし決裁の範囲を超えていないか、原価を下回っていないかは機械で確かめられる
着手は根拠を集めて並べるところまでに絞り、定型に収まる案件から金額の組み立てへ広げる。先に揃えるのは価格表の現行版、条件が読める過去の見積、案件の結果の記録、決裁の範囲

Augueでは、社内に散らばった価格表や過去案件を根拠として引けるようにし、どこまでを機械に任せどこから人が決めるかを含めてAIエージェントを設計・開発しています。自社の見積業務のどの工程から着手できるか整理したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

見積作成の機能を持つ販売管理システムやSFAを既に使っている場合、どう組み合わせますか？

既存システムを置き換えず、金額の欄が埋まる手前に根拠を組み立てる工程を足す形が扱いやすくなります。販売管理システムは決まった金額を書面にして残すことは得意ですが、いくらで出すかを過去の実績から導く部分は空いていることが多いためです。作った金額と根拠を既存システムの項目へ渡し、書面の発行と履歴の保管はそのまま任せます。

過去案件のデータが社内に溜まっていない場合、何から始めればよいですか？

直近で出した見積の控えを、条件が読める形で集めるところから始めます。金額だけの一覧では根拠に使えないため、数量や期間、対象範囲、先方の要望のうち金額に効いたものを一緒に残します。過去分をさかのぼって整えるより、これから出す見積の記録の取り方を先に決めるほうが早く使える状態になります。

社内の価格情報を外部のAIサービスに渡すことになりますか？

設計次第で分けられます。価格表や過去の成約価格を検索して候補を絞る部分は社内の仕組みで処理し、文章としての説明を組み立てる部分だけを生成AIに任せる構成にすれば、渡す情報を絞れます。どこまで外に出るかは導入前の審査項目になるため、検索と文章化の境目を先に決めておきます。

見積の精度は、どうやって確かめてから任せますか？

一律の合格ラインは出せません。確かめるのは提示金額が当たったかではなく、示された根拠が実在の案件や価格表と一致しているかです。過去に出した見積を入力として同じ手順で組み立て直し、根拠に挙げた案件が条件の近いものかを人が確認する形で測ります。ここが合わない状態で件数を広げると、直しの手間が増えます。

新規性の高い案件でも使えますか？

使える範囲は狭くなります。似た案件が見つからない場合は金額を出さず、比較できる案件が無いことを示して人へ戻すのが正しい挙動です。それでも、構成要素へ分解する工程と価格表の該当箇所を引く工程は使えるため、根拠のある部分と人が値を置く部分を分けた状態まで下書きできます。