AIで賃貸物件の修繕受付を安全に自動化する方法｜誤判定を防ぐ業務フロー・例外設計・KPI

「修繕依頼のメールを転記するだけで午前中が終わる」

「担当者によって緊急度の判断が異なり、対応漏れが起きる」

「AIを導入したいが、誤送信や個人情報の扱いが怖い」

賃貸管理における修繕受付は、AIによる業務自動化と相性のよい領域です。ただし、最初から完全自動化を目指すと、漏水や停電などの緊急案件を取りこぼす危険があります。

成功のポイントは、受付業務を細かく分解し、AIに任せる範囲と人が判断する範囲を明確にすることです。

この記事では、修繕受付を例に、初心者でも実行できるAI業務自動化の手順を解説します。業務フロー台帳、例外処理、テスト方法、KPI、導入可否の判断基準まで具体化するので、自社で安全に導入できるかを検討する材料として活用してください。

この記事の前提

本記事は、AIによる診断や修繕判断の完全自動化を推奨するものではありません。AIの主な役割は、情報抽出、分類候補の提示、確認質問や返信文の下書きです。緊急対応、発注、費用負担、契約責任に関する最終判断は、社内規程に基づいて人が行います。

修繕受付をAIで自動化すると何が変わるのか

修繕受付では、一般に次の作業が発生します。

1. 入居者から電話、メール、フォームなどで連絡を受ける
2. 物件名、部屋番号、連絡先、不具合の内容を確認する
3. 緊急度を判定する
4. 管理システムや台帳へ登録する
5. 担当者や修繕業者へ連絡する
6. 入居者へ受付完了を通知する
7. 対応状況を追跡する
8. 完了後に履歴を保存する

AIが得意なのは、文章から必要項目を抜き出すこと、不具合の分類候補を提示すること、返信文案を作ることです。

一方、次のような判断までAIだけに任せるべきではありません。

• 漏水、火災、ガス臭など、生命や財産に関わる緊急判断
• 高額な修繕の発注承認
• 費用負担者の最終判断
• 契約責任や法的責任に関する回答
• 情報が不足した依頼の自動完了
• 現地確認を伴わない故障原因の断定

国土交通省によると、賃貸住宅管理業には、賃貸人から委託を受けて行う建物・設備の点検、維持、修繕などの維持保全業務が含まれます。自己所有物件を除く管理戸数が200戸以上の賃貸住宅管理業者には、国土交通大臣への登録が義務付けられています。

自動化しても、管理会社としての責任そのものがAIへ移るわけではありません。適用される制度や義務は、自社の契約形態と管理戸数を踏まえて確認してください。

参考：国土交通省「賃貸住宅管理業法ポータルサイト」

自動化する範囲を先に決める

修繕受付を一つの業務として扱うと、「自動化できるか、できないか」という極端な判断になりがちです。実際には、工程ごとに自動化レベルを分けられます。

導入初期は、「情報抽出」「分類候補」「返信下書き」「担当者通知」までを対象にすると、効果と安全性のバランスを取りやすくなります。

最初に作るべき「業務フロー台帳」

ツールを選ぶ前に、現在の業務を台帳化します。少なくとも、次の項目を1行につき1作業として記録してください。

「担当者がいい感じに判断する」のような曖昧な表現は避けます。自動化できない原因の多くは、AIの性能不足ではなく、判断ルールが言語化されていないことです。

実務では、判断ルールを次の形式で記述すると検証しやすくなります。

条件：
現在も天井から水が落ちている

処理：
緊急候補に設定し、当番担当者と責任者へ同時通知する

禁止事項：
AIだけで原因や費用負担を断定しない

必要な追加確認：
水の量、発生場所、上階の有無、止水の可否、電気設備への接触

AIによる修繕受付自動化の実装手順

ステップ1：受付窓口を一つに集約する

電話、メール、チャット、紙のメモが混在している状態では、対応漏れを防げません。

まずは、各窓口から届いた依頼を一つのチケット管理システムまたはデータベースへ集約します。電話受付についても、担当者が同じフォームへ入力する運用にします。

最低限、次の項目を設定してください。

• 受付日時
• 入居者名
• 連絡先
• 物件名
• 部屋番号
• 不具合の場所
• 症状
• 発生時期
• 現在も継続しているか
• 写真または動画の有無
• 希望する連絡方法

すべてを必須入力にすると、緊急時の受付を妨げる可能性があります。そのため、「受付に必須の項目」と「後から補完できる項目」を分けます。

たとえば、緊急候補では連絡先、物件、部屋番号、症状、現在の状況を優先し、写真は後から追加できる設計が現実的です。

AIが必須情報を抽出できなかった場合は、処理を止めて追加確認へ回します。存在しない物件名や部屋番号をAIに推測させてはいけません。

ステップ2：AIの出力形式を固定する

AIの回答を自由文のまま使うと、後続処理が不安定になります。次のように出力項目と値の候補を固定します。

{
  "request_id": "REQ-20260722-0001",
  "property_name": "物件名",
  "room_number": "部屋番号",
  "category": "water",
  "symptom": "キッチン下から漏水",
  "urgency_candidate": "emergency",
  "missing_fields": [],
  "confidence": 0.94,
  "evidence": [
    "現在も水が流れている",
    "床まで水が広がっている"
  ],
  "recommended_action": "担当者へ即時通知",
  "prohibited_auto_actions": [
    "費用負担の確約",
    "修繕業者への自動発注"
  ]
}

出力値は、後から集計できるようにコード化します。

category:
water / electricity / gas / lock / air_conditioning /
noise / common_area / other / unknown

urgency_candidate:
emergency / urgent / normal / unknown

confidenceが一定値を下回った案件や、missing_fieldsに重要項目が含まれる案件は、自動送信せず人の確認へ回します。

ただし、AIが出す確信度は客観的な正解率ではありません。0.9と表示されても、実際に90％正しいとは限りません。しきい値は感覚で決めず、過去案件を使ったテスト結果から調整してください。

ステップ3：緊急度をルールとAIの二段階で判定する

緊急案件は、AIだけで分類しない設計が安全です。

最初に、明確な語句や選択項目を使ったルール判定を行います。

「火」「煙」「焦げ臭い」「ガス臭」
「大量の水」「天井から水」「水が止まらない」
「閉じ込め」「停電」「鍵が開かず入れない」
→ 緊急候補として即時エスカレーション

キーワードだけでは誤検知も起こります。たとえば、「昨日は焦げ臭かったが、現在は臭わない」と「今も煙が出ている」では対応が異なります。

そのため、ルールが緊急候補を検知した場合は、その判定をAIに解除させない設計にします。AIは文章全体から状況を整理し、担当者が確認すべき質問を追加します。

たとえば「水が出ない」という文だけでは、断水、凍結、元栓の閉鎖、給湯器故障など複数の可能性があります。AIに原因を断定させず、次のような確認質問を作らせるのが適切です。

• 水とお湯の両方が出ないか
• 室内のすべての蛇口で発生しているか
• 近隣や共用部でも断水しているか
• 元栓を操作したか
• 凍結の可能性がある気温か

ステップ4：返信は最初から自動送信しない

導入初期は、AIに返信の下書きだけを作らせます。

担当者が確認すべき項目は次のとおりです。

• 物件名と部屋番号が一致しているか
• AIが症状を誤解していないか
• 緊急度が実態より低く判定されていないか
• 費用負担を断定していないか
• 訪問日時を確約していないか
• 不要な個人情報が含まれていないか
• 入居者が行うと危険な操作を案内していないか
• 担当者が未確認の事実を記載していないか

修正内容は上書きするだけでなく、AIの原文と人の修正版を分けて保存します。これにより、どの分類や表現で誤りが多いかを分析できます。

ステップ5：担当者通知と期限管理を自動化する

受付後は、分類に応じて通知先と対応期限を変えます。

ここで示した時間は、法的な一律基準ではありません。管理委託契約、社内規程、物件の設備、営業時間、緊急連絡体制に合わせて定義してください。

期限を過ぎた場合は、自動的に上位担当者へ通知します。ただし、通知しただけで完了扱いにせず、「担当者が受領したか」「対応を開始したか」まで記録することが重要です。

received     受付済み
notified     担当者へ通知済み
acknowledged 担当者が受領済み
in_progress  対応中
dispatched   業者手配済み
resolved     症状解消
closed       記録確認後に完了

ステップ6：監査ログを残す

事故や問い合わせが発生したときに、結果だけが残っていても原因を追跡できません。最低限、次の情報を保存します。

ログへ個人情報を残しすぎると別のリスクが生じます。監査に必要な情報、閲覧できる担当者、保存期間、削除方法をあらかじめ定めてください。

ステップ7：小規模な並行運用で検証する

本番導入前に、過去の修繕依頼を必要な範囲で匿名化し、テストします。

最低限、次のケースを含めてください。

• 明確な漏水
• 漏水に見えるが結露だった案件
• ガス臭や焦げ臭の申告
• 鍵の紛失
• 騒音や近隣トラブル
• 同じ入居者からの重複連絡
• 物件名や部屋番号がない依頼
• 複数の不具合が一つの文章に含まれる依頼
• 誤字、方言、極端な短文
• 写真と本文の内容が一致しない依頼
• 緊急性を否定する表現を含む依頼
• 過去の出来事と現在進行中の出来事が混在する依頼

AIの判定と、複数の担当者が確認した正解ラベルを比較します。担当者同士でも判断が分かれる場合は、AIを評価する前に社内ルールを見直す必要があります。

本番移行後も、最初の2〜4週間は従来運用を残した並行稼働が安全です。

本番移行の合否を決めるテスト方法

単純な正解率だけでは、安全性を評価できません。たとえば100件中95件を正しく分類しても、誤り5件がすべて緊急案件なら本番投入できません。

次のように、実務上の影響を分けて集計します。

重要なのは、緊急案件を非緊急と判定した件数です。過剰検知は人の確認負荷を増やしますが、見逃しは安全性に直結します。

本番移行基準の例は次のとおりです。

緊急案件の見逃し：0件
必須項目の誤補完：0件
費用・日時の無承認確約：0件
個人情報の誤送信：0件
通常案件の分類精度：社内目標以上
人による修正理由：すべて記録済み
障害時の手動切替：訓練済み

これは一律の基準ではありません。自社のリスク評価に基づいて、責任者が承認できる基準を定めてください。

必ず設計しておきたい例外処理

自動化は、正常系よりも例外設計で品質が決まります。

AIや外部サービスが停止した場合

• 受付データを消さず待機キューへ保存する
• 一定回数だけ再実行する
• 再実行に失敗したら担当者へ通知する
• 手動受付へ切り替える
• 復旧後の二重登録を防ぐ識別子を付ける
• 緊急候補はAIの復旧を待たず人へ通知する
• 障害の開始時刻、影響件数、復旧時刻を記録する

同じ依頼が複数回届いた場合

メールアドレスだけで重複判定すると、家族や代理人からの連絡を見落とします。

物件、部屋番号、症状、発生時間、画像などを組み合わせて「重複候補」とし、最終的な統合は人が判断します。

重複案件を統合する場合も、元の問い合わせを削除せず、どのチケットへ統合したかを記録してください。

AIが判断できない場合

無理に分類させず、unknownを正式な分類として用意します。

「判断不能」は失敗ではありません。誤った自動処理を防げたという意味では、正常な安全機能です。

ただし、unknownの割合が高すぎる場合は、入力フォーム、分類定義、プロンプトのいずれに問題があるかを確認します。

添付画像を読み取れない場合

画像の破損、暗さ、対象箇所の不明瞭さなどにより、AIや担当者が状況を確認できないことがあります。

• 画像が読めなくても受付自体は完了させる
• 本文だけで緊急候補に該当する場合は処理を止めない
• 必要に応じて撮影箇所や撮影方法を案内する
• 室内全体など、不要な個人情報が写り込む撮影を求めない
• 画像だけで故障原因を断定しない

個人情報が含まれる場合

修繕依頼には、氏名、住所、電話番号、部屋番号、室内写真などが含まれます。

外部の生成AIサービスへ入力する前に、次を確認してください。

• 利用目的の範囲内で入力できる情報か
• 入力データがモデル学習に利用されるか
• オプトアウトや学習除外の条件
• 保存期間と保存場所
• 委託先や再委託先
• アクセス権限
• ログに残る情報
• 契約終了時の削除方法
• 海外移転の有無
• 事故発生時の連絡体制

個人情報保護委員会は、生成AIサービスへ個人情報を入力する際、利用目的の範囲やサービス提供者による機械学習への利用などを確認するよう注意喚起しています。

参考：個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」

効果を判断するKPI

「便利になった気がする」だけでは投資判断ができません。導入前の数値を2〜4週間計測し、導入後と比較します。

効率のKPI

• 1件当たりの受付処理時間
• 月間の手入力時間
• 担当者が修正した項目数
• 自動下書きの採用率
• 人の確認だけで処理できた案件の割合
• 時間外受付件数
• unknownへ分類された割合
• 例外処理に要した時間

品質のKPI

• 緊急案件の見逃し率
• 誤分類率
• 重複登録率
• 必須項目の欠損率
• AIによる誤補完件数
• 一次返信までの時間
• 対応期限超過率
• 入居者からの再問い合わせ率
• 承認前に送信・発注された件数

特に重要なのは、平均処理時間よりも「緊急案件の見逃し率」です。見逃しの目標は原則ゼロとし、1件でも発生したら本番運用の継続可否を含めて原因を調査します。

安全性のKPI

• 緊急ルールが正常に発火した割合
• AI停止時に手動運用へ切り替えられた割合
• 通知から担当者受領までの時間
• 個人情報を含むログへの不正アクセス件数
• 誤送信件数
• プロンプトやルールの無承認変更件数
• 障害から復旧までの時間
• 二重登録や二重送信の件数

収益性のKPI

月間効果は、次の式で概算できます。

月間削減額
＝ 削減できた作業時間 × 担当者の時間単価
－ AI・連携ツールの月額費用
－ 保守運用コスト

投資回収月数は次の式で確認します。

投資回収月数
＝ 初期導入費用 ÷ 月間削減額

たとえば、月間300件、1件当たり4分を削減し、担当者の時間単価を2,500円とすると、削減時間は月20時間、削減効果は月5万円です。

300件 × 4分 ÷ 60分 × 2,500円
＝ 50,000円

ここからAI、連携ツール、保守にかかる費用を差し引きます。これは計算例であり、実際の投資判断には自社の実測値を使ってください。

人件費だけで評価するのも危険です。対応漏れの減少、初動の短縮、履歴品質の改善も別の指標として記録します。

30日で始める小規模導入プラン

初心者は、次の順序で進めると実行内容が明確になります。

1週目：現状を測定する

• 直近50〜100件の依頼を収集する
• 個人情報の利用範囲を確認する
• 受付から完了までの工程を台帳化する
• 1件当たりの処理時間を測る
• 緊急、通常、情報不足、重複の定義を決める

2週目：テスト環境を作る

• 過去案件を必要な範囲で匿名化する
• AIの出力項目を固定する
• 緊急キーワードと禁止事項を設定する
• 正解ラベル付きのテストセットを作る
• 誤判定時の記録方法を決める

3週目：下書き運用を試す

• AIは情報抽出と返信下書きだけを行う
• すべての出力を担当者が確認する
• AIの出力と修正後の内容を別々に保存する
• 緊急案件の見逃しがないか毎日確認する
• 障害時の手動切替を一度訓練する

4週目：導入可否を判断する

• 導入前後のKPIを比較する
• 誤分類の原因を分類する
• 自動化範囲を広げる条件を決める
• 継続、修正後に再試験、中止のいずれかを責任者が判断する
• 次回評価日とルール管理者を決める

最初の30日で自動送信まで進める必要はありません。安全に再現できる「情報抽出と下書き作成」を完成させることが優先です。

本番稼働前に専門家が確認するポイント

本番稼働前に、次の質問へすべて回答できる状態にします。

• AIが誤判定したとき、誰が責任を持って修正するか
• どの条件で人へエスカレーションするか
• 緊急案件をAI停止時にも受け付けられるか
• AIの入力、出力、修正履歴を追跡できるか
• プロンプトや分類ルールの変更履歴が残るか
• 入居者がAI以外の窓口を選べるか
• 個人情報を必要以上に保存していないか
• 誤送信を防ぐ承認工程があるか
• 費用や訪問日時をAIが勝手に確約しないか
• 月に一度、誤判定を再評価する担当者が決まっているか
• AIサービスの契約条件が変わった際の確認担当者がいるか
• 障害時の手動運用を担当者が実行できるか
• 外部委託先を含むアクセス権限を定期的に見直しているか

経済産業省などが公表する「AI事業者ガイドライン」では、人間中心、安全性、プライバシー保護、セキュリティ、透明性、アカウンタビリティなどの考え方が示されています。版が更新される可能性があるため、導入時点の最新版を確認し、自社の運用ルールへ反映してください。

参考：経済産業省「AI事業者ガイドライン検討会」

よくある失敗と改善方法

失敗1：いきなり完全自動化する

誤分類や危険な返信に気づけません。

最初は「抽出だけ」、次に「分類候補と下書き」、最後に「限定条件で自動送信」という順序で拡大します。自動化範囲を広げるたびに、承認者と停止条件を決めてください。

失敗2：正常系しかテストしない

実際の問い合わせには、誤字、情報不足、複数症状、重複連絡が含まれます。

過去案件から難しい事例を集め、失敗しやすいテストセットを固定してください。モデル、プロンプト、分類ルールを変更するたびに、同じテストを再実行します。

失敗3：AIの回答を正解として保存する

AIは、もっともらしい理由を付けて誤分類することがあります。

元の問い合わせ、AI出力、担当者の修正、最終判断を別々に保存し、後から比較できるようにします。

失敗4：通知した時点で完了扱いにする

通知が届いても、担当者が確認したとは限りません。

「通知済み」「受領済み」「対応中」「業者手配済み」「症状解消」「完了確認済み」を分けて管理します。

失敗5：AIモデルを変更しても再テストしない

同じ指示でも、モデルや設定が変わると出力傾向が変わる場合があります。

使用モデル、プロンプト、ルールをバージョン管理し、変更前後で固定テストを実施してください。性能が上がったとされるモデルでも、自社の修繕受付で安全とは限りません。

実運用の検証ログを掲載する際のフォーマット

この記事の作成時点では、筆者による実運用件数、処理時間、誤分類数などの一次データは提示されていません。実測していない成果を「導入実績」として掲載するのは避けるべきです。

検証後は、次の形式で条件と結果を公開すると、読者が自社への適用可能性を判断しやすくなります。

検証期間：
対象件数：
対象物件数：
使用した受付経路：
比較対象となる従来フロー：
使用したAI・モデル：
プロンプトの版：
分類ルールの版：
AIが処理した範囲：
人が承認した範囲：

導入前の平均受付時間：
導入後の平均受付時間：
自動下書き採用率：
担当者による修正率：
誤分類率：
判断不能率：
緊急案件数：
緊急案件の見逃し数：
緊急案件の過剰検知数：
情報不足による停止件数：
システム停止回数：
手動運用への切替時間：

発生した失敗：
失敗が起きた入力：
原因：
実施した改善：
再テスト結果：
残っている限界：

成功例だけでなく、停止したケース、人へ差し戻した件数、期待した効果が出なかった指標も公開すると、一般的なAI活用記事との差別化になります。

画面やデータを公開する場合は、次の視覚資料が有効です。

• 導入前後の業務フロー図
• 個人情報をマスキングした入力画面
• AI出力と担当者修正の比較
• 緊急案件の見逃し・過剰検知を示す集計表
• KPIの導入前後比較
• 障害発生から手動切替までの時系列

室内写真、氏名、住所、部屋番号、電話番号、チケットIDなどから個人や物件を特定できないよう、公開前に必ず確認してください。

「人が対応したほうが早い」という反論について

件数が少なく、担当者が一人で全体を把握できる会社では、自動化の費用が効果を上回る場合があります。また、個別性の高い高級物件や、電話中心で高齢者からの問い合わせが多い現場では、人による受付の価値が大きいでしょう。

AI導入は目的ではありません。

次の条件に当てはまる場合に、部分的な自動化を検討してください。

• 月間の受付件数が増え続けている
• 転記作業に多くの時間を使っている
• 担当者ごとに分類結果が異なる
• 対応状況を追跡できていない
• 営業時間外の受付が多い
• 過去履歴を改善に活用できていない
• 同じ確認や返信を繰り返している
• 担当者の交代時に対応品質が落ちる

逆に、業務量やミスの発生状況を計測していない段階では、まず2週間の現状測定から始めるべきです。

測定の結果、月間件数が少なく、対応漏れもなく、自動化による削減効果が運用費を下回るのであれば、フォームの統一や返信テンプレートの整備だけで十分な場合もあります。

まとめ：完全自動化ではなく「安全に止まる仕組み」を作る

修繕受付のAI自動化で重要なのは、回答を速く生成することではありません。

必要な情報を正確に集め、危険な案件を人へ渡し、処理履歴を追跡できる状態を作ることが重要です。

最初のアクションとして、次の三つを実施してください。

1. 直近50〜100件の修繕依頼を収集し、必要な範囲で匿名化する
2. 受付から完了までの作業を業務フロー台帳に記録する
3. 緊急案件、情報不足、重複連絡、判断不能の基準を文章にする

そのうえで、次の順序で自動化範囲を広げます。

情報抽出
↓
分類候補の提示
↓
返信下書き
↓
担当者通知
↓
限定条件での自動処理

各段階で、誤判定時に止まる条件、人が承認する条件、元の状態へ戻せる手順を用意してください。

この設計が整えば、AIに任せる部分と、人が責任を持って守るべき部分が見えてきます。まずは「情報抽出と返信下書き」から始め、実測したKPIを確認しながら自動化範囲を広げるのが、安全で再現性の高い進め方です。