結論・概要
構造化データ(JSON-LD)とは、WebページのHTMLに「これはホテルです」「このFAQの答えはこうです」という意味情報を、人間ではなくAI・検索エンジンが読める形式で書き添える仕組みです。
Google Search Centralは構造化データをリッチリザルト表示の要件として明示しており、ChatGPT・Gemini・PerplexityなどのAIもJSON-LDをエンティティ抽出(「何の事業者か」「何の質問への回答か」を判断する処理)の手がかりとして利用します。
AEO対策の中で、構造化データは最も費用対効果が高い施策の一つです。多くのサイトで半日〜1日の実装で完了し、FAQPageだけでも引用適性が大きく変わります。
この記事でわかること
- 構造化データの仕組み(非エンジニア向けの説明)
- 業態別にどのSchemaを選ぶか
- FAQPage / Restaurant / Hotel のコピペ可能なコード例
- 公開前の検証手順とチェックリスト
3行サマリー
- JSON-LD = AIが読める形式で「これはホテル/FAQです」と宣言する仕組み
- 迷ったらFAQPage Schemaから始める(全業種で最も効果が高い)
- HTMLソースに直書き → Rich Results Test → AEO診断で検証
3行で理解する JSON-LD
- HTMLの
<script type="application/ld+json">タグ内にJSON形式で情報を書く - Schema.orgという共通語彙(
@type: "Hotel"等)を使う - Google・AIがこのJSONを読んで「営業時間は17:00–23:00」と理解する
01背景・課題 — なぜ構造化データがないとAIに無視されるのか
よくある問題:情報が「見えない」形で公開されている
多くの日本企業サイトでは、次のような状態になっています。
- 料金表がPDFや画像で、HTMLテキストがない
- 営業時間がフッターの小さな文字だけ
- FAQがJavaScriptで動的生成され、HTMLソースに存在しない
- 会社名・住所・電話番号(NAP)がページごとに微妙に異なる
AIはテキストとSchema.orgの @type から「何の事業者か」を判断します。上記の状態では、引用候補から除外されやすくなります。
診断ロジックが示す傾向
AEOチェッカーの評価軸(構造化データ20点満点)では、FAQPage未実装とLocalBusiness系Schemaの欠落が低スコア帯に多く見られる傾向があります。これは診断ロジック上の参考所見であり、大規模な実ログ集計ではありません。
先行事例
米国のMarriottやOpenTableは、公式サイト全域でHotel/Restaurant SchemaとAggregateRatingを統一実装し、AIアシスタント連携の前提データを整備しています。日本企業でも、OTA依存から「AI-readableな自社一次情報」への転換が急務です。
[DATA] エビデンス — 出典: Google Search Central
- 構造化データはリッチリザルト表示の要件としてGoogleが明示
- ChatGPT・Gemini・PerplexityもJSON-LDをエンティティ抽出の手がかりとして利用
[DATA] エビデンス — 出典: Princeton / arXiv
- GEO研究で、権威ある引用の追加・統計明示が生成エンジン可視性向上に寄与
- 構造化に近い情報整理がAEOの最優先施策の一つ
02Schema選定 — 業態別の優先順位
用途別に優先Schemaを選びます。迷ったらFAQPageから始めてください。全業種共通で最も効果が高いです。
| 優先度 | Schema | 主な用途 | AI引用への効果 |
|---|---|---|---|
| ★★★ | FAQPage | よくある質問 | Q&A形式の回答を直接抽出(最重要) |
| ★★★ | Restaurant / Hotel | 飲食・宿泊 | 営業時間・住所・予約URLのエンティティ化 |
| ★★☆ | Organization | 企業・運営者 | ブランド同一性・公式サイトの紐付け |
| ★★☆ | Article | コラム・レポート | 著者・公開日・更新日の信頼性担保 |
| ★☆☆ | BreadcrumbList | 全ページ | サイト階層・トピック専門性の提示 |
| ★☆☆ | AggregateRating | レビューあり店舗 | 評価点数の構造化(GBPと整合必須) |
業態別クイックスタート
| 業態 | 最初に実装するSchema | 対象ページ |
|---|---|---|
| 飲食店 | Restaurant + FAQPage | トップ、メニュー、FAQ |
| ホテル・旅館 | Hotel + FAQPage | トップ、客室、FAQ |
| BtoB SaaS | Organization + FAQPage + Article | トップ、料金、ブログ |
| 士業・コンサル | Organization + FAQPage | トップ、サービス、FAQ |
同一ページに複数 @type をネストする場合は、@graph または mainEntity で関係を明示してください。
03具体的な実装 — コピペ可能なコード例
FAQPage(全業種共通・最優先)
FAQPageは、AI OverviewsやChatGPTが「質問→回答」を直接抜き出す際に最も参照されるSchemaです。最低5問、理想は10問以上を構造化してください。
HTMLへの埋め込み方:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "チェックインは何時からですか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "チェックインは15:00から、チェックアウトは11:00までです。早朝チェックインは前日までにフロントへご連絡ください。"
}
}]
}
</script>
ポイント:
name(質問)とtext(回答)は、ページ上の表示テキストと完全一致させる- 回答は100字以上の具体的な内容にする(「詳しくはお問い合わせください」だけはNG)
Restaurant Schema(飲食店)
Schema.org/Restaurant に準拠し、営業時間・メニューURL・予約リンクを含めます。
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "渋谷 和食 花月",
"image": "https://example.com/images/storefront.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "道玄坂1-2-3",
"addressLocality": "渋谷区",
"addressRegion": "東京都",
"postalCode": "150-0043",
"addressCountry": "JP"
},
"telephone": "+81-3-1234-5678",
"servesCuisine": "Japanese",
"priceRange": "¥¥¥",
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "17:00",
"closes": "23:00"
}],
"acceptsReservations": "https://example.com/reserve",
"menu": "https://example.com/menu"
}
Hotel Schema(宿泊施設)
Schema.org/Hotel では checkinTime / checkoutTime / amenityFeature がAIの比較クエリ(「温泉付き」「駅近」)に効きます。
{
"@context": "https://schema.org",
"@type": "Hotel",
"name": "箱根 温泉旅館 翠峰",
"url": "https://example.com",
"telephone": "+81-460-00-0000",
"checkinTime": "15:00",
"checkoutTime": "11:00",
"starRating": {
"@type": "Rating",
"ratingValue": "4"
},
"amenityFeature": [
{ "@type": "LocationFeatureSpecification", "name": "露天風呂", "value": true },
{ "@type": "LocationFeatureSpecification", "name": "無料Wi-Fi", "value": true }
]
}
実装の4ルール
<script type="application/ld+json">をサーバーHTMLに直接埋め込む(GTM後挿入は避ける)nullや空文字のプロパティは出力しない- 表示テキストとSchemaの内容を完全一致させる(食い違いはE-E-A-T低下)
- GBP(Googleビジネスプロフィール)のNAPと1文字単位で整合
04検証手順 — 公開前に必ずやる4ステップ
Google Search Central推奨の検証フローに従い、公開前後で必ずテストします。
| ステップ | ツール | 確認内容 |
|---|---|---|
| 1 | Rich Results Test | エラー・警告をゼロにする |
| 2 | Schema Markup Validator | Schema.org準拠を確認 |
| 3 | Google Search Console →「拡張」 | インデックス後のリッチリザルト状態を監視 |
| 4 | AEOチェッカー | 構造化データカテゴリ(20点)の得点を再診断 |
実装チェックリスト
- FAQPageが主要LP・料金ページに実装されている
- Restaurant/Hotel/LocalBusinessの
@typeが業態に合っている - openingHours / checkinTime / checkoutTime がISO 8601形式
- Organization Schemaに
sameAs(公式SNS)が設定されている - Article Schemaに
author・datePublished・dateModifiedがある - AggregateRatingの値がGBP・実際のレビューと一致している
- JSON-LDが
<head>または<body>先頭付近に静的配置されている - リッチリザルトテストで「Page is eligible for rich results」を確認済み
05よくある失敗と回避策
| 失敗パターン | なぜ問題か | 回避策 |
|---|---|---|
| MicrodataとJSON-LDの二重実装 | 矛盾が生じやすい | JSON-LDに一本化 |
| 存在しない星評価の記載 | Googleガイドライン違反でペナルティリスク | 実レビューのみ構造化 |
| 全ページに同一FAQをコピペ | ページ固有性が失われる | ページ固有のQ&AのみFAQPage化 |
| JavaScriptレンダリング依存 | SPAでクライアント生成JSON-LDは取得漏れ | SSRまたは静的HTMLで出力 |
| GTM経由でのみ挿入 | クローラーが取得できないケースがある | HTMLソースに直書き |
| 検証を1回だけ | テンプレート更新で壊れる | 更新のたびにRich Results Testを再実行 |
06取るべきアクション — 今週の実装プラン
優先度順に、次の4つから着手してください。
- 現状把握(30分) — トップページ・料金/メニューページ・FAQページの3URLをRich Results Testにかけ、エラーリストを作成する。
- FAQPage実装(半日) — よくある質問5問以上をFAQPage JSON-LDで構造化する。最も費用対効果が高い。
- 業態Schema実装(半日) — RestaurantまたはHotel Schemaを実装し、NAP・営業時間・予約URLを含める。
- 月次モニタリング — Search Consoleの拡張レポートとAEO診断を比較し、構造化データカテゴリの改善幅を追跡する。競合3社のJSON-LD(ブラウザ「ページのソースを表示」)もDiffして不足プロパティを洗い出す。
参考文献
- Intro to structured data — Google Search Central
- FAQ structured data — Google Search Central
- Local business structured data — Google Search Central
- Rich Results Test — Google
- Schema.org — Restaurant
- Schema.org — Hotel
- Generative Engine Optimization — Princeton / arXiv
本記事はAEO総研技術チームが公開情報をもとに執筆しました。