同じ一枚のページを、人間とAIはまったく違うふうに「読んで」いる。
人間がこのページを開くと、見出しの大きさ、余白、色、並びから、どこが会社名で、どこが値段で、どれとどれが関係しているのかを、ほとんど無意識に読み取る。ところが機械にとって、ページは最初、意味のない文字とタグの連なりでしかない。「10万円〜」という文字列が、何の値段で、何と結びついているのか。それは推測するしかない。
構造化データとは、ひとことで言えば、その推測を不要にする仕組みだ。人間向けに整えた見た目とは別に、「これは会社で、名前はこれ、設立はこの年、提供しているサービスはこれ」という関係を、機械が確実に取り出せる形でもう一枚、書いておく。見た目の層と、意味の層。ページを二重化する作業だと言ってもいい。
ここまでは、たいていの解説記事に書いてある。問題はこの先だ。「構造化データ」という言葉は、実際には複数の異なるものを一語で束ねていて、その混同が理解を妨げている。私自身、長くこの業界にいながら、人に説明しようとして初めて自分の中の整理がついていなかったことに気づいた。だからこの連載は、まず言葉の交通整理から始める。地図を持たないまま街を歩いても、迷うだけだからだ。
「構造化データ」という言葉がカバーする範囲
混乱の正体は、ひとつの言葉が4つの層を指していることにある。会話のなかで人によって違う層を指しているのに、同じ「構造化データ」という単語を使うので、話が噛み合わない。
ひとつめは考え方そのもの。機械に、コンテンツの「見た目」ではなく「意味」を渡す、という発想。これは技術ではなく方針だ。
ふたつめは語彙。「会社」を Organization、「商品」を Product、「設立日」を foundingDate と呼ぼう、という共通の単語帳。これが schema.org にあたる。
みっつめは記法。その語彙を、実際にHTMLのどこに、どんな書式で書き込むか。JSON-LD、microdata、RDFa という3つの方式がある。
よっつめは、しばしば混同される隣人、セマンティックHTML。<article> や <nav>、見出しの <h1>〜<h6> のように、HTMLタグ自体に文書の役割を持たせる書き方だ。これは構造化データと近いが、同じものではない。
この4層を分けて考えるための、いちばん使える比喩がある。schema.org は語彙と文法、JSON-LD はそれを書くためのペンだ。どんなに良いペンを持っていても語彙を知らなければ文章は書けないし、語彙だけ知っていてもペンがなければ紙に残せない。両方いる。そして「何語で書くか（語彙）」と「どのペンで書くか（記法）」は、独立して選べる別の問題だ——ここが最初のつまずきポイントになる。
記法の違い — JSON-LD / microdata / RDFa
同じことを言うのに、3つの書き方がある。たとえば「アンタイプという会社が2007年に設立された」を、それぞれの記法で書くとこうなる。
JSON-LD は、本文のHTMLとは独立した <script> タグの中に、まとめて書く。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社アンタイプ",
"foundingDate": "2007-04"
}
</script>microdata は、本文のHTMLタグそのものに属性を付けて書き込む。
<div itemscope itemtype="https://schema.org/Organization">
<span itemprop="name">株式会社アンタイプ</span>
<meta itemprop="foundingDate" content="2007-04">
</div>RDFa も microdata に似て、HTMLタグに属性を足していく方式だが、使う属性名が違う。
<div vocab="https://schema.org/" typeof="Organization">
<span property="name">株式会社アンタイプ</span>
<meta property="foundingDate" content="2007-04">
</div>3つとも、表現している意味はまったく同じだ。違うのは、どこに、どう書くか。この違いが、保守のしやすさに効いてくる。
ここで現在地を正確に押さえておく。2026年時点で、Google は3つの記法すべてをサポートしているが、推奨しているのは JSON-LD ひとつだ。microdata と RDFa も「使って問題ない」とされてはいるものの、Google 自身が「ほとんどの場合、実装と保守がいちばん楽なのは JSON-LD」と明記している。実際、microdata は古いCMSテーマに残るレガシー、RDFa は政府系・学術系という限られた領域で使われる、というのが実情だ。
理由は、上のコードを見れば直感的にわかる。microdata と RDFa は、意味の情報が本文HTMLの中に散らばって埋め込まれる。だからテンプレートの構造を変えると、マークアップも一緒に壊れやすい。対して JSON-LD は、意味の層がひとつの <script> ブロックに分離している。本文の見た目を一行も触らずに、構造化データだけを足したり直したりできる。プログラムから機械的に生成するのも、JSON-LD のほうがはるかに楽だ。
| JSON-LD | microdata | RDFa | ||
|---|---|---|---|---|
| 書く場所 | <script> タグに分離 | 本文HTMLタグの中 | 本文HTMLタグの中 | |
| 本文への侵襲 | なし | あり | あり | |
| 保守・拡張のしやすさ | 高い | 低い | 低い | |
| 主な使われ方 | 新規実装の標準 | レガシーCMS | 政府系・学術系 | |
| Googleの位置づけ | 推奨 | サポート | サポート |
結論はシンプルで、いまから新しく実装するなら JSON-LD を選べばいい。この連載でも、以降は JSON-LD を前提に話を進める。ただし「JSON-LD で書いたから順位が上がる」といった記法そのものによる優遇は存在しない。記法は、あくまで保守性の選択であって、魔法ではない。
セマンティックHTMLとの関係
ここで、先ほど4番目に挙げた隣人を片付けておきたい。セマンティックHTMLと構造化データは、よく同じものとして語られるが、役割が違う。
セマンティックHTMLは、文書の骨格に意味を与える。<header> はヘッダー、<nav> はナビゲーション、<main> は主要コンテンツ、<article> は独立した記事。見出しの <h1>〜<h6> は階層。これらは、機械がページの「どこに何があるか」という構造を把握するのを助ける。
一方、schema.org による構造化データは、そこにある実体（エンティティ）の意味を与える。「この <article> は BlogPosting であり、著者はこの人物で、公開日はこの日付だ」と。骨格の上に、固有名詞と関係を載せる作業だ。
つまり両者は競合せず、重なり合う層の関係にある。セマンティックHTMLで文書の骨を正しく組み、その上に構造化データで意味の肉を付ける。骨が歪んでいれば肉も付けにくいし、骨だけあっても「これが何なのか」は伝わらない。後の回で「4つの層」として整理するときに、この2つは別の層として再登場する。いまは「似ているが役割が違う、補い合うもの」とだけ覚えておけばいい。
schema.org とは何か
記法の話で何度も出てきた schema.org を、最後にきちんと紹介しておく。これは「会社」や「商品」や「設立日」を、世界中で同じ単語で呼ぶための共通辞書だ。
歴史は意外と新しい。schema.org が正式に発足したのは2011年6月2日。本来は競合である Google、Microsoft（Bing）、Yahoo! という検索エンジン3社が共同で立ち上げ、同年11月にロシア最大手の Yandex が加わった。バラバラの語彙を各社が勝手に決めると、サイト運営者は同じことを何度も書き分ける羽目になる。それを避け、一度書けばどの検索エンジンにも通じるようにしよう、という実務的な動機から始まっている。
現在は W3C のコミュニティグループ（2015年に発足）の場で公開議論され、語彙の追加・変更はGitHub上で進められる。最新版はバージョン30.0（2026年3月19日公開）で、Credential や Error といった型が新たに加わるなど、いまも更新が続いている。型（Organization、Product、Person など）は800を超え、2024年時点で世界4,500万を超えるドメインが何らかの形でこのマークアップを使っているとされる。つまり schema.org は、構造化Webデータの事実上の共通語になっている。
語彙が共通化されていることの意味は大きい。私たちが自社サイトに Organization と書けば、それを読む側——検索エンジンであれAIであれ——は「ああ、これは組織を表しているのだな」と、解釈を巡る曖昧さなしに受け取れる。共通辞書があるからこそ、書き手と読み手のあいだの推測が消える。冒頭で述べた「推測を不要にする」とは、突き詰めればこういうことだ。
すべては、検索エンジンのために設計されていた
ここまでで、地図はひととおり描けた。整理しておく。
構造化データとは、人間向けの見た目とは別に、機械が意味を取り出せる層をページに足す考え方である。その意味を表す共通の語彙が schema.org であり、それをHTMLに書き込む記法として JSON-LD・microdata・RDFa があって、いまの標準は JSON-LD だ。そして、文書の骨格に意味を与えるセマンティックHTMLは、その土台として隣り合っている。
ただ、この連載の本題はここから先にある。改めて並べてみると、いま整理したものはすべて、もともと検索エンジンに読ませるために設計されていた、という事実に気づく。schema.org が検索エンジン各社の共同事業として生まれたこと。記法の優劣がGoogleの推奨で語られること。構造化データの成果が長らく「リッチスニペット」、つまり検索結果での見栄えで測られてきたこと。すべての前提に、「読む相手は検索エンジンである」という想定が置かれていた。
その前提が、いま静かに動いている。同じマークアップを読む相手が、検索エンジンから、ChatGPT や Perplexity のようなAI、そして自社のRAGへと移りつつある。語彙も記法も一行も変わっていないのに、それが「何のためのものか」だけが引っ越していく。
なぜ生まれ、その意味がどう引っ越したのか。次回は、構造化データの15年をその目で辿り直す。とりわけ、ある一機能が「検索結果に表示するため」の役目を終えながら、なお生き続けているという、引っ越しの生き証人を取り上げる。
参考情報
この記事をシェアする
