中古車買取店が、過去の査定と業者オークションでの落札の記録から車種・年式・走行距離・状態の近い車を探し、査定額の根拠を示して担当者による差を減らす

処理の起点を決める

査定士が査定の表を保存したときに動かします。 評価点と減点の項目が入った時点で保存するので、車を見終わってお客様に提示するまでのあいだに、根拠のメモができています。

評価点や走行距離を直して保存し直したら、検索もやり直します。 前の検索の結果は、査定番号ごとに版を付けて残します。どの入力で出した根拠かが、後から分かるようにします。

もう1つの起点は、落札の結果の確定です。 業者オークションで落札が確定し、結果が出品の記録に入ったら、毎晩その日の分を索引に足します。流札の記録も入れます。 流札は「その価格では売れなかった」という情報で、分布の外に別の段で示します。

入力データを集める

質を決めるのは、2行目の減点の項目です。 年式と走行距離だけなら、相場の検索の端末と大差がありません。「右フロントドアに凹み」「内装にタバコの臭い」のような減点の項目が残っているから、近い車との状態の違いを示せます。

4行目の査定のときの記録は、査定士だけが見るものです。 自社がその車をいくらで買い取ったかは、仕入の値段です。店舗のほかのスタッフには見せない項目にします。

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

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

POST /auction-results/_search
{
  "size": 10,
  "query": {
    "function_score": {
      "query": {
        "bool": {
          "filter": [
            { "term": { "model_code": "6AA-XXXX" } },
            { "term": { "repair_history": false } },
            { "term": { "sold": true } },
            { "exists": { "field": "mileage_km" } },
            { "exists": { "field": "grade_score" } }
          ],
          "should": [
            { "term": { "trim": "G" } },
            { "term": { "color_group": "white_pearl" } }
          ]
        }
      },
      "functions": [
        { "gauss": { "reg_months": { "origin": 600, "offset": 3, "scale": 12 } }, "weight": 2 },
        { "gauss": { "mileage_km": { "origin": 48000, "offset": 3000, "scale": 15000 } }, "weight": 2 },
        { "gauss": { "grade_score": { "origin": 4.0, "offset": 0, "scale": 0.5 } }, "weight": 1 },
        { "gauss": { "sold_on": { "offset": "30d", "scale": "90d" } }, "weight": 1 }
      ],
      "score_mode": "avg",
      "boost_mode": "sum"
    }
  },
  "aggs": {
    "near": {
      "diversified_sampler": { "field": "vehicle_hash", "shard_size": 30, "max_docs_per_value": 1 },
      "aggs": {
        "price": { "percentiles": { "field": "hammer_price", "percents": [25, 50, 75] } }
      }
    }
  }
}

reg_months は、初度登録年月を月数にした値です。 年と月を別の項目にすると、「2021年12月」と「2022年1月」が1年離れているように扱われます。月数にすれば、1か月の差として近さを測れます。

sold_on の減衰には origin を書いていません。 日付の項目では省くと現在の日時になり、落札から30日以内は満点、そこから90日で点数が半分になります。 古い落札の記録が上に来にくくなり、第3章の（c）を点数の側で防ぎます。

shard_size は、シャードごとに標本に入れる上位の件数です。 索引をいくつかのシャードに分けているなら、標本の大きさはシャードの数だけ増えます。標本の件数は応答の doc_count で確かめ、少なすぎる分布は表示しません。

落札の記録の索引の1件は、次のような形にします。

{
  "record_id": "AU-2026-08-11873",
  "appraisal_id": "AP-2026-07-30412",
  "vehicle_hash": "車台番号のハッシュ",
  "model_code": "6AA-XXXX",
  "trim": "G",
  "reg_months": 598,
  "mileage_km": 51200,
  "grade_score": 4.0,
  "repair_history": false,
  "color_group": "white_pearl",
  "deductions": ["右フロントドア 凹み 小", "リアバンパー 擦り傷"],
  "listed_on": "2026-08-04",
  "sold_on": "2026-08-11",
  "sold": true,
  "hammer_price": 1830000,
  "store": "S-07"
}

AIへ渡す前に整形する

1. 記録のつなぎ … 査定番号と出品番号で、査定の記録と落札の結果を1件にします
2. 車台番号のハッシュ化 … 車台番号はそのまま入れず、ハッシュにして同じ車の記録をまとめるためだけに使います
3. 年式の換算 … 初度登録年月を月数にします
4. 区分のそろえ … 色の名前を色の系統に、グレードの書き方を型式ごとの区分にそろえます
5. 減点の項目のそろえ … 査定の表の減点の項目を、部位・種類・程度の区分にそろえます
6. 範囲の確認 … 走行距離・評価点・落札額が、ありうる範囲に入っているかを確かめます

換算と範囲の確認はプログラムで行います。 Claude API の構造化出力は、JSON スキーマの minimum・maximum のような数値の制約に対応しておらず、使うと 400 のエラーになります。 範囲はスキーマで縛れないので、取り込みの処理で止めます。

6番目で止まる記録の多くは、入力の誤りです。 走行距離の桁を1つ多く入れた記録が索引に入ると、その記録だけが遠い車として外れるのではなく、分布の端を引っぱります。

AIに処理させる

させるのは、近い車ごとに、プログラムが出した違いを査定士と店長が読める文にすることだけです。 探すのは OpenSearch、違いの計算はプログラム、金額を決めるのは査定士です。

2行目がいちばん起きやすい失敗です。 走行距離の差と落札額の差が並んでいると、AIは親切に「1万kmあたり約5万円の差」と割り算を書きます。2台の差を走行距離だけのせいにした数字で、根拠がありません。 査定士がその数字を口にすると、お客様への説明が根拠の無い数字になります。

指示内容を固定する

あなたは中古車の買取店で、査定士が査定の根拠をまとめるのを手伝う立場です。
検索で見つかった近い車の落札の記録を、査定士と店長が読める根拠のメモにしてください。
買取の金額を決めたり、提案したりしないでください。決めるのは査定士と店長です。

【やること】
1. 近い車ごとに、査定する車との違いを、渡された diff の値を使って書いてください。
2. 減点の項目は、査定する車にだけあるもの、近い車にだけあるものに分けて並べてください。
3. 落札額の分布は、渡された四分位と標本の台数をそのまま書いてください。
4. 説明ごとに、根拠の記録番号と落札日を付けてください。

【厳守事項】
- 金額を提案しないでください。「○万円が妥当」「○万円で買い取れる」と書かないでください。
- 違いを金額に換算しないでください。
  「1万kmあたり」「1点あたり」「この減点で○万円」のような計算を書かないでください。
- 差や平均を自分で計算しないでください。渡された値だけを使ってください。
- 相場が上がる・下がるといった予想を書かないでください。
- 標本の台数が5台未満なら、分布について「標本が少ない」とだけ書いてください。
- 検索結果に無い記録番号・車種を書かないでください。

【査定する車】{target}
【近い車（記録番号・違い・減点の項目）】{neighbors}
【落札額の分布（四分位・標本の台数）】{distribution}

「金額に換算しない」を例を挙げて禁じているのは、言い方を変えて書くからです。 「金額を提案しない」とだけ伝えると、提案ではない体裁で「走行距離の差は○万円程度の影響と考えられる」と書きます。換算の言い回しそのものを並べて禁じます。

「標本が少ない」の一文を決めているのは、3台の四分位を書かせないためです。 3台でも四分位の数字は出ます。数字があると、査定士はそれを相場として使ってしまいます。

出力形式を固定する

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

{
  "appraisal_id": "",
  "neighbors": [
    {
      "record_id": "",
      "sold_on": "",
      "hammer_price": 0,
      "diffs": [ { "item": "", "target": "", "neighbor": "", "diff": "" } ],
      "deductions_only_target": [],
      "deductions_only_neighbor": [],
      "explanation": ""
    }
  ],
  "distribution": { "p25": 0, "p50": 0, "p75": 0, "sample_size": 0, "note": "" },
  "unsold_count": 0
}

1つ目の理由は、record_id を照らせることです。 出てきた番号が検索結果に含まれているかを、プログラムで確かめます。 含まれていない車は表示しません。

2つ目は、数の値をプログラムが入れられることです。 hammer_price・diffs・distribution の数は、検索と計算の結果をプログラムが入れ、AIの出力で上書きしません。 AIが書くのは explanation と note だけです。数を文の中で写し間違えていないかも、プログラムで照らします。

3つ目は、unsold_count で売れなかった記録を見せられることです。 近い車が流札していれば、その価格では売れなかったということです。分布の横に流札の台数を並べ、査定士が強気の金額を付けすぎないようにします。

システムへ連携する

人が確認する

1. 入力を確かめる … 型式・初度登録年月・走行距離・修復歴の入力が車検証と車に合っているかを見ます。型式を誤ると、別の車の記録が並びます
2. 近い車の記録を開く … 上位3台は記録を開き、減点の項目と写真を見ます
3. 提示額を決める … 根拠のメモと車の状態から、査定士が提示額を決めます
4. 店長が了承する … 根拠のメモと提示額を並べて見て、了承するか差し戻します
5. 結果を残す … 提示額と、成約したか、断られたかを査定の記録に残します

2番目を省かないでください。 説明は要約です。同じ「凹み 小」でも、写真を見ると板金が要る凹みかどうかが分かります。

目標は、1,200件をならして1件5分です。 入力の確認に1分、近い車の記録を開くのに2分、店長への説明に2分という見込みです。

例外に対処する

5行目は、検索のついでに見つかるものです。 同じ車台番号のハッシュで、前に出品したときの走行距離がいまより多ければ、メーターの交換か入力の誤りか、それ以外かを確かめる必要があります。 判断はせず、印を付けて店長に回します。

記録を残す

• 査定する車の入力と、入力を直した版
• 検索の条件（絞り込み、origin・offset・scale・重み）と、上位の記録と点数
• 落札額の分布と標本の台数
• Claude API の出力と、使った指示の版
• 査定士が決めた提示額と、店長の了承か差し戻しか
• 成約したか、断られたか。成約した車の後の落札額

最後の行が、この構成の答え合わせになります。 買い取った車が実際にいくらで落札されたかを、査定のときの分布と比べます。分布の中央から大きく外れる車が続く型式は、減衰の幅か重みが合っていません。