空室期間を縮める退去〜再募集パイプライン設計

空室期間が伸びる原因は、立会や見積作成といった個々の作業が遅いことではありません。工程と工程の間に挟まる「待ち」の連鎖です。この記事では、1住戸を1本のパイプラインとして串刺しにするデータ設計と、待ちを可視化する状態管理の作り方を工程順に整理します。

なぜ空室期間は「作業時間」を削っても短くならないのか？

結論から言うと、退去から再募集までのリードタイムの大半は、誰かが作業している時間ではなく、誰かの返事を待っている時間だからです。

典型的な流れを工程に分解すると、次のようになります。

作業そのものは、それぞれ数十分から数時間で終わります。一方で太字にした3つの待ちは、日単位で発生します。ここを触らずに見積作成を速くしても、全体のリードタイムはほとんど動きません。

さらに厄介なのは、工程4〜6と工程9が別の担当・別のシステムで管理されている会社が多いことです。工事管理はExcelの工事台帳、精算は基幹システム、募集は募集用のシステムやポータル入稿ツール。1住戸が今どこで止まっているのかを、一目で答えられる人が社内にいない状態が生まれます。

空室期間のどこで止まっているかを、どう特定するか？

自動化ツールを検討する前に、8つの日付を1住戸1行で記録するところから始めてください。これが仕組み化の起点になります。

記録する日付は次の8つです。

1. 退去届受領日
2. 退去（鍵返却）日
3. 立会実施日
4. 原状回復見積の確定日
5. オーナー承諾日
6. 工事発注日
7. 完工日
8. 募集掲載日（＋申込日）

この8列があれば、区間ごとの日数が引き算だけで出ます。見るべきは平均値ではなく、区間ごとの分布と最長ケースです。平均7日の区間でも、半分は2日で終わり残りが20日かかっているなら、それは「遅い工程」ではなく「特定条件で止まる工程」です。

滞留区間を特定するときの判断基準を挙げます。

• 区間の日数が担当者によって大きく変わる → 属人的な運用の問題。手順の標準化が先。
• 区間の日数がオーナーによって大きく変わる → 承諾フローの問題。連絡手段と提案フォーマットの設計が効く。
• 区間の日数が時期（3月など）に集中して伸びる → キャパシティの問題。自動化より前倒し着手の設計が効く。
• 区間の日数がほぼ一定で長い → 工程そのものの問題。ここは自動化が効きやすい。

エクサテックが不動産会社の業務システムを設計するときも、いきなり要件定義書を書くことはしません。株式会社イーリアルティ様の転記エージェントでも、契約の前段階から何度も現場に足を運び、実際にどこで手が止まっているかを見るところから始めています。空室期間の短縮も同じで、どの区間が長いかを知らないまま作った仕組みは、速い工程をさらに速くするだけに終わります。

1住戸を1本のパイプラインにするデータ設計とは？

結論として、既存システムを統合する必要はありません。住戸を一意に識別するIDをキーに、日付と状態だけを集めた「状態テーブル」を1枚持つのが最小構成です。

状態テーブルに持つ項目

重要なのは「ボール保持者」列です。ステータスだけでは「工事発注待ち」が自社都合なのかオーナー都合なのかが分かりません。ボール保持者が「オーナー」のまま3日経過している住戸だけを抽出できれば、催促の優先順位が自動的に決まります。

ステータスの粒度

細かすぎると入力されなくなり、粗すぎると滞留が見えません。実務では次の粒度が扱いやすい設計です。

• 退去予告受領
• 立会日調整中
• 立会済・見積作成中
• オーナー承諾待ち
• 発注済・着工待ち
• 施工中
• 完工確認待ち
• 募集条件調整中
• 募集準備中（原稿・写真）
• 募集中
• 申込あり

10前後。1画面のプルダウンに収まる数が上限です。これを超えると現場が更新しなくなり、テーブルが死にます。

既存システムとどうつなぐか

基幹システムを入れ替える必要はありません。段階を踏みます。

1. 読み取りだけ集約する：基幹システムのCSVエクスポート、工事台帳のExcel、募集システムの掲載状況を、住戸IDをキーに日次で1枚に集約する。この時点では誰の入力作業も増えません。
2. 入力が発生しない項目を自動判定する：掲載URLが生きていれば「募集中」、完工報告書のファイルが所定フォルダに入っていれば「完工確認待ち」など、既存の成果物から状態を推定する。
3. どうしても人が入れる項目だけを残す：ボール保持者と次アクション、期日。ここだけは判断が要るため人が入れます。

この順序を守らないと、「新システムのために現場が二重入力する」状態になり、運用が3か月で止まります。

見積や募集原稿の自動生成は、どの工程に差し込むと効くのか？

効く場所と効かない場所がはっきり分かれます。

効く差し込み位置

(1) 立会当日に概算見積を出す

立会でチェックした損耗項目から、単価表を引いて概算金額まで出す仕組みは、見積作成が後日になっている会社では滞留区間をまるごと消せます。判断基準はシンプルで、「立会当日に金額をオーナーに伝えられていないなら効く」です。

ここで生成AIが担うのは、立会メモや写真の内容を単価表の項目名にマッピングする部分です。金額計算そのものは単価表の照合なので、生成AIに計算させてはいけません。AIは項目の特定まで、金額は単価マスタから引く。この切り分けを外すと、数字が合わない見積が出て信用を失います。

(2) オーナー提案書を承諾判断に必要な形で自動生成する

オーナー承諾が遅れる原因の多くは、オーナーが判断できる材料が揃っていないことです。金額の内訳、負担区分（入居者負担／オーナー負担）の根拠、実施した場合の想定募集条件、実施しない場合の想定募集条件。この4点が1枚に揃っていれば、返事は速くなります。逆に言えば、追加質問が来る提案書を送っている限り、送信を自動化しても往復が1回増えるだけです。

自動生成の対象は、提案書のドラフトです。負担区分の判断は原状回復のガイドラインや契約書の特約に依存するため、最終判断は人が行い、システムは根拠となる契約条項と経過年数を並べて提示するところまでにします（負担区分の法的な解釈は個別案件により異なるため、判断に迷う場合は専門家にご確認ください）。

(3) 募集原稿を「退去通知の直後」に作る

これが最も効きやすく、かつ多くの会社がやっていない差し込み位置です。

募集原稿に必要な情報のうち、工事完了を待たなければ確定しないのは室内写真だけです。所在地、間取り、面積、設備、交通、周辺施設、契約条件、図面は退去通知の時点で確定できます。前入居者の入居時データ、過去の募集履歴、設備更新履歴から原稿の大部分を先に生成し、完工日に写真を差し替えて掲載する。この設計なら、完工から掲載までの工程が「写真の差し替え」だけになります。

判断基準は、「完工後に原稿を書き始めているかどうか」。書き始めているなら効きます。

効かない差し込み位置

• オーナー承諾が最長滞留区間なのに、見積作成を自動化する：見積は当日出ているのに承諾で1週間止まっている会社では、見積生成を速くしても総リードタイムは動きません。
• 職人手配が最長滞留区間なのに、発注書の作成を自動化する：発注書を書く時間より、職人の空きを待つ時間のほうが長い場合、書類側を触っても意味がありません。この場合に効くのは、退去予告の時点で施工枠を仮押さえする運用であり、そのために必要なのは「退去予告一覧を工事担当が毎朝見られる状態」です。書類生成ではなく情報の到達速度の問題です。
• 掲載作業自体が滞留していないのに、ポータル入稿を自動化する：入稿の手間は削れますが、リードタイムは変わりません（担当者の負荷軽減という別の価値はあります）。

つまり、自動化の効果は「その工程が最長滞留区間かどうか」でほぼ決まります。だからこそ、前述の8つの日付の計測が先なのです。

待ちを可視化する状態管理を、現場でどう回すか？

仕組みを作っても、状態が更新されなければ意味がありません。運用を成立させるための設計上のポイントを挙げます。

1. 毎朝1画面で「止まっている住戸」を出す

全住戸の一覧ではなく、「ボール保持者が自社で、期日を過ぎている住戸」と「ボール保持者が社外で、3営業日以上動いていない住戸」の2つのリストだけを出します。件数が多いリストは見られません。

2. 催促を仕組みに載せる

オーナー承諾待ちが一定日数を超えたら担当者に通知、さらに超えたら上長にも通知。ここは自動化しやすく、かつ効果が出やすい部分です。ただしオーナーへの催促文面を完全自動送信にしないこと。関係性によって適切な連絡手段と表現が違うため、ドラフト生成＋担当者の送信判断に留めるのが安全です。

3. 状態更新を「別作業」にしない

工事担当が完工報告をチャットに投げたら、その内容から完工日を拾って状態を更新する。募集システムに掲載したら、掲載状況を日次で読み取って状態を更新する。既存の行動の副産物として状態が変わる設計にしないと、更新は続きません。

4. 数字は月次で区間別に振り返る

「今月の平均空室日数」ではなく、「立会→承諾の平均日数」「承諾→着工の平均日数」を並べます。改善が効いたかどうかは区間単位でしか判定できません。

この仕組みで短縮できないこと

正直に書きます。パイプライン化とAI活用で短縮できない領域があります。

• オーナーの意思決定そのもの：判断材料を揃え、催促のタイミングを最適化することはできますが、オーナーが決断するまでの時間は削れません。相続や共有名義で関係者が複数いる案件は特にそうです。
• 職人・施工業者の空き状況：繁忙期に職人がいなければ、システムで前倒しできるのは「発注のタイミング」だけです。キャパシティ自体は増やせません。
• 施工日数：クロス張替やハウスクリーニングにかかる日数は物理的な制約です。
• 市況で決まる募集期間：掲載後に申込が入るまでの期間は、賃料・立地・競合によって決まります。パイプラインが短縮するのは「退去から掲載まで」であり、「掲載から申込まで」ではありません。
• 原状回復の負担区分の判断：契約書の特約、経過年数、通常損耗か否かの評価は法的な解釈を含みます。システムは根拠の提示までで、判断は人が行うべき領域です。個別案件は専門家にご確認ください。
• 写真の質：室内写真の撮り方は成約率に影響しますが、これは撮影者のスキルと機材の問題で、パイプライン設計では解決しません。

また、入力データが整っていない状態でAIを載せても精度は出ません。前入居者の入居時データや設備更新履歴が基幹システムに正しく入っていなければ、募集原稿の自動生成は使えないドラフトを出し続けます。この場合、先に手を付けるべきはマスタデータの整備です。

まとめ

• 空室期間の大半は作業時間ではなく、オーナー承諾待ち・職人手配待ち・確認待ちという「待ち」の連鎖で構成される。
• 着手前に、退去届受領日から掲載日までの8つの日付を1住戸1行で記録し、区間別の日数分布を見る。平均ではなく最長ケースを見る。
• 既存システムの入れ替えは不要。住戸IDをキーに、日付・ステータス・ボール保持者・次アクション・期日を持つ状態テーブルを1枚追加するのが最小構成。
• 自動化の効果は「その工程が最長滞留区間かどうか」で決まる。募集原稿の先行生成（退去通知直後）は、多くの会社で効きやすい差し込み位置。
• オーナーの意思決定、職人の空き、施工日数、掲載後の成約期間は仕組みでは短縮できない。短縮できる範囲を明確にしてから投資判断をする。

よくある質問

Q. 空室期間を短縮するには、まず何から着手すべきですか？

最初にやるべきは自動化ではなく計測です。1住戸ごとに「退去日・立会日・精算確定日・発注日・完工日・募集条件確定日・掲載日・申込日」の8つの日付を記録し、どの工程間で日数が空いているかを可視化します。多くの場合、作業時間ではなく承諾待ち・手配待ちが最大の滞留区間です。

Q. 原状回復の見積を自動生成すれば空室期間は短くなりますか？

見積作成そのものが滞留原因になっている場合だけ効きます。立会当日に概算を出せず後日作成している会社なら効果がありますが、見積は当日出ているのにオーナー承諾で1週間止まっている会社では、自動生成しても空室期間はほぼ変わりません。着手前に滞留区間の特定が必要です。

Q. 募集原稿や図面の自動生成は、どの工程に差し込むと効果がありますか？

完工後ではなく、退去通知を受けた直後です。募集原稿・図面・写真以外の項目は工事完了を待たずに確定できます。完工日に「写真を差し替えて掲載」だけが残る状態を作れば、完工から掲載までの数日を削れます。完工後に原稿作成を始める運用では自動化しても順番待ちは解消しません。

Q. 既存の基幹システムを入れ替えないと、パイプライン化はできませんか？

入れ替えは必須ではありません。基幹システム・工事管理表・募集システムがバラバラでも、住戸ID・部屋番号をキーに各システムから日付と状態だけを集めた「状態テーブル」を別に持てば、串刺しの可視化は成立します。まず読み取り専用の集約から始めるのが現実的です。

Q. AIで空室期間の短縮をどこまで自動化できますか？

自動化できるのは書類作成・転記・原稿生成・催促の通知といった手を動かす部分です。オーナーの承諾判断、職人の空き状況、募集賃料の最終決定はAIでは短縮できません。これらは人の判断と外部都合に依存するため、AIができるのは「判断待ちが発生していることを早く可視化する」ところまでです。

ご相談について

エクサテックは、不動産・建設業の現場に入り込んで業務システムと生成AIの開発を行っています。株式会社イーリアルティ様の転記エージェントでも、契約前から現場に足を運び、実際の作業を見るところから設計しました。

空室期間のどこで止まっているか分からない、という段階からのご相談も歓迎します。まずは現状の工程を一緒に分解するところからお手伝いします。