賃貸管理の入居者対応で、AIに任せられるのはどこまでですか
結論として、AIに任せられるのは「一次受け・切り分け・情報整理」までです。入居者対応のAI一次受けとは、入居者からの連絡を受け付け、緊急度と案件種別を判定し、非緊急かつ回答が一意に決まる問い合わせだけを自動回答し、それ以外を適切な担当者に整理済みの情報として渡す仕組みである。
この設計で重要なのは、自動回答率を上げることが目的ではない点です。賃貸管理の入居者対応は、水漏れ・ガス漏れ・鍵の紛失といった「対応が遅れると被害が拡大する案件」と、「ゴミ出し日を知りたい」という案件が同じ窓口に同じ形で飛んでくる構造になっています。AIの価値は、この2つを最初の数秒で分離することにあります。
任せられる範囲と、任せてはいけない範囲を分けると次のようになります。
| 範囲 | 内容 | AIの担当 |
|---|---|---|
| 受付 | 24時間の一次接触、氏名・物件・部屋番号の特定 | 全面的に可 |
| 切り分け | 緊急度判定、案件種別の分類 | 可(ただし非緊急側に確信が必要) |
| 定型回答 | 物件情報・契約情報から一意に決まる回答 | 可 |
| 情報整理 | 症状のヒアリング、写真収集、担当者への引き渡し | 可 |
| 原因判断 | 設備不具合の原因特定、修理範囲の確定 | 不可 |
| 費用負担判断 | 貸主負担か借主負担かの判定 | 不可 |
| 業者手配の確定 | どの業者をいつ手配するかの決定 | 条件付き(事前ルール化した範囲のみ) |
緊急案件の判定ロジックはどう組みますか
緊急度判定は「AIが緊急と判断したら人に回す」ではなく、「AIが非緊急と確信できない限り人に回す」という逆向きの設計にします。
前者の設計は、AIが緊急性を見落とした時点で対応が止まります。後者なら、AIが判断に迷った案件は自動的に人間側へ流れます。取りこぼしのコストが圧倒的に非対称な領域では、後者以外の設計は取れません。
具体的には、判定を3層で構成します。
第1層:キーワードによる機械的検出
AIの推論を通す前に、文字列マッチで即エスカレーションする語を定義します。ここをLLMに任せないのは、推論には必ず揺らぎがあり、緊急語の検出だけは揺らいではいけないからです。
- 水関連:水漏れ、漏水、水が止まらない、天井から、床が濡れ、階下
- ガス・火:ガス臭い、焦げ臭い、煙、火
- 施錠:鍵をなくした、鍵が回らない、締め出され、開かない
- 人身・防犯:怪我、倒れ、不審者、侵入
- 停止系:電気がつかない、お湯が出ない、エアコンが動かない(季節条件で緊急度が変わる)
第2層:LLMによる文脈判定
キーワードに引っかからなかった案件を、LLMで分類します。ここで判定させるのは緊急度だけではなく、次の項目をセットで構造化させます。
- 案件種別(設備/契約手続き/近隣トラブル/その他)
- 緊急度(即時/当日/翌営業日/期限なし)
- 被害の拡大可能性(他の住戸に及ぶか)
- 入居者の在宅状況・連絡可能時間
- 不足している情報(部屋番号、症状の詳細、写真の有無)
出力は自由文ではなくJSONで受け取り、緊急度フィールドが「即時」または「判定不能」ならエスカレーションに回します。
第3層:不足情報のヒアリング
非緊急と判定された設備案件でも、そのまま人に渡すと担当者が電話をかけ直すことになります。AI側で「いつから」「どの場所で」「音や臭いはあるか」「写真を送れるか」を確認し、写真を受け取ってから引き渡します。ここが一次受けの実質的な省力化ポイントです。
水漏れと鍵の案件は、他と何が違うのですか
この2つは、賃貸管理のAI一次受けにおける設計上の特異点です。
水漏れは「時間経過で被害額が増える」唯一の類型に近い
給湯器の故障は入居者1名の不便で止まりますが、水漏れは階下住戸・共用部・躯体に波及します。したがって水漏れ案件のフローは他と分けて設計します。
- キーワード検出の時点で、回答文より先に「元栓・止水栓を閉めてください」という応急指示を返す
- 階下への影響の有無を最初に聞く(「下の階の方から連絡がありましたか」)
- 部屋番号と建物名から、階下住戸の有無を物件マスタで引く
- 人への通知と同時に、事前登録した緊急水道業者の連絡先を担当者に提示する
- 入居者には「業者手配の連絡が○分以内に入ります」という次のアクションを明示する
応急指示を回答より先に出すのは、担当者が電話に出るまでの数分間が被害の大小を分けるからです。ここをAIに任せる価値は、自動回答の効率ではなく初動の速さにあります。
鍵は「入居者が屋外にいて、時間が読めない」
鍵の紛失・室内閉じ込めは、被害額は増えませんが入居者が家に入れない状態が続きます。深夜であれば苦情に直結します。設計上のポイントは次の2つです。
- 本人確認をAIの段階でどこまでやるか。契約者情報との照合をどの項目で行うか(氏名・生年月日・電話番号の下4桁など)を事前に決めておく。ここを曖昧にすると防犯上の問題になります
- オートロック解錠と鍵交換は費用負担が絡むため、AIには「概算をお伝えできません」と明示させ、費用の確定回答は人が出す
エスカレーション経路はどう設計しますか
エスカレーション先を「担当者」という人単位で設計すると、必ず穴が空きます。 経路は役割単位で定義し、時間帯と応答有無で段階を上げる構造にします。
| 緊急度 | 通知先 | 通知手段 | 未応答時 |
|---|---|---|---|
| 即時(水・ガス・鍵) | 当番担当 → 管理課長 | 電話発信+チャット | 5分未応答で次段へ自動送出 |
| 当日 | 物件担当 | チャット通知 | 営業時間内2時間で課内共有 |
| 翌営業日 | 物件担当 | 案件一覧に積む | 期限超過でリマインド |
| 期限なし | 案件一覧に積む | なし | — |
設計時に必ず決めておく項目を挙げます。
- 当番表をどこに持つか:スプレッドシートで運用すると更新漏れが起き、深夜に誰にも通知が飛ばない事故が起きます。システム側に当番マスタを持たせ、シフト変更をUIから更新できるようにします
- 未応答の判定基準:「既読」ではなく「担当者が対応開始ボタンを押した」で判定します。既読判定は通知画面に表示されただけで立ってしまいます
- 入居者への中間連絡:人が対応を開始した時点で、入居者側に「担当者が確認しています」を自動送信します。これがないと入居者は同じ内容を電話でかけ直し、窓口が二重化します
- 記録の残り方:AIの判定理由、通知履歴、応答時刻を1つの案件レコードにまとめます。後から「なぜ緊急と判定しなかったのか」を検証できない仕組みは、運用が続きません
エクサテックが株式会社イーリアルティ様に構築した転記エージェントでは、契約の前段階から何度も現場に足を運び、実際の困りごとを理解するところから着手しました。入居者対応の自動化も同じ順序です。緊急案件がどんな言葉で飛んでくるか、誰が今どうやって受けているか、休日は誰に電話が回るかを、実際の受付記録と当番表を見せてもらってから判定ロジックを書きます。ヒアリングだけで書いた判定基準は、現場の言い回しと合いません。
自動回答してよい問い合わせの線引きはどこですか
自動回答の可否は「回答が物件情報・契約情報から一意に決まるか」で切ります。判断に条件分岐が入るものは、条件をシステムに持たせられているかで判定します。
自動回答してよい類型
- ゴミ出しの曜日・分別ルール(物件マスタに登録済みであること)
- 駐車場・駐輪場の位置、宅配ボックスの操作方法
- 家賃の振込先、引き落とし日
- 更新手続きの流れと必要書類
- 退去予告の期限(契約書の予告期間をデータとして持っていること)
- 設備の型番から辿れる取扱説明書の該当箇所
自動回答してはいけない類型
- 修繕費用の負担区分(貸主/借主)。原状回復の判断も含みます
- 契約内容の解釈に関わる回答
- 近隣トラブルの事実関係に踏み込む回答
- 更新料・違約金などの金額の確定回答
- 「この程度なら問題ない」という設備状態の判断
この線引きで肝になるのは、自動回答してはいけない類型でも「受付」はAIがやることです。「費用のご負担についてはお答えできませんので、担当者から回答いたします」と返しつつ、必要情報のヒアリングと写真収集は済ませておきます。入居者にとっては待ち時間が生じるだけですが、担当者側は最初の連絡で回答を出せる状態になります。
なお、宅地建物取引業法や借地借家法に関わる回答をAIに生成させる設計は避けるべきと考えます。個別案件の法的な線引きは弁護士等の専門家にご確認ください。
AIの一次受けでできないこと・限界
導入前に合意しておくべき限界を明示します。
1. 現場を見ない判断はできない
「壁にシミがある」という連絡から、雨漏りか結露か上階の漏水かを切り分けることはできません。AIができるのは、シミの位置・広がり方・発生時期・上階の状況を聞き、写真を集めて担当者に渡すところまでです。原因判定を自動化しようとした設計は、必ず誤判定で信頼を失います。
2. 音声チャネルは判定精度が落ちる
電話の音声認識は、入居者が焦って早口になる緊急時ほど誤認識します。「水が漏れて」が正しく取れない可能性がある以上、緊急案件の判定を音声認識の出力だけに依存させることはできません。実装順序としては、チャット・LINE等のテキストチャネルで判定ロジックを安定させ、その後で音声を追加するのが現実的です。電話は当面「AIが受けて要件を聞き、緊急語を検出したら即転送する」に留めるのが安全です。
3. 感情的な入居者への対応は代替できない
近隣騒音や長期化した不具合の連絡では、入居者が既に不満を抱えている状態で連絡が来ます。この状態でAIが定型文を返すと、不満が増幅します。連絡文の語気や過去の問い合わせ回数から「人に回す」フラグを立てる設計は可能ですが、対応そのものは人が行うほかありません。
4. 通知が届かない環境は解決できない
現場に出ている担当者の電波状況、通知をオフにしているスマートフォン、夜間の就寝。これらはシステム側では解決できません。だからこそ「未応答なら次の人へ」という多段の経路が必要になります。技術で埋められない部分を運用ルールで埋める前提を、導入時に共有します
5. 導入直後は自動回答率が上がらない
物件マスタにゴミ出し日が入っていなければ、ゴミ出しの質問には答えられません。自動回答の範囲は「持っているデータの範囲」で決まります。したがって初期は、緊急判定とヒアリング・振り分けの価値が先に出て、自動回答率は物件データの整備に応じて後から伸びる形になります。この順序を最初に説明しておかないと、「思ったより自動化されていない」という評価になります。
まとめ
- 入居者対応のAI一次受けは、自動回答率ではなく「緊急案件を数秒で分離すること」に価値がある
- 緊急度判定は「非緊急と確信できないものは全て人へ」の向きで設計する。キーワードによる機械的検出とLLMの文脈判定を併用し、緊急語の検出は推論に依存させない
- 水漏れは応急指示(止水栓を閉める)を回答より先に返し、階下影響の確認を最初に行う。鍵は本人確認項目を事前に定義し、費用の確定回答はAIに出させない
- エスカレーションは人単位ではなく役割単位で定義し、当番マスタをシステム側に持たせる。未応答判定は「既読」ではなく「対応開始操作」で行う
- 自動回答の範囲は保有データの範囲で決まる。原因判断・費用負担判断・契約解釈はAIに任せない
ご相談について
入居者対応の一次受けは、現在どんな言葉で連絡が来ているか、休日は誰が受けているかを見ないと判定ロジックが書けません。エクサテックでは受付記録や当番表を実際に拝見しながら、どこまでを自動化して、どこから人に渡すかの線引きから一緒に設計しています。現状の窓口体制を整理する段階からでも、お気軽にお声がけください。

