「物件ページにも構造化データを入れておいて」と言われて、Googleの公式ドキュメントを開いた。ところが、記事にもレシピにも求人にも型があるのに、肝心の「物件」だけ見つからない。
探し方が悪いのだろうかと、しばらく一覧を往復した経験のある方は、少なくないのではないかと思います。
結論から言うと、見つからないのは探し方のせいではありません。Googleが公開している構造化データの一覧に、住宅・オフィス・店舗の物件を対象にした専用の型は含まれていないからです。
この記事は、賃貸仲介・売買仲介・新築分譲を手がける不動産事業者のWeb担当者を想定して書きました。専用の型が無いという前提の上で、AIO（AI検索最適化。海外ではLLMOとも呼ばれます）として今日から何に着手できるのかを、図解と会話でやさしく整理していきます。
こんなふうに調べていませんか
- 「不動産 構造化データ」で調べたが、物件の型がどこにも見当たらない
- 上司から「AI Overviewsに物件を出せるようにして」と言われて困っている
- RealEstateListingという型を見つけたが、入れてよいのか判断できない
この記事を読み終えたときに手に入るもの
- 不動産物件専用の構造化データが無いという事実を、社内に説明できるようになります
- Vacation Rentalが自社に使える型かどうかを、その場で判断できます
- 今日から着手できる手順が、順番どおりに分かります
結論30秒でわかる、この記事の結論
- 不動産物件を対象にしたGoogle公式の専用構造化データは、公開されている一覧に存在しません。
- 物件そのものを扱える唯一の型はVacation Rentalですが、適用条件が限られており、一般的な売買・賃貸物件には使えません。
- 今日着手できるのは、RealEstateAgentの実装と、物件スペックを表形式で明記する情報設計です。専用の型を待つ必要はありません。
この記事では、不動産会社のWeb担当・若葉さん（入社2年目）と高梨課長、そしてAIO/SEOの専門家である本誌監修の鈴木さんの会話をはさみながら進めます。まず前提の確認から入り、後半で実装の順番へ進みます。
01そもそも不動産のAI Overviews対策とは、AI検索で構造化データを何に使うことですか？
若葉さん鈴木さん、物件ページ用の構造化データを探しているんですが、どうしても見つからなくて……。私の探し方が悪いんでしょうか。
鈴木さんいえ、探し方は合っています。そもそも用意されていないんですよ。まずは、構造化データがAI Overviewsの中でどういう位置づけなのかから整理しましょうか。
Google公式のAI最適化ガイドは、AI機能に表示されるための追加要件は無く、特別な最適化も不要だと明記しています（出典: Google公式）。条件として挙げられているのは、Google検索でインデックス化され、スニペット表示に適格であることだけです。
AI Overviews自体も、Google検索のコアランキング・品質システムを土台としています。構造化データは必須ではないと、公式に明記されています（出典: Google公式）。
不動産のAI Overviews対策とは、専用スキーマの有無にかかわらず、物件情報を通常検索と同じ品質基準の中で機械可読に示す取り組みです。
不動産業界の場合、この一般原則の上に「専用スキーマが存在しない」という業界特有の制約が重なります。制約はありますが、土台のほうは他業種とまったく同じです。ここを取り違えると、必要のない探しものに時間を使うことになります。
この章のまとめ
不動産のAI検索対策も、土台は通常検索と同じです。違うのは、物件を表す専用の型が無いという1点だけです。
02「不動産物件の専用スキーマが無い」というのは、AI検索対策として本当ですか？
Google公式の構造化データ一覧（Search Gallery）には、約30種類の型が掲載されています（出典: Google公式）。内訳は記事・パンくずリスト・イベント・レシピ・商品・求人・ローカルビジネス・動画などです。
この一覧に、住宅・オフィス・店舗の物件情報を対象にした専用の型はありません。
不動産に関係する範囲を整理すると、次の3つに分かれます。
| 分類 | Google構造化データでの扱い |
|---|---|
| 住宅・オフィス・店舗の売買/賃貸物件 | 専用の構造化データ型なし（一覧に含まれない） |
| 短期宿泊施設（バケーションレンタル） | Vacation Rental対応（Hotel Center提携が前提） |
| 不動産仲介業者そのもの | LocalBusiness系のRealEstateAgent型で表現可能（schema.org） |
この3区分のうち、Googleのリッチリザルトとして実際に機能するのは、仲介業者の情報と、限定的な短期宿泊施設だけです。 物件そのものの情報を対象にした構造化データは、現時点で存在しません。
つまり「物件の型を探す」という作業は、はじめから空振りが確定しています。ここに気づくのが早いほど、着手も早くなります。
この章のまとめ
探しても見つからないのは、無いからです。不動産のAI対策は、専用の型を待たずに組み立てられます。
03Vacation Rentalは、不動産のAI検索最適化に使える型なんですか？
高梨課長唯一、物件そのものを扱える型があると聞きました。うちでも使えるものでしょうか。
鈴木さんVacation Rentalですね。短期宿泊施設向けに設計された型なので、そこがまず前提になります。あと、参加そのものに条件があるんですよ。
Vacation Rentalへの参加には、事前の提携が前提条件として明記されています（出典: Google公式）。具体的には、Google Technical Account Managerとの連携と、Hotel Centerへのアクセス権が必要です。
参加できるのは、一定の適格条件を満たすサイトに限られる早期採用者プログラムです（出典: Google公式）。
短期宿泊事業（民泊・マンスリーマンションなど）をすでに併営している場合は、適用の可否を確認する価値があります。一方で、併営していない一般的な不動産事業者にとっては、現実的な経路ではありません。
この章のまとめ
Vacation Rentalは短期宿泊施設のための型です。併営していないなら、判断は「使わない」で確定させて構いません。
04schema.orgのRealEstateListingは、構造化データのAIO対策として今すぐ入れるべきですか？
schema.org本体の語彙には「RealEstateListing」という型が存在します（出典: schema.org公式）。名前だけを見れば、まさに探していたものに見えます。
ただし該当ページには、この語が新規（new）エリアにあり、実装フィードバックと採用実績が定義の改善に役立つ段階だと記載されています（出典: schema.org公式）。
現時点でGoogleのリッチリザルトには採用されておらず、実装しても検索結果の見た目は変わりません。
実務判断としては、RealEstateListingを対策の主軸に据えるのは時期尚早だとWEBMARKSは考えます。既存テンプレートへの追記で済む範囲であれば、語彙が将来採用される可能性に備えて入れておく価値はあります。
一方で、これを理由に、RealEstateAgentの実装や物件スペックの表形式化を後回しにすることは避けてください。 見た目が変わらない作業に時間を使い、確実に効く作業のほうが止まる。これがいちばん避けたい形です。
この章のまとめ
RealEstateListingは「入れてもよいが、主軸にはしない」。判断をここで止めず、次の手順へ進みます。
05不動産の物件情報は、AI検索に読ませるためにどう構造化するんですか？
物件ページに載っている情報は、ひとかたまりに見えて、実は受け皿がばらばらです。どの要素が、どこで機械可読になるのか。まずこの対応を押さえます。
RealEstateAgent型は、住所・電話番号・営業時間・サービス提供地域などのプロパティを、LocalBusinessから継承しています（出典: schema.org公式）。役割は、物件そのものではなく、事業者の実在性と信頼性を機械可読に示すことだとWEBMARKSは考えます。
物件スペックには、対応する構造化データがありません。だからこそ、本文の表が受け皿になります。価格・専有面積・所在地・築年数といった項目を、地の文に埋め込まず、表として独立させます。
この章のまとめ
物件ページの要素ごとに受け皿は違います。事業者情報は構造化データ、物件スペックは表。この住み分けが出発点です。
06物件の価格は、AI検索最適化のために構造化データで持つべきですか？
価格は、物件ページでいちばん見られる項目です。それだけに「構造化データで持てないか」という相談をよく受けます。
価格情報の構造化には、schema.org Offerの活用も選択肢の1つです。ただし、Googleの構造化データ一覧にある「商品（Product）」は小売向けの設計であり、不動産物件への適用が公式に想定されているとは確認できません。
無理に既存の型へ当てはめるより、価格を本文と表の両方に数値で明記する運用のほうが確実だとWEBMARKSは考えます。型の当てはめを誤ると、見た目が変わらないうえに、仕様変更のたびに保守が必要になります。
この章のまとめ
価格は、型を探すより先に「本文と表の両方に書く」を満たします。ここは仕様変更に左右されません。
07不動産のAI Overviews対策は、AI検索での構造化データ実装をどの順番で進めるんですか？
高梨課長やることは分かってきました。ただ、限られた工数でどれから手をつけるかが判断できません。
鈴木さん順番があります。上から順にやれば、途中で止まっても効果が残るように並べてありますよ。
若葉さん途中で止まってもいい、というのは少し安心します。
専用スキーマが無い以上、実務で着手できるのは、既存の汎用スキーマを組み合わせる設計です。手順は次のとおりです。
この順番で進めます
事業者情報を構造化する
不動産仲介業者の情報をRealEstateAgent（LocalBusiness系）で記述します
物件スペックを表にする
価格・面積・所在地・築年数などの主要スペックを、本文に表形式で明記します
サイト階層を機械可読にする
パンくずリスト（BreadcrumbList）でサイト構造を示します
クロールを確認する
Googlebotのクロールをrobots.txtで妨げていないかを見ます
短期宿泊の有無を判定する
併営している場合のみ、Vacation Rental参加をHotel Center経由で検討します
この章のまとめ
専用の型が無くても、既存の汎用スキーマの組み合わせで着手できます。途中で止まっても、そこまでの分は効果として残ります。
08不動産のAI検索対策では、各手順で何を埋めて、どこに置くんですか？
各手順で実際に埋める項目と置き場所は、次のとおりです。
| 手順 | 実際に埋める項目 | 置き場所 |
|---|---|---|
| 事業者情報の構造化 | name・address・telephone・openingHoursSpecification・areaServed（RealEstateAgentがLocalBusinessから継承するプロパティ） | 会社概要ページと各店舗ページ |
| 物件スペックの表化 | 価格・専有面積・所在地・築年数・間取り・最寄駅からの徒歩分数 | 物件詳細ページ本文の冒頭付近 |
| サイト階層の機械可読化 | BreadcrumbList（エリア→沿線→物件種別→個別物件の4階層） | 全物件ページ共通のテンプレート |
| クロール可否の確認 | robots.txtのDisallow指定・noindex・JavaScript依存レンダリングの3点 | サイト全体 |
| 短期宿泊の判定 | Hotel Centerの適格条件を満たすか否かの社内確認 | 短期宿泊事業を併営する場合のみ |
JSON-LDの記述そのものに不慣れな場合は、別記事『JSON-LDの書き方入門』の実装例を、テンプレートとして使ってください。
この章のまとめ
順番は、事業者情報→物件スペックの表→サイト階層→クロール確認。上から順に、効果が確実な順で並んでいます。
09構造化データを増やす前に、AI検索最適化で知っておく2つの事実は何ですか？
構造化データを追加すれば引用が増える、と考えるのは早計です。前提として押さえておきたい事実が2つあります。
1つ目は、Google公式が、AI機能表示のために特別なスキーママークアップは不要だと明記している点です（出典: Google公式）。構造化データを増やすこと自体が、引用の増加を約束するわけではありません。
2つ目は、FAQ構造化データの扱いが変わった点です。この変化は、物件ページの「よくある質問」をどう扱うかの判断に、直接効いてきます。
この章のまとめ
構造化データは、入れれば効くという道具ではありません。いま機能している型かどうかを、入れる前に確かめます。
10FAQの構造化データは、AI検索の引用に効かなくなったんですか？
Googleは2026年5月の変更履歴で、FAQリッチリザルトが検索結果に表示されなくなったと告知し、翌6月に該当ドキュメントを削除しています（出典: Google公式）。
つまり、物件ページによくある「よくある質問」を構造化データ化しても、検索結果上の見た目は変わりません。
ここで注意したいのは、「見た目が変わらない」ことと「書く意味が無い」ことは別だという点です。FAQ構造化データとAI検索エンジンの引用可否は、別の仕組みで動いています。この関係は、別記事『FAQ構造化データと引用率の関係』で詳しく扱っています。
物件ページのよくある質問そのものは、読者にとって役立つ情報です。リッチリザルト目当てで書くのをやめる、という判断だけを切り分けてください。
この章のまとめ
FAQの構造化データは、検索結果の見た目には効かなくなりました。質問と答えを書くこと自体の価値とは、分けて考えます。
11不動産のAI Overviews対策として構造化データを入れたのに、AI検索で引用されないのはなぜですか？
若葉さん言われたとおりに構造化データを入れたのに、AI Overviewsに何も出てこないときは、どこを見ればいいでしょうか。
鈴木さんそのときは、構造化データより手前を見ます。AI Overviewsは、通常検索のインデックスとスニペット適格性が前提なんですよ。
AI Overviews対策として最初に見るべきなのは、Googlebotのクロールとインデックスの状態です（出典: Google公式）。ここが通っていなければ、構造化データをいくら足しても土俵に上がれません。
なお、生成AI学習用の「Google-Extended」を拒否しても、Google検索の掲載や順位には影響しないと明記されています（出典: Google公式）。学習の可否と、検索での扱いは別々に判断できます。
現場でよく見かけるつまずきは、次の2つです。
存在しない「不動産専用スキーマ」を探し続けてしまう — 実装作業そのものが止まります。Googleが物件専用の構造化データを提供していない以上、汎用スキーマの組み合わせへ軸足を移すことをおすすめします。
物件情報を、長文の説明文だけで構成してしまう — 価格・面積・所在地などの数字を地の文に埋め込むより、表形式で独立させたほうが、機械的に抽出されやすいとWEBMARKSは考えます。
この章のまとめ
引用されないときは、構造化データより手前を疑います。クロールとインデックスが、いちばん最初に見る場所です。
12不動産のAI検索最適化は、物件の構造化データ以外に何を見ておくんですか？
最後に、着手状況を自分で点検できる形に整理しておきます。
- 不動産仲介業者の情報を、RealEstateAgentで構造化データ化している
- 物件スペック（価格・面積・所在地・築年数など）を、表形式で本文に明記している
- パンくずリスト（BreadcrumbList）を実装している
- Googlebotのクロールを、robots.txtで妨げていない
- 短期宿泊事業がある場合、Vacation Rental参加の要否を検討している
なお、海外の不動産ポータルについて、AI検索経由の引用・流入の実名と数値がそろった公開事例は、本稿執筆時点で確認できていません。確認でき次第、本記事を更新します。
事例が出そろうのを待つ判断は、この分野では機会損失になりやすいとWEBMARKSは考えます。上のチェックは、事例の有無にかかわらず着手できるものだけで構成しています。
この章のまとめ
点検の観点は、事業者情報・物件スペック・サイト階層・クロールの4つ。どれも他社の事例を待たずに進められます。
13よくある質問
不動産物件専用の構造化データは、将来的に追加される予定がありますか？
公式に予定は発表されていません。schema.org側にはRealEstateListing型が新規（new）エリアの語彙として存在しますが、Google側の採用時期は本稿執筆時点で確認できません。
Vacation Rentalスキーマを実装すれば、賃貸物件の情報も表示されますか？
表示されません。Vacation Rentalは短期宿泊施設向けに設計されており、Hotel Centerへのアクセスと適格条件の充足が前提です（出典: Google公式）。一般的な売買・長期賃貸物件は対象外です。
RealEstateAgent型を実装すれば、AI Overviewsへの引用が増えますか？
増加を保証するものではありません。RealEstateAgentは仲介業者の情報を機械可読にする手段であり、AI Overviewsの選定基準そのものではありません（出典: schema.org公式）。
海外の不動産ポータルでは、AI検索経由の実績事例が公開されていますか？
本稿執筆時点で、AI検索経由の引用・流入について、実名と数値がそろった公開事例は確認できていません。確認でき次第、本記事を更新します。
物件スペックの表は、どのくらい詳しく書けばいいですか？
まずは、読者が問い合わせ前に確認する項目からで構いません。価格・専有面積・所在地・築年数・間取り・最寄駅からの徒歩分数が、その中心になります。項目を増やすことより、全物件ページで同じ並びに揃えるほうが効きます。
14まとめ｜今日やる2つのこと
専用スキーマの登場を待つ判断は、この分野では機会損失になりやすいとWEBMARKSは考えます。今日着手できるのは、RealEstateAgentの実装と、物件スペックを表形式で明記する情報設計の2つです。
どちらもGoogleの仕様変更に左右されにくく、AI Overviews以外の流入経路にも効きます。RealEstateListingの動向は、この2つを終えてから追いかけても遅くありません。
今日この順でやります
RealEstateAgentを実装する
会社概要ページと各店舗ページに、名称・住所・電話番号・営業時間・提供地域を記述します
物件スペックを表にする
価格・専有面積・所在地・築年数・間取り・最寄駅からの徒歩分数を、物件詳細ページの冒頭付近に置きます
AI検索では、こう聞かれています
不動産物件の構造化データは、どの型を使えばいいですか？
「そもそも不動産のAI Overviews対策とは、AI検索で構造化データを何に使うことですか？」の章で、専用の型が無い前提から説明しています
AI Overviewsに自社の物件情報を載せるには、何をすればいいですか？
「不動産のAI Overviews対策は、AI検索での構造化データ実装をどの順番で進めるんですか？」の章に、着手順の手順があります
RealEstateListingは実装したほうがいいですか？
「schema.orgのRealEstateListingは、構造化データのAIO対策として今すぐ入れるべきですか？」の章で答えています
短期宿泊向けのVacation Rentalは使えますか？
「Vacation Rentalは、不動産のAI検索最適化に使える型なんですか？」の章に、適用条件があります
次に読むなら、この記事です
