売買仲介の物件調査を始めるときに、同じ地域で過去に作った重要事項説明書・役所調査のメモ・調査報告書から、道路・法令上の制限・インフラの調査結果を根拠付きで探し、今回確かめる窓口と項目を先に並べる

処理の起点を決める

起点は、営業が媒介を受けて、検索の画面で物件の所在地を入れたことです。 役所に出る前、物件の現地を見たあとに使います。現地で前面道路の幅や私道の有無を見てから引くと、検索の文に道路の手がかりを入れられます。

記録の取り込みは、社内の確認が終わったときに動かします。 重要事項説明書と調査報告書は、宅地建物取引士と店長の確認が終わったものだけを取り込みます。確認の前の書面には、後で直された誤りが残っているからです。

入力データを集める

質を決めるのは、役所調査のメモの「窓口」と「調査日」です。 「道路は42条2項」とだけ書かれたメモは、どこで確かめたのか、いつの話なのかが分からず、次の営業は同じ窓口を探し直します。 「○○市 建築指導課で道路台帳を閲覧（調査日）。前面道路は2項道路、中心後退あり」と書く様式にします。

地番は検索の文に入れますが、絞り込みには使いません。 同じ地番の過去の記録はまれで、引きたいのは同じ町丁目・同じ道路に面した記録だからです。

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

確認済みの書面は、個人情報を除いて Cloud Storage に置き、データストアに取り込みます。 メタデータは JSONL の各行に id、structData、content.mimeType、content.uri を書きます。

絞り込みは市区町村で、町丁目と道路はブーストで寄せます。 項目を索引可能にしておけば、city: ANY("city_a") AND doc_kind: ANY("disclosure", "survey_report") のように絞り込めます。町丁目まで絞り込むと、隣の町丁目にある同じ道路に面した記録が落ちます。 そこで town: ANY("town_3") と road_id: ANY("r_0123") を条件にした boostSpec に正の値を与え、同じ町丁目・同じ道路の記録を上に寄せます。

新しい調査ほど上に出すには、日付のブーストを使います。 ブーストの指定には日付の属性による寄せ方があり、検索した時点からの経過期間を 7D のような形式で指定できるとされています。surveyed_at を使い、1年以内の記録を強く、5年を超える記録を弱く寄せます。 古い記録を消すのではなく、下に置きます。

データストアは、レイアウト パーサーとチャンク分割を有効にして作ります。 includeAncestorHeadings を有効にすると、文書の途中のチャンクにもタイトルと見出しが付きます。重要事項説明書の「私道に関する負担」の段落だけが引かれても、どの物件のどの項目かが分かるようにします。

見られる人は、売買仲介の営業と宅地建物取引士に限ります。 個人情報を除いた版でも、どの地域でいつ調査したかは営業の情報です。メタデータの acl_info に売買仲介のグループの group_id を書き、賃貸管理や他の部署の社員の検索には出さないようにします。アクセス制御はデータストアを作るときにしか有効にできず、Cloud Storage からの定期的な取り込みでは使えないため、確認が終わるたびに取り込みを実行します。

AIへ渡す前に整形する

1. 個人情報を除く … 売主・買主の氏名・住所・連絡先、価格、ローンの情報を、取り込む版から消します
2. 所在地をそろえる … 町丁目の表記（「三丁目」「3丁目」）をそろえ、市区町村と町丁目のコードを付けます
3. 道路の識別を付ける … 調査報告書に書かれた路線名や道路番号を road_id に入れます。無いものは空のままにします
4. 調査日を付ける … 調査報告書の調査日を surveyed_at に入れます。調査日の無い記録は取り込みません
5. 役所調査のメモを清書する … 手書きのメモは、窓口・内容・資料・調査日の様式に写してから取り込みます
6. 項目の区分を付ける … 調査結果の項目ごとに、地域で共通／道路ごと／物件ごとの区分を付けます

1番目を最優先にしてください。 重要事項説明書には、売主の氏名と住所、取引の価格が入っています。検索に入れれば、別の店舗の営業の画面に、自分の顧客ではない人の取引が出てきます。 取り込むのは、調査結果の項目だけを抜き出した版にします。

2番目の所在地のそろえ方は、ブーストの効き方を決めます。 「三丁目」と「3丁目」、「大字」の有無が混ざったままだと、同じ町丁目の記録が別の町として扱われ、上位に寄りません。 市区町村と町丁目は、表記ではなくコードで持たせます。

6番目の区分は、項目の種類で機械的に決めます。 用途地域・建ぺい率・容積率・下水道の処理区域は「地域」、道路の種別・幅員・中心後退は「道路」、私道の持分・越境・引込管の口径は「物件」。営業に1件ずつ判断させず、項目の名前から決める表を作ります。

AIに処理させる

させるのは、同じ地域の過去の調査結果を、項目ごとに調査日と窓口付きで並べることです。 今回の物件の調査結果を書かせることはしません。

4行目の窓口と資料が、経験の浅い営業にいちばん効く部分です。 「○○市では、道路の種別は建築指導の窓口で道路台帳を見る」「下水の引込みは下水道の窓口で台帳の写しを取る」。市ごとの窓口の分かれ方は、過去のメモにしか書かれていません。

answer メソッドの設定は次のようにします。

3行目がいちばん起きやすい失敗です。 隣の物件の前面道路が2項道路と書かれていると、モデルは「この物件の前面道路も2項道路と考えられます」と書きます。同じ通りでも、角を曲がれば別の道路で、種別も違うことがあります。 過去の結果は、どの物件の記録かを添えて並べるだけにします。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます（1回目の調査結果の呼び出し用）。

あなたは不動産の売買仲介の会社で、物件調査を始める営業に、
同じ地域で過去に行った調査の記録を示す担当です。
読むのは、これから役所と各事業者の窓口で調査する営業です。

【前提】
検索の文の最初に、市区町村、町丁目、地番、物件の種別、前面道路の手がかりが並んでいます。
検索の対象は、社内で確認が終わった過去の重要事項説明書と調査報告書だけです。

【答え方】
1. 法令上の制限、道路と私道の負担、飲用水・電気・ガス・排水 の3つに分けて書いてください。
2. 各項目について、過去の記録の所在地（町丁目まで）、調査日、記載の内容を、
   記録の言葉のまま書いてください。
3. 同じ項目で記録ごとに内容が違うときは、両方を調査日と一緒に書いてください。

【厳守事項】
- 検索結果の記録に書かれていることだけで答えてください。
  一般的な法令の知識や、他の市の例で補わないでください。
- 今回の物件について、「〜と考えられます」「〜の可能性が高い」と書かないでください。
  過去の記録の所在地と調査日を書き、今回の物件の結果としては書かないでください。
- 調査日を省略しないでください。
- 重要事項説明書に書く文章を作らないでください。
- 関係する記録が見つからないときは、
  「この地域の過去の調査記録が見つかりません。すべての項目を窓口で確かめてください」
  とだけ書いてください。

2回目の窓口の呼び出しでは、【答え方】を「項目ごとに、訪ねた窓口の名前、閲覧・取得した資料、注意点を、メモの言葉のまま調査日と一緒に書く」に替えます。 【厳守事項】に「メモに無い窓口の名前を書かない」を足します。

「今回の物件について『考えられます』と書かない」を名指しで禁じるのが、この指示の要です。 推定を禁じるだけでは、モデルは「近隣の例では」と前置きして同じことを書きます。禁じるのは、過去の記録を今回の物件に当てはめる文の形そのものです。

「記録ごとに内容が違うときは両方を書く」も外せません。 同じ町丁目で用途地域の記載が違えば、途中で変更があったか、町丁目の中で境界があるかのどちらかです。 どちらかに丸めると、調査で確かめるべき点が消えます。

出力形式を固定する

2回の応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "request_id": "",
  "city": "",
  "town": "",
  "lot": "",
  "property_type": "land | house | condo",
  "items": [ { "item": "", "category": "legal_restriction | road | utilities",
               "scope": "area | road | parcel",
               "past_results": [ { "text": "", "town": "", "surveyed_at": "", "uri": "" } ],
               "conflict": false,
               "counters": [ { "office": "", "material": "", "note": "", "surveyed_at": "", "uri": "" } ] } ],
  "status": "found | no_record | partial"
}

1つ目の理由は、scope で調べ方を分けられることです。 area の項目は過去の結果が手がかりになり、parcel の項目は過去の結果があっても「今回の物件で一から確かめる」と画面で強調します。 区分は第7章の前処理で決めた表から付け、AIに判断させません。

2つ目は、conflict で食い違いを目立たせられることです。 同じ項目で過去の記録ごとに内容が違えば true にし、画面の先頭に出します。 用途地域や道路の扱いが途中で変わった地域は、調査でいちばん注意が要る地域です。

3つ目は、counters で調査の段取りを組めることです。 項目ごとの窓口を集めれば、どの窓口に何の資料を取りに行くかの一覧になり、役所を回り直す手間が減ります。

4つ目は、surveyed_at を全部の結果に持たせることです。 画面では、調査日から1年を超える結果を灰色にします。古い結果ほど、今回の調査で変わっている見込みが高いからです。

システムへ連携する

基幹システムと重要事項説明書には書き込みません。 調査報告書と重要事項説明書は、これまでどおり営業が今回の調査の結果から書きます。画面の結果を書面に貼り付ける機能も作りません。 貼り付けができると、調査日の違う結果が書面に入ります。

人が確認する

営業は、すべての項目を、今回あらためて窓口で確かめます。 画面に出るのは過去の記録で、今回の調査の代わりにはなりません。

1. 調査日を確かめる … 何年前の結果かを見ます。1年を超えるものは変わっている前提で調べます
2. 食い違いのある項目を先に調べる … conflict の項目は、変更の時期か境界を窓口で確かめます
3. 物件ごとの項目を一から調べる … parcel の項目は、過去の結果を参考にもしません
4. 窓口の名前を確かめる … 組織の改編で窓口の名前が変わっていることがあります

4番目は、役所調査のメモに返します。 窓口の名前が変わっていたら、今回のメモに新しい名前を書きます。次の営業の画面は、そのメモで正しくなります。

目標は、120件をならして1件18分です。 出典を開いて確かめ、調査の段取りを組む時間の平均です。

例外に対処する

7行目は、起きる前提で備えます。 取り込みの手順で1件でも見落とせば、別の店舗の営業に他人の取引が見えます。 取り込む版を作る処理で、氏名と価格の欄が空であることを確かめてから置きます。

記録を残す

• 物件の条件、日時、営業の所属店舗
• 中継プログラムが組み立てた絞り込みとブーストの式
• answer メソッドの応答の全文（2回分。出典、調査日、回答しなかった理由）
• 項目ごとの区分と conflict の結果
• 今回の調査で、過去の結果と違っていた項目

最後の行は、地域の変化の記録になります。 過去の結果と今回の結果が違った項目を数えれば、どの地域でどの項目が変わりやすいかが分かり、調査日の灰色の基準を見直せます。