言語

JSON-LD（JSONによるリンクデータ）

JSON-LDはGoogleが推奨するスクリプトベースの構造化データ形式です。見えるHTMLに触れず、SEOでは通常schema.orgと組み合わせます。

初回公開：2026年6月26日 · 最終更新：2026年8月11日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

JSON-LD（リンクデータ向けのJavaScript記法）は、ページ内容を記述する構造化データ形式で、<script type="application/ld+json">タグ内に置きます。SEOでは通常schema.orgの語彙と組み合わせますが、JSON-LD自体はほかの語彙も扱えます。2014年のW3C勧告であり、GoogleがMicrodataやRDFaより推奨するのは、見えるHTMLに触れず、大規模に実装・維持しやすいからです。3形式とも正しく実装すれば同等に有効です。構文の軸は@context、@type、相互参照に便利だが任意の@idです。@graphも有効な整理方法の1つですが必須ではありません。AIクローラーの挙動はプロバイダーと日付に依存するため、直接検証してください。構造化データはランキングシグナルではなく、リッチリザルトの適格性とエンティティ理解を支え、表示されるコンテンツを記述する必要があります。

TL;DR — JSON-LD（リンクデータ向けのJavaScript記法）は、2014年のW3C勧告です。JSONを基盤としていますが、単なるJSONではなくリンクデータにするのが@contextです。Googleが推奨する構造化データ形式なのは、大規模に実装・維持しやすく、見えるHTMLに一切触れないからです。MicrodataとRDFaも、正しく実装すれば同等に有効です。構文の軸は、@context（語彙。SEOマークアップの多くではschema.orgですが、仕様はほかのコンテキストも許容します）、@type（エンティティ）、@id（エンティティを相互参照するための、便利ですが任意の安定URI。@graphの基礎ですが、@graph自体も複数エンティティを整理する有効な方法の1つにすぎず、必須ではありません）です。<head>にも<body>にも置け、Googleはどちらも受け付けます。GooglebotはJSをレンダリングするため、動的に挿入したJSON-LDはGoogleでは機能します。一方、GPTBotやClaudeBotを含む複数のAIクローラーは、テストではJSを実行しませんでした。ただしこれはプロバイダーと日付に依存する挙動です。すべてのAIクローラーに当てはまると決めつけず、特定のクローラーが重要なら直接検証し、確認できないマークアップはサーバー側でレンダリングしてください。構造化データはランキングシグナルではありません。リッチリザルトの適格性とエンティティ理解を支え、ページに表示されるコンテンツを記述する必要があります。

JSON-LDは語彙ではなく形式

まず、混乱の多くを解く区別を押さえましょう。JSON-LDは形式であり、schema.orgは語彙です。JSON-LDはマークアップの書き方で、schema.orgのArticle、Product、Organizationタイプは、何を述べるかです。リッチリザルトは、その両方の上にある機能レイヤーです。このページは形式を扱います。（AI向け語彙の側面はAIのためのスキーママークアップで扱っています。）

JSON-LDはW3C勧告で、2014年に初めて公開されました。SEOで採用されるより前から存在し、検索専用ではなく、ウェブ全体で一般的なリンクデータを相互運用するために設計されました。この経緯があるからこそ@idのようなプロパティが存在し、SEOガイドの多くが省く仕様レベルのポイント、つまりJSON-LDは単なるJSONではないという点につながります。JSON構文を基盤としますが、データをリンクされたもの、つまりウェブ全体で識別・接続可能なものにするのは@context宣言です。@contextを取り除けば、パーサーが解釈できないデータになります。

JSON-LDはschema.orgに限定されるものでもありません。仕様では、@contextが公開済みの任意の語彙を参照できます。仕様自身の例にもschema.org以外のコンテキストへのリンクがあります。したがって、JSON-LDは「どの形式か」という問いへの正しい答えであり、schema.orgは「どの語彙か」という問いへの答えの1つ、検索やAI検索のマークアップでは一般的な答えです。ページが別の語彙とJSON-LDを組み合わせても正当ですが、その場合はschema.orgマークアップではなくなります。

JSON-LDとMicrodataとRDFaの比較

構造化データを表現する方法は3つあり、Googleはすべてをサポートしています。

JSON-LDMicrodataRDFa
どこに置くか独立した<script>ブロックHTML上のインラインitemprop属性HTML上のインラインproperty属性
見えるHTMLに触れるかいいえはいはい
JS / タグマネージャーで注入できるかはい（きれいに実装可能）難しい難しい
Googleの立場推奨サポートサポート
エラーの起きやすさ最も低い高い（マークアップと絡む）高い（マークアップと絡む）

Googleの推奨は明確ですが、範囲は限定されています。“In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (翻訳)「一般に、サイトの設定が許すなら、JSON-LDを構造化データに使うことをGoogleは勧めています。サイト所有者が大規模に実装・維持しやすく、ユーザーエラーが起きにくいからです。」

競合サイトが通常省く、そして残す価値のあるニュアンスは、同じGoogleのページにあります。“All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (翻訳)「マークアップが有効で機能の文書どおりに実装されていれば、3形式はすべてGoogleにとって同等に問題ありません。」つまり推奨の理由は実装の容易さとエラー率であり、解析速度やランキング上の優位性ではありません。Microdataを使ってもペナルティにはなりません。JSON-LDが実務で勝るのは、構造化データが、明日デザイナーが編集するかもしれないマークアップと絡まないからです。

構文: @context、@type、@id、プロパティ、ネスト

注釈付きのArticleブロックです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>
  • @context — 意味の枠組み（語彙）を定義します。schema.orgのSEOマークアップでは通常"https://schema.org"ですが、これは規則ではなく慣例です。@contextは用語を識別子に対応付け、仕様ではほかの語彙を指すことも許容しています。後続するすべてのプロパティ名をパーサーがどう解釈するかを伝えます。ここがデータをリンクされたものにする部分です。
  • @type — エンティティを宣言します。Article、Product、Organization、BreadcrumbListなどです。schema.orgのタイプに対応します。該当する最も具体的なタイプを使います。該当するならArticleよりNewsArticleを優先します。
  • @id — リソースを識別する一意のURIです。あるエンティティを別のエンティティから参照できるようにする仕組みです（下記の@graphを参照）。相互参照するものには設定する価値がありますが、普遍的に必須ではありません。JSON-LD仕様では識別子のない空白ノードも許容しているため、ほかから参照する必要のないエンティティでは@idを省いた正当なJSON-LDも作れます。
  • プロパティ — @contextの語彙用語を使う、通常のJSONのキーと値の組です。
  • ネスト — 子エンティティは、ネストしたJSONオブジェクト（上記のauthorオブジェクト）またはオブジェクトの配列として表します。

@graphパターン（スケーラブルな方法）

多くのページには複数のエンティティが必要です。Organization、WebSite、BreadcrumbList、そしてArticleまたはWebPageなどです。素朴な方法は、データを繰り返す4つの別々の<script>ブロックです。スケーラブルな代替案は、@graphを使った1つのブロックです。@idで相互参照するエンティティの配列を持たせます。JSON-LD仕様もGoogleも、@graphを唯一のパターンとして義務付けていません。これはグラフを表現する構文であり、ほかにも有効なレイアウト（別々の型付きブロック、トップレベル@graphを使わないネストしたオブジェクト、@idのない空白ノード）が存在します。ただし、相互参照するエンティティが複数あるサイトでは、各ページで同じOrganizationやWebSiteデータを繰り返さずに済むパターンです。

Declare each entity once and connect the graph with stable `@id` references instead of repeating full objects. 出典： Nested Schema

One Organization is referenced as publisher by the WebSite and Article. The WebPage belongs to the WebSite and is connected to the Article. Each entity is declared once, and the same stable ID string is reused for every reference.

© Patrick Stox LLC · CC BY 4.0 · 

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

Organizationを一度定義し、名前、ロゴ、URLを繰り返す代わりに、ほかの場所では{ "@id": "...#org" }で参照します。これは主要なCMSのスキーマプラグインが出力を構築する方法であり、@idが存在する理由でもあります。BingもJSON-LDのネストについて、“makes defining links and relationships between data and entities… easy because it supports nested data.” (翻訳)「ネストされたデータをサポートするため、データとエンティティのリンクや関係を簡単に定義できる」と説明しています。

置き場所: <head>か<body>か

Googleはどちらも機能すると確認しています。“You can put the JSON-LD data in the <head> or the <body> of the page.” (翻訳)「JSON-LDはページの<head>または<body>に置けます。」 <head>が慣例ですが、多くのCMSプラグインは<body>の末尾近くに注入します。それでも問題ありません。Bingも、“in the header, body or foot of the page.” (翻訳)「ページのヘッダー、本文、フッターに置ける」と説明するとしています。<body>の有効なブロックを<head>へ移すことに時間を使わないでください。何も変わりません。 Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: Google: Structured data introduction

JSON-LDを動的に生成する方法とAIクローラーの落とし穴

JavaScriptでJSON-LDをその場で組み立てることができ、Googleは2つの方法を文書化しています。

Evidence for this claim Dynamically generated structured data is acceptable to Google when it is rendered and complies with content and quality guidelines. Scope: Google Search JavaScript and structured-data guidance; crawlability and rendering remain prerequisites. Confidence: high · Verified: Google: Generate structured data with JavaScript
  1. Google Tag Manager — GTM変数から値を取得する、JSON-LDを含むCustom HTMLタグです。（ページとタグの間でデータを重複させないでください。）
  2. Custom JavaScript — スクリプト要素をプログラムで作成します。 
    const script = document.createElement('script');
script.setAttribute('type', 'application/ld+json');
script.textContent = structuredDataText;
document.head.appendChild(script);

これはGooglebotに対して機能します。Googleはページをレンダリングするためです。ここまでは問題ありません。 “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (翻訳)「Google検索は、ページをレンダリングしたときにDOMで利用できる構造化データを理解し、処理できます。」

多くのガイドが見落とす点を、慎重に述べます。GPTBotやClaudeBotを含む複数のAIクローラーは、一般的なテストではJavaScriptを実行していません。 JSON-LDがクライアント側スクリプトの実行後にしか存在しない場合、JSを実行しないクローラーはそれを見ません。Googleが構造化データを探す前にDOMをレンダリングすることを文書化しているため、Googlebotには読めてもそのボットには見えないのです。

このAIクローラーの挙動には、正直に2つの注意点があります。Googlebot側を裏付けるのはGoogle自身の文書です。一方、AIクローラー側は、各プロバイダーに関するテストや報告によるもので、どのプロバイダーも公開している仕様ではありません。したがってプロバイダーと日付に依存し、クローラーのJavaScriptサポートは変わる可能性があります。私はすべてのプロバイダーを直接検証したわけではありません。「AIクローラーはJSをスキップする」を構築の前提となる普遍的ルールとして扱わず、実際に重要なクローラーを確認する理由として扱ってください。確認できない場合は、サーバー側レンダリングをデフォルトにします。サーバーでレンダリングされたHTMLに存在せず、そのクローラーがJSを実行することも確認できないなら、見えないと考えてください。AI検索での可視性のため、別途確認できていない限り、JSON-LDを静的HTMLへサーバー側でレンダリングしてください。（これは構造化データの観点から見たJavaScriptレンダリング問題です。JavaScript SEOも参照してください。）

ECサイトにはもう1つ注意点があります。Googleは、動的に生成されたProductマークアップについて、“can make Shopping crawls less frequent and less reliable,” (翻訳)「Shoppingのクロールを頻度の低い、信頼性の低いものにする可能性がある」と警告しています。価格や在庫が頻繁に変わる場合には現実的な問題です。商品については、AIに関係なくサーバー側レンダリングを優先してください。

ポリシー（現在は無視できません）

Googleの構造化データガイドラインは短いものですが、重要です。

  • “Don’t mark up content that is not visible to readers of the page.” (翻訳)「ページの読者に見えないコンテンツをマークアップしないでください。」
  • “Don’t mark up irrelevant or misleading content, such as fake reviews.” (翻訳)「偽のレビューのような無関係または誤解を招くコンテンツをマークアップしないでください。」
  • “Put the structured data on the page that it describes.” (翻訳)「構造化データは、それが説明するページに置いてください。」
  • “Use the most specific applicable type and property names defined by schema.org.” (翻訳)「schema.orgで定義された、該当する最も具体的なタイプとプロパティ名を使ってください。」
  • 構造化データのページをrobots.txtやnoindexでGooglebotからブロックしないでください。

表示されるコンテンツのルールは、身に付けるべき中心点です。ページに表示されないコンテンツを記述するスキーマは、常に違反でした。「見えない」スキーマへの取り締まりは厳しくなっています。Bingは、“even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.” (翻訳)「マークアップがページに表示されなくても検索エンジンは読み取り、スパムデータを入れると存在感を損なう可能性がある」と率直に警告しています。

よくあるJSON-LDの間違い

  • 表示されるページと一致しないマークアップ — 最も大きなポリシー上の問題です（訪問者に表示されない評価をJSON-LDに入れるなど）。
  • 不正なJSON — 末尾のカンマ、エスケープされていない引用符、またはWordのスマートクォート（"ではなく"）が、気付かないうちにブロック全体を壊します。JSON-LDは厳格です。
  • 誤ったプロパティ名 — schema.orgにないプロパティを作ったり、実在する名前を誤記したりすると、パーサーに無視されます。
  • 具体的なタイプがあるのに汎用タイプを使う — RecipeやNewsArticleが適切なのに、ThingやArticleを使うなどです。
  • ページ間で名前やロゴが食い違う、**重複して一貫性のないOrganization**ブロック。
  • 対象とするリッチリザルトに必要なプロパティの不足（各機能に固有の必須フィールドがあります）。
  • すべてのクローラーに見えると思い込んだJS注入マークアップ — Googleはレンダリングしますが、AIクローラーの一部はそうしていません。クローラーごとに確認する価値があります（上記の注意点）。

JSON-LDの検証

「自分のJSON-LDは有効か」という言葉の下には、4つの異なる問いがあります。それらは同じではありません。1つに合格しても、ほかに合格したことにはなりません。

テスト証明すること証明しないこと
JSONの解析（任意のJSONリンター、またはRich Results Testの解析ステップ）構文が正しいJSONであること。末尾のカンマ、エスケープされていない引用符、スマートクォートによる破損がないことどのプロパティ名が実在するschema.org語彙か、Googleが何かを表示するか
Schema.org Validatorプロパティとタイプがschema.org語彙に存在することGoogleがそのタイプをリッチリザルトとしてサポートするか、特定機能に必要なフィールドがそろっているか
Rich Results Testテストしたレンダリング済みページで、特定のサポート対象リッチリザルトタイプについてGoogleの要件を満たすことGoogleが実際にリッチリザルトを表示すること（適格性は保証ではありません）、他の検索／AIシステムが同じように解析すること
Google Search Console — 拡張 / リッチリザルトレポート実際にクロールされたページをGoogleが大規模かつ実際のエラーとともに解析した内容リアルタイムの状態。レポートは再クロール後まで遅れます
  • 貼り付けたコードではなくURLでテストしてください。JSでレンダリングされるページでは特に重要です。Rich Results Testのコード入力モードはスクリプトを実行せず、ライブURLテストのように相対参照も解決しません。クライアント側で注入されたブロックがレンダリング後にどう見えるかは判断できません。
  • Bing Webmaster Tools — Markup Validator — Bingは2018年8月からJSON-LDを検証しています。
  • これらのテストは、JavaScriptをレンダリングしないクローラー（上記のAIクローラーの注意点を参照）については何も保証しません。レンダリング済みURLのテストで確認できるのはGoogleが見るものです。JSを実行しないボットが受け取るものとは限りません。

JSON-LDはSEOに役立つか

期待値を正直に設定しましょう。

  • ランキングシグナルではありません。 John Muellerは、構造化データでサイトのランキングが上がることはないと述べています。以上です。
  • リッチリザルトの適格性。 強化されたSERP機能（星、価格、FAQ、パンくずなど）を得るための適格性を作ります。保証ではありません。
  • 間接的なCTR。 より豊かに見える結果はクリックを増やす可能性があり、多くのサイトにとって本当の見返りです。
  • エンティティ理解。 エンジンがページを既知のエンティティやナレッジグラフに結び付ける助けになります。
  • AI検索。 BingのFabrice Canelは2025年、スキーママークアップがMicrosoftのLLMによるコンテンツ理解を助けると確認しました。ただし、AIのためのスキーママークアップにある統制研究の注意点も確認してください。これは曖昧性解消のためのインフラであり、直接的な引用を増やす仕組みではありません。

したがって、JSON-LDはリッチリザルトの適格性、エンティティの明確さ、AI/LLMの理解のために実装しましょう。ランキングを不正に上げる方法としてではありません。

この記事は構造化データハブにあります。schema.org語彙についてAIに特化した説明はAIのためのスキーママークアップを、動的な注入を支えるレンダリングの仕組みはJavaScript SEOを参照してください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.