サイトの各ページにschemaを実装していても、AIエンジンが「このWebPageはどのWebSiteに属し、誰が運営しているのか」を把握できないことがあります。問題はタグの数ではなく、タグ同士に関係が定義されていないことです。Organization、WebSite、WebPageを別々のJSON-LDとして記述するだけでは、機械に関連性のない3枚の名刺を渡すようなものです。@graphは、その3枚を明確な線で結び、サイト全体のエンティティ構造をAIに伝える役割を果たします。
分散したschemaでは、AIがサイトの全体像を把握できない
多くのWebサイトでは、プラグインやCMSのテンプレートがschemaを自動生成しています。トップページにはOrganization、記事ページにはArticle、料金ページにはProductという具合です。個々のschemaは仕様上正しく、Rich Results Testにも合格するでしょう。しかし、機械が「この記事の発行元は誰か、信頼できるのか」を判断しようとしても、そこにあるのは互いにつながっていないオブジェクトの集まりです。Articleのpublisherが、トップページで定義されたOrganizationと同じ組織であることを示すフィールドがありません。とりわけAI要約や回答エンジンでは、そのコンテンツを実在し検証可能な組織と結び付けられるかどうかが、引用可否を判断する重要な要素になります。関係性が定義されていなければ、企業の公式情報であるはずのコンテンツも、出所不明の文章として扱われかねません。
@graphは何をするものなのか
@graphはJSON-LDのトップレベルに置くフィールドで、値には複数のエンティティオブジェクトを含む配列を指定できます。これにより、本来は複数のscriptタグに分かれていたエンティティを、同じファイルと名前空間にまとめられます。ただし、本質は単に「一か所にまとめる」ことではありません。重要なのは、同じ@graph内のオブジェクトが@idを使って互いを参照できる点です。Organizationで@idを定義し、WebSiteのpublisherに同じ@idを指定すれば、機械は両者が同一のエンティティを指すと理解できます。Organization全体をもう一度記述する必要はありません。「一度定義し、必要な場所から参照する」という設計は、ナレッジグラフの基本です。schema.orgが@graphをサポートしていることで、ページは属性を羅列するだけでなく、エンティティ間の関係まで表現できます。
1ページ分の@graphは、1つのscriptタグに収められます。これは、3つのプラグインが同じOrganizationをそれぞれ生成し、属性が競合するという従来の問題にも有効です。@graphでは企業エンティティを一度だけ定義できるため、サイト全体で一貫した唯一の情報源になります。メンテナンス時の修正箇所も1か所で済みます。
@id：各エンティティに変わらない住所を与える
@idは、この設計全体の土台です。ドメイン全体で一意となる識別文字列で、通常はhttps://example.com/#organizationのように、URLの末尾にハッシュ記号を付けた形式を使います。この値は、必ずしもブラウザで開ける必要はありません。役割はリンクではなく、エンティティの識別です。サイト内のどこでも同じエンティティに同じ@idを使えば、AIは各ページに分散した情報を同一の対象としてまとめられます。トップページ、記事ページ、料金ページに同じ@idがあれば、機械は各ページにある企業情報を統合し、より完全で改ざんされにくいエンティティ情報を形成できます。
- Organizationには、https://example.com/#organizationのようにドメインルートとフラグメントを組み合わせた値を使います。サイト全体で一意とし、常に同じ企業を参照させます。
- WebSiteには、ドメインルートと#websiteを組み合わせた値を使い、Webサイト全体のエンティティを表します。
- 各ページのWebPageには「ページURL + #webpage」を使います。この値はページごとに異なります。
- フラグメント名はチーム内で統一します（#organization、#website、#webpage）。今日は#org、明日は#companyというように表記を変えてはいけません。
- 公開後の@idは安易に変更しないでください。変更すると新しいエンティティとして扱われ、それまで蓄積された関連付けが途切れてしまいます。
3つのエンティティをどうつなぐか
接続の方向には明確な考え方があります。小さい単位から大きい単位へ、つまりページからサイト、運営主体へとたどれるようにします。WebSiteのpublisherからOrganizationを参照し、「このサイトはこの企業が運営している」と示します。各WebPageのisPartOfからWebSiteを参照し、そのページがサイトの一部であることを宣言します。会社概要や料金ページなど、企業そのものを扱うページでは、aboutまたはmainEntityからOrganizationを参照します。記事ページではArticleのpublisherから同じOrganizationの@idを指定すれば、発行元との関係が完成します。
そのまま使える完全な実装例
次の@graphをページの<head>に配置すれば、1つのscriptタグに3つのエンティティを収められます。それぞれの@idを一度だけ定義し、Organization全体を複製せず、@idで相互に参照します。実務では、OrganizationとWebSiteをサイト全体で共有するテンプレートに切り出し、一度だけ記述します。WebPageについては、ページごとのurl、name、@idを動的に出力できます。 { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example company", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "Pricing plan", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
よくある4つのミス
- @idが統一されていない：トップページでは#organizationと記述しているのに、記事ページのpublisherには別の完全なURLを入れたり、ハッシュ記号以降のフラグメントを省いたりすると、機械は別々の企業として扱います。
- 参照だけでよい箇所にオブジェクト全体を入れている：publisherの中にOrganization全体を再記述すると、同じエンティティが二重に存在し、属性同士が競合する可能性があります。
- エンティティが孤立している：WebPageにisPartOfがなく、Articleにpublisherがない状態です。オブジェクト自体は仕様上正しくても、運営主体との関係が切れています。
- 変動するURLを@idに使っている：トラッキングパラメータやセッションによってURLが変わるたびに別のエンティティが生成され、関連付けが一からやり直しになります。
AIから信頼されるサイトに必要なのは、タグの多さではありません。エンティティの関係を、十分に明確に示すことです。
公開前に必ず確認したい3項目
実装しただけで、正しく設定できたとは限りません。まず、@graph全体をRich Results TestまたはSchema Markup Validatorに貼り付け、構文エラーが表示されないことを確認します。次に、多くの担当者が見落とす確認を行います。参照されている@idを一つずつ拾い、同じグラフ内で実際に定義されているか照合してください。存在しない識別子を参照してはいけません。最後に、ブラウザでページを読み込み、レンダリング後のHTMLを確認して、scriptが実際に出力されているかを確かめます。SSRやCMSの処理によって、この段階で消えてしまうケースは少なくありません。エンティティ接続の不備は、テクニカルGEO診断でよく見つかる項目です。修正に何時間もかかるものではありませんが、AIがサイトを信頼できる情報源として扱うかどうかに直接影響します。Organization、WebSite、WebPageが本当につながっているか、publisherの関係が切れていないか判断できない場合は、30分のGEO診断をご予約ください。レンダリング後のHTMLを実際に取得し、不足している関係線を一つずつ指摘します。
