JSON-LDとは、schema.orgなどの語彙（ボキャブラリ）で定義した意味情報を、JavaScriptオブジェクトの形式でHTMLの<script>タグ内に埋め込み、検索エンジンやAIにページの内容を正確に伝えるための構造化データの記述フォーマットです。Googleは構造化データの形式としてJSON-LD・Microdata・RDFaの3つをサポートしつつ、実装と管理が最も容易な形式としてJSON-LDを推奨しています。本記事ではシンタックスとボキャブラリの二層構造、記述場所、検索エンジンとAI検索が読み取って引用に至るまでの流れを図解的に整理し、基本の書き方と検証方法までを解説します。
- JSON-LDの仕組み（シンタックスとボキャブラリの役割分担、記述場所、読み取りの流れ）
- Microdata・RDFaとの違いとJSON-LDが推奨される理由
- 最小限の書き方と実装後の検証方法・つまずきポイント
JSON-LDは意味を定義するボキャブラリと組み合わせて機械可読性を担保する仕組みであり、検索エンジンとAI検索の双方が読み取って検索結果や回答生成に活用します。3形式の中でもGoogleはJSON-LDを推奨しており、本文と分離して記述できる点が保守性の高さにつながります。最小限のスキーマから実装し、検証ツールで確認しながら段階的に広げることが現実的な進め方です。
JSON-LDの仕組みを一言でいうと？
JSON-LDの仕組みは、意味付けのルールである「ボキャブラリ」に沿って情報を整理し、それを「シンタックス」であるJSON-LD形式でHTMLに埋め込むことで、検索エンジンやAIがページの内容を機械的に理解できるようにする仕組みです。文章を読むだけでは判断しづらい「これは会社名」「これは価格」といった意味を、コンピュータにも伝わる形で明示するのが目的です。
JSON-LDとは何の略か
JSON-LDは「JavaScript Object Notation for Linked Data」の略で、Web上のデータ同士を意味的につなぐLinked Data（RDF）の考え方をJSON形式で表現する技術です。検索エンジン対策のために生まれた専用フォーマットではなく、任意のデータをつなぐための汎用的な技術という出自を持っています（出典）。2014年にW3Cが標準化し、以降Webの構造化データ記述の主流フォーマットとして採用が広がりました。
「何を・どこに・どう書くと」伝わるかを図で理解する
JSON-LDの全体像は、意味を定義する語彙を選び、それをscriptタグの中に記述し、検索エンジンとAIがそれを読み取るという3ステップで整理できます。この3ステップを表で押さえておくと、後述する記述例やスキーマ選定の理解がスムーズになります。
| 要素 | 役割 | 具体例 |
|---|---|---|
| ボキャブラリ | 意味付けの辞書（何を表すかの定義） | schema.orgのOrganization、Recipeなど |
| シンタックス | 意味を記述する構文の仕様 | JSON-LD、Microdata、RDFa |
| 記述場所 | 実際にコードを書き込む位置 | HTMLの<head>/<body>内のscriptタグ |
| 読み取り先 | 記述内容を解釈し活用する主体 | Google検索、AI Overviews、ChatGPT等 |
TechSuite株式会社の「AI検索パートナーズ」は、構造化データが検索エンジンとAIに引用・推薦されるまでの仕組みを、構造化データ・意味的文脈・エンティティ認識・想定質問の分解といった技術的な観点から捉え、LLMO/GEO/AEOの施策に落とし込んでいます。仕様の変化にも研究とデータをもとに追従しながら支援している点が特徴です。
JSON-LDは「意味の辞書×記述構文×読み取り主体」の3つがそろって初めて機能する仕組みなんですね。
そもそも構造化データとは？なぜ機械に意味を伝える必要があるのか
構造化データとは、検索エンジンがHTMLで書かれたコンテンツを理解しやすいよう、タグを使って情報を整理したものです。検索エンジンやAIはページ内のテキストを基本的に「文字の並び」としてしか読み取れず、文脈から意味を正確に推測することが難しいため、意味付けによってその理解を助ける必要があります。
検索エンジン・AIは本文を「文字列」としてしか読めない
人間であれば「山田太郎さんは1990年生まれ」という文章から、氏名と生年月日を自然に区別できます。一方で検索エンジンやAIはこの文章を単なる文字列として処理するため、どこが人名でどこが日付かを厳密に区別するのは容易ではありません（出典）。構造化データはこの曖昧さを取り除くための補助情報にあたります。
意味付けの具体例で理解する
同じ情報でも、構造化データがあるかないかで検索エンジン側の解釈のしやすさは大きく変わります。以下の比較で、意味付けの効果を確認しておきましょう。
| 情報 | 文字列としての解釈 | 構造化データによる意味付け |
|---|---|---|
| 山田太郎 | 単なる4文字の並び | Personのname（人名） |
| 1990年生まれ | 数字と単語の並び | birthDate（生年月日） |
| パスタ | 料理名らしき単語 | Recipeのname（料理名） |
| 東京都渋谷区 | 地名の文字列 | PostalAddressのaddressLocality |
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおけるAI Share of Voiceの計測結果をもとに、どのページ・どの意味付けがAIの回答で参照されやすいかを検証しており、支援先ではAI Overviewの引用率が改善した実績もあります。こうしたデータをもとに、意味付けの優先順位を判断できる点が強みです。
機械にとっては「文脈」より「明示された意味」の方がずっと理解しやすいというのがポイントです。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
JSON-LDはどんな仕組みで検索エンジンとAIに伝わるのか
JSON-LDが検索エンジンとAIに伝わる仕組みは、シンタックスとボキャブラリの分業、scriptタグによる記述、検索エンジンによる解析とエンティティ理解、そしてAI検索による引用という一連の流れで成り立っています。この流れを理解すると、なぜ書き方1つで反映結果が変わるのかが見えてきます。
シンタックス（構文）とボキャブラリ（語彙）の二層構造
JSON-LDのようなフォーマットの仕様をまとめて「シンタックス」と呼び、意味付けの規格である「ボキャブラリ」としてschema.orgなどが存在します。Googleはボキャブラリとしてschema.orgを推奨しており、シンタックスが「書き方の文法」、ボキャブラリが「意味の辞書」という役割分担になっている点が仕組みの核心です（出典）。@contextで辞書を指定し、@typeでその辞書内の型を指定し、各プロパティで具体的な値を記述します。
記述場所とscriptタグ、本文分離のメリット
JSON-LDはHTMLページの<head>および<body>要素内の<script type="application/ld+json">タグに埋め込むJavaScript表記です。ユーザーに見える本文テキストの間にマークアップが挟まらず、EventのMusicVenueのPostalAddressのCountryのようなネストしたデータも簡単に表現できます（出典）。また、GoogleはCMSなどによってページに動的に挿入されたJSON-LDデータも読み取れるため、テンプレート単位での一括管理にも向いています。
検索エンジンがリッチリザルトや知識パネルに反映するまでの流れ
検索エンジンはJSON-LDをクロールで取得したあと、記述内容を解析してエンティティ（人物・組織・商品などの実体）として理解し、その結果を検索結果のリッチリザルトや知識パネル、ナレッジグラフへの反映に用います。この一連の流れを段階に分けると、どの処理でつまずきやすいかが把握しやすくなります。
| 段階 | 処理内容 | 反映される先 |
|---|---|---|
| クロール | ページのHTMLとscript内のJSON-LDを取得 | インデックス登録の前段 |
| 解析 | JSON構文を読み込み、型とプロパティを判定 | 構造化データの有効性判定 |
| エンティティ理解 | schema.orgの意味に基づき実体として整理 | ナレッジグラフとの紐づけ |
| 結果反映 | 検索結果や回答生成に活用 | リッチリザルト・知識パネル・AI引用 |
AI検索が構造化データを引用する理由
ChatGPTやPerplexity、Gemini、AI Overviewsといった生成AIは、複数のページを読み込んで1つの回答を生成する仕組みを持っています。構造化データで「これは会社名」「これはFAQの回答」と明示されたページは、AIにとって内容を正確に把握しやすく、引用元として採用されやすい傾向があります（出典）。このようにAIに引用されるための取り組み全体はLLMOやGEOと呼ばれ、構造化データはその技術的な土台の1つに位置づけられます。
TechSuite株式会社の「AI検索パートナーズ」は、技術的アプローチを担う人材とAIを活用したコンテンツ制作人材が同一チームで連携し、戦略設計から構造化データの技術実装、コンテンツ企画、効果測定、改善までを一気通貫で伴走できる体制を持っています。仕組みの理解だけでなく、実装から検証までを途切れさせずに進められる点が強みです。
JSON-LDの仕組みを把握するうえで押さえておきたい全体像は次の通りです。
- ボキャブラリ（schema.org）で意味を定義し、シンタックス（JSON-LD）で記述する
- scriptタグ内に本文と分離して記述できるため保守性が高い
- 検索エンジンはクロール→解析→エンティティ理解の順で読み取る
- AI検索は複数ページの構造化データを参照して回答・引用元を判断する
構文と語彙、記述場所、読み取りの4点セットで理解すると仕組み全体がすっきり整理できます。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
JSON-LD・Microdata・RDFaは何が違う？なぜJSON-LDが推奨されるのか
JSON-LD・Microdata・RDFaはいずれも構造化データを記述するためのシンタックス（構文形式）ですが、記述場所や保守性に違いがあり、Googleは実装と管理が最も容易な形式としてJSON-LDを推奨しています。3形式とも有効に実装されていれば構造化データとして機能する点は共通です。
3形式の比較で見る記述場所と保守性の違い
MicrodataやRDFaはHTMLタグの属性として本文中に直接意味付けを記述する形式で、JSON-LDは本文とは別に1か所にまとめて記述する形式です。この違いにより、JSON-LDはHTMLの構造を変えずに構造化データだけを一括で追加・修正できるという保守性の高さを持っています（出典）。
| 形式 | 記述場所 | 可読性・保守性 | Google推奨度 |
|---|---|---|---|
| JSON-LD | scriptタグ内（本文と分離） | 一括管理しやすく保守性が高い | ほとんどの場合で最も推奨 |
| Microdata | HTMLタグの属性（本文中に記述） | 本文と混在し修正の手間が増えやすい | サポート対象だが優先度は低め |
| RDFa | HTMLタグの属性（本文中に記述） | 専門知識が必要になりやすい | サポート対象だが優先度は低め |
なぜ実装・管理が最も容易とされるのか
既存のサイトがMicrodataで実装されている場合でも、特別な事情がなければリニューアルのタイミングでJSON-LDへ移行するのが一般的な進め方です（出典）。HTMLとJSONを分離できることで、複数ページのテンプレートに同じ構造化データを一括で反映しやすく、CMSとの相性も良好です。
TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・商材・既存のCMS環境ごとに事情が異なることを踏まえ、どの形式で構造化データを整備すべきかをサイトごとに個別に設計しています。テンプレート化された一律の施策ではなく、既存実装の状況を踏まえたうえで移行の優先順位を提示できる点が特徴です。
形式を選ぶ際に確認しておきたいポイントは次の通りです。
- 既存サイトの実装形式（Microdata/RDFaが残っていないか）
- CMSがJSON-LDの動的挿入に対応しているか
- 複数ページへ一括で反映できる管理体制があるか
迷ったらまずJSON-LDを選び、既存のMicrodataは移行のタイミングで整理していきましょう。
JSON-LDはどう書く？基本文法と実装マップ
JSON-LDの基本文法は、中括弧・クォーテーション・コロン・コンマ・大括弧といった限られた記号の組み合わせで構成されており、@contextと@typeを起点に必要なプロパティを追加していく形で書き進めます。まずは最小限のスキーマから実装し、ページ種別に応じて対象を広げていくのが現実的な進め方です。
文法の基礎を押さえる
JSON-LDは中括弧{}でオブジェクトのまとまりを表し、クォーテーション""でキーと値を囲み、コロン:でキーと値をつなぎ、コンマ,で要素を区切り、大括弧[]で複数の値をまとめます（出典）。この基本ルールを守るだけでも、実装時に多いダブルクォート抜けなどの破損トラブルの多くは回避できます。
最小サンプルで読み解く
例えば料理レシピのページであれば、@contextに"https://schema.org/"、@typeに"Recipe"、nameに"パスタ"と書くことで、「これは料理の話題であり、料理名はパスタである」と検索エンジンに伝えられます（出典）。企業サイトのトップページであれば、@typeを"Organization"とし、name・url・logo・sameAsといったプロパティで会社の基本情報を明示します。複数のエンティティをまとめて記述したい場合は、@graphを使ってノードの配列を作成することで、1つのJSON-LD内で複数の型を関連づけて表現できます。
代表的なスキーマと導入順の定石
どのページに何のスキーマを入れるべきかは、サイトの種類やページの役割によって異なります。まずは全ページ共通のOrganizationとBreadcrumbListから着手し、ページ特性に応じてBlogPostingやFAQPageなどを追加していく順序が定石とされています（出典）。
| ページ種別 | 推奨スキーマ | 概要 |
|---|---|---|
| 全ページ共通 | Organization／BreadcrumbList | 会社情報とサイト内の階層構造を明示 |
| 店舗・拠点ページ | LocalBusiness | 住所・営業時間・電話番号などの実店舗情報 |
| ブログ記事 | BlogPosting | 著者・公開日・更新日などの記事属性 |
| FAQページ | FAQPage | 質問と回答のペアを明示 |
| サービスページ | Service | 提供サービスの内容・対象範囲 |
TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」事業で培っており、その制作エンジンとナレッジをLLMO対策に転用しています。検索意図や想定質問の分解に沿って、ページ種別ごとに必要なスキーマと本文構成を高品質かつ高速に設計できる点が独自の強みです。
実装前に最低限用意しておきたいスキーマは次の通りです。
- Organization（会社名・URL・ロゴ・公式SNSなどのsameAs）
- BreadcrumbList（全ページ共通のナビゲーション情報）
- ページ種別に応じたBlogPosting／FAQPage／Serviceなど
文法さえ守れば書き方はシンプルなので、まずはOrganizationから始めるのがおすすめです。
実装後の検証方法とメリットは？「順位は上がるのか」の正しい理解
JSON-LDを実装したら、リッチリザルトテストなどのツールで有効性を確認する必要があります。また構造化データそのものは直接のランキング要因ではないものの、CTR向上や知識パネルの獲得、AI検索への引用といった間接的な効果が期待できます。
検証ツールとよくある失敗パターン
Googleが提供するリッチリザルトテスト（search.google.com/test/rich-results）を使うと、構造化データが有効かどうかを確認し、検索結果での表示イメージをプレビューできます（出典）。実装時に多いトラブルは、FAQ本文の質問数とJSON-LD内の質問数の不一致、回答文中のダブルクォートによる構文破損、画像URLが相対パスになっている、Organizationの重複記述、BreadcrumbListのpositionが1から始まっていないといったケースです（出典）。なお2023年以降、FAQのリッチリザルトは信頼性の高いサイトに絞って表示される傾向があり、正しく実装しても表示されないことがある点も理解しておく必要があります。
直接のランキング要因ではないが得られる間接効果
構造化データはページ内のコンテンツを記述するために使うものであり、構造化データを保持するためだけの空ページを作成したり、ユーザーに表示されない情報をマークアップすることは認められていません（出典）。Googleの公開している導入事例では、構造化データを追加した10万ページでCTRが25%増加したケースや、全ページの80%で検索機能を有効化してアクセス数が35%増加したケース、滞在時間が1.5倍になったケース、リッチリザルト表示ページのCTRが82%高かったケースなどが紹介されています（出典）。
| 指標 | 直接効果か | 内容 |
|---|---|---|
| 検索順位 | 直接効果ではない | 構造化データ自体はランキング要因に含まれない |
| CTR | 間接効果 | リッチリザルト表示によりクリック率が向上しやすい |
| 知識パネル | 間接効果 | Organizationなどの情報がナレッジグラフに反映されやすい |
| AI検索への引用 | 間接効果 | 意味が明示されたページが回答の引用元に選ばれやすい |
TechSuite株式会社の「AI検索パートナーズ」の支援では、AI検索経由での受注率が従来のSEO経由と比べて約3倍という傾向が見られています。順位やインプレッションといった露出の指標だけでなく、構造化データの整備を含めて“受注”という成果に直結させる支援を行っている点が特徴です。より具体的な進め方はLLMO対策の記事でも解説しています。
実装後の検証で確認しておきたい項目は次の通りです。
- リッチリザルトテストでエラー・警告が出ていないか
- FAQの質問数とJSON-LD内の質問数が一致しているか
- 回答文中のダブルクォートが正しくエスケープされているか
- BreadcrumbListのpositionが1から連番になっているか
順位への直接効果を期待しすぎず、CTRや引用といった間接効果を積み上げていく発想が大切です。
よくある質問
- 構造化データを入れると検索順位は上がりますか
構造化データそのものは直接のランキング要因ではありませんが、リッチリザルトによるCTR向上や知識パネルの獲得、AI検索への引用といった間接的な効果が期待できます（出典）。
- JSON-LDとMicrodataはどちらを使うべきですか
特別な事情がなければJSON-LDが無難です。Googleが推奨しており、HTMLと構造化データを分離して保守しやすいため、既存でMicrodataを使っている場合もリニューアル時にJSON-LDへ移行するのが一般的です（出典）。
- 実装したのにリッチリザルトが表示されないのはなぜですか
構文エラーや必須プロパティの不足のほか、2023年以降はFAQなどのリッチリザルトが信頼性の高いサイトに絞られる傾向があり、正しく実装しても表示されないことがあります（出典）。まずはリッチリザルトテストでエラーの有無を確認することをおすすめします。
- AI検索対策として構造化データはどこまで必要ですか
すべてのスキーマを一度に整備する必要はなく、まずはOrganizationやBreadcrumbListなど基本的なスキーマから着手し、ページ種別に応じて広げていく方法が現実的です。AI検索最適化全体の考え方はAI検索最適化の用語整理でも解説しています。
まとめ
JSON-LDの仕組みは、意味を定める「ボキャブラリ」と、それを記述する「シンタックス」の二層構造を軸に、scriptタグを介して検索エンジンやAIに情報を伝える流れで成り立っています。Microdata・RDFaと比べても保守性が高く、Googleが推奨する形式として広く採用されています。
実装にあたっては、まずOrganizationやBreadcrumbListといった基本的なスキーマから着手し、リッチリザルトテストで検証しながら段階的に対象を広げていく進め方が現実的です。構造化データは直接のランキング要因ではないものの、CTR向上やAI検索への引用といった間接的な効果を積み重ねる土台になります。
参考にした情報源
