JSON-LDの書き方入門｜3つのコピペ例で今日から書ける【図解つき】

「構造化データを入れておいて」と言われたけれど、JSON-LDって結局何を書けばいいのか分からない。調べてみると@contextや@typeといった見慣れない記号が並んでいて、そこで手が止まってしまう。

そういう状態のまま検索して、この記事にたどり着いた方が多いのではないかと思います。

この記事は、JSON-LDという言葉を今日はじめて見た方を想定して書きました。むずかしい説明はいったん脇に置き、身近なものにたとえながら、記事・会社概要・パンくずリストという3つのコピペ例を使って、実際に手を動かせるところまで進みます。JSON-LDの実装は、AI対策の入り口としてもよく挙げられます。

この記事では、ある会社のマーケティング部の2人と、専門家の会話をはさみながら進めます。あなたに近い立場の人の質問から読んでいただいて構いません。

• 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
• 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
• 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役

01そもそもJSON-LDって、AI検索対策で何をするものなんですか？

若葉さん

若葉さんの発言

あの…そもそもなんですが、「JSON-LD」ってどう読むんでしょうか。アルファベットの並びを見ただけで、もう身構えてしまって…。

鈴木さん

鈴木さんの発言

「ジェイソン・エルディー」と読みます。最初は誰でもそうなるので、大丈夫ですよ。ひとことで言うと、JSON-LDは、ページの中身に「これは何のデータか」という札を付ける書き方なんです。

JSON-LD(JSON for Linking Data)は、人間が読み書きしやすいJSON形式をベースにした記述方式です。HTMLの中に<script type="application/ld+json">というタグを1つ置き、その中にデータを書きます。

Googleは、実装のしやすさとエラーの起きにくさから、この形式を推奨しています。理由は3つあります。1つめは、ページの表示用テキストとは独立した<script>ブロックに書けるため、既存のHTMLタグを汚さないこと。2つめは、入れ子構造を簡潔に表現できること。3つめは、JavaScriptで動的に生成・挿入したデータも読み取れることです。

02JSON-LDの書き方は、名札にたとえるとAI検索対策で何を書く作業なんですか？

このたとえで言うと、JSON-LDを書く作業は「名札に、決められた項目を、決められた書式で書き込む」作業に近いといえます。デザインを考える必要はありません。空欄を埋めていくだけです。

03AI検索対策の土台になるJSON-LDの書き方は、骨格がいつも同じ3つだけって本当ですか？

若葉さん

若葉さんの発言

さっきの名札の話、なんとなくイメージはできたんですが…実際のコードだと、どこに何を書けばいいんでしょうか。

鈴木さん

鈴木さんの発言

そこは、どんな型を書くときも同じ骨格を使い回せます。@context・@type・プロパティの3つです。この3つさえ押さえれば、あとは型に当てはめるだけなんですよ。

@contextは、名札でいう「発行元のルール」にあたる部分です。「このデータは、schema.orgという共通の辞書に従って書いています」という宣言をします。多くの場合、値はhttps://schema.orgという決まった文字列になります。

@typeは、名札でいう「役職」にあたる部分です。「これは記事です」「これは会社です」というように、データの種類を宣言します。

プロパティは、名札でいう「名前」「連絡先」にあたる部分です。"キー": "値"という形で、具体的な情報を並べていきます。

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

04JSON-LDの全部のプロパティを、AI検索最適化のために書かないといけないんですか？

高梨課長

高梨課長の発言

鈴木さん、プロパティって、全部書かないといけないものなんですか？うちは専任がいないので、全部となると結構な作業量になりそうで心配なんですが。

鈴木さん

鈴木さんの発言

いえ、全部を書く必要はありません。 Googleのガイドラインでは、プロパティは必須と推奨の2段階に分かれています。ここに任意を加えた3段階で考えると、力の入れどころが見えてきますよ。

コードを書く前に、Googleの構造化データガイドラインが定める前提を押さえておきます。Googleのガイドラインでは必須・推奨の2段階が定義されています。本記事ではこれに「任意(定義には存在するが必須・推奨に含まれないプロパティ)」を加えた3段階で整理します。こうしたプロパティの整備は、AI検索最適化(LLMOとも呼ばれます)の土台になる作業でもあります。

05AI検索対策でも、ページに表示していない情報をJSON-LDの書き方として入れていいんですか？

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

06実際のJSON-LDって、AI検索対策としてどうやって書けばいいんですか？

若葉さん

若葉さんの発言

骨格は分かってきました。それで、実際のコードって、そのままコピペして使ってもいいものなんでしょうか。

鈴木さん

鈴木さんの発言

大丈夫です。 ここでは、使う場面が違う3つの例を用意しました。自社の情報に置き換えれば、そのまま使えるテンプレートです。

ここからは、記事(Article)・会社概要(Organization)・パンくずリスト(BreadcrumbList)という、使う場面が異なる3つの実装例を見ていきます。

07記事(Article)のJSON-LDは、AI検索対策としてどう書けばいいんですか？

最初の実装例は、ブログ記事やニュース記事に使う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が推奨するプロパティです。authorとpublisherはPerson型・Organization型を内側に入れ子にして記述します。この入れ子の考え方は、後ほど「入れ子と配列」の章で改めて整理します。

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

08会社概要(Organization)のJSON-LDの書き方は、AI検索最適化でどう変わりますか？

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

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

{
  "@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型を入れ子にして記述しています。

09パンくずリスト(BreadcrumbList)のJSON-LDは、AIOではどう書きますか？

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

以下は、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公式ドキュメント「パンくずリスト」に掲載されている例と同じ書き方です。

10入れ子と配列は、JSON-LDの書き方としてAI検索対策でどう使い分けるんですか？

若葉さん

若葉さんの発言

さっきのOrganizationは波括弧{}だけでしたけど、パンくずリストは角括弧[]も出てきましたよね。この違いって、何なんでしょうか。

鈴木さん

鈴木さんの発言

いいところに気づきましたね。 3つの実装例を並べると、JSON-LDには2種類の「組み合わせ方」があることが分かるんです。

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

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

11JSON-LDの入れ子と配列を混同すると、AI検索対策の実装でどうなってしまうんですか？

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

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

12書いたJSON-LDのコードが合っているか、AI検索対策としてどうやって確かめるんですか？

高梨課長

高梨課長の発言

コードの書き方は分かりました。それで、公開する前に、これが合っているかどうかは、誰がどうやって確認するんでしょうか。

鈴木さん

鈴木さんの発言

そこは、Googleが無料で提供しているツールがあります。特別な知識がなくても、貼り付けるだけで確認できます。

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

検証の手順は次の4ステップです。

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

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

13JSON-LDのコードは、AI検索対策としてページのどこに置けばいいんですか？

若葉さん

若葉さんの発言

コードが書けて、確認もできました。あとは、このコードをどこに置けばいいのか、というところが最後に気になっています。

鈴木さん

鈴木さんの発言

そこは、そこまで気にしなくて大丈夫なところです。ただ、代わりによく起きる間違いが4つあるので、そちらを一緒に確認しておきましょう。

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

14JSON-LDの書き方でよくある間違いは、AI検索最適化の観点で何ですか？

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

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

15よくある質問

16まとめ｜今日やる3つのこと

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

Article・Organization・BreadcrumbListという3つの実装例を通じて、入れ子と配列という2つの組み合わせ方も確認しました。実装後は、リッチリザルトテストでの検証を忘れないようにしましょう。構造化データとAI引用の関係そのものについては、まだ研究間でも結論が割れています。この論点を一次研究の追試という形で検証した記事が、別記事『Schema markupとAI引用の相関｜SSRN論文検証』です。実装の目的は、AI引用を直接増やすことよりも、自社の情報を機械可読な形で正確に伝えることだと捉えるのが実務的です。