スキーママークアップのネスト（@idと@graph）

要点 — ネストとは、スキーママークアップをばらばらのブロックとして置くのではなく、相互に接続することです。@id は、組織や著者などのエンティティに付ける一意の名前（通常はページURLに #tag を加えたもの）で、他のエンティティは詳細を繰り返さずにそれを参照できます。@graph を使えば、関連する複数のエンティティを1つのコードブロックにまとめられます。組織を一度だけ宣言し、各ページでは参照することで、同じブロックのコピー＆ペーストを避けられます。

ネストが解決する問題

サイトに、名前・ロゴ・ソーシャルプロフィールへのリンクを持つ Organization があり、各ブログ記事には著者と発行者を持つ Article があるとします。ネストしなければ、すべての記事のマークアップ内に組織名、ロゴ、各ソーシャルリンクを丸ごと記述することになります。ロゴを変えるだけで、40か所を更新しなければなりません。

ネストはこの重複を解消します。組織を一度だけ宣言して安定した識別子を与え、ほかの場所ではその識別子を参照します。スキーママークアップとJSON-LDの基礎がまだなら、先に構造化データのハブを読んでから戻ってきてください。

@id — エンティティに付ける名前

@id は、1つのエンティティを表す一意の識別子です。一般には、実際のページURLに次のようなフラグメントを加えます。

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "logo": "https://example.com/logo.png"
}

この "@id": "https://example.com/#organization" がエンティティの名前になります。別の場所で「発行者はExample Co」と示すときは、詳細をすべて書き直さず、この名前だけを参照します。

{
  "@type": "Article",
  "publisher": { "@id": "https://example.com/#organization" }
}

小さいながら重要な点として、@id は内部のリンク機構であり、公開するページそのものではありません。実際に取得できるURLである必要はなく、自社ドメインのURLにフラグメントを付けるのが標準的です。そのフラグメント自体が独立したページとして読み込めなくても構いません。これは、実在するページを表す url プロパティとは異なります。

@graph — 関連するエンティティをまとめる

@graph を使うと、複数のエンティティを別々の場所に散らさず、1つのコードブロックに列挙できます。3個の <script> ブロックではなく、次のように1個にまとめます。

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Co" },
    { "@type": "WebSite", "@id": "https://example.com/#website", "publisher": { "@id": "https://example.com/#organization" } }
  ]
}

先頭で @context を一度だけ記述し、内部のエンティティ同士を @id で参照させます。関連する要素が増えるほど、整理しやすく保守も容易になります。

正しく実装するための要点

大半のケースは、次の2つのルールでカバーできます。

• 一貫させる。 同じエンティティには、どこでも同じ @id 文字列を使います。あるページでは組織が #organization、別のページでは #org なら、検索エンジンは同一のものと判断できません。
• 存在しないものを参照しない。 Article の著者が {"@id": "#author-jane"} を参照するなら、#author-jane が @type と詳細を伴って実際に宣言されていることを確認します。定義していないエンティティへの参照は、気づかれないまま失敗します。

期待値も現実的に保ちましょう。適切なネストは検索エンジンによるエンティティの理解を助け、データの重複を減らしますが、それだけで順位が上がったりリッチリザルトが利用可能になったりするわけではありません。

コピーして使える2つの標準パターン、グラフを壊す3つのミス、Googleの文書が確認していることと明言していないことまで知りたい場合は、Advancedタブに切り替えてください。

エンティティを捏造せずJSON-LDグラフを監査する

Audit the JSON-LD below as a graph.

1. Inventory every declared node: @id, @type, and where it is declared.
2. Inventory every @id reference made by another node.
3. Flag exact orphan references, duplicate full declarations, case/fragment drift,
   unstable-looking IDs, and relationships that point at the wrong entity type.
4. Distinguish a reference-only object ({"@id":"..."}) from a full declaration.
5. Do not assume an @id resolves across pages and do not invent missing facts.
6. Return (a) a findings table, (b) a minimal corrected graph using the existing
   facts only, and (c) questions for facts that cannot be verified from the input.

JSON-LD:
[PASTE SCRIPT CONTENT]

テンプレートを比較する場合は、レンダリング済みの2つのグラフを提示し、両者で予期せず変化するIDを列挙させます。発行者のような安定したエンティティは大文字・小文字を含め同じ @id を維持し、ページ固有のエンティティは各正規ページに固有であるべきです。

レンダリング済みJSON-LDから孤立参照と重複IDを探す

このコードをDevTools Consoleで実行します。すべてのJSON-LDブロックを解析し、配列と @graph をたどって、完全な宣言と参照専用の @id オブジェクトを分けます。

const documents = [...document.querySelectorAll('script[type="application/ld+json"]')]
  .flatMap((script, scriptIndex) => {
    try {
      return [{ scriptIndex, value: JSON.parse(script.textContent) }];
    } catch (error) {
      console.warn(`Invalid JSON-LD in script ${scriptIndex + 1}`, error);
      return [];
    }
  });

const declarations = new Map();
const references = [];

function walk(value, path, scriptIndex) {
  if (Array.isArray(value)) {
    value.forEach((item, i) => walk(item, `${path}[${i}]`, scriptIndex));
    return;
  }
  if (!value || typeof value !== 'object') return;

  if (typeof value['@id'] === 'string') {
    const keys = Object.keys(value).filter((key) => key !== '@id');
    if (keys.length) {
      const rows = declarations.get(value['@id']) ?? [];
      rows.push({ script: scriptIndex + 1, path, keys: keys.join(', ') });
      declarations.set(value['@id'], rows);
    } else {
      references.push({ id: value['@id'], script: scriptIndex + 1, path });
    }
  }

  Object.entries(value).forEach(([key, child]) =>
    walk(child, `${path}.${key}`, scriptIndex));
}

documents.forEach(({ value, scriptIndex }) => walk(value, '$', scriptIndex));

console.table(references.filter(({ id }) => !declarations.has(id)));
console.table([...declarations.entries()]
  .filter(([, rows]) => rows.length > 1)
  .map(([id, rows]) => ({ id, declarations: rows.length, locations: rows })));

孤立参照の表が空なのは良い兆候ですが、グラフが意味的に正しい証明にはなりません。大文字・小文字を区別するID、エンティティ型、正規URL、そしてこのページに必要な完全なグラフが実際に存在するかを確認してください。

要点 — ネストは、安定した一意のURI（通常は正規URLと #fragment）である @id を介してJSON-LDエンティティを接続し、エンティティの再宣言を避けます。@graph は関連エンティティを1つのスクリプトにまとめるキーワードです。Googleはネストと個別項目の両方が機能し、関連項目を @id で結ぶことを確認しています。ただし、@id がページをまたいで解決されるかは明言していません。安全な既定値は、一貫した @id と、それを必要とする各ページ上の完全なエンティティグラフです。覚えるべきパターンは、公開コンテンツの WebSite → WebPage → Article → Author と、ECの Product → Offer → Organization/seller の2つです。注意すべき障害は、不整合または一意でない @id、孤立参照（参照されるが宣言されていない @id。JSON-LDとして無効ではないものの意味的に不完全）、同じエンティティの完全な宣言の重複です。最後のものは保守上の罠で、同一エンティティの反復はJSON-LDの規則で統合されますが、本当に異なるエンティティに同じ @id を使うと競合します。これは曖昧さと重複を減らすエンティティ理解の仕組みであり、単独で順位やリッチリザルトを生む施策ではありません。

範囲：入門ではなく詳細解説

この記事は、JSON-LDとは何か、なぜ推奨形式なのかをすでに理解している前提です。スキーママークアップでは基礎と @id／@graph の概要を説明しています。ここでは、実際の仕組み、標準的なノードパターン、グラフを静かに壊す具体的なミスまで掘り下げます。形式の基本や <script> ブロックの配置を知りたい場合は、関連ページのJSON-LDを参照してください。

@id — 取得可能なURLではなく、安定した識別子

@id はJSON-LDエンティティに一意のURIを割り当て、ほかのエンティティがそれを参照できるようにします。信頼できる資料に共通する慣例は、絶対形式の正規URLに意味の分かるフラグメントを加えることです。

"@id": "https://example.com/#organization"
"@id": "https://example.com/#website"
"@id": "https://example.com/team/jane-doe/#person"

ここでは、よくある誤解が2つあります。

• 解決可能である必要はありません。 JSON-LD仕様によれば、@id の役割はノードの識別、つまりエンティティに一意で安定した「名前」を与えることであり、取得可能性ではありません。自社ドメインのURLにフラグメントを付けるのが標準的で、そのURLが独立したページとして読み込める必要はありません。Sitebulbのノード識別子ガイドは、ノード識別子を “a unique ‘name’ for an entity, which is publicly accessible and can be looked up or linked to.” (翻訳) 「公開され、検索やリンクが可能な、エンティティに対する一意の『名前』」と説明しています。
• @id は url ではありません。 両者は別の役割を持つプロパティです。@id はグラフ内のノードを識別し、url はエンティティについての実在し、取得可能なページを表します。Organization は、https://example.com/#organization という @id と https://example.com/ という url の両方を持てますし、多くの場合そうすべきです。

また、@id の値は大文字・小文字を区別します。#Organization と #organization は別のエンティティです。規則を1つ決め、そこから逸脱しないでください。

@graph — 関連エンティティを1つのブロックにまとめる

@graph は、複数のトップレベルエンティティを1つの <script type="application/ld+json"> ブロック内の配列に置き、@id で相互参照させるJSON-LDキーワードです。

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "...": "..." },
    { "@type": "WebSite", "@id": "https://example.com/#website", "...": "..." },
    { "@type": "WebPage", "@id": "https://example.com/post/#webpage", "...": "..." }
  ]
}

@graph はコンテナであって必須要件ではありません。 個々の項目に別々の <script> ブロックを使っても問題なく、Googleの文書も両方の方法が機能すると確認しています。@graph を選ぶ理由は保守性です。相互参照するエンティティが3つ以上あれば、各ブロックで @context を繰り返さず先頭に一度だけ記述でき、関係するものを1か所で管理できます。Yoastも本番環境でこのパターンを使い、スキーマ設計の文書で “avoid having to duplicate or repeat shared properties, and to reduce the amount of code/processing/overhead required.” (翻訳) 「共有プロパティの重複や反復を避け、必要なコード、処理、オーバーヘッドを減らせる」と説明しています。

なぜネストするのか、Googleは何を述べているか

Googleは2つの構造を文書化し、どちらも理解できると確認しています。構造化データに関する一般的なガイドラインには、“Google Search understands multiple items on a page, whether you nest the items or specify each item individually.” (翻訳) 「Google検索は、項目をネストする場合でも個別に指定する場合でも、ページ上の複数の項目を理解します」とあります。さらに、ネストを “when there is one main item, and additional items are grouped under the main item” (翻訳) 「主要な項目が1つあり、追加項目がその下にまとめられている場合」、個別項目を “when each item is a separate block on the same page.” (翻訳) 「各項目が同じページ上の別々のブロックである場合」と定義しています。

@id の公式な根拠に最も近い一節は次のものです。“…use @id in both the recipe and the video items to specify that the video is about the recipe on the page. If you didn’t link the items together, Google Search may not know that it can show the video as a Recipe rich result.” (翻訳) 「レシピと動画の両方に @id を使用し、その動画がページ上のレシピについてのものだと指定します。項目を関連付けなければ、Google検索はその動画をレシピのリッチリザルトとして表示できることを認識できない場合があります」。つまりGoogle自身の説明でも、2つの項目が関連していると伝える仕組みが @id です。

正確さのために補足すると、Googleの文書はこの原則を文章で示していますが、@graph と @id を組み合わせた実例コードは掲載していません。コード例はネストしたRecipeと2つの独立したトップレベル項目で、@id による相互参照は行っていません。以下の例はその空白を補います。

これは、スキーママークアップで説明したスキーマの2つの役割に直結します。適切なネストは、曖昧さや矛盾・重複したデータを減らすエンティティ理解の施策であり、それ自体がリッチリザルトを発生させるわけではありません。Article を Author に明確に結び付けても新しい検索結果機能は解放されませんが、関係は明瞭になります。

パターン1 — WebSite → WebPage → Article → Author

公開サイトの標準パターンです。発行者である1つの Organization と1つの WebSite を置き、ページごとに WebPage とその上の Article を置きます。author と publisher は再宣言せず @id で解決します。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Media",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/example-media/",
        "https://en.wikipedia.org/wiki/Example_Media"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Media",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/nesting-schema/#webpage",
      "url": "https://example.com/nesting-schema/",
      "name": "Nesting Schema Markup",
      "isPartOf": { "@id": "https://example.com/#website" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "url": "https://example.com/team/jane-doe/",
      "sameAs": ["https://www.linkedin.com/in/jane-doe/"]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/nesting-schema/#article",
      "mainEntityOfPage": { "@id": "https://example.com/nesting-schema/#webpage" },
      "headline": "Nesting Schema Markup",
      "author": { "@id": "https://example.com/team/jane-doe/#person" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

ここでは、author と publisher が1行の参照になっています。Person と Organization はそれぞれ一度だけ宣言されます。Article は WebPage に mainEntityOfPage で結び付き、その WebPage は WebSite の isPartOf、さらに WebSite は Organization を publisher として参照します。5つの孤島ではなく、接続されたグラフです。

パターン2 — Product → Offer → Organization（販売者）

これはEC版のパターンで、大規模になるほどネストが効きます。何千もの商品ページで販売者の Organization を再宣言する代わりに、一度だけ宣言し、seller として参照します。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://shop.example.com/#organization",
      "name": "Example Shop",
      "url": "https://shop.example.com/",
      "logo": "https://shop.example.com/logo.png"
    },
    {
      "@type": "Product",
      "@id": "https://shop.example.com/widget/#product",
      "name": "Deluxe Widget",
      "sku": "WIDGET-001",
      "brand": { "@type": "Brand", "name": "Example" },
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "seller": { "@id": "https://shop.example.com/#organization" }
      }
    }
  ]
}

Offer の seller は共有の Organization ノードを指します。同じ販売者エンティティを一度だけ宣言し、すべての商品から参照できます。バリエーションが非常に多い場合も、共有 @id の考え方を ProductGroup と各バリエーションの Product に拡張できます。これは別の仕組みではなく、このパターンの応用です。

グラフを壊す3つのミス

ここが監査の実務上の核心です。ネストが「機能しない」ときは、ほぼ必ず次の3つのどれかに該当します。

1. 不整合または一意でない @id の値

同じエンティティにページ間（または移行の前後）で異なる @id を与えると、検索エンジンや検証ツールは1つではなく無関係な別エンティティと見なします。逆に、本当に異なる2つのエンティティに同じ @id を使うのも問題です。修正方法は、{base-url}/#organization、{page-url}/#webpage、{profile-url}/#person などの厳密な規則を文書化し、機械的に適用することです。大文字・小文字は区別され、#author と #Author は同じではありません。

2. 孤立参照

@id を参照しているのに、どこにも宣言していない状態です。たとえば "author": {"@id": "https://example.com/#person-jane"} を書いたものの、テスト対象文書内にその @id を @type とプロパティ付きで宣言したノードがありません。正確には、JSON-LD仕様がノード参照、すなわち “a node object used to reference a node having only the @id key” (翻訳) 「@id キーだけを持ち、ノードを参照するために使われるノードオブジェクト」と呼ぶ {"@id": "..."} は、それ単体でも有効なJSON-LD構文であり、解析エラーではありません。問題は意味と利用者側にあります。「この記事の著者はこの人物」という関係が有用な情報へ解決されず、著者名、URL、sameAs が必要な機能や読者には何も届きません。検証ツールは宣言済みの各項目をエラーなしで解析することが多いため、特に見落としやすい問題です。不完全なグラフのまま公開しても気づけません。Momenticの@idガイドも、実環境でよくあるネストの失敗として挙げています。

3. 同じエンティティの完全な宣言を重複させる

孤立参照とは逆に、完全な Organization／Person オブジェクトを一度参照するのではなく、各ページのインラインに再宣言する状態です。ここでは2つの異なる事態を区別する必要があります。

• 本当に同じエンティティの宣言を繰り返す場合。 JSON-LD仕様には、“the properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node.” (翻訳) 「グラフ内のノードのプロパティは、文書内の複数のノードオブジェクトに分散してよく、その場合は各ノードオブジェクトのキーを統合して結果のノードのプロパティを作る必要がある」とあります。したがって、同じ @id と同一または互換性のあるデータの反復は解析失敗ではなく、処理系によって統合されます。ただし推奨できるわけではありません。マークアップを肥大化させ、あるテンプレートの住所やロゴだけ更新して残り40件を忘れるような保守上の罠になります。AhrefsとSchema Appも「1か所を変更して他を忘れる」という同じ問題を指摘しています。
• 実際には異なる2つのエンティティに同じ @id を再利用する場合。 こちらは本当の破損です。2つのノードオブジェクトが同じ識別子を共有しながら、異なる名前、ロゴ、@type など競合する内容を表します。無害な統合ではなく意味的な競合なので、別エンティティごとに異なる @id を選びます。

一度宣言し、どこでも参照するという保守上の原則は変わりません。同一エンティティの反復は、孤立参照や競合する @id と同じ形で技術的にグラフを壊すわけではありませんが、避けるべきです。

未解決の問い：@id はページをまたいで解決されるか

ここには、もっともらしい断言と正確な回答を分ける限界があります。Googleの文書は、商品ページの Offer.seller がホームページだけで宣言された Organization を指す例のように、@id 参照がページをまたいで解決されるかを明示していません。Google検索セントラルの文書も、@id との関連で「cross-page」や「across pages」という表現を使っていません。

近い手掛かりは自己完結したページを支持します。Googleは重複コンテンツについて “placing the same structured data on all page duplicates, not just on the canonical page” (翻訳) 「正規ページだけでなく、重複するすべてのページに同じ構造化データを配置する」ことを推奨しています。これは構造化データが別の場所から取得されるのではなく、ページ単位で評価されることを示唆します。また、GoogleやBingの担当者（Mueller、Illyes、Splitt）がページ間の @id 問題に明確に答えた記録も確認できませんでした。BingにはWebmaster ToolsのJSON-LD検証がありますが、@id／@graph 固有の公開ガイダンスはありません。これは立場を推測すべき材料ではなく、文書上の空白です。

したがって、2026年7月時点では「Googleがページをまたいで @id リンクをたどる」という見方を、確認済みの動作ではなく業界の推測として扱うべきです。Yoast、Momentic、Schema Appが独立に一致している安全な既定値は、同じエンティティの @id をどこでも一貫させつつ、必要な各ページに完全なエンティティグラフを出力することです。Googleが別URLから参照先エンティティを取得すると仮定してはいけません。Yoastも本番ではページ間解決に頼らず、各ページに完全なグラフを出力しています。

ネストしたスキーマの検証方法

使うツールは2つです。

• リッチリザルト テスト — 2026年7月時点の実務者による検証では、@graph 配列を解析し、テスト対象文書内の @id 参照を解決します。エンティティAがBを @id で参照し、Bが同じグラフ内に宣言されていれば接続された状態で表示されます。参照先が未宣言でも、宣言済み項目は個別にエラーなく解析される一方、接続は表示できません。このUI挙動をGoogleが明示した文書は見つからないため、公式仕様ではなく再現可能な観察結果として扱い、UIが変われば再確認してください。孤立参照がエラーではなく接続欠落として見逃される理由でもあります。
• Schema Markup Validator — schema.org自身の語彙検証ツールで、Googleが対応するリッチリザルト種別への依存が少ないものです。

テンプレートのソースだけでなく、レンダリング後のページをテストしてください。JavaScriptでJSON-LDを挿入するなら、実際に存在することを確認します。GoogleはJavaScriptで 動的に挿入されたJSON-LDの読み取りを文書化していますが、これはGoogle固有です。JavaScriptの実行動作はクローラーや製品ごとに異なり、すべてのAIクローラーが同じようにJSをレンダリングする（あるいは一切レンダリングしない）という一律の規則はありません。実行を前提にせず、最初のHTMLでJSON-LDを配信するのが保守的な選択です。これはAI向けスキーママークアップにも関わります。

打ち消しておきたい誤解

• 「@id は実在し、読み込めるURLでなければならない」 いいえ。慣例では正規URLとフラグメントを使いますが、目的は取得ではなく識別です。フラグメントが独立したページに解決される必要はありません。
• 「別ページで同じ @id を使えば、canonicalタグのようにGoogleのインデックス内でエンティティが自動統合される」 Googleの文書では確認されていません。一貫した @id は適切な運用ですが、ページ間統合が証明された仕組みではありません。
• 「@graph は必須で、別々のscriptブロックは誤り」 誤りです。Googleは両方を理解します。@graph は保守性のための選択です。
• 「ネストを増やすほどエンティティ理解が必ず向上する」 本当に関係するエンティティに限ります。Schema Appの例にある、無関係な Event を Recipe の下に置くようなネストは役立たず、シグナルを曖昧にします。
• 「@id／@graph の構造は順位やリッチリザルトの要因」 いいえ。価値は曖昧さと重複の削減で、スキーマ自体がランキング要因ではないこととも整合します。
• 「宣言されていない @id は無害で、エンジンが無視するだけ」 それが孤立参照です。意図した接続が形成されず、ツールもエラーを出さないことが多いため、見落としたまま公開することになります。

このトピックの位置付け

これは構造化データのハブ配下の実践層で、@id／@graph を紹介するスキーママークアップと、形式を扱うJSON-LDの詳細な関連ページです。エンティティやAI向けスキーママークアップと同じエンティティ理解の考え方に基づきます。利用者がGoogleのナレッジグラフでもLLMでも、適切なグラフはエンティティ基盤です。このサブクラスター全体はオンページSEOに属します。

AIによる要約

Advanced版の要点を短くまとめます。

• 概要。 ネストは、分断されたブロックのままにせずJSON-LDエンティティを接続します。**@idは、エンティティに名前を付け、再宣言の代わりに参照できるようにする安定した一意のURI（通常は正規URLと #fragment）です。@graph**は、関連エンティティを1つの <script> ブロックにまとめ、@id で相互参照させるキーワードです。
• @id と url は別で、@id は解決可能でなくてもよい。 JSON-LD仕様では @id は取得可能性ではなくノード識別を担い、url は実在するページを表します。@id は大文字・小文字を区別します。
• Googleが確認していること。 ネストと個別項目の両方を理解し、2項目の関連をGoogleに伝えるため @id を使います。一方、ページをまたぐ @id 解決は文書化されておらず、業界の推測として扱うべきです。近い手掛かりである「重複ページすべてに同じスキーマを置く」という助言は、ページ単位の自己完結した評価を示唆します。
• 2つのパターン。 公開コンテンツの WebSite → WebPage → Article → Author（author／publisher を @id で参照）と、ECの Product → Offer → Organization/seller（各商品から1つの販売者ノードを参照）です。
• 3つの失敗。 （1）不整合または一意でない @id、（2）参照されるが宣言されない孤立参照（構文上は有効でも意味的に不完全で、検証ツールがエラーを出さず静かに失敗する）、（3）同じエンティティの完全な宣言の重複（保守上の罠。同一エンティティの反復はJSON-LDの規則で統合される一方、異なるエンティティへの同一 @id 再利用は競合）です。
• 安全な既定値。 どこでも一貫した @id を使い、必要な各ページに完全なエンティティグラフを置きます。ページ間取得に頼りません。Yoast、Momentic、Schema Appはいずれもこの方針です。
• 検証。 テスト文書内の @id を解決するリッチリザルト テストとschema.org validatorを使い、レンダリング後のページを確認します。
• 単独で順位やリッチリザルトを生む仕組みではありません。 目的はエンティティ理解、つまり曖昧さと重複の削減です。

公式文書

一次資料の文書と仕様です。

Google

• 構造化データに関する一般的なガイドライン — Googleがネストと個別項目、@id による関連付けを説明するページです。2026年7月10日更新を実ページで確認済みで、重複するすべてのページに同じ構造化データを置くという助言も含みます。
• 構造化データ マークアップの仕組みの概要 — 形式の背景と、完全性・正確性のルールです。
• リッチリザルト テスト — @graph を解析し、テスト対象文書内の @id 参照を解決します。

schema.org／W3C

• W3C JSON-LD 1.1勧告 — @id、@graph、ノードオブジェクト、グラフオブジェクトを定義する仕様です。
• Schema Markup Validator — Googleのリッチリザルト対応一覧への依存が少ない、schema.orgの語彙検証ツールです。

Bing／Microsoft

• Bing Webmaster ToolsでのJSON-LD対応 — BingのMarkup ValidatorはJSON-LDをサポートします。ただし、@id／@graph のネスト機構に固有の公開ガイダンスはありません。

情報源からの引用

Googleによる記録済みの説明です。各リンクは引用箇所へ直接移動します。

Google — ネストと個別項目

• “Google Search understands multiple items on a page, whether you nest the items or specify each item individually.” (翻訳) 「Google検索は、項目をネストする場合でも個別に指定する場合でも、ページ上の複数の項目を理解します」 — Google検索セントラル「構造化データに関する一般的なガイドライン」。 引用箇所へ

Google — @id が存在する理由（関連付けの原則）

• “…use @id in both the recipe and the video items to specify that the video is about the recipe on the page. If you didn’t link the items together, Google Search may not know that it can show the video as a Recipe rich result.” (翻訳) 「レシピと動画の両方に @id を使用し、その動画がページ上のレシピについてのものだと指定します。項目を関連付けなければ、Google検索はその動画をレシピのリッチリザルトとして表示できることを認識できない場合があります」 — 同じページ。 引用箇所へ

Google — 各ページを自己完結させるという、ページ間動作に最も近い手掛かり

• “If you have duplicate pages for the same content, we recommend placing the same structured data on all page duplicates, not just on the canonical page.” (翻訳) 「同じコンテンツの重複ページがある場合は、正規ページだけでなく、重複するすべてのページに同じ構造化データを配置することを推奨します」 — 同じページ。 引用箇所へ

記録にないこと

Googleの文書は、@id 参照がページをまたいで解決されるかを明示しておらず、その問いに答えたGoogleまたはBingの担当者の記録も確認できませんでした。この記事で採用する実務上の表現は “the safe default is consistent @id plus the full graph per page,” (翻訳) 「安全な既定値は、一貫した @id とページごとの完全なグラフ」です。これはYoast、Momentic、Schema Appが独立に一致する実務者の共通見解であり、Googleの引用ではありません。Advancedタブでも公式見解のように扱わず、その旨を明記しています。

ネストしたスキーマ — チートシート

@id、url、@graph の違い

@id の規則

• 絶対URLと意味の分かるフラグメントを使う：https://example.com/#organization。
• 大文字・小文字を区別する：#Author と #author は異なる。1つに決めて変えない。
• 同じエンティティにはどこでも同じ @id、異なるエンティティには異なる @id を使う。
• "id1" のような任意の裸文字列は使わない。

2つのパターン

注意すべき3項目

早見表

• Googleはネストと個別項目の両方が機能すると確認しており、@graph は任意です。
• Googleはページ間の @id 解決を文書化していないため、ページ単位と考えます。
• 安全な既定値： 一貫した @id と、それを必要とする各ページ上の完全なグラフ。
• 順位やリッチリザルトを直接生む仕組みではなく、目的はエンティティ理解です。
• リッチリザルト テスト（文書内の @id を解決）とschema.org validatorで、レンダリング後のページを検証します。

ネストのアンチパターン

ネストしたスキーマが失敗する具体的な原因と、それぞれの修正方法です。

テンプレート間で @id の規則がずれる ブログは #organization、商品テンプレートは #org、移行済みセクションは #company を出力します。実体は1つなのに3つの文字列となり、別エンティティに見えます。修正： プラグインのように、できれば単一設定から生成する文書化済みの規則を機械的に適用します。

宣言していないエンティティを参照する（孤立参照） 文書内に #person-jane ノードがないのに、"author": {"@id": "#person-jane"} と記述します。リンクは何にも解決されず接続は失敗しますが、リッチリザルト テストは通常エラーを出さず、接続を表示しないだけです。修正： 参照する各 @id を、テスト対象マークアップ内で @type 付きで一度宣言します。

各ページで完全なエンティティを再宣言する 名前、ロゴ、すべての sameAs を含む完全な Organization を各記事や商品にコピーします。動作はしますが、ロゴを1か所だけ変えて40ページを忘れれば、エンティティが自己矛盾する保守上の罠です。修正： 一度宣言し、ほかでは @id で参照します。

「スキーマを増やす」ため無関係なエンティティをネストする 「マークアップは多いほどよい」と考え、Recipe、無関係な Event、JobPosting を1つのグラフにまとめます。同じ場所にあるだけでは関係になりません。修正： 本当に関係するエンティティだけを接続します。

ページ間の @id 解決を前提にする Organization をホームページだけで宣言し、商品ページから @id で参照して、Googleが取得すると期待します。Googleの文書はこの動作を確認していません。修正： @id を一貫させつつ、参照する各ページに完全なエンティティを含めます。

実際には url にすべきものを @id にする（またはその逆） 取得可能なページ参照が必要な場所で @id を使ったり、url がグラフのノードを結ぶと期待したりします。役割は別です。修正： グラフ内の識別には @id、実在するページには url を使います。1つのエンティティが両方を持つこともできます。

大文字・小文字と末尾スラッシュが不統一 あるページでは https://example.com/#Org、別ページでは https://example.com/#org、または .../post/#article と .../post#article を混在させます。すべて別物として扱われます。修正： 大文字・小文字、スラッシュ、プロトコル、ホストを厳密に正規化します。

実装例

2つのパターンと正しい参照について、そのまま使える出発点です。

公開コンテンツ：WebSite → WebPage → Article → Author

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Media",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": ["https://www.linkedin.com/company/example-media/"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Media",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post/#webpage",
      "url": "https://example.com/post/",
      "isPartOf": { "@id": "https://example.com/#website" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "url": "https://example.com/team/jane-doe/"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/post/#article",
      "mainEntityOfPage": { "@id": "https://example.com/post/#webpage" },
      "headline": "Example headline",
      "author": { "@id": "https://example.com/team/jane-doe/#person" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

EC：Product → Offer → Organization（販売者）

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://shop.example.com/#organization",
      "name": "Example Shop",
      "url": "https://shop.example.com/"
    },
    {
      "@type": "Product",
      "@id": "https://shop.example.com/widget/#product",
      "name": "Deluxe Widget",
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "seller": { "@id": "https://shop.example.com/#organization" }
      }
    }
  ]
}

正しい参照と孤立参照

正しい例 — 参照先ノードが同じグラフ内で宣言されています。

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Person", "@id": "https://example.com/#jane", "name": "Jane Doe" },
    { "@type": "Article", "author": { "@id": "https://example.com/#jane" } }
  ]
}

破損した例（孤立）— #jane を参照しているのに宣言していないため、author は何にも解決されません。

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Article", "author": { "@id": "https://example.com/#jane" } }
  ]
}

ネストしたスキーマの監査チェックリスト

グラフが接続され、一貫し、自己完結していることを確認します。

• @id の規則を1つに統一し、文書化して全体に適用する（例：{base}/#organization、{page}/#webpage、{profile}/#person）。
• **同じエンティティには同じ @id**を全ページ・全テンプレートで使う（#org と #organization のずれをなくし、大文字・小文字と末尾スラッシュを正規化する）。
• 孤立参照をなくす。参照するすべての @id を、テスト対象文書内で @type とプロパティ付きで宣言する。
• 完全な宣言を重複させない。共有エンティティ（Organization、Person）は一度だけ宣言し、インラインに再掲せず @id で参照する。
• @id と url を正しく使い分ける。@id はノード識別、url は実在するページを表し、1つのエンティティが両方を持つこともある。
• 本当に関連するエンティティだけを接続し、マークアップを増やすために無関係な項目をまとめない。
• 必要な各ページに完全なグラフを置く。ページ間の @id 解決に頼らず、参照先エンティティをページごとに含める。
• リッチリザルト テスト（接続がリンクとして表示される）とschema.org validatorで検証済みにする。
• テンプレートソースだけでなくレンダリング後のページをテストする（JS挿入のJSON-LDが存在することを確認し、AIクローラー向けにはサーバー側で出力する）。
• 正規ページと重複ページで一貫したマークアップを使い、すべての版に同じ構造化データを置く。

理解度チェック：スキーママークアップのネスト

@id、@graph、ネストしたグラフを壊すミスについての5問です。各問の答えを選んで確認してください。

参考資料

関連する私の記事

• 構造化データとは何か、どう使うか — スキーマの種類、実装方法、検証ツール、sameAs によるエンティティ曖昧性のリスク（@id／@graph が担うエンティティ理解）を扱ったAhrefsガイドです。
• テクニカルSEO初心者ガイド — テクニカルSEO全体の中で構造化データが占める位置を説明します。

私の講演

• 検索の仕組み（SlideShare）— 構造化データが関わる背景として、クロール、レンダリング、インデックス登録、ランキングを解説します。いつもの免責事項：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳) 「これは私が理解しているシステム像であり、100%完全または正確とは限りません」

公式

• Googleの構造化データに関する一般的なガイドライン — ネストと個別項目の違い、@id による関連付けの原則。
• W3C JSON-LD 1.1勧告 — @id、@graph、ノード／グラフオブジェクトを定義する仕様。
• リッチリザルト テストとschema.org validator — ネストしたグラフを確認する2つのツール。

業界の参考資料

• スキーマを追加した1,885ページを追跡。AI引用はほとんど動かなかった（Louise Linehan、Xibeijia Guan、Ahrefs）— ネストを含む適切なマークアップは引用獲得の近道ではなくエンティティ基盤だと期待値を調整するのに役立つ調査です。
• ノード識別子：構造化データからリンクトデータへ（Patrick Hathaway、Sitebulb）— ノード識別子の意味を、異なる @id の実例と大文字・小文字の注意点付きで説明します。
• 構造化データの @id とは（Mark van Berkel、Schema App）— JSON-LD仕様の定義と、エンティティの完全な定義を置く「entity home」という有用な捉え方を紹介します。
• スキーママークアップのネストとは（Jasmine Drudge-Willson、Schema App）— 階層と利便性のためのネストの違い、無関係なエンティティをネストする問題を解説します。
• スキーマ：技術とアプローチ（Yoast開発者文書）— 本番の @graph 設計、@id テンプレート、ページ間解決に頼らず各ページに完全なグラフを出す判断を説明します。
• SEO、LLM、ナレッジグラフで @id を使う（Tyler Einberger、Momentic）— 孤立参照、不安定なID、不整合な値など、よくある @id のミスを整理しています。

変更履歴