管理物件の入居者の契約・更新の時期・問い合わせ・入居年数から翌月以降の退去を見込み、募集の準備とオーナーへの連絡の順番を出す

処理の起点を決める

毎月1日の朝6時に動かします。 前月末の入金の締めと解約の受付の入力が終わった後で、担当が朝の打合せで一覧を見られる時刻にします。

見込む先は「今後90日以内に解約の通知が届くか」です。 通知から退去までが30日前後なので、90日先まで見込めば、退去の2か月から3か月前に準備を始められます。 30日以内の見込みだけでは、通知が来てから動くのと変わりません。

1月と2月は、月の半ばにもう一度動かします。 3月に向けた転勤や進学の動きは、この時期に一気に出ます。月初の1回だけでは、2月の半ばに出た社宅の借上げの動きが3月の一覧まで載りません。

入力データを集める

質を決めるのは、解約の「通知を受けた日」です。 退去日しか残っていないと、「その月の時点で、90日以内に通知が届いたか」という答えが作れません。賃貸管理システムの書き出しに、通知の受付日の列があるかを最初に確かめます。 無い場合は、退去日から30日を引いて代え、その旨を記録に残します。

法人契約の記録は、過去の退去の月を持たせます。 社宅の借上げは、更新の時期ではなくその法人の人事異動の時期で動きます。同じ法人の社員が毎年3月と9月に退去しているなら、それが部屋の特徴になります。

入居者の年齢・国籍・家族の構成は、入力に入れません。 当たりが良くなる列があったとしても、その列で「出そう」と見た部屋を、オーナーへの説明に使えません。 理由として説明できない列は、最初から外します。

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

賃貸管理システムの帳票の機能で、前月末の時点の記録をCSVで書き出します。賃貸管理システムによって、書き出しの方法と列の名前が違います。 APIを持つものは定時に取りに行き、持たないものは帳票を定時に書き出す設定にして、営業部だけが読める共有フォルダに置かれたファイルを読みます。

過去の分は「その月の時点で見えていた記録」で作ります。 いまの契約の記録から過去の月を組み立てると、後から入力された解約の理由や、退去の後に締めた修理の記録まで含まれます。 その月の時点では見えていなかった値で学ばせると、本番で外れます。月末の書き出しを毎月保管し、それを過去の分に使います。

AIへ渡す前に整形する

1. 対象を絞る … 定期借家の契約、解約の通知がすでに届いている部屋、入居して3か月以内の部屋を外します
2. 更新までの残りを作る … 次の更新日までの日数を作ります。更新日を過ぎて自動で更新された部屋は、次の更新日から数え直します
3. 入居年数を作る … 入居日からの月数を作ります。更新の回数も別の列にします
4. 受付の記録を数える … 直近6か月の問い合わせと修理の依頼を区分ごとに数え、対応が終わるまでの日数の最大も作ります
5. 入金の遅れを作る … 直近6か月で期日から遅れた回数と、遅れの日数の最大を作ります
6. 法人の動きの月を作る … 法人契約の部屋について、その法人の社員が過去に退去した月の分布から、見込む先の90日に、その法人の動きの月が入るかを作ります
7. 季節の列を作る … 見込む先の90日に3月が入るか、9月が入るかを作ります
8. 学ばせる組を作る … 過去の各月末の時点の特徴と、「その後90日以内に解約の通知が届いたか」を組にします

2番目で、更新日そのものではなく残りの日数を使います。 更新の案内を送る時期は会社ごとに決まっていて、案内を受け取った後の数週間に通知が集まることがあります。残りの日数にすると、この山を学べます。

8番目で、検証の分け方を時期で切ります。 古い2年で学ばせ、直近の1年で確かめます。同じ部屋の別の月の組が両側に入ると、その部屋を覚えているだけで当たります。

AIに処理させる

させるのは、部屋ごとに今後90日以内に解約の通知が届く確率を見込むことだけです。 理由の並べ方、足し上げ、順番の付け方は、決めた計算で行います。

右端の列の no_signal が、担当に読ませたい部屋です。 確率は高いのに、理由の事実が1つも並ばない部屋は、モデルが特徴の組み合わせから見込んでいて、人が読める理由が無いということです。担当が自分の知っていることと照らします。

4行目を明記しておきます。 入金の遅れは見込みには効きますが、「出そうだから督促を強める」「出そうだから更新の条件を変える」という使い方は、この構成の目的から外れます。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と、理由・足し上げ・順番の規則を書いておきます。

【モデル】
- HistGradientBoostingClassifier(
    learning_rate=0.05, max_iter=500, early_stopping="auto",
    categorical_features="from_dtype", class_weight="balanced")
- CalibratedClassifierCV(estimator=上記, method="isotonic", cv=5)
  （学ばせる組が1,000件を大きく超えるため isotonic）
- 目的変数：月末から90日以内に解約の通知を受け付けたか（1/0）
- 学ばせる組：古い2年の各月末 ／ 確かめる組：直近1年の各月末

【理由の事実の表（学ばせる組から毎回作り直す）】
- 事実ごとに「その事実があった部屋の90日以内の通知の割合」と
  「全体の割合」を出し、比が1.5以上のものだけを理由の候補にする
- 事実の例：更新まで残り120日以内／入居4年以上／法人契約で動きの月が入る／
  直近6か月で設備の修理の依頼が2回以上／対応に30日以上かかった依頼がある／
  直近6か月で入金の遅れが2回以上／周辺の同じ間取りの募集が前年より多い
- 1つの部屋につき、比の大きい順に3つまで

【足し上げ】
- 空室の見込みの数（物件・オーナー・月）= Σ 部屋の確率
- 月の割り振り：通知の見込みの月 + 30日 を退去の見込みの月とする

【連絡の順番】
- オーナーごとに、空室の見込みの数の大きい順
- 同じ数なら、募集の図面・写真が無い部屋を含むオーナーを先に
- 担当が「準備に入らない」とした部屋は足し上げから外す

【印を付ける条件】
- low_history：その物件の種別・契約の種別で学ばせた組が 50 未満
- no_signal：確率が上位1割に入るのに、理由の事実が1つも無い
- prep_unknown：図面・写真の有無が分からない
- jump：前月から確率が 0.2 以上上がった

理由の事実を毎回作り直すのは、割合が年によって変わるからです。 周辺に新築の物件が増えた年は、「入居4年以上」の部屋の動きが大きくなります。学ばせ直すたびに、理由の表も同じ学ばせる組から作り直します。

「退去の見込みの月＝通知の見込みの月＋30日」は、目安です。 標準契約書では30日前の申入れとされていますが、自社の契約で予告の期間が違う物件は、その日数で置き換えます。 契約の記録に予告の日数の列を持たせておくと、ここが物件ごとに直せます。

出力形式を固定する

部屋ごとに、次の形のJSONを作り、部屋の一覧とオーナーの一覧の2つの表にします。

{
  "unit_id": "",
  "property_id": "",
  "owner_id": "",
  "as_of": "",
  "probability_90d": 0.0,
  "expected_moveout_month": "",
  "reasons": [
    { "fact": "", "value": "", "lift": 0.0 }
  ],
  "listing_ready": { "floor_plan": true, "photos_taken": "" },
  "flags": ["low_history | no_signal | prep_unknown | jump"],
  "model_version": "",
  "staff_override": { "prepare": null, "reason": "" }
}

reasons には比の大きい順に3つまでの要素を並べます。value にはその部屋の実際の値（「更新まで残り68日」「直近6か月で設備の修理の依頼3回」）、lift にはその事実があった部屋の通知の割合が全体の何倍だったかを入れます。

1つ目の理由は、reasons をそのままオーナーへの説明に使えることです。 「この部屋は更新まで残り68日で、過去に同じ条件の部屋は全体の2.1倍の割合で通知が来ています」と言えれば、オーナーは賃料の見直しの相談を聞く気になります。

2つ目は、listing_ready で準備の遅れが見えることです。 確率が高いのに図面や写真が古い部屋が、最初に手を付ける部屋です。 撮影日を持たせておけば、内装を変えた後に撮り直していない部屋も拾えます。

3つ目は、staff_override で担当の知っていることが残ることです。 担当が「準備に入らない」とした部屋が翌月に通知を出したかを数えれば、担当の判断とモデルのどちらが当たっていたかが分かります。

システムへ連携する

オーナーへの連絡は、担当が行います。 オーナーの一覧には空室の見込みの数と理由の事実が並びますが、電話や訪問の文面は担当が自分で考えます。 オーナーには確率の数字ではなく、「この3か月で2室ほど動きそうです」という幅で伝えます。

人が確認する

人が見るのは、オーナーの一覧の上位と、印の付いた部屋だけです。 3,000戸すべてを開く設計にはしません。

1. オーナーの一覧を上から見る … 空室の見込みの数が大きいオーナーから、連絡するかを決めます
2. no_signal と jump を確かめる … 理由の無い高い確率と、急に上がった部屋です。担当の知っていることと照らします
3. 上書きする … 更新の意思を聞いている、入居者と話した記録があるなどで、準備に入らないと決めた部屋は staff_override に理由を書きます
4. 準備に入る … 図面と写真の準備、賃料の相談の材料の用意を始めます

目標は、720件をならして1件1.5分です。 上位のオーナーの部屋は理由を読んで連絡を考えるので数分、それ以外は流し見るので数十秒です。印の多い月は、書き出しの漏れか、学期ならぬ転勤の時期で記録が大きく動いています。

例外に対処する

5行目は、モデルでは防げません。 法人がまとめて社宅を引き払うときは、個々の部屋の記録には何の兆しも出ません。法人の担当との付き合いで聞いた情報を、上書きで入れる経路を必ず残してください。

記録を残す

• 実行ごとに、読み込んだ書き出しのファイル名と日時、行数、対象から外した部屋の数と理由
• 学ばせたモデルの版（学ばせた期間、特徴の一覧、較正の方法）と、理由の事実の表
• 確かめる期間での外れ方（較正の曲線と、上位100室に実際に通知が来た部屋が何室入ったか）
• 部屋ごとの出力のJSONと、オーナーごとの足し上げ
• 担当の上書きの記録（準備に入らないとした部屋と理由）
• 実際に通知が届いた日と、見込みとの差

較正の曲線は、空室の見込みの数を信じてよいかを決めます。 確率を足し上げて数にする以上、確率0.3と出た部屋の3割前後に実際に通知が来ていないと、オーナーへの「2室ほど」が外れます。 曲線がずれ始めたら学ばせ直します。