構造化データの引っ越し　第6回：メリット・デメリットと技術ハードルを正直に

前回まで、空いていた層を埋める作業を、どちらかといえば前向きに辿ってきた。だがその途中で、私たちは OfferCatalog の語彙の制約や、非推奨になっていた型に、何度も足をすくわれた。あれは氷山の一角だ。構造化データは、機械の推測を減らす確かな道具である一方、正しく使おうとするほど限界とコストが見えてくる。

この連載は、最初の回で「メリットだけでなく、コスト・保守負担・過剰実装のリスクも書く」「構造化データとAI引用は相関であって因果ではない、と取り違えない」と決めて始めた。今回は、その約束を果たす回だ。前向きな話を一度脇に置き、この技術の効かない範囲を直視する。

メリットの正味 — 何が言えて、何が言えないか

まず、確かに言える部分から。構造化データは、人間向けの見た目とは別に、機械が推測せずに受け取れる「意味の層」を用意する。社名や設立年を文脈から当てさせるのではなく、確定値として渡す。前回、私たちが自社サービスを Service として書いたことで、エージェントは「unType が何を提供しているか」を曖昧さなく辿れるようになった。これは外部の評価を待たずに確かめられる、堅い効き目だ。Google も「リッチリザルトには引き続き有用」と認めているし、自社の RAG で使う資産としても、この確かさは効く。

問題は、ここから先に過剰な期待が乗りやすいことだ。「構造化データを書けば検索順位が上がる」「AIに引用される」——この手の言い切りは、いま最も注意を要する。次の節で、その線を引く。

相関≠因果 — 構造化データ「だけ」では引用されない

これは、この連載の背骨にあたる論点だ。

Google は、AIによる回答（AI Overviews / AI Mode）のために特別なマークアップは必要ない、と繰り返し述べている。構造化データはリッチリザルトには有用だが、AIの回答に出るための専用スイッチではない。そもそも Google は、構造化データを検索順位の直接のランキング要因ではないと公言している。どのスキーマ型も、AIに引用されることを保証しない。構造化データは、コンテンツの理解を助ける支援シグナルであって、引用のトリガーではない。

一方で、巷には威勢のいい数字も流れている。「スキーマを入れたサイトはAI回答での引用が2.5倍」「3.2倍」「AI Overview への露出が40%増」——こうした観察データだ。これらを頭から否定はしない。だが、ここで効くのが、相関と因果の区別である。

スキーマを丁寧に実装するようなサイトは、たいてい、そもそもコンテンツがしっかりしていて、権威があり、よく保守され、情報設計が明快な傾向がある。引用が増えたとして、それがスキーマ「だけ」の手柄なのか、それとも「スキーマを丁寧に入れるような運営姿勢」全体の結果なのかは、観察データからは切り分けられない。スキーマと引用は、同じ「よくできたサイト」という上流からそろって流れ出てくる——その可能性を排除できないのだ。Google 自身がその機構を公開していない以上、「相関は見えるが、因果は証明されていない」が、いまの正直な現在地である。

実際、この相関を正面から検証した研究も出ている。2026年5月、Ahrefs が約600万のURLを調べると、AIに引用されたページは、引用されないページよりおよそ3倍の確率で JSON-LD を持っていた——まさに、巷で「証拠」とされてきた相関そのものだ。だが彼らはそこで止まらなかった。新たにスキーマを追加した1,885ページを、引用傾向のそろった約4,000の対照ページと突き合わせ、追加の前後で引用がどう動いたかを比べた。結果、AI Overviews でも AI Mode でも ChatGPT でも、引用は意味のある形では増えなかった。スキーマは「引用されるページに同居している」が、「あとから足しても引用を押し上げはしない」。相関は本物で、因果は確認できなかった——ここまでの話を、そのまま裏づける結果だった。

だから前回、改修の効果を語ったときも、「診断スコアが上がる」「引用が増える」とは約束しなかった。言えたのは「機械が読める構造になった」という構造的事実だけだ。構造化データは、引用の十分条件でも、まして魔法でもない。ただし、これは「無意味だ」という話ではない——リッチリザルトや、機械が推測せず読める状態、自社の RAG で使える資産といった確かな効き目は、第5回で見たとおり残っている。引用という不確かな見返りのためではなく、その確かな部分のためにやる。その線引きが要る。

デメリットとコスト

嘘をつくマークアップ、という最大のリスク

構造化データの最大の危険は、技術的な難しさよりも、「機械にだけ別のことを言える」点にある。人間に見える本文とは別に書ける、ということは、本文と食い違うことも書けてしまう、ということだ。

Google の構造化データの品質ガイドラインは、この一線を明確に引いている。ユーザーに見えないコンテンツをマークアップしてはいけない。無関係な、あるいは誤解を招くコンテンツ（実体のないレビューなど）をマークアップしてはいけない。構造化データでユーザーを欺いてはいけない。これらに違反すると、手動による対策（ペナルティ）の対象になり、そのページ（場合によってはサイト単位で）はリッチリザルトの資格を失う。

そして見落とされがちなのは、これらの品質ガイドラインは自動ツールでは検査できないという点だ。Google 自身がそう明言している。構文的に完璧でも、内容が伴っていなければ、スパムとして扱われうる。前回、診断 Pro の価格を固定値で書かず、本文の料金ロジックから単価を算出して同期させたのは、まさにこの「嘘をつかない」を守るためだった。マークアップは本文より目立たないぶん、嘘が放置されやすい。価格は、その嘘が最も生まれやすい場所だ。

保守負担と、語彙の陳腐化

構造化データは、書いて終わりではない。本文を直すたびに、対応するマークアップも直さねばならない。本文と構造が食い違えば、前項の「嘘」になる。前回 OfferCatalog を CMS の取得結果から動的に生成したように、設計で保守負担を軽くはできるが、ゼロにはならない。

加えて、「正しい書き方」そのものが時代で動く。前回見た ProfessionalService の非推奨化がそうだったし、第2回で扱った FAQ リッチリザルトの表示終了（2026年5月）もそうだ。数年前のブログ記事のスニペットをそのまま貼ると、知らないうちに非推奨の型を使っている、ということが起きる。この連載自体が「意味の引っ越し」を主題にしてきたが、引っ越すのは意味だけではない。推奨される書き方も、Google が用意する機能も、静かに入れ替わっていく。

過剰実装

「何でもマークアップすればするほどよい」も、誤りだ。便益の乏しい型まで律儀に実装すれば、保守対象が増えるだけで、見返りは伴わない。前回、サイト全体をスキーマで埋め尽くすのではなく、空いていた4か所に絞ったのは、この過剰実装を避けるためでもあった。地図（第4回）が効いたのは、ここでも「やらないことを決められた」からだ。

技術ハードル

正しく、嘘なく書く覚悟を決めても、実装の現場には固有の難所がある。前回ぶつかったものも含めて、整理しておく。

スキーマ選定と、語彙の作法

正しい型を選ぶのは、見た目より難しい。前回の ProfessionalService は好例だった——意味は近いのに、非推奨。型ごとに「持てるプロパティ」も決まっていて、OfferCatalog に provider を付けて警告が出たように、意味が通りそうでも語彙にない組み合わせは通らない。schema.org は自由作文ではない。

複数の JSON-LD ブロックと、@id の解決

一枚のページに、<script type="application/ld+json"> ブロックが複数載ることがある。untype.jp でも、FAQ は独立したブロックで出力され、診断ページにはソフトウェアとしての記述が併存している。複数あること自体は問題ではない（機械はまとめて読む）が、前回の「宙吊り」で見たように、@id の参照が同じまとまりの中で解決していないと、ノード同士が繋がらない。ブロックが分かれるほど、その解決の見通しは悪くなる。保守のしやすさという観点では、できるだけ一つの @graph に束ねておくほうがよい。

JavaScript 依存のレンダリング — いちばん見落とされる罠

そして、AIエージェントの時代にこそ効いてくる、見落とされやすい落とし穴がある。構造化データを JavaScript で後から挿入していると、多くのAIクローラーには見えない。

近年の観測がこれをはっきり示している。Vercel と MERJ が5億回を超える GPTBot のアクセスを追跡したところ、JavaScript を実行した形跡はゼロだった。ChatGPT・Claude・Perplexity に内容を供給するクローラーは、いずれも生のHTMLを取得するだけで、スクリプトを実行しない。JavaScript を実行するのは、実質 Google の系統だけだ。Googlebot が二段階（まず生HTML、あとでレンダリング）で処理し、その描画基盤（Web Rendering Service）はGemini 向けの取得とも共有されている——だから Google の検索と Gemini は、レンダリング後の内容も読める。ただし、それもすべてのページで保証されるわけではない。

クローラー	JavaScript の実行	構造化データへの含意
Googlebot	実行する（二段階・遅延あり。描画基盤 WRS は Gemini とも共有）	生HTMLに置くのが安全
Bingbot	実行する（2019年以降 Chromium ベース。ただし確実性・規模は Googlebot に劣る）	生HTML推奨
GPTBot / OAI-SearchBot（OpenAI）	実行しない	JS挿入の構造化データは見えない
ClaudeBot（Anthropic）	実行しない	同上
PerplexityBot（Perplexity）	実行しない	同上

表：主要クローラーの JavaScript 実行可否（2026年時点の観測ベース）。JavaScript で後から挿入した構造化データや主要コンテンツは、Googlebot 以外のAIクローラーにはほとんど届かない。構造化データは、スクリプト実行後ではなく、最初に返る生のHTMLの中に存在させる必要がある。つまり、サーバーサイドレンダリング（SSR）か静的生成（SSG）が、事実上の要件になる。

ここで、土台の選択が効いてくる。untype.jp は Astro で作られており、JSON-LD はサーバー側で生成されて生のHTMLに出力される。前回組んだ Service や Offer のノードは、この点で最初からAIクローラーに届く形だった。皮肉なことに、構造化データの価値が最も問われるエージェントの時代に、何年も前に選んだレンダリング方式が、地味に効いている。逆にいえば、クライアント側でしか描画されないシングルページアプリでいくら丁寧にスキーマを書いても、Google 系を除くAIクローラーには空のページしか見えていない、という事態が起こりうる。

検証は構文を見るが、正直さは見ない

前回、構文の検証には schema.org 公式のバリデータを正とした。これは正しい。ただし、その検証には重要な限界がある——バリデータが見るのは構文だけだ。

型が存在するか、プロパティ名は正しいか、必須項目は揃っているか、@id の書式は妥当か。ツールが緑を返すのは、ここまでである。Google も、品質ガイドラインは自動ツールでは検査できないと明言している。

検証ツールが見るもの（構文）	検証ツールが見ないもの（品質・実態）
型が存在するか	内容が本文と一致しているか（真実性）
プロパティ名が正しいか	その情報がユーザーに見えているか
必須項目が揃っているか	そのマークアップが有用か、過剰でないか
@id の書式・参照の整合	実際にリッチリザルトとして表示されるか／AIに引用されるか

表：検証ツールの守備範囲。バリデータの「緑」は、文法が正しいことの証明であって、書いてある内容が正直であることの証明ではない。価格を偽っても、見えないテキストをマークアップしても、構文さえ整っていればツールは通してしまう。

つまり、嘘のマークアップも、構文的には通る。だから最後に効くのは、ツールではなく、「本文と一致させる」という人間側の規律だ。前回の「嘘をつかない設計」は、検証では捕まえられないこの部分を守るためのものだった。検証の緑は出発点であって、ゴールではない。

道具として、正しく使うために

構造化データは、機械の推測を減らす確かな道具だ。だが同時に、引用を保証する魔法ではなく、嘘を許さない正直さと、本文との同期という保守を要求する道具でもある。相関を因果と取り違えず、ユーザーに見えるものだけを、現在の正しい語彙で、（JavaScript の後ではなく）生のHTMLに書く——ここまで見てきた限界とハードルを裏返せば、それがそのまま「正しく使う」の中身になる。

ここまでで、技術としての構造化データは、ほぼ語り尽くした。メリットも、コストも、現場の罠も並べた。だが、まだ答えていない問いが一つ残っている。

では、何のためにやるのか。「AIに見つけてもらうため」という外部の報酬が、相関どまりで保証のないものだとしたら——私たちは何を頼りに、この手間をかけるのか。次回、いよいよ終章で、その問いに着地する。

参照情報

この記事をシェアする

X (Twitter) LinkedIn Facebook Bluesky Threads

メリットの正味 — 何が言えて、何が言えないか

相関≠因果 — 構造化データ「だけ」では引用されない