賃貸管理会社が空室の募集の掲載を、管理台帳と各ポータルの一覧で確かめるエージェントを動かし、止め忘れと載せ漏れを拾う

処理の起点を決める

起点は Schedule Trigger です。 火曜と金曜の朝9時に動かします。週2回にするのは、成約から掲載の削除までを長くても数日に収めるためです。 ガイドラインの最長2週間は上限で、目標ではありません。

ワークフローのタイムゾーンを必ず設定します。 公式のページでは、ワークフローにタイムゾーンが無ければインスタンスのタイムゾーンを使い、自社で動かすインスタンスの既定は America/New York とされています。設定しないと、朝9時のつもりが夜に動きます。

Schedule Trigger は、ワークフローを保存して公開しないと動きません。 公式のページにそう書かれています。作って試しただけで止まっていた、ということが起きやすいので、公開の状態を最初に確かめます。

一覧の置き忘れに備えます。 動いた時点で4つの一覧のどれかが当日の日付でなければ、照合をせずに担当へ「一覧が古い」と知らせて止まります。 古い一覧で照合すると、すでに止めた掲載を「止め忘れ」と出します。

入力データを集める

質を決めるのは、部屋の番号の対応表です。 各サイトの掲載の番号は台帳の部屋の番号と別で、物件名の書き方もサイトごとに違います（「〇〇ハイツ 201」「〇〇ハイツ201号室」）。物件名で突き合わせると、表記ゆれのたびに「台帳だけ」と「一覧だけ」が対で出ます。 掲載を入稿するときに、対応表へ1行足す決まりにします。

広告の可否を持たせるのは、載せ漏れの判定のためです。 オーナーが特定のサイトへの掲載を断っている部屋は、そのサイトに載っていなくて正しいからです。

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

照合は Compare Datasets ノードで行います。 入力 A に台帳の空室（と申込・退去予定）、入力 B にサイトごとの掲載の一覧をつなぎ、Fields to Match に部屋の番号を指定します。出力は4つの枝に分かれます。

Fields to Skip Comparing に、更新日や掲載の番号のような比べる意味の無い項目を入れます。 入れないと、すべての部屋が Different に出ます。数字と文字の違いで食い違いを出さないよう、Fuzzy Compare をオンにします。 公式のページでは、オンのときだけ数値の3と文字列の"3"が一致するとされています。

1つの部屋が同じサイトに2件載っている（重複の掲載）は、Multiple Matches の既定の「Include All Matches」のまま拾います。 重複は、それ自体を担当に知らせる対象です。

照合はサイトごとに4回行います。 台帳1つに対して一覧を4つまとめてつなぐと、どのサイトの食い違いかが分からなくなるからです。同じ部屋が4つのサイトすべてで In B only に出たら、台帳の側の更新が先に進んだ（成約した）可能性が高い、という手がかりにもなります。 この「何サイトで出たか」の数は、エージェントに渡す diff_detail に入れます。

先行募集の部屋は、退去予定日と先行募集の可否で入力 A に入れるかを決めます。 退去の受付の表で先行募集が「不可」の部屋は、退去予定でも入力 A に入れません。入れてしまうと、オーナーが退去後の内装の工事を終えてから募集したいと言っている部屋を、載せ漏れとして毎回出します。

エージェントのツールは、Call n8n Workflow Tool で小さなワークフローを呼ぶ形にします。 部屋の状態、申込・契約、退去予定、広告の可否、依頼の下書きの登録の5本で、どれも部屋の番号を1つ受け取って決まった項目だけを返します。 申込・契約の仕組みの全部をエージェントに渡しません。

AIへ渡す前に整形する

1. 一覧の日付の確認 … 4つの一覧が当日に出力されたものかを確かめます。古ければ止まります
2. 部屋の番号のそろえ … 対応表で各サイトの掲載の番号を台帳の部屋の番号に置き換えます。対応表に無い掲載は「対応表に無い」として別に出します
3. 金額のそろえ … 「6.5万円」「65,000円」「65000」を円の整数にそろえます
4. 台帳の状態の絞り込み … 入力 A に入れるのは、空室と、先行募集ができる退去予定だけにします
5. 件数の上限の確認 … 食い違いが普段の数倍あれば、一覧の出力の誤りを疑い、エージェントに回す前に担当へ知らせます

2番目で対応表に無い掲載を別に出すのは、それが最も危ない掲載だからです。 台帳とつながっていない掲載は、誰も止めない掲載です。 過去の担当が入れたまま、管理を外れた部屋が載り続けていることがあります。

5番目は、エージェントの暴走ではなく、入力の誤りを止めるためです。 あるサイトの一覧が途中で切れて出力されると、そのサイトの全部屋が「載っていない」と出ます。100件の誤った食い違いをエージェントに調べさせる前に止めます。

AIに処理させる

させるのは、食い違いのある部屋1つごとに、ツールで記録を引いて原因を確かめ、対応の区分と根拠を返すことです。

エージェントにするのは、食い違いの種類ごとに引くべき記録が違い、引いた結果でさらに引く先が変わるからです。 「載っているのに募集中でない」部屋で申込の記録が取消になっていれば、台帳の戻し忘れを疑って部屋の状態を変えた日を引きます。この分かれを固定の枝で全部書くと、枝が組み合わせの数だけ増えます。

指示内容を固定する

AI Agent ノードの System Message に次の文を入れます。

あなたは賃貸管理会社の募集担当の補助で、空室の募集の掲載と
管理台帳の食い違いの原因を調べる立場です。
渡された1つの部屋の食い違いについて、ツールで記録を引いて確かめ、
決まった形で返してください。

【使えるツール】
- get_unit_status：部屋の状態、条件、状態を変えた日
- get_application：申込・契約の記録（申込日、状態、契約日）
- get_moveout：退去予定日と先行募集の可否
- get_ad_permission：広告の承諾と、掲載してよいサイト
- register_request：対応の依頼の下書きを作業一覧に登録する（人の承認が要る）

【区分】
- stop_listing ... 掲載を止める
- add_listing .... 載せる
- fix_terms ...... 条件を台帳に合わせて直す
- no_action ...... 食い違いに正当な理由がある（広告不可など）
- needs_human .... 記録どうしが食い違う、または記録が足りない

【厳守事項】
- 区分の根拠には、ツールが返した記録の項目と値をそのまま書いてください。
- 記録に無いことを推測しないでください。「おそらく成約」「たぶん空室」と
  書かず、記録が足りなければ needs_human にしてください。
- 申込が取消になっているのに台帳が「申込」のままなど、記録どうしが
  食い違うときは、どちらが正しいかを決めずに needs_human にしてください。
- 条件のずれは、台帳の値を正としてください。賃料を提案しないでください。
- 表示が規約に違反するかどうかを書かないでください。
- register_request は、区分が stop_listing・add_listing・fix_terms の
  ときだけ、1つの部屋につき1回だけ呼んでください。
- 同じツールを同じ引数で2回呼ばないでください。

【部屋の番号】{unit_id}
【サイト】{site}
【食い違いの種類】{diff_type}
【照合で出た値】{diff_detail}

「記録どうしが食い違うときは決めない」をいちばん強く書きます。 申込が取消なのに台帳が「申込」のままの部屋は、台帳の戻し忘れかもしれないし、取消の記録の誤りかもしれません。 エージェントがどちらかに決めると、空いていない部屋を載せるか、空いている部屋を載せないかのどちらかが起きます。

「同じツールを2回呼ばない」は、繰り返しの上限のためです。 公式のページでは、Max Iterations の既定は10です。記録が見つからないとき、エージェントは同じツールを呼び直して上限に当たることがあります。

出力形式を固定する

Require Specific Output Format をオンにして Structured Output Parser をつなぎ、次の形で受け取ります。

{
  "unit_id": "H0123-201",
  "site": "site_b",
  "diff_type": "listed_not_vacant",
  "action": "stop_listing | add_listing | fix_terms | no_action | needs_human",
  "evidence": [
    { "tool": "get_application", "field": "contract_date", "value": "2026-10-24" }
  ],
  "request_draft": "サイトBの掲載（H0123-201）を停止してください。10/24に契約済み。",
  "notes_for_staff": ""
}

1つ目の理由は、evidence にツールの名前と項目と値を並べられることです。 担当は Slack の通知で「どの記録の、どの値を見て、止めると言っているのか」を読めます。根拠の無い区分は、この形では返せません。

2つ目は、action が5つに決まっていることです。 承認のあとの流れは action で分かれ、no_action は作業一覧に載らず、照合の記録にだけ残ります。

スキーマは $ref を使わずに書きます。 公式のページでは、Structured Output Parser の JSON Schema で参照（$ref）を使えないとされています。

システムへ連携する

依頼の下書きの登録のツールには、人の承認を挟みます。 公式のページでは、AI Agent のツールのうち承認の要るものを Human review の段階につなぐと、エージェントがそのツールを使おうとした時点でワークフローが止まり、選んだ経路で承認の依頼が送られ、承認すればツールが動き、却下すれば取りやめになるとされています。経路に Slack を選び、募集担当が承認します。

呼ぶ側のワークフローを公開していると、呼ばれる側も公開が要ります。 公式のページでは、本番で動くエージェントから呼ぶ小さなワークフローが公開されていないと「Workflow is not active and cannot be executed」で失敗し、その文がツールの結果としてエージェントに渡るとされています。エージェントはそれを記録として読もうとするので、5本とも公開の状態を確かめます。

人が確認する

1. Slack の承認の通知で、区分と根拠を読む … evidence の値が記録と合っているかを見ます
2. needs_human を先に見る … 記録どうしの食い違いは、店舗の担当と事務に確かめて台帳を直します
3. 承認したら各サイトの管理画面で直す … 掲載を止める・載せるのは担当の手です
4. 却下したら理由を残す … どの区分を、なぜ却下したかを記録します

stop_listing は当日中に直します。 成約した部屋の掲載を止めるのが、この構成のいちばんの目的だからです。add_listing と fix_terms は、写真と図面がそろっているかを見てからでよいとします。

承認の通知は、部屋ごとではなくサイトごとにまとめます。 1つの照合で20件の通知が別々に届くと、担当は上から順に承認ボタンを押すだけになります。サイトごとに stop_listing を先頭に並べた1通にし、evidence の値を見比べやすい表にします。

目標は、600件をならして1件1分です。 食い違いの無い部屋は担当が見る必要が無く、見るのは通知が来た部屋だけです。

例外に対処する

5行目と6行目は、エージェントの失敗を正常な結果に見せないための行です。 どちらもエージェントは何かしらの文を返すので、形の上では区分が付いて見えます。 Code ノードで結果の文と繰り返しの回数を見て、当たれば区分を上書きします。

記録を残す

• 照合に使った4つの一覧と台帳の出力（日付つき）
• Compare Datasets の4つの枝の結果
• 部屋ごとのエージェントの結果（区分、evidence、下書き）と、呼んだツールの順序（Return Intermediate Steps をオンにして残す）
• Slack での承認・却下と、答えた人、時刻
• 各サイトの管理画面で直した日時（担当が作業一覧に付ける）
• 成約日から掲載を止めた日までの日数

最後の行が、この構成の成績表です。 成約から削除までの日数が、照合の回数を増やしたことでどれだけ縮んだかを、月ごとに見ます。ガイドラインの2週間に近い部屋が出ていれば、どこで止まっているかを調べます。