結論を一つだけ覚えるなら、AIエンジンに正確に読み取られ、参照されやすくしたい場合はJSON-LDを選びましょう。同じschema.orgのマークアップをMicrodataやRDFaで実装しても、Googleに拒否されるわけではありません。しかしAIクローラーは、HTML全体に散らばった属性を拾い集め、一つのエンティティに組み直す必要があります。処理が一段増えるたびに、情報の見落としや誤読が起きる余地も増えます。
3つの形式が表現する語彙は同じ
まず、混同されやすい点を整理しておきましょう。JSON-LD、Microdata、RDFaは、異なる3種類のデータではありません。いずれもschema.orgの語彙をWebページへ記述するための構文です。マークアップするエンティティは共通で、Organization、Product、Article、FAQPage、HowToといった同じ語彙を使います。違うのは、属性をどこに置き、どの形式で記述するかだけです。schema.orgは3形式すべてを正式にサポートしており、Googleもすべて解析できます。したがって本記事で比べるのは「利用できるかどうか」ではなく、「機械が最も容易に読み取れるのはどれか」です。
本質的な違いは、構造化データとHTMLの結合方法
3形式を分ける最大のポイントは、構造化データがHTMLとどれほど密接に結び付いているかです。Microdataでは、itemscope、itemtype、itempropなどの属性を使い、div、span、h1といったHTML要素へ階層的にマークアップを埋め込みます。RDFaも考え方は同様ですが、vocab、typeof、propertyなどの属性で既存タグに意味を重ねます。より豊かな意味表現ができる反面、構文は複雑です。JSON-LDは正反対の設計です。エンティティ全体を独立したJSONとして記述し、画面を構成するHTMLとは切り離して、type="application/ld+json"のscriptタグ内に配置します。
- JSON-LD：自己完結したJSONオブジェクトをscriptタグ内に集約します。レイアウトから独立しているため、保守やプログラムによる生成がしやすく、Googleも明確に推奨している形式です。
- Microdata：itemscopeやitempropなどの属性を使い、ユーザーに表示されるHTMLへ直接埋め込みます。マークアップとコンテンツが密接に結び付くため、レイアウト変更時に属性が欠落しやすくなります。
- RDFa：vocab、typeof、propertyなどの属性を使ってHTMLへ埋め込みます。意味表現に最も優れ、W3Cが掲げるリンクトデータの理念にも近い一方、構文の負荷が大きく、実装ミスも起こりやすい形式です。
AIクローラーがJSON-LDを読み取りやすい理由
AIクローラーにとってJSON-LDの処理が容易な理由は明快です。一つのエンティティが完全なJSONオブジェクトとしてまとまり、フィールド、値、入れ子の関係もすべて同じブロック内に収まっているからです。パーサーで読み込めば、そのまま整理されたオブジェクトツリーになり、DOM全体をさかのぼって調べる必要がありません。対してMicrodataとRDFaでは、まずHTML全体を走査し、複数のタグに分散した属性を一つずつ収集したうえで、入れ子関係に従ってエンティティを再構成します。ページが複雑でレイアウトの階層が深いほど、再構成時のエラーも起きやすくなります。
この差をさらに広げる実務上の要因が2つあります。1つ目はJavaScriptレンダリングです。多くのAIクローラーは、Googlebotほど積極的にJSを実行しません。フロントエンドフレームワークでMicrodataをDOMへ動的に挿入している場合、クロール時点ではまだ生成されていない可能性があります。JSON-LDはサーバー側で完全な文字列を出力する実装が一般的なため、取得された時点ですぐ利用できます。2つ目は保守コストです。JSON-LDは一か所に集約されているため、FAQPageを追加したり商品の価格を変更したりするときも、該当するJSONだけを直せば済み、レイアウトには影響しません。インラインのマークアップでは、改修のたびに属性が移動・削除されていないか確認する必要があります。
MicrodataとRDFaは今も使われているのか
だからといって、MicrodataやRDFaが誤った形式というわけではありません。古いCMSやECサイトのテーマを使っている場合、標準の構造化マークアップがMicrodataであることは珍しくありません。問題なく機能しているなら、無理に変更する必要はないでしょう。RDFaも、オープンガバメントデータや学術出版など、複数の語彙をまたぐ複雑なリンクトデータを表現する場面では今なお有用です。ただし、「AIエンジンに参照されること」に目的を絞ると、両形式の強みはほとんど生かされず、むしろ弱点が目立ちます。
JSON-LDへの移行前に押さえたい落とし穴
- マークアップと画面上の内容が一致していない：JSON-LDに記載する評価、価格、著者は、ユーザーが実際に目にする情報と一致させる必要があります。不一致があると、スパムとして扱われる可能性があります。
- scriptはあるが必須フィールドが欠けている：たとえばProductにnameやoffersがない、FAQPageの質問に対応する回答がないといった場合、機械はエンティティ全体を読み飛ばします。
- @idでエンティティを関連付けていない：Organization、WebSite、Articleが相互に関係する場合は、@idで参照を設定すると、AIがより完全なブランドのナレッジマップを構築しやすくなります。
- 検証せずに公開する：公開後にSearch Consoleでエラーを見つけるより、事前にGoogleのリッチリザルト テストやschema.orgのバリデーターへ通すほうが、はるかに早く問題を解決できます。
見落とされがちな重要点があります。構造化データの目的は、機械を欺くことではありません。機械が画面から読み取った内容を確認できるようにすることです。そのため、最も確実なのは、JSON-LDを表示コンテンツの鏡として設計する方法です。画面にある情報だけをマークアップし、マークアップで宣言した情報はすべて画面上でも確認できるようにします。この一貫性こそが、AIエンジンがページの信頼性と引用価値を判断する土台になります。
構造化データを追加しても、中身のないページが引用に値するようになるわけではありません。本来引用されるべきページが、機械に理解できないという理由で見落とされるのを防ぐこと。それが構造化データの本当の役割です。— Tenten GEO Technical Audit Team
自社サイトを確認する方法
自社サイトを見直す際は、まず3つの点を確認してください。主要ページはどの形式を使っているか。同じエンティティを重複してマークアップしていないか。JSON-LDのフィールドは画面上の内容と一致しているか。多くのB2B SaaSサイトでは、異なる時期や外部委託先による実装が積み重なっています。その結果、形式の混在やフィールドの欠落が起きるのは珍しくありません。AIエンジンにとって、こうした不備はページを読み飛ばす理由になります。AIクローラーから自社サイトがどう見えているのか、どのエンティティが認識されていないのかを知りたい方は、30分のGEO診断をご予約ください。実際のページを使いながら、その場で一緒に確認します。
