MCPで不動産テックの業務システムを接続する｜2026-07-28仕様と実装パターン6つ

MCPとは、AIと外部システムをつなぐ共通規格のことです。

2026年7月28日、Model Context Protocolの新しい仕様が公開されました。プロトコルの中核が状態を持たない設計に変更され、初期化の手続きとセッションが廃止されるという、公開以来もっとも大きな改訂です。不動産テックの文脈でこれが意味するのは、AIから自社の顧客管理システムや物件マスタを呼び出す実装が、より単純な形で組めるようになったということでした。一方で、古い仕様で作ったサーバーは新しいクライアントと噛み合わない可能性があり、これから作るなら新仕様を前提にすべき局面です。本記事は、宅建業免許（東京都知事(1)第113520号）を保有し、AI導入コンサル100社超の実績を持つ株式会社オルセル（不動産のチカラ運営）の知見をもとに、不動産業務システムのMCP接続を6つの実装パターンで整理します。

2026-07-28仕様で何が変わり、不動産業務に何が効くか

変わったのは、接続の前提です。MCP公式ブログの発表によると、2026-07-28版では初期化の手続きとプロトコル層のセッションが廃止され、すべてのリクエストが自己完結する形になりました。あわせて、複数往復のリクエスト、ヘッダーによるルーティング、一覧結果のキャッシュ、認可の強化、拡張機能の正式な枠組みが導入されています。

この仕様は2026年5月21日にリリース候補として固定され、10週間の検証を経て7月28日に確定版として公開されました。The Registerの報道は、この変更を状態を持つ設計との決別と表現しています。廃止対象となった機能は少なくとも12か月は動作する方針が示されている一方、新仕様のサーバーが古いクライアントで動かない場合がある点は、導入時の確認事項になります。

不動産業務にとって実務的に効くのは、状態を持たない設計になったことでした。従来はAIとシステムの間で接続を維持する必要があり、処理の途中で接続が切れると最初からやり直しになる構造です。1件ずつのリクエストが独立していれば、処理の一部が失敗しても、その1件だけを再実行できます。物件データの一括処理や、複数店舗からの同時アクセスといった不動産業務の使い方と、この設計は噛み合います。

認可の強化も見逃せません。業務システムには顧客情報と契約情報が入っており、誰がどの範囲までアクセスできるかの制御が要ります。プロトコル層で認可の扱いが明確になると、実装側で作り込む部分が減り、設計の抜け穴が生まれにくくなりました。

現場で繰り返し見るのは、この種の規格変更を「技術部門の話」として扱い、業務側が判断に関われない状況です。実際には、どのシステムをAIから呼べる形にするかは業務判断でした。物件マスタは読み取り専用で開放するのか、更新まで許すのか。この判断は技術者には決められません。

不動産テックにおける6つの実装パターン

パターンは、接続先の性質で分かれます。自社が保有するデータか、他社のサービスか、業界システムかで、取れる設計がまったく違います。

第1のパターンが、自社の物件マスタへの読み取り接続です。最も導入しやすく、最初に組むべき構成でした。AIから「この条件の空室を検索して」と呼べる状態を作るだけで、反響対応や提案資料の作成が速くなります。書き込みを含まないため、事故のリスクが小さい。実装も、既存のデータベースに検索用の窓口を1つ足すだけで済みます。

第2が、物件マスタへの書き込み接続です。募集条件の変更、成約フラグの更新、写真の差し替え。ここから権限設計が要になります。読み取りと書き込みを別の道具として定義し、書き込み側には変更幅の制限や承認フローを組み込んでください。同じシステムへの接続でも、読み書きを1つの窓口にまとめるのは避けるべき設計でした。

第3のパターンは、顧客管理システムへの接続です。反響履歴、内見記録、成約履歴。個人情報を含むため、接続の設計で最も慎重さが要る領域でした。実務的な解は、顧客IDと属性情報だけを返し、氏名や連絡先を返さない窓口を作ることです。個人情報保護委員会の考え方に沿って、外部サービスへ個人データを提供する形にならない設計を先に決めてください。

第4が、社内文書への接続です。契約書のひな型、社内規程、業務手順書、過去のトラブル記録。これらをAIから検索できる状態にすると、担当者の質問に対して社内の実際のルールに基づいた回答が返るようになります。文書はファイルサーバーに眠っていることが多く、検索できる形にする前処理が要りますが、投資対効果は高い領域でした。

第5のパターンが、外部サービスへの接続です。地図情報、公的データ、電子契約サービス。国土交通省の不動産情報ライブラリのようにAPIが公開されているものは、MCPサーバーを1つ作って包めば、AIから呼べる道具になります。この種の公的データは利用条件が明示されているため、規約面の確認が比較的容易でした。

第6が、業界システムへの接続です。ここは慎重に扱う必要があります。不動産流通標準情報システムのような会員制のシステムは、会員が業務のために利用する仕組みであり、利用規約の範囲を超えた自動アクセスは認められません。ポータルサイトの入稿システムについても、各社の規約が優先します。技術的に接続できることと、接続してよいことは別問題です。この確認を怠ると、システムの利用停止という事態につながりかねません。

6つのうち、第1から第4は自社が主体的に判断できる領域、第5は規約の確認が容易な領域、第6は規約の制約が強い領域という整理になります。導入の順序も、この順が安全でした。

物件マスタのMCPサーバーを設計する

設計で決めるのは、道具の粒度、返す情報の範囲、権限の3点です。

道具の粒度は、細かすぎても粗すぎても使いにくくなります。「物件を検索する」という1つの道具に、賃貸も売買も管理物件も全部詰め込むと、AIが条件を組み立てられません。逆に「駅から徒歩5分以内の1LDKを検索する」のように細かく分けると、道具の数が爆発します。現場で落ち着いたのは、物件種別ごとに1つ、検索条件はパラメータで受ける、という粒度でした。

返す情報の範囲は、業務に必要な最小限に絞ってください。物件マスタには内部管理用の項目が多数含まれており、それをすべて返すとAIの判断が散漫になります。加えて、オーナー情報や仕入れ原価といった社外に出せない情報が混ざるリスクもある。窓口の側で返す項目を明示的に列挙する設計が、安全でした。

権限については、道具の実装側で制限をかけるのが原則です。指示文で「賃料の変更は5%以内」と書いても、その制約は破られる可能性があります。窓口の実装で変更幅を検証していれば、破られません。以下は、物件マスタの窓口を設計するときの検討項目をAIに整理させるプロンプトです。

プロンプト1：物件マスタ接続の設計レビュー

あなたは不動産テックのシステム設計者です。以下の物件マスタについて、AIから呼び出す窓口の設計案をレビューしてください。

物件マスタの項目一覧：
{列名と説明を列挙}

想定する用途：
{反響対応／提案資料作成／条件変更／棚卸し など}

レビューの観点：
1. AIに返すべき項目と、返すべきでない項目の区分
2. 読み取り用と書き込み用に分けるべき操作
3. 書き込み操作に設けるべき制限（値の範囲、件数の上限、承認が要る条件）
4. 個人情報・オーナー情報・原価情報が漏れる経路
5. 検索条件として受け付けるべきパラメータ

出力：
項目／推奨／理由／リスク

制約：
- 「返すべきでない」と判定した項目には、その理由を業務上のリスクで説明すること
- 権限の制限は、指示文ではなく実装側でかけるべきものを明示すること

窓口を作ったあとは、実際にAIから呼んでみて挙動を確認します。ここで見るべきは、AIが道具の説明を正しく解釈しているかでした。道具の説明文が曖昧だと、AIが想定と違う使い方をします。「該当がない場合は空の配列を返す」「日付は西暦8桁で受ける」といった仕様を、説明文に明記してください。

プロンプト2：道具の説明文の点検

以下は、AIから呼び出す道具の説明文です。AIが誤解しうる箇所を洗い出してください。

道具の説明文：
{貼り付け}

点検の観点：
1. 引数の形式が曖昧な箇所（日付、金額、単位など）
2. 該当データがない場合の挙動が書かれていない箇所
3. エラー時に何が返るか書かれていない箇所
4. 副作用（データが書き換わる、通知が飛ぶなど）が明示されていない箇所
5. 似た名前の他の道具と混同しうる箇所

出力：
該当箇所／誤解の可能性／修正案

接続で事故が起きる3つの経路

1つ目が、権限の抜け穴です。読み取り用の窓口と書き込み用の窓口を分けたつもりでも、書き込み用の窓口に検索機能が付いていると、そこから制限を迂回できてしまう。窓口ごとに「この操作でデータが変わるか」を明示し、変わる操作には例外なく制限をかけてください。

2つ目が、大量アクセスです。AIが繰り返し呼び出す設計では、想定外の回数のリクエストが飛ぶことがあります。自社システムなら負荷の問題で済みますが、外部サービスへの接続では規約違反や利用停止につながる。窓口の側で呼び出し回数の上限を設け、上限に達したら明確なエラーを返す実装にしてください。回数制限は、実装の初期から入れるべき機能でした。

3つ目が、個人情報の意図しない露出です。窓口が返す項目を絞ったつもりでも、備考欄やメモ欄に氏名や連絡先が書かれていることがあります。項目名で絞るだけでは不十分で、自由記述欄の扱いを別途決める必要がありました。実務的な解は、自由記述欄を返さない設計にするか、返す前に個人情報らしき文字列を除去する処理を挟むことです。

規約面の確認も、実装前に済ませてください。業界システムやポータルサイトへの接続は、技術的に可能でも規約上認められないケースが大半です。不動産×AI導入コンサルの現場で繰り返し確認したパターンとして、技術検証が先行して規約確認が後回しになり、動くものができてから使えないと判明する、という順序の失敗がありました。規約確認を設計の第1工程に置いてください。

既存システムがAPIを持っていない場合の進め方

不動産会社の現場でよく直面するのが、使っている業務システムに外部から呼べる窓口がない状況です。パッケージ製品をそのまま使っており、データベースに直接触れない。この場合、取れる手は3つあります。

第1の手が、ベンダーへの相談です。近年は多くのベンダーがAPI提供を検討しており、要望として伝えることに意味があります。同種の要望が複数の顧客から出れば、製品側の対応が進む。これは時間がかかる手ですが、最も筋の良い経路でした。相談するときは「AIと接続したい」という抽象的な要望ではなく、「物件の空室状況を外部から参照したい」のように具体的な用途で伝えると、話が進みやすくなります。

第2の手が、エクスポート機能を経由する方法です。多くの業務システムにはCSV出力の機能があります。日次でエクスポートしたファイルを別の場所に置き、そこにMCPの窓口を作る。リアルタイム性は失われますが、日次で足りる用途は少なくありません。物件の棚卸しや、月次の集計はこの方式で十分でした。ただし、エクスポートしたファイルに個人情報が含まれる場合、その保管場所の管理が新たな論点になります。

第3の手が、システムの入れ替えです。これは大きな決断ですが、既存システムが古く、他の面でも制約になっているなら、この機会に検討する価値があります。選定の際は、外部から呼べる窓口があるかを確認項目に加えてください。2026年以降に選ぶ製品では、この点が数年後の選択肢の広さを左右します。

現場感覚では、多くの会社が第2の手から始めています。すぐに動かせて、投資も小さい。そこで効果を確認してから、ベンダーへの相談や入れ替えの検討に進む順序が現実的でした。最初から完璧な接続を目指すと、着手そのものが遅れます。

導入の費用と期間

費用の中心は開発工数です。物件マスタの読み取り窓口1つで、既存システムの構造が整理されていれば2〜5人日。顧客管理システムを含む複数システムの接続になると、20人日を超えることもあります。既存システムがAPIを持っているかどうかで、この幅が決まりました。

期間としては、規約確認と設計に2週間、実装に2〜4週間、検証に2週間という配分が現実的です。実装より、その前後の工程に時間がかかります。特に、どの情報をAIに渡すかという判断は業務側の合意が要るため、関係部署との調整が入ると期間が延びます。

保守についても見込んでおく必要があります。MCPの仕様は2026年7月に大きく変わったように、今後も更新されます。廃止される機能は12か月の猶予が示されていますが、追随の作業は発生します。年に1回程度、仕様の変更に対応する工数を予算に入れておいてください。

投資判断の材料としては、接続によって何時間の業務が短縮されるかを先に見積もってください。窓口を作ること自体は目的ではなく、その先の業務自動化が目的です。接続だけ作って使わない状態は、実際に起きます。

規格の統一が進むと、不動産テックの何が変わるか

変わるのは、システム選定の基準です。これまで製品を選ぶとき、機能の豊富さと価格が主な比較軸でした。接続規格が定着すると、「外部から呼べるか」が新しい軸として加わります。機能が優れていても閉じている製品は、AIを前提とした業務設計に組み込めません。

不動産テック各社にとっては、戦略の分岐点になります。自社製品を外部から操作できる形で開放すれば、他社のエージェントから呼ばれる部品として使われる可能性が広がる一方、自社で業務全体を抱え込む戦略は取りにくくなる。この判断が、2027年に向けた各社の立ち位置を決めていくと見ています。

不動産会社側の準備は、自社データの整理でした。接続の窓口を作っても、その先のデータが古かったり表記がばらついていたりすると、AIの判断品質が上がりません。物件マスタの正規化、顧客情報の重複整理。この作業は、どの規格が普及するかとは無関係に効いてきます。

推測を含む見立てを書いておくと、規格の統一で恩恵が大きいのは、複数のシステムを併用している中規模の会社だと考えています。大手は自社開発で統合しており、零細はシステムの数自体が少ない。3つから5つのシステムを併用し、その間の連携に手作業が挟まっている規模帯が、最も効果を実感できる位置にありました。

よくある質問

MCPとは何ですか

MCPとは、AIと外部システムをつなぐための共通規格のことです。従来はAIごと、システムごとに個別の接続を実装する必要がありましたが、共通規格に対応すれば1つの窓口を複数のAIから呼べるようになります。2026年7月28日に大きな仕様改訂が行われました。

2026-07-28の仕様変更で何が変わりましたか

プロトコルの中核が状態を持たない設計に変わり、初期化の手続きとセッションが廃止されました。あわせて複数往復のリクエスト、ヘッダーによるルーティング、一覧結果のキャッシュ、認可の強化が導入されています。廃止された機能は少なくとも12か月は動作する方針が示されています。

古い仕様で作ったサーバーは使えなくなりますか

すぐに使えなくなるわけではありませんが、新仕様のクライアントと噛み合わない可能性があります。廃止対象の機能には12か月以上の猶予が示されているため、その期間内に移行を計画してください。これから新規に作る場合は、新仕様を前提にすることをおすすめします。

レインズやポータルサイトに接続してもいいですか

いいえ、会員制の業界システムやポータルサイトは、各システムの利用規約が優先します。規約の範囲を超えた自動アクセスは認められません。まずは自社が保有する物件マスタや顧客管理システムとの接続から始めてください。

最初にどのシステムから接続すべきですか

自社の物件マスタへの読み取り接続が最初の1本に向きます。書き込みを含まないため事故のリスクが小さく、実装も既存のデータベースに窓口を1つ足すだけで済みます。この1本で効果を確認してから、書き込みや他システムへ広げてください。

個人情報を扱うシステムに接続しても問題ありませんか

窓口の設計次第です。顧客IDと属性情報だけを返し、氏名や連絡先を返さない設計にすれば、外部サービスへの個人データ提供という論点自体を小さくできます。備考欄などの自由記述欄に個人情報が混ざる点にも注意してください。

開発にどのくらいの期間と費用がかかりますか

物件マスタの読み取り窓口1つで2〜5人日が目安です。複数システムの接続になると20人日を超えることもあります。期間は規約確認と設計に2週間、実装に2〜4週間、検証に2週間という配分が現実的でした。

参考文献

不動産テックの動向は不動産テックカテゴリにまとめています。接続先のエージェント設計についてはClaude Sonnet 5で業務エージェントを構築する記事、導入の全体像はAIエージェントによる不動産業務の自動化をあわせてご覧ください。

著者：齋藤竹紘（株式会社オルセル編集長／EC支援19年5,000社超／AIコンサル100社超／宅建業免許東京都知事(1)第113520号）

※不動産のチカラでは、生成AIの導入支援から運用最適化まで、貴社の不動産事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://fudosannochikara.jp/contact/

【監修】齋藤竹紘（株式会社オルセル代表 / 宅建業免許東京都知事(1)第113520号 / AI導入コンサル100社超）