本ケーススタディは、AI導入をご検討中の企業様から実際にいただくご相談をもとに、内容を再構成した仮想ケースを取り上げ、「その相談に私たちならどう答えるか」を解説するシリーズです。
なお、本記事は法的助言を提供するものではありません。個別の法的判断については専門家にご相談ください。
今回の想定ケース
「管理戸数は増えているのに、コールセンターや管理担当の人員は増やせない。電話が鳴りやまず、本来やるべきオーナー折衝や空室対策に時間が割けない」
賃貸管理会社・PM会社の方から、こうしたご相談をいただくことがあります。
問い合わせ対応は、賃貸管理業務の中でも特に「量が多く、割り込みで入り、属人化しやすい」業務です。内容を分解すると、おおよそ次のような構成になっています。
● 設備トラブル系：給湯器が動かない、水漏れ、エアコンの不調、鍵の紛失
● 契約・手続き系：更新料の確認、退去手続き、名義変更、駐車場の解約
● 金銭系：家賃の引き落とし日、振込先の確認、敷金精算の内訳
● オーナー系：送金明細の確認、修繕見積の進捗、入居状況の問い合わせ
このうち一定数は「定型的な確認」であり、担当者でなくても答えられる内容です。一方で、漏水やガス臭のように一刻を争うものも混ざっており、単純に「全部自動化しましょう」とは言えないのがこの業務の難しさです。
そしてもう一つ、この業界特有の前提があります。問い合わせチャネルの主役が、今も電話であることです。入居者アプリやWebフォームを導入している管理会社も増えていますが、特に設備トラブルや高齢の入居者からの連絡は電話に集中します。つまり、問い合わせ対応の自動化を考えるとき、テキストのチャットボットだけを考えていては現場の実態に届かず、「音声」をどう扱うかが避けて通れない論点になります。
また、一口に問い合わせ対応といっても、入居者とオーナーでは性質が異なります。
入居者からは、設備トラブルや契約・手続きなど件数の多い問い合わせが中心となり、なかには緊急対応を要するものも含まれます。一方、オーナーからは、修繕判断や送金明細、入居状況など、物件ごとの個別条件や機密性の高い情報に関する問い合わせが多くなります。
したがって、「問い合わせ全体の何％をAIで自動化するか」と一括りに考えるのではなく、誰から、どのような問い合わせがあり、回答を誤った場合の影響がどの程度あるのかを分解したうえで、自動化の範囲を設計する必要があります。
アプローチの全体像
私たちがこの種のご相談を受けたときに描く構成は、大きく4つのステップです。
1. 問い合わせ者・対象契約の特定
まず、「誰から」「どの物件・契約について」の問い合わせなのかを特定します。電話番号や物件名・部屋番号、契約情報などと照合し、送金明細や契約条件など機密性の高い情報を回答する場合には、必要に応じて追加の本人確認を行います。
2. 入口（受付・認識）
電話であれば音声認識によって発話をテキスト化します。アプリやWebフォームであれば、そのままテキストとして受け取ります。
3. 判定（分類・振り分け）
問い合わせ内容を分類し、緊急性や回答リスクを判定します。
ここで重要なのは、緊急度判定をLLMだけに任せないことです。「ガス臭がする」「煙が出ている」「水が止まらない」といった明確な条件はルールでも検知し、そのうえでLLMによる文脈理解を組み合わせます。
また、AI側で判断に確信が持てない場合も有人対応へ切り替えます。AIに積極的に「緊急ではない」と判断させるのではなく、安全に自動化できる問い合わせだけを切り出すという考え方が重要です。
4. 応対（回答・記録）
回答に必要な情報の種類に応じて、参照方法を使い分けます。
管理規約、マニュアル、FAQ、過去の対応事例などの文書情報はRAG（検索拡張生成）を用いて検索します。一方、契約期間、更新料、入金状況、オーナー情報など、賃貸管理システムに構造化されている情報については、APIやデータ連携基盤等を通じて都度取得します。
そして、AIが回答できる問い合わせには一次回答を生成し、有人対応が必要なものについては必要情報を整理したうえで担当者へ引き継ぎます。応対内容は要約し、賃貸管理システム等に履歴として残します。
ポイントは、最初から「AIが全部答える」ことを目指さないことです。
分類や引き継ぎだけでも、「とりあえず全部ベテランに回ってくる」という状態を減らすことができます。回答まで完全自動化する領域は、その後、実績を見ながら段階的に広げていく方が安全です。
つまずき①：音声認識が「不動産の言葉」を聞き取れない
最初の壁は、意外にもAIの賢さ以前のところにあります。汎用の音声認識エンジンをそのまま電話に適用すると、不動産特有の語彙では認識誤りが起きやすくなります。
典型的なパターンは3つあります。
専門用語の誤変換
「原状回復」が「現状回復」に、「更新料」が「香辛料」に化ける、といった類のものです。同音・近音の一般語がある用語ほど誤りやすく、後段のLLMが読む前提テキストが崩れます。
固有名詞の壁
物件名（「メゾン○○」「グランドール△△」のような造語系の名称）、地名・駅名、設備の型番などは、一般語と比較して認識精度が安定しにくい領域です。
「どの物件の話か」が正しく特定できなければ、その後にどれだけ高度なAIを使っても正しい回答には辿り着けません。そのため、固有名詞の認識は実務上非常に重要なポイントになります。
話し言葉の揺れ
入居者は「原状回復」とは言いません。「退去のとき、壁紙って自分で払うんですか」などと言います。正式な用語と現場の言い回しのギャップを埋めないと、せっかくのFAQに辿り着けません。
レイヤーごとに積み上げることで対策します。
● カスタム語彙の登録
多くの音声認識サービスには、ドメイン固有の語彙を優先的に認識させる機能（カスタム語彙・キーワードブースト等）があります。
不動産用語に加え、自社で管理している物件名や設備名などを読み仮名付きで登録することで、認識精度の改善が期待できます。こうした情報が賃貸管理システム等でマスタ管理されている場合には、マスタデータから音声認識用の辞書を生成し、物件の入れ替わりに追従させる設計も可能です。
● LLMによる後段補正
それでも認識誤りをゼロにすることは困難です。
そこで、音声認識結果をLLMに渡し、不動産の問い合わせ文脈から不自然な語を検出・補正候補として提示させます。「香辛料の支払いについて」という認識結果であれば、前後の文脈から「更新料」の可能性を推定するといった処理です。
ただし、重要な情報をLLMの推測だけで上書きするのは危険です。元の認識結果も保持したうえで、物件名や部屋番号などはマスタデータと照合する設計が適しています。
● 聞き返しの設計
物件特定のように回答結果へ大きく影響する項目は、認識に頼り切らず、「○○マンションの201号室のお話でお間違いないでしょうか」と復唱・確認するフローにします。
これは特別なAI技術というより、人間のオペレーターが普段行っている確認作業を、そのままシステム設計に落とし込む発想です。
ここで一つ実務的なコツを挙げると、どの用語を辞書に載せるべきかの棚卸し自体をLLMに支援させる方法があります。
過去の通話録音や応対メモを文字起こしし、「頻出するが認識が崩れやすい語」「正式用語と入居者の話し言葉との対応関係」を抽出させれば、担当者がゼロから辞書を作成するよりも効率的に初期整備を進められます。
つまずき②：そもそも参照すべきナレッジが「人の頭の中」にある
2つ目の壁は、回答の元ネタの問題です。RAGは「文書を検索して答える」仕組みなので、検索対象の文書が存在しなければ何も答えられません。ところが賃貸管理の現場では、判断基準の多くが文書化されていません。
● 「この物件のオーナーは、10万円未満の修繕なら事後報告でよい」
● 「○○マンションは築古なので、給湯器の不調はまず△△設備さんに直行してもらう」
● 「このオーナーへの送金明細の質問は、経理の□□さんしか答えられない」
こうした物件別・オーナー別の暗黙のルールこそが、ベテランに電話が集中する理由です。FAQを整備しようとして「書くことが多すぎて挫折した」という話も珍しくありません。
ここでも、ゼロから手で書き起こすのではなく、すでにある記録からLLMでナレッジを起こす方が現実的です。応対履歴、通話録音の文字起こし、業者への発注メール。これらには判断の結果が残っています。LLMに「この応対ログから、物件別の対応ルールとして一般化できるものを抽出せよ」と処理させ、人間は生成されたドラフトを確認・修正する側に回る。ナレッジ整備を「執筆作業」から「レビュー作業」に変えるのが、挫折しないための要点です。
もう一つ、システム連携の観点も欠かせません。
AIが回答に利用する情報は、大きく「文書として探す情報」と「システムから取得する情報」に分かれます。
例えば、管理規約、業務マニュアル、FAQ、過去の対応事例などは、RAGによる文書検索との相性が良い情報です。
一方、更新料の有無、退去予告期間、契約期間、入金状況、オーナー情報など、賃貸管理システムに構造化されている情報については、FAQへ転記するのではなく、APIやデータ連携基盤等を通じて元のシステムから取得する方が適しています。
何でもRAGに取り込めばよいわけではありません。
同じ情報を複数の場所に書き写す仕組みにすると、いずれどこかの情報が古くなります。文書は検索し、マスタ・トランザクションデータはシステムから取得する。情報の性質に応じて参照方法を分けることが、正確性を維持するうえで重要です。
つまずき③：「全自動」を目指して信頼を失う
3つ目は、技術ではなく設計思想の問題です。導入初期に「せっかく入れるのだから」と自動応対の範囲を広げすぎると、誤回答や不適切な自動応対が発生し、かえって利用者や現場の信頼を損なう可能性があります。
象徴的なのが緊急対応です。「天井から水が漏れている」という電話にAIが悠長にFAQを読み上げれば、実害が出るだけでなく、「あそこの管理会社はAIに丸投げしている」という評判リスクに直結します。入居者対応は、対応を誤れば入居者満足度の低下や、オーナーによる管理会社の見直しにもつながり得る、失敗コストの高い業務です。
だからこそ、自動化の線引きを先に決めます。
判断する際には、主に以下の3つの観点で考えると整理しやすくなります。
① 緊急性
回答を待たせることで、人身・建物等への被害につながる可能性があるか。
② 情報の機密性・本人確認の必要性
誰にでも回答してよい情報なのか、契約者・オーナー本人であることを確認する必要があるのか。
③ 回答の確定性
客観的に一つの答えが決まる問い合わせなのか、個別判断や交渉を伴うものなのか。
例えば、次のように役割分担できます。
特に緊急対応では、AIの役割を「問題を解決すること」ではなく、必要な情報を聞き取り、緊急性を検知し、迅速かつ正確に人へ引き継ぐことまでに限定する方が安全です。
そして、この線引きは一度決めれば終わりではありません。
応対ログを分類・集計すると、「どの問い合わせが多いか」「どこまでAIだけで完結できたか」「どの段階で人へ切り替わったか」が見えるようになります。
その結果を見ながら、安全性と効果を確認できた領域から少しずつ自動化対象を広げていく。導入して終わりではなく、ログをもとに育てていく運用設計が、この領域では特に重要です。
進め方の目安
最後に、実際に着手する場合のステップを示します。
1. 現状把握（～1ヶ月）
直近数ヶ月分の応対履歴や通話録音を集め、問い合わせ主体、問い合わせ種別、件数、対応時間、緊急性などを分類します。
まず、「何にどれだけ時間が使われているのか」「どの問い合わせが繰り返し発生しているのか」を可視化します。
2. 自動化対象の選定（～2週間）
件数だけではなく、回答の難易度や誤回答時のリスクを踏まえて、AIへ任せる領域を決めます。
件数が多く、回答が定型的で、失敗時の影響が小さい問い合わせから始めるのが基本です。
3. スモールスタート（1～3ヶ月）
対象を絞って一次自動化を構築します。
音声を扱う場合には、音声認識精度、物件特定精度、聞き返しフローなどを検証します。回答まで自動化する場合には、単純な正解率だけではなく、以下のような指標を確認します。
● AIのみで完結した問い合わせの割合
● 有人対応へ切り替わった割合
● 回答の正答率
● 本人・対象を正しく特定できた割合
● 緊急問い合わせを正しく検知できた割合
● 一件あたりの対応時間・担当者工数
特に緊急度判定では、全体の正解率よりも、緊急案件を見逃していないかを重視します。
4. 範囲拡大（3ヶ月～）
応対ログを分析しながら、自動応対の対象とナレッジを段階的に広げます。
あわせて、物件マスタや契約データ等との連携を深め、FAQへの手作業による転記ではなく、必要な情報を元システムから取得する構成へ移行していきます。
まとめ
問い合わせ対応の自動化は、単にチャットボットや音声AIを導入することではありません。
「電話という音声チャネル」「入居者・オーナーそれぞれの問い合わせ特性」「物件・オーナーごとの暗黙知」「本人確認」「失敗コストの高い緊急対応」といった不動産管理業務固有の条件を、システム設計にどう織り込むかが重要です。
そして、AIに何ができるかを考えるよりも先に、どの業務であれば安全にAIへ任せられるのかを見極める必要があります。
いきなり音声AIや自動応答システムを構築する必要はありません。
まずは直近数ヶ月の問い合わせ履歴や通話ログの分析から始めるだけでも、AI導入の優先順位や投資判断の材料になります。
