重要事項説明書の特記事項・容認事項を書くときに、物件の条件が近い過去の文例を根拠の資料とあわせて検索し、下書きの材料にする

処理の起点を決める

宅地建物取引士が検索画面で「文例を探す」を押したときに動かします。 特記事項を書く段は、物件調査が終わって説明書をまとめる時点です。調査のメモと条件を選んで押すと、1〜2分で条件ごとの文例が出ます。

もう1つの起点は、店長の確認が終わったときです。 作成ソフトから確定版の説明書をPDFで書き出し、確定版のフォルダに保存したときに、特記事項を取り出して索引に足します。この起点が無いと、索引は導入時のまま古くなります。

法務の確認で文が直されたときは、直した版を確認済みとして入れ、元の版の状態を「差し替え済み」に変えます。 消さずに残すのは、いつ何が直されたかを後から引けるようにするためです。

入力データを集める

質を決めるのは、2行目の「確認の状態」です。 店長と法務の確認を経た文だけを confirmed にし、検索は confirmed に絞ります。 確認前の文を入れると、直される前の書き方が何度も出てきます。

3行目の根拠の資料の名前は、最初の作業でいちばん手間がかかります。 過去の説明書の添付資料の一覧から、その特記事項がどの資料に基づくかを付けます。付けられなかった文は「根拠不明」として入れ、検索結果にもそう表示します。

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

ハイブリッドクエリの filter には、確認の状態・物件種別・条件の分類を入れます。 filter は1つの検索の形で書く必要があるので、複数の条件は bool にまとめます。 ハイブリッドクエリは最上位のクエリとして書く必要があり、function_score などの中に入れると正規化を通らずに動くことがあります。

条件1つ分の検索は、次のような形になります。検索パイプライン clause-hybrid には正規化の処理器を置き、単語の一致0.4・埋め込み0.6の重みから始めます。

POST /special-clauses/_search?search_pipeline=clause-hybrid
{
  "size": 5,
  "_source": ["clause_id", "clause_text", "category", "evidence", "created_on"],
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "clause_text": "隣地 ブロック塀 越境 覚書なし" } },
        { "knn": { "clause_vector": { "vector": [0.0], "k": 20 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "status": "confirmed" } },
            { "term": { "category": "encroachment" } },
            { "terms": { "property_type": ["detached_house", "land"] } }
          ]
        }
      }
    }
  }
}

物件種別は1つに絞りすぎないようにします。 戸建と土地の越境は書き方がほぼ同じで、片方に絞ると文例の少ない店舗では候補が出なくなります。 絞るかどうかは、分類ごとの文例の数を見て決めます。

同じ物件の過去の取引は、別に引きます。 同じ土地を数年前に仲介していれば、そのときの特記事項がいちばん近い文例です。点数で並べる必要は無いので、識別子で直接引きます。

文例の索引の1件は、次のような形にします。

{
  "clause_id": "SC-2025-0917-03",
  "clause_text": "本物件の北側隣地より、ブロック塀の一部が本物件内に越境しています。…",
  "clause_vector": [0.0],
  "category": "encroachment",
  "property_type": "detached_house",
  "zoning": "第一種低層住居専用地域",
  "evidence": ["越境に関する覚書（隣地所有者との間）", "確定測量図"],
  "status": "confirmed",
  "revised_from": "",
  "branch": "東店",
  "created_on": "2025-09-17",
  "access_group": "sales_all"
}

clause_text は Sudachi の解析、clause_vector は1,024次元の k-NN の項目として定義します。access_group は、第13章の文書の単位の権限に使います。

AIへ渡す前に整形する

1. 特記事項の切り出し … 確定版のPDFから特記事項・容認事項の欄を取り出し、番号や「・」で1条件ずつに分けます
2. 物件を特定する情報の置き換え … 地番、住所の番地、売主・隣地所有者の氏名を ［地番］ ［隣地所有者］ のような記号に置き換えます
3. 条件の分類 … 決まった語（越境、私道、セットバックなど）でまず分類し、付かなかったものだけを人が付けます
4. 根拠の資料の付与 … 説明書の添付資料の一覧から、その条件に関係する資料の名前を付けます
5. 埋め込み … 置き換え後の文で、1条件ごとに Titan Text Embeddings V2 の埋め込みを作ります
6. 確認の状態の付与 … 確定版から取り出した文は confirmed、法務の確認で直す前の文は superseded にします

2番目を軽く見ないでください。 文例は別の物件の説明書に使うものです。過去の物件の地番や当事者の氏名が検索結果に出る必要はありません。 置き換えておけば、文例をそのまま写したときに別の物件の情報が混ざる事故も防げます。

告知事項の文は、さらに慎重に扱います。 国土交通省のガイドラインは、告げる際に亡くなった方や遺族の名誉と生活の平穏に配慮し、氏名、年齢、住所、家族構成、具体的な死の態様や発見状況などを告げる必要はないとしています。文例にそうした記載が残っていれば、索引に入れる前に除きます。

AIに処理させる

させるのは2つです。調査のメモを条件ごとの検索文に分けることと、文例ごとに今回との違いを並べることです。

1行目を「させない」に置くのは、意図してのことです。 完成文を出すと、取引士は読み比べるより写すほうに傾きます。違いの一覧を見て自分で書く形にすることで、第3章の（b）の失敗を止めます。

指示内容を固定する

あなたは不動産の売買仲介会社で、宅地建物取引士が重要事項説明書の
特記事項・容認事項を書くための材料を整理する担当です。
特記事項の完成文は書かないでください。

【やること】
1. 今回の調査のメモと、条件ごとに検索された過去の文例を読んでください。
2. 文例ごとに、その文例が前提にしている事実（根拠の資料、
   当事者の取り決め、物件種別、用途地域など）を書き出してください。
3. その前提が今回のメモで確かめられているかを、
   confirmed / not_in_memo / differs のどれかで示してください。
4. 文例と同じ趣旨で書く場合に、今回確かめる必要がある資料を挙げてください。

【厳守事項】
- 今回のメモに書かれていない事実を、あるものとして扱わないでください。
  メモに無ければ not_in_memo にしてください。
- 文例の根拠が「根拠不明」の場合は、そのことをそのまま書いてください。
- 検索結果に無い文例を示さないでください。clause_id は検索結果のものだけを使ってください。
- 説明が必要かどうか、どう書けば足りるかの判断は書かないでください。
- 告知事項について、亡くなった方の氏名・年齢・死の態様などの詳細を書かないでください。
- 近い文例が無い条件は matches を空にし、note に「近い文例なし」と書いてください。
- quote には、文例の該当箇所を一字一句そのまま写してください。

【今回の調査のメモ】{survey_memo}
【条件ごとの検索結果（clause_id、文、分類、根拠の資料、確認日）】{search_results}

「メモに無ければ not_in_memo」を明記しないと、文例の前提を今回にも当てはめます。 文例に「越境に関する覚書を締結済み」とあると、今回も覚書があるかのように整理しがちです。確かめていないことを確かめたように見せないのが、この指示の目的です。

quote を一字一句で写させるのは、後で照らすためです。 プログラムで文例の原文と照らし、一致しないものは表示しません。

出力形式を固定する

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

{
  "request_id": "",
  "conditions": [
    {
      "category": "encroachment | private_road | setback | rebuild | retaining_wall | buried_object | soil | flood | death_disclosure | other",
      "query": "",
      "matches": [
        {
          "clause_id": "",
          "quote": "",
          "premises": [
            { "fact": "", "check": "confirmed | not_in_memo | differs" }
          ],
          "documents_to_check": [],
          "evidence_status": "listed | unknown"
        }
      ],
      "note": ""
    }
  ]
}

1つ目の理由は、条件ごとに分けて表示できることです。 条件が4つある物件でも、取引士は1条件ずつ文例と違いを見られます。category は条件の分類の一覧と同じ値に限ります。

2つ目は、premises の check で確認の要るところが一目で分かることです。 not_in_memo と differs が付いた前提は、今回の物件で確かめるか、文例と違う書き方にするかのどちらかです。 検索画面では、この2つを色を変えて出します。

3つ目は、quote と clause_id をプログラムで照らせることです。 構造化出力はスキーマに合う形を返しますが、中身が文例と一致するかまでは保証しません。一致しない quote は表示から外し、ログに残します。

システムへ連携する

検索画面には、条件ごとに3つの欄を並べます。 左に文例の quote、中央に文例の前提と check、右に今回確かめる資料です。not_in_memo と differs の行は色を変え、取引士がそこから読むようにします。 同じ物件の過去の取引が見つかった場合は、条件の欄の上に別枠で出します。

検索から表示までの処理は1つの Lambda でつなぎます。検索文の埋め込みは条件ごとに作り、条件の数だけ検索を並べて投げます。 条件が5つある物件でも、待ち時間が条件の数に比例して延びないようにするためです。

人が確認する

1. not_in_memo と differs を必ず見る … 文例の前提のうち、今回確かめていないものです。資料を取り寄せるか、文例と違う書き方にします
2. 根拠不明の文例を写さない … evidence_status が unknown の文例は、言い回しの参考にとどめます
3. 告知事項は店長と一緒に決める … 告げる必要があるか、どこまで書くかはガイドラインと事実関係で判断します
4. 店長が確認する … 新しく書いた文と、文例と大きく変えた文を中心に見ます
5. 法務に相談した結果を索引に戻す … 直した版を confirmed として入れます

1番目を省かないでください。 この構成の価値は、文例と今回の違いを見せることにあります。違いを見ずに写せば、探す時間が減っただけで、第3章の（b）の失敗は残ります。

目標は、120件をならして1件10分です。 検索結果を読んで違いを確かめるのに6分、書いて店長に回すのに4分という見込みです。

例外に対処する

上の2行が、運用の中で最も多い例外です。 珍しい条件の物件ほど文例が無く、そうした物件こそ店長や法務に相談すべき物件です。 文例が無いことを伝えるのも、この構成の出力です。

記録を残す

• 検索の依頼（条件、調査のメモ、依頼者、日時）
• 検索文、検索結果の clause_id と点数、そのときの重みと正規化の設定
• Claude API の出力と、そのとき使った指示の版
• 表示から外した quote と、その理由
• 取引士が実際に使った文例の clause_id
• 確定版から索引に入れた文と、法務の確認で差し替えた記録

5つ目の「実際に使った文例」は、検索の改善に使います。 上位に出たのに使われない文例が多い条件は、重みか分類を見直します。