リフォームの問い合わせを受けたときに、過去の施工事例から住まいと工事内容の近い事例を探し、提案と概算の根拠を事例番号付きで示す

処理の起点を決める

営業が現地調査の後に、問い合わせの内容と調査のメモを検索画面に貼り、「近い事例を探す」を押したときに動かします。 問い合わせの段階で、カタログを送れば済むものや、工事の対象外のものも混ざります。現地調査に進んだものだけを対象にします。

もう1つの起点は、完工の締めです。 工事が終わり、最終の金額が確定した現場を、毎週の締めのあとに索引に足します。追加工事の記録は完工までに写真の説明に書かれるので、完工の時点で取り込めばそろいます。

見積の段階の金額は入れません。 入れるのは、追加工事を含めて確定した最終の金額です。見積の金額と最終の金額の差が、追加工事の大きさになります。

入力データを集める

質を決めるのは、3行目です。 金額だけの索引なら、見積のソフトの検索と大差がありません。追加工事が付いているから、提案の前に読む意味があります。

5行目の掲載の同意は、写真を見せる範囲を決めます。 検索の結果は社内で使いますが、顧客への提案に写真を載せられるのは、同意のある事例だけです。 同意の無い事例は、金額と経緯の根拠としてだけ使います。

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

集計と検索は、同じ filter で行います。 上位10件と集計の母数が違うと、「上位の事例はどれも百万円台なのに、分布の中央値はもっと高い」という読みにくい結果になります。 filter には建物の種類・工事の種類・施工の年（直近5年）を入れます。

検索の形は、次のようになります。

POST /reform-cases/_search?search_pipeline=case-hybrid
{
  "size": 10,
  "_source": ["case_id", "summary", "building_type", "structure", "building_age",
              "work_type", "quantity", "cost_by_trade", "final_amount",
              "extra_works", "completed_on", "photo_consent"],
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "summary": "在来浴室 タイル ユニットバス 木造 寒い 段差" } },
        { "knn": { "summary_vector": { "vector": [0.0], "k": 30 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "building_type": "detached" } },
            { "term": { "work_type": "bath_conventional_to_unit" } },
            { "range": { "building_age": { "gte": 15, "lte": 35 } } },
            { "range": { "completed_on": { "gte": "now-5y" } } }
          ]
        }
      }
    }
  }
}

集計は別の問い合わせで、size を0にして件数と分布だけを取ります。

{
  "size": 0,
  "query": { "bool": { "filter": [ "（検索と同じ条件）" ] } },
  "aggs": {
    "amount_pct": { "percentiles": { "field": "final_amount", "percents": [25, 50, 75] } },
    "extra_reasons": { "terms": { "field": "extra_works.reason", "size": 10, "missing": "none" } }
  }
}

terms 集計の missing を指定すると、項目が空の事例を1つのバケットにまとめて数えられます。 追加工事が無かった事例の件数がそのまま出るので、「28件のうち19件は追加工事なし」と読めます。 指定しないと、追加工事が無い事例は数えられません。

AIへ渡す前に整形する

1. 事例の文書へのまとめ … 工事台帳・見積書・写真の説明を、事例番号で1つにします
2. 工事の種類の区分へのそろえ … 「浴室改修」「UB交換」「お風呂リフォーム」を bath_conventional_to_unit（在来から）と bath_unit_to_unit（ユニットからの交換）のように、元の状態で分けた区分にします
3. 追加工事の理由の取り出し … 写真の説明の文から、Claude API で理由の区分・金額・分かった時点を取り出します
4. 金額の確定値の確認 … 最終の金額が無い事例は索引に入れません。見積の金額だけの事例を混ぜると、分布が下にずれます
5. 数量あたりの金額 … 外壁の塗装の㎡あたり、床の張り替えの㎡あたりのように、数量で割った金額をプログラムで出して持たせます
6. 個人を特定する情報の除去 … 顧客の氏名・住所・電話番号は入れず、地域は市区町村までにします。写真の説明に書かれた表札や近所の情報も取り除きます
7. 事例の説明文と埋め込み … 建物の条件・工事の内容・経緯を200字程度の文にし、Titan Text Embeddings V2 で埋め込みを作ります

2番目が、検索の質を決めます。 「ユニットバスの交換」と一言で書かれた事例でも、在来の浴室からの工事は、解体と土台・配管の工事を含み、金額も追加工事の起きやすさも違います。 元の状態で区分を分けないと、条件の違う事例が同じ分布に入ります。

埋め込みのモデルは、日本語の対応を確かめてから選びます。 Titan Text Embeddings V2 は英語に最適化され、日本語を含む多言語に対応するとされています（100を超える言語はプレビュー）。言語をまたぐ問い合わせは結果が劣るとされているので、事例の説明文と問い合わせはどちらも日本語でそろえます。

AIに処理させる

させるのは3つです。問い合わせから検索の条件を取り出すこと、写真の説明から追加工事の理由を取り出すこと、検索と集計の結果から提案の論点を並べることです。

3行目を「させない」に置くのが、この設計で大事なところです。 古い事例の金額を見せると、AIは親切に「物価の上昇を考えると」と補正します。その補正には根拠がありません。 施工の年を必ず添えて見せ、今の単価で積み直すのは積算の担当の仕事にします。

指示内容を固定する

あなたは住宅リフォーム会社の営業部で、提案を作る営業のために、
過去の施工事例から提案の論点と概算の根拠を整理する立場です。
金額を決めないでください。決めるのは営業と積算の担当です。

【やること】
1. 問い合わせの条件と、検索で見つかった過去の事例を読んでください。
2. 次の論点ごとに、過去の事例から読み取れることを書いてください。
   工事の範囲／製品の選び方／工期／追加工事の可能性
3. 各論点に、根拠にした事例番号（case_id）を必ず付けてください。
4. 金額の幅を書くときは、渡された集計の値（25・50・75％点）をそのまま使い、
   集計に使った件数を添えてください。
5. 追加工事は、渡された理由ごとの件数をそのまま使ってください。
6. 問い合わせの要望が、近い事例の工事内容と違う点を挙げてください。

【厳守事項】
- 金額を自分で計算・補正しないでください。平均を出さないでください。
- 古い事例の金額を、今の金額に直して書かないでください。施工の年を添えてください。
- 検索結果に無い事例番号を示さないでください。
- 建物の劣化や構造について、診断や断定を書かないでください。
  「解体後に確認が要る」と書くだけにしてください。
- 問い合わせに書かれていない条件を推測しないでください。「記載なし」としてください。
- 集計の件数が10件未満の論点は、confidence を low にしてください。

【問い合わせの条件】{inquiry}
【検索結果（事例の文書、上位10件）】{cases}
【集計（同じ絞り込みでの金額の分布と追加工事の件数）】{aggregations}

「平均を出さない」を明記しないと、上位10件の金額の平均を書きます。 集計の値を渡していても、手元の事例のほうが具体的なので、そちらで計算したくなります。

「解体後に確認が要る、と書くだけ」を書くのは、診断を防ぐためです。 追加工事の件数を渡すと、AIは「この家も土台が傷んでいる可能性が高い」と書きます。現地を見ていないAIに、その家の状態は分かりません。 書けるのは、似た事例で何件起きたかまでです。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "inquiry": {
    "building_type": "", "structure": "", "building_age": "",
    "work_type": "", "quantity": "", "requests": [], "concerns": []
  },
  "issues": [
    {
      "topic": "scope | product | duration | extra_work",
      "finding": "",
      "evidence_cases": [],
      "counts_used": "",
      "confidence": "high | low",
      "differs_from_request": ""
    }
  ],
  "amount_basis": {
    "p25": "", "p50": "", "p75": "", "sample_size": "", "years": ""
  },
  "consented_cases": []
}

1つ目の理由は、論点ごとに根拠の事例番号を照らせることです。 evidence_cases の番号が検索結果に含まれているかを、プログラムで確かめます。 含まれていない番号があれば、その論点は表示しません。

2つ目は、amount_basis を集計の値と照らせることです。 AIが写した25・50・75％点と件数が、集計の結果と一致するかをプログラムで確かめます。一致しなければ、集計の値で上書きして表示します。

3つ目は、consented_cases で提案に載せられる事例が分かることです。 掲載の同意がある事例だけを並べ、提案書に写真を載せるときは、この一覧から選びます。

システムへ連携する

人が確認する

1. 条件を確かめる … 検索の前に、取り出された建物の条件と工事の種類を見ます。元の状態（在来かユニットか）が違うと、結果がまるごと外れます
2. 根拠の事例を開く … 論点に付いた事例のうち、少なくとも上位の2〜3件は見積書と写真を開いて読みます
3. 施工の年を見る … 金額の幅を顧客に伝える前に、事例の年を確かめ、今の単価での積算を担当に頼みます
4. 追加工事の伝え方を決める … 件数を顧客にどう伝えるかは、営業が現地の状態を見て決めます
5. 提案と概算を記録する … 顧客に伝えた概算の幅と、根拠にした事例番号を残します

2番目を省かないでください。 論点の整理は要約です。同じ在来浴室の交換でも、2階の浴室か、窓の位置を変えたかは、写真を見ないと分かりません。

目標は、180件をならして1件8分です。 条件の確認に2分、根拠を読むのに4分、提案のメモを作るのに2分という見込みです。

例外に対処する

7行目の区別が、分布の信頼を左右します。 説明を書かない担当の現場が「追加工事なし」に数えられると、起きやすさが実際より低く見えます。 取り込みの段で、説明の無い事例を印で分けます。

記録を残す

• 問い合わせと取り出した条件、営業が直した条件
• 検索の条件（filter、重み）と、上位の事例番号と点数
• 集計の結果（分布と件数）
• Claude API の出力と、使った指示の版
• 表示しなかった論点と理由
• 顧客に伝えた概算の幅と、最終の見積の金額

最後の行が、次の検索の質を上げます。 概算の幅と最終の見積が残れば、概算がどれくらい外れたかを、工事の種類ごとに見直せます。