「問い合わせが少ないから、家賃を下げましょう」
そう提案されても、本当に家賃が原因とは限りません。検索結果には表示されているのに写真で選ばれていない、問い合わせ後の返信が遅い、内見時の印象で候補から外れている――詰まり方によって打ち手は変わります。
そこで、賃貸募集を次の5段階に分けます。
閲覧 → 問い合わせ → 内見 → 申込 → 契約
各段階の件数と通過率を同じ形式で記録すれば、「反響が悪い」という曖昧な状態を、「詳細閲覧から問い合わせへの転換率が落ちている」のように特定できます。
この記事では、スプレッドシートで募集ファネルを作り、異常を自動通知するところまで、初心者向けに解説します。単発の空室対策ではなく、次の物件でも再利用できる監視システムを作ることが目標です。
先に結論:家賃を変える前に「どこで落ちたか」を確認する
募集ファネルの各段階で疑うべき項目は異なります。
| 数字が落ちた場所 | 最初に確認する項目 | すぐに家賃を下げない理由 |
|---|---|---|
| 表示・閲覧 | 掲載状況、検索条件、設備タグ、1枚目の写真 | 掲載漏れや写真が原因なら値下げでは直らない |
| 閲覧→問い合わせ | 初期費用、写真枚数、間取り図、設備、募集文 | 詳細情報の不足で離脱している可能性がある |
| 問い合わせ→内見 | 初回返信時間、内見可能枠、鍵の手配 | 運用上の遅れなら条件変更は不要 |
| 内見→申込 | 室内、共用部、臭い、騒音、競合との差 | 現地で初めて分かる欠点を切り分ける必要がある |
| 申込→契約 | 審査、必要書類、契約条件、連絡速度 | 申込数が少ない場合は偶然の影響も大きい |
ファネルは原因を自動的に証明するものではありません。調べる順番を絞る診断装置です。
Hiroサイトの実行ログから学んだ「失敗も監視する」設計
Hiroが運用する auto-ai-blog の generator/logs/generate.log を確認すると、2026年7月11日の記事生成は次のように記録されています。
| 時刻 | 記録 |
|---|---|
| 16:12:38 | 「賃貸募集条件を見直すためのAIチェックリスト」を選択 |
| 16:15:07 | 下書き生成に成功 |
| 16:15:12 | Geminiによるレビューが認証エラーで失敗 |
| 16:18:27 | Codexへ切り替え、レビューに成功 |
| 16:21:09 | 最終チェックに成功し、記事を保存 |
| 16:21:09 | Notionへの保存に成功 |
トピック選定からレビュー成功までは5分49秒、最終チェック成功・保存までは8分30秒でした。「約6分12秒」という元案の記載とは一致しないため、本記事では実ログに合わせて訂正しています。
このログが証明するのは、賃貸募集の成果ではありません。自動処理について、開始、成功、失敗、代替処理、保存まで追跡できるというサイト固有の運用実績です。
賃貸募集の監視でも同じ設計が必要です。反響減少だけでなく、次の状態も通知対象にします。
- 媒体データが更新されていない
- 問い合わせ件数だけ未入力
- 通知処理そのものが停止している
- 同じ問い合わせが重複集計されている
- 募集終了後も掲載中になっている
なお、このサイトの generator/ai_slop_guidelines.json には10項目の品質検査が保存され、最低合格点は8点です。固有データ、数字の根拠、視覚的証拠、限界、読後アクション、類似記事との差別化などが評価対象になっています。
ステップ1:ファネルの定義を統一する
最初に、担当者間で言葉の意味をそろえます。
| 指標 | 推奨する定義 |
|---|---|
| 表示数 | 検索結果などに物件が表示された回数 |
| 詳細閲覧数 | 物件詳細ページを開かれた回数 |
| 問い合わせ数 | 重複を除いた問い合わせ件数 |
| 内見数 | 実際に実施した内見件数 |
| 申込数 | 入居申込書を受領した件数 |
| 契約数 | 賃貸借契約の成立を確認した件数 |
| 初回返信時間 | 問い合わせ受信から最初の有人返信までの時間 |
| 募集日数 | 募集開始日から申込日または募集終了日までの日数 |
「内見予約」と「内見実施」を混ぜると、キャンセル率が見えません。可能なら別々に記録してください。
集計期間も統一します。週次で見る場合は、月曜日から日曜日など、開始曜日を固定します。媒体ごとに集計期間が違う場合は、無理に合算せず別行にします。
ステップ2:スプレッドシートに必要な列を作る
最初は1部屋、1媒体から始めます。最低限、次の列を用意してください。
| 列 | 項目 | 入力例 |
|---|---|---|
| A | 週の開始日 | 2026/07/20 |
| B | 物件ID | A203 |
| C | 媒体 | 媒体A |
| D | 表示数 | 2,000 |
| E | 詳細閲覧数 | 200 |
| F | 問い合わせ数 | 10 |
| G | 内見実施数 | 4 |
| H | 申込数 | 1 |
| I | 契約数 | 1 |
| J | 初回返信時間の中央値 | 35分 |
| K | 実施した変更 | 1枚目の写真を変更 |
| L | データ状態 | 正常 |
| M | 詳細閲覧率 | 数式 |
| N | 問い合わせ率 | 数式 |
| O | 内見化率 | 数式 |
| P | 申込率 | 数式 |
| Q | 契約率 | 数式 |
率は次の式で計算できます。
詳細閲覧率 = 詳細閲覧数 ÷ 表示数
問い合わせ率 = 問い合わせ数 ÷ 詳細閲覧数
内見化率 = 内見実施数 ÷ 問い合わせ数
申込率 = 申込数 ÷ 内見実施数
契約率 = 契約数 ÷ 申込数
Googleスプレッドシートでは、たとえばM2からQ2へ次の数式を入れます。
=IFERROR(E2/D2,"")
=IFERROR(F2/E2,"")
=IFERROR(G2/F2,"")
=IFERROR(H2/G2,"")
=IFERROR(I2/H2,"")
ゼロ除算を0%にすると、「データがない」のか「成果がゼロ」なのか区別できません。そのため、母数がゼロなら空欄にする方が安全です。
ステップ3:重複と集計ズレを除く
ファネル分析で最も危険なのは、計算式より元データの不整合です。
同じ人がフォーム、電話、別媒体から連絡した場合、そのままでは問い合わせ3件として集計されます。個人を特定できる情報を分析表へ残さず、社内で生成した問い合わせIDを使って重複を除きます。
次の点も確認してください。
- 問い合わせ日と内見日を別々に保存する
- 内見キャンセルを実施数へ含めない
- 同じ物件の媒体違いを別行で持つ
- 募集開始日と掲載開始日を分ける
- 申込取り下げと審査否決を区別する
- 募集条件を変更した日時を残す
契約は問い合わせから数週間後に決まることがあります。同じ週の「問い合わせ数」と「契約数」を割ると、異なる顧客群を比較する場合があります。厳密に見るなら、問い合わせIDで後工程をひも付けるコホート集計を使います。
ステップ4:基準値を作り、母数不足を表示する
「問い合わせ率は何%なら合格か」という万能な基準はありません。エリア、賃料帯、間取り、季節、媒体によって変わるからです。
まずは4週間程度記録し、自物件の基準値を作ります。ただし、4週間という期間も絶対ではありません。表示数や問い合わせ数が少なければ、期間を延ばしてください。
たとえば次のように判定します。
表示数100未満 → 母数不足
詳細閲覧数20未満 → 問い合わせ率は参考値
直近7日が28日平均より30%以上低い → 要確認
データ更新が48時間以上ない → 取得停止の疑い
これらは説明用の仮定であり、賃貸業界共通の合格基準ではありません。自社データを蓄積した後で調整してください。
小さな母数では、問い合わせが1件増えるだけで率が大きく動きます。率だけでなく、必ず分子と分母を併記します。
悪い表示:
問い合わせ率が50%低下しました。
良い表示:
詳細閲覧20件に対する問い合わせが2件から1件へ減少しました。母数が小さいため、条件変更前に翌週も確認します。
ステップ5:詰まり方に合わせて改善する
表示数が少ない場合
媒体への掲載有無、募集終了扱い、設備タグ、住所、駅、徒歩分数、入居可能日を確認します。管理会社から「掲載済み」と聞くだけでなく、実際の検索条件で表示されるか確認してください。
詳細閲覧率が低い場合
1枚目の写真、検索結果上の賃料総額、間取り、築年数、駅距離を競合と並べます。写真を変えるときは、明るさだけでなく、部屋の広さや生活動線が伝わるかを確認します。
問い合わせ率が低い場合
初期費用、設備、入居可能日、写真枚数、間取り図、禁止事項の見え方を確認します。家賃だけでなく、管理費を含む毎月の総額と契約時費用を比較してください。
内見化率が低い場合
初回返信時間、候補日時の数、オンライン予約の分かりやすさ、鍵の手配を調べます。平均返信時間だけでは長時間放置された問い合わせを隠すため、中央値と90パーセンタイルを併記すると異常を見つけやすくなります。
申込率が低い場合
室内清掃、臭い、騒音、共用部、照明、温度、携帯電波など、掲載画面では分からない項目を確認します。内見後の断り理由は自由記述だけでなく、「賃料」「初期費用」「室内」「共用部」「立地」「競合で決定」などに分類します。
ステップ6:自動通知を設定する
通知は多すぎると読まれなくなります。緊急度を3段階に分けます。
| レベル | 条件例 | 対応 |
|---|---|---|
| 情報 | 週次レポート完成 | 次回会議で確認 |
| 注意 | 主要KPIが基準値を下回った | 元データと掲載画面を確認 |
| 異常 | データ未更新、掲載終了物件が掲載中 | 当日中に担当者へ連絡 |
通知文には必ず次の5項目を入れます。
- どの物件・媒体か
- どの指標が変化したか
- 分子と分母はいくつか
- データはいつ更新されたか
- 次に確認する担当者は誰か
【注意】A203・媒体A
直近7日:
詳細閲覧 200件
問い合わせ 4件
問い合わせ率 2.0%
過去28日平均:3.5%
データ更新:2026/07/22 06:00
確認事項:初期費用表示、入居可能日、掲載写真
担当:募集担当者
AIには、通知の送信や家賃変更を直接決定させず、最初は要約と確認候補の提示だけを任せます。
ステップ7:一度に変える施策を絞る
写真、家賃、礼金、募集文を同日に変えると、どれが数字に影響したのか分かりません。緊急性がなければ、変更は一度に1項目か、目的が同じ小さな一群に絞ります。
説明用の仮定として、次の変化を考えます。
| 期間 | 表示 | 詳細閲覧 | 問い合わせ | 変更 |
|---|---|---|---|---|
| 変更前 | 2,000 | 200 | 10 | なし |
| 変更後 | 2,050 | 280 | 13 | 1枚目の写真のみ変更 |
詳細閲覧率は10.0%から約13.7%へ上がっています。ただし、これだけで写真の効果が証明されたとは言えません。季節、競合の募集終了、掲載順位なども影響します。
同条件の別物件、前年同時期、変更していない媒体などと比較し、少なくとも複数週確認してから判断します。
専門家目線で確認したいKPI
募集成果だけでなく、データと自動化の健全性も測ります。
募集成果
- 表示数、詳細閲覧数
- 問い合わせ数、問い合わせ率
- 内見予約数、内見実施数、キャンセル率
- 申込数、申込率
- 契約数、契約率
- 募集日数、入居可能後の空室日数
対応品質
- 初回返信時間の中央値
- 初回返信時間の90パーセンタイル
- 内見候補日時を提示できた割合
- 内見後24時間以内のフォロー率
- 断り理由を取得できた割合
監視システムの品質
- 最終データ取得日時
- 欠損行数
- 重複問い合わせ数
- 自動処理の成功・失敗件数
- 通知への対応完了率
- 誤検知されたアラートの割合
家賃収入への影響を見る場合は、概算値として次の式も使えます。
推定空室損失 = 月額賃料 ÷ 30.4 × 空室日数
これは比較用の簡易計算です。管理費、広告費、フリーレント、原状回復費、税金などは別に扱います。
よくある失敗と対策
AIに個人情報をそのまま入力する
氏名、電話番号、メールアドレス、勤務先、年収、身分証情報は、外部AIへ安易に送らないでください。個人情報保護委員会も生成AI利用時の個人情報入力について注意喚起しています。生成AIサービスの利用に関する注意喚起
分析には匿名IDと集計値を使い、利用サービスの規約、保存設定、学習利用の有無、社内ルールを確認します。
掲載終了物件を残してしまう
自動収集や更新処理が止まると、契約済み物件が掲載されたままになる恐れがあります。不動産公正取引協議会連合会は、実際に取引できない物件などを「おとり広告」の規制対象として示しています。「おとり広告」の規制概要とインターネット広告の留意事項
募集終了時は、各媒体の掲載停止を確認するチェックを自動処理とは別に設けます。
AIの診断を原因と断定する
「問い合わせ率が低いから募集文が悪い」は仮説です。掲載画面、管理会社の対応記録、競合条件、現地状態を人間が確認してから変更します。
自動通知を作って満足する
通知後の担当者と期限が決まっていないシステムは機能しません。「誰が、いつまでに、何を確認するか」を通知文に含め、完了状態まで記録します。
家賃を下げないことが目的になる
ファネル分析は値下げを避けるための理屈ではありません。競合比較と損失試算の結果、値下げや条件変更が合理的なら実施します。最終判断はオーナー、管理会社、必要に応じて宅地建物取引業などの専門家が行います。
この方法の限界
募集ファネルを整えても、すべての空室が解消するわけではありません。
立地、建物構造、周辺環境、重大な設備不足、需要そのものの減少は、写真や返信速度だけでは解決できません。また、問い合わせが少ない物件では統計的な判定が難しく、数週間の変化が偶然である可能性もあります。
媒体側から表示数や詳細閲覧数を取得できない場合は、問い合わせ以降だけを記録します。取得できない数字を推測で埋めるより、「未取得」と明記する方が安全です。
賃貸住宅管理業者には、管理戸数など一定の条件に応じた登録制度や業務上の義務があります。自動化は専門家の判断や適切な管理を置き換えるものではありません。国土交通省「賃貸住宅管理業者の業務」
既存記事との違い
既存記事が「募集条件のチェック」や「空室原因の分析」を中心にしているのに対し、本記事は次の点まで踏み込みました。
- 閲覧から契約までの定義を統一する
- 重複、欠損、期間ズレを除く
- 母数不足を誤判定しない
- データ取得停止も監視する
- 通知後の担当者と期限を決める
- 変更履歴を残し、次の空室で再利用する
差別化の中心はAIによる文章生成ではありません。判断に使ったデータ、変更内容、結果、失敗を残す運用資産です。
今日から始める30分アクション
最初から完全自動化する必要はありません。今日は次の順番で進めてください。
- 募集中の1部屋を選ぶ
- 表示、閲覧、問い合わせ、内見、申込、契約の定義を決める
- スプレッドシートに17列を作る
- 直近4週間で取得できる数字を入力する
- 取得できない項目は「未取得」と記録する
- 最も大きく落ちている1段階を確認する
- 改善施策を1つだけ決める
- 翌週の確認日と担当者を入力する
この1部屋を4週間運用できたら、対象物件と媒体を増やします。
賃貸募集の改善で先に自動化すべきなのは、家賃の決定ではありません。数字の取得、欠損検知、異常通知、変更履歴の保存です。そこまで整えば、「空室だから何か変える」対応から、「どの段階が落ちたので何を確認するか」という再現可能な運用へ移行できます。