GenAX/ガイド/02 構造化データ

GUIDE · 02 構造化データ

構造化データ（JSON-LD）はAI検索の引用に効くのか
— 実装すべきスキーマと優先順位

「構造化データを入れればAIに引用される」という説明をよく見ますが、LLMが引用先を選ぶときにschema.orgを直接読んでいる証拠はほとんどありません。それでも実装する価値があるのは、効き方が別の経路にあるからです。このガイドでは、何に効いて何に効かないかを分けたうえで、優先順位付きの実装手順を示します。

1. 何に効いて、何に効かないか

効くもの

• Google検索経由のAI機能：AI OverviewsとAIモードは、Google検索の通常インデックスから引用元を選びます。構造化データはそのインデックスでページの種類・日付・発行者を明確にするので、間接的に効きます。
• エンティティの同定：OrganizationとsameAs（公式SNS、Wikipedia、法人番号ページなど）で「このサイトはどの組織か」が機械的に確定します。同名の別組織との混同を減らし、AIが「〇〇社によると」と帰属するときの根拠になります。
• 日付と著者の機械可読化：datePublished・dateModified・authorは、本文中の表記が曖昧でも確実に読める形で鮮度と責任主体を示せます。

効かないもの、または証拠がないもの

• ChatGPT検索やPerplexityが引用先を選ぶ際にJSON-LDを評価しているという公式情報はありません。これらは主に本文テキストを読んでいると考えるのが安全です。
• FAQPageで回答を「そのまま引用させる」：Googleは2023年にFAQリッチリザルトを政府・医療系サイトに限定しました。構造としては有効ですが、表示上の特典はほぼありません。
• スキーマの数を増やす：関係ないスキーマを大量に入れても評価は上がらず、本文と矛盾すればスパム扱いのリスクがあります。

2. 実装の優先順位

1と2だけで大半のサイトは十分です。3以降はサイト構造に合う場合にだけ追加してください。

3. 実装例（コピーして使える）

JSON-LDを<head>内の<script type="application/ld+json">に置きます。Microdata・RDFaより保守しやすく、Googleも推奨しています。

Organization + WebSite（トップページ）

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "株式会社サンプル",
      "url": "https://example.com/",
      "logo": "https://example.com/assets/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/example",
        "https://x.com/example_jp"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "株式会社サンプル",
      "publisher": { "@id": "https://example.com/#org" },
      "inLanguage": "ja"
    }
  ]
}
</script>

Article + BreadcrumbList（記事ページ）

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "記事タイトル（本文のh1と一致させる）",
      "datePublished": "2026-08-26",
      "dateModified": "2026-08-26",
      "inLanguage": "ja",
      "mainEntityOfPage": "https://example.com/blog/post-1/",
      "author": { "@type": "Person", "name": "執筆者名" },
      "publisher": { "@id": "https://example.com/#org" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
        { "@type": "ListItem", "position": 2, "name": "ブログ", "item": "https://example.com/blog/" },
        { "@type": "ListItem", "position": 3, "name": "記事タイトル", "item": "https://example.com/blog/post-1/" }
      ]
    }
  ]
}
</script>

@idを使ってOrganizationを一度だけ定義し、他のスキーマから参照する形にすると、ページごとに組織情報が食い違う事故を防げます。

4. 検証方法

• Googleリッチリザルトテスト：Googleが認識する範囲での妥当性。リッチリザルト対象外のスキーマは「検出されない」と出ますが、それはエラーではありません。
• Schema Markup Validator（schema.org公式）：schema.org語彙としての構文チェック。Googleの対象外スキーマも検証できます。
• Search Consoleの「拡張」レポート：本番反映後、Googleが実際にどう解釈したかを確認できます。

5. よくある間違い

• 本文と一致しない：JSON-LDのheadlineと実際のh1が違う、datePublishedが本文の表記と食い違う。AIにとっては矛盾した情報源になります。
• JavaScriptでしか出力されない：クライアント側で後から挿入するJSON-LDは、JavaScriptを実行しないクローラーには存在しません。静的HTMLに含めてください。
• Organizationの重複：ページごとに名前やURLが微妙に違うOrganizationが定義されている。@idで一本化します。
• authorが空、または組織名だけ：記事の責任主体が分からない。個人名を出せない場合はOrganizationをauthorにしても構いませんが、本文の署名と揃えます。
• dateModifiedを更新していない：内容を直したのに日付が古いままだと、鮮度で不利になります。逆に内容を変えずに日付だけ更新するのは、鮮度偽装として扱われるリスクがあります。