構造化データの種類と選び方｜ECサイトで優先すべきスキーマ【2026年版】
こんにちは、ツバサです。自分のブログにFAQ構造化データを入れたことがきっかけで構造化データに興味を持ったのですが、調べれば調べるほど種類が多くて混乱しました。schema.orgには800以上の型が定義されていて、Googleがリッチリザルトとしてサポートするのはそのうちの約25種類。しかも2025年から2026年にかけて立て続けに廃止されたタイプもあり、今の時点でどれが有効なのかが分かりにくい。
そもそも構造化データを入れると何が変わるのかを先に整理しておきます。変わるのは大きく2つです。1つ目は検索結果の見た目です。通常の検索結果はタイトル・URL・説明文だけですが、構造化データを入れると、商品の価格や在庫状況、レビューの星評価、FAQのQ&Aなどが検索結果に直接表示されることがあります。この拡張された表示のことを「リッチリザルト」と呼びます。リッチリザルトはクリック率に直結するため、ECサイトではProduct schemaの実装が特に重要です。2つ目はAIの情報理解の精度です。ChatGPTやPerplexityなどのAI検索エンジンは、Webページの情報を読み取って回答を生成します。構造化データがあると、AIは「このページの商品名は○○、価格は○○円、在庫は○○」といった情報を推測ではなく確定的に取得できます。人間向けの文章をAIが誤読するリスクが減り、正確に引用される可能性が高まります。
この記事では、2026年6月時点でGoogleがサポートしている構造化データの種類を整理し、ECサイトの担当者がどれを優先すべきかをまとめました。後半では、レビュー評価の水増しといった構造化データの偽装パターンと、「構造化データを入れればAIに引用される」という説がAhrefsの大規模調査でどう評価されたかも書いています。
もくじ
Googleがサポートする構造化データの種類一覧（2026年6月時点）
まず全体像を把握しておきます。構造化データの記述形式（フォーマット）は3種類あって、JSON-LD・Microdata・RDFaの3つをGoogleはサポートしています（Google Search Central「構造化データの仕組み」）。このうちGoogleが推奨しているのはJSON-LDで、HTMLの<head>内に<script type="application/ld+json">で埋め込む形式です。ページ本文のHTMLと分離できるのでメンテナンスしやすく、2026年時点で新規に実装するなら実質JSON-LD一択です。
Googleの構造化データ機能ギャラリーに掲載されている、現在サポートされている主なタイプは以下のとおりです。
検索結果の見た目に影響するもの（リッチリザルト対応）
- Article（ニュース・ブログ記事）
- Product（商品情報・価格・在庫）
- Review snippet / AggregateRating（星評価）
- Recipe（レシピ）
- Event（イベント）
- Local Business（店舗情報）
- Organization（企業・組織情報）
- Video（動画のサムネイル・キーモーメント）
- Job posting（求人）
- BreadcrumbList（パンくずリスト）
- Software app（アプリ情報）
- Carousel（カルーセル表示）
構造の補助・特定用途向け
- FAQ（Q&Aドロップダウン。リッチリザルトは2026年5月に廃止）
- Q&A（Yahoo知恵袋型）
- Discussion forum（フォーラム）
- Profile page（プロフィール）
- Course list（教育コース）
- Dataset（Google Dataset Search専用）
- Education Q&A（教育向けフラッシュカード）
- Image metadata（画像のライセンス情報）
- Math solver（数学問題の解法）
- Speakable（音声読み上げ対象指定）
- Subscription / paywalled content（有料記事）
- Vacation rental（バケーションレンタル）
2025年から2026年にかけてGoogleが廃止した構造化データ
Googleは2023年ごろから「使われていないリッチリザルトを整理する」方針を打ち出しており、ここ1年で廃止のペースが加速しています。
2023年8月、FAQリッチリザルトとHowToリッチリザルトが大幅に制限されました。FAQは政府・医療機関のサイトのみに表示対象が絞られ、HowToはデスクトップで完全廃止（モバイルのみ残存）。
2025年6月には7タイプが一斉に廃止されました。Book Actions、Course Info、Claim Review（ファクトチェック）、Estimated Salary、Learning Video、Special Announcement、Vehicle Listingです（Google Search Central Blog 2025年6月12日）。Googleはこの変更について「ユーザーにとって使用頻度が低く、追加の価値が限定的な表示を整理する」と説明しています。
2026年1月にはPractice Problem（練習問題）のサポートも終了し、2026年5月にはFAQリッチリザルトが完全廃止されました。Search Consoleの報告やリッチリザルトテストからも順次除外されています。
ただし注意点が2つあります。1つ目は、廃止はあくまで「Googleの検索結果でのリッチリザルト表示」の話であり、ランキングには影響しないとGoogleは明言しています。2つ目は、FAQPage等のマークアップをHTMLに残しておいても害はなく、BingbotやPerplexityBotなどAI系のクローラーは引き続きこれらの構造化データを読みます。Googleのリッチリザルトが出なくなっただけで、構造化データとしての情報伝達機能は失われていません。
僕のブログの場合、直近ではBingからのクリック数がGoogleを上回る逆転が起きています。以下はサーチコンソールとBing Webmaster Toolsのデータです（2026年6月時点）。
3か月間（2026年3月〜6月）
| 指標 | Google（日本） | Bing |
|---|---|---|
| 合計クリック | 179 | 159 |
| 合計表示 | 9,503 | 7,108 |
| CTR | 1.88% | 2.24% |
直近7日間
| 指標 | Google（日本） | Bing |
|---|---|---|
| 日平均クリック | 4.6 | 7.8 |
3か月の合計ではほぼ拮抗していますが、直近7日間ではBingの日平均クリック数がGoogleの約1.7倍に加速しています。さらにMicrosoftのCopilotに引用される回数は1日あたり約118件に達しており、3か月前の15倍です。BingのインデックスはCopilotだけでなくChatGPT SearchやPerplexityのバックエンドにもなっているので、Googleがリッチリザルトを廃止してもBing経由のAI引用チャネルが生きていれば、構造化データを残す意味は十分にあります。この話は別の記事で詳しく書いています。
ツ Bing Webmaster Toolsで分かったAI検索時代のBing対策 Copilotに引用されるには tsubasa-memo.github.io/bing-vs-google-traffic.htmlECサイトで優先して実装すべき5つの構造化データ
ECサイトの担当者が全タイプを気にする必要はありません。優先度の高いものを5つに絞ります。
1. Product（商品情報）
ECサイトにとって最も重要な構造化データです。商品名、価格、在庫状況、ブランド名、商品画像をGoogleに伝えることで、検索結果に価格や「在庫あり」の表示が出ます。Googleはeコマース向けの構造化データガイドで、Product schemaの実装を明確に推奨しています（Google Search Central「ECサイトで実装すべき構造化データ」）。ある調査ではProduct schemaの実装によりCTRが20〜30%改善したという報告もあります。
2. BreadcrumbList（パンくずリスト）
サイトの階層構造を検索エンジンに伝えるものです。検索結果のURLの代わりに「ホーム > カテゴリ > 商品名」のように表示されるので、ユーザーがページの位置づけを一目で判断できます。実装コストが低く効果が安定しているので、Productの次に入れるべきです。
3. Organization（組織情報）
法人名、ロゴ、連絡先、所在地などの基本情報です。Googleのナレッジパネルに情報が反映される可能性があり、ブランドのエンティティ認識を強化します。LLMO（AI検索最適化）の文脈では、AIが「この会社は何者か」を正確に把握するための土台になります。
4. Review / AggregateRating（レビュー・星評価）
実際のユーザーレビューに基づく星評価を検索結果に表示させるものです。視覚的に目立つため、CTRへの効果が大きい。ただし後述するとおり、レビュー件数の水増しなど偽装に使われやすいタイプでもあり、Googleのガイドラインを正確に守る必要があります。
5. FAQPage（FAQ）
2026年5月にGoogleのリッチリザルトとしては廃止されましたが、AIクローラーにとってのFAQ構造化データの価値は残っています。Q&A形式のデータはLLMが引用しやすい構造なので、LLMO施策として継続する意味があります。僕のブログでもFAQPage JSON-LDは全記事に入れたままにしています。
これ以外にEvent（セール・キャンペーン情報）やVideo（商品紹介動画）なども状況に応じて有効ですが、まずは上記5つを実装した上での追加検討です。
モール出品者と自社ECサイトで必要な対応が異なる
楽天市場・Amazon・Yahoo!ショッピングなどのモールに出品している場合と、自社ECサイト（Shopify・EC-CUBE・BASE・フルスクラッチなど）を運営している場合では、対応の仕方がまったく違います。
モール出品者は基本的に対応不要です。 モール側がProduct・BreadcrumbList等の構造化データを商品ページのテンプレートに組み込んで自動生成しています。出品者が独自にJSON-LDを追加する手段は通常ありません。モール内の商品ページに構造化データを追加したいと思っても、HTMLを直接編集する権限がないためです。
自社ECサイトでは自力での実装が必要です。 プラットフォームによって難易度が異なります。
Shopifyはテーマに基本的なProduct構造化データが含まれていますが、テーマによっては不完全な場合があります。BreadcrumbListやOrganizationなどProduct以外のタイプはテーマに含まれていないことが多く、アプリ（「JSON-LD for SEO」等）を追加するか、テーマのLiquidテンプレートにJSON-LDを直接書く必要があります。
EC-CUBEはプラグインで対応する形です。標準機能には構造化データの出力がないため、プラグインの導入かテンプレートへの手書きが必要になります。
フルスクラッチの場合は、テンプレートエンジン側で商品データをJSON-LDに変換して出力する仕組みを開発チームに組み込んでもらう形です。
少人数のEC担当者が自社サイトの構造化データを一から整備するのは負荷が大きいので、まずGoogleのリッチリザルトテストで自社商品ページのURLを入力して、現時点でどのタイプが認識されているかを確認するところから始めるのが現実的です。
AggregateRating水増しなど構造化データの偽装パターン
構造化データはJSON-LDで<head>内に自由な値を書けるため、ページ上の実態と異なる情報を申告することが技術的には可能です。Googleは構造化データガイドラインで「ページ上に表示されているコンテンツを正確に反映すること」を求めていますが、実際には違反しているサイトが存在します。
AggregateRating（レビュー評価）の水増し
最もインセンティブが高い偽装です。検索結果に星評価が表示されるとCTRに直結するため、実際のレビュー数より大幅に多い件数や、実態と異なる高評価を構造化データに書き込むケースがあります。
僕が確認したケースでは、あるサービスサイトのトップページにJSON-LDで「レビュー200件・平均4.8点」のAggregateRatingが埋め込まれていましたが、ページ上に表示されている「お客様の声」は5件のテスティモニアルだけでした。外部のレビュープラットフォーム（Googleビジネスプロフィール、Trustpilot等）へのリンクもありません。5件の声を200件のレビューとして申告するのは、Googleの構造化データガイドラインに対する明確な違反です。
Product / Offerの価格偽装
構造化データに実際のページより安い価格を入れて、検索結果で「最安値」のように見せかけるパターンです。ユーザーがクリックして実際のページを見たときに価格が異なるため、発覚しやすい偽装ではありますが、景品表示法の有利誤認表示（第5条第2号）に該当する可能性もある法的リスクの高い行為です。景品表示法では、価格について実際のものよりも著しく有利であると消費者に誤認させる表示を禁止しています（消費者庁「二重価格表示」）。
FAQPageのページ不一致
ページ上にFAQセクションが存在しないのに、JSON-LDにだけFAQPageを入れるパターンです。Googleのガイドラインでは「ページ上に表示されているコンテンツと一致すること」が求められているため、本来はNGです。2026年5月のFAQリッチリザルト廃止で、この偽装を行う動機自体がなくなりました。
構造化データは本来、偽装コストが高い信頼のシグナルとしてAIが品質判定に使える情報です。ページのテキストで「業界No.1」と書くのは誰でもできますが、Product schemaに正確な価格・在庫・外部レビューのデータを入れるのは、データが存在しないと不可能です。しかし、AggregateRatingの水増しのような偽装が横行すると、このシグナルの信頼性そのものが損なわれます。Googleもこの問題は認識しており、スパムアクションの対象になり得ます。
「構造化データを入れればAIに引用される」は本当か
LLMO（AI検索最適化）の文脈で「構造化データを入れればAIに引用される」という主張をよく見かけます。しかし、2026年5月にAhrefsが公開した大規模調査は、この主張に疑問を投げかけています。
Ahrefsは、2025年8月から2026年3月にかけてJSON-LDスキーマを追加した1,885ページを特定し、4,000ページの対照群と比較して、Google AI Overviews・AI Mode・ChatGPTでの引用数の変化を測定しました（Search Engine Journal 2026年5月11日の報道）。
結果は、いずれのプラットフォームでもスキーマ追加による引用数の有意な増加は確認されませんでした。AI Overviewsでは-4.6%の微減（統計的に有意だがAhrefs自身がスキーマのみに帰属できないと注記）、AI Modeでは+2.4%、ChatGPTでは+2.2%で、後者2つは統計的にノイズと区別できない範囲でした。
ただしこの調査には留意点があります。対象ページはすべて調査前の時点で月100回以上AIに引用されていた「すでに高パフォーマンスのページ」です。すでに十分に引用されているページにスキーマを足しても効果が見えにくいのは当然かもしれません。「ゼロからスキーマを入れたら引用が始まった」というケースは、この調査のスコープ外です。
Ahrefs自身も、構造化データにはリッチリザルト表示、音声アシスタント対応、ナレッジグラフ構築、エンティティ認識の強化といった「AI引用以外の役割」があることを認めています。
僕の理解をまとめると、構造化データは「入れただけでAI引用が増える直接のレバー」ではなく、「AIが自社の情報を正確に理解するための前提条件」として位置づけるのが妥当です。AI引用を実際に増やすのは、コンテンツの質、被リンク、サイテーション（外部での言及）、E-E-A-T（経験・専門性・権威性・信頼性）であり、構造化データはそれらが正しくAIに伝わるための通訳のような存在です。
FAQ
Q. 構造化データを入れると検索順位は上がりますか？
A. Googleは構造化データの有無がランキングに直接影響するとは公言していません。2025〜2026年に複数の構造化データタイプを廃止した際も「ランキングには影響しない」と明言しています。ただし、リッチリザルト表示によるCTRの向上や、AIによる情報理解の正確性向上が間接的にプラスに働く可能性はあります。
Q. 楽天やAmazonの商品ページに自分で構造化データを追加できますか？
A. できません。モールの商品ページはモール側が管理するHTMLテンプレートで生成されており、出品者がJSON-LDを追加する手段は通常ありません。構造化データの整備が必要なのは自社ECサイトです。
Q. FAQのリッチリザルトが廃止されたのに、FAQPage JSON-LDを残す意味はありますか？
A. あります。Googleの検索結果にFAQのドロップダウンは表示されなくなりましたが、FAQ構造化データを残しておいてもGoogleは「問題ない」としており、BingbotやPerplexityBotなどのAI系クローラーは引き続きこのデータを読みます。LLMO（AI検索最適化）の観点ではQ&A形式の構造化データはAIが引用しやすいため、残しておく価値があります。
Q. AggregateRatingを使うときに注意すべきことは何ですか？
A. Googleの構造化データガイドラインでは、構造化データの内容がページ上に表示されているコンテンツと一致することが求められています。レビュー件数や平均評価点は、ページ上で実際に確認できるレビューの数と合致していなければなりません。外部のレビュープラットフォーム（Googleビジネスプロフィール等）のデータを引用する場合は、そのプラットフォームへのリンクが確認手段として必要です。水増しはGoogleのスパムアクションの対象となります。
Q. 構造化データの実装後にエラーがないか確認する方法はありますか？
A. GoogleのリッチリザルトテストにページのURLを入力すると、検出された構造化データのタイプとエラーの有無を確認できます。また、Search Consoleの「拡張」セクションでも構造化データの認識状況を継続的に監視できます。
Q. JSON-LDの書き方がわからない場合、どこから学べますか？
A. Googleの構造化データに関するドキュメントに、各タイプごとのコード例と必須プロパティが記載されています。ECサイト向けにはeコマースの構造化データガイドも参考になります。
Q. 構造化データの偽装がバレるとどうなりますか？
A. Googleはガイドライン違反の構造化データに対して、リッチリザルトの表示停止（マークアップが無視される）や、手動対策（検索順位への影響）を適用する可能性があります。Product schemaでの価格偽装は、景品表示法上の有利誤認表示に該当するリスクもあり、法的な問題に発展する可能性もあります。
まとめ
構造化データの種類は多いですが、ECサイトの担当者がまず対応すべきなのはProduct・BreadcrumbList・Organization・Review / AggregateRating・FAQPageの5つです。モール出品者はモール側が対応済みなので、自社ECサイトを持っている場合に実装を検討してください。
2025〜2026年にGoogleが複数のリッチリザルトを廃止しましたが、構造化データそのものの価値がなくなったわけではありません。リッチリザルトが出なくなったタイプでもAI系クローラーは読み続けていますし、正確な情報を機械可読な形式で提供することの重要性は変わりません。
一方で、構造化データを入れるだけでAIに引用されるというのは過剰な期待です。Ahrefsの調査が示したように、スキーマ追加単体ではAI引用は増えません。構造化データはAIに情報を正確に伝えるための前提条件であり、引用される記事を作るにはコンテンツの質と信頼性を積み上げる必要があります。
レビュー評価の水増しのような偽装は、短期的には検索結果で目立つかもしれませんが、Googleのスパムアクションや法的リスクを考えると割に合いません。正確な情報を正確に構造化する。地味ですが、それが長期的に正しいやり方です。
関連する記事
ツ 構造化データ（JSON-LD）の書き方｜FAQPage・Articleの実装手順 tsubasa-memo.github.io/json-ld-guide.html ツ 記事にFAQ構造化データを設置したら検索結果がどう変わるか調べた tsubasa-memo.github.io/faq-structured-data.html ツ Bing Webmaster Toolsで分かったAI検索時代のBing対策 Copilotに引用されるには tsubasa-memo.github.io/bing-vs-google-traffic.htmlよく読まれている記事
