ECサイトのLLMO対策では、記事を増やす前に、同じSKUの名称、価格、在庫、画像、バリエーション、配送、返品条件が、購入者に見える商品ページと機械向けデータで一致しているかを確認します。本記事では、商品ページ、Product JSON-LD、Google Merchant Center、OpenAI商品フィードの4面を25項目で照合し、AIの商品推薦と検索表示を保証せずに改善を判断する方法を整理します。

結論：ECのLLMOは商品説明文より先にデータの不一致を直す

商品ページには現在価格、Merchant Centerには旧価格、JSON-LDには在庫あり、実際の購入画面では在庫なし、という状態では、どの取得経路を使うかによって説明が変わります。最初にCMS、商品マスター、在庫、注文、配送、返品のどれを正本とするかを決め、各出力の更新時刻と担当者を接続します。

LLMO専用のキーワード欄を商品フィードへ足すことが目的ではありません。商品を識別でき、条件に合う候補か判断でき、購入前の重要事実を最新状態で確認できることが先です。

  • SKU・バリエーションIDを更新のたびに変えない
  • 商品名、ブランド、GTIN・MPN、URLを同じ商品へ接続する
  • 価格、通貨、セール期間、在庫を商品ページとフィードで一致させる
  • 色、サイズ、素材など、選択条件になる属性を構造化する
  • 配送費・配送日数・返品条件を購入前に確認できるようにする
  • 表示、候補掲載、販売者選択、クリック、購入を別々に測る

ChatGPTの商品結果で公式に確認できること

OpenAIの2026年7月27日時点のヘルプでは、ChatGPTはショッピング意図のある質問で、画像、商品情報、販売サイトへのリンクを含む候補を表示する場合があります。商品結果は広告とは分けられ、商品や販売者のメタデータは第三者または販売者から直接提供される場合があります。

複数販売者が同じ商品を扱う場合、在庫、価格、品質、メーカーまたは主要販売者かどうかなどが販売者一覧の要素として案内されています。Shopify販売者の商品データはShopify Catalog経由で統合され、その他の販売者には商品フィード仕様と申請経路が案内されています。

これらは商品掲載や順位の保証ではありません。機能、対象地域、対応販売者、表示形式は変わります。商品フィードを送信できない事業者でも公開商品ページが参照される場合があり、フィードがあっても特定質問で必ず候補になるとは限りません。

監査する4つの商品データ面

第一は、購入者が見る商品ページです。商品名、価格、在庫、画像、仕様、対象者、配送、返品、販売者、更新された説明をHTMLで確認できることが基準です。JSON-LDやフィードだけにある情報は、購入者が検証できません。

第二はProduct、Offer、ProductGroupなどの構造化データです。Googleは、購入可能な商品ページではMerchant listing向けのProduct情報を利用でき、商品バリエーションにはProductGroup、hasVariant、variesBy、productGroupIDを案内しています。

第三はGoogle Merchant Centerの商品データです。Googleは商品ID、タイトル、URL、画像、価格、説明、在庫などを商品データ仕様で定義し、商品ページ、構造化データ、購入画面と価格・在庫を一致させるよう求めています。

第四はOpenAIの商品フィードです。Stable仕様では、検索・購入の適格性フラグ、安定したitem_id、タイトル、説明、URL、ブランド、画像、価格、販売者名、販売者URL、返品ポリシーURLなどが定義されています。直接フィードは申請・対応状況を確認し、仕様を読めることと自社が送信可能であることを分けます。

商品識別子をバリエーション単位で安定させる

親商品と販売可能なSKUを混ぜると、色やサイズの価格・在庫が別の商品へ結びつきます。Google Merchant CenterのidとOpenAIのitem_idは、販売可能なバリエーションごとに安定させます。商品名を変更しても同じSKUならIDを再利用し、別商品へ同じIDを使い回しません。

GTINが付与された商品は正しいGTINを使い、存在しない番号を作りません。MPN、ブランド、SKU、GTIN、親商品IDの役割を分け、販売店名をメーカーのブランド名として送らないようにします。

  • 親商品：共通名、説明、バリエーション軸、ブランド
  • 販売SKU：色、サイズ、価格、在庫、固有画像、固有URL
  • グローバル識別子：割り当て済みの場合だけGTIN
  • メーカー型番：公式のMPN
  • 販売者：自社、メーカー、マーケットプレイスの関係を分ける

価格・在庫・セール情報は同じ時点へそろえる

通常価格、セール価格、通貨、セール期間、在庫状態を一つの更新処理から出力します。Googleは価格と在庫を商品ページ、構造化データ、購入画面と一致させるよう案内しています。OpenAIの商品フィードも通貨つき価格、セール価格と期間を定義しています。

在庫が頻繁に変わる場合は、静的な記事更新では追いつきません。商品マスターや在庫システムからフィード、JSON-LD、画面を生成し、更新失敗を監視します。欠品を隠して候補掲載を維持しようとせず、予約、取り寄せ、欠品を正しい状態へ分けます。

色・サイズ・素材は検索条件として扱う

AIの商品質問は「おすすめの靴」だけでなく、予算、用途、色、サイズ、素材、重量、配送日、返品可否など複数条件を含みます。商品説明の文章にすべてを埋め込むだけでなく、バリエーションと属性をSKUへ結びつけます。

Googleではitem_group_idやProductGroup、OpenAIではvariant_dict、item_group_id、色、サイズ、サイズ体系などの項目が用意されています。自社独自の値は、単位、表記、選択肢を揃え、同じ色を「紺」「ネイビー」「NAVY」と無計画に分けません。

配送・返品・販売者情報を商品からたどれるようにする

配送費、対象地域、出荷までの日数、配送日数、返品可能日数、返送費、交換可否は、比較の終盤で重要になります。GoogleはMerchant Centerと構造化データの両方で配送・返品情報を扱い、OpenAIの商品フィードもshipping、return_policy、return_deadline_in_daysなどを定義しています。

全商品共通の返品ポリシーは専用ページと組織レベルのデータで管理し、セール品や受注生産品など例外がある場合だけ商品単位の条件を上書きします。特定商取引法ページだけに情報を置いて終わらず、商品・カート・購入画面から同じ条件を確認できるようにします。

レビューとQ&Aは実在する根拠だけを使う

レビュー件数、平均評価、質問と回答を使う場合は、自社が実際に収集し、表示し、更新できる情報に限ります。OpenAIの仕様にはレビューやQ&Aの項目がありますが、存在しない評価を追加する根拠にはなりません。

商品ページ上で確認できない星評価をJSON-LDやフィードだけへ足したり、別商品のレビューを統合したり、提供レビューを自然投稿のように見せたりしません。質問と回答は、購入者の制約判断に役立つ事実を、商品担当者が確認できる形で維持します。

クロールとインデックスは商品データの入口

正しいデータがあっても、商品URLがログイン必須、noindex、robots.txtで遮断、HTTPエラー、JavaScript実行後だけのリンクに依存していると、通常の取得経路で見つけにくくなります。カテゴリから商品へのHTMLリンク、自己参照canonical、商品サイトマップ、HTTP 200を確認します。

無限スクロールや絞り込み検索では、全商品が検索フォーム操作だけで到達する構成を避けます。ページ分割されたカテゴリやサイトマップから、重要商品とバリエーションの正規URLへ到達できるようにします。

OAI-SearchBot、GPTBot、Googlebotは目的が同じではありません。取得を許可しただけで候補掲載されるとは扱わず、検索・ショッピングに必要なクローラー方針と自社の権利・負荷・契約条件を分けて決めます。

25項目をSKU単位で照合する

配布CSVでは、商品ページ、Product JSON-LD、Google Merchant Center、OpenAI商品フィードを横に並べ、商品ID、名称、URL、画像、ブランド、識別子、価格、在庫、バリエーション、配送、返品、レビューなど25項目を確認できます。

全商品を一度に調べる前に、売上上位、在庫変動が大きい、新商品、バリエーションが多い、返品が多い商品から20 SKUを選びます。各欄の実際値と取得時刻を保存し、差分があれば出力先を個別修正する前に正本データと更新処理を確認します。

  • 1. 対象SKUと親商品IDを固定する
  • 2. 商品ページの可視情報とHTMLを保存する
  • 3. JSON-LD、Merchant Center、利用可能ならOpenAIフィードを同時取得する
  • 4. 値、不在、更新時刻、取得失敗を分けて記録する
  • 5. 商品マスターまたはポリシーの正本を修正する
  • 6. 各出力を再生成し、同じ25項目を再確認する

EC向け20問で商品掲載と販売者選択を分けて測る

AI商品検索の測定では、同じ質問でも、商品が候補に出ること、特定販売者が選ばれること、公式商品URLが表示されること、価格・在庫・仕様が正しいことを分けます。一回の質問を一般的な掲載率や売上効果と呼びません。

配布テンプレートは、カテゴリ探索、用途、予算、制約、比較、正確性、配送、返品、バリエーション、販売者選択の20問です。自社名を含む指名質問と、含まない非指名質問を分け、画面上のサービス、検索機能、日時、地域、質問文、回答、商品、販売者、URL、事実判定を保存します。

  • 商品候補：自社商品が候補に含まれたか
  • 販売者候補：自社が購入先に含まれたか
  • 公式URL：正しい商品・販売者URLが表示されたか
  • 正確性：価格、在庫、色、サイズ、配送、返品が一致したか
  • 適合性：質問の予算・用途・制約を満たしていたか
  • 行動：商品ページ遷移、カート、購入を別々に記録できるか

実装は上位20 SKUから小さく始める

最初の2週間は、正本と担当者を決め、20 SKUの25項目監査、技術取得確認、20問の基準線を作ります。次に、重大な価格・在庫・識別子の不一致を優先し、商品ページ、構造化データ、Google商品データを再出力します。

OpenAIの商品フィードを利用できる場合は、公開仕様と自社の承認範囲に沿って追加します。利用できない場合も、存在しない連携を成果として書かず、商品ページ、Google検索、管理可能な外部情報、固定質問の観測を続けます。

改善後は同じSKU、質問、条件で再取得し、改善、悪化、変化なし、不明を分けます。順位や推薦を保証するKPIではなく、不一致件数、更新遅延、取得不能、誤った商品・販売者URL、重要事実の正確性を先に減らします。

やってはいけないEC向けLLMO対策

商品名へ検索語を詰め込み、説明を大量生成し、実在しないレビューや人気度を付ける方法は採用しません。OpenAIのCommerce policies、Googleの商品データ仕様、広告・表示・消費者保護に関する自社の適用法令とプラットフォーム規約を確認します。

  • 商品ページと異なる価格・在庫を送る
  • 存在しないGTIN、評価、受賞、在庫、配送速度を作る
  • 同じSKUのIDを更新ごとに変える、別商品へ使い回す
  • 全バリエーションを一つの価格・在庫として扱う
  • フィード連携だけでChatGPT掲載や売上を保証する
  • Product構造化データをChatGPT専用マークアップと説明する
  • AI生成の商品説明を確認せず全商品へ一括公開する
  • 取得失敗を候補掲載0として集計する