管理物件の空室の期間と反響・内見の数を毎月見て、長く空いている部屋の募集条件の見直し案とオーナーへの提案の文面を作る

処理の起点を決める

毎月1日の朝7時台に、月1回の時間主導型のトリガーで動かします。 空室の日数、反響、内見はどれも月単位で見るもので、毎日動かしても案はほとんど変わりません。 月1回にして、担当者が月初に相談の準備を始められるようにします。

ただし、ポータルサイトの反響の件数のCSVは、月末に担当者が置く必要があります。 動き始めたら、まずCSVの対象の月を確かめます。前月の分が無ければ、案を作らずに担当者へ「反響のCSVが届いていない」とだけ送ります。反響の件数が無いと止まっている段階を判定できず、どの部屋にも賃料を下げる案が出てしまいます。

繁忙期の前には、月の半ばにもう一度動かす設定を足せます。 1〜3月は空室の動きが速く、月初の案が月の半ばには古くなることがあります。その場合も、反響のCSVを月の半ばに出せることが前提です。

トリガーは賃貸管理部の共有の管理用アカウントで作ります。 インストール型のトリガーは作った人のアカウントで動き、失敗したときのメールもその人に届きます。

入力データを集める

質を決めるのは、成約の記録です。 見込みの日数は、似た部屋の過去の成約から出します。成約の記録に、募集を始めた日が無ければ、決まるまでの日数が出せません。 5年分のうち、募集を始めた日が残っている成約だけを使います。

オーナーの方針のシートは、案の範囲を絞るために持ちます。 「賃料はこれ以上下げない」「フリーレントは付けない」というオーナーに、その案を出しても使えません。担当者が知っているオーナーの意向を、表にしておきます。

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

CSVとスプレッドシートは、範囲を1回でまとめて読み、スクリプトの中で計算します。 40戸の部屋それぞれに、成約の記録の数千行から似た部屋を探します。

似た部屋の条件と、見込みの日数の出し方は、次の手順に決めます。

似た部屋 ＝ 同じ駅 かつ 同じ間取り かつ 専有面積が ±15％ かつ 築年が ±10年 の、直近24か月の成約
賃料の位置 ＝ 今の㎡あたりの賃料（管理費込み）が、似た部屋の成約の㎡あたりの賃料の何パーセンタイルか
見込みの日数 ＝ 似た部屋のうち、賃料の位置が今の部屋と同じ帯（25％刻み）だった成約の、募集から申込までの日数の中央値

見直しの候補ごとの日数も、同じ手順で出します。 賃料を下げる候補なら、下げた後の位置の帯の成約の中央値、礼金をなくす候補なら、似た部屋のうち礼金が無かった成約の中央値です。似た部屋が8件に満たないときは、日数を出さずに「似た成約が少ない」とします。 数件の成約から出した中央値は、オーナーへの提案に載せられる数字ではありません。

AIへ渡す前に整形する

1. CSVの対象の月の確認 … 空室の一覧と反響のCSVが前月末の分かを確かめます
2. 対象の部屋の抽出 … 募集を始めた日から60日を超え、申込が入っていない部屋だけにします
3. 止まっている段階の判定 … 直近3か月の反響の件数を、似た部屋の過去の水準と比べ、少なければ inquiry（反響で止まっている）とします。反響が足りていて内見の割合が低ければ viewing、内見があって申込が無ければ application とします
4. 似た部屋の成約の抽出と、賃料の位置の計算 … 「データの取得方法」の手順で出します
5. 見直しの候補ごとの見込みの日数 … 賃料を1段下げる、礼金をなくす、フリーレントを1か月付ける、の3つについて出します。オーナーの方針で使えない候補は外します
6. 見送りの理由のまとめ … 内見の記録のメモから、その部屋の分を時系列で並べます。仲介会社の担当者名と内見者の情報は消します
7. 賃料のそろえ方 … 成約の記録と空室の一覧で、管理費を賃料に含めているかどうかが違うことがあります。どちらも管理費込みの㎡あたりの賃料にそろえてから比べます。 そろえないと、管理費の高い部屋ほど相場より安く見えます

3番目の判定を、AIに任せないでください。 段階の判定は、見直す条件を決める根拠そのものです。線をシートに置き、スクリプトで判定しておけば、なぜその案になったかを後から説明できます。

5番目で設備の候補を数字にしていないのは、成約の記録に設備の有無が揃っていないことが多いからです。 記録に設備の列があれば、設備の有無で分けた中央値も出せます。無ければ、設備の案はAIに理由だけを書かせ、日数は付けません。

AIに処理させる

させるのは、止まっている段階と、候補ごとの見込みの日数と、見送りの理由のメモを読んで、見直す条件を選び、オーナーへの提案の文面にすることです。 日数の計算と段階の判定は前処理で終わっています。

選ぶ条件は、1部屋に最大2つまでにします。 賃料も礼金も設備も、と並べると、オーナーはどれも決められません。第1案と第2案に絞り、それぞれに理由と見込みの日数を添えさせます。

4行目が、オーナーへの文面でいちばん起きやすい失敗です。 何も言わなければ「この賃料に見直せば、早期の成約が見込めます」と書きます。見込みの日数は過去の似た部屋の中央値で、この部屋が決まる約束ではありません。 約束に読める文面は、決まらなかったときにオーナーとの関係を損ないます。

指示内容を固定する

あなたは賃貸住宅の管理会社で、空室が長引いた部屋の募集条件について、
オーナーへ相談する担当者を支える立場です。
与えられた数字と記録だけを使ってください。推測で埋めないでください。

【あなたの仕事】
部屋ごとに、見直す条件を最大2つ選んで順位を付け、
担当者向けの理由と、オーナーへの提案の文面を書いてください。

【条件の選び方】
- stage が inquiry なら、rent_down（賃料）か listing（掲載の写真と文面）を中心に選ぶ
- stage が viewing なら、key_money_zero（礼金）か free_rent（フリーレント）を中心に選ぶ
- stage が application なら、equipment（設備）か room_condition（室内の状態）を中心に選ぶ
- stage が insufficient_data なら、選ばずに human_review を返す
- candidates に無い条件は選ばない

【厳守事項】
- 賃料、日数、件数は入力の値をそのまま書いてください。計算や推定をしないでください。
- candidates に無い賃料や、方針で外された条件を提案しないでください。
- 「決まります」「成約が見込めます」など、成約を約束する書き方をしないでください。
  日数は「似た部屋の過去の成約では、中央値で○日でした」と書いてください。
- 見送りの理由のメモから、内見した人の年齢、家族構成、国籍などに触れないでください。
- 設備の案に日数が付いていない場合は、日数を書かないでください。
- オーナーへの文面は、です・ます調で、400字以内にしてください。
- 担当者向けの理由には、選ばなかった条件を選ばなかった理由も1文で書いてください。

【部屋の情報】{room_json}
【止まっている段階】{stage}
【候補と見込みの日数】{candidates_json}
【見送りの理由のメモ（時系列）】{feedback}
【オーナーの方針】{owner_policy}

「選ばなかった条件の理由」を書かせるのは、担当者が確かめやすくするためです。 賃料を下げない案が出たときに、なぜ下げないのかが書かれていれば、担当者はオーナーから「賃料を下げればいいのでは」と聞かれたときの答えを持てます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "room_id": "R-10234",
  "stage": "viewing",
  "proposals": [
    {
      "rank": 1,
      "lever": "rent_down | listing | key_money_zero | free_rent | equipment | room_condition | human_review",
      "candidate_id": "C2",
      "expected_days_median": 0,
      "reason_for_staff": "",
      "not_chosen_reason": ""
    }
  ],
  "owner_message": ""
}

1つ目の理由は、candidate_id で前処理の候補とつなげられることです。 AIが選んだ案が、どの候補の数字を根拠にしているかを、スクリプトが確かめられます。expected_days_median が、その候補の前処理の値と一致しなければ、その案を捨てます。

2つ目は、lever を決まった値に絞れることです。 自由文で案を書かせると、「家賃の調整」「条件緩和」と言い方が毎月変わり、どの見直しで決まったかを後から数えられません。 決まった値なら、半年後に「viewing の部屋で key_money_zero を選んだら何日で決まったか」を記録から出せます。

3つ目は、構造化出力の決まりで、項目の欠けが起きないことです。 OpenAI の構造化出力ではすべての項目を required にするため、not_chosen_reason を空にしたくても、項目そのものは必ず返ります。 空の文字列が返ったときは、スクリプトの側で「理由なし」と表示します。

拒否のときは、スキーマに沿わない応答が返ります。 安全上の理由で応答しない場合、応答に refusal の項目が入ります。refusal があればその部屋は人に回し、文面の下書きを作りません。

システムへ連携する

OpenAI API は UrlFetchApp.fetch で呼びます。 method を post、contentType を JSON にし、headers に API キーを入れます。muteHttpExceptions を true にして、失敗の応答でも例外で止めずに応答のコードを見ます。 API キーはスクリプトのプロパティに置きます。

オーナーへの文面は、Gmail の下書きにします。 createDraft で下書きを作り、replyTo に担当者のアドレスを、name に会社と担当者の名前を指定します。送信はしません。 上長の確認を経て、担当者が送ります。郵送やFAXのオーナーには、下書きの本文を手紙の文面に使います。

賃貸管理のシステムとポータルサイトには書き込みません。 募集条件を変えるのは、オーナーの返事を受けた後の担当者の作業です。

人が確認する

担当者が、自分の担当の部屋の案をすべて確かめます。 40戸を4名で分けるので、1人10戸ほどです。

1. 段階の判定を確かめる … 反響と内見の数が、自分の知っている状況と合うかを見ます。ポータルサイトの掲載が止まっていた月があると、反響が少なく出ます
2. 案が部屋の状況に合うかを確かめる … 室内の状態、オーナーとの過去のやり取りを知っているのは担当者です
3. 数字を確かめる … 見込みの日数と似た部屋の件数を見ます。似た部屋の件数が少ない案は、文面から日数を外します
4. 文面を直す … オーナーとの関係に合わせて、言葉を直します
5. 上長の確認 … 賃料を下げる案は、必ず上長が確認します

1番目を省かないでください。 掲載を止めていた月、写真を撮り直していた月の反響は、部屋の人気とは関係ありません。その月を含めて判定すると、inquiry と出て賃料を下げる案になります。

5番目の上長の確認は、賃料を下げる案だけに絞ります。 礼金やフリーレントの案は担当者の判断で送れるようにしておかないと、月初に40戸の相談がそろう意味が薄れます。賃料はオーナーの収入に直結し、一度下げると戻しにくいので、二人の目を通します。

目標は、40件をならして1件15分です。 数字と案の確認に10分、文面の手直しに5分を想定しています。

例外に対処する

上から3行目までが、最初の数か月の大半を占めます。 どれもAIの問題ではなく、成約の記録と空室の一覧の整備の問題です。 似た部屋が少ない駅は、似た部屋の条件を「同じ駅」から「隣の駅まで」に広げるかを、担当者と決めます。

記録を残す

• その月に読み込んだCSVのファイル名と対象の月
• 部屋ごとの段階の判定、似た部屋の件数、賃料の位置、候補ごとの見込みの日数
• AIに渡した入力と、返ってきたJSONの全文
• 担当者が直した案と文面
• オーナーの返事（採用した条件、見送った条件）と、その後に決まるまでの日数
• そのときの似た部屋の条件と、段階の判定の線

5つ目が、この構成を良くしていく材料です。 見直しの後に実際に何日で決まったかを記録すれば、次からは「自社がこの見直しを提案した部屋が、何日で決まったか」を候補の数字に使えます。