管理物件の修繕・設備交換・入居者対応の記録を部屋ごとに探し、担当の交代や入居者からの連絡のときに経緯を根拠付きで引く

処理の起点を決める

トリガーは2つあります。記録を入れる側と、探す側です。

入れる側は、毎晩2時の定時実行です。前日分の対応履歴、完了報告、修繕の分類が付いたメールを取り込みます。当日の出来事は、賃貸管理システムを直接見れば足ります。

探す側は、担当者が Teams の検索の窓口に質問を書いたときです。質問と一緒に、場面を3つから選んでもらいます。

場面を選ばずに送った質問は、見せる範囲がいちばん狭い電話対応中として扱います。

入力データを集める

質を決めるのは、いちばん下の契約の区切りです。 これが無いと入居者に付く記録の契約が決まらず、場面による見せ分けが成り立ちません。 物件マスタの通称と旧名も欠かせません。担当者は「駅前のコーポ」のように書くからです。

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

取り込みでは、1件の記録を1つの文書として入れ、案件の番号（受付番号）を必ず付けます。 完了報告とメールは次の順で結び付けます。

1. 本文に受付番号が書かれていれば、それを使う
2. 無ければ、物件・部屋・協力業者名・日付が近い受付を探し、1件に決まれば結び付ける
3. 決まらなければ、案件の番号に U- と記録の番号を入れ、link_status を unlinked にする

3番目の記録も捨てません。 1件だけの案件として検索に出ます。

case_id を keyword にするのは必須です。 collapse でまとめる項目は、keyword か数値の型でなければなりません。 埋め込みは、取り込みパイプラインの text_embedding プロセッサが field_map で指定した body_text から作ります。

探す側は、2回の問い合わせに分けます。 1回目のハイブリッド検索で案件を上位5件まで取り、2回目で、その5件に付く記録を event_date の古い順にすべて取ります。

AIへ渡す前に整形する

取り込み側

1. メールの引用と署名を落とす … そのままだと同じ文が何件もの記録に現れます
2. 完了報告のPDFから文字を取り出す … 文字の無いスキャンは、本文を空にして source_url だけを入れます
3. 部屋番号の表記をそろえる … 「302号室」「3-02」を 302 に。改装で変わった番号は対応表で寄せます
4. tenancy_id を決める … 記録の日付を入居日・退去日と比べます
5. 個人の連絡先を落とす … 経緯を探すのに連絡先は要りません

探す側

1. 物件の手がかりを物件マスタで引く … 正式名・通称・旧名で照合します。複数に当たったら候補を返して選んでもらいます
2. 場面から見せてよい範囲を組む … 次の条件を filter に入れます

範囲の条件は、生成AIに組ませません。 いまの契約は賃貸管理システムから n8n が引いて組みます。

AIに処理させる

生成AIは2回呼び、それぞれに1つの仕事をさせます。

いちばん起きやすい失敗は、表の1行目です。 完了報告が無い案件を渡すと「その後、交換されました」と書きたがります。記録が無いことは、残っている事項として書かせます。

指示内容を固定する

呼び出し1（structured outputs で受け取る）

あなたは賃貸管理会社の社内検索の窓口です。
担当者の質問から、検索の条件を取り出してください。検索そのものはしません。

【取り出す項目】
- property_hint : 物件を指す言葉（正式名・通称・旧名・住所の一部）。書かれた言葉のまま
- unit_no       : 部屋番号。「号室」は付けない。共用部の話なら COMMON
- equipment     : 設備の種類。書かれていなければ null
- symptom       : 症状や出来事を表す言葉。書かれた言い回しを残す
- date_from / date_to : 期間。「去年の冬」のような表現は、今日の日付 {today} から範囲にする
- mode          : relevance / timeline / open_cases のどれか

【厳守事項】
- 書かれていない項目は null にしてください。推測で埋めないでください。
- 物件名を正式名に直さないでください。照合は別の仕組みが行います。
- 部屋番号を補わないでください。「3階の角部屋」は unit_no を null にします。
- 「前回」「この前」は mode を timeline にしてください。
- 「まだ終わっていない」「進行中」は mode を open_cases にしてください。

【質問】{question}

呼び出し2（citations を有効にした文書で渡す）

あなたは賃貸管理会社の物件担当者の補助です。
渡された記録だけを根拠にして、この部屋（または共用部）の経緯をまとめてください。

【書くこと】
1. 案件ごとに、受付から現在までの経緯を日付の順に書く
2. 各案件で残っている事項（完了報告が無い、完了後に再連絡がある、
   見積の承認が無い）を書く
3. 別の案件で同じ設備・同じ症状が出ていれば、くり返しとして書く
4. 記録どうしで食い違いがあれば、両方をそのまま書く
5. 質問に対して記録が見つからない部分は「記録なし」と書く

【厳守事項】
- 渡された記録に書かれていないことを書かないでください。
  記録が無い出来事を「おそらく」「と思われる」で補わないでください。
- 完了報告が無い案件を、完了したものとして書かないでください。
- 費用を誰が負担するか、入居者の過失かどうかを書かないでください。
- 保証の期間や残りを計算しないでください。
- 記録の title に「前の契約」とあるものは、経緯の事実だけを書き、
  入居者の発言や苦情の内容を引用しないでください。

【場面】{scene}
【質問】{question}
【記録】（案件ごとに document ブロックで渡す）

「完了報告が無い案件を完了と書かない」を別に書くのは、「推測しない」だけでは手配の記録の「交換予定」を「交換した」と読むからです。

呼び出しを2回に分けるのは、仕様の制約でもあります。 文書に citations を有効にしたうえで output_config.format を付けると、400のエラーが返ります。

出力形式を固定する

呼び出し1は、structured outputs で次のJSONを受け取ります。 スキーマは output_config.format に json_schema として渡します。

{
  "property_hint": "駅前のコーポ",
  "unit_no": "302",
  "equipment": "給湯器",
  "symptom": "お湯がぬるい",
  "date_from": null,
  "date_to": null,
  "mode": "timeline"
}

呼び出し2は、記録を1件ずつ plain text の文書として渡します。 citations は要求の中の全文書で有効にするか、全文書で無効にするかのどちらかです。title に event_id と日付を、context に case_id と scope を入れます。title と context はモデルに渡るが、引用の対象になりません。 回答は文と引用（cited_text）の組で返り、n8n が次の形に組み直します。

{
  "scene": "phone",
  "property_id": "P-0148",
  "unit_no": "302",
  "cases": [
    {
      "case_id": "R-2025-03112",
      "summary": [
        { "text": "2025年12月、入居者から湯温が上がらないとの連絡があり、協力業者が点検した。",
          "evidence": [ { "event_id": "E-88121", "cited_text": "" } ] }
      ],
      "open_items": [ "完了報告の記録なし" ],
      "has_prior_tenancy": false
    }
  ],
  "repeat_pattern": "",
  "not_found": [ "給湯器の設置日" ]
}

JSONに組み直す理由は3つです。 evidence を文ごとに持てるので、担当者は気になる文の根拠だけを開けます。open_items と not_found を独立した欄にできるので、「記録が無い」が経緯の文に埋もれません。has_prior_tenancy で、前の契約の記録を含む案件に色を付けられます。

システムへ連携する

ハイブリッド検索の要求は次の形です。

{
  "size": 5,
  "query": {
    "hybrid": {
      "queries": [
        { "multi_match": { "query": "給湯器 お湯がぬるい", "fields": ["body_text", "model_no"] } },
        { "neural": { "body_embedding": { "query_text": "お湯がぬるい", "model_id": "<埋め込みモデルのID>", "k": 50 } } }
      ],
      "filter": { "bool": { "filter": [
        { "term": { "property_id": "P-0148" } },
        { "terms": { "unit_no": ["302", "COMMON"] } }
      ] } }
    }
  },
  "collapse": { "field": "case_id" }
}

filter は1つの問い合わせの形で書く決まりなので、 場面の条件（scope と tenancy_id）も同じ bool に足します。下位の検索は最大5つまでです。

timeline のときは sort に event_date の新しい順を指定します。 並べ替えを指定すると文書のスコアは null になるため、「前回は何をしたか」に限って使います。collapse と併用した集計は、まとめる前の結果に対して動きます。 案件の数は2回目の問い合わせで数えます。

賃貸管理システムには書き込みません。 対応履歴の追記は、これまでどおり担当者が行います。

人が確認する

経緯は、担当者が根拠を開いてから使います。 入居者やオーナーへ直接送る経路は作りません。

1. open_items と not_found を先に読む … 「完了報告の記録なし」は、作業が終わっていないのか、報告が取り込まれていないのかを見分けます
2. 説明に使う文の根拠を開く … evidence のリンクから元の記録を開きます
3. 前の契約の印を確かめる … has_prior_tenancy の案件は、入居者の発言を外部へ伝えません
4. 違っていたら印を付ける … 根拠の誤りや結び付けの誤りを、窓口のボタンで返します

1番目を先にするのは、「記録が無い」が最も誤解されやすいからです。 「何もしていない」と伝えたら、実は協力業者が作業を終えていた、ということが起きます。電話対応中は、その場で伝えるのを日付と作業の有無までにし、詳しい内容は折り返す運用にします。

例外に対処する

4行目で生成AIを呼ばないのは、呼ぶと一般的な不具合の説明を書き始めるからです。 0件の答えはワークフローの側で決めます。

記録を残す

• 質問の文と場面、担当者、日時
• 呼び出し1が返した条件のJSONと、物件マスタで確定した物件コード
• OpenSearch に送った問い合わせの全文（filter の中身を含む）
• 返った案件の番号と、2回目で取り出した記録の番号の一覧
• 呼び出し2の回答と引用（文ごとの event_id と cited_text）
• 担当者が付けた印（根拠が関係なかった、結び付けが違っていた）
• 記録が見つからなかった質問の一覧

3つ目で filter の中身を残すのは、見せてよい範囲を後から確かめるためです。 前の入居者の記録が出たという申し出があったとき、原因が範囲の組み方か取り込みの誤りかを切り分けられます。 最後の一覧は、記録する習慣が無い出来事を見つける材料になります。