賃貸管理ソフトがAIと繋がりました、というニュースは去年から何度も流れてきます。
ただ、どれが本当に動いていて、どれが構想止まりなのかは、記事を読んでも分かりません。
海外の主要サービスについて公式の一次情報を1本ずつ当たってみたら、実態はきれいに分かれました。
海外の大家はどこまで賃貸管理をAIに任せているのか
MCPは、AIに外部のデータやツールを触らせるための接続規格です。
賃貸管理ソフトにこれが刺さると、何が起きるのか。
「先月の滞納を一覧にして」「更新が近い部屋の賃料を近隣と比べて」と話しかけるだけで、管理ソフトの中の数字をAIが直接読んで返してきます。
管理画面を開いてCSVを落としてスプレッドシートに貼る、という手順が丸ごと消えるわけですね。
ここまで聞くと全部のソフトがもう繋がっていそうに思えますが、実際に確認していくと様子が違いました。
当初の候補に入れていたRentRediは、公式サイトにもヘルプにもAIやMCPの記載が一切なく、公開APIすら見つからなかったので調査の途中で落としています。
代わりに入ったのが、いちばん堅い1本でした。
公式に動いているのは、6本のうち1本だけでした
Yardiです。
米国の大手不動産管理ソフトで、自社のAI基盤であるVirtuosoにClaude向けのコネクタを載せています。
重要なのは、これがAnthropic検証済みのコネクタとしてClaude側の一覧に掲載されている点ですね。
第三者が勝手に作ったものではなく、Yardi自身が出している公式の接続です。
できることは、作業依頼の管理やデータ検索を含む5つの機能で、財務モデルやメンテナンスの見通し、ポートフォリオの情報を自然言語で引き出せます。
書き込みで暴れるタイプではなく、読み取りと照会が中心の設計です。
対象は投資・物件・資産の管理に関わるプロ向けで、個人の大家が契約して使えるものではありません。
それでも見ておく価値があるのは、「管理ソフトの中の数字を、会話でそのまま引く」という形が、実運用に耐える水準で成立していることの証明だからです。
AppFolioのRealm-Xは公式でも、まだ登録制のベータ
AppFolioも公式です。
こちらはRealm-Xという自社のAI機能をClaudeに繋ぐ構成で、Anthropic側の事例ページにも載っています。
ただ、2026年6月のカンファレンスでお披露目された早期アクセスの段階で、登録した会社から順に使える形です。
誰でも今日から使えるわけではない、というのがYardiとの違いですね。
数字は具体的に出ています。
入居者とのやり取りを扱うRealm-X Messagesで、AIが提案した返信は50万件を超え、返信1件あたり平均26秒が短縮されました。
物件管理の担当者ベースでは、コミュニケーション業務が週あたり約11時間減ったとされています。
1件26秒と聞くと小さく見えますよね。
ただ入居者対応は件数で殴ってくる業務なので、週11時間という数字のほうが実感に近いはずです。
BuildiumとRentCastは非公式でも、土台の公式APIが強い
ここから層が変わります。
Buildiumは、ソフト自体はOpen APIを公開していますが、MCPサーバーを出しているのはBuildiumではありません。
第三者が公式のAPI仕様から組み上げた luthersystems/mcp-server-buildium というリポジトリがあり、81個のツールを備えています。
READMEに「Buildiumとは無関係のコミュニティ実装」「実験段階でSLAなし」と自分から書いてあるタイプですね。
前提として、土台のOpen APIはPremiumプラン以上でしか使えません。
Buildiumの料金はEssentialが月62ドル(約9,300円)、Growthが月192ドル(約28,800円)、Premiumが月400ドル(約60,000円)です。
為替は概算ですが、つまりAIに繋ぐ入口の時点で月6万円のプランが前提になります。
RentCastは毛色が違って、管理ソフトではなくデータ提供側です。
物件情報、賃料の推定、市場統計を返す公式APIがあり、無料枠は月50コールまで。
これを叩く非公式のMCPサーバーが複数公開されていて、robcerda/rentcast-mcp-server あたりが代表的です。
この2本に共通するのは、MCPの部分が壊れても土台のAPIは公式なので、繋ぎ直せば済むという点ですね。
非公式だから危ない、ではなく、非公式なのはどの層なのかを見るほうが実用的です。
StessaとZillowに、公式の接続はまだありません
Stessaは個人大家向けの無料の収支管理ツールとして人気ですが、公開APIを持っていません。
出回っている非公式クライアントは、Webアプリの内部エンドポイントを解析して叩く作りで、作者自身が「Stessa側の仕様変更で壊れる可能性がある」と注意書きを添えています。
公式コミュニティにはMCPエンドポイントとClaude連携を求める要望スレッドが立っていますが、Stessaからの対応表明はまだ出ていません。
要するに、今は要望の段階です。
Zillow Rental Managerはさらに手前でした。
賃貸領域の公式APIがなく、公式のMCPサーバーも存在しません。
「Zillow MCPサーバー」として見つかるものはスクレイピング実装で、Zillowが関与しているわけではありません。
自分の物件データを扱うならともかく、規約の解釈が必要な領域なので、業務の基盤に据えるのはおすすめしません。
6本を並べ直すと、信じてよい順番が見えます
では、どこで線を引けばいいのか。
見るべきはMCPサーバーの有無ではなく、その下に公式のAPIがあるかどうかです。
公式APIの上に乗っているものは、接続が壊れても直せます。
内部エンドポイントやスクレイピングに乗っているものは、相手がページを1枚変えた翌朝に止まります。
海外の大家が本当に日常業務で回せているのは、上の2行までと考えたほうが実態に近いです。
日本の賃貸管理に移植できる工程、できない工程
ここまでの6本、日本の大家は1つも契約できません。
いずれも米国市場向けで、物件データも賃料統計も米国の話です。
ではこの棚卸しに意味はないのかというと、構造だけは持ち帰れます。
家賃相場と更新判断は、自前のSkillで再現できます
RentCastがやっているのは、物件の属性を入れると周辺の賃料推定と市場統計が返ってくる、という1点です。
同じ構造を手元で作るなら、材料は公開ポータルの募集事例、管理会社からの月次報告、自分の過去の成約条件で足ります。
それらを1つのフォルダに集めて、Claude Skillとして手順を固定してしまう。
「この部屋、更新時に賃料を据え置くか上げるか。近隣の募集事例と自分の過去2回の更新を踏まえて根拠つきで」と聞けば、毎回プロンプトを書き直さずに同じ質の答えが返ってきます。
入居者への文面も同じです。
更新の案内、設備不具合の一次返信、原状回復の説明。
このあたりは相手の制度にも信用情報にも依存しないので、AppFolioが1件26秒を削っているのとほぼ同じことが、個人の規模でも起きます。
入居審査と送金は、今の日本では任せられません
逆に移植できないのがこの2つです。
日本の入居審査は、実務上は家賃保証会社の審査が判断の中心にあります。
大家の手元にあるのは結果の可否で、判断ロジックそのものではありません。
そこにAIの独自スコアを重ねても、保証会社の審査が通らなければ意味がなく、応募者の属性を機械的に扱うこと自体に個人情報と公平性の論点がついて回ります。
私は申込書の記載内容を整理させるところまでで止めていて、可否の判断そのものはAIに出させていません。
送金も同じです。
海外のツールが当たり前に持っている家賃のオンライン集金は、日本だと管理会社と保証会社の口座を経由する前提なので、そもそも大家の側に繋ぐ口がありません。
ここを無理に自動化しようとすると、効率化ではなく事故になります。
区分大家が今週やる棚卸しの手順
では、今週何から手を付けるか。
やることは3つです。
- 手元のデータがどこにあるかを紙1枚に書き出す。管理会社の月次PDF、会計ソフト、募集サイトの反響数、どれがどこにあるかを並べるだけで十分です
- この1か月で自分が繰り返し聞いたことを思い出す。同じ質問を2回以上しているなら、それがSkillにすべき1本です
- 賃料と更新から始める。相場と更新判断は材料が手元で揃う数少ない工程なので、成果が早く出ます
海外のツールを羨ましがる話ではないんですよね。
向こうが公式コネクタでやっているのは、散らばった数字を1つの入口から引くことだけです。
区分1戸から数戸の規模なら、その入口はフォルダ1つで作れます。





コメント
ログイン か 会員登録 するとコメントできます