JSON-LDとは、HTMLの本文とは分けてscriptタグ内にJSON形式で書く「機械向けの意味付けデータ」で、schema.orgの語彙を使い検索エンジンとAIにページの内容を正確に伝える仕組みです。@contextで語彙を指定し、@typeで対象の種類を示し、name・authorなどのプロパティで各要素に意味を与えます。これをGoogleのクローラや生成AIが読み取り、リッチリザルト表示・知識パネル・AI検索での引用へつなげます。本記事は、データが検索結果やAI回答に届くまでの流れを図解の発想で分解し、構文・3形式比較・実装と検証まで一気通貫で解説します。
- JSON-LDの仕組みと二層構造
- @context・@type・プロパティの役割
- 実装すべきスキーマと検証の手順
JSON-LDは本文と分離して機械にだけ意味を伝える注釈で、schema.orgの語彙を使い検索エンジンとAIに読み取らせます。基本構文の役割を理解し、Organizationなど優先度の高いスキーマから入れ、リッチリザルトテスト等で検証する流れがつかめます。
JSON-LDとは何か、どんな仕組みなのか？
JSON-LDとは「JavaScript Object Notation for Linked Data」の略で、Webページの情報に意味と構造を付与する記述形式です。人間が読む本文とは別に、機械が読むためのデータをscriptタグ内に置くのが最大の特徴です。まずは、この二層構造こそがJSON-LDの仕組みの核だと押さえておきましょう。
JSON-LD 1.0は2014年1月にW3C勧告として公開され、2020年7月に上位互換の1.1が勧告化されました（W3C）。もともとはSEO専用の技術ではなく、データの意味を機械がたどれるようにするLinked Data／RDFの思想から生まれたものです。
一言でいうと機械向けの意味付け注釈とは？
JSON-LDは、ページに書かれている内容を機械が誤解なく理解できるよう、種類と属性を明示する注釈です。本文の見た目を変えずに、検索エンジンやAIだけに構造化された意味を渡せる点が最大の利点です。人間には見えない裏側でデータを整理するイメージが近いといえます。
正式名称のLinked Dataは何を意味するのか？
Linked Dataとは、データ同士を機械がたどれるようにつなぐ考え方です。JSON-LDはこの発想をJSON形式で表現し、企業・記事・FAQといった対象を意味の辞書へひも付けます。単なる文字列を意味を持つ情報に変えるのがLinked Dataの役割です。SEOだけでなくデータ連携の基盤技術である点が特徴です。
なぜ今JSON-LDの仕組みを理解すべきなのか？
検索がSEOからAI検索へ広がる時代に、機械可読性の担保は重要度を増しています。生成AIは整った構造化データを持つページを参照しやすい傾向があり、仕組みの理解が投資判断の土台になります。AI検索対策の進め方を検討する前提としても役立つ知識です。
TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データ・意味的文脈・エンティティ認識の観点から技術的に捉え、LLMO/GEO/AEOを一次情報の設計まで踏み込んで支援しています。
JSON-LDは本文と分けて機械に意味を渡す注釈だと理解すれば、以降の話がぐっと腑に落ちますよ。
JSON-LDはどんな流れで検索結果やAI回答に届くのか？
JSON-LDのデータは「本文とは別に書かれた注釈をクローラが読み取り、インデックスやナレッジグラフへ格納し、リッチリザルトやAIの引用に反映される」という流れで機能します。データフローを分解すると、仕組みが図解のように見えてきます。まずは全体像を段階で追っていきましょう。
この流れの各段で「意味付けが正確か」が問われます。誤った注釈は反映されないだけでなく、ガイドライン違反にもなり得るため、仕組みの理解が精度に直結します。
人間が読む本文と機械が読むデータの二層構造とは？
ページは、ユーザーが見るHTML本文と、機械が読むJSON-LDの二層で成り立たせられます。本文にマークアップが挟まらないため表示を崩さず意味だけを追加できます。この分離構造が、後述する動的挿入やネスト表現のしやすさにもつながっています。
scriptタグにschema.orgの語彙で意味付けする流れとは？
実際の記述はscript type="application/ld+json"で囲み、その中にschema.orgの語彙で対象を意味付けします。@contextで辞書を指定し@typeで種類を示すことで機械が種類と属性を判別できます。Googleは本文でも
クローラからリッチリザルトやAI引用に届くまでは？
クローラが注釈を読み取ると、内容はインデックスやナレッジグラフへ整理され、リッチリザルト表示や知識パネル、AI検索の引用に使われます。構造化データの活かし方は主に検索のリッチリザルト、知識パネル、AI検索への引用の3つとされています（envydesign）。
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceが高水準にあり、支援事例でAI Overviewの引用率を改善した実績を踏まえ、届くまでの各段を検証しながら最適化しています。
本文→注釈→クローラ→ナレッジグラフ→表示・引用、という一本の流れで捉えると迷いませんね。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
JSON-LDの基本構文はどう読むのか？
JSON-LDの基本構文は、@contextで語彙を宣言し、@typeで対象の種類を示し、name・author・datePublishedなどのプロパティで各要素を意味付けする、という三段構成で読めます。ここを押さえれば、コードが書けなくても内容を理解できます。まずは各キーの役割を整理しましょう。
基本構文の読み方として、script type="application/ld+json"で形式を指定し、"@context":"https://schema.org/"で語彙を提示、"@type":"Recipe"で話題の種類を示す例が挙げられます（GMO TECH）。
次に、代表的なキーの役割を表で整理します。読み分けの基準として活用してください。
| キー | 役割 | 例 |
|---|---|---|
| @context | どの語彙を使うかの宣言 | https://schema.org/ |
| @type | 対象の種類 | Organization / Article |
| プロパティ | 各要素の意味付け | name / author / datePublished |
| @id | 対象を一意に識別する識別子 | URLベースのID |
| @graph | 複数の対象をまとめて記述 | Organizationと記事を併記 |
@contextはどの語彙を使うかをどう宣言するのか？
@contextは、その注釈がどの意味の辞書に基づくかを宣言するキーです。検索用途ではschema.orgを指定するのが一般的です。@contextがなければ機械は語の意味を正しく解釈できません。いわば会話の前提となる共通言語の宣言だと考えると分かりやすいでしょう。
@typeとプロパティは何を表すのか？
@typeは対象が企業か記事かFAQかといった種類を示し、プロパティはその属性を具体化します。nameで名称をauthorで著者をと属性ごとにラベルを付けていきます。種類と属性がそろって初めて、機械はページの意味を立体的に理解できます。
@idや@graphなどJSON-LD特有キーの役割は？
@idは対象を一意に識別する識別子で、@graphは複数の対象をひとまとまりで記述するためのキーです。企業情報と記事情報を同じページで整理する際に役立ちます。ネスト構造を表現しやすいのはJSON-LDの構造的な強みで、複雑な関係も破綻なく書けます。
TechSuite株式会社の「AI検索パートナーズ」は、技術的アプローチを担う人材とコンテンツ制作人材が一つのチームで連携し、構文設計から実装・効果測定・改善までを一気通貫で伴走しています。
@contextで辞書、@typeで種類、プロパティで属性。この3点セットで読めば構文はもう怖くありませんよ。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
なぜGoogleはJSON-LDを推奨するのか？
Googleは構造化データの3形式（JSON-LD・Microdata・RDFa）のうち、実装と管理が最も容易な形式としてJSON-LDを推奨しています。本文にタグが挟まらず、ネストや動的挿入にも対応しやすいことが理由です。まずは3形式の違いを整理しましょう。
Googleは、マークアップが有効で適切に実装されていれば3形式いずれも有効としつつ、ほとんどの場合JSON-LDを推奨すると明記しています（Google検索セントラル）。
3形式の特徴を比較すると、実装のしやすさの差が明確になります。
| 形式 | 書く場所 | 特徴 |
|---|---|---|
| JSON-LD | scriptタグ内 | 本文と分離。実装・管理が容易で推奨 |
| Microdata | HTMLタグ内属性 | 本文に直接埋め込むため管理が煩雑 |
| RDFa | HTMLタグ内属性 | 柔軟だが記述が複雑になりやすい |
本文にタグが挟まらないメリットとは？
JSON-LDは本文と分離して書けるため、表示を崩さず注釈だけを追加・修正できます。本文と分離できることが管理のしやすさと更新の速さに直結します。MicrodataやRDFaのように本文タグへ属性を差し込む必要がなく、運用負荷を大きく抑えられます。
ネストや動的挿入に強い理由は何か？
JSON-LDはEventの中にMusicVenue、その中にPostalAddressといった入れ子構造を簡潔に表現できます。CMSやJavaScriptで動的に挿入したJSON-LDもGoogleは読み取れます。動的なサイトでも仕組みを崩さず構造化データを運用できる点が実務上の強みです。
Microdataやdata-vocabularyとの違いは？
Microdataは本文に密結合するため大規模サイトでは管理が難しくなりがちです。また、かつて使われたdata-vocabulary.orgはリッチリザルトでサポート終了済みで、現在はschema.orgが標準です。新規実装ではJSON-LD×schema.orgの組み合わせが基本となります。
TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・商材・課題に応じてサイト構造や検索導線を捉え、テンプレートではなく顧客ごとに構造化データの設計を個別最適化しています。
迷ったらJSON-LD、というのがGoogleの立場。理由は管理のしやすさに尽きるのですね。
JSON-LDはどんな効果があり何から実装すべきか？
JSON-LDの効果はリッチリザルト表示・知識パネルへの反映・AI検索での引用にあり、実装はOrganizationやFAQPageなど優先度の高いスキーマから始めるのが現実的です。ただし順位への直接効果は限定的で、正確な理解と表示強化が本質です。まず効果と注意点を整理します。
構造化データの効果事例として、あるレシピ・メディア系の大手ではCTRやアクセス数の向上が公表されており、リッチリザルトページのCTRが高いとの報告もあります（Google検索セントラル）。一方、2023年以降FAQリッチリザルトは表示が制限される方向にあり、価値は短期の表示狙いから中長期の機械可読性の担保へシフトしています（envydesign）。
まず押さえるべきスキーマを表で整理します。中小企業のサイトで実用性が高い6種です。
| スキーマ | 用途 | ポイント |
|---|---|---|
| Organization | 企業情報 | サイト全体で通常1回だけ記述 |
| LocalBusiness | 店舗・営業時間 | 緯度経度も記述可 |
| BlogPosting | 記事・著者・日付 | 公開日と著者を明示 |
| FAQPage | 質問と回答 | 本文の数と一致させる |
| Service | 提供サービス | 事業内容を意味付け |
| BreadcrumbList | パンくず | positionは1始まり |
リッチリザルトや知識パネルにどう効くのか？
適切な構造化データは、パンくずや記事、レビューなど公式で約30種類あるリッチリザルトの表示条件を満たしやすくします（GIG）。必須プロパティを完全に満たすことが拡張表示の前提条件です。社名検索時の知識パネルへの採用にもつながります。
AI検索やLLMOにJSON-LDは有効なのか？
AI検索は構造化データが整ったページを優先的に参照する傾向があるとされ、JSON-LDは機械可読性を担保する基盤になります。表示狙いから機械可読性の担保へと構造化データの価値は移っています。LLMOの基礎やAEOの考え方とあわせて捉えると効果が理解しやすくなります。
順位は上がるのか、費用対効果はどう見るのか？
JSON-LDは検索順位を直接押し上げるものではなく、内容を正確に理解させ表示を強化する施策です。リッチリザルト縮小の流れも踏まえ、短期の見た目より中長期の資産として評価するのが現実的です。露出よりも成果に目を向けた設計が費用対効果を高めます。
TechSuite株式会社の「AI検索パートナーズ」は、AI検索経由での受注率が従来のSEO経由の約3倍という実績を踏まえ、露出や順位ではなく受注という成果に構造化データ施策を接続しています。
まず入れるべきスキーマの判断チェックです。
- 企業情報のOrganizationを全体で1回設置したか
- 記事にBlogPostingで著者と公開日を付けたか
- 本文にあるFAQだけをFAQPageにしたか
- パンくずのpositionが1から始まっているか
順位アップの魔法ではなく、正しく伝えて資産化する施策。ここを取り違えないことが大切です。
JSON-LDはどう実装し、どう検証するのか？
JSON-LDの実装は手動マークアップ・Googleの支援ツール・CMSプラグインの3通りで進められ、公開後はリッチリザルトテストやSchema Markup Validatorで必ず検証します。ページにない内容はマークアップしないという原則が前提です。まず実装の選択肢を整理します。
書き方は「HTMLで直接マークアップ」と「Googleの構造化データマークアップ支援ツール」の2通りが基本で、JSON-LDは
でもでも記載でき、検証にはSchema Markup ValidatorやMERKLEのツールが使えます（GIG）。手動・支援ツール・CMSのどれで書くべきか？
コードに不慣れならジェネレーターやCMSプラグインが安全で、精密に制御したいなら手動記述が向きます。ページに記載のない情報はマークアップできない点が全手法に共通する前提です。監修者欄やFAQが実際にないのに構造化データだけ入れても反映されません。
実装後はどのツールでどう検証するのか？
開発中はリッチリザルトテスト、公開後はリッチリザルトのステータスレポートで検証するのが基本です。Search Consoleのビフォーアフター比較で効果を客観的に測れます。Schema Markup Validatorで構文エラーを、URL検査ツールで検出状況を確認します。
よくある実装ミスをどう避けるのか？
頻出するのはFAQ本文数と注釈の質問数の不一致、回答内のダブルクォートによるJSON破損、画像URLの相対パス、Organizationの重複、positionの誤設定です。公開前のバリデーションで多くは防げます。LLMO対策の実務とあわせて運用フローに組み込むと安定します。
TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作のノウハウを「バクヤスAI記事代行」で培い、その制作エンジンを転用して想定質問の分解に沿った構造化データと本文を高品質に設計しています。
| よくあるミス | 回避策 |
|---|---|
| FAQ数の不一致 | 本文の質問数と注釈を一致させる |
| ダブルクォート破損 | 回答内の記号をエスケープする |
| 画像が相対パス | 絶対URLで記述する |
| Organization重複 | サイト全体で1回に統一する |
| positionミス | パンくずを1始まりにする |
公開前の最終チェックリストです。
- リッチリザルトテストでエラーがないか
- ページに表示のある内容だけを記述したか
- 画像や著者などのURLが絶対パスか
- 公開後にSearch Consoleで検出を確認したか
書いたら必ず検証、これが鉄則。ツールで確認する習慣がミスをぐっと減らしてくれます。
よくある質問
JSON-LDの仕組みや実装に関して、読者から寄せられやすい疑問に簡潔に答えます。TechSuite株式会社の「AI検索パートナーズ」は、こうした個別の疑問に対しても仕組みと構造を捉えたうえで解決策を提示し実行まで伴走しています。
- JSON-LDとMicrodataはどちらを使うべきですか
新規実装ではJSON-LDが基本です。本文と分離でき管理が容易なため、Googleもほとんどの場合JSON-LDを推奨しています。既存のMicrodataが正しく動いていれば無理に置き換える必要はありません。
- 構造化データを入れれば必ずリッチリザルトが出ますか
必ずしも表示されるとは限りません。必須プロパティを満たすことが前提で、Googleが表示可否を判断します。FAQなど一部は表示が制限されており、機械可読性の担保という中長期の価値で捉えるのが現実的です。
- どのスキーマから始めるのが効果的ですか
まずは企業情報のOrganizationとパンくずのBreadcrumbList、記事のBlogPostingが着手しやすい候補です。店舗があればLocalBusiness、本文にFAQがあればFAQPageを加えます。ページに実在する情報だけを対象にしてください。
- AI検索対策としてJSON-LDは有効ですか
有効な基盤になり得ます。AI検索は構造化データが整ったページを参照しやすい傾向があるとされ、機械可読性を高めることが引用の土台になります。本文の一次情報設計と組み合わせると効果が高まります。
まとめ
JSON-LDは、本文と分離してscriptタグに書く機械向けの意味付け注釈で、schema.orgの語彙を使い@contextで辞書、@typeで種類、プロパティで属性を示す仕組みです。この注釈をクローラや生成AIが読み取り、リッチリザルトや知識パネル、AI検索の引用につなげます。
Googleが3形式の中でJSON-LDを推奨するのは、本文にタグが挟まらず実装と管理が容易だからです。実装はOrganizationなど優先度の高いスキーマから始め、ページに実在する情報だけを対象にし、公開後は必ずツールで検証します。
順位を直接上げる魔法ではなく、内容を正確に伝え表示と引用を強化する中長期の資産です。仕組みを理解したうえで自社に合うスキーマから着実に整え、AI検索時代の機械可読性を担保していきましょう。
参考にした情報源
