Shopifyの構造化データ実装ガイド｜AI検索に理解されるECサイトの作り方【2026】

構造化データとは、schema.orgの語彙を使って「このページが何を意味しているか」を検索エンジンやAIに機械可読な形で伝える追加情報である。ECサイトでは、商品名・価格・在庫・評価・パンくずといった情報をこの形式で明示することで、Googleのリッチリザルトに表示されやすくなるだけでなく、ChatGPT検索やPerplexity、Google AI Overviewsのような生成AI検索エンジンにも商品情報を正確に読み取ってもらいやすくなる。

Shopifyのテーマはあらかじめ商品ページの基本的な構造化データを出力していますが、それだけではパンくず・よくある質問・会社情報・レビューの平均評価といった、AI検索での引用や検索結果の見た目強化に効くタイプまではカバーされていません。この記事では、ECサイトで重要になるschema.orgタイプの整理から、Shopifyでの具体的な実装方法、検証ツールの使い方、よくある実装ミス、そしてAI検索エンジンが構造化データを実際どう扱っているのかまでを、公式ドキュメントと確認できた一次情報にもとづいて解説します。

なお、Shopify自身もChatGPT向けの商品発見チャネル「Agentic Storefronts」や、AIショッピングチャネルに商品情報を連携する基盤「Shopify Catalog」への対応を進めています。検索エンジン向けのSEOだけでなく、AIに商品を正しく理解してもらうための情報設計は、今後のShopify運用で無視できないテーマになりつつあります。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

構造化データとは何か——検索結果とAI検索での役割

構造化データは、Schema.orgという共通の語彙(ボキャブラリー)を使って、Webページの内容に「これは商品である」「価格は◯円である」「評価は◯点である」といった意味づけを追加する仕組みです。実装形式にはJSON-LD、Microdata、RDFaの3種類がありますが、Google Search Centralの公式ドキュメントではJSON-LD形式が推奨されています。HTMLの表示用マークアップと分離して記述できるため、デザインを変更してもデータ部分だけを独立して追加・修正・削除しやすいことが理由です。

構造化データを実装すると、Google検索結果で商品の価格や星評価、パンくずリストが表示される「リッチリザルト」の対象になり得ます。ただし、構造化データを入れたからといって検索順位が上がるわけではない点には注意が必要です。GoogleのJohn Mueller氏は2025年4月、Blueskyで「構造化データはサイトの順位を良くするものではない」と明言し、その役割は検索ギャラリーに掲載されている各種の検索機能を表示するために使われるだけだと説明しています(Search Engine Roundtable、2025年4月21日報道)。つまり構造化データは「検索結果での見え方を良くする」ためのものであり、「掲載順位を上げる」ための施策ではない、という整理が公式見解です。

一方で、生成AIによる検索(ChatGPT検索、Perplexity、Google AI Overviewsなど)では、構造化データの扱われ方がGoogleの伝統的なリッチリザルトとは異なります。この違いについては、記事後半の「AI検索は構造化データをどう扱うのか」で詳しく解説します。まずは、EC事業者が押さえておくべきschema.orgのタイプを整理します。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

ECサイトで重要なschema.orgタイプ一覧

schema.orgには数百のタイプが定義されていますが、ECサイトで優先的に検討すべきタイプは限られています。ここでは、Google Search Centralの公式ガイドラインで言及されている主要なタイプを、EC運用の観点から解説します。

Product / Offer——商品情報の基本

Productは商品そのものを表すタイプで、Offerは「その商品に対する1件の販売条件(価格・在庫・通貨など)」を表すタイプです。Googleの公式ガイドラインによると、Product snippet(検索結果に価格や評価を表示する機能)が適用されるためには、少なくともname(商品名)に加えて、review・aggregateRating・offersのいずれか1つ以上を含める必要があります。

offersを使う場合、価格を表すpriceと、通貨コードを表すpriceCurrencyが事実上必須です。priceCurrencyは「JPY」「USD」のようなISO 4217形式の3文字コードで指定する必要があり、Googleの無料商品リスティング(Merchant Listings)機能を狙う場合はpriceCurrencyが必須項目として扱われます。このほか、availability(在庫状況。https://schema.org/InStockのようなschema.orgの値を使う)、priceValidUntil(価格の有効期限。ISO 8601形式)、brand、gtinやmpnといった商品識別子も推奨プロパティとして案内されています。なお、価格が変動した際にGoogle検索結果へ反映される「価格の下落」表示機能の対象はOfferのみで、価格帯を示すAggregateOfferは対象外とされている点も実務上のポイントです。

Googleの無料商品リスティング(Merchant Listings)を本格的に狙う場合は、配送条件を表すshippingDetails(OfferShippingDetails型をOfferにネストする)と、返品ポリシーを表すhasMerchantReturnPolicy(MerchantReturnPolicy型をOrganizationまたは個別のOfferにネストする)も合わせて用意する必要があります。Google Search Centralの公式ドキュメントでは、MerchantReturnPolicyに返品を受け付ける国を示すreturnPolicyCountry(ISO 3166-1 alpha-2の国コード)を含めることが案内されており、返品可能日数を示すmerchantReturnDaysや、返送料の有無を示すreturnFeesも推奨プロパティとして案内されています。米国・カナダ・オーストラリア・欧州の主要国など、対象国によってはこれらの情報が実質的に必須として扱われ、欠けているとGoogle Search Consoleの「商品」レポートに警告が出ます。

AggregateRating / Review——評価・レビュー

AggregateRatingは商品やサービスに対する複数レビューの平均評価をまとめて表すタイプで、ratingValue(平均評価値)とreviewCountまたはratingCount(件数)が中心的なプロパティになります。Reviewは個別の1件のレビューを表し、reviewRating、author、本文にあたるreviewBodyなどを含みます。前述のとおり、Product snippetはreviewかaggregateRatingのどちらかがあれば要件を満たせるため、レビュー機能を持つShopifyアプリ(レビュー収集アプリなど)を導入している場合は、そのアプリが構造化データを自動出力するかどうかを確認しておくとよいでしょう。

BreadcrumbList——パンくずリスト

BreadcrumbListは、トップページから現在のページまでの階層(パンくず)を表すタイプです。itemListElementという配列の中に、各階層を表すListItemを並べ、それぞれに順序を示すposition(1から始まる整数)、表示名のname、リンク先URLのitemを指定します。Google公式ガイドラインでは、最後の階層(現在のページ自身)にはitemを指定する必要はなく、省略した場合はGoogleがそのページ自身のURLを使う、とされています。また、ドメインやホスト名などの最上位パスを含める必要はないとも案内されています。

FAQPage——よくある質問

FAQPageは、質問と回答のペアを構造化して示すタイプです。ただし2026年8月時点では、Googleの検索結果におけるFAQリッチリザルトの扱いが大きく変わっている点に注意が必要です。Googleは2023年8月、FAQリッチリザルトの表示対象を「よく知られた、権威のある政府機関・医療機関のサイト」に限定すると発表し、一般の商用サイトはこの時点で対象外になりました。さらにGoogleの構造化データドキュメントの更新によれば、FAQリッチリザルト機能自体が2026年5月7日以降、検索結果に表示されなくなり、該当ドキュメントは2026年6月15日に削除されています。つまり、ECサイトがFAQPageを実装しても、Google検索結果上での見た目の変化(星の代わりに質問がドロップダウン表示されるような機能)はもう期待できません。ページ内にFAQコンテンツ自体を用意すること自体には、ユーザーの疑問解消やAI検索での引用という価値が残るため、この記事のFAQセクションのようにH3見出し形式で用意することは引き続き有効ですが、「FAQPageのJSON-LDを入れればGoogle検索結果に大きく表示される」という説明は、2026年時点ではすでに古い情報である点を押さえておいてください。

Organization / WebSite——会社情報とサイト全体の情報

Organizationは運営会社そのものを表すタイプで、name、url、logo、公式SNSアカウントなどを列挙するsameAs、問い合わせ先を表すcontactPointなどを含みます。会社概要ページや全ページ共通のフッターなどに一度だけ実装しておけば、検索エンジンやAIに対して「このサイトを運営している主体は誰か」を明示できます。WebSiteはサイト全体を表すタイプで、サイト内検索をGoogleのサイトリンク検索ボックスに対応させるpotentialAction(SearchAction)を含めることができます。これらはページ単位ではなくサイト全体に関わる情報のため、実装漏れが起きやすい領域でもあります。

Article——ブログ・コラム記事

Articleは、ニュースやブログ記事、コラムなどのコンテンツを表すタイプです。ECサイトそのものではなく、比較記事やノウハウ記事、Shopi Labのようなオウンドメディアのコラムに使われます。主なプロパティには、見出しを表すheadline、著者を表すauthor、公開日を表すdatePublished、更新日を表すdateModified、記事のアイキャッチ画像を表すimageなどがあります。ShopifyのブログもLiquidのstructured_dataフィルターでarticleオブジェクトをArticle型に変換できるため、商品ページだけでなくブログ記事側の構造化データも見落とさずに整えておくと、記事コンテンツ全体の情報設計として一貫性が保てます。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

Shopifyのテーマが標準で出している構造化データと、その限界

Shopifyには、オブジェクトをschema.org形式のJSON-LDに変換するstructured_dataというLiquidフィルターが公式に用意されています(Shopify Developer Documentation「Liquid filters: structured_data」)。このフィルターはproductオブジェクトとarticleオブジェクトに対応しており、商品にバリエーション(色・サイズなど)がない場合はProduct型、1つ以上のバリエーションがある場合はProductGroup型として出力されます。記事(ブログ)オブジェクトはArticle型として出力されます。使い方は次のように、商品テンプレート内で対象オブジェクトをフィルターに渡すだけです。

<script type="application/ld+json">{{ product | structured_data }}</script>

Dawnをはじめとする標準テーマでは、この記述がmain-product.liquidなどのテンプレートにあらかじめ組み込まれており、商品名・価格・在庫状況・URLといった基本的な情報は、追加の作業なしにJSON-LDとして出力されています。

ただし、この標準出力だけでは足りない部分もあります。商品説明文、複数画像、GTIN、ブランド、SKU、レビュー(AggregateRating)、配送料や返品ポリシーといった情報は、標準のstructured_dataフィルターだけでは自動的にカバーされず、テーマコードを編集するか、専用アプリを追加するかたちで補う必要があります。また、BreadcrumbList・FAQPage・Organizationといった、商品ページ以外の情報を扱うタイプも標準では出力されません。パンくずリストの表示自体はテーマにある場合が多い一方、それに対応する構造化データまでは自動生成されないケースが一般的です。「Shopifyを使っているから構造化データは自動で万全」という前提は誤りで、EC事業者側で優先度をつけて補完していく必要がある、という理解が実務上は重要です。

自社のストアに現在どこまでの構造化データが出力されているかは、実装作業に入る前に必ず確認しておきましょう。商品ページをブラウザで開き、「ページのソースを表示」または開発者ツールからapplication/ld+jsonで検索すれば、現状出力されているJSON-LDの内容を直接確認できます。テーマをカスタマイズ済みのストアでは、テーマ制作会社や過去の担当者が独自にJSON-LDを追加している場合もあるため、これから新しく追加しようとしているタイプが、実はすでにどこかに実装されていないかを確認してから着手すると、後述する「重複・矛盾」の実装ミスを防ぎやすくなります。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

JSON-LDの実装方法と実務上の注意点

必ずscriptタグで囲む——生JSONを裸で置くと壊れる

JSON-LDを実装するときの大原則は、JSONデータを必ず<script type="application/ld+json">タグで囲んで記述することです。schema.orgやGoogleの公式ガイドラインでも、JSON-LDはscript要素の中に置く形式として案内されています。

この「scriptタグで囲む」というルールは、単なる仕様上の作法ではなく、実務上の事故を防ぐためのものでもあります。多くのCMSには、本文中の引用符やハイフンを自動的に見た目の良い記号(スマートクオートや全角ダッシュなど)に変換するテキスト整形処理が組み込まれています。たとえばWordPressにはwptexturizeという関数があり、投稿本文中の直線的な引用符(")を装飾的な引用符に自動変換します。この処理は<script>・<style>・<pre>・<code>・<kbd>・<tt>タグの中身をスキップするよう設計されていますが、これは裏を返せば「JSONデータがscriptタグで囲まれていなければ、この保護の対象外になる」ということでもあります。JSON-LDをタグで囲まずに裸のテキストとして本文に貼り付けてしまうと、引用符が自動変換されてJSONとして構文エラーになり、そのページの構造化データが丸ごと機能しなくなる、という実務上のトラブルが起こり得ます。

Shopifyのテーマ(Liquid)に直接JSON-LDを書き込む場合は、コンテンツ管理システムのテキスト整形処理の影響を受けにくい環境ですが、Shopifyのブログ機能やページ本文にリッチテキストエディタ経由でJSON-LDを貼り付けるようなケースでは、同種の自動整形によって構文が壊れるリスクがあります。実装後は必ず後述の検証ツールでJSONとして正しくパースできているかを確認する習慣をつけてください。

ShopifyのLiquidでJSON-LDを出力する方法

商品ページであれば、前述のstructured_dataフィルターを使うのが最も手軽な方法です。標準出力でカバーされない項目(レビュー評価、パンくず、FAQ、会社情報など)は、Liquidのassignやオブジェクトのプロパティを組み合わせて、手動でJSONを組み立てる必要があります。たとえばパンくずリストであれば、テーマが持つコレクション階層やページ階層の情報をもとに、itemListElementの配列をLiquidのループ処理で生成し、<script type="application/ld+json">タグの中に出力する、という実装になります。

複数のJSON-LDブロックを1ページに置くこと自体は仕様上問題ありませんが、同じ種類のデータ(たとえばOrganization)を複数のアプリやテーマコードが重複して出力してしまうケースには注意が必要です。テーマを更新したり、構造化データ関連のアプリを追加・削除したりしたタイミングで、ページのソースコードを確認し、重複や矛盾がないかをチェックする運用をおすすめします。

参考として、BreadcrumbListのJSON-LDは、プロパティの構成だけを取り出すと次のような形になります。itemListElementの配列に、階層ごとのposition・name・itemを並べる構造です。

{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"トップ","item":"https://example.com/"},{"@type":"ListItem","position":2,"name":"レディース","item":"https://example.com/collections/ladies"},{"@type":"ListItem","position":3,"name":"商品名"}]}

最後の階層である「商品名」にはitemを含めていない点が、前述したGoogle公式ガイドラインの案内(最終階層のURLは省略可能で、省略時はページ自身のURLが使われる)に対応しています。Shopifyのコレクション階層やパンくずスニペットが持つデータを、この構造に合わせてLiquidでループ処理すれば、既存の表示用パンくずと矛盾しないJSON-LDを生成できます。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

Shopifyで構造化データを追加する具体的な手順

テーマコードを直接編集する方法

Shopify管理画面の「オンラインストア」→「テーマ」→「コードを編集」から、対象テーマのLiquidファイルを直接編集できます。商品ページの構造化データを拡張したい場合はsections/main-product.liquidやそれに準ずるファイル、パンくずリストであればヘッダーやパンくず専用のsnippetファイルを確認し、必要なJSON-LDブロックを追加します。編集前には必ずテーマを複製してバックアップを取り、公開中のテーマを直接壊さないようにしてください。コード変更を伴うため、Liquidの構文やschema.orgのプロパティ名に誤りがないか、後述の検証ツールで必ず確認する工程を挟むことが重要です。

アプリを使う方法

Shopify AppStoreには、構造化データやSEOメタデータの管理を目的としたアプリが複数公開されています。コードを直接編集する自信がない場合や、複数の担当者がテーマを触る体制の場合は、こうしたアプリを使ってOrganization・BreadcrumbList・レビューのAggregateRatingなどを管理する方法も選択肢になります。アプリを導入する際は、テーマのstructured_dataフィルターによる出力と重複しないか、アプリの管理画面やテーマのソースコードを確認し、同一タイプのJSON-LDが二重に出力されていないかをチェックしてください。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

多通貨・多言語Shopifyストアでの構造化データの注意点

ShopifyのMarkets機能を使って複数の国・通貨・言語でストアを展開している場合、構造化データにも market ごとの整合性が求められます。もっとも起こりやすいのは、priceCurrencyが特定の市場向けに固定されたまま、他の市場向けページでも同じ値が出力されてしまうケースです。たとえば日本向けとアメリカ向けで表示価格・表示通貨が切り替わっているにもかかわらず、構造化データ側のpriceCurrencyが常に「JPY」のままになっていると、アメリカ向けページでは表示価格と構造化データの通貨が矛盾し、Merchant Listingsの審査で不整合として扱われる可能性があります。

また、多言語対応をしている場合は、ページの言語を示すinLanguageプロパティを付与しておくと、どの言語で書かれた情報かをGoogleやAIに明示できます。翻訳アプリで生成した各言語のページごとに、商品名や説明文が正しく翻訳された状態でJSON-LDにも反映されているか(旧言語のテキストが構造化データ側にだけ残っていないか)も、多言語ストアで見落とされやすいポイントです。市場や言語を追加・変更するたびに、対象ページの構造化データを個別に確認する運用を組み込んでおくことをおすすめします。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

Googleリッチリザルトテスト・Schema Markup Validatorでの検証方法

構造化データを実装したら、公開前後で必ず検証します。代表的なツールはGoogleリッチリザルトテスト(search.google.com/test/rich-results)と、schema.org公式のSchema Markup Validator(validator.schema.org)の2つで、それぞれ役割が異なります。

Googleリッチリザルトテストは、対象のURLまたはコードスニペットを入力すると、そのページがGoogleのリッチリザルト機能の対象になり得るかどうかを判定します。必須プロパティが欠けている場合は「エラー」、あった方が望ましい推奨プロパティが欠けている場合は「警告」として表示されます。スマートフォン向け・パソコン向けのクローラーを切り替えて確認できる点も実務上便利です。一方のSchema Markup Validatorは、Googleの検索機能への適合可否ではなく、記述したJSON-LDがJSON-LD 1.0・Microdata・RDFaとしてschema.orgの語彙に構造的に正しく準拠しているかどうかを検証します。Googleリッチリザルトテストより判定基準が緩やかなため、Schema Markup Validatorで合格しても、Googleリッチリザルトテストでは要件不足としてエラーになることがある点には注意してください。これは、Google側がリッチリザルト表示のために独自の必須項目を追加で設けているためです。

実務上のおすすめの順序は、(1)Schema Markup Validatorでschema.orgとしての構造的な正しさを確認する、(2)Googleリッチリザルトテストでリッチリザルトの対象になり得るかを確認する、(3)公開後はGoogle Search Consoleの各種構造化データレポート(商品、パンくずリストなど)で継続的にエラーが出ていないかを監視する、という3段階です。特に(3)は、テーマ更新やアプリの追加・削除によって構造化データが意図せず壊れることがあるため、公開して終わりにせず定期的に確認する運用が欠かせません。

また、両ツールともコードスニペットを直接貼り付けて検証する機能があるため、本番環境に公開する前の段階、たとえばテーマの複製(開発用テーマ)で構造化データを実装した時点でも検証できます。公開してからエラーに気づくのではなく、公開前の時点で必須プロパティの欠落や構文エラーを洗い出しておくことで、手戻りを減らせます。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

よくある実装ミス

必須プロパティの欠落

Googleの公式ガイドラインでは、必須プロパティが1つでも欠けていると、そのリッチリザルト全体が対象外になる(部分的にではなく丸ごと表示されなくなる)と案内されています。Product snippetであればnameに加えてreview・aggregateRating・offersのいずれか、Merchant ListingsであればさらにpriceCurrencyが必須になるなど、狙う検索機能によって必須項目が異なります。「とりあえずProductタイプだけ入れておけば良い」という認識のまま実装すると、狙っている表示機能の要件を満たせていないケースが少なくありません。

価格の通貨コード忘れ・形式ミス

priceCurrencyを書き忘れる、または「¥」「円」のような記号・単位で代用してしまうミスもよく見られます。priceCurrencyにはISO 4217形式の3文字コード(日本円であれば「JPY」)を指定する必要があり、記号や単位語は無効な値として扱われます。またpriceの小数点は、日本語の慣習であるカンマ区切りではなく、ピリオドで指定する必要がある点も見落とされがちです。多通貨展開しているShopifyストアでは、市場(マーケット)ごとに表示通貨が変わるため、構造化データ側のpriceCurrencyが実際にページで表示されている通貨と一致しているかを、市場ごとに確認する必要があります。

パンくずの不整合

BreadcrumbListのJSON-LDと、画面に実際表示されているパンくずリストの内容が食い違っているケースです。Google公式ガイドラインは、URLの階層構造をそのまま反映するのではなく、実際にユーザーがたどる閲覧経路にもとづいてパンくずを構成することを推奨しています。コレクションのカテゴリ構成をリニューアルした際に、表示側のパンくずは更新したが構造化データ側のテンプレートは古いままになっている、といった更新漏れは典型的な失敗パターンです。ガイドラインに反する状態が続くと、サイトに対する手動対策(マニュアルアクション)の対象になり得るともGoogleは案内しています。

複数のJSON-LDが重複・矛盾する

テーマ標準のstructured_dataフィルターによる出力と、後から追加したアプリやカスタムコードによる出力が同じページに重複して存在し、価格や在庫状況の値が食い違ってしまうケースです。同一タイプのJSON-LDが複数存在すること自体は仕様違反ではありませんが、内容が矛盾していると検証ツールでエラーや警告の原因になります。アプリを追加・変更するたびに、ページのソースを確認して重複がないかをチェックする運用をルール化しておくと防ぎやすくなります。

JavaScriptで後から挿入している

Googleの公式ガイドラインでは、Merchant Listingsを狙う構造化データは、Webサーバーから返されるHTMLの中に存在している必要があり、ページ読み込み後にJavaScriptで生成されたものは対象にならないと明記されています。サードパーティアプリの中には、ページ読み込み後にJavaScriptでJSON-LDを挿入する実装のものもあるため、導入するアプリがサーバーサイド(または初期HTML)でJSON-LDを出力しているのか、クライアントサイドのJavaScriptで後から挿入しているのかを確認しておくことをおすすめします。判別が難しい場合は、ブラウザの「ページのソースを表示」機能で、JavaScript実行前の初期HTMLにJSON-LDが含まれているかを確認するとよいでしょう。

画像URLの要件を満たしていない

imageプロパティに、実際には存在しないURLや、Shopifyの画像CDNのサイズ違いパラメータが古いまま切れたURLを指定してしまうミスもあります。Googleの公式ガイドラインでは、画像は高解像度であることに加え、クロールとインデックスが許可されたURLである必要があると案内されています。商品画像を差し替えた際にテーマ側の表示は更新されても、構造化データのテンプレートが古い画像フィールドを参照したままになっていないか、画像を大幅に入れ替えたタイミングでは特に確認が必要です。

キャッシュ・CDNによって更新が反映されない

テーマコードを修正して構造化データを更新しても、ページキャッシュやCDNの設定によって、Googleのクローラーや検証ツールに古いバージョンのJSON-LDが返され続けることがあります。特に在庫状況や価格のように更新頻度が高い項目でこの問題が起きると、実際の在庫・価格と検索結果に表示される情報がずれてしまいます。構造化データを修正した際は、ブラウザのシークレットモードや検証ツールのURL入力機能を使って、キャッシュを経由しない状態で最新の内容が反映されているかを確認する習慣をつけてください。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

AI検索(ChatGPT検索・Perplexity・Google AI Overviews)は構造化データをどう扱うのか

ここまで解説してきたGoogleのリッチリザルト向けルールは、あくまで「Googleの検索結果でどう表示されるか」というルールです。ChatGPT検索やPerplexity、Google AI Overviewsのような生成AIによる検索は、構造化データの扱い方がこれとは異なる、という点を理解しておく必要があります。

2026年初め、SEOコンサルタントのMark Williams-Cook氏(発案の原点はRichard Barrett氏によるとされています)が、この違いを示す実験を公開して話題になりました。実在しない架空のアパレルブランドのページを用意し、目に見える本文には会社の住所を一切記載せず、<script type="application/ld+json">内の、schema.orgとして無効な(構文として正しくない)JSON-LDの中にだけ、架空の住所を仕込みました。この状態でChatGPTとPerplexityにその会社の住所を尋ねたところ、両方とも、無効なJSON-LDの中にしか存在しないその架空の住所をそのまま回答した、という結果が報告されています。この実験結果は、ChatGPTやPerplexityがscriptタグの中身をschema.orgの仕様に照らして厳密に検証しているわけではなく、ページ上の他のテキストと同様に「読み取れる情報」として扱っている可能性を示すものです。この件についてGoogleのJohn Mueller氏は、構造化データがLLMの助けになるかどうかは「場合による(it depends)」とコメントしています(Search Engine Roundtable、2026年2月3日報道)。

この結果からEC事業者が読み取るべき実務上の教訓は、「構造化データさえ入れればAI検索に正しく理解されるとは限らない」ということです。Googleのリッチリザルトのように、仕様を満たしていなければ機能が丸ごと不採用になる、という明確な合否判定がAI検索側にはまだ確立されていません。むしろ、構造化データの中身と、ページ本文で人が読む情報とが一致していること——つまりJSON-LDに書いた商品名・価格・在庫と、実際にページに表示されている内容が食い違っていないことが、SEOとAI検索の両方に共通して重要になります。構造化データは「検索エンジンやAIに情報を伝えるための手段の一つ」であって、ページ本文やレビュー、FAQといった人間向けコンテンツの整備を代替するものではない、という位置づけで運用するのが実務上は安全です。

Google AI Overviewsについては、Googleがユーザーの検索クエリに対して関連性の高いWebページ、構造化データ、ナレッジグラフの情報をGeminiモデルに渡し、要約を生成したうえで引用元を明示する(グラウンディングする)という仕組みが、Google自身の発表で説明されています。この仕組み上、Article・Product・FAQPageのようなschema.orgタイプは、AI側がページの文脈を把握する材料の一つになり得ますが、Googleの伝統的な検索と同様、構造化データを入れること自体が引用されることを保証するものではありません。ページ本文の情報が正確で、ユーザーの疑問に具体的に答えられている状態を土台としたうえで、構造化データはその理解を助ける補助的な手段として位置づけるのが実態に即した考え方です。

ECサイトの運用担当者が実務で気をつけるべき点をまとめると、次の3つに集約されます。第一に、構造化データに書く値と、ページに表示されている値を必ず一致させること。これはGoogleのMerchant Listingsのガイドラインでも明確に禁止されている「表示内容と構造化データの不一致」を避けるためであると同時に、AI検索が本文とJSON-LDの両方を「読み取れる情報」として扱っている以上、両者が食い違えばどちらか一方、あるいは両方が誤った形で引用されるリスクにつながるためです。第二に、構造化データだけでSEO・AIO対策を完結させようとしないこと。商品説明文やFAQ、レビューといった人間向けのコンテンツ自体の質を高めることが、Google検索・AI検索のいずれにとっても土台になります。第三に、実装後は放置せず、定期的に検証ツールとSearch Consoleで状態を確認することです。前述のGoogleリッチリザルトテストとSchema Markup Validatorによる確認は、AI検索向けの構造化データを整える場合にも同様に有効です。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

構造化データの実装優先順位——何から着手すべきか

ここまで紹介してきたタイプをすべて一度に整えるのは現実的ではないため、優先順位をつけて着手することをおすすめします。まず着手すべきはProduct / Offerです。テーマ標準のstructured_dataフィルターで基本部分はすでにカバーされているため、不足しているpriceCurrency・availability・gtinやbrandを補完するだけで、Product snippetの要件に近づけやすいためです。次に優先度が高いのはBreadcrumbListで、実装難易度が比較的低く、パンくずの表示自体がすでにあるテーマであれば、そのデータをJSON-LD化するだけで済みます。

その次に、レビュー機能を導入している場合はAggregateRating、全ページ共通の情報としてOrganizationを整備します。FAQPageについては、前述の通りGoogleの検索結果での見た目上のメリットはすでになくなっているため、優先度としては最も低く位置づけて構いません。それよりも、FAQコンテンツ自体を商品ページやサポートページに人が読んで分かりやすい形で用意しておくことのほうが、AI検索での引用や、購入前の疑問解消という点で実利があります。売れ筋商品や広告経由のアクセスが多い商品ページから優先的に整備し、テンプレート化できた実装を他の商品ページへ横展開していく進め方が、限られたリソースの中では現実的です。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

Shopifyの構造化データ運用チェックリスト

最後に、Shopifyストアで構造化データを運用していくうえで、定期的に確認しておきたいポイントを整理します。

• 商品ページのstructured_dataフィルター(またはテーマ標準の出力)が、name・offers(price・priceCurrency)・availabilityを正しく出力しているか
• レビュー機能を使っている場合、AggregateRatingが商品ページのJSON-LDに反映されているか
• BreadcrumbListの内容が、画面に表示されているパンくずリストおよび実際のカテゴリ構成と一致しているか
• Organization(会社情報)・WebSiteが全ページ共通で実装されており、内容が最新か
• 複数の海外市場を展開している場合、市場ごとにpriceCurrencyの値が実際の表示通貨と一致しているか
• JSON-LDが必ず<script type="application/ld+json">タグの中に収まっており、途中で構文が壊れていないか
• テーマ更新・アプリの追加や削除のたびに、Schema Markup ValidatorとGoogleリッチリザルトテストで再検証しているか
• Google Search Consoleの構造化データ関連レポートで、継続的にエラーが発生していないか

構造化データの実装は、一度作って終わりの施策ではありません。テーマのアップデート、アプリの入れ替え、商品カテゴリの再編、海外市場の追加といった運用上の変化のたびに、構造化データが実態とずれていないかを確認する体制を作っておくことが、Google検索とAI検索の両方に対してECサイトの情報を正しく届け続けるための土台になります。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

よくある質問

Shopifyで構造化データを実装すれば、必ずGoogleでリッチリザルトが表示されますか?

いいえ、保証されるものではありません。構造化データは、Googleのリッチリザルト機能の対象になり得る「資格」を得るためのものであり、必須プロパティを満たしていても、実際に表示されるかどうかはGoogle側の判断に委ねられます。Googleの公式見解でも、構造化データは検索順位を上げるものではなく、検索結果での見え方に関わるものだと説明されています。

FAQPageの構造化データを入れる意味はもうないのですか?

Googleの検索結果上での表示効果は、2026年時点ではほぼなくなっています。Googleは2023年8月にFAQリッチリザルトの対象を政府機関・医療機関サイトに限定し、その後2026年5月にはFAQリッチリザルト機能自体が検索結果に表示されなくなりました。ただし、FAQコンテンツをページに用意すること自体は、ユーザーの疑問解消やAI検索での引用という点で引き続き価値があります。

Product構造化データに必須なプロパティは何ですか?

Googleの公式ガイドラインでは、Product snippetの対象になるには商品名(name)に加えて、review・aggregateRating・offersのいずれか1つ以上が必要とされています。offersを使う場合はpriceとpriceCurrencyが事実上必須で、priceCurrencyはISO 4217形式の3文字コードで指定する必要があります。より広い無料商品リスティング(Merchant Listings)を狙う場合は、priceCurrencyが必須項目としてさらに厳密に扱われます。

Shopifyのテーマにはじめから入っている構造化データだけで十分ですか?

不十分なケースが多いです。ShopifyのLiquidにはstructured_dataフィルターが標準で用意されており、商品ページの基本的な情報(商品名・価格・在庫状況・URLなど)は自動で出力されますが、GTIN・ブランド・レビュー評価・配送条件・返品ポリシー、さらにBreadcrumbListやOrganizationといったタイプは標準では出力されません。テーマコードの編集やアプリの活用で補完する必要があります。

JSON-LDをブログ記事やページに直接貼り付けても大丈夫ですか?

必ず<script type="application/ld+json">タグで囲んだうえで貼り付けてください。JSONを裸のテキストとしてリッチテキストエディタなどに貼り付けると、CMS側の自動テキスト整形機能(WordPressのwptexturizeなど)によって引用符が変換され、JSONとして構文エラーになることがあります。貼り付け後は必ずGoogleリッチリザルトテストやSchema Markup Validatorで、正しくJSONとして読み込めているかを確認してください。

構造化データを入れるとGoogleでの検索順位は上がりますか?

直接的な順位向上効果はないというのがGoogleの公式見解です。GoogleのJohn Mueller氏は2025年4月、構造化データはサイトの順位を良くするものではなく、検索ギャラリーに掲載されている検索機能の表示に使われるだけだとBluesky上で説明しています。ただし、リッチリザルトによって検索結果での見え方が変わることで、クリック率が変化する可能性はあります。

ChatGPT検索やPerplexityは構造化データをどう扱いますか?

Googleのリッチリザルトのように、仕様への準拠を厳密に検証しているわけではないとみられています。2026年初めに公開された実験では、schema.orgとして無効なJSON-LDに書かれた架空の情報を、ChatGPTとPerplexityがそのまま回答した事例が報告されました。これは、これらのAIがscriptタグの中身をページ本文と同様の「テキスト情報」として読み取っている可能性を示しており、構造化データの仕様準拠よりも、本文とJSON-LDの内容が正確で一致していることのほうが実務上重要になります。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

編集ポリシー

• 本記事は各社の公式発表・公式ドキュメント・一次情報を優先して執筆し、本文中に出典と日付を明記しています。
• 効果や改善幅に関する記述は、公的な統計が存在しない領域では断定せず、確認できた一次情報と、読者が自分で確かめるための手順に置き換えています。
• 執筆は片岡、内容の正確性はShopify Plus Partnerの黒岩が確認しています(執筆・監修者は記事上部・下部に記載)。
• 公開後に誤り・古い情報が判明した場合は、本文を修正のうえ更新日を改めます。修正のご指摘は運営元(株式会社セルフプラス)までお寄せください。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

執筆者について

本記事は、Shopify公認の上位認定「Shopify Strategic Partner」に選出された株式会社セルフプラスが運営しています。

Shopifyやその他ECの制作・運用・保守について、お気軽にご相談ください。
連絡は問い合わせ・無料相談・無料お見積りよりどうぞ。

Shopifyの構造化データ実装は、Shopi Labにご相談ください

Product・BreadcrumbList・Organizationなど、schema.orgタイプごとの設計から、Googleリッチリザルトテストでの検証、AI検索を見据えた情報設計まで、ECサイトの構造化データ整備には専門的な確認作業が伴います。「何から手をつければよいか分からない」「今の実装が正しいか不安」という場合は、Shopify公認パートナーであるShopi Labまでお気軽にご相談ください。

» 無料相談はこちら