ECの構造化データ実装ガイド — AI引用のためではなく、誤読を防ぐために
ECサイトの構造化データを、目的から整理して実装まで解説します。統制実験ではJSON-LDの追加によるAI引用の増加は確認されておらず、Googleも生成AI向けの特別なマークアップは不要と明言しています。それでも実装する3つの理由、優先すべきスキーマ、よくある実装ミス5つをまとめました。主要9ブランドのうち商品情報を構造化できていたのは1ブランドだけでした。
この記事のポイント
- 構造化データはAI引用を増やす道具ではありません。統制実験でも有意差は出ておらず、Googleも生成AI向けの特別なマークアップは不要と明言しています
- それでも実装する理由は3つあります。リッチリザルト、商品フィードとの整合、そして誤読の防止です
- 日本の主要9ブランドを監査したところ、商品ページでProductとOfferを構造化できていたのは1ブランドだけでした
結論、構造化データは誤読を防ぐために実装する
「AIに読ませるために構造化データを入れましょう」という記事が増えていますが、この因果は成り立っていません。実装する理由は別のところにあります。
目的は3つです。検索結果でのリッチリザルト、商品フィードとの整合の検証、そして価格・在庫・レビュー数を推測ではなく確定値で渡すこと。3つ目が「誤読の防止」で、AIとの関係でいちばん効くのはここです。
順番に説明します。まず、なぜ「AI引用のため」が成り立たないのかから。
「AIにはschemaが効かない」の正確な意味
雑にまとめると誤解されるので、条件まで書きます。
Ahrefsが2026年6月に公開した統制実験では、JSON-LDを新たに追加した1,885ページと、追加しなかった対照群4,000ページを比較しました。結果として、AI引用の有意な増加は観測されませんでした。対象は元々引用の多いページ群で、条件としては効果が出やすい側です。
Googleの見解も同じ方向です。生成AI機能向けの公式ガイドには、生成AI検索のために追加すべき特別なschema.orgのマークアップは無いと明記されています。
生成AI検索のために追加すべき特別なschema.orgのマークアップはありません。
確認されていないのは「JSON-LDを追加するとAI引用が増える」という因果だけです。検索側のリッチリザルトには従来どおり有効で、Googleは商品情報についてMerchant Centerフィードの利用を推奨しています。目的を取り違えないでください。
用語の全体像はLLMO対策とは何か、施策の確度による仕分けはチェックリスト22項目にまとめています。
それでも実装する3つの理由
1つ目はリッチリザルトです。検索結果に価格、在庫、レビューの星が出るかどうかは、クリック率に直接効きます。ここは以前から変わっていません。構造化データの本来の目的であり、いまも最大の理由です。
2つ目が商品フィードとの整合です。Googleは商品情報について、構造化データよりMerchant Centerフィードの利用を推奨しています。ではschemaは不要かというと逆で、フィードとサイトの表示が一致しているかを検証する材料になります。フィードで税込価格、サイトで税抜価格を出しているような食い違いは、schemaを見れば機械的に検出できます。フィード側の設計は商品フィードの実装で扱いました。
3つ目が誤読の防止です。価格が「¥189,800」なのか「189,800円（税込）」なのか、在庫が「残りわずか」なのか具体的な数なのか。本文の文字列だけを渡すと、AIは推測で埋めます。schemaで確定値を渡せば、推測の余地が減ります。AI引用の量は増えなくても、引用されたときの内容の正しさは変わります。
当社が返品・保証について100パターンの質問を投げた調査では、公式情報と照合して正解だったのは60.0%でした。誤答の多くは、公式に書かれていない条件を推測で補ったものです。3つ目の理由は、この種の誤りに効きます。
日本の主要ECは、どこまで実装できているか
当社が主要家電量販9ブランドの公式サイトを監査した調査では、商品ページでProductとOfferのmicrodataを確認できたのは9ブランド中1ブランドのみでした。
暫定判定の分布では、「理解される前で止まる」が6ブランドと最も多くなりました。公式ページ自体は読めるものの、商品属性や価格、在庫、配送、返品・保証を機械可読に揃える構造化データが限定的だったということです。
読み方を間違えないでください。「大手がやっていないから不要」ではなく「大手でも空いている」という状況です。カテゴリを絞れば、いま整えることで差が付く領域が残っています。
ECで優先すべきスキーマ
全部入れる必要はありません。優先度を付けます。
| スキーマ | 目的 | 最低限必要なプロパティ | 優先度 | 落とし穴 |
|---|---|---|---|---|
| Product | 商品そのものを特定させる | name、image、description、sku | 必須 | 商品名がページのタイトルと違うと、どちらが正か判断できなくなる |
| Offer | 価格・在庫・販売条件を確定値で渡す | price、priceCurrency、availability、url | 必須 | セール価格をHTMLだけで差し替え、JSON-LDが定価のまま残る |
| AggregateRating | 評価の平均と件数を渡す | ratingValue、reviewCount | 推奨 | ページ上のレビュー件数と数値が一致していないとガイドライン違反になる |
| Review | 個別レビューの内容を渡す | author、reviewRating、reviewBody | 推奨 | 自社で作成したレビューの出力は違反 |
| BreadcrumbList | サイト内の位置を示す | itemListElement（position、name、item） | 推奨 | 実際のパンくず表示と階層が食い違う |
| Organization | 運営者の実体を示す | name、url、logo、address | 推奨 | サイト内の会社概要と表記が揺れる |
| ItemList | カテゴリページの商品一覧を渡す | itemListElement（position、url） | 余力があれば | ページネーションで同じpositionが重複する |
| FAQPage | よくある質問を構造化する | mainEntity（name、acceptedAnswer） | 余力があれば | 2023年の変更でリッチリザルトの表示対象が絞られ、ECでは出ない |
FAQPageについて補足します。2023年8月の変更で、検索結果にFAQリッチリザルトが表示される対象が政府機関と医療機関のサイトに絞られました。一般のECサイトでリッチリザルトが出ることは、現在ほぼありません。それでも構造化する価値があるかというと、AIへの情報提供という観点では意味が残ります。ただし優先度は下がるので、Product・Offerを整えたあとで構いません。
実装
JSON-LDで書きます。新規実装でmicrodataを選ぶ理由はもうありません。
{
"@context": "https://schema.org",
"@type": "Product",
"name": "○○冷蔵庫 XR-500",
"image": ["https://example.com/images/xr500.jpg"],
"description": "500L・6ドア・幅685mmの大容量冷蔵庫",
"sku": "XR500-WH",
"gtin13": "4901234567890",
"brand": { "@type": "Brand", "name": "○○電機" },
"offers": {
"@type": "Offer",
"url": "https://example.com/products/xr500",
"priceCurrency": "JPY",
"price": "189800",
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"seller": { "@type": "Organization", "name": "○○ストア" }
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.3",
"reviewCount": "128"
}
}
これを <script type="application/ld+json"> で囲み、<head> 内に出力します。
主要なAIクローラーはJavaScriptを実行せず、返ってきたHTMLしか読みません。タグマネージャー経由でJSON-LDを注入している場合、Googlebotは読めてもChatGPTやPerplexityからは存在しないのと同じです。サーバー側で出力してください。
確認は簡単です。ブラウザでJavaScriptを無効にしてページを開き、ソースを表示して application/ld+json を検索してください。出てこなければ、それがそのままAIから見た状態です。
よくある実装ミス5つ
実務で失敗するのは、書き方ではなく整合の部分です。
ページ表示価格とJSON-LDの価格が違う。セール価格をHTMLだけで差し替え、JSON-LDが定価のまま残るパターンが典型です。検出方法: リッチリザルトテストで抽出した価格と、実際の表示を目視で突き合わせる
在庫状態が更新されない。availability を InStock で固定したまま、実際は品切れという状態です。検出方法: 品切れ商品のページでJSON-LDのavailabilityを確認する
レビューが実在しない、または自作である。AggregateRatingの数値が、ページ上のレビュー件数と一致しないケースを含みます。ガイドライン違反として手動対策の対象になります。検出方法: reviewCountとページ上の件数を突き合わせる
JSON-LDがJavaScriptでしか出力されない。Googlebotは読めるため、Search Console上は正常に見えます。検出方法: JavaScriptを無効にしてソースを表示する
Merchant Centerフィードとschemaが矛盾している。価格、在庫、GTINのいずれかが食い違うと、どちらの情報も確信度が下がります。検出方法: フィードの1行と、同じ商品のJSON-LDを並べて比較する
5つ目がいちばん実害が大きい項目です。矛盾を抱えた情報源は、AIから見ると「どちらが正しいか判断できない候補」になります。片方だけを正しく整えるより、2つを一致させることのほうが優先度が高いと考えてください。
検証とモニタリング
実装したら終わりではありません。商品データは毎日動きます。
検証には3つの道具を使い分けます。リッチリザルトテストはGoogleが実際にどう解釈したかを見るもので、単体のURLを確認するときに使います。スキーマ検証ツールはschema.orgの仕様に対する適合を見るもので、Googleがサポートしていないプロパティも確認できます。Search Consoleの拡張レポートはサイト全体のエラーを一覧で見るもので、定点観測に向きます。
頻度の目安は、商品を追加するタイミングで個別に1回、月次でSearch Consoleのエラー件数を確認、というくらいです。エラーが増えたときは、たいていテンプレートの改修が原因なので、リリースの記録と突き合わせると早く原因が分かります。
よくある質問
多くのテーマで基本的なProductとOfferは自動出力されます。ただしGTINやbrand、priceValidUntilが空のまま出ていることがよくあります。まずリッチリザルトテストで実際に何が出ているかを確認してください。
テンプレートで実装するので、通常は全商品に入ります。問題になるのは商品数ではなく、データが揃っていない商品が混ざることです。必須プロパティが埋まらない商品は、埋めるまで出力しないほうが安全です。
直接的なランキング要因ではありません。効くのは、リッチリザルトによって検索結果での見え方が変わり、クリック率が上がる経路です。
新規実装はJSON-LDにしてください。既存のmicrodataが正しく動いているなら、急いで移行する必要はありません。ただし両方が併存して矛盾している状態は、いちばん避けるべきです。
あります。自社で作成したレビューや、実在しない評価を出力することは違反です。AggregateRatingの数値は、ページ上に表示されているレビューと一致している必要があります。
必須プロパティが揃っていれば、推奨プロパティの警告は表示に影響しません。逆に、エラーがなくても表示されないことがあります。構造化データは表示の必要条件であって、十分条件ではありません。
まとめ
構造化データをAI対策として実装するのは、目的の取り違えです。統制実験でもAI引用の増加は確認されていません。
実装する理由は3つ。リッチリザルト、商品フィードとの整合、誤読の防止です。特に3つ目は、AI経由で自社の情報が誤って伝わるリスクを直接下げます。
日本の主要9ブランドのうち、商品情報を構造化できていたのは1ブランドだけでした。大手でも空いている領域です。実装より整合のほうが難しく、そこで差が付きます。当社では小売・EC事業者向けに無料のAI可視性診断を提供しています。
