この記事は、不動産会社の事業責任者や、自社サイトを担当している方に向けて書いています。WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を、物件検索・内見予約・問い合わせの場面で使うとしたら、何をAIに開き、何を人が持ち続けるのか。読み終えると、その仕分けの考え方と、最初に試す範囲を決められるようになります。
先にお伝えしておくと、WebMCPは草案の段階です。W3C（Web標準を決める団体）の標準ではなく、W3CのWeb Machine Learning Community Groupが公開している仕様草案です。Chromeでは、オリジントライアル（期間限定の試験提供）として使えます。記事の内容は2026年10月20日時点の確認に基づき、今後変わる可能性があります。
全体像はWebMCPの入門記事にまとめています。先にそちらを読むと、用語がつかみやすくなります。
不動産サイトで、WebMCPが関係しそうな場面
WebMCPの基本は、サイトが「名前・説明・入力項目の定義・実行する処理」をひとまとめにしたツールを用意し、ブラウザ内のエージェントがそれを呼ぶ、というものです。エージェントは、画面を読み取ってクリックする代わりに、ツールを使えます。
Chromeの公式資料には、使いどころの例として「絞り込みと予約」が挙がっており、その中に賃貸とホテルが含まれています。つまり、条件を伝えて候補を絞り、予約や問い合わせに進む流れは、資料が想定している典型的な場面の一つです。不動産サイトの物件検索から問い合わせまでの流れとも、よく重なります。
ただし、資料に書かれているのは例の紹介までです。不動産業に向けた手順や、業法への対応方法は書かれていません。この記事も、業種固有の法令には踏み込みません。法令に関わる点は、専門家に確認してください。
仕様の位置づけも押さえておきます。人間向けの画面が主役であることは変わらず、WebMCPはそれを補うものです。Chromeの資料も、ローカルのブラウザで人が関わる使い方（human in the loop）を主に想定していると述べています。
AIに開く操作の候補
ここからは、考え方をつかむための架空の例です。実在の会社やサイトとは関係がありません。「架空の不動産会社」が、自社サイトの操作をAIエージェントに開くとしたら、どんな候補があるかを表にしました。
| 操作（架空の例） | 性質 | 付けられる注釈 | 扱いの考え方 |
|---|---|---|---|
| エリア・賃料・間取りで物件を検索する | 読み取りのみ | readOnlyHint | 最初に試す候補。結果の鮮度に注意する |
| 検索結果を条件で絞り込む | 読み取りのみ | readOnlyHint | 画面の表示も更新して、人が確認できるようにする |
| 気になる物件を並べて比較する | 読み取りのみ | readOnlyHint | 表示項目は公開済みの情報に限る |
| 内見の日程の候補を出す | 読み取りのみ | readOnlyHint | 空きの情報が古くならないようにする |
| 内見の希望を送る | 状態を変える | consequentialHintを検討 | 送信前に人が内容を確かめる |
| 問い合わせの下書きを作る | 状態を変える（起票） | consequentialHintを検討 | 送信は人が押す形が無理のない出発点 |
注釈とは、ツールに添えるヒントのことです。W3Cの草案には、読み取りのみを示すreadOnlyHint、返す内容が信頼できない可能性を示すuntrustedContentHint、実世界への影響や取り消せない操作を示すconsequentialHintがあります。いずれも初期値は「いいえ」です。クライアント（エージェントを動かす側）は、これらを手がかりに確認を求められますが、草案はユーザーへの確認を必須とは定めていません。ですから、確認の仕組みは自社でも用意しておく必要があります。
ツールの切り分け方は、WebMCPのツール設計の記事が参考になります。Chromeの資料も、1つのツールは1つの機能にして、重複させないことを勧めています。
物件検索：条件を伝えて、絞り込む
最初の候補は、物件検索です。読み取りが中心で、リスクが比較的低いからです。
Chromeの資料は、ツールを作る手順の一つとして、利用者が実際に話す言葉でやり取りを想定してみること（ロールプレイ）を挙げています。架空の例で考えてみます。
- 利用者「駅から歩ける範囲で、家賃は抑えめ、二人で住める部屋を探したい」
- エージェントは、曖昧な部分を推測せず、足りない条件（エリア、賃料の上限など）を利用者に尋ねる。
- 条件がそろったら、検索ツールを呼ぶ。結果が出たら、さらに絞り込みのツールを使う。
資料は、曖昧な依頼に備えて、推測せずに足りない引数を尋ねられる設計にするよう述べています。また、結果が0件のときは、条件を変えるよう促す返答を返すとよい、という趣旨の例も示しています。「見つかりません」だけで終わらせない、ということです。
入力項目の作り方では、自然言語に近い値が勧められています。たとえば、間取りを内部のコード番号で受けるより、利用者が口にする言葉に近い値で受けるほうが、エージェントは扱いやすくなります。また、資料は「検証はコードで厳しく、スキーマでは緩く」という考え方を示しています。入力の定義を厳しくしすぎてエージェントが止まらないよう、実行する側のコードで確かめ、直し方が分かるエラーを返す設計です。
比較と内見の日程候補
候補が絞れたら、比較に進みます。比較ツールは、公開済みの物件情報を並べて返すだけなら、読み取りのみの操作です。どの項目を並べるかは、人が画面で見るときと同じ範囲にとどめると、考えが整理しやすくなります。
内見の日程候補は、少し注意が要ります。空きの情報は、時間とともに変わるからです。日程候補を返すツールには、「いつの時点の情報か」を結果に添える、確定ではなく候補であると明記する、といった工夫が考えられます。確定は、担当者との確認を経て人が行う形が、無理のない設計です。
Chromeの資料は、ツールの「開始」と「実行」を動詞で区別するよう勧めています。たとえば、予約を即座に作るツールと、予約の手続きに誘導するツールは、名前から違いが分かるようにします。内見でいえば、「日程の候補を調べる」と「内見の希望を送る」は、別のツールにするのが安全です。
問い合わせの起票：送信は人が押す
問い合わせの入力は、エージェントが力を発揮しやすい場面です。長いフォームを埋める作業は、利用者にとって負担になりがちだからです。Chromeの資料も、長いフォームの入力を使いどころの一つに挙げ、既存のフォームがあれば2ステップでツールにできると述べています。
Chromeの資料で紹介されている宣言的API（HTMLのフォームに注釈を付けてツールにする方式）では、フォームにtoolnameとtooldescriptionを付けると、ツールとして登録されます。エージェントが呼ぶと、ブラウザがフォームの項目を入力し、フォームは利用者に見える状態のままです。既定では、利用者が送信ボタンを押して完了します。toolautosubmitという属性を付けると自動送信にできますが、問い合わせのように相手に届く操作では、人が押す形にしておくのが堅実です。
なお、この宣言的APIは、Chromeの資料では紹介されていますが、W3C草案の本文には、2026年10月時点でまだ含まれていません。ここは両者で扱いが違うので、混同しないようにしてください。
問い合わせの内容には、個人情報が含まれます。何を項目に含めるか、どこまでエージェントに渡すかは、個人情報の取り扱いに関わるので、専門家に確認しながら決めてください。草案も、過剰なパラメータによるプライバシー漏えいを、リスクとして挙げています。
人が持つべき判断
エージェントに任せる範囲を広げるほど、「ここは人が持つ」という線引きが大切になります。不動産の取引には、重要な説明や契約など、専門性と責任を伴う場面があります。これらを担う範囲や、そこに適用される法令（宅地建物取引業法など）の扱いは、この記事では判断できません。専門家に確認してください。そのうえで、整理の軸は次のとおりです。
| 場面（架空の例） | エージェントに任せやすい | 人が持つ |
|---|---|---|
| 物件探し | 条件の聞き取り、検索、絞り込み、比較表の作成 | 物件の説明の正確さ、最新の状況の確認 |
| 内見 | 日程候補の提示、希望の下書き | 日程の確定、案内の可否の判断 |
| 問い合わせ | 項目の入力、下書きの作成 | 内容の最終確認と送信、返信 |
| 契約・重要な説明 | （ツールとして開かない） | すべて人が担当する |
契約や重要事項に関わる操作は、最初からツールとして開かない、という選択も立派な設計です。ツールを減らすことは、リスクを減らすことにつながります。草案も、ツールの数は文脈量に制約されると述べ、動的な登録を勧めています。
人の確認の設計は、人の確認に関する記事で詳しく扱っています。Chromeの資料によれば、購入などの重要な操作では、ユーザーに確認ダイアログを出す指示を含められます。これを参考に、起票や希望の送信の前に、内容を人が見る段階を置けます。
情報の鮮度と、おとり広告を避ける注意
不動産サイトで特に気をつけたいのは、情報の鮮度です。エージェントは、サイトが返した情報をそのまま利用者に伝えます。成約済みの物件や、条件が変わった物件が、検索結果に残っていると、利用者に誤った期待を持たせてしまいます。
おとり広告のような問題は、法令や業界の規約に関わる話です。この記事では、規制の中身には触れません。どの表示が問題になるかは、専門家に確認してください。ここでは、技術と運用の面で、情報を新しく保つための考え方だけを挙げます。
- ツールが返す結果に、情報の更新時点を添える。
- 成約済み・募集停止の物件は、ツールの結果から除く。画面と同じ元データを使い、ツール専用の古い複製を作らない。
- 鮮度の確認を誰が、どの周期で行うかを決めておく。
- 結果に「最新の状況は担当者に確認してください」と促す案内を入れることを検討する。
もう一点。草案は、ツールの宣言と実際の動作が一致する保証がない点をリスクとして挙げています。たとえば、名前が「候補を調べる」なのに、裏で希望を送ってしまうようなことがあってはいけません。名前・説明・動作は、そろえておきます。
よくある失敗
- 最初から広く開けすぎる。検索、比較、内見、問い合わせ、さらに契約まわりまで一気に開くと、確認すべきことが膨らみます。まずは読み取り系の少数から。
- 古い情報を返す。画面とツールで元データが違うと、食い違いが生まれます。
- 送信まで自動にする。相手に届く操作は、人が最後に確認する形が基本です。
- エラーが不親切。「失敗しました」だけでは、エージェントが立て直せません。何が足りないか、次に何をすればよいかを返します。
- 試さずに公開する。ChromeのDevToolsでは、ツールの一覧を確認し、手動で実行できます。エージェントが意図どおりにツールを選ぶかは、実際に確かめます。
- 個人情報を多く求める。必要以上の項目は、利用者の不安にもつながります。
最初の一歩
- 操作を書き出す。自社サイトで利用者ができる操作を、検索・比較・内見・問い合わせなどに分けて書き出します。
- 仕分ける。読み取りのみ、状態を変える、人が担当する、の三つに分けます。
- 読み取りから試す。物件検索と絞り込みから始め、Chromeのテスト環境（chrome://flags/#enable-webmcp-testing とDevTools）で動きを確かめます。
- 鮮度の運用を決める。情報を新しく保つ担当と周期を決めます。
- 確認の流れを置く。起票や送信の前に、人が内容を見る段階を設計します。
- 専門家に確認する。個人情報、表示、業法に関わる点は、公開前に確認します。
AIエージェントに向けた準備の全体は、AIエージェント対応サイトのチェックリストも参考にしてください。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- この記事の例は架空です。実在の会社・サイト・実績とは関係がなく、効果を示すものでもありません。
- 法務・個人情報・業法は専門家に確認してください。この記事は、これらについて判断を示すものではありません。
- プロンプトインジェクションに注意が必要です。ツールの説明や出力に紛れた悪意ある指示で、エージェントが意図しない動きをする危険があります。物件の備考欄など、利用者や外部が書いた内容を返すツールには、untrustedContentHintの利用を検討してください。
Otsumuに相談できること
操作の書き出しと仕分けは、社内で始められます。サイトでできる操作を、読み取りのみ・状態を変える・人が担当、に分けるだけでも、方針が見えてきます。
そのうえで、ツールの設計、情報の鮮度を保つ仕組み、人の確認の流れなどは、実装との兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築を支援しており、サイトを「AIが使える形」にする設計もご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20