構造化データとは、ページの内容を検索エンジンに正しく伝えるための注釈の記述のことです。
構造化データは、長らく「リッチリザルトを出すための仕込み」として語られてきました。2026年のいま、その役割はもう一段大きくなっています。検索結果にAIによる要約が出るAI Overviewや、対話型AIがページ内容を引用して回答する場面が増え、機械にとって読み取りやすい形で情報を整えておくことが、これまで以上に効いてきました。この記事は旧版を2026年6月時点の最新事情に全面更新し、Schema.orgとJSON-LDの基礎、AI引用時代に構造化データが効く理由、ECで効く主要スキーマの実装例、そしてGoogleリッチリザルトテストの使い方までを整理します。
構造化データとは何か、現場での意味
構造化データは、HTMLで書かれたページの内容に「これは商品名」「これは価格」「これはレビューの評価」といった意味のラベルを付ける記述です。人間は見た目で何が価格かを判断できますが、検索エンジンは文字の並びだけでは意味を確実には読み取れません。そこに構造化データで注釈を付けると、機械が内容を正確に理解し、検索結果に価格や評価、在庫状況といった付加情報を表示できるようになります。
規格として広く使われているのがSchema.orgです。これはGoogle・Microsoft・Yahoo!などが協力して策定した共通の語彙で、商品・レビュー・イベント・組織・FAQなど、さまざまな対象に対応する型が用意されています。実装の書き方には複数の方式がありますが、2026年時点ではJSON-LDという形式が推奨されています。HTMLの本文に埋め込むのではなく、ページ内に独立したスクリプトとして記述できるため、本文を汚さず管理しやすいのが利点です。
EC事業者の現場での意味は具体的です。構造化データを商品ページに入れておくと、検索結果に価格やレビューの星が表示され、クリックされやすくなります。クリック率は流入に直結するため、順位を上げる施策とあわせて、表示の見栄えを整える施策として効きます。検索結果での見せ方を整える観点では、meta descriptionの書き方やSEOのためのh1タグの使い方とあわせて設計すると、タイトル・説明文・リッチな付加情報が一貫します。
現場で繰り返し見るのは、構造化データを入れたのにリッチリザルトが出ない、という相談です。多くは記述の誤りや、ガイドラインに沿わない使い方が原因です。構造化データは「入れれば必ず表示される」ものではなく、内容が正確でガイドラインに沿っていて初めて表示候補になる、という前提を押さえておく必要があります。
AI Overview・LLM引用時代に構造化データが効く理由
2026年に構造化データの重要度が増したのは、検索の出口が変わったからです。従来は青いリンクをクリックして自社ページに来てもらう流れでしたが、いまは検索結果の上部にAIによる要約が出たり、対話型AIが複数のページから情報を集めて回答したりする場面が増えました。この変化のなかで、機械が内容を正確に読み取れるかどうかが、引用・参照されるかを左右します。
構造化データは、まさにその「機械が読み取りやすい形」を提供する手段です。商品名・価格・在庫・評価・配送条件といった情報を型に沿って明示しておけば、AIが要約や回答を作るときに、あいまいさなく拾えます。逆に、見た目では分かるが注釈のないページは、機械にとって解釈の余地が残り、誤って伝わったり拾われなかったりするリスクが残ります。直近の支援案件で観測したのは、FAQを構造化データで整えた店舗が、検索結果のFAQ表示や要約での参照を取りやすくなった傾向です。
もう一つの論点は、情報の信頼性を伝える役割です。組織情報や著者情報を構造化データで明示すると、誰が発信しているかが機械に伝わります。AIが参照元を選ぶときに、発信主体が明確なページは扱いやすくなります。EC事業者にとっては、商品情報だけでなく、運営者情報やレビューの実在性を構造化データで示すことが、AI時代の信頼の土台になります。これは派手な施策ではありませんが、長く効く地味な投資です。
ECで効く主要スキーマと実装例
ECサイトで優先して入れたいスキーマは、商品を表すProduct、価格や在庫を表すOffer、レビューを表すReview/AggregateRating、よくある質問を表すFAQPage、パンくずを表すBreadcrumbListの五つです。これらは検索結果での見せ方に直結し、実装の効果が見えやすい型です。商品ページにはProductとOfferとReviewを、記事や解説ページにはFAQPageを、サイト全体にはBreadcrumbListを、という分担で考えると整理しやすくなります。
商品ページに入れるProductとOffer、AggregateRatingのJSON-LDの基本形は次のとおりです。実際の値は自店の商品情報に置き換え、表示されている内容と一致させます。表示と異なる情報を構造化データに書くのはガイドライン違反になるため、必ず実データと合わせます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "{商品名}",
"image": "{商品画像URL}",
"description": "{商品説明}",
"brand": {"@type": "Brand", "name": "{ブランド名}"},
"offers": {
"@type": "Offer",
"price": "{価格}",
"priceCurrency": "JPY",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "{平均評価}",
"reviewCount": "{レビュー件数}"
}
}
</script>
解説ページやFAQページに入れるFAQPageのJSON-LDの基本形は次のとおりです。ページ上に実際に表示されている質問と回答だけを記述するのが原則で、表示していない内容を構造化データだけに書くことはできません。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "{質問1}",
"acceptedAnswer": {"@type": "Answer", "text": "{回答1}"}
},
{
"@type": "Question",
"name": "{質問2}",
"acceptedAnswer": {"@type": "Answer", "text": "{回答2}"}
}
]
}
</script>
BreadcrumbListは、サイト内での現在地を階層で示すスキーマで、検索結果にパンくずを表示させ、サイト構造を機械に伝えます。リッチスニペットの全体像はリッチスニペット初心者ガイドで扱っているので、どの型がどんな表示につながるかをあわせて確認してください。WordPressやShopifyを使っている場合は、SEO関連のプラグインやテーマが主要スキーマを自動出力していることが多く、その場合は重複して二重に入れないよう注意します。
Googleリッチリザルトテストの使い方
構造化データを入れたら、正しく認識されるかを必ず検証します。検証にはGoogleのリッチリザルトテストを使います。URLを入力するか、HTMLコードを貼り付けると、ページに含まれる構造化データを検出し、エラーや警告を一覧で示してくれます。エラーは表示の妨げになるため修正が必要で、警告は表示はされるが改善の余地がある項目です。
検証の手順はシンプルです。商品ページのURLを入力して実行し、ProductやOfferが検出されているか、必須項目が欠けていないかを確認します。エラーが出た場合は、指摘された項目をJSON-LDで補い、再度テストします。表示と構造化データの内容が食い違っているとガイドライン違反となり、最悪の場合は手動による対策の対象になるため、価格や在庫は実データと一致させます。アパレル系の単一店舗で試したケースでは、レビュー件数の表記が表示とずれていてエラーになり、実データに合わせたことで星付き表示が安定しました。
検証は一度きりではなく、商品情報を更新したタイミングや、テーマ・プラグインを変更したタイミングでも行うと安心です。自動出力に任せている場合でも、仕様変更で出力が変わることがあるため、主要ページは定期的に点検する習慣をつけると、表示の取りこぼしを防げます。
よくある質問
構造化データを入れれば必ずリッチリザルトが表示されますか
表示されるとは限りません。構造化データは表示の候補になる条件であって、保証ではありません。内容が正確でガイドラインに沿っていることが前提で、最終的な表示は検索エンジンが判断します。
JSON-LDとMicrodataはどちらを使うべきですか
2026年時点ではJSON-LDが推奨されています。本文と分けて記述でき、管理しやすいためです。旧来のMicrodataで実装されている場合は、JSON-LDへの移行を検討すると保守が楽になります。
ECサイトでまず入れるべきスキーマは何ですか
商品ページのProduct・Offer・AggregateRating、解説ページのFAQPage、サイト全体のBreadcrumbListが優先です。検索結果での見せ方に直結し、効果が見えやすい型から始めるのが効率的です。
表示していない情報を構造化データに書いてよいですか
できません。構造化データはページに表示されている内容と一致させるのが原則です。表示と異なる情報を書くとガイドライン違反となり、リッチリザルトの対象から外れる恐れがあります。
WordPressやShopifyでも手動で入れる必要がありますか
多くのテーマやSEOプラグインが主要スキーマを自動出力します。その場合は手動で追加すると二重になるため、まず現状の出力をリッチリザルトテストで確認し、不足している型だけを補うのが安全です。
AI Overviewに引用されやすくする方法はありますか
情報を構造化データで正確に整え、FAQや商品情報を機械が読み取りやすい形にしておくことが土台になります。発信主体や著者情報を明示することも、参照される確率を高める要素です。
構造化データのエラーはどう直せばよいですか
リッチリザルトテストが指摘する欠けている項目をJSON-LDで補い、再度テストして解消を確認します。価格や在庫、レビュー件数は表示と一致させ、必須項目を埋めることが基本です。
著者:齋藤竹紘(株式会社オルセル 編集長/5,000社以上のEC支援実績/書籍3冊)
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。