家賃滞納の督促自動化は、文面の送信から作ってはいけません。土台は入金照合です。口座振替・振込・集金代行・保証会社立替が混在した入金データの名寄せに失敗すると、支払済みの入居者に督促が飛ぶという回復困難な事故になります。本記事では照合設計と、自動送信して良い段階の分岐条件を示します。
家賃滞納の督促業務はどこまで自動化できますか？
結論として、自動化できるのは次の3つです。
- 入金照合と滞納の検知（誰がいくら未納かを毎日確定させる）
- 一次リマインドの自動送信（事務的な入金確認のお願い）
- 督促履歴の記録と時系列出力（後工程で使う証跡づくり）
一方、自動化できないのは次の3つです。
- 支払えないのか支払わないのかの見極め（失職・入院・世帯事情は会話でしか取れません）
- 分割合意などの交渉
- 保証会社への代位請求や法的手続きに移る判断
督促業務を「送信作業」と捉えると自動化は失敗します。実務の負荷は、送る作業ではなく「送っていいかを確かめる作業」に集中しています。ここを設計対象にしてください。
なぜ督促自動化は「入金照合」から設計するのですか？
督促の誤送信は、他の業務システムの不具合とコストの性質が違います。マイソクの誤記は差し替えられますが、支払済みの入居者に送った督促は取り消せません。信頼関係が壊れ、クレーム対応の工数は自動化で削減した工数を上回ります。
そのため設計上の第一原則はこうです。
督促候補は「照合済み」と確定した入金データからのみ生成する。未照合の入金が1件でも残っている日は、督促バッチを起動させない。
このブロッキング条件を実装するかどうかで、システムの安全性がほぼ決まります。滞納の検知ロジックを賢くする前に、止める条件を先に作ってください。
入金データの名寄せはどこで失敗しますか？
失敗は経路ごとに違う顔で現れます。実務で潰す必要があるのは主に次のパターンです。
| 入金経路 | 失敗しやすい点 | 設計上の対応 |
|---|---|---|
| 口座振替 | 結果ファイルの到着が振替日当日ではない。結果コードの体系が代行会社ごとに異なる。再振替の有無 | 結果コードのマスタ化。再振替がある契約は1回目の不能で督促候補に載せない |
| 銀行振込 | 依頼人名がカナ、部屋番号なし、配偶者名義、勤務先名義、旧姓 | 契約ごとに名義エイリアスを持つ。人が紐づけた組み合わせを次回以降は自動適用 |
| 集金代行 | 口座には合算で1本入金され、明細ファイルと突合が別レイヤーになる | 「入金の突合」と「明細の充当」を2段階の処理として分ける |
| 保証会社立替 | 立替により入居者の残高は消えるが、督促主体が保証会社に移る | 立替検知で自社督促を停止するフラグを必須化。ここを止めないと二重督促になる |
| 法人一括払い | 1本の振込に複数物件・複数戸分が含まれる | 社宅一覧との照合。分解できない振込は自動照合させず人のキューへ |
さらに金額不一致の扱いが残ります。一部入金、複数月の一括入金、共益費・駐車場・水道料金・町内会費の分離、更新料や退去精算の混入、遅延損害金、振込手数料の差引です。
ここで必要なのは充当順序ルールの明文化です。古い債権から充当するのか、費用→損害金→賃料の順か、駐車場は別債権として扱うのか。この順序が決まっていないと、残高が合わず、滞納月数の表示が担当者ごとにずれます。ルールが決まっていない管理会社は珍しくないため、自動化プロジェクトの前半はこの整理に時間を使います。契約書の条項と実務慣行の両方を踏まえる論点になるため、判断に迷う場合は弁護士等にご確認ください。
自動送信して良い段階と人が判断すべき段階の分岐条件は？
段階を先に定義し、段階ごとに「送信主体」を固定します。日数の閾値は管理会社ごとに違うため、システム側では日数を直接埋め込まず、自社ルールとして設定値で持たせます。
| 段階 | トリガー | 自動化の範囲 | チャネル |
|---|---|---|---|
| 0. 検知 | 引落不能・入金なしを照合で確定 | 完全自動。送信はしない。再振替待ちの契約はここで待機 | — |
| 1. 一次リマインド | 社内で定めた猶予経過 | 自動送信可。事務的な入金確認 | SMS／LINE／メール |
| 2. 二次督促 | 段階1で入金なし | 文面生成と対象抽出は自動、送信は担当者承認 | 電話併用＋書面 |
| 3. 関係者連絡・保証会社報告 | 段階2で入金なし | 人が実施。システムは期限アラートと履歴出力 | 書面・保証会社所定様式 |
| 4. 法的手続きの検討 | 段階3で解決せず | 人＋専門家。システムは証跡の時系列出力のみ | 内容証明等 |
段階1で自動送信して良いのは、次のガードを全て通過した契約に限ります。
- 保証会社の立替が登録されていない
- 分割払いの合意が登録されていない
- 退去精算中・係争中・生活保護の代理納付でない
- 前回入金の経路が変わっていない（振替から振込への変更直後は照合が乱れます）
- 連絡先の不達フラグが立っていない
いずれかに該当する契約は自動送信から外し、担当者のキューに積みます。除外条件の設計が督促自動化の本体です。送信ロジックより時間をかけてください。
送信タイミングも設計対象です。夜間バッチで検知しても、送信は営業時間内にキューイングします。深夜や早朝の督促送信は、内容にかかわらずトラブルの起点になります。
督促文面の温度差はどう設計しますか？
段階ごとに足していく情報を決めるのが実務的です。文体を強めるのではなく、記載する事実を増やします。
- 段階1：対象月・金額・入金方法・行き違いの可能性への言及。「入金の確認が取れておりません」
- 段階2：期限の明示・遅延損害金の取り扱い・連絡先。期限までに連絡が取れない場合の次の手続きの予告
- 段階3以降：契約条項の引用・書面での通知。到達証跡が残る手段に切り替える
テンプレートは固定部と差込部に分け、差込部（宛名、物件・部屋番号、対象月、内訳、金額、期限、問い合わせ先）だけを可変にします。督促本文をLLMに自由生成させることは推奨しません。金額や対象月の誤りは回収の話をする前に信頼を壊しますし、表現の逸脱を検知できません。
そのうえで、テンプレート審査の観点として禁止表現を明文化します。威圧的な表現、退去を示唆する断定、勤務先や家族への連絡を示唆する記述などです。これらは法的評価に関わり得るため、テンプレート確定時に弁護士等の確認を経る運用にしてください。
外国籍の入居者が多い物件では、段階1のみ多言語テンプレートを用意し、段階2以降は日本語＋やさしい日本語の併記に切り替える、といった分岐も設計に入れます。
保証会社への代位請求や法的手続きはシステムでどう扱いますか？
現実的な実装範囲は次の3つに限られます。
- 報告期限のアラート：保証会社ごとに、滞納発生からの報告期限が異なります。期限を過ぎると保証の対象外になる契約もあるため、契約単位で期限を管理し、担当者に通知します。
- 必要書類チェックリストの生成：契約書、督促履歴、入出金明細、送付書面の控えなど、保証会社ごとに必要な添付が違います。様式に合わせたCSV／PDF出力までを担当させます。
- 督促履歴の時系列出力：いつ・どのチャネルで・どの文面を送り、到達したか（SMS到達、開封、郵便追跡）。この一覧が法的段階で最も価値を持ちます。
APIで連携できる保証会社は多くありません。Web画面入力やメール添付が実態です。したがって「請求を自動で出す」設計は避け、人が提出する直前までを揃える設計にします。請求のタイミング判断そのものは、入居者との関係や物件事情を踏まえた経営判断であり、システムに委ねるべきではありません。
なお、督促の内容や実施主体によっては法的な位置づけが変わり得ると解釈されます。管理会社が自ら行える範囲についても、個別案件は弁護士等の専門家にご確認ください。
この設計でできないこと・限界はどこですか？
- 到達の保証はできません。 電話番号の変更、LINEのブロック、メールの不達は日常的に起きます。システムの仕事は「届いた」ことにするのではなく、不達を検知して人のキューに戻すことです。不達フラグの設計を省くと、送ったつもりで放置される契約が生まれます。
- 支払えない事情は取得できません。 失職、入院、家族の状況は会話でしか把握できません。自動化の目的は電話をなくすことではなく、電話をかけるべき相手を絞ることです。
- 例外処理は自動化に向きません。 生活保護の代理納付、成年後見、借主死亡による相続、賃料減額請求中の契約は、それぞれ処理が異なります。自動フローから除外し、専用のリストで管理します。
- 充当ルールはシステムだけでは決められません。 契約条項と実務の運用に依存します。ここを決めずに開発を始めると、後半で残高がずれ、作り直しになります。
- AIによる判断の代替はできません。 LLMが有効なのは、入金摘要から契約候補を提示する、電話メモを要約して履歴に残す、督促履歴を時系列に整理する、といった補助工程です。督促の可否判断や文面の自由生成には使いません。
導入はどの順で進めるべきですか？
エクサテックが業務自動化に入るときの進め方は、いずれの案件でも共通しています。要件を紙で受け取るところから始めず、現場の作業を見るところから始めます。株式会社イーリアルティ様の転記エージェント（リーシングサービスと基幹システム間のデータ転記を自動化）でも、契約の前段階から何度も現場に足を運び、困りごとを理解することから着手しました。督促業務も同じ構造で、入金照合という「見えている以上に複雑な転記作業」が中心にあります。
推奨する工程は次の順です。
- 入金経路の棚卸し：全経路、全ファイル形式、到着タイミング、結果コード体系を台帳化する
- 過去データでの検証：直近数か月の実データで照合ロジックを流し、督促対象になったはずの契約を担当者の記憶と突合する
- 停止フラグと除外条件の定義：立替、分割合意、退去精算中、係争中などを洗い出す
- 段階1のみ自動化して並走運用：送信対象一覧を担当者が事前確認する期間を置く
- 段階2を承認付きで自動化：文面生成と履歴記録まで移す
いきなり全段階を自動化しないことが、「導入したのに使われない」を避ける最短ルートです。
まとめ
- 家賃滞納の督促自動化は、送信機能ではなく入金照合から設計する
- 未照合の入金が残っている日は督促バッチを起動させないというブロッキング条件を必ず入れる
- 口座振替・振込・集金代行・保証会社立替は失敗パターンが異なる。経路ごとに対応を分ける
- 自動送信は一次リマインドまで。二次督促は生成を自動化し、送信は承認を通す
- 代位請求・法的手続きは「期限アラート」「書類チェックリスト」「履歴の時系列出力」までがシステムの役割
督促業務の設計についてのご相談
入金照合のルールが整理できていない段階でも構いません。現在の入金経路とファイルの実物を見せていただければ、どこまで自動化できてどこを人が持つべきか、切り分けの案をお出しします。1業務に絞った小さなプロジェクトなら数十万円から着手でき、対象範囲が広がると数百万円前半のレンジが目安です。まずは現状の運用をお聞かせください。
