現地調査メモと過去の類似見積から、工事見積の明細の初期案を作る

処理の起点を決める

営業が見積作成を実行したときを起点にします。現地調査メモの保存をきっかけに自動で走らせる構成は取りません。

理由は、メモが書きかけの状態で明細が作られると、数量の空欄が大量に並んで使い物にならないためです。また、同じ顧客で複数の案を出す場合、営業がどの前提で見積を作るかを選ぶ必要があります。営業が「この前提で作る」と決めた時点を起点にします。

入力データを集める

4番目の「作成ルール」を明文化することが、この構成の準備の中心です。 ベテランが頭の中で持っている「3階以上でエレベーターが使えなければ、階段での搬入費を載せる」といったルールを書き出します。ルールで決まるものはルールで入れ、AIには「ルールにないが、類似案件には載っていた項目」を拾わせます。

データの取得方法を決める

調査メモ： 自由記述だと条件の取り出しが安定しません。調査メモの書式を決めることが最初の作業です。 工事種別、面積（平米）、階数、エレベーターの有無、作業可能時間帯、既存設備の撤去の有無、といった項目を必須欄にし、それ以外を自由記述にします。

過去見積： 販売管理システムから明細データを書き出します。案件ごとの条件（工事種別・面積・階数など）が明細データと別に管理されている場合は、案件番号で結合します。条件がデータとして残っていない過去見積は、件名から条件を推定するしかなく、精度が落ちます。 直近2〜3年分に絞るほうが、単価の新しさの面でも扱いやすくなります。

類似案件の探し方： 条件（工事種別・面積の帯・階数・作業時間帯）で絞り込んだうえで、明細の項目構成が近いものを選びます。受注した見積を優先します。 失注した見積には、競合に負けた単価や、顧客に不要と言われた項目が含まれているためです。

単価表： Excelの単価表を読み込みます。項目コードで引けるように整えておきます。

Excelへの書き込み： Python のライブラリ openpyxl でテンプレートを開き、明細行を書き込みます。注意点として、openpyxl でブックを読み込むときの data_only は、数式のセルから「数式そのもの（既定）」を取るか「Excelが最後にそのシートを読んだときに保存された値」を取るかを切り替えるものです。数式の計算はExcel側で行われる前提で設計し、合計金額はプログラム側でも計算して別に持ち、照合に使います。

AIへ渡す前に整形する

1. 調査メモの必須欄の確認 … 工事種別・面積・階数が空欄なら処理を止め、営業に入力を求めます。条件が欠けたまま類似案件を探すと、まったく違う規模の見積が参照されます
2. 単位の統一 … 面積が「坪」と「平米」で混在していることがあります。平米に揃えます
3. 過去見積の単価の除去 … 類似案件の明細をAIに渡すとき、単価と金額の列を落として渡します。 AIに過去の金額を見せないことで、金額を推測で入れる余地を無くします
4. 項目名の正規化 … 過去見積では同じ項目が「養生費」「養生」「床養生一式」と揺れています。単価表の項目コードに寄せる対応表を作ります
5. 作成ルールの適用 … ルールで決まる付帯項目は、AIに渡す前にプログラムで入れておきます

3番が、この構成でもっとも効く前処理です。

AIに処理させる

2回に分けて呼び出します。

1回目：調査メモから条件を取り出す。 自由記述の部分から、「搬入は階段のみ」「土日のみ作業可」「既存のパーティションは再利用」などの条件を拾い、決められた項目に整理させます。

2回目：明細行の候補を作る。

AIに金額・単価・掛率を扱わせません。 出力にも金額の欄を持たせません。

指示内容を固定する

あなたは内装工事会社の見積担当を補佐する担当者です。
今回の現地調査の条件と、条件の近い過去見積の明細構成（金額は含みません）を渡します。
今回の見積に載せるべき明細行の候補を作ってください。

【厳守事項】
- 単価、金額、掛率、値引きを出力しないでください。
  それらは別の仕組みで計算します。
- 数量は、調査メモの記載から計算できる場合だけ入れてください。
  計算に使った記載（例「面積 120平米」）を quantity_basis に書いてください。
  記載から決まらない数量は null にし、needs_confirmation に入れてください。
- 項目は、下の単価表の項目コードに対応付けてください。
  対応するコードが無い項目は item_code を null にし、理由を書いてください。
  新しい項目コードを作らないでください。
- 過去見積に載っているという理由だけで項目を加えないでください。
  今回の調査メモの条件から必要と言える理由を reason に書いてください。
- 過去見積に載っていたが今回は不要と判断した項目は、excluded に理由とともに書いてください。
- 労務費・法定福利費など、人件費にかかわる項目を省略・削減する提案をしないでください。

【今回の調査条件】
{survey_conditions}

【作成ルールで既に入っている項目】
{rule_based_items}

【条件の近い過去見積の明細構成（上位5件、金額なし）】
{similar_quotes}

【単価表の項目一覧（コード・名称・仕様・単位のみ）】
{price_items}

「数量は調査メモの記載から計算できる場合だけ入れる」の1行が、この構成でもっとも重要です。 これが無いと、AIは類似案件の数量を「このくらいだろう」と流用します。見積の数量が現地と合わないまま提出されると、赤字の工事になるか、顧客からの信頼を失います。

出力形式を固定する

{
  "survey_id": "",
  "conditions": {
    "work_type": "",
    "area_m2": 0,
    "floor": 0,
    "elevator": true,
    "work_hours": "",
    "carry_in": ""
  },
  "line_items": [
    {
      "item_code": "",
      "item_name": "",
      "spec": "",
      "unit": "",
      "quantity": null,
      "quantity_basis": "",
      "reason": "",
      "source": "rule | similar_quote | survey"
    }
  ],
  "excluded": [
    { "item_name": "", "reason": "" }
  ],
  "needs_confirmation": [],
  "similar_quote_ids": []
}

source で、その行がルールから入ったのか、類似案件から拾ったのか、調査メモから直接拾ったのかを区別します。営業が確認するとき、類似案件由来の行を重点的に見れば済むようにするためです。

数量は数値型、または null で返させます。「約120」のような文字列が入ると計算で壊れます。

システムへ連携する

プログラム側で次の処理を行い、Excelの見積書テンプレートへ書き込みます。

販売管理システムへの登録は、上長の承認後に行います。 下書きの段階で登録すると、未確定の見積が実績として集計に混ざります。

人が確認する

全件、人が確認します。確認は2段階です。

1. 営業 … 明細の過不足、数量、空欄の数量を確認する。顧客に確認すべき条件を洗い出す
2. 上長 … 単価・掛率・値引き・最終金額を確認し、提出を承認する

理由は、見積が顧客への約束になるためです。提出した見積の金額と範囲は、受注後の工事の採算と、追加請求の可否を決めます。

確認を速くするための設計が要ります。

• 類似案件から拾った行と、数量が空欄の行を色分けする
• 各行の reason と quantity_basis を、見積書とは別のシートに並べる
• 参照した類似案件の見積書へのリンクを付ける
• 除外した項目も一覧で見せる（抜けではなく意図的に外したことが分かるように）

例外に対処する

記録を残す

• 調査メモと、取り出した条件
• 参照した類似案件の番号
• AIが出した明細の候補と、除外した項目
• 営業が追加・削除・修正した行
• 上長が承認した最終版と提出日
• 受注・失注の結果

4番目と6番目を突き合わせると、この構成の実力が見えます。 営業が毎回追加している項目は、作成ルールに入れるべき項目です。受注した見積で除外されていた項目は、本当に不要だったのか、後から追加請求したのかを確認します。

見積の履歴には原価や利益にかかわる情報が含まれます。保管場所の閲覧権限を営業部と管理部門に限定します。