JSON-LDがAIによるウェブサイト理解を助ける仕組み

JSON-LDは、Schema.orgのボキャブラリーを構造化された機械可読メタデータとしてHTMLに埋め込むための<script>ベースのフォーマットです。これにより、検索エンジンやAIシステムは、文章から推測することなく、記事・組織・製品・パンくずリスト・人物といったエンティティを識別できるようになります。Google Searchにおいては、正しいJSON-LDによってページが特定の検索機能の対象となり、ナレッジグラフへの情報提供にも役立ちます。GPTBot・ClaudeBot・PerplexityBotといったAIクローラーに関しては、フロントエンド開発者が見落としがちな重大な制約があります。これらのクローラーはJavaScriptを実行しないため、JSON-LDはサーバーレスポンスに含まれていなければ、そもそもクローラーに届かないのです。

本記事では、JSON-LDが実際に何をするのか、どこで役立ちどこで役立たないのか、応用可能な3つの実用例、クライアント側で注入されたマークアップをAIクローラーに見えなくするレンダリングギャップ、そして実装内容の検証方法について解説します。

JSON-LDとは何か、なぜ存在するのか

JSON-LD（JavaScript Object Notation for Linked Data）は、JSONでLinked Dataを表現するためのW3C標準化された構文です。ウェブ上では、ほぼ常にHTMLドキュメント内の<script type="application/ld+json">タグにSchema.orgのボキャブラリーを埋め込む形で使用されます。このデータは、ページのエンティティ——何について書かれているか、誰が書いたか、どの組織が公開したか、他のページとどう関連するか——をパーサーが文章を読むことなく解析できる形式で記述します。

「なぜ必要か」という問いに対する答えは、解釈コストの削減です。構造化データがなければ、クローラーはページ上の「Apple」が果物ではなく企業を指すのかを推測し、「Jane Chen」というバイラインが主題ではなく著者であることを判断し、マークアップ内の価格がサイドバーの関連アイテムではなくページ上の製品に属することを確認しなければなりません。Schema.orgはこれらの事実に明示的な型とプロパティを与えます。JSON-LDはそれらを可視DOMから切り離されたブロックとして提供します。これがGoogleがMicrodataやRDFaよりJSON-LDを推奨する理由です——レイアウトに触れることなく生成・更新できるからです。

いくつかの点について正確に述べておく価値があります。JSON-LDはGoogleの文書化されたランキングシステムにおいて、確認されたランキング要因ではありません。リッチリザルトを保証するものでもありません——適格性は必要条件ですが十分条件ではないのです。AI OverviewsやAI Modeへの掲載を保証するものでもありません。そしてAIシステムはJSON-LDを必要としません——文章を読むことができます。JSON-LDが行うのは推論作業の削減であり、それによって正確な解釈がより可能性が高くなり、曖昧なコンテンツが誤分類される可能性が低くなります。

JSON-LDとAI Overviews・AI Modeの関係

AI OverviewsおよびAI Modeは、Googleの既存の検索インデックスの上に構築されています。Googleが公開しているガイダンスによれば、AI固有のマークアップは存在しません——ページは通常の検索を規定するのと同じコンテンツおよび構造化データシグナルを通じてAI機能の対象となります。ページが正しくインデックスされ、構造化され、ユーザーの意図に合致していれば、検索のために実装した構造化データがそのままこれらの機能でも活用されます。

率直に言えば、構造化データはAIシステムがコンテンツを正確に解釈するのを助けます。生成された回答への掲載を保証するものではありません。曖昧さを排除する手段として扱うべきであり、集客のためのレバーとして扱うべきではありません。

AIクローラーにおけるレンダリングギャップ

これはフロントエンド開発者にとって最も影響の大きい技術的ポイントであり、ほとんどのJSON-LD解説記事では触れられていません。AIクローラーは基本的に非レンダリングクローラーとして扱うべきであり、構造化データは最初のHTMLレスポンスに含まれている必要があります。

• OpenAIのGPTBotはHTMLを取得しますが、クライアントサイドのJavaScriptをレンダリングしません。
• AnthropicのClaudeBotはJS実行なしの標準的なHTTPクローラーとして動作します。
• PerplexityBotも同様に生のHTMLを読み取ります。

Googlebotは例外です。Googlebotは遅延パスでJavaScriptを一般的にレンダリングするため、クライアント側で注入されたJSON-LDは検索向けに最終的には処理されます。AIクローラーはそこまで追いつきません。JSON-LDがハイドレーション後にのみ存在する場合、現在最も多くの読者が注目しているシステムからは見えない状態になります。

実際のフロントエンドアプリでよく見られる本番環境での失敗パターンがあります。開発者がuseEffectフック内にJSON-LDを追加するか、Google Tag Manager経由でプッシュします。ブロックはレンダリングされたDOMに表示され、（レンダリングを行う）Rich Results Testでは有効と表示され、チームは作業完了と判断します。一方、非レンダリングクローラーはすべて、構造化データを一切含まないHTMLレスポンスを受け取っています。

解決策は<script type="application/ld+json">ブロックを最初のサーバーレスポンスに含めることです。

フレームワーク別のJSON-LDサーバーレンダリング方法

原則はどのスタックでも同じです。JSON-LDブロックはサーバーから返されるバイト列に存在しなければならず、ブラウザが最初のペイント後に追加するバイト列に含まれてはなりません。

3つの実用的なJSON-LD例

以下の例は、2026年3月19日にリリースされたSchema.orgバージョン30.0のボキャブラリーを使用しています。

BlogPosting（Articleのサブタイプ）

Schema.orgの階層において、BlogPostingはArticleのサブタイプであり、Article自体はCreativeWorkのサブタイプです。"@type": "BlogPosting"を宣言することで、すべてのArticleプロパティが暗黙的に継承されます——両方を宣言する必要はありません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://openreplay.com/blog/json-ld-ai-search#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://openreplay.com/blog/json-ld-ai-search"
  },
  "headline": "How JSON-LD Helps AI Understand Your Website",
  "description": "A frontend-focused guide to JSON-LD, Schema.org, and the server-rendering requirement for AI crawlers.",
  "image": "https://openreplay.com/images/blog/json-ld-ai-search.png",
  "datePublished": "2026-05-20T09:00:00-04:00",
  "dateModified": "2026-05-20T09:00:00-04:00",
  "author": {
    "@type": "Organization",
    "name": "OpenReplay Team",
    "url": "https://openreplay.com"
  },
  "publisher": {
    "@id": "https://openreplay.com/#organization"
  }
}
</script>

長文記事ページで使用します。mainEntityOfPageは記事を正規URLに紐付けます。dateModifiedは、鮮度がクエリシグナルとなる場合にGoogleが使用するため重要です。

Organization

Organizationタイプは公開エンティティを記述します。sameAsを使用して正規の外部プロフィールを指定します——これにより、システムが類似した名前を持つ他のブランドとあなたのブランドを区別できます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://openreplay.com/#organization",
  "name": "OpenReplay",
  "url": "https://openreplay.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://openreplay.com/images/logo.png",
    "width": 512,
    "height": 512
  },
  "sameAs": [
    "https://github.com/openreplay",
    "https://www.linkedin.com/company/openreplay",
    "https://x.com/OpenReplayHQ"
  ]
}
</script>

これはサイト全体で一度だけ実装します——通常はすべてのページのドキュメントヘッドに配置します。他のスキーマブロックから@idを再利用することで（上記のBlogPosting.publisherが行っているように）、Organizationの定義が重複することなく、単一の正規定義がどこからでも参照されます。

BreadcrumbList

BreadcrumbListはサイト階層におけるページの位置を記述します。Googleはパンくずリッチリザルトをサポートしており、同じデータがAIシステムのサイト構造理解にも役立ちます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://openreplay.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://openreplay.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How JSON-LD Helps AI Understand Your Website"
    }
  ]
}
</script>

最後のアイテムは現在のページであるためitemを省略しています。positionは1始まりのインデックスです。

構造化データと可視コンテンツの整合性を保つ

Googleの構造化データガイドラインは明確です。JSON-LD内のコンテンツはページ上に表示されているものと一致しなければなりません。ページに存在しないレビュー、表示されていない価格、可視のバイラインと矛盾する著者名をマークアップすることは、手動対策のリスクとなります。構造化データはページを記述するためのものであり、DOMで裏付けられていない主張でページを強化するためのものではありません。

これはAIシステムにとっても重要です。可視の文章と JSON-LDの内容が異なる場合、構造化データが解消すべき曖昧さをむしろ作り出すことになります。

実装前の検証

ワークフローをカバーする2つのツールがあります。

Rich Results Testはページをレンダリングするため（AIクローラーには見えないクライアント側で注入されたJSON-LDも確認できます）、非レンダリングクローラーが実際に何を受け取るかを確認するには、URLに対してcurl -A "GPTBot" https://your-pageを実行し、レスポンスでapplication/ld+jsonを検索してください。その生のHTMLにブロックが含まれていなければ、AIクローラーには見えていません。

Google Search Consoleの「拡張機能」セクションでは、Googleが追跡する構造化データタイプの解析エラーと適格性が報告されます。デプロイ前の検証の代替としてではなく、継続的なモニタリングに活用してください。

FAQPageについての注記

FAQPageは依然としてSchema.orgの有効なタイプであり、Googleはコンテンツ理解のために引き続き使用しています。ただし、GoogleはFAQPageのドキュメントにおいて、FAQ関連の検索機能が削除されることを明記しています。FAQリッチリザルトは2026年5月に検索への表示が終了し、Search ConsoleのレポートとRich Results Testのサポートは2026年6月に削除され、Search Console APIのサポートは2026年8月に続きます。現在、可視的なリッチリザルト効果を目的としてスキーマを実装するなら、FAQPageは適切な選択ではありません。本物のFAQページがあり、セマンティクスを記録として残したい場合に実装してください——SERPの表示領域獲得を目的とした施策としてではなく。

これはまた、長期的な検証作業においてvalidator.schema.orgがより安全なデフォルト選択である理由でもあります。Googleがリッチリザルトとして表示することを選択した機能に依存しないためです。

最初に実装すべきもの

ゼロから始める場合、最も価値の高い実装順序は次のとおりです。サイト全体に単一のOrganizationブロック、ホームページ以外のすべてのページにBreadcrumbList、そして編集コンテンツにArticle/BlogPostingです。これらすべてをサーバーレンダリングしてください。両方のツールで検証し、非レンダリングのユーザーエージェントで生のHTMLレスポンスを確認して、AIクローラーが実際に実装した内容を受け取っていることを確かめてください。

構造化データだけでランキングは動かず、AI Overviewsへの掲載を保証するものでもありません。正しく実装されたときに確実に行われることは、検索エンジンやAIシステムがコンテンツを誤解する原因となる解釈上の推測を排除することです。フロントエンドチームにとって最も重要な作業は、どのスキーマタイプを追加するかではなく、レンダリングパイプラインのどこに配置するかです。JSON-LDをサーバーレスポンスに含めれば、残りはコンテンツの問題です。

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.