売却査定の依頼が来たときに、自社の過去の成約記録と査定書から立地・面積・築年数・間取りの近い取引事例を探し、査定書に載せる比較事例を根拠付きで並べる

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、毎晩の定時で行います。 成約は契約日の翌日以降に基幹の仕組みに確定して入るので、毎晩で足ります。 査定書は作成のたびに保存されますが、比較事例として使うのは成約の記録で、査定書から取り込むのは「そのとき選ばれた事例」と査定した価格だけです。

成約の取り消しも、毎晩の取り込みで反映します。 契約が解除された成約が索引に残ると、存在しない取引を比較事例に使うことになります。基幹の仕組みで取り消しの印が付いたものは、索引から外します。

検索は、営業担当が査定書の作成を始めたときに動きます。 査定書の作成の仕組みで査定物件の条件を入れ終えたところで、「比較事例の候補を出す」を押す形にします。 依頼を受けた直後に自動で動かさないのは、聞き取りの段階では面積や階が確定していないことが多いためです。

入力データを集める

質を決めるのは、建物の一覧です。 マンション名の書き方は、成約の記録ごとに揺れます。建物の番号にそろえておかないと、同じ建物の事例を別に取り出す5番目が当たりません。 号棟が分かれるマンションは、同じ敷地でも別の建物として持つか、同じ建物として持つかを先に決めます。

成約記録に、売主と買主の情報は入れません。 比較事例に要るのは物件と取引の条件だけです。氏名や連絡先が索引に入っていると、事例の引用として査定書に出る経路ができます。

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

基幹の仕組みから、前日に確定・変更・取り消しされた成約を毎晩書き出してもらいます。 Lambda で所在地を緯度経度に変え、マンション名を建物の一覧で建物の番号に置き換えて登録します。緯度経度への変換は、住所から位置を引く仕組み（ジオコーディング）を別に用意します。 変換できなかった住所は、取り込みで止めて担当に戻します。

索引の項目は、次のように持たせます。

築年は、年ではなく年月の日付として持たせます。 日付の項目にすれば、減衰の scale を「5年」のように単位付きで書けます。公式のドキュメントでは、日付の項目の scale は単位付きの数で指定でき、単位が無ければミリ秒とされています。

AIへ渡す前に整形する

1. 所在地を緯度経度に変える … 成約記録の住所から、建物の位置を引きます。部屋ごとではなく建物ごとの位置にします
2. 建物の番号にそろえる … マンション名を建物の一覧で照合し、号棟や旧名の揺れをまとめます
3. 必須の項目の欠けを確かめる … 面積、築年月、成約日、位置のどれかが空の成約は、取り込みで止めて印を付けます
4. 取り消しを外す … 契約が解除された成約を索引から外します
5. 単価を計算する … 成約価格を専有面積で割り、㎡単価として持たせます
6. 査定書の事例を結ぶ … 過去の査定書で選ばれた成約番号を、成約記録の側に「選ばれた回数」として持たせます

3番目が、この構成でいちばん効く前処理です。 公式のドキュメントには、項目が文書に無い場合、減衰関数は点数1を返すと書かれています。築年月が空の成約は、築年の近さで満点になり、築年が分からない事例が上位に並びます。 必須の項目が欠けた成約は、索引に入れる前に止めます。

6番目の「選ばれた回数」は、並べる順には使いません。 よく選ばれる事例は使いやすい事例ですが、近い事例とは限りません。 画面に参考として出すだけにします。

AIに処理させる

AIの仕事は、検索で出た事例ごとに、査定物件との違いを成約記録の値のまま書き出すことだけです。 事例を探すのも、近さの順に並べるのも検索基盤で行います。

1行目が、いちばん外せない線です。 近い事例の単価が並ぶと、AIは「これらの事例から、査定価格は〇〇万円前後と考えられます」と書きがちです。その一文が査定書に紛れ込むと、根拠の検討を経ない価格が依頼者に伝わります。 価格には一切触れさせません。

2行目も同じくらい大事です。 「3階と8階の違いは〇％程度」とAIが書けば、それが補正の根拠のように読まれます。補正は自社の査定の基準で決めるもので、AIには違いの事実だけを書かせます。

指示内容を固定する

あなたは不動産会社の営業部で、売却査定の比較事例の候補を整理する係です。
渡された検索結果だけを根拠にしてください。一般的な相場の知識で補わないでください。

【査定物件】
所在地：{address}　建物：{building_name}　階：{floor}　向き：{direction}
専有面積：{area_m2}㎡　間取り：{layout}　築年月：{built_ym}

【検索結果】
same_building：同じ建物の過去の成約
nearby：周辺の成約（近さの点数の順）

【事例ごとに書くこと】
1. 成約番号、成約日、建物名、階、向き、専有面積、間取り、築年月、成約価格、㎡単価
2. 査定物件との違い（値で書く）
   - 距離（m）、駅と徒歩の分数の差、階の差、向きの違い、面積の差（㎡）、築年の差（年）、成約からの経過（か月）
3. 確かめるべき点（成約から2年以上、間取りが違う、など）

【厳守事項】
- 査定価格や価格の目安を書かないでください。
- 階や向きの違いを、何％の差といった補正の数字で書かないでください。違いの事実だけを書いてください。
- 成約価格と㎡単価は、検索結果の値をそのまま写してください。計算し直さないでください。
- 検索結果に無い周辺の相場、再開発、人気などを書かないでください。
- 事例が適切かどうかを評価しないでください。
- same_building が空のときは「同じ建物の成約なし」と書いてください。
- 売主・買主に関わる情報には触れないでください。

「補正の数字で書かない」を明記しないと、AIは親切に階の補正率を書きます。 一般的な目安として書かれた数字でも、査定書の上では自社の基準と同じ重さで読まれます。 違いは値で書かせ、補正は人の側に残します。

検索結果は、Claude の検索結果ブロックで渡します。 成約1件を1つの search_result にし、source に成約番号、title に建物名と階、content に成約の条件を入れます。公式の説明では、引用付きの答えが返り、Amazon Bedrock でも使えます。 違いの書き出しがどの成約から来たかを、査定書の作成の画面で辿れます。

出力形式を固定する

周辺の事例の検索は、次のように組みます。

GET /deals/_search
{
  "size": 10,
  "query": {
    "function_score": {
      "query": { "bool": { "filter": [
        { "term": { "property_type": "condo" } },
        { "range": { "closed_on": { "gte": "now-3y/d" } } },
        { "geo_distance": { "distance": "3km",
            "location": { "lat": 35.6581, "lon": 139.7017 } } }
      ] } },
      "functions": [
        { "gauss": { "location": { "origin": { "lat": 35.6581, "lon": 139.7017 }, "scale": "1km" } } },
        { "gauss": { "area_m2": { "origin": 68.5, "offset": 3, "scale": 10 } } },
        { "gauss": { "built_ym": { "origin": "2008-03-01", "scale": "1825d" } } },
        { "gauss": { "closed_on": { "origin": "now", "scale": "365d" } } }
      ],
      "score_mode": "multiply",
      "boost_mode": "replace"
    }
  }
}

boost_mode を replace にしているのは、絞り込みの部分に点数が無いためです。 公式のドキュメントでは、replace はクエリの点数を無視して関数の点数を使うとされています。面積の offset: 3 は、±3㎡以内を点数1として同じ扱いにする設定です。

査定書の作成の仕組みに返す形は、次のJSONです。

{
  "subject": { "building_id": "B-01234", "floor": 8, "area_m2": 68.5, "built_ym": "2008-03" },
  "same_building": [
    { "deal_id": "D-2025-0412", "floor": 5, "direction": "南", "area_m2": 70.2,
      "closed_on": "2025-04-12", "price": 0, "unit_price_m2": 0,
      "differences": { "floor_diff": -3, "area_diff_m2": 1.7, "months_since": 18 } }
  ],
  "nearby": [
    { "deal_id": "D-2026-0108", "building_name": "", "distance_m": 420, "score": 0.61,
      "differences": { "walk_min_diff": 2, "floor_diff": 2, "area_diff_m2": -4.3,
                       "age_diff_years": 3, "months_since": 9 },
      "to_check": ["間取りが違う（2LDK）"] }
  ],
  "excluded_missing_fields": 3
}

1つ目の理由は、same_building と nearby を別の配列にできることです。 査定書の作成の画面で、同じ建物の事例を別の表として先頭に固定できます。

2つ目は、differences を数値の項目で返せることです。 違いが数値で並べば、営業担当は自社の補正の表にそのまま当てはめられます。 文章の中の数字を拾い直す手間がありません。

3つ目は、excluded_missing_fields で、必須の項目が欠けて外した成約の数を見せられることです。 数が多ければ、基幹の仕組みの入力の漏れを直す合図になります。

システムへ連携する

査定書の作成の仕組みには、候補の欄にだけ返します。 比較事例の欄に移すのは営業担当の操作で、候補がそのまま査定書に載ることはありません。

人が確認する

この構成の確認は、必須です。 査定書の比較事例は、価格の意見の根拠になります。

1. 同じ建物の事例を先に見る … 階・向き・面積の違いと成約の時期を確かめ、使うかを決めます
2. 周辺の事例から3〜5件を選ぶ … 点数の順に上から使うのではなく、違いの数値を読んで、補正で説明できる事例を選びます
3. 確かめるべき点を見る … 成約から時間がたった事例、間取りが違う事例は、使うなら理由を査定書に書きます
4. 店長が査定書を確かめる … 比較事例の選び方と補正を、店長が見ます

2番目で点数の順に頼らないのは、点数が近さの目安にすぎないからです。 角部屋、眺望、リフォームの有無は、点数に入っていません。それを知っているのは、現地を見た担当です。

1件あたり10分を目安にします。 候補が10件出れば、違いの数値を流し読みして3〜5件を選び、確かめるべき点を見る時間です。

例外に対処する

1行目で半径を自動で広げないのは、広げた事例を担当が「近い事例」と読むためです。 郊外の物件で3kmの外まで事例を探すかは、地域を知る担当と店長が決めます。

記録を残す

• 毎晩の取り込みの件数と、止めた成約とその理由
• 査定ごとの、査定物件の条件と、返した事例の成約番号と点数
• Claude に渡した検索結果と、返ってきた答えと引用
• 営業担当が査定書に載せた事例と、載せなかった事例
• 店長が査定書を差し戻した記録と、その理由

4つ目と5つ目は、減衰の scale を直す材料です。 担当が選ぶ事例が、いつも点数の順位の下のほうにあるなら、どれかの軸の scale が実際の感覚より狭いか広いということです。3か月ごとに見直します。