AI検索のための構造化データ
検索エンジンやAIシステムが組織、コンテンツ、商品、回答を正しく識別できるようにするための、JSON-LDの選定・実装・検証・保守方法を解説します。
クイックアンサー
構造化データは、AI検索システムがページ上のエンティティ、著者、日付、商品、ユーザーに表示される回答を識別するのに役立ちます。ただし、ページそのものの代わりにはなりません。適用できるスキーマタイプの中で最も具体的なものを選び、マークアップする情報はすべてページ上に表示し、正確に保ちましょう。エンティティ同士は安定した識別子で結び付け、テンプレートを変更するたびにJSON-LDを検証してください。
主要なポイント
- マークアップの役割は、ページに表示されている事実を明確にすることです。事実を捏造したり、訪問者にコンテンツを隠したりしてはいけません。
- Organization、Person、Article、Product、FAQPage、HowToは、それぞれ異なるエンティティ情報を明確にします。
- 安定した@idとsameAsによる参照は、複数のページに登場する同一のエンティティを結び付けるのに役立ちます。
- リッチリザルトの表示対象になることと、AIの回答で引用されることは別の成果です。
- 検証では、構文、語彙、表示内容との事実の一致、本番環境でレンダリングされたHTMLを確認する必要があります。
構造化データはAI検索でどのような役割を果たしますか?
JSON-LDは、誰が公開したのか、どのエンティティについて説明しているのか、いつ変更されたのか、各要素がどう関係しているのかを、機械が理解できる明示的なグラフとして表します。これにより、情報の抽出や出典の特定における曖昧さを減らせます。ただし、検索エンジンにページのクロール、信頼性の評価、順位付け、引用を強制するものではありません。まずページへのアクセスと表示コンテンツを適切に整え、そのうえで構造化データを実装しましょう。
どのスキーマタイプを使うべきですか?
| ページの目的 | 主なタイプ | 重要なプロパティ |
|---|---|---|
| 企業・ブランドの紹介 | Organization | name, url, logo, sameAs |
| 記事コンテンツ | ArticleまたはBlogPosting | headline, author, datePublished, dateModified |
| 氏名を公開している専門家の紹介 | Person | name, jobTitle, affiliation, sameAs |
| 商品・ソフトウェアの紹介 | ProductまたはSoftwareApplication | name, brand, offers、および該当する場合はoperatingSystem |
| ページ上に表示される質問と回答 | FAQPage | ページの内容と一致するQuestionとacceptedAnswer |
| ページ上に表示される順序付きの手順 | HowTo | nameと、順序どおりに記述したすべての手順 |
一貫性のあるエンティティグラフを構築するには?
- 組織を表す安定した@idを1つ決め、サイト全体で再利用します。
- 必要に応じて、publisher、provider、brand、affiliationからその組織を参照します。
- Personエンティティは、氏名が明らかで、プロフィールや資格・経歴が公開されている実在の人物にのみ作成します。
- sameAsには、そのエンティティの同一性を裏付ける信頼できるページを指定します。見つけたソーシャルメディアのURLをすべて追加するものではありません。
- 関係が具体的で、ページ上でも確認できる場合は、mainEntityまたはaboutを使って各ページを主なエンティティやトピックに結び付けます。
- 名称、URL、ロゴ、日付、価格、在庫状況をページの表示内容と常に一致させます。
安全に実装するための手順は?
JSON-LDは、ページの表示に使うものと同じ正本データから生成します。これにより、価格、在庫状況、日付、FAQの回答、著者情報の食い違いを防げます。最終的なHTMLにスクリプトが含まれるようサーバー側でレンダリングし、シリアライズする値を安全にエスケープしてください。また、プラグインと独自コードによって、互いに矛盾するエンティティが複数追加されないようにしましょう。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data for AI search",
"author": { "@id": "https://example.com/#organization" },
"datePublished": "2026-09-22",
"dateModified": "2026-09-22",
"mainEntityOfPage": "https://example.com/guide"
}構造化データはどのように検証すべきですか?
| 確認項目 | 確認すること | 不備の例 |
|---|---|---|
| 構文 | JSONの構文は正しいか? | 末尾の余分なカンマ、安全でないシリアライズ |
| 語彙 | タイプとプロパティはschema.orgで定義された有効な用語か? | タイプに適合しないプロパティの使用 |
| 表示要件 | 対象の検索機能は、このマークアップに対応しているか? | 対応していないリッチリザルトの表示を期待する |
| 内容の一致 | 重要な記述がすべてページの表示内容と一致しているか? | 非表示のFAQ、表示内容と異なる価格 |
| 配信 | 本番環境のHTMLにスクリプトが含まれているか? | クライアント側だけで挿入したため、クローラーが取得できない |
特に悪影響の大きい構造化データの誤りは?
- ページ上に回答が表示されていない質問にFAQPageを追加する。
- 訪問者が内容を確認・検証できない総合評価やレビューを使用する。
- 価格、在庫状況、著者、dateModifiedの値を古いまま公開する。
- テンプレートごとに、名称やURLが一致しない別々のOrganizationエンティティを作成する。
- すべてのページに、互いに関連のない複数の主要タイプを指定する。
- バリデーターの検証に合格すれば、品質、表示要件への適合、インデックス登録、引用まで証明できると思い込む。
AI検索での露出に対するスキーマの効果を測るには?
マークアップの修正後に、検索エンジンがエンティティをより正確に識別・説明できるようになったかを測定します。検証の実施範囲、抽出エラー、該当する場合は検索結果の拡張表示、クローラーの訪問状況、固定したプロンプト群に対する引用の正確性を追跡しましょう。コンテンツ、リンク、クロールのアクセス条件も同時に変更した場合は、露出の変化をスキーマだけの効果と判断しないでください。
ステップ・バイ・ステップ
- 1ページの主なエンティティを特定する
ページに表示されている内容の目的に合う、最も具体的なタイプを選びます。
- 2表示されている事実をプロパティに対応付ける
訪問者が確認できるプロパティを洗い出し、裏付けのない情報や非公開の情報は除外します。
- 3安定した識別子でエンティティを結び付ける
組織や人物の@id値と、慎重に選定したsameAsの参照先を再利用します。
- 4共通データからJSON-LDを出力する
表示内容とのずれを防ぐため、ページの表示に使うものと同じコンテンツソースからマークアップを生成します。
- 5本番環境で検証する
デプロイ後に、構文、語彙、表示内容との一致、サーバー側でレンダリングされた最終レスポンスを確認します。
よくある質問
- スキーママークアップを実装すれば、AIによる引用は保証されますか?
- いいえ。構造化データは曖昧さを減らし、出典の特定を助けますが、引用されるかどうかは、クロールのアクセス可否、コンテンツの品質、関連性、権威性、鮮度、クエリに対して使われる情報検索システムにも左右されます。
- JSON-LDはmicrodataより優れていますか?
- 一般にJSON-LDは、表示用のHTMLに属性を混在させずに済むため、生成・保守・検証が容易です。重要なのは、訪問者が閲覧できるコンテンツをマークアップが正確に表していることです。
- FAQスキーマに、訪問者には表示しない回答を含めてもよいですか?
- 含めるべきではありません。FAQPageのマークアップに記述する質問と回答は、ページに表示される内容と一致している必要があります。非表示の回答や表示内容と矛盾する回答は、事実の不一致を生み、検索機能のガイドラインに違反する可能性があります。
- すべてのページにOrganizationスキーマが必要ですか?
- 安定したOrganizationエンティティをサイト全体から参照することはできますが、矛盾する完全な定義を重複して記述するのは避けてください。組織を一貫した形で定義し、関連ページからその安定した@idを参照しましょう。
- JSON-LDはどのくらいの頻度で監査すべきですか?
- テンプレート、CMS、価格、著者、商品、ナビゲーションを変更した後に監査し、通常のリリース工程にも構造化データの検証を組み込んでください。時間の経過で変わるプロパティは、ページに表示するコンテンツと同じデータソースから更新する必要があります。