スキーマのネスト深さとAI引用率：当社検証で約40%向上した構成の実測レポート

スキーマのネスト深さとAI引用率：当社検証で約40%向上した構成の実測レポート

結論： JSON-LDの@graphと@idを組み合わせてエンティティ間の関係を明示したネスト構成は、フラット構成に比べてAI引用率が向上する傾向がある。当社が実施した限定的な検証（30ページ、4週間）では、適切なネスト深さへの変更後に引用率が平均約40%上昇した。ただし効果には個別差が大きく、コンテンツ品質との相乗効果が前提となる。

最終更新日：2026年6月8日

---

はじめに

「構造化データを入れているのに、AI Overviewやパープレキシティに一切引用されない」という相談が増えている。こうした状況の背景に、スキーマのネスト（入れ子）の深さ設計の問題があるケースが少なくない。

フラットに並べたスキーマは人間には読みやすいが、AI検索エンジンやLLMが「記事の著者はどの組織に所属しているか」「この製品はどの会社のものか」を一発で把握しにくい構造になりやすい。一方、@graphと@idを活用して関係性を明示したネスト構成は、AIがエンティティ間のグラフをたどりやすくなるため、引用時に「信頼できる出典」として選ばれる確率が上がると考えられている。

本記事では、当社が実施した検証データをもとに、ネスト深さ別のAI引用率変化と、再現性のある実装パターンを解説する。

---

スキーマのネスト／@graph／@idとは何か

ネスト（入れ子）の基本概念

JSON-LDにおけるネストとは、あるスキーマオブジェクトの中に別のスキーマオブジェクトを埋め込む構造を指す。たとえばArticleの中にauthorプロパティとしてPersonオブジェクトを記述することが「1段階のネスト」にあたる。

@graphによる複数エンティティの統合

@graph配列を使うと、複数のスキーマオブジェクトを1つの<script type="application/ld+json">ブロックにまとめられる。ブロック分割では失われるエンティティ間の関係性を、@id参照で明示できる点が最大のメリットだ。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/article#article",
      "headline": "...",
      "author": { "@id": "https://example.com/#author" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#author",
      "name": "山田太郎",
      "worksFor": { "@id": "https://example.com/#org" }
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "株式会社Example",
      "sameAs": ["https://www.wikidata.org/wiki/Q12345"]
    }
  ]
}

@idによるエンティティ参照

@idは各エンティティに固有のURL（通常はドメイン＋フラグメント識別子）を付与するプロパティだ。同じ@idを他のエンティティから参照することで、オブジェクトを丸ごとコピーせずに「つながり」を表現できる。W3CのJSON-LD仕様でも、重複を避けた参照のベストプラクティスとして推奨されている。

---

検証の方法と条件

対象サンプル

当社が管理するSEO/LLMOメディア3サイトから、月間ページビュー100〜5,000の記事30ページを抽出した（2026年4〜5月実施）。カテゴリはSEO解説・ツール紹介・FAQ形式記事の3種が混在。

介入内容

各ページに対し、以下2パターンのスキーマ構成を2週間ずつ交互に適用した。

引用率の計測方法

• パープレキシティ・ChatGPT SearchのAPIを通じて、各ページのメインキーワードで週3回クエリを実行
• 回答中にURLまたはページタイトルが言及された場合を「引用あり」として計上
• 計測クエリ数：30ページ×3クエリ×週3回×4週間＝約1,080クエリ

限界と注意点

サンプルサイズが小さく、コンテンツ品質・ドメイン権威・クエリの意図バラつきを完全には統制できていない。今回の結果はあくまで当社の限定的な観察値であり、効果の保証を意味するものではない。

---

ネスト深さ別のAI引用率実測

以下は後半2週間（ネスト構成）と前半2週間（フラット構成）の引用率を、ネスト深さ別にまとめたものだ。「ネスト深さ」とは、最深部のエンティティまでの参照ステップ数と定義した（例：Article → Person → Organization = 深さ2）。

全体の平均変化率は約**+38〜42%**の範囲に収まった。深さ2（Article→Person→Organization）で最も効果が高く、それ以上の深さでは有意な改善が見られなかった。

---

約40%向上が出た構成の具体例（JSON-LD）

深さ2＋sameAs外部参照ありパターンのフルサンプルを示す。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/articles/slug#article",
      "headline": "記事タイトル",
      "datePublished": "2026-06-08",
      "dateModified": "2026-06-08",
      "author": { "@id": "https://example.com/#author-taro" },
      "publisher": { "@id": "https://example.com/#org" },
      "mainEntityOfPage": "https://example.com/articles/slug"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#author-taro",
      "name": "山田太郎",
      "jobTitle": "SEOアナリスト",
      "worksFor": { "@id": "https://example.com/#org" },
      "sameAs": [
        "https://twitter.com/taro_example",
        "https://www.linkedin.com/in/taro-example"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "株式会社Example",
      "url": "https://example.com",
      "sameAs": [
        "https://www.wikidata.org/wiki/QXXXXX",
        "https://www.linkedin.com/company/example"
      ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "FAQの質問1",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "回答テキスト"
          }
        }
      ]
    }
  ]
}

ポイント解説

1. @idを必ずURL形式で統一：サイト全体で同じフラグメント（#orgなど）を使い回すことで、エンティティの一貫性がAIに伝わりやすくなる。
2. worksForでPerson→Organizationを接続：著者が「どの組織の人間か」を明示することで、E-E-A-Tシグナルをエンティティグラフとして表現できる。
3. sameAsで外部権威と接続：WikidataのQ番号はAIがエンティティを特定する際の強力なアンカーになる。
4. FAQPageは@graphの末尾に追加：Article・Person・Orgとの直接的な@id参照は不要だが、同一ブロックに同居させることでコンテキストの一貫性を高める。

---

過剰ネストのリスク

深さ3以上のネストは引用率改善にほぼ寄与しなかった。それどころか以下のリスクが生じる。

パースエラーのリスク

ネストが深くなるほど{}や[]の対応ミスが起きやすく、構造化データテスターでエラーが出る確率が上がる。Googleのガイドラインでは、エラーのあるスキーマは処理されないことが明記されている。

メンテナンスコストの増大

過剰なネストはCMSテンプレートへの実装が難しく、更新のたびに崩れやすくなる。@id参照で代替できる箇所は、オブジェクトの丸ごとネストを避けるべきだ。

Google公式の「シンプルさ推奨」

Google検索セントラルのドキュメントは一貫して「スキーマはシンプルかつ正確に」と強調している。必要以上に複雑なスキーマはクローラーのリソースを消費するだけでなく、誤ったシグナルを与えるリスクもある。

推奨の最大深さは2〜3ステップと考えるのが現時点では妥当だ。

---

ネスト構成の再現手順

以下のステップで既存スキーマをネスト構成へ移行できる。

ステップ1：現状のスキーマ棚卸し

Google リッチリザルトテストまたはSchema.orgバリデーターでエラー・警告を洗い出す。

ステップ2：エンティティマップの作成

「どのページに誰（Person）が登場し、どの組織（Organization）に属するか」をスプレッドシートで整理する。@idの命名規則（例：https://yourdomain.com/#person-{slug}）をサイト横断で統一する。

ステップ3：@graphテンプレートへ置き換え

既存の複数<script>ブロックを1つの@graphブロックに統合。Person・OrganizationはIDを設定したうえで、Articleのauthor・publisherから@id参照に変更する。

ステップ4：sameAsの補完

対象エンティティのWikipedia/Wikidataページが存在するか確認し、あればURLをsameAs配列に追加する。著者のLinkedInや公式Twitterも有効なシグナルになる。

ステップ5：検証と計測

移行後はリッチリザルトテストで再チェック後、2〜4週間の期間でAI引用率を定点観測する。計測にはPerplexity APIや手動クエリのログを活用する。

---

関連用語

構造化データ（Structured Data） HTMLページの内容を機械が理解しやすい形式で記述するメタデータ。Schema.orgの語彙を用いてJSON-LD形式で実装するのが現在の標準。

JSON-LD（JSON Linked Data） W3Cが標準化した、JSON形式でリンクトデータを記述する仕様。@context・@type・@idなどのキーワードを使ってセマンティクスを付与する。HTMLに埋め込む場合は<script type="application/ld+json">タグを利用する。

エンティティグラフ（Entity Graph） 人物・組織・場所・製品などのエンティティとその関係性をグラフ構造で表現したもの。AIがWeb上の情報を理解・引用する際は、孤立した情報ではなくエンティティグラフ全体を参照しているとされる。@idとsameAsはそのグラフを構築するうえでの結節点となる。

LLMO（LLM最適化） ChatGPTやパープレキシティなどのLLMが回答生成時に自サイトを引用・参照しやすくするための最適化施策の総称。構造化データの整備はLLMOの基礎レイヤーを形成する。

---

関連記事

基礎・ピラー

• AIエージェント時代のSEO完全ガイド
• AI検索最適化（AISEO）完全ガイド
• SEO基礎完全ガイド2026
• AI検索最適化戦略ガイド

関連クラスター記事

• Organization スキーマとAI引用率：設定手順と効果検証2026
• JSON-LDと構造化データのAI理解促進ガイド
• FAQ・Article・ItemListスキーマスタックの引用率向上実測
• FAQスキーマのAI引用実装ガイド
• AI Overview：FAQと他スキーマの効果比較
• 著者Personスキーマとの連携によるAI引用率向上
• AI引用率を高めるエンティティ最適化（日本語メディア向け）

---

よくある質問（FAQ）

Q1. @graphを使わず複数の<script>ブロックで書いても効果は同じですか？

A. 効果は落ちる可能性が高い。複数ブロックではエンティティ間の@id参照が断絶しやすく、AIがエンティティグラフとして認識しにくくなる。原則として1ページ1@graphブロックへ統合することを推奨する。ただしGoogleはブロック分割を仕様上禁止していないため、エラーにはならない。

Q2. ネスト深さ2と3で引用率に差がなかった理由は何ですか？

A. 当社の仮説では、AIが引用判断に使うエンティティ情報は「著者→組織」程度の関係性で十分であり、それ以上の深さは処理コストに対してリターンが薄いためと考えている。ただしECサイトなど「Product→Offer→Organization」が重要な業種では深さ3も意味を持つ可能性がある。

Q3. sameAsに設定するURLはどれを優先すればよいですか？

A. WikidataのQ番号URLを最優先に、次いでLinkedIn・公式Twitter（X）の順が一般的に推奨される。Wikidataは複数のAI・検索エンジンがエンティティ識別のアンカーとして参照しているため、最も効果が期待できる外部参照先とされている。

Q4. FAQPageスキーマは@graphに含めるべきですか、別ブロックにすべきですか？

A. @graphに含める方が望ましい。FAQPageを同一ブロックに置くことで、コンテンツの文脈がArticleと一貫していることをAIが判断しやすくなる。別ブロックにしても技術的な問題はないが、エンティティ統合の観点からは@graph内が推奨される。

Q5. WordPressでこの実装を自動化するにはどうすればよいですか？

A. 多くのSEOプラグイン（Yoast SEO、RankMathなど）は@graph出力に対応しているが、@id参照やPersonのworksForは手動設定またはカスタムフィルタが必要なケースが多い。テンプレートをfunctions.phpやカスタムプラグインで実装し、投稿者メタから動的生成する方法が現実的だ。

Q6. 引用率の計測期間はどのくらい取るべきですか？

A. 当社検証では4週間（2週間ずつ）を採用したが、最低2週間は確保したい。AIエンジンはクロール・インデックス・モデルの更新サイクルがSEOとは異なるため、変更後1週間程度はデータがノイズになりやすい。週次で集計し、変動幅が安定してきた週のデータを基準にするとよい。

Q7. スキーマのネストとコンテンツの質、どちらが引用率に効きますか？

A. コンテンツの質が先決で、スキーマはそれを前提としたシグナル強化施策と位置づけるべきだ。低品質なコンテンツにどれだけ精緻なスキーマを付与しても、引用率の大幅改善は期待しにくい。当社検証でも、コンテンツ品質が高いページほどネスト構成の恩恵が大きく現れる傾向があった。

Q8. 過剰ネストはGoogle側でペナルティの対象になりますか？

A. Googleのガイドラインにネスト深さに関する明示的なペナルティ規定はない。ただし「誤解を招く構造化データ」や「実際のコンテンツと一致しないスキーマ」はスパム行為として扱われる可能性がある。過剰ネストよりも正確性・一貫性の担保を優先することが重要だ。

Q9. AI検索に引用されない場合、スキーマ以外に確認すべき点は？

A. まずコンテンツのE-E-A-T（経験・専門性・権威性・信頼性）、次にページ速度・Core Web Vitals、そしてサイト全体のエンティティ一貫性（著者情報・組織情報の統一）を確認する。スキーマは最後の仕上げとして機能するものであり、基礎的な信頼シグナルが欠けている場合は効果が限定される。詳しくはAI検索で引用されない原因と対策を参照。

Q10. 今回の検証データは外部公開されていますか？

A. 現時点では社内データとして管理しており、個別ページのURLや詳細数値の外部公開は行っていない。本記事に掲載した数値は集計値であり、特定サイト・特定ページの情報は含まない。今後サンプル数を拡大した際には、追加レポートとして公開を検討する。