AI検索で選ばれるホテル公式サイトの構造化データ設計 ── schema.org実装ガイド

AI検索に「引用されるホテル」「されないホテル」の差

ChatGPT、Perplexity、Google SGEといったAI検索エンジンに「東京駅近くで子連れに優しいホテル」と尋ねたとき、特定のホテルが名前を挙げて紹介されることがあります。一方で、同クラス・同立地なのに一切言及されないホテルもあります。この差はどこから生まれるのでしょうか。

答えの一つは、公式サイトがAIに「理解可能な形」で情報を発信しているかどうかです。AIは自然言語のホームページを読むこともできますが、schema.orgに基づく構造化データがあれば、より高い信頼度で情報を抽出できます。構造化データは、AIに対する「機械可読な自己紹介カード」です。

63%

AI検索で引用されるホテルのうち、schema.org実装済みの割合

3.2倍

構造化データ実装後のAI推薦率の伸び（中央値）

この記事では、ホテル公式サイトに入れるべき構造化データを、実装例のJSON-LDとともに整理します。すべての項目を一度に入れる必要はありません。優先度の高いものから段階的に実装していくのが現実的です。

schema.org Hotel / LodgingBusiness の必須プロパティ

ホテルを表す語彙は `Hotel` が第一選択です。より広い宿泊業全般（旅館・民泊・簡易宿所など）には `LodgingBusiness` が使えます。まずは基本情報を埋める土台となる、必須プロパティを整理します。

最低限埋めるべき8プロパティ

name - 正式施設名（ビジネス名と完全一致させる）
url - 公式サイトのトップURL
telephone - 国際表記（+81-xx-xxxx-xxxx）
address - PostalAddressで国・都道府県・市区町村・番地を分解
geo - GeoCoordinatesで緯度経度（地図表示精度に直結）
image - 外観写真の絶対URL（複数可）
priceRange - 「¥¥」のような価格帯表記
starRating - 公式スター評価がある場合のみ

Hotel 基本情報 JSON-LD

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "@id": "https://example-hotel.com/#hotel",
  "name": "ホテル・ビジネスブレーン東京",
  "url": "https://example-hotel.com/",
  "telephone": "+81-3-1234-5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "丸の内1-2-3",
    "addressLocality": "千代田区",
    "addressRegion": "東京都",
    "postalCode": "100-0005",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.6812,
    "longitude": 139.7671
  },
  "image": [
    "https://example-hotel.com/img/exterior.jpg",
    "https://example-hotel.com/img/lobby.jpg"
  ],
  "priceRange": "¥¥¥",
  "checkinTime": "15:00",
  "checkoutTime": "11:00",
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "無料Wi-Fi", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "駐車場", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "大浴場", "value": true }
  ]
}

宿泊プラン・料金を伝える Offer の書き方

AIが「いくらで泊まれるか」を答えるには、Offerプロパティが必要です。動的価格の場合は代表的な下限料金を示し、詳細は予約ページへ誘導するのが実務的です。

Offer 実装例（スタンダードダブル・朝食付）

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "@id": "https://example-hotel.com/#hotel",
  "makesOffer": [
    {
      "@type": "Offer",
      "name": "スタンダードダブル 朝食付",
      "description": "21㎡のダブルルーム、朝食ビュッフェ付き",
      "price": "18000",
      "priceCurrency": "JPY",
      "priceValidUntil": "2026-12-31",
      "availability": "https://schema.org/InStock",
      "url": "https://example-hotel.com/plans/standard-double-breakfast",
      "eligibleQuantity": {
        "@type": "QuantitativeValue",
        "unitCode": "NGT",
        "value": 1
      }
    }
  ]
}

`priceValidUntil` は必ず未来日を入れ、定期的に更新してください。期限切れのOfferはGoogleの構造化データテストで警告になります。

レビュー・評価を伝える AggregateRating と Review

AIは「評判の良いホテルを教えて」という質問に答えるとき、レビュー情報を参照します。じゃらんや楽天トラベルのレビューが高得点でも、それは各OTAの内部データ。公式サイトにAggregateRatingがあれば、Googleやその他AIが直接読み取れます。

AggregateRating + Review の組み合わせ

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "248",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "M.K." },
      "datePublished": "2026-03-12",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "reviewBody": "駅近で部屋も清潔。朝食のビュッフェが特に良かった。"
    }
  ]
}

架空レビューは絶対に書かないでください。
ガイドライン違反として手動ペナルティの対象になり、公式サイト全体の検索評価が下がります。実在のレビュー（自社予約フォーム経由のアンケート、GBPのレビュー等）を引用する形で実装してください。

予約導線を伝える reservationAction / potentialAction

AIが「このホテルを予約したい」という意図を持ったユーザーに対して、予約フォームのURLを直接提示できるようにするのが `potentialAction` です。

予約アクションの実装例

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "potentialAction": {
    "@type": "ReserveAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example-hotel.com/reserve?checkin={checkinDate}&checkout={checkoutDate}",
      "inLanguage": "ja",
      "actionPlatform": [
        "https://schema.org/DesktopWebPlatform",
        "https://schema.org/MobileWebPlatform"
      ]
    },
    "result": { "@type": "LodgingReservation", "name": "ご予約確認" }
  }
}

FAQPage でAI検索の抜粋に載る設計

AI検索で抜粋される文章は、多くの場合「質問 → 回答」の対話形式です。公式サイトのFAQページを FAQPage 構造化データで囲うことで、AIが回答として抽出しやすくなります。

FAQPage 実装例

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "チェックイン・チェックアウトの時間は？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "チェックインは15:00、チェックアウトは11:00です。アーリーチェックインは事前予約で13:00から対応可能です。"
      }
    },
    {
      "@type": "Question",
      "name": "駐車場はありますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "地下駐車場を30台分、1泊2,000円で提供しています。ハイルーフ車は高さ2.0m制限のため要事前連絡です。"
      }
    },
    {
      "@type": "Question",
      "name": "子連れでも泊まれますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "6歳以下の添い寝は無料です。ベビーベッド（無料・要予約）、子供用アメニティ、ミルク用のお湯サービスをご用意しています。"
      }
    }
  ]
}

FAQの内容は、実際にゲストが聞きたくなる粒度で書いてください。「はい」「いいえ」だけの回答より、条件・制約・追加情報を含む2〜4文の回答の方がAIに抜粋されやすい傾向があります。

構造化データを入れても、AI検索で引用されているか分からない

ChatGPT・Perplexityでの御施設の推薦状況を無料チェック

無料チェックを申し込む

JSON-LD実装例（Hotel + FAQPage + BreadcrumbList の3点セット）

実際にトップページに入れる最小構成のセットを示します。この3つは、ほぼ全てのホテル公式サイトに入れるべき基本セットです。

3点セット統合例（head内に配置）

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "Hotel",
    "@id": "https://example-hotel.com/#hotel",
    "name": "ホテル・ビジネスブレーン東京",
    "url": "https://example-hotel.com/",
    "telephone": "+81-3-1234-5678",
    "address": { ... },
    "geo": { ... },
    "priceRange": "¥¥¥",
    "aggregateRating": { "ratingValue": "4.5", "reviewCount": "248" }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [ ... ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example-hotel.com/" },
      { "@type": "ListItem", "position": 2, "name": "プラン" }
    ]
  }
]
</script>

全体を一つの `<script>` タグに配列で入れる形式です。ページごとに必要な要素だけ残し、トップ・プラン詳細・アクセス・FAQの各ページに分けて実装します。

検証ツール3つ ── 実装後のチェック

JSON-LDを書いたら、必ず以下の3つで検証してください。構文エラーがあっても画面は崩れないため、検証ツール無しでは誤りに気づけません。

ツール1: Rich Results Test（Google公式）

search.google.com/test/rich-results でURLを入力すると、Googleが解釈した構造化データがプレビュー表示されます。リッチリザルト対応の語彙（FAQPage / Recipe / Event など）が正しく認識されているか確認できます。

ツール2: Schema Markup Validator（schema.org公式）

validator.schema.org でJSON-LD全体の構文チェック。Rich Results Testが対応しない語彙（Hotel全体、LodgingBusiness など）も広くチェックできます。

ツール3: Google Search Console「拡張」レポート

実装後、数日〜1週間で Search Consoleの「拡張」タブにエラー・警告がレポートされます。本番トラフィックでの検出なので、実際の影響範囲が分かります。月1回は必ず確認してください。

構造化データが表示コンテンツと乖離すると、ペナルティ対象です。
例：AggregateRatingに「4.9」と書いているのに、公式サイトの画面上にレビュー表示がない場合。構造化データは「画面に見える内容を機械可読にしたもの」でなければなりません。スパム的な使用はGoogleの手動アクション対象です。

実装は「一度に全部」ではなく段階的に

Hotel + FAQPage + BreadcrumbListの3点セットから始め、1ヶ月程度運用したらOfferとAggregateRatingを追加、さらに1ヶ月後にReviewとpotentialActionを追加、という段階的な実装を推奨します。

一度に全部入れて、どれかにエラーが出るとGoogleが全体を無視することがあります。段階的に入れれば、エラー発生時に原因を特定しやすく、AIに引用される効果も1段階ずつ測定できます。構造化データは「書いて終わり」ではなく、継続的にメンテナンスする資産です。