JSON-LDは「意味ない」と言われることがありますが、この主張は半分正しく半分誤りです。FAQやHowToのリッチリザルト表示が縮小した結果、リッチリザルト目的での効果は限定的になった一方、検索エンジンやAI検索に内容を正確に伝える機械可読性の担保という役割は依然重要です。本記事ではGoogle公式情報などの一次情報をもとに「意味ない」説の真偽を検証し、サイトタイプ別の必要性判断や優先すべきスキーマ、効果検証の手順まで解説します。
- 「JSON-LDは意味ない」という説の真偽
結論として、FAQ・HowToなど一部のリッチリザルトは縮小しましたが、これはJSON-LD自体の否定ではなく表示条件の厳格化です。
- JSON-LDが必要とされる本当の理由
結論として、価値の重心はリッチリザルトからAI検索やナレッジグラフ向けの機械可読性へ移っています。
- 自社が入れるべきかどうかの判断基準
結論として、指名検索で流入が足りる大手より、ブランド力で戦いにくい中小企業やローカルビジネスほど優先度が高くなります。
JSON-LDは今も必要なのか？「意味ない」は本当か
結論として、JSON-LDが「意味ない」という主張は一部の事実に基づいていますが全体としては誤りです。FAQやHowToのリッチリザルト表示が縮小した結果、リッチリザルト目当ての実装効果は薄くなりましたが、検索エンジンやAI検索に内容を正確に伝える役割は今も機能しています。
リッチリザルト目的なら効果は縮小したのか？
結論として、FAQ・HowTo系のリッチリザルトは2023年8月の仕様変更により表示範囲が大幅に縮小しました。FAQリッチリザルトは政府機関や医療機関など権威性の高いサイトのみに限定され、一般的な企業サイトやブログでは表示されなくなりました。この変更はGoogleの公式ブログで明言されています（Google 検索セントラル）。
HowToリッチリザルトについても、当初はデスクトップのみの表示に限定され、その後モバイルでは非表示になったと報告されています。こうした変更を見た担当者の一部が「JSON-LDはもう意味がない」と判断した背景には、この事実があります。
なぜ「意味ない」と言われるようになったのか？
結論として、「意味ない」論には3つの背景があります。1つ目はFAQ・HowToリッチリザルトの縮小、2つ目は構造化データが直接のランキング要因ではないというGoogleの明言、3つ目は実装コストに対して見える成果が乏しいという実感です。
これらはいずれも事実の一部を切り取ったものであり、JSON-LD全体の価値を否定する根拠にはなりません。TechSuite株式会社の「AI検索パートナーズ」は、業種や商材、既存のサイト構造によってJSON-LDの投資対効果が大きく変わることを踏まえ、テンプレート化した施策ではなく企業ごとの状況に合わせて優先度を個別に設計しています。
| 指摘される点 | 「意味ない」とされる理由 | 実際の位置づけ |
|---|---|---|
| FAQリッチリザルト | 表示されなくなった | 政府・医療系など権威サイト以外は対象外になっただけ |
| ランキング要因 | 直接には効かない | CTR向上やAI引用など間接効果は別に存在する |
| 成果の見え方 | 実装しても変化が分からない | ビフォーアフター検証を行っていないケースが多い |
| 実装コスト | 工数に対して割に合わない | 優先スキーマに絞れば工数を抑えられる |
「意味ない」論を支える3つの背景です。
- FAQ・HowToリッチリザルトの表示条件が厳格化された
- 構造化データは直接のランキング要因ではないと明言されている
- 実装コストに対して見える成果が乏しいと感じられがち
「意味ない」という声は一部事実ですが、全否定するのは早計といえそうですね
JSON-LDとは何かschema.orgとの関係は？
結論として、JSON-LDは構造化データを記述するための書式（シンタックス）であり、schema.orgはその意味付けに使う語彙（ボキャブラリ）です。両者は組み合わせて使うことで初めて機能し、どちらか一方だけでは構造化マークアップは完成しません。
JSON-LDは構造化データの記述フォーマットなのか？
結論として、JSON-LDはJavaScript Object Notation for Linked Dataの略で、ページの内容をコンピュータが理解できる形で記述するためのフォーマットです。検索エンジンはHTMLの文章を単なる文字列として読み取るため、人間のように文脈から意味を推測することが難しく、この課題を補うのが構造化データの役割です（GMOTECH）。
JSON-LDはscriptタグの中に記述され、ユーザーに見えるテキストとは分離されているため、ページのデザインを崩さずに情報を追加できる点も特徴です。構造化データを含むAI検索最適化の全体像はLLMOとはの記事でも整理しています。
schema.orgとJSON-LDはどう違うのか？
結論として、schema.orgは「何を意味するか」を定義する語彙であり、JSON-LDは「どう書くか」を定義する書式です。例えば記事であれば「BlogPosting」、企業であれば「Organization」といった型（@type）はschema.org側が用意し、それをJSON-LDの構文で記述します。
この関係を理解しておくと、必要なのはJSON-LDの書き方だけでなく、どのschema.org型を選ぶかという設計判断であることが分かります。
GoogleがJSON-LDを推奨する理由は何か？
結論として、Googleは構造化データの記述形式としてJSON-LD、Microdata、RDFaの3つを有効なものとしていますが、一般に実装と管理が最も容易な形式としてJSON-LDを推奨しています（Google 検索セントラル）。
JSON-LDはページ本文とは独立したネスト構造で記述できるため複雑な情報の入れ子表現がしやすく、JavaScriptで動的に挿入されたJSON-LDもGoogleは読み取れるとされており、CMSやテンプレートからの自動出力にも向いています。TechSuite株式会社の「AI検索パートナーズ」は、構造化データを一次情報設計の一部として捉え、エンティティ認識や意味的文脈の一貫性まで踏み込んで技術的に実装する点を強みとしています。
| 形式 | 記述場所 | 特徴 |
|---|---|---|
| JSON-LD | scriptタグ内 | 本文と分離、ネスト表現がしやすく実装管理が容易 |
| Microdata | HTML要素の属性 | 本文中に属性を埋め込む、可読性が下がりやすい |
| RDFa | HTML要素の属性 | Microdataに近いがLinked Data向けの拡張仕様 |
JSON-LDは書き方、schema.orgは意味付けの言葉、と分けて理解すると迷わなくなりますよ
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
「意味ない」説は一次情報でどう検証できるか？
結論として、Google公式情報を突き合わせると「意味ない」説の一部は事実ですが、構造化データ全体を否定する根拠にはなりません。FAQ・HowToの表示縮小と、ランキング要因ではないという明言はいずれも事実ですが、これはリッチリザルト表示の話にすぎず、機械可読性としての価値とは別の論点です。
FAQ・HowToリッチリザルトは本当に縮小したのか？
結論として、2023年8月のGoogleの発表により、FAQリッチリザルトは政府機関や医療機関など権威性の高い著名サイトのみに表示され、それ以外のサイトでは通常の検索結果表示に戻りました。HowToリッチリザルトも当初はデスクトップのみの表示に縮小され、後にモバイルでは表示されなくなったと報告されています（Google 検索セントラル ブログ）。
この変更はSearch Consoleの表示回数レポートにも影響し、該当する検索結果タイプの表示回数が減少したと公式に説明されています。
構造化データは直接のランキング要因なのか？
結論として、Googleは構造化データそのものを直接のランキング要因としていないと明言しています。順位を上げる魔法の実装ではなく、検索結果の見せ方や検索エンジンの理解を助ける仕組みという位置づけです。
一方で、リッチリザルトによるCTR向上や知識パネルへの採用など、順位以外の流入経路を強化する間接効果は複数報告されています（ENVY DESIGN）。ランキング要因ではないことと、効果がないことは同義ではありません。
未使用の構造化データは害があるのか？
結論として、Googleは使用していない構造化データがあってもSearch上の問題を引き起こさないが、可視効果もないと説明しています。つまり入れても損はしないが、条件を満たさなければ表示メリットも生まれないという中立的な位置づけです。
この一次情報は「意味ない」論の一部を裏付けつつも、機械可読性という別の価値を否定するものではない点が重要です。TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおけるAI Share of Voiceの計測を継続しており、支援先ではAI Overviewsでの引用率が改善した実績も確認しています。
| 項目 | 変更前 | 変更後（2023年8月以降） |
|---|---|---|
| FAQリッチリザルト | 多くのサイトで表示 | 政府・医療系など権威サイトのみ表示 |
| HowToリッチリザルト | PC・モバイル双方で表示 | デスクトップのみ→後にモバイルは非表示 |
| Search Consoleレポート | 表示回数を通常計測 | 該当タイプの表示回数が減少 |
| 未使用の構造化データ | 特筆事項なし | 問題は起きないが可視効果もない |
一次情報で確認しておきたい3つの事実です。
- FAQ・HowToリッチリザルトは表示対象が限定された
- 構造化データは直接のランキング要因ではない
- 未使用の構造化データは害はないが可視効果もない
公式情報を分解すると、表示条件が厳しくなっただけで無意味ではないと分かりますね
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
それでもJSON-LDが必要な理由は何か？
結論として、JSON-LDの価値はリッチリザルト狙いから機械可読性の担保へ重心が移っています。AI検索が複数ページを読み込んで回答を生成する際、意味が明示されたページは引用元として採用されやすくなる可能性があり、この役割はリッチリザルトの縮小とは無関係に機能します。
リッチリザルトはまだ効果があるのか？
結論として、レビューやパンくず、商品、求人などの一部のリッチリザルトは現在も表示され、CTR向上に寄与した事例が報告されています。Googleの公式ドキュメントでは、Rotten Tomatoesが10万ページに構造化データを追加してCTRが25%増加、The Food Networkは全ページの80%で機能を有効化してアクセス数が35%増加したと紹介されています（Google 検索セントラル）。
同ドキュメントでは楽天が滞在時間1.5倍、AMPのインタラクション率3.6倍、Nestléが競合よりCTR82%高いと報告しており、リッチリザルトの効果自体は消えていません。表示条件が厳しくなった分野があるだけで、対象が残る分野では投資価値が続いています。
ナレッジグラフ・知識パネルへの影響は？
結論として、Organizationなどのエンティティ情報を構造化データで明示すると、企業や人物、サービスに関する情報がナレッジグラフに正しく登録されやすくなります。これは検索結果の知識パネル表示だけでなく、AI検索がエンティティを認識する土台にもなります。
エンティティ情報の一貫性が保たれていないと、検索エンジンやAIがブランド名や事業内容を正確に紐づけられない場合があり、結果として引用や紹介の機会を逃す可能性があります。
AI検索に引用されやすくなるのか？
結論として、AI Overviews・ChatGPT・Perplexity・Geminiなどの生成AI検索は、回答生成の際に複数ページを読み込みますが、その際に構造化データで意味が明示されたページは理解と引用の対象になりやすいと考えられています。ある解説記事では、構造化データの網羅的な実装を土台にAI検索流入を12か月で約3倍に増やしたという自社事例が紹介されています（ENVY DESIGN、※自社事例に基づく主張のため参考情報として捉える必要があります）。
TechSuite株式会社の「AI検索パートナーズ」が支援する現場でも、AI検索経由の受注率は従来のSEO経由の約3倍にのぼるというデータがあり、露出や順位そのものではなく受注という成果に直結させる観点から構造化データの整備を位置づけています。AI検索に引用されるための施策全体はAI検索対策として整理されており、構造化データはその土台の一つです。生成AIに引用される仕組みを体系的に理解したい場合はGEO（生成エンジン最適化）の考え方も参考になります。
JSON-LDの価値を分解すると3つの活かし方に整理できます。
- 残存するリッチリザルトによるCTR向上
- ナレッジグラフ・知識パネルへの登録
- AI検索での引用されやすさ
リッチリザルトが縮んでも、AI検索という新しい活躍の場が広がっているといえそうです
自社サイトはJSON-LDを入れるべきか？
結論として、必要性はサイトタイプによって変わります。指名検索とブランド力で流入が足りている大手はあえて優先度を下げる合理性がありますが、ブランドで戦いにくい中小企業やローカルビジネス、ECや求人サイトでは機械可読性の担保が有力な打ち手になり得ます。
大手企業はやらなくてよいのか？
結論として、強いブランド力を持つ大手企業は指名検索だけで十分な流入を確保できるため、構造化データを「あえてやらない」という判断も一定の合理性を持ちます。ただしECや求人など残存リッチリザルトの恩恵が大きい領域では、大手でも実装する価値は残ります。
ポジショニングとして、指名検索で戦える立場かどうかが優先度を左右する分岐点になります。
中小企業やローカルビジネスはどうか？
結論として、ブランド力で指名検索を取りにくい中小企業やローカルビジネスほど、機械可読性による理解の後押しが有効な打ち手になり得ます。OrganizationとLocalBusinessの整備から着手することで、事業情報や所在地、営業時間などをAI検索や地図検索に正確に伝えやすくなります。
店舗名や住所の表記がページごとに揺れていると、せっかく構造化データを入れても検索エンジンが同一の事業者と認識しづらくなるため、表記の統一も欠かせません。
ECやメディアはどのスキーマを優先すべきか？
結論として、EC・メディア・求人サイトは残存するリッチリザルトの恩恵が大きい領域であり、商品ページはProduct、記事はBlogPosting、求人はJobPostingといった型を優先します。全ページ共通で整えるべきなのはBreadcrumbListで、これはサイト構造全体の理解を助ける基礎的なスキーマです。
TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とAIを活用したコンテンツ制作人材が同じチームで連携し、サイトタイプごとの優先スキーマ選定からコンテンツ設計、効果測定までを一気通貫で伴走できる体制を整えています。自社の対応状況を客観的に確認したい場合は、LLMO診断のチェック項目を使って現状を把握する方法もあります。
| サイトタイプ | 必要性の傾向 | 優先スキーマ |
|---|---|---|
| 強いブランドの大手 | あえて後回しにする選択肢もある | 残存リッチリザルト対象領域のみ |
| 中小企業・ローカルビジネス | 優先度が高い | Organization / LocalBusiness |
| ECサイト | 優先度が高い | Product / BreadcrumbList |
| メディア・ブログ | 中〜高 | BlogPosting / BreadcrumbList |
| 求人サイト | 優先度が高い | JobPosting |
導入前に確認したい判断ポイントです。
- 指名検索だけで十分な流入を確保できているか
- ECや求人など残存リッチリザルトの対象領域があるか
- 店舗名や住所などの表記が全ページで統一されているか
入れるべきかどうかは、ブランド力と業種によって答えが変わってくるようです
実装ミスと効果検証はどう行うべきか？
結論として、「実装したのに効果が出ない」という声の多くは表示条件を満たしていない実装ミスか、効果検証の手順を踏んでいないことが原因です。よくあるミスを避け、Googleが推奨するビフォーアフター検証を行うことで、必要性を自社データで確かめられます。
よくある実装ミスは何か？
結論として、現場でつまずきやすいミスは主に5点に整理できます。FAQの本文にある質問数とJSON-LD側の質問数が一致していない、回答文中のダブルクォートがエスケープされずJSON-LDが壊れているといったミスは特に頻発します（ENVY DESIGN）。
画像URLを相対パスで記述してしまう、Organizationの記述がページごとに重複する、BreadcrumbListのpositionが1始まりになっていないといったミスも報告されており、いずれも検証ツールで検出可能です。
| ミスの内容 | 起きやすい原因 | 影響 |
|---|---|---|
| FAQの質問数不一致 | 本文更新後にJSON-LDを更新し忘れる | 構文エラーや内容不整合 |
| ダブルクォート未エスケープ | 回答文中の引用符をそのまま記述 | JSON構文が壊れて読み取れない |
| 画像URLが相対パス | テンプレートのコピー流用 | 画像を正しく認識できない |
| Organizationの重複 | 複数ページで同じ情報を個別記述 | エンティティ情報の分散 |
| positionが1始まりでない | 手動記述時の数え間違い | パンくずの階層認識ミス |
効果検証はどう進めるべきか？
結論として、Googleはビフォーアフター形式の検証を推奨しています。まず構造化データを実装していないページでSearch Consoleのデータを数か月分収集し、その後機能を追加してURL検査ツールで検出を確認し、検索パフォーマンスレポートで数か月単位の変化を比較する、という手順です（Google 検索セントラル）。
AI検索での引用状況は自社サイト名やブランド名での言及をモニタリングすることで把握でき、リッチリザルトテストやスキーマ検証ツールでの構文チェックと併用すると精度が上がります。TechSuite株式会社の「AI検索パートナーズ」は、こうした効果検証の結果を踏まえたコンテンツ改善に、記事制作を高速に量産できる「バクヤスAI記事代行」の制作エンジンとナレッジを転用し、検証から改善までのサイクルを速められる体制を持っています。
効果検証で使いたいチェック項目です。
- リッチリザルトテストで表示可否を確認する
- スキーマ検証ツールで構文エラーを確認する
- Search ConsoleのURL検査ツールで検出状況を確認する
- 検索パフォーマンスレポートで数か月単位で比較する
効果が出ないと感じたら、まず実装ミスと検証手順を見直すのが近道かもしれません
よくある質問
- 構造化データを入れると順位は上がりますか
Googleは構造化データを直接のランキング要因にしていないと明言しています。ただしリッチリザルトによるCTR向上やAI検索への引用といった間接効果を通じて、結果的に流入増加につながる場合があります（Google 検索セントラル）。
- JSON-LDとMicrodataはどちらを使うべきですか
Googleは実装と管理が容易な形式として一般的にJSON-LDを推奨しています。特別な事情がない限り、これからJSON-LDで実装するのが無難といえます。
- FAQ構造化データはもう外すべきですか
一般的な企業サイトではFAQリッチリザルトの表示対象から外れていますが、構造化データ自体を外す必要はありません。Googleも未使用の構造化データはSearch上の問題を起こさないとしており、将来の仕様変更やAI検索での意味理解に備えて残す判断も選択肢になります。
- AI検索に引用されるには構造化データだけで十分ですか
構造化データだけで引用が保証されるわけではありません。一次情報としての内容の質、専門性や信頼性、意味的文脈の一貫性など複数の要素が組み合わさって初めて引用されやすくなると考えられています。
まとめ
JSON-LDが「意味ない」という主張は、FAQ・HowToリッチリザルトの縮小と直接のランキング要因ではないという事実の一部を切り取ったものであり、全体としては誤りといえます。
構造化データの価値はリッチリザルト狙いから機械可読性の担保へと重心を移しており、AI検索やナレッジグラフでの理解を助ける役割は今も機能しています。
自社サイトのタイプに合わせて優先スキーマを選び、Googleが推奨するビフォーアフター検証を行うことで、必要性を自社データで判断できるようになります。
参考にした情報源
