JSON-LDの書き方基礎｜3つの実装例で学ぶハンズオンガイド

「構造化データを実装したいが、JSON-LDの書き方がわからない」。コンテンツ制作やサイト運用を担当されている方から、こうしたご相談を受けることがあります。本記事は、schema.orgとGoogle公式ドキュメントにもとづく解説です。記事・企業情報・パンくずリストという3つの実装例で、JSON-LDの基本文法をコピペ可能なテンプレートとともに紹介します。

01この記事でわかること

• JSON-LDの基本文法（@context・@type・プロパティの3要素）
• 記事(Article)・企業情報(Organization)・パンくずリスト(BreadcrumbList)のコピペ可能な実装例
• 複数の型を組み合わせる入れ子構造・配列の書き方
• 実装後にリッチリザルトテストで検証する手順
• 設置場所と、つまずきやすい構文エラーの直し方

03JSON-LDとは（基礎定義）

引用されやすい定義文

JSON-LDとは、JSONの記法でページの構造化データを記述するためのリンクドデータ形式です。

JSON-LD(JSON for Linking Data)は、人間が読み書きしやすいJSON形式をベースにした記述方式です(出典: json-ld.org)。既存の巨大なJSONエコシステムを土台に、データ同士を意味的につなげることを目的としています。

Googleがこの形式を推奨する理由は3つあります(出典: Google Search Central「Google 検索における構造化データのマークアップの概要」)。第一に、ページの表示用テキストとは独立した<script>ブロックに書けるため、HTMLの各タグを汚しません。第二に、イベント内の会場、会場内の住所といった入れ子構造を簡潔に表現できます。第三に、JavaScriptで動的に生成・挿入したデータも読み取れます。

構造化データを実装する目的も確認しておきます。Googleは、ページ内容の理解とリッチリザルト表示のために構造化データを使います。ただし、構造化データを追加したからといって、掲載順位が直接上がるわけではない点には注意が必要です。

📊 図解制作中

04実装ルールの前提——必須・推奨・任意プロパティ

コードを書く前に、Googleの構造化データガイドラインが定める前提を押さえておきます。Googleのガイドラインでは必須・推奨の2段階が定義されています(出典: Google Search Central「構造化データの一般ガイドライン」)。本記事ではこれに「任意(定義には存在するが必須・推奨に含まれないプロパティ)」を加えた3段階で整理します(編集部の実務整理)。

もう1つ重要な前提があります。マークアップの内容は、ページに実際に表示されている情報と一致させる必要があります。表示されていない情報を構造化データにだけ書くことは、ガイドライン違反にあたります。

05実装例①: 記事(Article)のJSON-LD

最初の実装例は、ブログ記事やニュース記事に使うArticle型です。schema.orgの定義では、Article型は「ニュース記事や調査報告書など、様々なタイプの記事」を表す型です(出典: schema.org/Article)。継承構造はThing > CreativeWork > Articleです。

以下は、企業ブログの記事を想定したテンプレートです。自社の情報に置き換えれば、そのまま利用できます。企業ブログ記事にはBlogPostingを使います(継承:Thing>CreativeWork>Article>SocialMediaPosting>BlogPosting)。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事のタイトルをここに入力",
  "author": {
    "@type": "Person",
    "name": "山田太郎",
    "jobTitle": "コンテンツディレクター",
    "url": "https://sample.example.com/author/yamada-taro"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://sample.example.com/images/logo.png"
    }
  },
  "datePublished": "2026-07-24",
  "dateModified": "2026-07-24",
  "image": "https://sample.example.com/images/article-thumbnail.jpg"
}

headline・author・datePublishedはGoogleが推奨するプロパティです(出典: Article構造化データガイド)。authorとpublisherはPerson型・Organization型を内側に入れ子にして記述します。この入れ子の考え方は、後述の「入れ子構造の書き方」で改めて整理します。

著者情報のプロパティをさらに深掘りしたい方は、別記事『著者Person schemaの書き方とE-E-A-T効果』もあわせてご覧ください。name・sameAs・jobTitleなど、Person型固有のプロパティの選び方を扱っています。

06実装例②: 企業情報(Organization)のJSON-LD

2つ目の実装例は、会社概要ページなどで使うOrganization型です。schema.orgの定義では「学校、NGO、企業、クラブなど、組織を表現する型」とされています(出典: schema.org/Organization)。

以下は、コーポレートサイトの会社概要ページを想定したテンプレートです。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://sample.example.com/",
  "logo": "https://sample.example.com/images/logo.png",
  "sameAs": [
    "https://twitter.com/sample_example",
    "https://ja.wikipedia.org/wiki/株式会社サンプル"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-0000-0000",
    "contactType": "customer service"
  },
  "address": {
    "@type": "PostalAddress",
    "addressRegion": "東京都",
    "addressLocality": "千代田区",
    "postalCode": "100-0000",
    "streetAddress": "サンプル1-2-3"
  }
}

name・url・logoは基本プロパティです。sameAsには、自社であると確認できる公式アカウントやWikipediaページを配列で指定します。contactPointとaddressは、それぞれContactPoint型・PostalAddress型を入れ子にして記述しています。

07実装例③: パンくずリスト(BreadcrumbList)のJSON-LD

3つ目の実装例は、カテゴリ階層を示すBreadcrumbList型です。schema.orgの定義では「URLと名前で説明される、リンクされたWebページの連鎖」とされています(出典: schema.org/BreadcrumbList)。

以下は、ECサイトのカテゴリページを想定したテンプレートです。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "トップ",
      "item": "https://sample.example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "サービス一覧",
      "item": "https://sample.example.com/services/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "AIO診断サービス"
    }
  ]
}

BreadcrumbListは、これまでの2例と違い、itemListElementという配列の中に複数のListItemを並べる構造です。positionは1から始まる連番、itemにはページのURLを指定します。最後の階層（現在地のページ）はitemを省略して構いません。これはGoogle公式ドキュメント「パンくずリスト」に掲載されている例と同じ書き方です。

08入れ子構造・配列の書き方——3つの実装例を比較する

3つの実装例を並べると、JSON-LDには2種類の「組み合わせ方」があることがわかります。1つは、あるオブジェクトの中に別のオブジェクトを直接入れる入れ子です。実装例①のArticleにPersonとOrganizationを入れた形がこれにあたります。

もう1つは、同じ型のオブジェクトを順番に並べる配列です。実装例③のBreadcrumbListが、この配列の考え方を使っています。

入れ子と配列を混同すると、構文エラーの原因になります。入れ子は波括弧{}1つ、配列は角括弧[]の中に波括弧を複数並べる、という違いを意識してください。

📊 図解制作中

なお、本記事で扱ったArticle・Organization・BreadcrumbListのような汎用スキーマ単体のAI引用効果には、慎重な見方を示すデータもあります。FAQPage・HowToとの関係は、別記事『FAQ・HowTo構造化データと引用率の関係を一次データで検証』で扱っています。

09実装後の検証方法

コードを書いたら、公開前に検証しましょう。Googleが提供する公式ツール「リッチリザルトテスト」を使えば、構文エラーやプロパティの過不足を確認できます。

検証の手順は次の4ステップです(出典: 同ガイド)。

1. リッチリザルトテスト(search.google.com/test/rich-results)にアクセスする
2. 公開済みのURL、またはコードスニペットを直接貼り付ける
3. 「テストを実行」をクリックする
4. 検出された型・エラー・警告の有無を確認する

エラーが出た場合は、該当プロパティ名を確認し、JSON構文のカンマ・括弧の過不足を見直してください。検証ツールの詳しい読み方は、別記事『構造化データのテスト・検証ツールの使い方』で扱います。

📊 図解制作中

10設置場所とよくある構文エラー

JSON-LDの<script>タグは、<head>内または</body>の直前に置きます。Google公式ドキュメントによれば、ページ内のどちらに置いても解釈に違いはありません(出典: 同ガイド)。

書き方でつまずきやすいポイントは4つです。

• 末尾のカンマが余分に残ってしまう: プロパティを追加・削除した際、最後の項目の後ろに不要なカンマが残ると構文エラーになります
• 括弧の対応が崩れる: 波括弧{}と角括弧[]の開始・終了の数を、書き終えたら数えて確認します
• 表示されていない情報を書いてしまう: sameAsやaddressに、ページ本文にない情報を書くとガイドライン違反になります
• @typeのスペルミス: Organizatonのような綴り間違いは、その型として認識されない原因になります

11チェックリスト

• @context・@type・プロパティという3要素の役割を理解している
• Article・Organization・BreadcrumbListいずれかのテンプレートを自社情報に置き換えて設置できる
• 入れ子({})と配列([])の使い分けを理解している
• リッチリザルトテストでエラー・警告がないことを確認している
• マークアップの内容がページの表示情報と一致している

12よくある失敗

JSON構文のエラーに気づかず公開してしまう。カンマや括弧の1つの誤りで、構造化データ全体が読み取れなくなることがあります。公開前にリッチリザルトテストで検証する習慣をつけましょう。

とりあえず全プロパティを埋めようとしてしまう。任意プロパティは、自社に該当する情報がある場合だけ書けば十分です。存在しない情報を無理に埋めると、ガイドライン違反のリスクが高まります。

構造化データを追加すれば順位が上がると期待してしまう。Googleは構造化データを、ページ内容の理解とリッチリザルト表示に使うとしています。掲載順位を直接押し上げる仕組みではない点は、正しく理解しておく必要があります。

13FAQ

14まとめ

JSON-LDとは、<script>タグの中にJavaScriptのオブジェクト記法で構造化データを書く記述形式です。@contextで語彙の出典を、@typeでデータの種類を宣言し、あとはプロパティを並べるだけという骨格は、どの型でも共通しています。

Article・Organization・BreadcrumbListという3つの実装例を通じて、入れ子と配列という2つの組み合わせ方も確認しました。実装後は、リッチリザルトテストでの検証を忘れないようにしましょう。

構造化データとAI引用の関係そのものについては、まだ研究間でも結論が割れています。この論点を一次研究の追試という形で検証した記事が、別記事『Schema markupとAI引用の相関｜SSRN論文検証』です。実装の目的は、AI引用を直接増やすことよりも、自社の情報を機械可読な形で正確に伝えることだと捉えるのが実務的です。

15この分野を体系的に学ぶ