事業用の物件を探す法人の要望に合う区画を、過去の募集図面と物件資料から探し、条件ごとの根拠を添えて提案の候補に並べる

処理の起点を決める

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

取り込みは毎晩の定時で行います。 募集図面は、新しい募集が始まるたびに共有フォルダに保存されます。その日のうちに検索に載れば足りるので、保存のたびに動かす必要はありません。 物件台帳の募集の状況（募集中、申込あり、成約、募集終了）も毎晩読み直し、索引の区画に付け直します。

募集の状況だけは、検索のときにもう一度物件台帳を引きます。 申込は日中に入ります。朝に「募集中」だった区画が、昼に申込済みになっていることがあります。 候補を並べる直前に台帳を引き、索引の状況と食い違うものは台帳の値で上書きして表示します。

検索は、担当が依頼の画面で「候補を探す」を押したときに動きます。 最初のメールでは条件が出そろっていないことが多いので、ヒアリングを終えたところで押します。

入力データを集める

質を決めるのは、区画の番号です。 図面のファイル名や本文のビル名は書き方が揺れます。区画の番号が付いていない図面は、collapse でまとめられず、同じ区画が何度も並びます。 取り込みで、物件台帳のビル名と階から区画の番号を引き当てます。

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

共有フォルダの新しい図面を Lambda が読み、本文を取り出します。画像だけのPDF（古いスキャンの図面）は止めて一覧に出します。 図面の書式はビルごと・年ごとに違うので、本文から項目を作る作業は Claude に任せ、次の形に整えます。

用途は「可／相談／不可／記載なし」の4つの値で持たせます。 第3章の（b）の書き方の揺れを、取り込みの段階で吸収します。「記載なし」を「不可」に寄せないことが、この表でいちばん大事な点です。

AIへ渡す前に整形する

1. 区画の番号を引き当てる … 図面のビル名と階を物件台帳と照合し、unit_id を付けます。当たらない図面は止めて担当に戻します
2. 月の総額を計算する … 賃料と共益費を足して monthly_total にします。坪単価で書かれた図面は面積を掛けます。計算は Lambda で行い、AIにはさせません
3. 単位をそろえる … 面積は坪、天井高はm、床荷重はkg/㎡にそろえます。㎡で書かれた面積は坪に換算し、元の値も残します
4. 物件資料の値を区画に足す … 天井高や床荷重は、図面に無ければビルの仕様書の値を使います。どちらから取ったかを項目の横に残します
5. 古い図面に印を付ける … 作成から3年を超えた図面は stale の印を付けます
6. 募集の状況を付ける … 物件台帳の状況を status に入れます

4番目で「どちらから取ったか」を残すのは、仕様書の床荷重が標準の値で、区画によっては補強してあることがあるためです。 図面の値と仕様書の値は、根拠として重さが違います。

AIに処理させる

AIの仕事は、条件の分解と、区画ごとの充足の書き出しの2か所です。 区画を探して並べるのは検索基盤です。

最後の行が、いちばん起きやすい失敗です。 竣工年と規模から、AIは床荷重や天井高をもっともらしく補います。その一文が候補表に載ると、法人は記載があると思って内見に進みます。 図面にも仕様書にも無い値は not_stated と書かせます。1行目の幅も、自社の規則（面積は±10％など）で付けます。

指示内容を固定する

依頼の文章を条件に分けるときの指示です。

あなたは事業用の賃貸の仲介会社の営業部で、法人の要望を検索の条件に整える係です。
渡された依頼の文章だけを根拠にしてください。

【取り出す条件】
エリア（駅・区）、面積、月の総額の上限、用途、階、設備（天井高、床荷重、電気容量、
24時間、駐車場）、入居の希望時期

【分け方】
- must ...... 文章に「必須」「最低」「以上」「まで」「でないと困る」など、外せないことが書かれている
- prefer .... 「できれば」「望ましい」「あれば」と書かれている
- unclear ... どちらとも読めない。勝手にどちらかに寄せないでください

【厳守事項】
- 値は文章に書かれた表現のまま写してください。「40坪前後」を「36〜44坪」のように幅に直さないでください。
- 「駅近」「広め」「きれいなビル」のような値の無い条件は unclear に入れ、確かめる質問を1文で書いてください。
- 文章に無い条件を、業種から推測して足さないでください。

検索結果から候補を書き出すときの指示です。

あなたは事業用の賃貸の仲介会社の営業部で、提案の候補を整理する係です。
渡された検索結果だけを根拠にしてください。一般的なビルの知識で補わないでください。

【条件】{conditions}
【検索結果】区画ごとに、代表の図面1枚と、条件に当たった記載の抜き出し

【区画ごとに書くこと】
1. 区画の番号、ビル名、階、面積、月の総額、図面の番号と作成日、募集の状況
2. 条件ごとの充足：met ／ not_met ／ not_stated と、根拠の記載をそのまま写したもの
3. 確かめるべき点（用途が consult、図面の作成から3年超、値が仕様書から来ている など）

【厳守事項】
- 検索結果に書かれていない値を書かないでください。無ければ not_stated です。
- not_stated を not_met として扱わないでください。
- 用途が consult のときに「可能と思われる」と書かないでください。「貸主に確認」と書いてください。
- 区画が空いているか、賃料が下がるかを書かないでください。
- 区画を良い・悪いで評価しないでください。選ぶのは担当です。

「not_stated を not_met として扱わない」を書かないと、AIは記載の無い条件を満たさないものとして書きます。 候補表で「床荷重：×」と出れば、法人はその区画を見なくなります。

検索結果は、Claude の検索結果ブロックで渡します。 区画1つを1つの search_result にし、source に図面の番号、title にビル名と階、content に図面の項目と抜き出しを入れます。公式の説明では、引用を有効にすると答えの文に、渡した source と title の引用が付きます。 引用は既定で無効で、1つのリクエストの中の検索結果はすべて同じ設定にする必要があります。

出力形式を固定する

検索は、次のように組みます。

GET /flyers/_search
{
  "size": 10,
  "query": { "bool": {
    "filter": [
      { "range": { "area_tsubo": { "gte": 36, "lte": 44 } } },
      { "range": { "monthly_total": { "lte": 2000000 } } },
      { "terms": { "station": ["渋谷", "恵比寿"] } },
      { "terms": { "use_office": ["allowed", "consult"] } }
    ],
    "should": [
      { "range": { "floor_load_kg": { "gte": 500, "_name": "floor_load" } } },
      { "range": { "walk_min": { "lte": 5, "_name": "near_station" } } },
      { "match": { "body": { "query": "床荷重 補強 サーバー", "_name": "body_load" } } }
    ]
  } },
  "collapse": {
    "field": "unit_id",
    "inner_hits": { "name": "older_flyers", "size": 3,
                    "sort": [{ "flyer_date": "desc" }] }
  },
  "highlight": { "fields": { "body": { "fragment_size": 80, "number_of_fragments": 3 } } }
}

should の句に _name を付けているのは、どの条件で当たったかを区画ごとに知るためです。 公式のドキュメントでは、名前を付けた句は結果ごとの matched_queries の配列に、当たった句の名前が返ります。 これをそのまま、条件ごとの met の判定に使います。

ハイライトは、根拠の記載を図面から抜き出すために付けます。 既定の unified ハイライトは文を単位に当たり方を見ます。fragment_size の既定は100文字、number_of_fragments の既定は5で、図面の備考は短いので80文字で3つに絞ります。

顧客管理の仕組みに返す形は、次のJSONです。

{
  "request_id": "R-2026-1007-031",
  "conditions": {
    "must": { "area": "40坪前後", "monthly_total_max": 2000000,
              "stations": ["渋谷", "恵比寿"], "use": "office" },
    "prefer": ["床荷重500kg/㎡", "駅から徒歩5分以内"],
    "unclear": [{ "text": "来客が多いので駅から近いところ",
                  "question": "徒歩何分までなら検討しますか" }]
  },
  "candidates": [
    { "unit_id": "U-0412-05", "building": "", "floor": 5, "area_tsubo": 41.2,
      "monthly_total": 1890000, "flyer_id": "F-2026-0815-12",
      "flyer_date": "2026-08-15", "status": "募集中",
      "checks": [
        { "condition": "床荷重500kg/㎡", "result": "met",
          "evidence": "床荷重：500kg/㎡（一部800kg/㎡補強済）", "from": "flyer" },
        { "condition": "駅から徒歩5分以内", "result": "not_stated",
          "evidence": "", "from": "" }
      ],
      "to_check": ["用途：事務所は可。サーバー室の設置は図面に記載なし"],
      "older_flyers": ["F-2023-0302-07"] }
  ],
  "excluded_no_unit_id": 2
}

1つ目の理由は、conditions を返して担当が分け方を確かめられることです。 第5章の6番目は、この must／prefer／unclear を画面で直す作業です。

2つ目は、checks の result と from で、根拠の重さが分かることです。 同じ met でも、図面に書かれた値（flyer）とビルの仕様書の標準の値（spec）では意味が違います。法人に伝える前に確かめるべきものが一目で分かります。 older_flyers からは、同じ区画の過去の図面も辿れます。

システムへ連携する

顧客管理の仕組みには、候補の欄にだけ返します。 法人へ送る提案の候補表に移すのは担当の操作で、候補がそのまま法人に送られることはありません。

人が確認する

確認は必須です。 候補表は、法人の内見と出店の判断の材料になります。

1. 条件の分け方を確かめる … must／prefer／unclear を見て、unclear に答えてから検索を進めます
2. not_stated と consult を拾う … 候補ごとに、記載の無い条件と相談の用途を貸主に聞く項目として書き出します
3. 空きと条件を貸主に確かめる … 物件台帳が「募集中」でも、提案の前に貸主か管理会社に空きと賃料を確かめます
4. 候補を選んで送る … 5〜8件を選び、確かめた結果を候補表に書いて送ります

3番目を省かないでください。 空いていない区画を提案すると、法人は内見の日程を空けてから断られることになります。

1件あたり12分を目安にします。 貸主への問い合わせの時間は、導入の前から別にかかっているので入れていません。

例外に対処する

1行目で自動で条件を緩めないのは、緩めた結果を担当が「条件に合う区画」と読むためです。 どの条件を外すかは、法人に聞いて決めます。

記録を残す

• 毎晩の取り込みの件数と、止めた図面とその理由
• 依頼ごとの、Claude が分けた条件と、担当が直した後の条件
• 検索の要求と、返った区画・matched_queries・抜き出し
• Claude に渡した検索結果と、返ってきた答えと引用
• 担当が候補表に載せた区画と、載せなかった区画
• 貸主に確かめた結果（空き、用途の可否、賃料）

2つ目は条件の分け方の指示を、最後の行は物件台帳を直す材料です。 貸主に聞いた床荷重や用途の可否を台帳に戻せば、第3章の（c）の記憶が索引に移ります。