JSON-LDとは、検索エンジンやAIにページの内容を正確に伝えるための構造化データの記述形式です。読み方は「ジェイソンエルディー」、正式名称はJSON Linked Dataで、2014年にW3Cが勧告した仕様です。難しく見えるコードですが、要点は「HTMLに<script>タグでデータの意味を書き足すだけ」というシンプルな仕組みで、慣れれば誰でもコピペで導入できます。本記事では、JSON-LDの意味・書き方・3つのメリットを図解イメージとQ&Aでわかりやすく整理し、実装から検証までの手順を解説します。
- JSON-LDの意味と基本の書き方
- 導入で得られる3つのメリット
- 実装後の検証方法と注意点
JSON-LDは、検索エンジンやAIにページの意味を伝える構造化データの記述形式で、schema.orgという語彙集と組み合わせて使います。
導入すると、検索エンジンへの正確な情報伝達、リッチリザルトによるCTR向上、AI検索での引用対策という3つの効果が期待できます。
実装後はリッチリザルトテストやSearch Consoleでエラーを確認し、末尾カンマなどの文法ミスやガイドライン違反を避けることが重要です。
【結論】JSON-LDとは?わかりやすく一言で

JSON-LDとは、Webページの内容を検索エンジンやAIが正確に理解できるように、意味情報を追加で書き足す記述形式です。人間なら文章の前後関係から「これは会社名」「これは日付」と判断できますが、コンピュータには単なる文字列にしか見えません。JSON-LDはその文字列に「これは会社名です」「これは日付です」というラベルを付ける役割を担っています。
JSON-LDは「検索エンジンに意味を翻訳して伝えるコード」
結論として、JSON-LDとはページの中の情報に意味のラベルを貼り、検索エンジンやAIに誤解なく伝えるための翻訳装置のようなコードです。たとえば「田中太郎」という文字列だけでは、それが著者名なのか会社名なのか機械には判断できません。そこにJSON-LDで「これはPersonというタイプのnameプロパティです」と書き加えることで、検索エンジンは初めてその意味を正確に認識できるようになります。
読み方や正式名称、W3C標準としての位置づけ
JSON-LDの読み方は「ジェイソンエルディー」で、正式名称はJSON Linked Dataです。JSON形式を拡張した記述形式として、2014年にW3Cによって標準として勧告されており、Web上のデータに意味や構造を付与し、検索エンジンやアプリがページ内容を正確に理解できるよう補助する仕組みとされています(e-words)。単なる一企業の独自技術ではなく、国際的な標準団体が定めた仕様である点は、導入を検討するうえで安心材料になります。
図解イメージで理解する人間とAIの読み方の違い
人間とコンピュータでは、同じ文章でも読み取れる情報量が大きく異なります。この違いを図解イメージとして整理すると、次の表のようになります。
| 読み手 | 認識できること | 認識できないこと |
|---|---|---|
| 人間 | 文脈から会社名・日付・価格などを推測できる | 特になし(文脈理解が得意) |
| 検索エンジン・AI(JSON-LDなし) | 文字列や単語の並びを認識できる | それが何を意味する情報かは推測しづらい |
| 検索エンジン・AI(JSON-LDあり) | company名・日付・価格などを構造として認識できる | ページに書かれていない情報 |
TechSuite株式会社の「AI検索パートナーズ」は、構造化データの実装においてエンティティ認識や意味的文脈の設計まで踏み込み、生成AIが引用しやすい形にページ情報を技術的に整える支援を行っています。単にコードを埋め込むだけでなく、検索エンジンやAIがどのようにページを解釈するかという仕組みの部分まで捉えて設計することが、JSON-LDを活かす前提になります。
JSON-LDの基礎を理解できたか、次のポイントで確認してみましょう。
- JSON-LDが「検索エンジンに意味を伝えるコード」だと説明できる
- 読み方(ジェイソンエルディー)と正式名称(JSON Linked Data)を言える
- W3Cが標準化した仕様であることを理解している
- 「人間には読めてもAIには読めない情報がある」という前提を理解している

JSON-LDは「意味を翻訳して伝えるコード」と覚えるとイメージが掴みやすいですね
そもそも構造化データとは?JSON-LDとの関係を図解


構造化データとは、コンピュータがページの意味を正確に理解できるように、内容をあらかじめ決められた形式で整理して記述する仕組みのことです。JSON-LDはその構造化データを実際に書くための「記述形式(シンタックス)」の一つであり、両者は上位概念と具体的な手段という関係にあります。
構造化データはコンピュータに意味を伝える仕組み
構造化データとは、HTML本文の見た目には影響を与えず、ページの裏側に「この情報はこういう意味です」という注釈を加えるコードのことです。検索エンジンは構造化データを読むことで、タイトルや価格、評価点などをバラバラの文字列ではなく意味を持った項目として認識できます。これにより検索結果への表示のされ方や、AIが回答を生成する際の情報の扱われ方に差が生まれます。
シンタックスとボキャブラリーの2軸で理解する
構造化データを理解するうえで欠かせないのが「シンタックス(記述形式)」と「ボキャブラリー(意味付けの規格)」という2つの軸です。構造化データには記述形式と意味を定義する語彙集の両方が必要で、Googleが推奨する組み合わせはシンタックス=JSON-LD、ボキャブラリー=schema.orgです(GMOTECH)。この2軸を分けて理解すると、「JSON-LDは書き方のルール」「schema.orgは使う言葉の辞書」という役割の違いがすっきり整理できます。
| 要素 | 役割 | 代表例 |
|---|---|---|
| シンタックス | データの書き方(文法)を決める | JSON-LD/Microdata/RDFa |
| ボキャブラリー | データの意味(語彙)を定義する | schema.org |
| 組み合わせ例(推奨) | 文法と語彙を組み合わせて記述する | JSON-LD+schema.org |
schema.orgはGoogleなどが整備した事実上の標準
schema.orgは、Google・Microsoft・Yahoo!などが共同で整備した事実上の標準となる語彙集です。@contextで参照する語彙を宣言し、@typeで対象の種類を指定することで、異なるシステム間でも同じ意味として解釈できるようになります(e-words)。TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とコンテンツ制作人材が一つのチームで連携し、戦略設計からスキーマ選定・実装・効果測定までを一気通貫で伴走できる体制を整えています。構造化データの設計はコード単体の話ではなく、コンテンツ戦略と技術実装を橋渡しする作業だからこそ、両輪での支援が有効です。



構造化データは「文法×語彙」の2軸で捉えると、JSON-LDの立ち位置が一気に整理されますね
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援!
なぜJSON-LDが推奨される?Microdata・RDFaとの違い


JSON-LDが推奨されるのは、HTML本文のマークアップと分離して記述できるため、既存サイトへの導入や運用が容易だからです。構造化データにはJSON-LD・Microdata・RDFaの3種類がありますが、Googleが推奨するのはJSON-LDで、それ以外の形式は反映されない可能性があります(GIGラボ)。
3つの記述形式の違いを比較する
MicrodataやRDFaはHTMLタグに属性を直接付与する形式のため、既存のマークアップ自体を変更する必要があります。一方でJSON-LDはscriptタグの中に埋め込むだけで済み、文書構造とデータ定義を分離できる点が最大の特徴です(e-words)。この違いを表で整理すると、導入のしやすさの差が明確になります。
| 形式 | 記述場所 | 保守性 | Googleでの扱い |
|---|---|---|---|
| JSON-LD | scriptタグ(HTMLと分離) | 高い | 推奨形式 |
| Microdata | HTMLタグに属性を直接付与 | 中程度 | 対応はするが推奨されない傾向 |
| RDFa | HTMLタグにRDF語彙の属性を付与 | 中程度 | 対応はするが推奨されない傾向 |
HTMLと分離できるから導入・保守がしやすい
JSON-LDはHTML本文コードに直接手を加えず、head・bodyにscriptブロックを追加するだけで実装が完了し、ページのデザインや表示に影響を与えません。この特性により、新規で構造化データを導入する場合はJSON-LDを選ぶのが一般的とされています(AI検索対策の解説記事)。デザイン変更やリニューアルの際にもデータ定義部分だけを切り出して管理できるため、長期的な保守コストを抑えやすい点も見逃せません。
Googleが推奨し他形式は反映されないことがある
構造化データをマークアップする際の注意点として、JSON-LD以外の形式は検索エンジンに反映されないケースがあることが指摘されています(GIGラボ)。すでにMicrodataやRDFaで運用しているサイトを移行する場合は、対象ページごとに記述形式を確認し、優先度の高いページからJSON-LDへ切り替えていく進め方が現実的です。TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・既存の実装状況に合わせてサイトごとに構造化データの移行計画を個別に設計し、どのページをどの順序で切り替えるべきかを整理したうえで実行まで伴走しています。
記述形式の違いを理解できたか、次の観点でチェックしてみましょう。
- JSON-LD・Microdata・RDFaの3種類の違いを説明できる
- JSON-LDがHTMLと分離できる理由を理解している
- 既存サイトの記述形式を確認したことがある



迷ったらJSON-LD一択と考えて差し支えなく、導入・保守の手間も少なくて済みますよ
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援!
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
JSON-LDの書き方をわかりやすく解説


JSON-LDの書き方は、scriptタグの中にJSON形式でデータを書くという、たった一つのルールに集約されます。構造化データは<script type=”application/ld+json”>で宣言し、波かっこの中に「key : value」の形で情報を書き、各項目をカンマで区切っていきます(GMOTECH)。
scriptタグとcontext・typeの役割
まずscriptタグのtype属性に「application/ld+json」と指定することで、ブラウザに対して「これは構造化データですよ」と伝えます。次に@contextでschema.orgという語彙を使うことを宣言し、@typeでOrganizationやArticleといった具体的な種類を指定します。@contextと@typeの2つを書くだけで、検索エンジンはそのデータがどの語彙集のどの種類の情報かを正確に判別できます。
中括弧やカンマなど記号の役割を整理する
JSON-LDの文法は、開き中括弧から始まり、文字列をクォーテーションで囲み、項目名と値をコロンで区切り、後続データがある場合のみカンマを付け、複数項目は大括弧の配列でまとめるというルールに沿っています。最後のプロパティにはカンマを付けない点が、初心者が最も詰まりやすい部分です(Web担当者Forum)。記号の役割を表で整理すると理解しやすくなります。
| 記号 | 名称 | 役割 |
|---|---|---|
| { } | 中括弧 | データのまとまり(オブジェクト)を示す |
| ” “ | クォーテーション | 文字列や項目名を囲む |
| : | コロン | 項目名と値を区切る |
| , | カンマ | 項目同士を区切る(最後の項目には付けない) |
| [ ] | 大括弧 | 複数の値を配列としてまとめる |
最小構成のコード例と代表的なスキーマ
最小構成の例として、企業情報を表すOrganizationスキーマは次のような構造になります。
- <script type=”application/ld+json”>
- {
- “@context”: “https://schema.org”,
- “@type”: “Organization”,
- “name”: “会社名”,
- “url”: “https://example.com”
- }
- </script>
この基本構造をベースに、@typeを変えることでさまざまな種類の情報を表現できます。代表的なスキーマと主なプロパティを表にまとめました。
| スキーマ名 | 用途 | 主なプロパティ例 |
|---|---|---|
| Organization | 企業・運営者情報 | name/url/logo/sameAs |
| Article | ブログ・ニュース記事 | headline/author/datePublished |
| FAQPage | よくある質問 | mainEntity/Question/acceptedAnswer |
| BreadcrumbList | パンくずリスト | itemListElement/position |
複数のノードを1つのブロックにまとめたい場合は@graphを使い、Organization・WebSite・WebPage・BreadcrumbList・Articleなどを並べて、@idとisPartOfで関係性を結びつけて記述することもできます(Web担当者Forum)。TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」事業で培ってきた制作エンジンとナレッジをLLMO対策に転用しており、想定質問の分解に沿ってFAQPageなどのスキーマ設計を高品質かつ高速に行うことができます。
コードを書く前に、次の5点を確認しておくと文法ミスを減らせます。
- scriptタグのtypeがapplication/ld+jsonになっている
- @contextでschema.orgを指定している
- @typeで正しいスキーマ名を指定している
- 最後のプロパティにカンマを付けていない



書き方の型を一度覚えれば、あとはコピペと差し替えでほとんど対応できますよ
JSON-LDを導入する3つのメリットとは?


JSON-LDを導入するメリットは、大きく3つに整理できます。①検索エンジンへの正確な情報伝達、②リッチリザルトによるCTR向上、③AI検索での引用対策です。それぞれ効果の性質が異なるため、順番に確認していきます。
①検索エンジンにページ内容を正確に伝えられる
1つ目は、検索エンジンがページの内容をエンティティ単位で正確に理解できるようになることです。構造化データがなければ検索エンジンは文字列としてしか情報を読めませんが、JSON-LDがあれば会社名・日付・価格などを意味ある項目として認識できます。この正確な理解が、後述するリッチリザルトやAI検索での引用の土台になります。
②リッチリザルトで検索結果が目立ちCTRが向上する
2つ目は、リッチリザルトによる視覚的な優位性です。構造化データを入れるとリッチリザルトとして表示でき、Google公式では約30種類が用意されており、代表例はパンくずリスト・記事・求人情報・レビューなどです(GIGラボ)。上位表示された状態でリッチリザルトが表示されると通常より大きなスペースで目立ち、クリック率が向上する可能性があるとされています(GMOTECH)。
③AI検索での引用・言及対策になる
3つ目は、AI OverviewsやChatGPT、Perplexityといった生成AIによる回答生成での引用対策です。構造化データによってエンティティや関係性が明確になったページは、AIが情報の裏付けとして参照しやすくなると考えられます。TechSuite株式会社の「AI検索パートナーズ」の支援実績では、AI検索経由での受注率が従来のSEO経由の約3倍という結果も出ており、露出や順位ではなく受注という成果に直結させることを重視した支援を行っています。あわせてLLMOとは何かを理解しておくと、JSON-LDをAI検索対策の一部として位置づけやすくなります。
| メリット | 内容 | 期待できる効果 |
|---|---|---|
| ①正確な情報伝達 | ページ内容をエンティティ単位で伝える | 誤解釈の防止・意味の一貫性 |
| ②CTR向上 | リッチリザルトとして目立つ表示になる | クリック率の向上 |
| ③AI検索の引用対策 | AI Overviews等が情報を参照しやすくなる | 引用・言及機会の増加 |



3つのメリットは土台・見え方・AI対策という別々の層に効くと考えると整理しやすいです
実装後はどう検証する?よくある失敗と注意点


JSON-LDは実装して終わりではなく、エラーがないかを検証する工程まで含めて完了と考える必要があります。検証には無料のツールを組み合わせて使うのが一般的で、代表的な失敗パターンもあらかじめ知っておくことでトラブルを避けやすくなります。
リッチリザルトテストとSchema Markup Validatorで確認する
実装後はGoogleの「リッチリザルトテスト」にURLやコードを入力してエラー・警告を確認し、Search Consoleの「拡張」セクションでサイト全体の検出状況を継続的に監視するのが望ましいとされています(AI検索対策の解説記事)。加えてSchema Markup Validatorは実装済みの構造化データの確認だけでなく、競合サイトの調査にも使えるツールです(GIGラボ)。
| ツール名 | できること | 料金 |
|---|---|---|
| リッチリザルトテスト | URL・コードでエラーと警告を確認 | 無料 |
| Schema Markup Validator | 実装済みデータの確認・競合調査 | 無料 |
| Search Console(拡張) | サイト全体の検出状況を継続監視 | 無料 |
末尾カンマなど文法エラーとガイドライン違反に注意する
文法エラーはJSON-LD全体を無効化してしまう頻出ミスで、例えばemailの後のカンマ抜けだけでもブロック全体が読み込まれなくなります(Web担当者Forum)。またページに記載がない内容はマークアップできない点も重要な注意点で、監修者欄やFAQがページ上に存在しないのにマークアップすると、ガイドライン違反として反映されない可能性があります(GIGラボ)。さらにFAQリッチリザルトの表示範囲縮小など、リッチリザルトの仕様は年々変化しているため、導入前に最新の対象範囲を確認しておくことも欠かせません。
WordPressなどCMSでの手軽な実装ルートも確認する
コードを直接書く自信がない場合でも、多くのWordPressテーマやSEOプラグインはJSON-LDを自動出力してくれます(AI検索対策の解説記事)。Google構造化データマークアップ支援ツールやMERKLEのSEO Toolsなど、ページ内容を選択・入力するだけで生成できる無料ツールもあわせて利用すると、手作業でのミスを減らせます。TechSuite株式会社の「AI検索パートナーズ」は、コンサルティングという性質上、業種・規模・既存のCMS環境に合わせて検証と改善の運用フローそのものを個別に設計し、どの工程で誰がチェックすべきかまで整理して実行を伴走しています。あわせてAI検索対策の進め方やChatGPTのSEO対策も確認しておくと、検証後の改善方針を立てやすくなります。
公開前の最終確認として、以下をチェックしましょう。
- リッチリザルトテストでエラー・警告が出ていない
- Search Consoleの拡張でサイト全体の検出状況を確認している
- ページに記載のない情報をマークアップしていない
- 末尾カンマ・クォート閉じ忘れがない



検証工程まで含めて初めてJSON-LDは実装完了と言えますね
よくある質問
- JSON-LDを入れれば必ず検索順位が上がりますか
JSON-LDの導入自体は順位を直接上げる要因ではなく、検索エンジンにページ内容を正確に伝えるための仕組みです。ただし正確な情報伝達やリッチリザルト表示によるCTR向上は、間接的に評価やクリック行動へ好影響を与える可能性があります。
- どのスキーマから始めるべきですか
まずは自社サイトの全ページに関わるOrganization(企業情報)や、記事ページのArticleから始めるのが取り組みやすいです。パンくずリストがあるサイトはBreadcrumbListも比較的導入しやすいスキーマです。
- リッチリザルトは必ず表示されますか
構造化データを正しく実装しても、リッチリザルトの表示は検索エンジン側の判断に依存するため、必ず表示されるとは限りません。また対象となるリッチリザルトの種類や表示範囲は仕様変更によって変わることがあるため、最新の対象範囲を確認しておくことが望ましいです。
- JSONやプログラミングの知識は必要ですか
本格的なカスタマイズには一定の理解が役立ちますが、Google構造化データマークアップ支援ツールやWordPressのSEOプラグインを使えば、コードをほとんど書かずに導入することも可能です。まずはテンプレートをコピーして自社情報に書き換えるところから始められます。
まとめ
JSON-LDとは、検索エンジンやAIにページの意味を正確に伝えるための構造化データの記述形式で、schema.orgという語彙と組み合わせて使うのが基本です。導入することで、正確な情報伝達・リッチリザルトによるCTR向上・AI検索での引用対策という3つのメリットが期待できます。
書き方はscriptタグの中に@contextと@typeを軸にしたJSONを記述するだけで、慣れれば一つの型として使い回せます。実装後はリッチリザルトテストなどで文法エラーがないかを確認し、ページに記載のない内容をマークアップしないという基本ルールを守ることが、安定した運用につながります。
参考にした情報源



