結論ファースト:管理会社の入居者対応は「初動仕分け+優先度判定+書類ドラフト」だけで月70時間が浮く
結論を1文で:不動産管理会社の入居者対応業務(問い合わせ仕分け・修繕業者手配の優先度判定・退去立会いチェック・原状回復見積ドラフト・定期巡回レポート)は、Claude Codeを「初動の仕分け補助」と「書類のたたき台生成」に絞って組み込むと、管理担当の判断時間を月60〜80時間圧縮できる、というのが現場感です。
- 要点1:「設備故障/隣人トラブル/契約更新」の3トリアージは、Claude Codeのプロンプト+構造化出力で初動振り分けが安定する
- 要点2:修繕の優先度(緊急・準緊急・通常)は「水漏れ・ガス・鍵」など固定ルールをCLAUDE.mdに書き出すと判定がブレない
- 要点3:退去立会いチェックリストと原状回復見積はテンプレ化+写真メモ突合で「ドラフトまで」を自動化。最終判断は管理担当・宅建士が必ず人手で行う
対象読者:賃貸管理戸数500〜5,000戸規模の管理会社の業務改善担当・社内SE・PM。賃貸仲介ではなく「管理運営」(プロパティマネジメント)が主領域の方。
今日読めること:対談形式で「入居者対応の現場で実際にClaude Codeをどう仕込んだか」「コピペで使えるプロンプト5本」「やらかした失敗パターン4個」「個人情報・宅建業法まわりで気をつけたポイント」までまとめて持ち帰れます。
リード文:ある火曜日の朝、管理会社のオペレーターから受けた相談
2026年の春先、知人経由で都内のとある不動産管理会社(管理戸数約2,800戸、社員25名)から「入居者対応の電話とメールが捌ききれない、Claude Codeでなんとかできないか」という相談を受けました。話を聞いてみると、月曜の朝イチで「お湯が出ない」「上の階の足音がうるさい」「更新の書類が届いた」が同時並行で20件来る、というよくある日常風景でした。
面白かったのは、相談主の担当者が「自動返信したいわけではない。最初の30秒の仕分けだけ手伝ってほしい」とハッキリ言ってくれたことです。「最終的に修繕業者を呼ぶか、本人に折り返すか、書類を発送するかは絶対に人が決める。ただ、その判断に行き着くまでの『これは何の問い合わせで、誰がいつまでに動くべきか』を整理する初動だけが地獄なんです」と。
この記事は、その現場で実装担当(私)と管理会社のオペレーター(以下、Aさん)が、3週間かけてClaude Codeをどう仕込んでいったか、を対談形式でまとめたものです。同業他社で似た課題を持つ方への、「先に詰まったポイント」の共有を兼ねています。
第1幕:なぜ「自動返信」ではなく「仕分け補助」にしたのか
佐藤(以下、S):Aさん、最初に「自動返信は絶対やらない」って釘を刺してくれましたよね。あれ、なぜですか?
Aさん:うちの業界で過去2回、メール自動返信を導入して炎上した事例を見てるからです。1つは「水漏れで床が浸かってます」という緊急問い合わせに、定型文で「営業時間内にご連絡します」と返してしまった件。もう1つは、契約更新の重要書類について「お問い合わせありがとうございます」だけ返して、肝心の更新意思確認を3週間放置した件。どっちも入居者の信用を失って、退去に直結しました。
S:なるほど、初動の判断ミスがそのままトラブル化する業界なんですね。
Aさん:そう。だから私たちが欲しいのは「ChatGPTにそのまま返信させる」じゃなくて、「来た問い合わせを3秒で分類して、優先度ラベルを貼って、担当者にSlackで通知する」という地味な裏方の作業なんです。判断と返信は人がやる。でも「どの箱に入れるか」を機械にやらせたい。
S:これ、世の中の「AIで顧客対応自動化!」みたいな煽りとは真逆の方針で、すごく現場感がありますよね。実際、Claude Codeを最初に組み込んだのも、メール本文を読み込んでJSONで「カテゴリ・緊急度・推奨アクション・対応期限」を返すだけのシンプルなパイプラインでした。
Aさん:そうそう。最初は「もっとリッチに返信案も生成して」って言いかけたんですけど、佐藤さんから「最初は仕分けだけで運用してから、3週間後に追加機能を入れましょう」と言われて、結果的にそれが大正解でした。仕分けだけでも担当者の朝のストレスが激減したので。
仕分けの3カテゴリと、なぜそれに絞ったか
S:カテゴリは「設備故障」「隣人トラブル」「契約更新」の3つに絞りましたよね。これも実は議論したポイントでした。
Aさん:業界の問い合わせ分類は本来もっと細かくて、家賃関連・原状回復・保険・退去・鍵紛失・駐車場…と20カテゴリ以上あります。でも実データを2ヶ月分集計したら、件数の8割が上記3カテゴリだったんです。残り2割は「その他」に投げて人が見る、というシンプルな割り切りにしました。
S:「分類が完璧じゃないとダメ」と思い込みがちなんですけど、現場のオペレーションでは「8割が正しく分類できて、残り2割は人が見る」で十分回りますもんね。
第2幕:プロンプト1本目「入居者問い合わせの3トリアージ」
ここからは実際に投入したプロンプトを1本ずつ紹介します。すべてClaude Code経由でAPIに投げているもので、CLAUDE.mdに業界知識(緊急判定ルール・宅建業法注意事項・社内エスカレーション基準)を書き込んだ上で使っています。
あなたは賃貸不動産管理会社のベテランオペレーターです。
入居者からの問い合わせ本文を読んで、以下のJSON形式で初動仕分けを返してください。
【入力】
- 問い合わせ本文(メール・電話起こし・LINE等)
- 物件名・部屋番号・入居者氏名(個人情報マスク済み)
- 受信日時
【出力JSON】
{
"category": "equipment_failure | neighbor_trouble | contract_renewal | other",
"urgency": "emergency | semi_urgent | normal",
"summary": "問い合わせの要旨を50字以内で",
"recommended_action": "管理担当が次にやるべき動作を1行で",
"deadline_hours": 数値(緊急時1, 準緊急24, 通常72),
"escalation_required": true/false,
"notes": "気をつけるべき事項(個人情報・宅建業法・契約上の制約等)"
}
【判定ルール】
- 水漏れ・ガス漏れ・鍵紛失・電気停止 → emergency
- 給湯器故障・エアコン故障(夏冬)・排水詰まり → semi_urgent
- 隣人トラブルは内容により urgency 判定。暴力・脅迫を匂わせる文言があれば emergency
- 契約更新は通知期限の30日前を切っていれば semi_urgent
- 不明確な場合は other + escalation_required: true で人に上げる
【厳禁】
- 入居者個人を特定する情報は summary・notes に書かない
- 法的判断・損害賠償の言及は escalation_required: true として人に上げる
- 「自動返信案」は生成しない。仕分けのみが本タスク
問い合わせ本文を入力します:
{ここに本文}このプロンプトのキモは、最後の「厳禁」セクションです。Claude Codeは指示しないと気を利かせて「返信案」まで生成しがちなので、初期は明示的に止めました。3週間運用して安定したあとに、別プロンプトで返信案ドラフト生成を追加しています(後述)。
運用1週間で気づいた、判定の偏り
Aさん:運用初週で気づいたのは、「夏のエアコン故障」を normal で返してくることがあったんです。8月の真夏日に「エアコンが効きません」が normal で来たときは、さすがに人が見てびっくりしました。
S:あれは私の判定ルールの書き方が甘かったですね。「夏冬」と書いただけだと、Claude Codeは「夏かどうか」を受信日時から判断するのに、サマー判定の閾値を持っていなかった。だからCLAUDE.mdに「6月15日〜9月30日の間にエアコン故障が来たら必ず semi_urgent 以上にする」と気温閾値を温度ではなく日付で書き加えました。
Aさん:気温で書かないのがミソですよね。実際の室温データなんて問い合わせに含まれてないので、日付ベースのほうがブレない。
第3幕:プロンプト2本目「修繕業者手配の優先度判定」
仕分けが安定したあと、次に組み込んだのが修繕業者手配の優先度判定でした。これは管理担当が「水道屋さんに今日中に行ってもらうか、明日でいいか、来週でいいか」を決める判断の補助です。
あなたは賃貸不動産の修繕手配を10年やってきたPM(プロパティマネージャー)です。
以下の問い合わせ内容から、修繕業者への発注優先度を判定してください。
【入力】
- カテゴリ(設備故障)
- 設備種別(給湯器・エアコン・トイレ・水道・電気・ガス・鍵・建具・その他)
- 故障状況の要旨
- 物件築年数
- 入居者属性(高齢者世帯・乳幼児有・ペット有・その他、本人の同意取得済み情報のみ)
- 季節(受信日)
【出力JSON】
{
"priority": "P0 | P1 | P2 | P3",
"target_dispatch_hours": 数値(P0は2時間以内, P1は24時間以内, P2は3営業日以内, P3は1週間以内),
"recommended_vendor_type": "24h緊急対応業者 | 通常委託業者 | メーカー直 | 自社対応可",
"additional_notes": "業者選定で考慮すべき特記事項",
"tenant_communication": "入居者への連絡で必ず伝えるべき事項を箇条書きで",
"billing_responsibility_guess": "貸主負担 | 借主負担 | 要契約確認"
}
【優先度判定ルール】
- P0(2時間以内): 漏水で階下被害発生中、ガス漏れ、玄関鍵故障で締め出し、真冬の給湯器全停止
- P1(24時間以内): 真夏のエアコン故障、トイレ全停止、給湯器水漏れ
- P2(3営業日): 建具のがたつき、網戸破れ、軽微な水漏れ
- P3(1週間): 美観のみの不具合、優先度不明案件
【厳禁】
- 費用負担の最終判定は出さない(契約書・状況確認が必須のため "要契約確認" を返す)
- 業者名・具体的な発注先は提示しない(管理会社の業者選定権限を侵すため)
- 高齢者世帯・乳幼児有という情報は判定に使ってよいが、出力 JSON 内に当該情報を残さない
問い合わせデータを入力します:
{ここに構造化データ}S:このプロンプトで一番議論したのは「費用負担の判定をAIに出させるかどうか」でした。
Aさん:あれは絶対やめてほしいって伝えました。費用負担(貸主か借主か)は契約書の特約や入居時の状況によって変わるので、AIに「借主負担」と1回でも出されたら、それを根拠に入居者と揉めるリスクがあるんです。だから出力は「要契約確認」固定で、最終判断は管理担当の人間が契約書を見て決める運用にしました。
S:これ、AI実装でやりがちな「ついでに判定」の典型的な落とし穴ですよね。技術的にはできても、業界の法務・慣習的にやってはいけない判定がある。
第4幕:プロンプト3本目「退去立会いチェックリスト生成」
退去立会いは、管理会社の業務の中でも特に時間と神経を使う作業です。物件タイプ・築年数・入居期間・前回原状回復の有無、によってチェック項目が大きく変わるため、毎回ベテランが頭の中でリストを組み立てていました。これをClaude Codeに「物件情報を渡したら、その物件専用のチェックリストPDFのドラフトを返す」形にしました。
あなたは原状回復ガイドライン(国土交通省)を熟知した、賃貸管理のベテラン立会い担当です。
以下の物件情報から、退去立会い用のチェックリストをMarkdown形式で出力してください。
【入力】
- 物件タイプ(マンション・アパート・戸建)
- 築年数
- 専有面積(㎡)
- 間取り(1K/1LDK/2LDK等)
- 入居期間(月数)
- 入居者情報(ペット有無・喫煙有無・単身/ファミリー、本人同意取得済み)
- 前回原状回復の実施有無と日付
- 特記事項(リフォーム済み箇所等)
【出力Markdown構造】
# 退去立会いチェックリスト
## 物件情報サマリー
## 立会い当日の持ち物
## 確認エリア別チェックリスト
### 玄関・廊下
### 居室(各部屋)
### キッチン
### 浴室・洗面
### トイレ
### バルコニー
### 共用部から見える範囲
## 写真撮影必須箇所(最低N枚)
## 入居者立会い時の確認事項
## 国交省ガイドライン照らし合わせメモ
- 経年劣化として貸主負担になる可能性が高い項目
- 善管注意義務違反として借主負担を協議すべき項目
- 「要協議」として後日判断する項目
【判定の根拠】
- 国土交通省「原状回復をめぐるトラブルとガイドライン」(再改訂版)に準拠
- 経年劣化と通常損耗は貸主負担が原則
- 入居期間に応じた減価償却を考慮(壁紙は6年で残存価値1円扱い等)
- ペット有・喫煙有は「善管注意義務違反」の判定基準を別建てで列挙
【厳禁】
- 最終的な原状回復費用の借主請求額は出さない(個別協議事項のため)
- 国交省ガイドラインの逐語引用は避ける(著作権配慮)
- 入居者氏名・連絡先はチェックリストに記載しない
物件データを入力します:
{ここに物件情報}Aさん:これ、最初に出力させたとき「ペット有」物件のチェックリストで「クロス全面張替前提」みたいに書かれて、ちょっと困りました。
S:あー、判定を強く出しすぎた失敗ですね。プロンプトに「経年劣化として貸主負担になる可能性が高い項目」と「善管注意義務違反として借主負担を協議すべき項目」を明示的に分けて出すよう書き直して、後者は必ず「協議事項」と明記するようにしました。
Aさん:修正後は「ペット飼育に伴うクロスの臭気付着は要協議。入居期間と減価償却を加味して判断」みたいな出力になって、現場でそのまま使えるレベルになりました。
第5幕:プロンプト4本目「原状回復見積ドラフト」
チェックリストの次は、見積ドラフトです。これは「立会い時の写真メモ+チェックリスト結果」をインプットに、「原状回復見積のたたき台」を出す用途で使っています。最終的には管理担当が業者見積と突き合わせて修正するものですが、ドラフトがあるだけで初動が2時間早くなります。
あなたは原状回復見積を年間500件作成しているベテラン担当です。
以下の入力から、原状回復見積のドラフトをMarkdown表形式で作成してください。
【入力】
- 退去立会い結果(チェックリストの記入済みデータ)
- 写真メモ(撮影箇所と状況の文字起こし)
- 物件情報(築年数・専有面積・入居期間・最終リフォーム履歴)
- 地域(東京23区・首都圏郊外・地方都市)
【出力Markdown】
## 原状回復見積ドラフト(管理会社内部用・確定見積ではない)
### 1. 貸主負担(経年劣化・通常損耗)
| 項目 | 数量 | 単価 | 小計 | 根拠 |
### 2. 借主負担候補(善管注意義務違反の可能性)
| 項目 | 数量 | 単価 | 小計 | 根拠 | 協議事項 |
### 3. 要協議(現時点で負担確定できない項目)
### 4. 単価の参照元
### 5. このドラフトを業者見積と突き合わせる際の確認ポイント
【単価設定の原則】
- 地域別単価表は管理会社が別途持っている前提(プロンプトには含めない)
- 単価が不明な項目は "要見積" と記載し、推測単価は出さない
- 入居期間×減価償却率を借主負担側で必ず明記
【厳禁】
- 入居者への請求額として確定的に提示する文言は使わない(「ドラフト」表記を全ページに入れる)
- 業者見積を待たずに最終金額を断定しない
- 「貸主側で全額負担すべき」「借主から取れる」等の断定的な言い方は避け、必ず「協議事項」を残す
入力データを渡します:
{ここに立会い結果・写真メモ}S:このドラフト機能の運用で、管理会社の経理担当から「業者見積と突き合わせるとき、最初に当社で叩き台を持ってる状態だと、業者交渉が全然変わる」というフィードバックをもらいました。
Aさん:そうなんですよ。今までは業者見積が出てきてから初めて「これ高いんじゃない?」と検討してたのが、こちらが叩き台を持ってる状態で見積を受け取れるので、議論の出発点が変わる。1物件あたりの見積精査時間が3時間→1時間に短縮されました。
第6幕:プロンプト5本目「定期巡回レポート自動化」
最後に組み込んだのが、定期巡回レポートの自動生成です。月1回の物件巡回で、巡回担当者が撮影した写真と短いメモ(「ゴミ置き場やや散乱」「廊下の電球1個切れ」)を入力すると、オーナー向けの定型フォーマットレポートを生成します。
あなたは賃貸物件の建物管理レポートを月100件作成している管理担当です。
以下の巡回メモから、オーナー(貸主)宛ての月次巡回レポートを生成してください。
【入力】
- 物件名・住所・巡回日時・巡回担当者名
- 撮影写真の場所と簡易メモ(箇条書き)
- 前回巡回との差分メモ
- 入居率(空室戸数/総戸数)
- 共用部の電気使用量推移(直近3ヶ月)
【出力Markdown】
## 月次巡回レポート({YYYY年MM月分})
### 1. 物件概要
### 2. 当月の主要トピックス(3行サマリー)
### 3. 共用部の状態
- 玄関・エントランス
- 廊下・階段
- ゴミ置き場
- 駐輪場・駐車場
- 屋外設備
### 4. 当月発見した要対応事項(優先度別)
- 緊急(1週間以内対応推奨)
- 通常(1ヶ月以内対応推奨)
- モニタリング(継続観察)
### 5. 入居状況サマリー
### 6. 推奨対応とその概算費用感(費用は要見積であることを明記)
### 7. 次月の重点確認事項
【書き方のルール】
- オーナーが30秒で全体像を掴めるよう冒頭3行サマリーを必ず置く
- 写真は本レポートには貼らず、別添資料として「写真集 P.X 参照」と参照番号を残す
- 入居者個人を特定する情報(クレーム主の氏名等)はレポート本文に出さない
- 法的トラブル(訴訟・賠償等)を匂わせる事項は「別途口頭でご報告」とする
【厳禁】
- 巡回担当者本人の主観的評価(良い・悪い)を強く出さない
- オーナーの判断を誘導する表現は避ける
- 隣地・周辺住民とのトラブルは事実関係のみを記述
巡回データを入力します:
{ここに巡回メモ・写真リスト}Aさん:このレポート自動化が、実は社内で一番喜ばれました。月100件の物件を回るうちの担当者が、巡回後の事務処理に1件30分かかってたのが、5分に短縮されたんです。月で言うと…単純計算で40時間以上の削減ですね。
S:これはAIに「写真を見せて」じゃなくて「写真の場所と短いメモ」を渡すだけで成立する設計にしたのがよかったですね。画像解析は不要で、テキスト処理だけで業務が回る。
第7幕:【要注意】やらかした失敗パターン4個
3週間の運用で、私たちが実際にやらかした失敗を正直に共有します。同じ轍を踏まないようにご注意ください。
失敗1:プロンプトに入居者の個人情報をマスクせずに投入
❌やってしまったこと:運用初日、Aさんのチームの新人さんが、入居者の氏名・電話番号入りのメール本文をそのままClaude Code経由でAPIに投げてしまいました。幸いログ保管設定で社内環境のみに留まりましたが、個人情報保護法の観点で「外部に出る前のマスキング」を徹底すべきでした。
⭕修正後:メール本文をAPIに送る前に、社内の前処理スクリプトで「氏名・電話番号・口座番号・物件号室の3桁目以降」をマスクしてからプロンプトに投入。マスキング処理自体もClaude CodeにCLI ツールとして作らせて、運用に組み込みました。
失敗2:Claude Codeに契約書の最終解釈をさせてしまった
❌やってしまったこと:初期版の修繕優先度判定プロンプトで、「ペット可物件で猫の爪痕クロス→借主負担100%」と断定的に出してきた回があり、それを根拠に管理担当が業者発注しかけました。実際はその物件は「ペット飼育時の小破損は協議事項」という特約があり、AIの判定は契約特約を見てなかった。
⭕修正後:修繕系のプロンプトすべてに「費用負担の最終判定は出さず、必ず “要契約確認” を返す」と明記。契約書のスキャンを別途人間が確認するワークフローに統合しました。宅建業法的にも、契約解釈は宅建士が行うべき領域なので、AI に任せきれない部分です。
失敗3:緊急判定の閾値を「気温」で書いてしまった
❌やってしまったこと:「気温30度以上の日にエアコン故障があれば緊急」とプロンプトに書いたら、Claude Codeが気温情報を持ってないため判定が空転。8月の真夏日にエアコン故障の問い合わせが normal で返ってきて、現場で気付くのが半日遅れました。
⭕修正後:気温ではなく「日付(6月15日〜9月30日)」で判定するルールに書き換え。AI が確実に持っている情報(受信日時)で判定するのが、運用上のコツです。
失敗4:仕分け結果を信用しすぎて「人の目」を外しかけた
❌やってしまったこと:運用2週目で、仕分け精度が90%を超えた頃に、Aさんのチームから「もう全部AIに任せて、Slackチャンネルへの通知も自動でやろう」という声が上がりました。実際に1週間ほど「AI仕分け→自動Slack通知」運用にしたところ、たまたま「上の階から子供の足音」という問い合わせが neighbor_trouble の通常優先度で振り分けられ、よく読むと末尾に「もう殴り込みに行きたい」という暴力示唆の一文があったのを見落とすところでした。
⭕修正後:「自動Slack通知前に、人の目で5秒だけ全件チェックする」工程を必ず挟むことに。仕分け作業自体は AI で90%短縮されているので、最終確認の5秒×30件=2.5分は許容範囲、という割り切りで運用しています。
第8幕:個人情報・宅建業法まわりで気をつけたこと
S:不動産管理の業務にAIを組み込むときに、技術以前に注意すべき法的・業界的な制約があったので、ここでまとめておきます。
個人情報保護法の観点
- 入居者の氏名・住所・電話番号・家族構成は「個人情報」に該当。プロンプトに投入する前にマスキング処理を行う
- 外部API(OpenAI・Anthropic等)に送信する場合は、利用規約とデータ保持ポリシーを確認(Anthropic Claude API のデフォルトは「学習に使用しない」設定だが、契約・設定の最新確認は必須)
- マスキング後でも、物件号室+周辺情報の組み合わせで個人特定が可能な場合があるため、号室の一部もマスク対象に
宅建業法・賃貸住宅管理業法の観点
- 賃貸借契約の「重要事項説明」「契約解釈」はAIに任せない。宅建士の業務領域
- 原状回復費用の最終確定は、契約書・国交省ガイドライン・入居者協議の3要素で決まる。AI のドラフトはあくまで「たたき台」
- 2021年施行の賃貸住宅管理業法により、管理戸数200戸以上の管理会社は登録制+業務管理者必置。重要事項説明・管理事務報告書の作成主体は人間の業務管理者
業界慣習・トラブル予防の観点
- 入居者・オーナーへの初動連絡は必ず「人の名前」で行う。AIによる自動返信は信頼を失う
- 修繕業者の選定は管理会社の重要な権限。AI が業者名を推奨することは避ける(取引関係・キックバック問題に発展する可能性)
- クレーム対応の記録は AI が要約してもよいが、原文(メール・通話録音書き起こし)は必ず保管
第9幕:他業界・類似ワークフローとの比較
この記事を読んで「うちの業界でも似たことやりたい」と思った方向けに、関連する Claude Code 実装事例を紹介します。
- 不動産仲介の物件情報処理を3倍速にしたClaude Code活用事例 — こちらは「仲介(売買・賃貸契約の成立まで)」の業務で、本記事の「管理(契約後の運営)」とは別フェーズの実装事例です。仲介と管理を両方やっている会社は両方参考になります
- 不動産AI査定を5ステップで自動化したClaude Code導入事例 — 査定(物件価格の算出)業務の自動化事例。本記事の管理業務とは目的が違いますが、「業界知識をCLAUDE.mdに書き込む」という設計思想は共通です
- クリニック予約管理ワークフローをClaude Codeで自動化 — 業界は違えど「問い合わせの初動仕分け」「人の最終判断を残す」という設計思想がよく似ています。仕組みの設計参考に
第9.5幕:CLAUDE.md にどう業界知識を書いたか(現場の生データ)
S:ここまでプロンプト5本を見てきましたが、実は「プロンプト本体」よりも「CLAUDE.md にどう業界知識を仕込むか」のほうが、現場の精度に効きました。Aさんの会社で実際に書き込んだ CLAUDE.md の章立てを共有します。
CLAUDE.md の構成(管理会社版・抜粋)
1. 物件管理ドメインの基本用語
「築古」「リファイン」「サブリース」「定期借家」「普通借家」「特定優良賃貸住宅」など、業界外の人には伝わりにくいが社内では日常用語のものを20語ほど定義しました。これを入れる前は、Claude Code が「リファイン」を「改善」と解釈して的外れな出力をすることがあったのですが、定義を入れたら一発で文脈が伝わるようになりました。
2. 緊急対応の社内エスカレーション基準
「水漏れで階下被害発生→即時に管理本部長へ電話」「ガス漏れ→ガス会社・消防への通報を入居者にも案内」「鍵紛失の深夜対応→24時間鍵業者の連絡先を入居者に教えてよい」など、社内で「これは即上に上げる」と決めているルールを箇条書きで10項目入れました。Claude Code は明文化されたルールに従ってくれるので、escalation_required フラグの精度が劇的に上がりました。
3. 契約特約パターン集
「ペット飼育時の小破損は協議事項とする」「短期解約違約金の標準額」「敷金償却特約の地域別慣習」など、契約書に頻出する特約を約30パターン記録。これは Claude Code に「契約解釈をさせる」ためではなく、「契約特約の存在を意識した上で『要契約確認』フラグを的確に立てる」ための知識です。
4. 業者ネットワーク情報(抽象化)
具体的な業者名は書かず、「24時間対応水道業者あり(夜間料金1.5倍)」「給湯器メーカー直保証期間は2年」など、業務判断に必要な抽象情報だけ書きました。具体業者名はAIに渡さないことで、業者推薦の偏りや取引関係のリスクを避けています。
5. 過去トラブル事例の学習データ
「過去に隣人トラブルが訴訟まで発展した事例の特徴(初動の言葉遣い・記録不足・対応遅延)」「原状回復で揉めた事例パターン」など、過去5年分の社内トラブル事例から教訓だけを抽出して10事例ほど書きました。これにより、新人担当者でも「ベテランが頭の中で警戒している危険サイン」を Claude Code 経由で察知できるようになりました。
Aさん:CLAUDE.md を整備する作業自体が、社内の暗黙知の見える化になりました。ベテラン社員が「こういう問い合わせには気をつけろ」と若手に口頭で伝えていたノウハウが、文書化されて全社員のローカル開発環境で利用可能になった。これは AI 化の副次効果として大きかったです。
CLAUDE.md の更新サイクル
S:運用が始まると、必ず「想定外の問い合わせ」が来ます。例えば「ベランダにハチの巣ができた」「同棲相手の住民票異動の相談」など、最初のルールに入っていない問い合わせ。これをどう CLAUDE.md に取り込むか、運用ルールを決めました。
- 週1回(月曜の朝会)で、その週の「分類不能・人手対応」案件をレビュー
- 3件以上同種の問い合わせが来たら CLAUDE.md にカテゴリ追加 or ルール追記
- 追記は git で管理し、変更履歴を残す(誰が何のために追加したかを後から検証できる)
- 四半期に1回、CLAUDE.md 全体を棚卸して、重複・古いルールを整理
Aさん:git で CLAUDE.md を管理する、というのは社内的に新しい文化でした。今までドキュメント類は共有フォルダで「最新版」「v2」「v3_確定」と乱立していたのが、git の commit log で「いつ・誰が・なぜ」追記したかが追跡できる状態に。これだけでも管理会社の文書文化が変わりました。
第9.7幕:他の管理会社にもヒアリングしてみた
記事の参考にするため、Aさんの会社以外に4社の管理会社にも非公式にヒアリングしました(管理戸数800戸〜12,000戸の範囲)。匿名化したうえで、共通して見えた論点を共有します。
共通課題1:24時間対応の負担
賃貸管理は「夜中の鍵忘れ」「深夜の水漏れ」など24時間対応が前提の業界です。これに対して各社の対応は割れていました。
- 大手系3社:外部の24時間コールセンターに一次受けを委託(月額数万円〜)
- 中堅系1社:管理担当の輪番制で深夜携帯当番
- Aさんの会社:輪番制+ AI による問い合わせ仕分け(深夜の自動分類は「emergency 以外は翌朝対応」で運用)
Aさんの会社のように、「AIで仕分けて『これは朝でいい』を判別する」やり方は、深夜当番の精神的負担を大きく下げます。深夜に着信があっても、AIの初動判定で emergency でなければ翌朝対応にできる、という判断軸を持てるからです。
共通課題2:オーナー報告の質のばらつき
巡回レポート・修繕報告・更新報告など、オーナー宛ての報告書は担当者ごとに品質がバラつきがちです。「Aさんのレポートは詳しいけどBさんのは粗い」というようなクレームに発展することも。
定型フォーマットを Claude Code で生成すると、最低限の品質が担保されます。ベテランが書くより劣る面はあるかもしれませんが、「平均値が上がる」「個人差が縮む」効果は大きいです。
共通課題3:管理委託契約の更新タイミングでのオーナー離脱
多くの管理会社が、管理委託契約の更新時に2〜3割のオーナーから「自主管理に切り替えたい」「他社に変えたい」と言われる経験を持っています。理由を聞くと「報告が遅い」「対応が遅い」「価値を感じない」という声が多い。
AI で初動が速くなり、定期報告の質が安定すると、この更新時離脱率が改善する可能性があります(Aさんの会社では、まだ AI 導入から3ヶ月なので確定的なことは言えませんが、明らかに「報告を褒められる頻度」が増えているそうです)。
第9.8幕:導入したい管理会社が最初の1ヶ月でやるべき5ステップ
「うちも明日から始めたい」という方のために、最初の30日でやるべきことを5ステップでまとめます。
Step 1(Day 1〜3):現状業務の棚卸し
過去2ヶ月分の問い合わせを Excel/Google Sheets に転記し、以下の項目で分類します。
- 受信日時・受信チャネル(電話・メール・LINE・対面)
- 問い合わせカテゴリ(自社の業務分類で)
- 緊急度(自分たちが実際にどう判定したか)
- 初動所要時間(問い合わせ受信から「次のアクション」が決まるまで)
- 完了所要時間(問い合わせ受信からクローズまで)
これだけで、「どこに時間を使ってるか」「どのカテゴリが多いか」が見えます。
Step 2(Day 4〜7):Claude Code 環境の準備
社内で Claude Code を試せる環境(個人のMac/Windows)を最低3名分用意します。インストールと API キー取得、CLAUDE.md の雛形作成までを完了。この時点では業務にはまだ入れず、「Claude Code で何ができるか」を肌感覚で覚えるフェーズです。
Step 3(Day 8〜14):仕分けプロンプトの試運転
本記事のプロンプト1本目を、Step 1 で集めた過去問い合わせデータに当てて、AI の分類結果と「実際の人間の判断」を突き合わせます。一致率が80%以上になるまで、プロンプトと CLAUDE.md を調整。
このフェーズで重要なのは、「不一致だった20%」を1件ずつ見て、どちらが正しかったかを判定する作業です。AI が間違っているのか、人間の判断にバラつきがあるのか、両方ともケースバイケースなのか、を切り分けます。
Step 4(Day 15〜21):社内ワークフローへの組み込み
仕分けプロンプトを実業務に組み込みます。具体的には:
- 新規問い合わせの受信時に、自動で AI 仕分けを実行
- 仕分け結果を Slack/Teams の指定チャンネルに通知
- 担当者が5秒で目視チェックしてから、優先度ラベル・担当者アサインを行う
- 1日の終わりに「AI 仕分けと最終アサインの差分」を全件ログ化(後の改善材料)
Step 5(Day 22〜30):効果測定と次フェーズ計画
1ヶ月運用したら、Step 1 で測った初動所要時間が「どれだけ短縮されたか」を測定。同時に、誤分類率・人手介入率・Slack通知精度などをログから集計します。
この時点で効果が見えていれば、次のプロンプト(修繕優先度判定・チェックリスト生成等)を1本ずつ追加していきます。一気に全部入れず、1ヶ月に1機能ずつ追加するペースが、社内の受容度的にちょうどよいです。
第10幕:導入を検討している管理会社へのアドバイス
Aさん:同業の方から「うちもやりたい」と聞かれたら、私は必ず3つ伝えます。
- 「自動返信」ではなく「仕分け補助」から始める。3週間運用して安定してから、返信案ドラフト生成を別途追加するのが安全
- 判定精度100%を求めない。8割で十分。残り2割は人が見る。これを最初に経営陣と握っておかないと、運用前に頓挫します
- 契約解釈・費用確定はAIに任せない。宅建業法・個人情報保護法の制約があるため、AIは「ドラフト生成」「初動仕分け」までに留め、最終判断は必ず人(できれば宅建士)が行う
S:あと技術的なアドバイスを補足すると、Claude Code の CLAUDE.md には「業界用語」「社内ルール」「過去のトラブル事例から得た判定基準」を必ず書き込んでおいてください。汎用 LLM に「不動産管理の問い合わせを仕分けて」と頼むより、CLAUDE.md でドメイン知識を注入した状態の Claude Code のほうが、現場で使える精度が出ます。
第11幕:導入3ヶ月後の数字
導入から3ヶ月経った時点での、Aさんの会社で出た数字を共有します(個別案件の特殊事情を含むため、他社で同じ数字が出るとは限りません)。
- 入居者問い合わせの初動仕分け時間: 1件あたり平均3分→30秒(対象月間700件)
- 修繕優先度判定の検討時間: 1件30分→10分(月間120件)
- 退去立会いチェックリスト準備: 1物件45分→15分(月間50物件)
- 原状回復見積ドラフト作成: 1件3時間→1時間(月間50件)
- 月次巡回レポート作成: 1物件30分→5分(月間100物件)
- 合計削減時間: 月間約70時間(管理担当2名分の月稼働時間に相当)
Aさん:削減した時間で何をしてるかというと、「もっと早く対応できなかった案件のフォローアップ」「オーナー訪問の頻度を上げる」「新規物件の管理委託営業」に回しています。AI で時間が浮いた分、管理会社の本来の付加価値である「人としての対応」に時間を使えるようになりました。
第12幕:技術スタック・実装環境の詳細
「具体的にどんな技術構成で動かしているか」を、業界外のエンジニアでも追体験できるレベルで共有します。
使用したツール・サービス
- Claude Code(Anthropic):ローカル開発機にインストール。プロンプト実行・JSON出力・CLAUDE.md管理の中核
- Claude API:本番運用時は API 経由で呼び出し。レート制限はデフォルト枠で十分賄えた
- Python(3.11):メール本文の前処理(マスキング)・JSON パース・Slack通知の仲介役
- Slack:仕分け結果通知・担当者アサイン・社内コミュニケーション
- Google Sheets:仕分けログの蓄積・週次レビュー資料の自動更新
- git(GitHub Private):CLAUDE.md・プロンプト・前処理スクリプトのバージョン管理
システムの全体フロー
- 入居者からメール受信(管理会社の info@ メールアドレスへ)
- メール受信フックで Python スクリプトが起動
- 本文・送信元情報をマスキング処理(氏名・電話番号・口座番号・号室の一部)
- マスキング済みデータを Claude API に投入(プロンプト1本目=仕分け)
- API から JSON 形式の仕分け結果を受信
- 結果を Google Sheets にログとして書き込み(全件、後の検証用)
- 緊急度に応じて Slack の専用チャンネルに通知(色・タグ付き)
- 担当者が5秒で目視チェック→ Slack のリアクションでアサイン確定
- アサイン後、担当者が問い合わせ元に「人の名前で」返信
運用コストの内訳
- Claude API 利用料: 月額 約3〜5万円(問い合わせ700件+巡回100物件+その他のドラフト生成を含む)
- Slack 既存契約利用: 追加コストなし
- Google Workspace 既存契約利用: 追加コストなし
- 初期実装(Uravation 支援): 3週間分の工数
- 社内人件費(運用工数): AI 仕分けの目視チェックに月10時間程度
セキュリティ・コンプライアンス対応
- API キー管理: 1Password Business で全社員のアクセス権を管理
- マスキング処理: API 送信前に必ず実施。ログにも個人情報は残らない
- 監査ログ: 全 API 呼び出しは Google Sheets と AWS CloudWatch に二重保管
- 個人情報保護方針: 管理委託契約書・入居規約に「業務効率化AI(マスキング処理後)の利用」を明記する方向で次回更新時に反映予定
- 事故時のエスカレーション: AI 起因の誤判定が原因で入居者対応に支障が出た場合の対応フローを社内SLAに明記
第13幕:管理会社のAI活用、これから3年で起きること
Aさんとの最終回の対談で、「3年後どうなってると思いますか」という話をしました。私たちの予測を共有します。
予測1:管理会社の人員構成が変わる
初動仕分け・書類ドラフト・定型レポートが AI で回るようになると、管理会社の人員配置は「初動対応の人」から「最終判断・関係構築の人」へシフトすると考えています。具体的には:
- 新人〜3年目: AI が出した仕分け・ドラフトを検証する「QC担当」
- 3〜7年目: 修繕業者・オーナーとの関係構築、現場判断のコアスタッフ
- 7年目以降: 大口オーナー向けの戦略提案、ポートフォリオマネジメント
「電話対応で1日が終わる」という管理担当のキャリア像が変わり、よりスキル蓄積型・キャリアパス型の業務設計が可能になります。
予測2:オーナーの管理会社選定基準が変わる
今までは「管理戸数」「業歴」「料率」が選定基準でしたが、3年後は「AI 活用によるオーナー報告の質」「データに基づく提案力」が基準に加わります。
例えば、AI で月次巡回レポートを自動生成している管理会社は、オーナーに対して「あなたの物件の状態をデータでこう示せます」と提案できるようになります。これは旧来の管理会社の強みとは異なる軸であり、AI 導入が早い管理会社が新規受託で優位に立つ可能性があります。
予測3:小規模管理会社にもチャンスがある
意外な予測ですが、AI 活用は大手より小規模管理会社のほうがインパクトが大きい可能性があります。理由は、小規模ほど「業界知識の属人化」が強く、ベテランが辞めると業務が回らなくなるリスクが高いから。CLAUDE.md に業界知識を文書化することで、属人化リスクを下げつつ、新人でもベテラン並みの初動が打てるようになります。
大手は既存の業務システムが整っているぶん、AI 統合の意思決定に時間がかかる傾向があります。逆に小規模・中堅は身軽に動けるので、ここでスピード勝負で先行できるかもしれません。
FAQ:よくある質問
Q1. 入居者からの問い合わせをAIが見ることに、入居者の同意は必要ですか?
A. 個人情報保護法の観点では、利用目的を入居規約や管理委託契約書に明示することが望ましいです。今回の実装では、入居規約の改訂(次回更新時)に「業務効率化のためのAI解析(マスキング処理後)」の利用目的を追加する作業を、管理会社の法務担当に並行で進めてもらいました。
Q2. 小規模の管理会社(管理戸数500戸以下)でも導入メリットはありますか?
A. 月の問い合わせ件数が100件を超えるなら、本記事のプロンプト1本目(仕分け)だけでも導入メリットがあります。500戸未満ならClaude Code APIの月額コストも数千円〜1万円程度に収まる規模感です。
Q3. オーナー(貸主)に「AIで管理してます」と説明する必要はありますか?
A. 「AIに業務委託している」のではなく「AIを業務効率化のツールとして使っている」という位置づけなので、業法上の説明義務はありません。ただし、月次レポートが定型的で品質が安定していることをオーナーに評価してもらえると、契約継続・追加委託につながりやすい印象です。
Q4. 外注業者(修繕業者)にAI生成の見積ドラフトを見せてもよいですか?
A. 内部用ドラフトとして「これが当社の現時点の想定です。御社の見積と突き合わせます」という使い方なら問題ありません。ただし「AIが出した数字だからこれで合意してほしい」という押し付けは関係性を損ねます。あくまで「人が判断するための補助資料」として位置づけることが重要です。
Q5. Claude Code の運用コストはどれくらいかかりましたか?
A. 今回の管理会社(管理戸数2,800戸・月間問い合わせ700件・月次巡回100物件)の規模で、Claude API 利用料が月額約3〜5万円、初期実装コストとして佐藤の支援で約3週間分の工数がかかりました。月70時間の削減効果と比較すると、3〜4ヶ月で初期投資を回収できる規模感です。
Q6. 担当者がAIに仕事を奪われると不安を持っています。どう説明すればいいですか?
A. 結論から言うと、「AIに奪われる仕事」と「AIで時間が浮いて新しくできる仕事」を具体的に並べて見せるのが効果的です。Aさんの会社では、AI導入の説明会で「仕分けの時間が浮いた分で、入居者ヒアリングを月10件追加する」「オーナー訪問の頻度を月1回→月2回に増やす」と具体的な新タスクを提示しました。「AIを使う側に回るための研修」を併せて提供すると、担当者の心理的抵抗は大きく下がります。
Q7. 古い管理システムと連携できますか?
A. 多くの管理会社が使っている老舗の管理システム(明光ネットワークジャパン・スマイスター・いえらぶCLOUD等)は、CSV出力やAPI連携機能を持っています。Claude Code 側で受け取る形式に整える前処理スクリプトを書けば、ほとんどのケースで連携可能です。Aさんの会社では、月次巡回データを既存システムからCSVエクスポート→Python前処理→Claude API投入というシンプルな流れで運用しています。
Q8. 「人間の判断は残す」と言いつつ、どこまでAIに任せていいか線引きが曖昧です。
A. 線引きの原則は「業法・法律で人が判断すべきと定められていることはAIに任せない」「金銭が動く最終判定はAIに任せない」「初動の仕分け・ドラフト生成は積極的にAIに任せる」の3つです。具体的には、本記事のプロンプト全てに「厳禁」セクションを設けて、AIに任せない領域を明文化しています。社内ルール化することで、現場で迷うことが減ります。
著者プロフィール
佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。Claude Code・AIエージェント導入支援を100社以上の企業に提供。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆、SBクリエイティブ「ビジネス+IT」レギュラー寄稿。Claude Code 個別指導プログラムを毎月10名限定で運営中。
次のアクション(3つ選んでください)
- まず自社の問い合わせデータを2ヶ月分集計してみる — カテゴリ分布を見ないと、どこから自動化するか決められません。Excel/Google Sheets でカテゴリ・件数・所要時間を記録してから次のステップへ
- 本記事のプロンプト1本目(仕分け)を Claude Code で試運転する — 過去の問い合わせメールを10件程度コピペで投入して、Claude Code がどう仕分けるかを見るだけで、自社業務との相性が分かります
- Uravation の Claude Code 個別指導(無料相談)に申し込む — 自社の管理業務にどう Claude Code を組み込めるか、業界経験のあるコンサルタントと一緒に設計したい場合は、無料相談を活用してください
参考出典
- 国土交通省「原状回復をめぐるトラブルとガイドライン」(再改訂版) – 国土交通省公式
- 個人情報保護委員会「個人情報保護法ガイドライン(通則編)」 – 個人情報保護委員会公式
- 賃貸住宅管理業法(令和3年6月施行)概要 – 国土交通省
- Anthropic公式ドキュメント「Claude API データ取り扱いポリシー」 – Anthropic公式
- Claude Code 公式ドキュメント – Anthropic Claude Code
※本記事は不動産管理会社1社での実装事例をもとにしたものです。法的判断・契約解釈・原状回復費用の確定は、必ず宅建士・弁護士など専門家と協議の上で行ってください。Claude Codeはあくまで業務効率化のツールであり、最終的な意思決定は人が行うべきものです。
