構造化データでAI検索の引用は増えるのか。実装して分かったこと
構造化データ（JSON-LD）を入れても、それだけでAIの回答に引用される件数が増える証拠は今のところ確認できていない。ただし、AIが自社の情報を正しく解釈する精度は上がる感触があり、入れる価値はあると考えている。以下、自社サイトで実装した際の判断基準と手順を共有する。
なぜ「引用が増える」とは言えないのか
Google検索のリッチリザルトと違い、ChatGPTやPerplexityなどのAI検索は、構造化データを直接の引用トリガーとして使っているという仕様は公開されていない。AIが参照するのは基本的にページの本文テキストであり、JSON-LDはあくまで補助情報という位置づけだと推測される（ここは推測であり、各社のクローラー仕様が公開されていない以上、断定はできない）。
一方で、構造化データには「情報の意味づけを明確にする」という役割がある。例えば記事のFAQ部分がただの箇条書きだと、AIは「これは質問と回答のペアだ」と解釈するのに文脈から推測する必要がある。FAQPageスキーマで明示しておけば、その推測の手間が減り、誤読のリスクが下がる。これは引用数の増加ではなく、引用された際の正確性に寄与する話だと捉えている。
どのスキーマから入れるべきか
全部入れる必要はない。効果とコストのバランスで優先順位をつけた。
| スキーマ | 目的 | 優先度 | 実装コスト |
|---|---|---|---|
| Organization | 会社の基本情報（名称・ロゴ・SNS）をAIに正確に伝える | 高 | 低（一度作れば全ページ共通） |
| Article | 記事の著者・公開日・更新日を明示する | 高 | 中（記事ごとに更新日を管理） |
| FAQPage | Q&A形式のコンテンツの構造を明示する | 中 | 中（本文と内容を一致させる必要） |
| BreadcrumbList | サイト内の階層構造を示す | 低 | 低（テンプレート化しやすい） |
OrganizationとArticleは、AIが「誰が書いた情報か」「いつの情報か」を判断する材料になりやすいので優先度を高くした。FAQPageは本文とスキーマの内容が食い違うとむしろマイナスになるため、運用の手間を考えると中程度に置いている。BreadcrumbListはAI検索への影響は限定的だと感じているが、実装コストが低いので入れておいて損はない。
最小構成の実装例
記事ページなら、以下の2つだけでも十分に機能する。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事タイトル",
"datePublished": "2024-01-10",
"dateModified": "2024-03-01",
"author": {
"@type": "Organization",
"name": "合同会社SUTEKINA JIKAN"
}
}Organizationは全ページ共通のヘッダー・フッターに一度埋め込めば済む。ここで注意したいのは、本文に書いていない情報をスキーマだけに書かないこと。AIも人間の検索エンジンも、本文とスキーマの内容が矛盾している場合は本文を優先する傾向があると考えられるため、スキーマは「本文の要約」であるべきで、「本文にない主張」を追加する場所ではない。
どこまでやると意味がなくなるのか
schema.orgには数百種類のタイプが定義されているが、ここまでは要らないと感じた部分がある。
- Productスキーマの過剰な属性埋め：価格・在庫・レビュー数まで細かく埋めても、AI検索での表示に反映されるかは不明で、更新の手間だけが増える。ECサイトでない限り優先度は低い。
- HowToスキーマの手順の細分化：手順を1ステップずつ全部スキーマ化すると、本文の修正のたびにスキーマも直す必要が出て、メンテナンスコストが実利を上回りやすい。
- 複数タイプの重複指定：同じページにArticleとBlogPostとNewsArticleを全部入れるようなケースは、AIやクローラーの解釈をむしろ複雑にする可能性がある。1ページ1タイプを基本にした方がいい。
入れれば入れただけ良くなるわけではなく、本文の更新と同期を取れる範囲に絞るのが実務上の目安になる。
実装後に何を確認すればいいのか
入れて終わりにせず、以下の手順で検証している。
- Googleのリッチリザルトテスト（Search Console内の機能）で構文エラーがないか確認する。JSON-LDは1文字のカンマ抜けでも全体が無効になるため、まずここでエラーゼロを確認する。
- Schema.org Validatorで、指定したプロパティがスキーマの仕様に沿っているか確認する。Googleのツールは検索表示用のチェックに寄っているため、仕様準拠の確認はこちらで補う。
- 本文との整合性を目で確認する。ツールはエラーの有無しか見てくれないので、スキーマに書いた内容が実際の本文と一致しているかは人力でチェックするしかない。
- AI検索側での挙動を定点観測する。ChatGPTやPerplexityに自社名や記事タイトルで質問し、引用される内容に変化がないか月次で見ている。ここでの変化は構造化データ単体の効果と断定できないため、あくまで参考値として扱っている。
結論として何をすればいいか
OrganizationとArticleだけは入れておく。FAQPageは本文と一致させられる場合に限り追加する。BreadcrumbListはテンプレート化できるなら入れておいて損はない。それ以上に手を広げる前に、まず本文そのものの情報の正確さと更新頻度を見直す方が、AI検索での扱われ方には効いてくると感じている。