AI見積りは下書きまで｜過去の似た案件を引く見積り自動化の設計

見積りの依頼が届いて、担当者が最初にするのは計算ではなく、似た案件を思い出すことです。その思い出す作業を仕組みに任せ、見積りの作成を下書きまで自動化します。

業務自動化でできること一覧の記事では、製造業・建設業・物流業の30の業務を洗い出し、4つの処理の型に分けました。

• 取り込み型：形の決まっていない入力を読み取り、台帳に入れる
• 照合型：2つの台帳、または台帳と今日の日付を突き合わせる
• 下書き型：過去のデータを探し、文書の下書きを作る
• 実行型：発注・振込などの確定処理を実行する

この記事が扱うのは、3つ目の下書き型です。取り込み型はFAX受注の自動化の記事、照合型は数字合わせと期限チェックの記事で扱いました。

下書き型は、4つの型のなかでいちばん準備に時間がかかり、過去の案件が探せる形で残っていないと動きません。そのぶん、準備が済めば効き目の大きい型です。

見積り作成を代表例に、AI見積りのサービスや見積りソフトで足りるかの見極めから、設計図、n8nで組んだ形までを順に示します。

見積りも報告も返信も過去から引いて書く仕事

下書き型の業務は、どれも同じ形をしています。過去の記録を探し、それを材料に文書を作る仕事です。

次の表は、この記事で扱う下書き型の業務です。

業務	適性	恩恵	着手	人の接点
見積り作成	◎	売上・時間	要準備	画面
安全書類と法定帳票の作成	○	時間	要準備	承認
図面と仕様書の検索	○	時間	要準備	通知
商談・訪問報告の記録と要約	○	時間	すぐ	通知
問い合わせの振り分けと一次返信	○	時間	すぐ	承認
積算と拾い出しの補助	○	時間	要準備	画面

表の記号は次のとおりです。

• 適性：◎は恩恵が大きい、○は恩恵がある、△は限定的
• 恩恵：時間（時間短縮）、ミス（ミス防止）、売上（機会損失の防止）
• 着手：「すぐ」は手元のデータで始められる、「要準備」はマスタの整備や入力の習慣づけが要る
• 人の接点：無人／通知／承認／画面の4段階

探すことと書くことを一つの型にまとめたのは、探した結果がそのまま書く材料になるからです。

見積りなら、似た案件の明細と実績原価が材料になります。問い合わせの返信なら、過去の似た質問と回答が材料です。

探す相手と、できあがる文書の形が変わるだけで、流れは同じです。この型だけ人の接点に「画面」が2つ入る理由は、後の節で説明します。

見積りの時間は計算ではなく探す作業に消える

見積りに時間がかかるのは、計算が難しいからではありません。依頼が届くと、担当者はまず過去に似た案件がなかったかを考えます。

見つかれば、その明細を土台に今回の違いを足し引きします。見つからなければ材料費と工数を一から積み上げることになり、半日がかりになることもあります。

ところが、過去の案件はたいてい一か所にまとまっていません。見積書はフォルダに、図面は別のフォルダにあり、実績原価は会計ソフトか担当者の手元の表に散らばっています。

たとえば、ある工務店が「浴室の入れ替えとあわせて、脱衣所の床も張り替えたい」という依頼を受けたとします。担当者は過去の浴室改修の見積りを探そうとします。

過去のファイル名は「〇〇様邸ユニットバス交換」「水回りリフォーム」とばらばらです。ファイル名で検索しても、目当ての案件になかなか届きません。

結局、頼りになるのはベテランの記憶です。「去年の秋に似た現場があった」と覚えている人に聞けばすぐ見つかりますが、その人が休みの日には作業が止まります。

記憶には偏りもあります。印象に残った案件は思い出せても、似ているのに忘れている案件は拾えないため、見積りの質が担当者によってばらつきます。

探せないことの損は、時間だけではありません。想定より手間がかかった工事の教訓は実績原価に残っており、探せなければ次の見積りでも同じ読み違いを繰り返します。

見積りソフトとAI見積りで足りるかを確かめる

自分で組む前に、いま使っているソフトや既製のサービスで足りるかを確かめてください。既製の手段で足りるなら、この記事の仕組みは要りません。

見積りの作成を速くする手段には、次のようなものがあります。きれいに分かれるものではなく、1つの製品が複数を兼ねることもあります。

手段	できること	残る手間
Excelの見積りテンプレート	単価表を関数で引き、数量を入れれば金額が出る	土台にする過去の見積りは自分で探す
見積りソフト・販売管理ソフト	過去の見積りの複製、よく使う明細のかたまりの部品登録	名前や番号で特定できる案件しか呼び出せない
業種向けのAI見積りサービス	図面や仕様から見積りを出す（加工品などに多い）	対象の業種や品目が合わないと使えない。費用は契約による
汎用の生成AI（チャット）	依頼文の整理や、見積書の文面づくり	自社の過去案件と単価を知らないため、金額の根拠にならない

Excelで見積りを自動化するなら、単価表を別のシートに置き、品目を選ぶと単価が入る形が基本です。計算は速くなりますが、どの過去案件を土台にするかは人が探すままです。

同じ工事を繰り返す会社なら、見積りソフトの部品登録で足ります。部品を十数個作っておけば、あとは数量を入れ替えるだけで見積りができます。

工務店向けの見積りソフトの機能と料金は、次の記事で比べています。図面から見積りを出す一品一様の金属加工の進め方は、金属加工の受注・見積りをAIで自動化する記事で扱っています。

汎用の生成AIに見積りを手伝わせるときは、顧客名・単価・原価をどこまで渡すかを先に決めてください。決め方は生成AIに社内データを渡していい範囲にまとめています。

既製の手段では足りなくなるのは、次のような場合です。

• 案件ごとに条件が違い、部品の組み合わせでは表せない
• 呼び出したい過去案件を、名前や番号で特定できない
• 見積書は残っているが、実際にかかった費用が別の場所にある
• 見積りを作る人が複数いて、同じ条件でも金額が人で変わる
• ソフトに入る前の依頼メールの段階で、情報が散らばっている

共通しているのは、探すところでつまずいている点です。テンプレートの機能は、目当ての案件を自分で特定できる人のための道具です。

この記事の仕組みが受け持つのは、その手前です。案件の中身の近さで過去案件を引き当て、見積りソフトに入れる前の下書きを作ります。

見積書を作るソフトの機能は、そのまま使い続けて構いません。

逆に、この記事の仕組みでも効きにくいのは次の場合です。

• 過去の案件が数件しかない
• 毎回、前例のない一品ものを受ける
• 現地を見ないと数量が決まらない

どれも、引き当てる過去案件がないか、引いても下書きの材料にならない場合です。

見積りで自動化する範囲と人に残す判断

見積りの自動化では、仕組みに任せる範囲と、人に残す判断をはっきり分けます。仕組みに任せるのは探すことと下書きを作ること、人に残すのは金額の確定です。

作業	受け持ち	中身
似た案件を探す	仕組み（AI）	依頼の要点を取り出し、中身の近い過去案件を引く
違いを書き出す	仕組み（AI）	引いた案件と今回の違いを、作業の名前と数量で書き出す
金額を計算する	仕組み（単価表とルール）	数量に単価を掛け、下書きの金額を出す
金額を確定する	人	下書きを確かめ、必要なら直して確定する
見積書を出す	人	確定した金額で見積書を作り、取引先に出す

探す作業を仕組みに任せると、毎回同じ基準で過去の全件から引けます。担当者の記憶にある案件だけでなく、忘れていた案件も候補に入ります。

金額の確定を人に残すのは、見積りが会社としての約束だからです。取引先との付き合いの長さや現場の難しさは、過去の記録だけでは読み切れません。

そのため、この記事で設計する仕組みは見積書を送りません。下書きを作り、担当者の確認を待つところで止めます。

担当者の仕事は、ゼロから積み上げることから、下書きを確かめて直すことに変わります。判断に使う時間は残し、探す時間と書き写す時間を減らします。

このシリーズでは、専用の画面は原則として作りません。見積りが例外になるのは、承認するかしないかの2択では足りず、金額の一部を書き換える場面があるからです。

画面に出すのは、次の3つです。

• 下書きの明細と金額
• 引いた過去案件と、今回の案件との違い
• 金額の修正欄と、確定の欄

担当者が直すのは、金額の一部だけを想定しています。「搬入経路が狭いため、運搬費の行だけ上げる」といった手直しの範囲です。

下書きを丸ごと書き直す場面が続くなら、設計が合っていません。似た案件の引き方がずれているか、過去データが足りないかのどちらかなので、画面を作り込むのではなく、探す仕組みを見直します。

画面は専用に作らなくても構いません。台帳のスプレッドシートをそのまま使い、金額の欄と状態の欄を手で書き換える形でも動くため、まずはこの形で始めることをお勧めします。

見積りの下書きの設計図を描く

ここがこの記事の中心です。データの流れ、過去案件の持ち方、似た案件の引き方、台帳の項目と例外の順に見ていきます。

データの流れ

流れは、次の4つの段階に分かれます。

1. 夜のうちに、新しく登録された過去案件を探せる形にしておく
2. 依頼が届いたら、要点を取り出して似た案件を引く
3. 引いた案件を根拠に下書きを作り、案件台帳に書く
4. 担当者が金額を直し、確定する

図の点線から下は人の仕事です。仕組みが受け持つのは、似た案件を引いて下書きを作るところまでで、金額を決めるのは担当者です。

ポイントは、過去案件の置き場を2つに分けている点です。案件の中身そのものを持つ台帳と、探すための索引です。

索引は、夜のうちにまとめて作ります。依頼が届いてから作っていては、下書きが間に合わないためです。

過去案件の記録に持たせる項目

過去の案件は、案件ごとに一つの記録にまとめます。似ているかどうかを判断するには工事や製品の中身が要るため、見積書だけでは足りません。

1件の記録に持たせる項目は、次のとおりです。例の値は架空のものです。

項目	内容	例
案件ID	過去案件に振る番号	K-2025-0142
依頼の内容	何を、どこに、どれだけ	戸建の浴室改修。ユニットバス交換と脱衣所の床張り替え
仕様の要点	材質、工法、寸法など	1618サイズ、木造2階建ての1階
工程と日数	何日かかったか	解体から仕上げまで5日
見積りの明細と金額	そのとき出した見積りの金額	128万円
実績原価	実際にかかった費用	103万円
担当者のひとこと	手間取った点、次に気をつける点	既存配管の位置がずれており、半日余分にかかった

特に大事なのは、実績原価と担当者のひとことです。

見積りの金額だけを残すと、積算を読み違えた案件も「正解」として引かれてしまいます。実際にかかった費用があれば見積りとの差が分かり、担当者のひとことは次の担当者への申し送りになります。

置き場は、最初はスプレッドシートで構いません。1行を1案件にし、図面や写真はファイルの保管場所を列に持たせます。

全件を一度にそろえる必要はありません。直近の案件から登録し、新しい案件は完了のたびに1行足していきます。

当社の目安では、20件から30件ほどそろうと、似た案件が引き当たり始めます。

意味検索で似た案件を引く

似た案件を探すには、意味検索（セマンティック検索）を使います。言葉が一致するかではなく、意味が近いかで探す方法です。

たとえば「ユニットバス交換」と「浴室の入れ替え」は、言葉は違っても意味はほぼ同じです。意味検索なら、この2つを結び付けられます。

仕組みとしては、まず文章を数値の並び（ベクトル）に変えます。この変換に使うモデルを埋め込みモデル（embedding model）と呼び、意味の近い文章どうしは近いベクトルになります。

過去の案件は、あらかじめベクトルに変えて保存しておきます。新しい依頼が届いたら依頼文も同じ埋め込みモデルで変え、依頼のベクトルに近い過去案件を上から順に引くのがベクトル検索です。

ただし、意味の近さだけで決めると外れを引くことがあります。「木造か鉄骨か」「新築か改修か」のようにはっきり分けられる項目は、条件として別に絞り込みます。

意味検索と条件の絞り込みを組み合わせるのが基本です。どの項目で絞り込み、何件を引くかは業種によって変わります。

案件台帳の項目と例外の決めごと

作った下書きは、案件台帳に1行ずつ記録します。例の値は架空のものです。

項目	内容	例
案件ID	今回の依頼に振る番号	M-20261012-004
受付日時	依頼が届いた日時	2026-10-12 09:41
依頼内容	届いた依頼の要点	浴室改修と脱衣所の床張り替え
引いた案件	検索で引いた過去案件の番号	K-2025-0142／K-2024-0088
近さの度合い	いちばん近い案件との近さ	0.83
下書きの金額	仕組みが計算した金額	1,340,000
根拠	過去案件との違いと、使った単価	3階のため揚重を加算
明細	計算した行の内訳	揚重 1.0時間 × 4,000円 ほか
要確認	単価表にない品目など	防水シートの増し張り
外れの印	過去の実績から大きく外れた金額	（なし）
確定金額	担当者が確定した金額	（空欄）
状態	下書き／確認中／確定／保留／完了	下書き
処理済	確定後の処理を済ませた日時	（空欄）

下書きの金額と確定金額は、別の列に分けます。二つの差を見れば、どの種類の案件で下書きが外れたかを後から確かめられ、探し方や過去データを見直す手がかりになります。

近さの度合いも台帳に残します。この数字が低い案件ばかりなら、過去データが足りていないしるしです。

処理の決めごとは、次の1枚の表にまとめます。

項目	内容
トリガー	索引づくりは毎晩決まった時刻／下書きは依頼のメールを数分おきに見に行って拾う／確定後は5分おきに台帳を見に行く
入力	依頼のメール、過去案件台帳、単価表
処理	要点の取り出し → 似た案件の検索 → 違いの書き出し → 金額の計算 → 台帳への記録
出力	案件台帳への追記、担当者への通知
例外	似た案件がない、単価表にない品目、依頼の要点が取り出せない

例外は、先に扱いを決めておきます。

• 似た案件がない：下書きを作らず、担当者に「似た案件なし」と知らせる
• 単価表にない品目：その行だけ金額を空欄にし、要確認の印を付ける
• 依頼の要点が取り出せない：依頼の本文をそのまま添えて、担当者に回す

似た案件がないと分かること自体が、前例のない新しい仕事だという大事な情報です。推測の単価は入れず、空欄と印で担当者に知らせます。

見積りでAIを使う箇所と使わない箇所

下書き型は、取り込み型と並んでAIが効く型です。照合型はAIを使わずに組みましたが、下書き型でもAIに任せる範囲は狭く取ります。

金額の計算はAIにさせない

AIの役割は、似た案件を選ぶことと、今回の案件との違いを書き出すことです。金額の計算はAIにさせず、単価表と計算のルールで出します。

AIは、同じ入力でも少しずつ違う答えを返すことがあります。金額が毎回揺れると担当者は下書きを信用できず、取引先に根拠を聞かれても説明できません。

役割は、次のように分けます。

• AI：似た案件を選び、今回との違いを言葉と数量で書き出す
• 単価表とルール：書き出された数量に単価を掛け、金額を出す
• 人：金額を確かめ、必要なら直して確定する

単価表は、材料や作業ごとの単価を持つマスタです。計算のルールは会社ごとに違うため、仕組みの側で調整できるようにしておきます。

計算した金額は、引いた過去案件の実績原価や見積りの金額と比べます。差が大きいときは、外れの印を付けます。

高すぎる金額だけでなく、安すぎる金額にも印を付けます。高すぎれば受注を逃し、安すぎれば赤字になるためです。

どれだけ離れたら印を付けるかは、業種や案件の規模で変わります。配布するワークフローでは実績原価の1.5倍を超えるか0.8倍を下回ると印を付ける仮の値にしており、自社の過去データを見ながら決め直してください。

印は、人の確認を助けるためのものです。印が付いた金額が正しいことも、印のない金額が誤っていることもあるため、最終の判断を印に置き換えません。

AIへの指示は項目の定義として書く

AIを使う処理は、依頼の要点を取り出す処理と、過去案件との違いを書き出す処理の2つです。どちらも自由な文章は書かせず、取り出してほしい項目を一つずつ定義し、その形で返させます。

項目名	型	定義	迷ったときの扱い
工事の種類	文字	改修、新築、修理のいずれか	どれにも当てはまらなければ空にする
対象の場所	文字	工事をする場所。建物の階数を含める	書かれていなければ空にする
構造	文字	木造、鉄骨、鉄筋コンクリートのいずれか	読み取れなければ空にする
過去案件との違い	文字	引いた案件と今回で異なる点	違いが見当たらなければ「同等」と書く
増える作業	一覧	違いによって増える作業の名前と数量	数量が読めない作業は名前だけ返す
減る作業	一覧	違いによってなくなる作業の名前	なければ空の一覧を返す

この形で書く理由は、次の3つです。

1. 迷ったら空で返させる：推測で埋めた値と、読み取れた値を見分けられる
2. 返ってくる形を固定する：後ろの計算の処理を、毎回同じ書き方で済ませられる
3. 直す場所を絞る：うまく取り出せない項目は、その定義だけを書き直せる

3つの理由と、様式ごとの位置の説明を書かない理由は、FAX受注を読み取る取り込み型の記事で詳しく説明しています。見積りで違うのは、違いを「数量」で返させ、金額の欄を定義に入れない点です。

当社が使っている指示の全文は載せていません。取引先の様式と、自社の単価表の作りに合わせて書くものだからです。

見積りの下書きをn8nで組むとどうなるか

設計図を n8n で組むと、3つのワークフローに分かれます。過去案件を探せる形にする「索引づくり」、依頼から下書きを作る「下書きまで」、確定した見積りを過去案件に回す「確定後」です。

この記事では、設定の細かい手順は載せていません。過去の実績を意味検索で引いて値付けを裏づける実装の例は、見積りのRAGの開発記録にもあります。

四角の1つひとつが、小さな仕事を表しています。図の中の英語は画面に出るとおりの名前で、読み解く必要はありません。

確定後のワークフローは、5分おきに台帳を見に行き、確定した見積りを過去案件台帳に仮登録します。実績原価は空のままにし、工事が終わったときに人が埋めることで、確定した見積りが次の依頼の材料になります。

同じ行を二度回さないよう、仮登録の前に処理済の印を書きます。印を先に書く理由は、送る前に止める実行型の記事で詳しく扱っています。

n8n は、自社で動かす版（Community Edition）なら、自社の業務に使う分にはソフトの利用料がかかりません。AIと埋め込みモデルの利用料は別にかかるため、目安はAI API料金の比較で確かめてください。

この記事で押さえてほしいのは、次の4つの決めごとです。

過去の案件は夜のうちに埋め込んでおく

索引を作る処理は、依頼が届いたときには動かしません。毎晩、決まった時刻に動かします。

依頼が届いてから全件を埋め込み直していては、下書きが届くまでに何分も待つことになります。前の晩までに登録された案件が引ければ、実用上は足ります。

毎晩読み込むのは、新しく足された案件だけです。全件を毎回作り直すと、件数が増えたときに夜のうちに終わらなくなります。

配布するワークフローでは、索引の置き場にデータベースの PostgreSQL と、その拡張機能の pgvector を使っています。埋め込み終えた案件には台帳に印を書き、次の晩に入れ直さないようにしています。

登録と検索で同じ埋め込みモデルを使う

過去案件を登録するときと、届いた依頼で検索するときは、必ず同じ埋め込みモデルを使います。

違うモデルで作ったベクトルどうしは、比べられません。数値の並び方そのものが違うため、近さを計算しても意味のない数字が返ります。

モデルによって、ベクトルの数値の数（次元数）も違います。たとえば OpenAI の埋め込みモデルは、初期の設定で text-embedding-3-small が1,536、text-embedding-3-large が3,072で、どちらも次元数を縮めて使えます。

困るのは、次元数が同じ別のモデルどうしです。エラーが出ないまま、的外れな案件を引くか、「似た案件なし」ばかりになります。

モデルを新しいものに替えるときは、過去案件の索引も全件作り直します。配布するワークフローには作り直しの処理を入れていないため、替えるときは手で作り直してください。

似た案件がないときは下書きを作らない

検索の結果には、過去案件の番号とあわせて近さの度合いが付いてきます。近さが決めた下限に届かない案件しか引けなかったときは、下書きを作りません。

この場合は、担当者に「条件の近い過去案件が見つかりませんでした」と知らせるだけにします。

遠い案件を根拠に金額を出すと、的外れな下書きになります。担当者がそれを直すのは、ゼロから積み上げるより手間がかかります。

下限を決めずに、いつも上位3件を引く形にしていると、まったく似ていない案件まで根拠に使われます。下限は必ず決め、下回ったら下書きを作らないようにします。

配布するワークフローでは下限を0.6にしていますが、これは仮の値です。近さの数値の意味は埋め込みモデルと距離の取り方で変わるため、他社の数字をそのまま持ってきても合いません。

下限は、次の手順で決めます。

1. しばらく下限をゼロにして動かす
2. 引いた案件と近さの数値を、担当者に見てもらう
3. 「これは違う」と言われた案件の数値を集める
4. その数値の帯より上に下限を置く

配布するワークフローは意味の近さだけで引いており、木造と鉄骨のような条件の絞り込みは入れていません。分けたい条件があれば、引いた後に絞る処理を足します。

単価表にない品目は空欄で返す

AIが返すのは、増える作業と減る作業の名前と数量までです。数量に単価を掛ける計算は仕組みの中で行い、単価表はスプレッドシートに置いて、下書きを作るたびに読み込みます。

単価表にない品目が出たら、その行の金額を空欄にして要確認の印を付けます。近い品目の単価で代用させないことがポイントです。

代用すると、担当者はその金額が推測であることに気づけません。

通知は、この形で担当者に届きます。依頼の要点、引いた過去案件、下書きの金額、要確認の印を一度に確かめられ、担当者は台帳を開いて確定金額を入れ、状態を「確定」に変えます。

動かしてからの手間

この仕組みを組むときに手がかかるのは、組む作業ではありません。過去案件を集めて、1行ずつ整える作業です。

動かし始めてからの手間は、月に1回ほどの見直しです。下書きの金額と確定金額の差を並べ、外れが大きい案件の理由を確かめて、絞り込みの条件か過去データに反映します。

この見直しをやめると、単価の変動や扱う工事の変化に合わなくなり、下書きは少しずつ当たらなくなります。

下書き型を他の業務へ広げる

見積りで組んだ仕組みは、残りの業務にもほぼそのまま使えます。変わるのは、トリガーと探す相手とできあがる文書です。

次の表は、見積りとの違いをまとめたものです。

業務	トリガー	入力	探す相手	出力	例外
見積り作成	依頼メールの到着	依頼の本文	過去案件（明細・実績原価）	見積りの下書き	似た案件がない、金額が実績から外れる
安全書類と法定帳票	現場の登録	現場と作業員の情報	作業員の台帳	様式に流し込んだ書類	資格や保険の期限切れ
図面と仕様書の検索	社内からの質問	探したい内容	図面と仕様書	候補の一覧	候補が見つからない
商談報告の要約	報告の登録	訪問メモ	同じ取引先の過去記録	要約と次の一手	取引先が特定できない
問い合わせの一次返信	問い合わせの到着	問い合わせの本文	過去の質問と回答	返信の下書き	前例のない質問、クレーム
積算と拾い出しの補助	図面の受け取り	図面	過去の拾い出し結果	数量の下書き	図面が読み取れない

このうち、組み方が大きく変わるのは次の3つです。

1. 図面と仕様書の検索：探すところで止め、下書きは作らない
2. 安全書類と法定帳票：過去を探すより、台帳から様式に流し込む
3. 積算と拾い出しの補助：数量を人が直す前提で組む

図面と仕様書の検索は、「あの図面はどこか」と聞かれたときに候補を並べて返す仕組みです。探している本人が候補から正しいものを選べるため、人の接点は通知で足ります。

図面の版が変わったときに関係者へ知らせる仕組みは、別の業務です。こちらは照合型に入り、数字合わせと期限チェックの記事で扱っています。

安全書類は書く項目が決まっており、作業員の台帳から様式に流し込めばおおむね足ります。資格や保険の期限が切れた項目があれば、書類を作らずに印を付けて知らせます。

それでも下書き型に入れているのは、特記事項の欄があるからです。そこだけは、過去の似た現場の書き方を引いて下書きします。

積算と拾い出しは、図面から数量を読み取る処理に精度の限界があります。仕組みが数量の下書きを作り、担当者が画面で確かめて直すため、見積りと同じく人の接点が「画面」になります。

検索と下書きでつまずかないための事前対策

下書き型の自動化は、組むことより、動かし始めてからつまずくことが多い型です。先に知っておきたい3つの箇所と、その対策を挙げます。

過去データの表記ゆれと欠け

同じ材料や工法でも、担当者によって書き方が違います。「SUS」と「ステンレス」のような表記ゆれは意味検索である程度は吸収できますが、型番や略称は、意味の近さでは拾えないことがあります。

対策は、よく使う項目の書き方を決めておくことです。材質や工法の列は自由記述をやめ、選択肢から選ぶ形にそろえます。

書き方をそろえる進め方は、属人化を解消してからAIに任せる手順の記事にまとめています。

実績原価が欠けた案件は、検索から外さず「実績原価なし」の印を付けて残します。外すと、最近の案件ほど引けなくなるためです。

「似ている」の基準が現場とずれる

仕組みが似ていると判断した案件が、ベテランには「現場の構造がまるで違う」と見えることがあります。ベテランの見積りの力は、今回との細かな違いを見抜けるところにあるからです。

対策は、ベテランに実際の検索結果を見てもらい、ずれを集めることです。ずれの理由を言葉にできれば、検索の前の絞り込み条件に足せます。

たとえば「木造と鉄骨は別物だ」と言われたら、構造の列を絞り込みの条件に加えます。理由を条件に足すたびに、引く案件が現場の感覚に近づきます。

この作業は、ベテランの判断の軸を会社に残す作業でもあります。本人が辞めれば記憶は会社から消えますが、案件の記録と担当者のひとこと、言葉にした判断の軸は残ります。

判断の軸の洗い出し方は、町工場の属人化を洗い出す記事にまとめています。

古い単価をそのまま引いてしまう

過去案件に残っている単価は、そのときの単価です。資材費や人件費が変わっていれば、過去の金額をそのまま使うと原価割れの見積りになります。

対策は、過去案件から金額を写さないことです。過去案件から使うのは数量と作業の中身までにし、金額はいまの単価表で計算し直します。

単価表は、仕入れ値や労務費が変わったらすぐ書き換える運用にしてください。下書きの金額は、単価表より新しくはなりません。

まとめ

見積りの自動化で最初に取り組むのは、計算の仕組みではありません。過去の案件を、いつでも探せる形に整えることです。

代表例の見積り作成では、次の点を押さえました。

• 過去案件には、見積りの金額だけでなく実績原価と担当者のひとことを残す
• 意味検索と条件の絞り込みを組み合わせて、似た案件を引く
• 単価表にない品目は空欄と印で知らせ、推測の単価を入れない
• 下書きの金額と確定金額の差を、月に1回ほど見直す

この記事で設計したワークフローは、JSONで配布しています。記事で説明した中心の流れだけを組んだもので、条件での絞り込みや見積書の書式への流し込みは、運用に乗せるときに足す前提です。

ワークフローのJSONを受け取る

つなぐAIの選び方は、社内業務をAIに任せるときのLLM選択で比べています。ほかの業務の自動化の向き不向きは、業務自動化でできること一覧にまとめています。

見積りのあとに届く注文を取り込む設計は、取り込み型の記事で扱いました。下書きが確定したあと、発注や請求を承認つきで送る実行型の設計は、次の記事で扱います。