構造化データの基礎 (JSON-LD / schema.org)

構造化データとは

構造化データ とは、Web ページの内容を検索エンジンが機械的に理解できる形式で記述するためのマークアップです。本文中の自然言語に頼らず、「このページの主題は何か / 提供者は誰か / 対象読者は誰か」といった意味情報を別レイヤーで宣言します。

検索エンジン (Google / Bing 等) は、本文の自然言語処理だけではページの主題を完全には把握できません。構造化データを併記することで、検索エンジンとコンテンツ提供者の間に 「このページの本質はこれだ」という契約 を結ぶことができます。

何が嬉しいか

検索結果に「リッチリザルト」(画像付き / レビュー星 / パンくずリスト等) が表示されやすくなる
ナレッジパネルの情報源として使われる (例: Organization マークアップはロゴやナレッジパネルの表示に影響する)
音声検索や AI アシスタントが情報を取り出しやすくなる
検索エンジンがページ間の関係 (組織 → サービス → 対象) を把握しやすくなる

ただし「構造化データを書けば必ずリッチリザルトが出る」わけではありません。Google の判断による、というのが公式の立場です。詳細は 02. Google ガイドラインで扱います。

構造化データの表現形式は 3 種類

構造化データの記述方法には主に 3 つの形式があります。

形式	配置	特徴
JSON-LD	`<script type="application/ld+json">` ブロック	本文 HTML と分離、メンテしやすい
Microdata	HTML 要素の属性 (`itemtype`, `itemprop`)	本文に埋め込む、視覚要素と直結
RDFa	HTML 要素の属性 (`typeof`, `property`)	本文に埋め込む、より汎用的

このうち JSON-LD が Google 推奨 です。本文 HTML から完全に分離できるため、SEO 要件のためにマークアップ構造を変更する必要がなく、メンテナンス性が高いことが主な理由です。詳細な根拠は 02 章で詳述します。

JSON-LD のシンタックス

JSON-LD は名前の通り JSON ベースですが、@ で始まる予約キーワードで意味を補強します。

最小例

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Acme Workflow"
}

@context: 使用するボキャブラリ (型・プロパティの定義元) を指定。schema.org の場合は "https://schema.org" を使う
@type: このオブジェクトが何の型か (例: WebPage, Service, Organization)
それ以外の通常プロパティ (name, description, url 等) は型ごとに定義されている

https を使う

古いサンプルでは "@context": "http://schema.org" という記述を見かけますが、現在は https://schema.org を使うのが正式です。schema.org が HTTPS 化された結果で、両方とも動作はしますが、混乱を避けるため新規実装は https で統一します。

`@id` — オブジェクトの一意識別子

複数のオブジェクトを 1 つの JSON-LD 内で扱うとき、相互参照のために @id を使います。URI を識別子として用い、慣習的に URL + フラグメント (#xxx) で表現します。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Acme Inc.",
      "url": "https://example.com/"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/services/workflow/#webpage",
      "name": "Acme Workflow",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

publisher から @id で Organization を参照することで、ネストを展開せずに関係を表現できます。@id の URL は そのオブジェクトを表す URL に対応 させるのが慣習で、フラグメントで「ページ内でのその概念」を識別します。

ネストと参照

オブジェクトを別オブジェクトに含めるには 2 方式あります。

インライン (ネスト):

{
  "@type": "WebPage",
  "publisher": {
    "@type": "Organization",
    "name": "Acme Inc."
  }
}

参照 (@id 経由):

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

複数のページから同じ Organization を参照する場合、後者のほうが整合性を保ちやすくなります。サイト全体で Organization を 1 箇所に定義し、各ページから @id で参照する設計が、規模が大きくなった時の保守性で勝ります。

schema.org Data Model

schema.org は、Google / Microsoft / Yahoo / Yandex によって設立され、現在は W3C Schema.org Community Group を中心としたオープンなコミュニティプロセスで策定されている語彙集です。型 (Type) とプロパティ (Property) の階層を定義しています。

schema.org のドキュメント

公式の Schema.org Data Model (確認: 2026-05) に全体像が解説されています。本ガイドは要点を絞って紹介します。

型階層 (Inheritance)

schema.org の型は階層構造を持ちます。Thing を最上位として、すべての型が Thing を継承します。

例えば WebPage は CreativeWork → Thing を継承するため、CreativeWork 由来のプロパティ (author, datePublished 等) と Thing 由来のプロパティ (name, description, url 等) を持ちます。

プロパティの値域 (Range)

各プロパティには「どんな型の値を取れるか」が定義されています。

Service.provider の値域は Organization か Person
WebPage.isPartOf の値域は CreativeWork または URL (本ガイドでは CreativeWork のサブタイプである WebSite を指定)
Service.areaServed の値域は AdministrativeArea / GeoShape / Place / Text のいずれか

値域は schema.org の各型ページ (例: Service) の "Properties" セクションで確認できます。

多重継承と DataType

schema.org は 多重継承を許容 します (例えば LocalBusiness は Organization と Place の両方を継承)。複数の文脈を併せ持つ実体を表現できますが、初学者は単一継承の範囲で型を選ぶほうが安全です。

また Text / Number / Boolean / Date のような データ型 も DataType 配下にあり、name のような String を取るプロパティはこの Text を値として受け取ります。

HTML への埋め込み方法

JSON-LD は <script> タグで HTML に埋め込みます。

<!DOCTYPE html>
<html lang="ja">
<head>
  <title>Acme Workflow</title>
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "WebPage",
    "name": "Acme Workflow",
    "description": "業務担当者向けのタスク管理 SaaS"
  }
  </script>
</head>
<body>
  ...
</body>
</html>

配置のベストプラクティス

<head> 内または <body> 内のどちらでも動作する (Google は両方を読む)
1 ページ内に複数の <script type="application/ld+json"> を置いてもよい (ただし主題の重複には注意、詳細は 03 章で)
React / Vue / Next.js などのフレームワークでは各 FW の推奨方法に従う (Next.js は layout / page コンポーネント内にネイティブ <script> タグで描画、Nuxt なら useHead 等)。なお next/script の <Script> は実行用 JS 向けで、JSON-LD には不適と公式に明記されている

動的生成 vs 静的生成

サイトの種類に応じて埋め込み戦略が変わります。

静的サイト: HTML に直接書く、または build 時に生成
SSR (Next.js / Nuxt): server-side で生成して initial HTML に含める (Google が JavaScript 実行前でも読める)
CSR のみ: クライアント JavaScript で生成。Google は JS 実行後の HTML も読みますが、レンダリング遅延の影響を受けやすいため SSR を推奨

本ガイドは フレームワーク非依存 に保ち、JSON-LD の中身 (構造) に集中します。実装言語固有のヘッド注入実装は各 FW のドキュメントを参照してください。

このあと

ここまでで構造化データの全体像と JSON-LD のシンタックス基礎を押さえました。次章 02. Google ガイドラインでは、Google が定めるポリシーと、なぜ JSON-LD が推奨されるのかの根拠を扱います。実装に着手する前に必ず一読してください。

構造化データとは​

構造化データの表現形式は 3 種類​

JSON-LD のシンタックス​

最小例​

@id — オブジェクトの一意識別子​

ネストと参照​

schema.org Data Model​

型階層 (Inheritance)​

プロパティの値域 (Range)​

多重継承と DataType​

HTML への埋め込み方法​

動的生成 vs 静的生成​

このあと​