毎日の新着物件を登録客の希望条件と照らして合う人を判定し、物件ごとの案内文を下書きして担当の確認に回す

処理の起点を決める

平日の11時に1回動かします。 n8n の Schedule Trigger ノードで「Weeks」の間隔を選び、月曜から金曜を指定して11時0分にします。朝の登録が終わり、昼の休みの前に担当が承認できる時刻です。 午後に入る新着のために、16時のルールを足して1日2回にすることもできます。公式のページでは、1つのノードに複数のトリガーのルールを足せるとされています。

時刻の基準を最初に直します。 公式のページでは、Schedule Trigger はワークフローのタイムゾーン、それが無ければインスタンスのタイムゾーンに従い、自分でサーバーを立てた場合の既定は America/New York です。ワークフローの設定で Asia/Tokyo を選ばないと、11時のつもりが夜中に動きます。

ワークフローは公開しておく必要があります。 公式のページでは、Schedule Trigger を使うワークフローは保存して公開するよう書かれています。作って試しただけで公開していないと、翌朝何も動きません。

新着物件の行には処理状態の列を持たせます。 読むのは「未処理」の行だけで、処理が終わったら「処理済み」に書き換えます。書き換えるのは、案内候補シートへの書き込みまで成功したときだけにします。 途中で止まったものは、次の回にもう一度読まれます。

入力データを集める

質を決めるのは、物件の側の「書かれていること」の量です。 向き・学区・管理規約の要点が空欄の物件では、自由記述の希望のほとんどが「分からない」になります。AIの判定を良くするより、物件の登録のときにこの3つの欄を埋めるほうが効きます。

過去の案内を渡すのは、同じ物件を二度送らないためです。 価格を下げて再び新着に出た物件では、前に案内した客に「価格が変わりました」と書くか、送らないかを担当が決めます。

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

Google Sheets ノードの操作は、公式のページでは「Get Row(s)」「Append Row」「Update Row」「Append or Update Row」などです。 この構成では、読むのに Get Row(s)、案内候補の書き出しに Append Row、処理状態の書き換えに Update Row を使います。ノードに無い操作が要るときは、Google Sheets の認証情報を使って HTTP Request ノードで API を呼べるとされています。

物件管理システムには直接つなぎません。 毎朝のCSVをスプレッドシートに貼る作業は、いまの登録の流れに1つ手順を足すだけです。システムのAPIに手を入れるより、最初はこのほうが早く動きます。

AIへ渡す前に整形する

1. 表の条件で絞る … Code ノードで、物件ごとに客を絞ります。エリアは市区町村か沿線の駅で照らし、予算は上限の5％までの超過を残します。 価格交渉で届く物件を最初から落とさないためです
2. 面積・間取り・築年数 … 面積は下限の95％まで、間取りは「3LDK以上」のような書き方をそろえて比べ、築年数は上限ちょうどまでを残します
3. 候補の数を抑える … 1物件あたりの候補は最大15人にします。超えるときは、最終の案内日が古い客から順に残します
4. 案内済みを外す … 同じ物件を案内済みの客は外し、価格が変わった物件だけは「再案内」の印を付けて残します
5. 自由記述の希望を整える … 改行や「・」で区切られた希望を、そのまま1つの文字列で渡します。区切り直しはAIにさせ、その結果を出力に書かせます
6. 個人を特定する情報を外す … AIに渡すのは客番号と希望条件だけです。名前、電話番号、メールアドレス、勤務先、年収は渡しません
7. 物件の情報を1つの文字列にまとめる … 欄の名前と値の組で並べ、空欄の欄は「記載なし」と書きます

5％と95％の幅は、自社で決める数字です。 狭くすると交渉の余地のある物件が落ち、広くするとAIに渡す人数が増えます。最初の1か月は、担当が「この客にも送りたかった」と書いた件数を見て調整します。

7番の「記載なし」は、AIが「分からない」と判定するための材料です。 空欄のまま渡すと、欄そのものが無かったように扱われます。

AIに処理させる

させるのは、客ごとに自由記述の希望を条件に分け、物件の情報に合うかを1条件ずつ判定し、根拠にした物件の欄を書き出すことです。 そのうえで、合う客への案内文を下書きします。

右端の列が、この構成でいちばん大事な区別です。 fail は物件の情報に希望と反する事実が書かれているということ、unknown はその事実が書かれていないということです。前者は案内しない理由、後者は担当が確かめる事項です。

2行目がいちばん起きやすい失敗です。 生成AIは地名から一般的な知識で答えを作れてしまい、「閑静な住宅街です」「坂は少ない地域です」と書きます。 物件の情報に無いことは、合っていても unknown にさせます。

指示内容を固定する

あなたは不動産の売買仲介の担当を補助する立場です。
新着物件の情報と、購入希望の客の希望条件を照らして、
条件ごとに合うかを判定し、合う客への案内文を下書きしてください。

【判定の手順】
1. 客の「その他の希望」を、条件1つずつに分けてください。
   分けた条件は、客が書いた言葉のまま condition に写してください。
2. 条件ごとに、物件の情報のどの欄が根拠になるかを探してください。
3. 次のどれかを result に入れてください。
   - pass ............ 物件の情報に、条件を満たす事実が書かれている
   - fail ............ 物件の情報に、条件と反する事実が書かれている
   - unknown ......... 判断に要る事実が物件の情報に書かれていない
   - not_applicable .. この物件の種類には当たらない条件（戸建に階数の条件など）
4. evidence には、根拠にした欄の名前と値をそのまま写してください。

【厳守事項】
- 物件の情報に書かれていないことを、地名や一般的な知識から推測しないでください。
  「記載なし」の欄に関わる条件は unknown です。
- 迷ったときに pass を選ばないでください。
- 「ペット可」とだけ書かれ、大きさや種類の定めが分からないときは、
  大きさや種類を条件にした希望を unknown にしてください。
- 誰に案内すべきか、案内すべきでないかは書かないでください。
- 価格交渉の見込み、ローン、客の資金については書かないでください。

【案内文の下書き】
- result に fail が1つも無い客についてだけ書いてください。
- 本文は200字以内。冒頭の宛名と末尾の署名は書かないでください。
- 客の希望の言葉を1つ以上引き、それに当たる物件の事実を続けて書いてください。
- 物件の情報に無い長所を書かないでください。「人気」「おすすめ」「閑静」などの
  評価の言葉を使わないでください。
- unknown の条件があるときは、「〇〇については確認のうえご連絡します」と書き、
  合うとは書かないでください。
- 価格を書くときは、物件の情報の価格の欄をそのまま写してください。

【物件の情報】{listing}
【候補の客（客番号と希望条件）】{candidates}

「迷ったときに pass を選ばない」を明記しないと、合う方に寄ります。 自由記述の希望はあいまいな書き方が多く、何も言わなければ好意的に読みます。pass が増えると、担当の確認が形だけになります。

案内文の禁止語を並べているのは、案内文が広告に近い文書だからです。 1人の客に向けたメールでも、事実と違う長所を書けば客の信頼を失います。物件の情報に無い言葉が出てきたら、それは下書きの誤りです。

出力形式を固定する

Structured Output Parser に、次の形の JSON の例を渡して受け取ります。

{
  "listing_id": "",
  "clients": [
    {
      "client_id": "",
      "checks": [
        { "condition": "", "result": "pass | fail | unknown | not_applicable",
          "evidence": "" }
      ],
      "unknown_items": [""],
      "draft": ""
    }
  ]
}

1つ目の理由は、判定と結論を別の層に置けることです。 checks はAIが埋め、match ／ check ／ no_match は後段の Code ノードが規則で決めます。

必須の印は台帳の側にあり、AIには渡していません。 AIは条件ごとの事実だけを返し、どれを重く見るかは客が言ったことに従います。 必須の印を付け直しても、checks を読み直すだけで振り分けをやり直せます。

2つ目は、Structured Output Parser の制約に合わせられることです。 公式のページでは、JSON の例から作った schema はすべての項目を必須として扱い、$ref を使った参照には対応していないとされています。入れ子は clients と checks の2段にとどめ、参照を使わない平らな形で書きます。 unknown_items が無い客にも空の配列を返させます。

3つ目は、evidence で担当の確認が速くなることです。 物件の資料を開く前に、どの欄を見て合うとしたかを読めます。

システムへ連携する

承認依頼のメールは、物件ごとに担当1人へ送ります。 宛先は、候補の客の担当のうち人数が多い人です。本文には物件の要点、match と check の客の一覧、check の理由、案内候補シートの該当行へのリンクを書きます。 承認の種類は「Approve and Disapprove」にし、ボタンの文字を「下書きを作る」「今回は見送る」に変えます。

承認されたら、Gmail ノードの Drafts の create で客ごとの下書きを作ります。 宛先は登録客台帳のメールアドレス、本文は宛名と署名の定型の間にAIの下書きを挟んだものです。送信はしません。 送るのは、担当が物件を確かめた後です。

登録客台帳には書き込みません。 最終の案内日を更新するのは、担当が実際に送ったときです。下書きを作っただけで更新すると、送られなかった案内が送ったことになります。

人が確認する

担当が見るのは、承認依頼のメールと案内候補シートの行だけです。 1物件あたり match と check を合わせて数人という想定です。

1. check を先に見る … unknown_items に並んだ事項を、物件の資料か元の業者への問い合わせで確かめます。多くは学区・ペットの細則・駐車場の台数です
2. match の根拠を確かめる … evidence を読み、物件の資料の該当欄と合っているかを見ます
3. 台帳に無い事情を足す … 事前審査の状況、前回の内見での反応など、担当だけが知っていることで案内する相手を足し引きします
4. 承認する … 「下書きを作る」を押します。見送るときは理由を案内候補シートに書きます
5. 物件の確認をして送る … まだ売りに出ているかを元の業者に確かめ、下書きを直して送ります

1番を省かないでください。 unknown は「AIが分からなかった」という意味ではなく、物件の情報に書かれていなかったという意味です。 確かめれば合う客かもしれず、ここで外すと第3章の（d）に戻ります。

目標は、1物件あたり5分です。 判定の根拠を読む時間と、check の事項を確かめる時間が中心です。check が多すぎる日は、物件の登録で向き・学区・管理規約の欄が空いています。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、物件と客の登録のしかたの問題です。 空欄の多い物件が続くときは、判定を工夫するより登録の手順を直します。

記録を残す

• 処理した物件番号と、そのときの物件の情報の全文
• 表の条件で絞った候補の客番号と、そのときの希望条件と必須の印
• AIが返した JSON の全文（checks、unknown_items、draft）
• Code ノードが決めた振り分けと、その規則の版
• 担当の承認・見送りと、その理由
• 担当が足した客と外した客 … AIの振り分けと担当の判断の違い
• 実際に送った日と、その後の内見・申込の有無

2つ目で「そのときの希望条件」を残すのは、希望が後から変わるためです。 客が予算を上げたり、エリアを広げたりすると、過去の判定の意味が変わります。当時の条件が残っていないと、判定の誤りか条件の変化かが区別できません。

6つ目は、表の条件の幅と指示の見直しの材料になります。 担当が足した客が多ければ絞り込みが狭すぎ、外した客が多ければAIが pass を出しすぎています。