「更新通知、今月出す分はもう発送しましたっけ」――管理戸数が増えるほど、契約更新の案内はコンスタントに発生する定常業務になります。それなのに多くの管理会社では、満了日をExcelで管理し、担当者が個人の感覚で「そろそろかな」と気づいて動く、という属人的な運用のままになっています。この記事では、契約更新の通知・回収・報告という一連の業務を、なぜ仕組み化する必要があるのか、そしてどう設計すれば属人化から抜け出せるのかを整理します。
先に、要点をまとめます。
- 建物賃貸借の更新拒絶通知は借地借家法26条により「満了の1年前から6ヶ月前まで」に行う必要があり、これを逃すと契約は「法定更新」される
- 法定更新後は、契約書に別段の定めがない限り更新料を請求できなくなる可能性がある
- 更新案内の発送・返信管理・入金確認・オーナー報告という一連の流れが、案件数の増加とともに属人化しやすい
- 期日管理を仕組みに載せることで、通知漏れそのものを構造的に起こしにくくできる
契約更新業務そのものの法的な位置づけと実務の流れを整理したうえで、後半では、この業務を仕組みとしてどう設計するかを具体的に書き下ろします。個別の契約における更新拒絶の可否や法定更新の成否といった法律判断は弁護士等の専門家の領域であり、本記事はあくまで「社内の期日管理・通知業務をどう仕組み化するか」という業務設計の観点に絞って解説します。なお、消防点検や貯水槽清掃など契約更新以外の法定点検も含めた期日管理の全体設計については賃貸管理会社の契約更新・法定点検の期日漏れを防ぐで扱っており、本記事はその中でも「契約更新の通知期限と更新料」に絞って、借地借家法の規定まで掘り下げています。
契約更新の通知は、いつまでに何をする必要があるのか
建物賃貸借契約の更新拒絶通知は、借地借家法26条1項により契約期間満了の1年前から6ヶ月前までの間に行う必要があります。この期間を過ぎて通知をしなかった場合、契約は従前と同一の条件で法定更新されたとみなされます。
借地借家法26条1項は、期間の定めがある建物賃貸借について、当事者が期間満了の1年前から6ヶ月前までの間に、相手方に対して更新をしない旨または条件を変更しなければ更新をしない旨の通知をしなかったときは、従前の契約と同一の条件で契約を更新したものとみなす、と定めています（出典: e-Gov法令検索「借地借家法」第26条、https://elaws.e-gov.go.jp/document?lawid=329AC0000000090 ）。管理会社にとっての実務上の意味は、「この期間内に、更新するのかしないのか、条件変更があるのかを入居者に伝える」ことが、契約を従前どおり継続させないための前提条件になっている、という点です。
もっとも、多くの賃貸借契約は更新を前提としており、管理会社が実際に行っているのは「更新拒絶」ではなく「更新の案内」です。契約期間満了の2〜3ヶ月前を目安に、更新案内書類（更新後の契約条件、更新料・事務手数料の金額、返信用の合意書等）を入居者へ送付するのが一般的な実務です（出典: いえらぶCLOUD「法定更新とは？更新料はどうなるのか、対処法とともに解説」、https://ielove-cloud.jp/blog/entry-03385/ ）。つまり実務上のスケジュールは、法律が定める「1年前〜6ヶ月前」という外枠の中に、案内発送・返信確認・入金確認という具体的な作業が詰め込まれている形になります。
通知を忘れると何が起きるのか
通知が期限内に行われず契約が法定更新された場合、契約書に更新料に関する明確な定めがない限り、更新料を請求できなくなる可能性があります。更新料は管理会社・オーナーにとって無視できない収入であり、通知漏れは直接的な機会損失につながります。
法定更新は「契約が従前と同一の条件で継続する」制度であり、更新料の支払いは法律上の義務ではありません。実務解説でも、法定更新となった場合には原則として更新料を請求できないとされており、対策として契約書に「法定更新された場合でも、一定期間ごとに更新料を支払うものとする」という条項をあらかじめ明記しておく方法が紹介されています（出典: いえらぶCLOUD「法定更新とは？更新料はどうなるのか、対処法とともに解説」、https://ielove-cloud.jp/blog/entry-03385/ ）。つまり、契約書の条項設計と、通知業務の期日管理の両方が揃って初めて、更新料の取りこぼしを防げるということです。
この記事で扱うのは後者、つまり「期日を逃さず通知する仕組み」の部分です。契約書の条項設計は個別の契約内容によって対応が分かれるため、顧問弁護士や契約書のひな形を確認しながら進める領域になりますが、どれだけ良い契約書を用意していても、通知を出し忘れれば意味がありません。
なぜ更新通知の期日管理は属人化しやすいのか
更新通知の期日管理が属人化する最大の理由は、管理戸数が増えるほど「満了日がバラバラな契約」が同時並行で発生し、Excelや紙の台帳での追跡が破綻しやすくなるためです。
管理戸数が少ないうちは、担当者が頭の中で「そろそろあの部屋の契約が切れる」と把握できます。しかし戸数が増えると、契約の満了日は物件ごと・入居者ごとにバラバラに分散し、ある月には5件、別の月には0件というように偏りも生じます。Excelで満了日一覧を管理していても、「今月チェックすべき案件」を毎回手動で絞り込む必要があり、確認を忘れた月に限って通知漏れが起きる、という事故が起きやすくなります。
さらに、更新業務は「通知の発送」だけでは終わりません。発送後の返信確認、更新料の入金確認、オーナーへの結果報告という後続の作業が続きます。この一連の流れのどこか一箇所でも担当者の記憶に依存していると、案件数が増えたときに必ずどこかで抜け漏れが発生します。典型的なのは、更新案内は発送したものの、返信がない案件のフォローを忘れてしまい、気づいたときには通知期限を過ぎていた、というケースです。
もう一つの落とし穴は、担当者の異動・退職です。「あの物件は口頭で更新の話がついているはず」というような、記録に残らない引き継ぎに頼っていると、後任者が把握できないまま期限を迎えてしまうリスクが残ります。
契約更新業務のフロー図。満了12ヶ月前の期日検知から、6ヶ月前までの案内発送、返信状況の追跡、更新料入金とオーナー報告までの流れと、期限を過ぎると法定更新になり更新料を請求できなくなるリスクを示している。
Excelでの期日管理、どこまでなら持ちこたえるか
Excelでの満了日管理は、案件数が少ないうちは機能しますが、「今月確認すべき案件の自動抽出」と「返信待ち案件の可視化」という2つの機能がないため、案件数が増えると見落としのリスクが加速度的に高まります。
Excelでの管理そのものが問題なのではなく、「満了日の一覧を眺めて、目視で今月分を探す」という運用の限界が問題です。件数が少なければ目視でも対応できますが、複数の担当者が同じシートを見て「誰かが確認しているだろう」という状態になると、結果的に誰も確認していなかった、という事故が起きます。
目安になるのは、「今月チェックすべき案件を、シートを開かなくても即答できるか」です。即答できないのであれば、それは属人的な目視確認に依存している証拠であり、案件数がこれ以上増える前に、期日管理そのものを仕組みに載せ替えるタイミングだと考えられます。
私たちなら契約更新の期日管理基盤をこう設計する
ここからは、実際によりどころべーすで賃貸管理会社の契約更新業務を受託するとしたら、という前提で、具体的な設計の考え方を書き下ろします。
データ設計: 中心に据えるのは「契約」という単位です。物件マスタ・入居者マスタに、契約開始日・契約満了日・更新料の金額・条件変更の有無をひもづけた契約レコードを持たせます。ここに「更新拒絶通知の期限（満了日の6ヶ月前）」「案内発送予定日（満了日の2〜3ヶ月前を目安に設定）」を自動計算するフィールドを追加し、契約が登録された時点でこれらの期日が自動的に確定するようにします。更新案内の発送履歴、返信の有無、更新料の入金確認、オーナーへの報告履歴は、この契約レコードに紐づく時系列のログとして記録します。
情報の流れ: 満了日から逆算した期日が近づくと、担当の管理担当者にダッシュボード上と通知の両方でアラートが届きます。担当者は更新案内の発送作業を行った時点でステータスを更新し、入居者からの返信があった時点で「返信あり・合意更新」または「未返信」に区分します。未返信のまま一定期間が経過した案件は「要フォロー」として上位に表示され、管理責任者が電話や再送の対応を指示できるようにします。更新料の入金が確認できた時点で、案件は「完了」に移行し、オーナーへの報告資料はこの一連のステータス変化から自動的にドラフトが組み立てられます。
AIの回答設計: 社内向けのナレッジbotに「今月、更新通知の期限が近い契約はどれ？」と尋ねると、契約マスタの満了日と自動計算された通知期限を参照し、「B棟203号室が今月末で通知期限（満了日の6ヶ月前）を迎えます。現在のステータスは未発送です」のように、対象契約と現在のステータスを具体的に示して回答します。「先月の更新案内で返信がまだない契約は？」と尋ねれば、発送履歴と返信ステータスを突合し、該当する契約を一覧で提示します。回答は必ず契約レコードとログのデータに基づかせ、AIが期日を推測で作らないように設計するのが前提です。
*デモ画面のイメージ:*
よりどころべーすの不動産管理向けダッシュボードのデモ画面（サンプルデータ）。管理物件数・入居率・今月の修繕依頼件数のKPIカード、担当者別の直近タスク一覧、AIインサイトの提案文が1画面にまとまっている。契約更新の期日管理は、この基盤の上に契約ステータスの列を追加する形で構築するイメージです。
権限・運用ルール: 契約情報の登録・満了日の変更は管理責任者のみに権限を絞り、日々の発送・返信ステータスの更新は現場の管理担当者が行える設計にします。通知期限を過ぎた未対応案件が発生した場合は、管理責任者へ自動でエスカレーション通知が届くようにし、「気づいたときには手遅れ」という状態を構造的に防ぎます。
既存環境との連携・移行: 既にExcelで満了日一覧を管理している場合、その一覧を契約マスタへそのまま取り込み、以降の新規契約と更新済み契約から順次システム側の期日管理に切り替えていく段階移行を想定します。契約書のひな形や更新料の条項自体は変更せず、あくまで「いつ・誰が・どう対応したか」を追跡する期日管理の部分だけを仕組みに載せる形なので、既存の契約実務のフローを大きく変える必要はありません。
こうした「契約単位で満了日から通知期限・発送・返信・入金までを一気通貫で追跡し、期限超過を構造的に防ぐ」という設計は、既製の賃貸管理SaaSでも契約情報の登録機能自体は用意されていますが、通知期限の自動計算からフォロー漏れの検知、オーナー報告の自動ドラフト生成までを一体で作り込んでいる例は多くありません。パッケージ×スクラッチという構成であれば、既存の物件・入居者管理の機能はそのまま活かしつつ、更新期日の追跡という自社の運用に合わせた部分だけを個別に追加開発できます。要件定義もエンジニアが直接ヒアリングするため、「更新料の条件変更をどのタイミングでオーナーに確認するか」「どの段階からフォロー対象とみなすか」といった細部まで仕様に落とし込めます。
もちろん、ここに書いた設計はあくまで一般化した叩き台です。実際には契約書のひな形やオーナーとの取り決め、社内の承認フローによって最適な設計は変わります。まずは現状の更新通知業務がどこで属人化しているかを整理するところから、一緒に要件を詰めていくのがよいステップです。
まとめ｜契約更新の期日管理を仕組みにする
この記事を読んで持ち帰れることは、次の3点です。
- 建物賃貸借の更新拒絶通知は借地借家法26条により満了1年前〜6ヶ月前が期限であり、これを逃すと法定更新となって更新料を請求できなくなる可能性があること
- 更新業務は通知発送だけでなく、返信確認・入金確認・オーナー報告まで一連の流れがあり、案件数が増えるほど属人化しやすいこと
- 期日管理を仕組みに載せることで、通知漏れという「起きてから気づく」事故を構造的に防げること
まずは今月・来月に満了を迎える契約が何件あり、それぞれ通知の発送状況がどうなっているかを、社内ですぐに答えられるか確認してみてください。即答できないなら、それは期日管理の仕組み化を検討するタイミングのサインです。
業務の仕組み化については、管理戸数を増やしても人を増やさずに済む状態をどう作るかという視点で管理戸数を増やす鍵は仕組み化｜不動産管理会社が戸数拡大を進める方法でも整理しています。自社の契約更新業務や社内の期日管理フローを踏まえた具体的な仕組みづくりについては、不動産管理会社向けの業務システムのページもあわせてご覧のうえ、お気軽にご相談ください。
よくある質問
Q. 更新拒絶の通知をすれば、必ず契約を終了させられますか？
A. いいえ。借地借家法上、正当な事由がなければ賃貸人からの更新拒絶は認められにくく、実務上も多くの契約は更新を前提に案内が行われます。更新拒絶の可否は個別の事情によって判断が分かれるため、弁護士等の専門家に相談することをおすすめします。
Q. 法定更新になった場合、更新料以外に何か不利益はありますか？
A. 記事内で述べた更新料の請求可否に加え、法定更新後は原則として「期間の定めのない賃貸借」に切り替わる点も実務上のポイントです。契約期間を改めて定め直したい場合は、別途合意更新の手続きが必要になります。
Q. 更新案内はどのくらい前に送るのが一般的ですか？
A. 借地借家法が定める通知期限（満了1年前〜6ヶ月前）とは別に、実務では契約満了の2〜3ヶ月前を目安に更新案内書類を送付するケースが一般的です。ただし返信待ちや再送の時間も見込んで、余裕を持ったスケジュールで動く管理会社が多いのが実情です。
Q. 導入にはどのくらいの期間がかかりますか？
A. よりどころべーすは最短1.5ヶ月での公開が目安です。既存の物件・入居者・オーナー管理機能をベースに、契約更新の期日管理機能を追加する範囲であれば、大きな独自機能の追加がない限り比較的短期間で運用開始できます。