AIに商品を探してもらう買い物が、少しずつ現実になってきました。ここで問われるのは、自社の商品情報をAIが正しく読めるかどうかです。
人が見れば分かる商品ページでも、AIには伝わらないことがあります。画像の中に書かれたサイズ表記、説明文に埋もれた素材名、更新されていない在庫表示。こうした情報は、機械には読み取れません。
この記事でわかることは、次の3点です。
- 従来のSEOとAI向け最適化で、何が変わるのか
- EC商品ページで実装すべき構造化データの具体的なプロパティ
- 実装後の検証手順と、価格や在庫を正しく保つ運用のポイント
仕様はすべてGoogle検索セントラルの公式ドキュメントで確認しています。
目次
この記事を読んでいる方におすすめ
AIエージェント時代におけるECサイトの新たな課題と「選ばれる商品ページ」の定義
検索エンジン最適化（SEO）からAI代理購買（GEO/AEO）へのパラダイムシフト
これまでの集客は、人が検索窓にキーワードを入れ、一覧から選ぶ前提で設計されてきました。順位が上がれば流入が増えるという構造です。
AIエージェントが介在すると、この前提が変わります。ユーザーが「予算1万円以内で、今週末までに届く撥水スニーカー」と条件を伝えれば、AIが複数の店舗を横断して候補を絞り込みます。つまり、最初にページを読むのが人ではなくAIになります。
この変化に対応する考え方が【GEO（Generative Engine Optimization）】です。検索結果で上位を取ることではなく、AIが情報を引用・参照する対象になることを目指します。
重要なのは、SEOを捨てる話ではない点です。クロールされ、インデックスされることは前提のまま変わりません。その上に、AIが正確に解釈できるデータ構造を重ねる作業になります。AI活用の全体像は【ECサイトのAI活用術】もあわせてご覧ください。
AIエージェントが商品情報を正確に識別するための「機械可読性」とは
人向けのページとAI向けのデータには、大きなギャップがあります。
たとえばサイズ表を画像で掲載しているケース。人は見れば分かりますが、機械はテキストとして読み取れません。「Mサイズは着丈68cm」という情報が、データとして存在しないことになります。
同様に、説明文の中に「肌触りのよい上質な天然素材を使用」と書かれていても、素材が綿なのか麻なのかは判別できません。AIは推測で補うか、あるいは情報なしとして扱います。
前者の推測が起きると、事実と異なる回答が生成されます。いわゆるハルシネーションです。AIの性能の問題というより、読み取れる情報を提供していない側の問題という側面があります。
【機械可読性とは、情報が項目として独立して存在している状態を指します】画像でもなく、文章に埋もれてもいない形です。これを実現する手段が、次章で扱う構造化データになります。
なぜ構造化データがAIエージェント対応のカギを握るのか？
ナレッジグラフと連携し、AIの認識精度を高めるメカニズム
構造化データとは、ページの内容を機械が理解できる形式で記述したものです。Googleは、ページ情報を提供しコンテンツを分類するための標準化されたデータ形式と説明しています。
仕組みは単純です。「この文字列は商品名」「この数値は価格」「この値は在庫状況」と、意味をラベル付けして併記します。機械は推測ではなく、ラベルを読んで判断できます。
こうして集められた情報は、モノ同士の関係を整理したデータベースに蓄積されます。 【ナレッジグラフ】と呼ばれる仕組みです。たとえば「このコートはAというブランドの 商品で、素材はウール、価格は12,800円」といった関係が、事実の集合として 保持されます。AIが回答を組み立てる際、この蓄積が根拠になります。
ここで注意したいのが、量より質という原則です。Googleは、不完全なデータや不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要だと明記しています。
プロパティを埋めることが目的ではありません。書いた内容が実際のページと一致していることが前提です。ここが崩れると、かえって信頼性を損ないます。
【機械可読性とは、情報が項目として独立して存在している状態を指します】画像でもなく、文章に埋もれてもいない形です。
これを実現する手段が【構造化データ】です。ページに表示される内容とは別に、「この値は価格」「この値は在庫数」という意味のラベルを付けたデータを併記する仕組みを指します。見た目は変わらず、機械だけが読む情報を裏側に持たせるイメージです。次章から詳しく見ていきます。
リッチリザルト表示を超えた「購買決定プロセス」への直結価値
構造化データのメリットとして長く語られてきたのが、【リッチリザルト】です。 検索結果に、通常のタイトルと説明文だけでなく、星評価や価格、在庫状況などが あわせて表示される形式を指します。目立つためクリック率が上がる、という 文脈で語られてきました。
AIエージェントの文脈では、役割が変わります。表示を装飾するためではなく、【条件を満たすかどうかの判定材料】になります。
「予算1万円以内」という条件に対しては価格、「今週末までに届く」には配送情報、「返品できる店で」には返品ポリシー。AIはこれらを照合して候補を絞ります。データがなければ、条件判定の対象から外れます。
つまり構造化データの有無は、表示の見栄えではなく候補に残るかどうかを左右します。
なお、Googleは商品の構造化データを個別の商品を掲載する単一ページにのみマークアップするよう定めており、複数商品を並べた一覧ページやカテゴリページには適用しないとしています。実装の際は対象ページを誤らないよう注意してください。
EC商品ページで絶対に実装すべき主要 Schema.org(構造化データ)プロパティ一覧
Googleの商品向け構造化データには、2つのタイプがあります。商品を直接購入できないページ向けの【商品スニペット】と、購入できるページ向けの【販売者リスティング】です。ECサイトは後者が該当します。
「Product」プロパティ：商品識別子（GTIN/JAN）と基本スペックの定義
Productタイプの必須プロパティは2つだけです。商品名を示すnameと、review・aggregateRating・offersのいずれか1つです。
ただし必須なだけでは足りません。AIが同一商品を特定するには、識別子が重要になります。押さえたいのは次の項目です。
- gtin：JANコードなどの国際的な商品識別番号。同一商品の名寄せに使われます
- mpn：製造元の型番
- sku：自社の管理番号
- brand：ブランド名。推奨プロパティです
- image：商品画像のURL
型番商品を扱う場合、gtinの有無が比較の土俵に乗れるかを左右します。同じ商品を複数店舗が扱っていても、識別子がなければAIは同一商品と判断できません。
サイズや色のバリエーションがある場合は、ProductGroupを併用します。variesBy、hasVariant、productGroupIDといったプロパティで親子関係を示す仕組みです。
「Offer」・「AggregateRating」プロパティ：価格・在庫状況・顧客評価のリアルタイム同期
Offerは販売条件を示すプロパティです。AIが条件判定に使う情報が集中しています。
記述する主な項目は次のとおりです。
- price と priceCurrency：販売価格と通貨
- availability：在庫状況。InStock、OutOfStockなどの定義済みの値を使います
- priceValidUntil：価格の有効期限
- url：購入ページのURL
AggregateRatingは、レビューの平均評価と件数を示します。ratingValueとreviewCountの組み合わせが基本です。
【この2つで最も重要なのは、実際のページと一致していることです】価格を変更したのに構造化データが古いまま、セールが終わったのにavailabilityが更新されていない。こうしたずれは、AIの誤判断を招きます。更新の自動化については後述します。
競合と差をつける「MerchantReturnPolicy」および「ShippingDetails」の構造化
多くの記事で省略されがちですが、差がつくのはここです。配送と返品の条件を構造化すると、AIの絞り込みに対応できます。
配送情報（shippingDetails）
OfferShippingDetailsタイプで記述します。送料を示すshippingRate、配送先地域を示すshippingDestination、そしてdeliveryTimeの中に出荷準備日数（handlingTime）と輸送日数（transitTime）を入れる構成です。
返品情報（hasMerchantReturnPolicy）
MerchantReturnPolicyタイプで記述します。返品受付期間を示すmerchantReturnDays、返品方法のreturnMethod、返品送料の負担を示すreturnFeesなどがあります。
なお、商品の大部分に共通するポリシーがある場合は、商品ごとに書くのではなくOrganizationタイプにネストして全社のポリシーとして定義する方法が推奨されています。配送はShippingService、返品はMerchantReturnPolicyを使います。
【実践】JSON-LDを用いた商品ページの構造化データ導入ステップ
Google推奨フォーマット「JSON-LD」でのコード記述とヘッダー実装
構造化データの記述形式は3種類ありますが、JSON-LDを選んでください。理由は管理のしやすさにあります。
MicrodataやRDFaは、HTMLのタグに属性を書き加える方式です。表示部分とデータが一体化するため、デザイン変更のたびに壊れるリスクがあります。JSON-LDは独立したブロックとして記述するので、表示と分離できます。
記述は <script type=”application/ld+json”> の中に入れ、head内またはbody内に配置します。基本構造は次のとおりです。
@context : https://schema.org を指定
@type : Product
name : 商品名
image : 商品画像URL
gtin : JANコード
brand : ブランド名
offers : price / priceCurrency / availability
shippingDetails / hasMerchantReturnPolicy
aggregateRating : ratingValue / reviewCount
完全な記述例と各プロパティの型は、Google公式ドキュメントに掲載されています。実装時はそちらを参照してください。手打ちするより、公式のサンプルを土台に自社の項目へ差し替えるほうが確実です。
主要ECプラットフォーム（Shopify、MakeShop、Futureshop等）での対応アプローチ
ゼロから書く必要があるケースは、実はそれほど多くありません。プラットフォームによって対応方法が分かれます。
テーマが標準対応しているケース
Shopifyの多くのテーマは、Product構造化データを標準で出力します。ただし出力されるプロパティは限定的なことが多く、gtinや配送情報が含まれていない場合があります。まず現状を確認してください。
アプリやプラグインで補完するケース
不足分は、構造化データ生成アプリで追加できます。Googleも、CMSを使っている場合は統合されたプラグインを使うほうが簡単な場合があると案内しています。
テンプレートに変数を埋め込むケース
国内カートの一部は、商品マスタの項目を構造化データとして出力する機能を持っています。商品名や価格が自動で反映される仕組みです。
いずれの場合も、自社の商品マスタに元データが入っていなければ出力されません。【実装の前に、マスタ側の項目が埋まっているかを確認してください】
実装後の検証手順とAIエージェントに選ばれるための運用ポイント
リッチリザルトテストと Search Console によるエラー・警告の解消
実装したら、必ず検証します。Googleは構造化データの導入手順を、必須プロパティの追加、ガイドラインの遵守、リッチリザルトテストでの検証という流れで示しています。
検証で表示される指摘は2種類あります。
- エラー：必須プロパティの欠落や形式の誤り。リッチリザルトの対象外になるため、必ず修正します
- 警告：推奨プロパティの欠落。対象外にはなりませんが、情報量が減ります
Googleは、重大ではない問題の修正も構造化データの品質向上に役立つとしています。ただし、埋めるために不正確な値を入れるのは本末転倒です。分からない項目は空欄のままにしてください。
公開後は、Search Consoleに商品スニペットと販売者のリスティングのレポートが表示されます。サイト全体で何件が有効か、どこにエラーがあるかを継続的に確認できます。
セール・価格変更・在庫切れに追従する動的データ更新の自動化
最も起きやすい事故が、表示価格と構造化データの不一致です。
原因の多くは、構造化データを静的に埋め込んでいることにあります。HTMLの表示価格はシステムが自動更新するのに、構造化データ側は手作業で入れたまま放置される。セールのたびにずれが生じます。
対策は、構造化データも商品マスタから動的に生成することです。テンプレート上で変数として出力すれば、価格や在庫が変わった瞬間に反映されます。
確認しておきたいのは次の3点です。
- 価格改定時に構造化データも変わるか
- 在庫切れのときにavailabilityがOutOfStockに切り替わるか
- セール終了時に元の価格へ戻るか
【月に一度、主要商品を抜き取ってリッチリザルトテストにかけてください】実装時に正しくても、運用の中でずれていきます。
構造化データと掛け合わせる！AIエージェントの評価を最大化するコンテンツ最適化
LLM（大規模言語モデル）が解釈しやすいFAQと商品説明文のテキスト設計
構造化データだけでは、伝わらない情報もあります。本文の書き方でも差がつきます。
避けたいのは、曖昧な修飾語だけで構成された説明文です。「上質な素材」「抜群の使い心地」といった表現は、情報として何も含んでいません。AIは事実として抽出できません。
書き換えの方向は、事実を明記することです。
- 素材：綿80%、ポリエステル20%
- サイズ：着丈68cm、身幅52cm（Mサイズ）
- 重量：約320g
- 使用シーン：通勤時の羽織りとして、春秋の気温15度前後
FAQの設置も有効です。問い合わせで多い質問と回答を、Q&A形式でページ内に配置します。「洗濯機で洗えますか」「サイズ選びに迷ったら」といった実際の疑問と、その明確な回答です。
この形式は、AIが該当箇所を特定しやすい構造になります。同時に、人にとっても分かりやすいページになります。
マルチモーダルAIを見据えた画像・動画メタデータ（ImageObject）の最適化
画像を扱えるAIが広がっていますが、それでもテキストの補足は必要です。
まずalt属性の記述を見直してください。「商品画像1」ではなく、「ネイビーのウールコートを着用した女性の正面写真、着丈は膝上」のように、何が写っているかを具体的に書きます。
構造化データ側では、Productのimageプロパティに画像URLを指定します。複数の角度から撮影した画像がある場合は、複数指定できます。高解像度の画像を用意しておくほうが有利とされています。
見落とされがちなのが、画像内のテキストです。サイズ表、成分表、使用方法を画像だけで掲載しているなら、同じ内容をHTMLのテキストとしても記載してください。機械可読性の観点では、画像内の文字は存在しないのと同じ扱いになります。
動画がある場合は、VideoObjectで説明文とサムネイルを記述します。
まとめ：次世代ECコマースを制する構造化データファーストのWeb戦略
検索エンジンの先にある「Agentic Commerce」への備えとロードマップ
構造化データは、目先のリッチリザルト対策にとどまりません。AIが商品を探し、比較し、購入まで代行する流れが広がるほど、データの整備状況が差になります。
実際、AIエージェントとECシステムを接続する規格の整備も進んでいます。ただし、どの規格が主流になっても、AIに読ませる元データが整っていなければ意味がありません。規格対応の前に、自社データの整備が先です。規格の動向は【MCPでECサイトの購買体験はどう変わる？】で解説しています。
着手の順序は次のとおりです。
- ステップ1：現在の商品ページに構造化データが出力されているか確認する
- ステップ2：リッチリザルトテストでエラーを洗い出す
- ステップ3：商品マスタの属性項目が埋まっているか点検する
- ステップ4：不足しているプロパティを追加する
- ステップ5：動的更新の仕組みを確認し、月次で抜き取り検証する
最初の3つは、エンジニアがいなくても実施できます。今日から始められる作業です。
まとめ
【この記事のポイント】
- AIエージェントが介在すると、最初にページを読むのは人ではなく機械になる。画像内の文字や説明文に埋もれた情報は読み取れない
- Productの必須プロパティはnameと、review・aggregateRating・offersのいずれか1つ。ただし識別子（gtin、mpn、sku）がないとAIは同一商品を特定できない
- 差がつくのは配送（shippingDetails）と返品（hasMerchantReturnPolicy）の構造化。AIの条件絞り込みに直結する
- プロパティは多く埋めるより、正確であることが優先される。表示価格と構造化データのずれが最大の事故要因
- 記述形式はJSON-LDを選ぶ。表示と分離できるため、デザイン変更で壊れにくい
構造化データは地味な作業ですが、AIに読まれる土台そのものです。派手な施策を検討する前に、足元のデータが機械に届いているかを確認してください。
自社の商品ページは、AIに読める状態になっていますか
とはいえ、何から点検すべきかのリストが手元にないと、着手しづらいはずです。構造化データだけでなく、商品マスタの整備状況や運用体制まで含めて確認する必要があります。
KUROCOでは、EC事業の成長に必要な観点を56項目にまとめたチェックリストをご用意しています。自社の現在地を、設問に答えながら確認できます。
AI経由の購買が本格化したとき、差がつくのはデータの整備状況です。まずは主要商品を1つ、リッチリザルトテストにかけてみてください。
齋藤健太 代表取締役 
慶応義塾大学理工学部卒業後、株式会社船井総合研究所に入社。主に中堅規模（数百億）以上の企業をメインクライアントとしたプロジェクトに従事。化粧品メーカや卸・リテール業界など、幅広い業種において、中期経営計画策定やマーケティング戦略の構築、M&Aにおけるビジネスデューデリジェンス等の実績を有する。独立後も製造業や小売業、サービス業に至るまで大小様々な企業の課題発見に従事、成果を上げる。特にデータ分析においては、複数のコンサルファームにもアサインされる実力を有する。コンサルティングに加え、ヘアサロン2店舗と、まつげ・眉毛専門のアイサロン1店舗の運営、ならびに伝統工芸品の販売事業にも携わり、現場視点での売上づくりにも取り組んでいる。その他、AI関連スタートアップや教育関連企業からもデータ分析支援の依頼を数多く受けている。2013年9月にクロスメディア・パブリッシングより「問題解決のためのデータ分析」を出版（2019年2月に新装版を出版）。教育プラットフォームUdemyで展開しているオンライン講座（「ビジネスの現場で使えるデータ分析」、他）の受講者数は4万人（2024年2月現在）を超える。2020年10月KUROCO株式会社を設立、現在に至る。
東亜大学芸術学部トータルビューティ学科非常勤講師。
＼ この記事を読んでいる方におすすめ！ ／
