AI引用のための構造化データ実装

TL;DR

• 構造化データを入れれば AI に引用される、とは言えない。Google は AI Overviews / AI Mode について「特別な schema.org 構造化データを追加する必要はない」と明言している
• それでも入れる価値はある。Google は構造化データをページ内容の理解に使い、リッチリザルトの対象にもなる。AI 機能で表示されるための前提は「インデックスされ、スニペット付きで表示できること」
• 2026年9月時点で、FAQ リッチリザルトは終了（2026-05-07）、HowTo リッチリザルトは 2023年に廃止。記事ページで優先するのは Article / BlogPosting
• JSON-LD は本文に見えている内容だけを書く。schema.org の仕様どおりのプロパティ名を使い、Schema Markup Validator とリッチリザルト テストで確かめる
• Google 以外の生成 AI が構造化データをどう使うかは、一次資料で確認できなかった。効果を断定しない

GEO×SEO統合シリーズ：本記事はGEO×SEO統合戦略シリーズの個別解説です。各施策を統合した全体ワークフローとKPI設計の全体像は統合戦略のハブ記事にまとめています。

この記事の目的と成功基準

• 目的: 「構造化データは AI の引用に効くのか」に一次資料で答え、そのうえで入れる場合の最小実装と検証手順を示す
• 想定読者: フロントエンド/コンテンツエンジニア、GEO 対応する技術者
• 成功基準: 読者が「何を期待して・何を・どう検証して」実装するかを自分で判断できること。citation-friendly 構造 への回遊

結論：構造化データは AI の引用に直接効くのか

Google 検索の AI 機能（AI Overviews / AI Mode）については、Google 自身が次のように書いています。

• 「AI Overviews や AI Mode に表示されるための追加要件はなく、特別な最適化も必要ない」。AI 用のファイルやマークアップを新たに作る必要はなく、「追加が必要な特別な schema.org 構造化データもない」（AI features and your website）
• AI Overviews / AI Mode の補足リンクとして表示されるには、ページがインデックスされ、スニペット付きで表示できる状態であること。追加の技術要件はない（同上）
• 生成 AI 機能向けの最適化ガイドでも「構造化データは生成 AI 検索に必須ではない」としたうえで、リッチリザルトの対象になるので SEO 全体の一部として使い続けるのがよい、としている（Optimizing your website for generative AI features on Google Search）

したがって本記事の立場は次のとおりです。

「入れれば引用される」という説明は、少なくとも Google の公式見解とは合いません。構造化データは、本文の質と検索インデックスへの載りやすさを前提にした 補助 として扱うのが正確です。

それでも実装する理由

Google は構造化データについて次のように説明しています（Intro to How Structured Data Markup Works）。

• Google はウェブ上の構造化データを、ページの内容の理解と、ウェブや世の中の情報の収集に使う
• 形式は JSON-LD を推奨（<script> タグに埋め込む。実装と保守がもっとも容易）
• 構造化データはリッチリザルトの 対象になる ための条件であって、表示を保証しない。一般ガイドラインにも「正しくマークアップしても検索結果に表示される保証はない」とある（General Structured Data Guidelines）

Article 構造化データについては「ページの理解を助け、検索結果でより適切なタイトル・画像・日付を表示できる」と説明されています（Article structured data）。AI 引用の効果が断定できなくても、日付や著者を機械可読にしておく実益はここにあります。

COSEOM の GEO ガイド のように、構造化データが AI の意味理解を助けるとする解説もあります。ただしこれは第三者の見解で、Google の公式ドキュメントが示す範囲（ページ理解に使う・AI 機能の条件ではない）を超える効果の裏付けにはなりません。

2026年時点の schema ごとの位置づけ

以前は「FAQPage / Article / HowTo が GEO の3点セット」と説明されることが多くありました。Google 検索での扱いは次のとおり変わっています。

FAQPage と HowTo は schema.org の型としては今も有効です（FAQPage / HowTo）。既存の実装を残すかどうかは、マークアップがページに見えている内容と一致しているか（構造化データの一般的なガイドライン）で判断すれば足ります。ただし Google のリッチリザルトを目的に新規実装する理由はなくなった、と整理できます。

FAQ の本文設計（質問の選び方・回答の粒度）は GEO向けFAQ設計 に任せます。

最小実装例：BlogPosting（JSON-LD）

記事ページでまず入れるのは BlogPosting（Article の下位型）です。以下のプロパティはすべて schema.org/BlogPosting のプロパティ一覧（Article / CreativeWork / Thing から継承したものを含む）に実在することを確認しています。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "AI引用のための構造化データ実装",
  "description": "構造化データはAI引用に直接効くのか。一次資料で答え、最小実装と検証手順を示す。",
  "datePublished": "2026-05-29T16:00:00+09:00",
  "dateModified": "2026-09-23T00:00:00+09:00",
  "inLanguage": "ja",
  "image": ["https://example.com/images/hero.png"],
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/articles/structured-data-for-ai-citation"
  },
  "author": {
    "@type": "Organization",
    "name": "Growth Lab編集部",
    "url": "https://example.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Growth Lab",
    "url": "https://example.com"
  }
}

書くときの注意（Google の Article structured data より）:

• 使える型は Article / NewsArticle / BlogPosting のいずれか
• 人は Person、組織は Organization で表す。author.name には著者名だけを入れ、肩書きなどを混ぜない
• author.url には著者の SNS ページや自己紹介ページ、経歴ページなど、著者を示すページを指定する

著者を Person として厚く表す方法は AI検索時代のE-E-A-T、sameAs で組織や概念を外部の知識ベースと結ぶ方法は GEO向けエンティティ設計 に委ねます。

FAQPage を併用する場合

本文に FAQ があり、既存の運用で FAQPage を出している場合の最小形です。mainEntity / acceptedAnswer / text は schema.org の仕様どおりのプロパティです。前述のとおり Google の FAQ リッチリザルトは終了しているので、Google での表示効果は期待しない 前提で使います。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "構造化データを入れれば AI に引用されますか？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "いいえ。Google は AI 機能に特別な構造化データは不要としています。"
    }
  }]
}

本文と JSON-LD を一致させる

Google の一般ガイドラインは、読者に見えていない内容をマークアップしないこと、ページの主な内容を表すマークアップにすることを求めています（General Structured Data Guidelines）。

• headline は本文のタイトルと一致させる
• FAQPage の Q&A は本文の FAQ と一致させる
• 本文に無い情報を JSON-LD だけに入れない

違反は手動による対策の対象になります。ただし同ガイドラインによれば、その影響は リッチリザルトとして表示される資格を失うこと で、ウェブ検索の順位には影響しない、とされています。「不一致はスパム判定で順位が落ちる」という説明は、この記述とは一致しません。

実装パターン

Next.js での実装例

export default function Article({ post, siteUrl }) {
  const url = `${siteUrl}/articles/${post.slug}`;
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    description: post.description,
    datePublished: post.date,
    dateModified: post.updatedAt ?? post.date,
    inLanguage: "ja",
    mainEntityOfPage: { "@type": "WebPage", "@id": url },
    author: { "@type": "Organization", name: "Growth Lab編集部", url: `${siteUrl}/about` },
    publisher: { "@type": "Organization", name: "Growth Lab", url: siteUrl },
  };
  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      {/* 本文 */}
    </>
  );
}

frontmatter の値から組み立てると、本文と JSON-LD の食い違いが起きにくくなります。

検証手順

ツールごとに確かめられる範囲が違うので、順に使い分けます。

1. Schema Markup Validator（schema.org が運営）: schema.org の語彙として正しいか（型名・プロパティ名の綴り、入れ子の構造）を確かめる
2. リッチリザルト テスト（Google）: Google 検索の機能として解釈できるかを確かめ、critical エラーを直す
3. URL 検査ツール（Search Console）: 公開後、Google がそのページをどう見ているかを確かめる。2 と 3 の順序は Google の Article structured data の手順どおり
4. Search Console の Generative AI performance report: AI 機能での表示状況を測る。Google の最適化ガイドが測定手段として挙げている（Optimizing your website for generative AI features on Google Search）

4 は構造化データの有無と引用の因果を示すものではありません。実装前後で比べる場合も、同時期の本文改訂などの影響と切り分けられない点に注意します。AI 引用の測り方全般は LLM引用の計測方法 にまとめています。

アンチパターン

• 「構造化データを入れれば AI に引用される」と期待する: Google は AI 機能の条件ではないと明言している
• 終了したリッチリザルトを目的に新規実装する: FAQ・HowTo のリッチリザルトは Google 検索に表示されない
• schema と本文の不一致: ガイドライン違反。リッチリザルトの資格を失う
• プロパティ名を推測で書く: schema.org の型ページで実在を確かめ、Schema Markup Validator で検査する
• 関係のない schema を盛る: ページの主な内容を表す型に絞る
• 構造化データだけで GEO が完結すると思う: 本文の質・構造・鮮度が前提（citation-friendly 構造 / 鮮度維持）

Growth Lab の実装

本サイトの記事ページが出力する構造化データは次のとおりです。

• 全記事に BlogPosting（見出し・説明・公開日・更新日・著者・発行者・画像など）。値は記事の frontmatter から組み立てる
• frontmatter に FAQ を持つ記事に FAQPage を出力する実装を 2026年9月に追加した（本番への反映は順次）。Google の FAQ リッチリザルトは終了しているため、リッチリザルトは期待していない
• HowTo は出力しない

本文側は citation-friendly 構造 に沿って、見出しと要約で内容が伝わるように書いています。構造化データは本文の内容を機械可読に言い直したもの、という位置づけです。

FAQ

Q. 構造化データを入れれば必ず AI に引用されますか？ A. いいえ。Google は AI Overviews / AI Mode に表示されるための特別な構造化データは不要としています。前提はページがインデックスされ、スニペット付きで表示できることです。

Q. では構造化データは入れなくてよいのですか？ A. Google はページ理解に構造化データを使い、リッチリザルトの対象にもなるため、SEO の一部として使い続けることを勧めています。記事ページなら BlogPosting から始めるのが無理のない選択です。

Q. JSON-LD と Microdata、どちらを使うべき？ A. JSON-LD です。Google が推奨しており、本文の HTML と分けて管理できます。

Q. FAQPage はもう外すべきですか？ A. 本文に見えている FAQ と一致していれば、外すかどうかは急いで決めなくてかまいません（構造化データのガイドラインが求めるのは、ページの内容との一致です）。ただし FAQ リッチリザルトは 2026-05-07 以降表示されないので、それを目的に新規実装する理由はありません。

Q. ChatGPT 検索や Perplexity は構造化データを読みますか？ A. 各社の公式な仕様説明を確認できなかったため、本記事では断定しません。検証するなら、自社サイトで実装前後を比べ、本文改訂など他の変化と切り分けて見る必要があります。

まとめ

構造化データは AI の引用に直接効くとは言えません。Google は AI 機能に特別な schema.org 構造化データは不要と明言しており、Google 以外の生成 AI については一次資料で確認できません。それでも、Google はページ理解に構造化データを使い、Article / BlogPosting は検索結果のタイトル・画像・日付の表示に役立ちます。FAQ・HowTo のリッチリザルトは終わっているので、記事ページは BlogPosting を正しく書き、本文と一致させ、Schema Markup Validator とリッチリザルト テストで検証する、という地道な実装が現実的な答えです。

参考

• AI features and your website（Google Search Central）
• Optimizing your website for generative AI features on Google Search（Google Search Central）
• Intro to How Structured Data Markup Works（Google Search Central）
• General Structured Data Guidelines（Google Search Central）
• Latest Google Search Documentation Updates（Google Search Central）
• schema.org
• Generative Engine Optimization Guide（COSEOM）
• citation-friendly 構造（社内）
• AI検索の鮮度維持戦略（社内）

References

• Article structured data（Google Search Central）
• リッチリザルト テスト（Google）
• Schema Markup Validator（schema.org）
• schema.org BlogPosting
• schema.org Article スキーマ仕様