管理を受ける部屋や退去後の部屋の募集賃料を決めるときに、自社の成約記録と物件の属性から賃料を幅で見込み、近い成約事例を添えてオーナーへの提案の材料にする

処理の起点を決める

毎朝7時に、前日までに登録された部屋をまとめて処理します。 退去の予定は、退去の1か月ほど前に入るのが普通です。その日のうちに賃料の材料がそろえば、原状回復の工事の間にオーナーと賃料を決められます。

新しく管理を受ける部屋は、担当が手で動かせるようにもします。 管理の受託の提案は、オーナーとの面談の日程に合わせて急ぎで作ることがあるためです。

予測のモデルは、毎月1日に作り直します。 前月の成約を学習に足し、相場の動きを1か月遅れで追いかけます。 作り直したときは、前月の見込みに対して成約が幅に入った割合を出し、大きく下がっていれば、新しいモデルを使う前に担当の責任者が確かめます。

入力データを集める

質を決めるのは、成約の記録の正しさです。 賃料の欄に共益費を含めた部屋と含めない部屋が混ざっている、フリーレントの月数が空欄のまま、といった記録が多いと、予測の幅が広がるだけでなく、近い事例として間違った賃料を見せることになります。

賃料は、賃料と共益費の合計で揃えます。 入居者が比べるのは毎月払う総額で、賃料と共益費の配分は物件ごとの考え方で違います。フリーレントがある成約は、その月数を2年で割った分を差し引いた「実質の月額」も別の列に持ちます。 見かけの賃料だけを学習すると、フリーレントで決めた部屋の賃料が相場に見えてしまいます。

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

台帳からは、毎朝 CSV で出力して読みます。 入居者や入居希望者の氏名などの個人の情報は出力に含めません。予測に要るのは部屋の属性と成約の条件だけです。

オーナーの名前も、予測の処理には持ち込みません。 提案書の宛名は、提案書の様式の側で担当が入れます。

AIへ渡す前に整形する

1. 賃料の揃え … 賃料と共益費の合計の列と、フリーレントを差し引いた実質の月額の列を作ります
2. 成約の時期の列 … 成約した月（1〜3月の繁忙期を区別）と、成約日から今日までの月数を列にします
3. 築年数の計算 … 成約日の時点の築年数を計算します。今日の築年数で学習しないことが大事です
4. 駅の扱い … 最寄り駅を区分の列にし、成約の少ない駅（年に数件）は沿線とまとめます
5. 外れた記録を除く … 社宅の一括の契約、身内の契約、事業用への転用など、相場で決まっていない成約に印を付けて学習から外します
6. 事例の選定用の尺度の揃え … 面積・徒歩の分数・築年数・階数を同じ尺度に直し、近さを測れるようにします

6番目の尺度は、近さの重みを兼ねます。 面積の1㎡の差と、徒歩の1分の差と、築年数の1年の差を同じ重さで測ると、面積の差が効きすぎます。担当と相談して「どの差なら同じくらい賃料に効くか」を決め、その分だけ尺度を伸び縮みさせます。 最初は面積2㎡・徒歩2分・築3年を同じ距離とする、のような素直な置き方で始め、担当が外した事例の理由を見て直します。

3番目を間違えると、古い成約がすべて割安に見えます。 3年前に築10年で決まった部屋を、今の築13年として学習すると、築年数の効き方を小さく見積もることになります。

5番目は、担当に聞かないと分からない記録が多くあります。 最初に過去3年分の成約を担当に見てもらい、相場で決まっていないものに印を付ける作業が、最初の準備になります。

AIに処理させる

機械学習にさせるのは、賃料の幅の予測と、近い事例の選定の2つです。 生成AIにさせるのは、その結果を説明する文の下書きだけです。

学習と予測の流れは次のようになります。

from sklearn.ensemble import HistGradientBoostingRegressor
from sklearn.neighbors import NearestNeighbors

cols = ["面積", "徒歩分", "築年数", "階", "総階数", "間取り", "方位",
        "駅", "構造", "設備数", "繁忙期", "成約から月数"]
cst = {"面積": 1, "徒歩分": -1, "築年数": -1}
models = {q: HistGradientBoostingRegressor(
             loss="quantile", quantile=q, monotonic_cst=cst,
             categorical_features=["間取り", "方位", "駅", "構造"])
          .fit(X[cols], y) for q in (0.2, 0.5, 0.8)}
nn = NearestNeighbors(n_neighbors=5).fit(Z_same_line)   # 尺度を揃えた属性
dist, idx = nn.kneighbors(z_target)

事例は、予測のモデルとは別に選びます。 予測のモデルは多くの成約から傾向を学ぶので、「この5件が根拠です」と言える形にはなりません。 オーナーに見せる根拠は、実際に決まった部屋そのものが一番伝わります。

事例の選び方には、2つの条件を付けます。 同じ駅か同じ沿線の成約に限ること、成約日が2年以内のものを優先することです。古い事例しか近くに無いときは、その旨を提案の材料に出します。

幅の確かさは、時間の順に分けて測ります。 scikit-learn の TimeSeriesSplit は、訓練のデータが常にテストのデータより前になるように分けるとされています。直近の6か月を1か月ずつテストにし、成約が幅（0.2〜0.8）の中に入った割合が6割前後になっているかを見ます。 あわせて、mean_pinball_loss でそれぞれの分位点の予測を alpha を合わせて測ります。

2行目がいちばん大事です。 生成AIに説明の文を頼むと、「7万円前後が妥当」のような丸めた数字を自分で書きます。 文に出す数字は、渡したJSONの値だけに限ります。

指示内容を固定する

あなたは賃貸管理会社の担当者が、オーナーに募集賃料を相談するときの
説明の文の下書きを作る係です。

【使ってよい情報】
渡したJSONの値だけを使ってください。
- 見込みの幅（下・中・上）、近い成約事例5件、前回の成約賃料との差、
  担当の書き足し

【守ること】
- 数字は、JSONにある値をそのまま書いてください。丸めたり、新しい数字を作ったりしないでください。
- 募集賃料を「いくらにすべき」と1つに決めないでください。
  幅のどこで出すかで、決まるまでの見込みの日数がどう変わりそうかを、事例の日数を使って書いてください。
- 近い成約事例は、成約の年月、面積、築年数、賃料、決まるまでの日数を書き、
  部屋番号や入居者のことは書かないでください。
- 「相場が上がっている」「人気のエリア」のような、JSONに根拠の無い主張を書かないでください。
- 事例の成約日が2年より前のものしか無い場合は、そのことを書いてください。
- 400字以内、です・ます調で書いてください。

【JSON】{estimate_json}

「1つに決めない」を書くのは、提案の主体を間違えないためです。 管理会社が出すのは材料で、決めるのはオーナーです。 文が「7万2千円で募集します」となっていると、担当はそのまま読み上げてしまいます。

「決まるまでの日数を事例から書く」は、オーナーの判断にいちばん効く材料です。 幅の上の方で決まった事例が60日かかっていて、中ほどの事例が15日なら、高く出すことの代償が日数で見えます。

出力形式を固定する

予測と事例の結果は、次の形のJSONでまとめます。

{
  "room_id": "B-1203-305",
  "estimate": { "low": 68000, "mid": 71000, "high": 74000, "unit": "円（賃料＋共益費）" },
  "previous": { "rent_total": 75000, "contracted": "2022-03", "diff_from_mid": -4000 },
  "comparables": [
    { "contracted": "2026-04", "area_m2": 25.4, "age_years": 15,
      "walk_min": 7, "rent_total": 72000, "days_to_contract": 21,
      "same_building": true }
  ],
  "warnings": ["近い事例のうち2件は成約日が2年より前"],
  "note_by_staff": ""
}

comparables には5件を並べます。warnings には、事例が古い、同じ駅に事例が少ない、予測する部屋の属性が学習の範囲の外にある（面積が極端に広いなど）といった注意を、Python の側で入れます。

1つ目の理由は、数字の出どころを1か所にできることです。 提案書の数字も、生成AIの文の数字も、このJSONから取ります。どこかで数字が書き換わっても、JSONと見比べればすぐ分かります。

2つ目は、days_to_contract を事例ごとに持てることです。 賃料と日数が並ぶので、担当はオーナーに「この賃料なら、このくらいの日数で決まっている」と説明できます。

3つ目は、warnings で見込みの弱いところを先に示せることです。 事例が古い、数が少ないときは、幅の信用度が下がることを、提案の前に担当が知っておく必要があります。

提案書の様式には、たとえば次のように書き出します。

【募集賃料の材料】B-1203 305号室（1K 25.1㎡ 築15年 徒歩7分 3階）
見込み（賃料＋共益費）  下 68,000円／中 71,000円／上 74,000円
前回の成約  75,000円（2022年3月）── 見込みの中より 4,000円高い
近い成約事例
  1 2026年4月 同じ建物 25.4㎡ 3階  72,000円  21日
  2 2026年2月 同じ駅   24.8㎡ 2階  70,000円  12日
  3 2025年11月 同じ駅  26.0㎡ 4階  74,000円  58日
  4 2025年9月 同じ沿線 25.0㎡ 2階  69,000円  15日
  5 2024年6月 同じ駅   25.2㎡ 3階  73,000円  33日
注意  事例5は成約日が2年より前
担当の書き足し（必須）  ＿＿＿＿＿＿

3番目と1番目を並べると、オーナーに伝えたいことが見えます。 7万4千円で決まった事例は58日かかり、7万2千円の事例は21日で決まっています。2千円の差と、1か月余りの空室の差を、オーナーが自分で比べられます。

生成AIの文の下書きは、{"draft": "", "numbers_used": []} の形で受け取り、numbers_used に書いた数字がすべてJSONにあるかを Python で照合します。JSONに無い数字が1つでもあれば、その下書きは使わず担当に知らせます。

システムへ連携する

賃貸管理のシステムの募集賃料の欄には書き込みません。 募集賃料を入れるのは、オーナーが決めた後の担当の作業です。見込みが自動で募集に出てしまう経路を作らないためです。

人が確認する

担当が、オーナーに提案する前に必ず確かめます。

1. warnings を先に見る … 事例が古い、少ない、属性が範囲外。当てはまるときは、幅を参考にとどめ、担当が別の材料を足します
2. 事例を1件ずつ見る … 同じ建物の事例か、向きや階が大きく違わないか。根拠として見せたくない事例（特殊な事情で決まったもの）は外して、次に近い事例に差し替えます
3. 部屋の事情を書き足す … リフォーム、眺望、騒音、周辺の変化など、台帳に無いことを書きます
4. 提案する賃料の案を決める … 幅の中のどこに置くかを、事情と前回の賃料を見て決めます
5. 下書きの文を直す … オーナーとのこれまでのやり取りに合わせて言い回しを整えます

4番目で幅の外に出すときは、理由を書きます。 「リフォーム済みで上に5千円」のような理由が残っていれば、成約の結果が出たときに、その判断が当たったかを確かめられます。

例外に対処する

2行目と5行目が、幅をいちばん信用してはいけない場面です。 学習のデータに似た部屋が無いと、モデルは近くの条件から引き延ばした値を出します。数字は出ますが、根拠は薄くなります。

記録を残す

• 部屋ごとの見込み（下・中・上）と、選んだ事例5件、使ったモデルの版
• 担当が外した事例と、その理由、書き足した事情
• 提案した賃料、オーナーが決めた賃料、決めた日
• 成約の賃料と、募集から成約までの日数
• 見込みの幅に入った割合（毎月、駅・間取りごと）

3つ目と4つ目がそろうと、提案の仕方の振り返りができます。 幅の上で出して長引いた部屋、中ほどで出してすぐ決まった部屋が並ぶので、オーナーへの次の提案で「前回はこうでした」と示せます。