前回、構造化データという言葉を4つの層に分けて整理した。考え方、語彙、記法、そして隣人のセマンティックHTML。地図は手に入った。今回はその地図を持って、時間をさかのぼる。
構造化データは、なぜ生まれたのか。そして、なぜその意味がいま動いているのか。この問いに答えるために、まず2年前の自社の記事を一枚、定点として置くことから始めたい。
定点：2024年、私たちが構造化データをどう語っていたか
2024年6月、当社のブログに「構造化データとは？SEOへの影響とメリット、実装方法を徹底解説」という記事が公開された。いま読み返すと、この2024年の記事は、当時の構造化データの「常識」がきれいに保存された標本になっている。
その記事は、構造化データの価値を一本の筋で説明している。検索エンジンがページの内容を深く理解できるようになり、検索結果にリッチリザルト——パンくずリスト、製品の価格やレビュー、レシピの調理時間といった、視覚的に目立つ表示——が出やすくなり、その結果クリック率（CTR）が上がり、最終的にSEO効果につながる。メリットの章は3つに分かれているが、3つとも行き着く先は「検索結果での見え方」だ。
これは、当時として何も間違っていない。むしろ正確で、丁寧な記事だ。注目したいのは、記事全体を貫く一つの前提のほうだ。構造化データを読む相手は、検索エンジンである。 ボキャブラリーもシンタックスも、最後に紹介される確認ツール（Googleのリッチリザルトテスト）も、すべてその前提の上に立っている。2024年において、それは問うまでもない当たり前だった。
ここを定点に据える。2年後のいま、この前提のどこが動いたのかを見ていく。
起源：そもそも「検索エンジンに読ませる」ために生まれた
前回ふれたとおり、schema.org が発足したのは2011年6月2日。Google、Microsoft（Bing）、Yahoo! の3社が共同で立ち上げ、同年11月に Yandex が加わった。出発時点の語彙は297の型と187の関係（relations、いまで言うプロパティ）だったというから、型だけ見てもいまの800超と比べればずいぶん小さい。
重要なのは、その動機だ。なぜ競合する検索エンジン各社が、わざわざ手を組んだのか。理由は実務的で、サイト運営者に「一度書けば、どの検索エンジンにも通じる」共通の語彙を渡すためだった。そして各社がその語彙を使って何をしたかったかといえば——検索結果を、リッチに見せることだった。
構造化データの当初の存在理由は、ここにはっきり書ける。検索結果の見栄えを良くし、検索エンジン経由の流入を増やすこと。 あの2024年の記事が語っていたメリットの構造は、そっくりそのまま、2011年の設計思想の反映だった。13年かけて、最初の目的が現場の常識として定着した、と言ってもいい。
セマンティックウェブ——ティム・バーナーズ＝リーが提唱した「機械が意味を解釈できるウェブ」という理想——も、構造化データの背景としてよく語られる。先の2024年の記事もそこに触れている。理想は大きかった。だが現場での構造化データは、長いあいだ、その理想のごく一部、「検索エンジンに意味を渡す」という用途にほぼ閉じて運用されてきた。
引っ越しの生き証人：FAQという機能の最期
では、その前提はどう動いたのか。動いたことを示す、いちばん分かりやすい証拠がある。FAQリッチリザルトの最期だ。
少し説明する。FAQPage という構造化データの型を使うと、ページのよくある質問が、検索結果に折りたたみ式のドロップダウンとして表示された。質問をクリックすると答えが開く、あの見慣れた表示だ。2024年頃まで、これは「実装すれば検索結果で目立てる」費用対効果の高い施策として広く使われていた。当時の記事が描いた「実装 → リッチリザルト → CTR」の世界の、まさに典型例である。
その機能が、二段階で消えた。
2023年8月、Googleはまず、FAQリッチリザルトの表示を「権威ある政府系・医療系サイト」にほぼ限定した。これで大多数の商用サイトでは、FAQをマークアップしても検索結果に何も出なくなった。そして2026年5月7日、その最後の枠も含めて、FAQリッチリザルトの検索表示は完全に終了した。Googleの通知は端的だった——2026年5月7日をもって、FAQリッチリザルトは検索結果に表示されない、と。あわせて、Search ConsoleのFAQレポートやリッチリザルトテストでの対応は2026年6月に、関連APIのサポートは8月に取り下げられる。そしてこれは、FAQに限った現象ではない。HowToリッチリザルトは一足先に同じ道をたどっていた——2023年8月にモバイルで、9月にデスクトップで表示が消え、すでに完全に廃止済みだ。さらに2025年6月には、書籍やコース情報など別の7タイプがまとめて廃止されている。FAQの消滅は単発の事件ではなく、「SEOツールに濫用されて実態と乖離した表示型を、対象を絞ってから消す」という、繰り返されてきたパターンの最も鮮明な一例なのだ。
つまり、2024年の記事が前提にしていた「実装 → リッチリザルト → CTR」という見返りの回路が、FAQという機能においては、まるごと外れた。2024年の常識の一部が、2年で字義どおり消えたのだ。
ここで普通なら、「では FAQPage マークアップは書くだけ無駄になったのか」という話になる。ところが、ならない。ここがこの連載の核心だ。
死んでいない。仕事が引っ越しただけ
FAQリッチリザルトの表示は消えた。しかし FAQPage という構造化データの型そのものは、いまも schema.org の有効な語彙であり続けている。そしてGoogle自身が、FAQマークアップを「ページの内容を理解するために」引き続き使うと明言している。Bingや、各種AIクローラーも、従来どおりこのマークアップを読んでいる。
整理すると、こうなる。FAQPage には、もともと2つの役割があった。ひとつは「人間に見せる」役割——検索結果のドロップダウン表示。もうひとつは「機械に意味を渡す」役割——このページは質問と回答の集まりだ、と機械に伝えること。2026年5月7日に終わったのは、前者だけだ。後者は、むしろ重みを増している。
同じ数行のコードが、ページの <head> に置かれたまま、その「目的」だけが入れ替わった。書いたときは検索結果の飾りのためだった。いまは、AIに意味を渡すために、そこにある。コードは一行も変わっていない。読む相手が変わったから、意味が変わった。
これが、私が「引っ越し」と呼びたい現象だ。技術そのものは動いていない。動いたのは、その技術が何のためにあるか、という意味のほうだ。FAQPage は、その引っ越しを誰の目にも見える形で記録している、生き証人なのである。
引っ越し先：AIエージェントとRAG
では、意味はどこへ引っ越したのか。読む相手は、誰に変わったのか。
ひとつは、AIだ。ChatGPT、Perplexity、Gemini、そしてGoogleのAI Overviews。これらが企業情報やサービスを調べる経路になりつつあり、いずれも人間のようにページを「眺める」わけではない。HTMLを解析し、意味を取り出す。このとき、構造化データで「これは組織で、これは提供サービスで、これは価格だ」と明示されていれば、AIは推測なしにそれを受け取れる。前回の言い方を借りれば、構造化データは「機械の推測を不要にする仕組み」であり、その機械の主役が、検索エンジンからAIへと移ってきた。AIに対してサイトをどう整えるかという観点は、当社でもllms.txtの記事などで扱ってきたが、その土台にあるのが構造化データだ。
もうひとつ、見落とされがちな引っ越し先がある。自社のRAGだ。RAG（検索拡張生成）は、自社のドキュメントやサイトの情報をAIに読み込ませて回答させる仕組みだが、このとき情報が構造化されているほど、機械は正確に取り出せる。ここで何が起きているかというと、構造化データの見返りが、「外から見つけてもらう」ことから、「自分でいま使える」ことへと変わっている。検索エンジンに評価してもらうための外部報酬から、自社の業務で即座に効く内部報酬へ。この転換は、連載の終盤で改めて主役として扱う。
ただし、ひとつ留保しておきたい。構造化データはAIが意味を取り出すための土台ではあるが、「マークアップを足せばAIに引用される」という因果は、まだ実証されていない。FAQマークアップを加えたら AI Overviews やチャット型AIでの引用が明確に増えた、という確たる証拠は、現時点では乏しい。土台を整えることと、露出や引用が増えることは、分けて考える必要がある。この相関と因果の切り分けは、連載の後半（第6回）で改めて扱う。
いずれにせよ、共通しているのは——読む相手が、検索エンジン一択ではなくなった、ということだ。2024年のあの記事の前提は、ここで静かに崩れている。
意味は、時代とともに引っ越す
今回の道のりを振り返る。
構造化データは2011年、検索結果をリッチに見せるという目的のために生まれた。その目的は13年かけて現場の常識になり、2024年のあの記事に、きれいな形で結晶した。ところがその前提——読む相手は検索エンジンである——が、いま動いている。FAQリッチリザルトの2段階の消滅は、その動きを日付つきで記録した生き証人だ。表示は終わったが、マークアップは死んでいない。仕事が、検索エンジン向けからAI・RAG向けへと引っ越しただけだ。
ここで強調しておきたいのは、技術が新しくなったわけではない、という点だ。schema.org の語彙も、JSON-LD という記法も、2011年からの延長線上にある。変わったのは、それが何のためにあるか、という意味のほうだ。同じ道具が、時代によって違う仕事をする。私たちが扱っているのは、そういう種類の変化である。
抽象論は、ここまでにしよう。意味が引っ越した、と言葉で言うのは簡単だ。だが本当にそうなのかは、現物を開いて確かめるしかない。次回は、私たち自身のサイト——untype.jp の <head> を開く。そこにどんな構造化データが、誰に向けて書かれているのか。引っ越しの現場を、自社の実コードで見ていく。
参考情報
この記事をシェアする
