AI引用要因の3層構造：Domain Authority、Schema、Geo Data の役割

AI検索ランキングに関するほとんどのガイドは二つの層を扱っています。domain authorityとschema markupです。これらのガイドは間違っていませんが、リスティングページ、不動産ポータル、バケーションレンタルプラットフォーム、在庫が位置情報に基づくあらゆるサイトにとって特に問題となる形で不完全です。

第三の層はgeo dataです。最も文書化が少なく、最も一般的に欠落しており、ページが位置情報固有のクエリに答えられるかどうかを決定するものです。AEOが実際に何を意味するかを理解することが出発点ですが、このガイドでは個々のページが引用されるかどうかを左右する構造的要因をさらに深く掘り下げます。

層1：ドメインとエンティティの権威

domain authorityは参入要件であり、ランキングシグナルではありません。閾値として考えてください。おおよそDA 20〜30以下のドメインからのページは、コンテンツの品質に関わらず、競合クエリのAI引用プールに滅多に現れません。その閾値を超えると、生のDAは引用頻度との相関が弱まります。

DA閾値以上の主要シグナルとして代わりに登場したのが、エンティティの権威です。AIモデルがあなたのサイトが何であるか、何をカバーしているか、誰に奉仕しているかをどれほど明確かつ一貫して理解しているかです。

ウェブ全体での一貫したエンティティアイデンティティ。 あなたの組織名、住所、URL、カテゴリは、自分のサイトのスキーマ、Google Business Profile、業界ディレクトリ、引用ソース全体で同一でなければなりません。NAP不一致はエンティティアイデンティティを直接分断します。複数の弱い表現ではなく、一つの強い表現に集中させます。

トピックの一貫性。 AIモデルはサイトが明確で一貫したトピッククラスターを持っているかどうかを評価します。一つの狭いニッチに30本の記事を持つサイトは、同じDAで20の無関係なトピックに散らばるサイトよりも、そのニッチでエンティティとしてより権威があります。

sameAs参照。 JSON-LD内のsameAsプロパティは、あなたのエンティティをWikidata、Crunchbase、LinkedIn、その他の権威あるグラフ上での表現にリンクします。AIモデルはこれらを使って、推論しているエンティティが複数のソース全体で説明されているものと同一であることを確認します。完全なLocalBusiness JSON-LD実装ガイドでは、正しい構造方法を解説しています。

ドメインがDA閾値をクリアしていれば、エンティティ権威の改善は追加のリンク構築よりもAI引用に対して多くの効果をもたらします。

層2：Schema Markup

Schema markupはページとAI検索システム間のコミュニケーション層です。構造化データを持つページは、スキーマなしのページよりも大幅に高い頻度で引用されます。Google AI Overviewsは構造化データを持つページを優先します。競合クエリに対する選択の向上は顕著です。

ほとんどの実装はGoogleのリッチリザルトテストを満足するフィールドで止まりますが、これはAI引用システムを満足させることと同じではありません。

ほとんどの実装が正しく行うこと： @type、name、description、url、openingHours、telephone、address、FAQスキーマ。

リスティングページでほとんどの実装が見落とすこと： リスティング在庫向けに設計されたスキーマタイプは、ほとんどのガイドが説明するタイプとは異なるプロパティを必要とします。

不動産、バケーションレンタル、宿泊業のリスティングページでは、関連するタイプはRealEstateListing、LodgingBusiness、Hotel、VacationRental、Apartment、SingleFamilyResidenceであり、それぞれ価格と在庫のOfferとネストされます。これらのタイプは、適切な位置プロパティと組み合わされた場合にのみ、AI検索のための機能を果たします。

FAQスキーマの誤り

FAQスキーマは編集コンテンツにとって価値があります。コンテンツの一部が答える質問を正確にAIエンジンに伝えます。リスティングページは編集コンテンツではありません。物件リスティングはバケーションレンタルに関する一般的な質問に答えているのではありません。特定の場所にある特定のエンティティを表しています。FAQスキーマは「地下鉄近くの2ベッドルームアパート」とリスティングをAIエンジンが一致させるのに役立ちません。リスティングページの適切なスキーマはエンティティ関係的であり、Q&A形式ではありません。

層3：Geo Data（文書化が不十分な層）

位置情報固有のクエリ（「イエローストーン近くのバケーションレンタル」、「ダウンタウンから10分以内のアパート」）に答えるAIモデルは、暗黙の地理空間マッチングを行っています。クエリされた場所と検索プール内のエンティティ間の地理的関係を解決しています。そのマッチングが機能するためには、リスティングページが構造化データにそれらの関係を明示的にエンコードする必要があります。

すべてのリスティングページに正確なGeoCoordinates

GeoCoordinatesのgeoプロパティにlatitudeとlongitudeを少なくとも4桁の小数点以下で指定することが基本的なシグナルです。これがないと、AIエンジンはあなたの住所文字列をジオコーディングします。これはいかなる不一致でも失敗し、はるかに低い精度しか生みません。geoを含む実装のほとんどは、個々のリスティングページではなく、サイトレベルのLocalBusinessスキーマにのみ適用しています。各リスティングページ自体が解決可能な地理的エンティティでなければなりません。

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 48.8566,
  "longitude": 2.3522
}

containedInPlace：物件を地理的階層にリンク

containedInPlaceプロパティは、リスティングをそれを含む近隣、地区、都市、地域のエンティティにリンクします。これにより、AIエンジンは単に「[番地]のアパート」ではなく「マレー地区のアパート」といったクエリに答えられます。これがないと、物件は住所として存在しますが、いかなる地理的エンティティのメンバーでもありません。

"containedInPlace": {
  "@type": "Place",
  "name": "Le Marais",
  "containedInPlace": {
    "@type": "City",
    "name": "Paris"
  }
}

近隣のPlaceエンティティ：交通機関、学校、ランドマーク

ユーザーが「地下鉄近くのレンタル」を求めるとき、AIは物件と交通インフラ間の明示的な機械読み取り可能な関係を探しています。説明文に「地下鉄4番線まで徒歩5分」という文があっても、AI検索には何もしません。同じ情報がamenityFeatureを通じてリンクされたPlaceエンティティとして構造化されれば検索可能です。

リスティングデータベースがこのデータをネイティブに持たない理由

ほとんどのプロパティ管理システムとリスティングデータベースは、オペレーターが入力したものを保存します。住所、価格、ベッドルーム数、バスルーム数、写真です。これらはポータルを閲覧する人間のために構築されており、機械読み取り可能な地理的コンテキストのためではありません。マッピングAPIはこのギャップを埋めます。Geocoding APIは住所を正確な座標に変換します。POI APIは指定した半径内の交通機関、学校、公園、ランドマークを返します。出力はschema.orgタイプに直接マッピングされ、リスティングページのJSON-LDにスケールで埋め込むことができます。

三つのギャップすべてを埋めると何になるか

AI検索でよく機能するリスティングページ：

1. 一貫したエンティティアイデンティティ、sameAs参照、明確なトピッククラスターを持つドメイン上にある
2. 価格にOfferとネストされた最も具体的な適用可能なスキーマタイプを使用する
3. リスティングページ自体にGeoCoordinatesを含み、近隣と都市エンティティにリンクするcontainedInPlace、交通機関、学校、ランドマークの構造化された近隣Placeデータを持つ

ほとんどのリスティングページは層1の一部と層2の基本的な部分をカバーしています。層3をカバーするものはほとんどありません。三層すべてをカバーするページが、位置情報固有のクエリのAI回答に表示されるページです。

現在、ローカルビジネスのわずか1.2%がAI検索推薦に表示されています。それらは平均して最も高いdomain authorityを持つものではありません。三つのギャップすべてを埋めたものです。