AI検索に商品を正しく伝えるには？ 商品ページ・Google Merchant Center・OpenAIの商品フィードで、商品ID・価格・在庫・対象国をそろえる対応表と点検手順

「AI検索に、うちの商品をちゃんと出したい。でも何を直せばいいの？」

ネットショップを担当していると、こんなところで迷いませんか？ 商品ページ、Google Merchant Center、OpenAIの商品フィード。入口が3つもあるうえに、列の名前まで違います。入口で迷子になりそうですよね。

まず、ここを押さえておきましょう。

やることは「3か所に同じファイルを送る」ではありません。「同じ商品を、同じ販売条件・同じ時点で説明できる」状態にすることです。

そのために、商品台帳を正本にして、提供先ごとに項目名と値を変換します。公式の仕様をもとに、対応表と点検手順をまとめました。

この記事で分かるのは、次のことです。

• 商品ページ・Googleへ渡す商品データ・OpenAIの商品フィードの役割の違い
• 商品ID、親ID、JANの使い分け
• 通常価格・セール価格・在庫・対象国の、3経路での対応表
• 青と白のマグカップで作った、3経路の出力例
• 12手順の点検と、担当者へそのまま渡せる依頼文

ネットショップの運営やマーケティングを担当する方のための記事です。エンジニアでなくても読めるように書きました。JSONなどのコードは実装担当に渡す参考として置いています。

この記事の確かめ方について。 2026-10-27に、GoogleとOpenAIの公式ドキュメントを読み直しました。OpenAIの仕様は公式のMarkdown版を直接取得し、Googleの在庫と価格の記述も原文で確かめています。一方、実際のショップやMerchant Center、OpenAIの加盟店アカウントへの送信はしていません。つまり、受理率、反映時間、AI回答での表示や順位、購入のしやすさは測っていません。出力例は、仕様に沿って作った架空のデータです。

011. 先に答え：8つのポイント

1. 提供経路は3つあって、別物です。 商品ページの構造化データ、Google Merchant Center、OpenAI商品フィード。Googleに登録しても、OpenAIに登録したことにはなりません。Googleはページとフィードの併用を勧めています。
2. 基本の単位は「購入できる1種類」です。 青と白、SとMは、別の商品IDにして、親IDを共通にします。
3. 価格の意味をそろえます。 ページのOffer.priceは「いま払う金額」。GoogleとOpenAIのフィードでは、通常価格をprice、値引き後をsale_priceに入れます。
4. 在庫は表示の言葉から、提供先の値へ変換します。 予約は、Googleがpreorder、OpenAIがpre_orderです。綴りが違います。
5. 対象国は通貨やサイズ表記では決まりません。 OpenAIの標準アップロードはいまのところ米国向けです。JPやJPYと書いても、日本向けにはなりません。
6. OpenAIはStableの仕様だけを見ます。 別のガイドの項目名を混ぜると、列名が合わなくなります。
7. 削除は即時ではありません。 OpenAIでは、一覧から商品を抜いても、最後に処理された記録が最大14日残ります。
8. 「受理」「表示」「購入」は別の話です。 データが正しく通っても、表示や購入までは保証されません。

022. 3つの経路は、それぞれ何をするのか

まずは、商品データがどこへ渡るのかを見てみましょう。

構造化データはページに埋め込む「機械向けの説明書き」です。多くはJSON-LDという形式で書かれます。

Googleのドキュメントで読むのは、Merchant listings向けの仕様です。商品を直接買えない紹介・レビュー用のProduct snippetsとは、必須条件が違うからです。

注意点が2つあります。

• すでにECプラットフォーム連携やGoogleの自動追加を使っているなら、手動のファイルを足す前に、どれが商品を更新しているか確認します。二重に上書きしあうと、値が戻ります。
• OpenAIの商品フィードは、承認されたパートナー向けの導入案内があります。仕様が公開されているからといって、自社アカウントからすぐ送れるとは限りません。OpenAIのヘルプには、Shopifyの加盟店はShopify Catalog経由ですでに統合済み、という説明もあります。Shopify利用店はまず既存の連携を確認しましょう。

「特別なAI用タグ」は要りません。 GoogleのAI機能のガイドは、AI向けの特別なSchema.org追加を求めていません。見える内容と構造化データが一致していること、Merchant Centerの情報が新しいことを案内しています。

033. 商品ID・親ID・JANを分ける

台帳には役割の違う4種類の識別子があります。

これは、この記事で考えた台帳の形です。ただし、元になる決まりは公式の仕様にあります。

• Googleのidには、SKUを使うことが勧められています。価格や在庫が変わっても、IDは変えないのが基本です。
• OpenAIの仕様にも、価格・在庫・タイトル・画像が変わっても、item_id・group_id・offer_idは変えないようにと書かれています。さらに、オファーIDに価格を入れないとも明記しています。

IDの付け替えは地味に痛いミスです。毎回IDが変わると、商品の履歴がつながらなくなります。

見栄えのためにIDを直さない

すでに連携で使っているIDがあるなら、変えないでください。別のID体系が動いているなら、対応表で結びつけます。

JANは「IDの代わり」ではない

JANはGTINの一種で、メーカーが割り当てる世界共通の番号です。販売者ごとの管理番号であるSKUとは別物です。

• 中古品、セット、個数違い、販売者違いを、同じ商品として混ぜない
• 表計算では文字列として持つ（先頭のゼロが消える、指数表記になる事故を防ぐ）
• 確認できない番号は作らない。OpenAIも「未割当なら省略」と書いています

同じSKUを日本と米国で売るとき

台帳では「商品そのものの情報」と「市場ごとの販売条件」を分けます。

• 商品情報：SKU、親ID、ブランド、色、サイズ、GTIN、説明
• 販売条件：販売者、対象国、言語、通貨、税の扱い、価格、注文できる在庫、URL、配送、返品、更新時刻

Googleのガイドは同じ商品を別の国・言語に出すときも、同じIDを使うよう案内しています。台帳の行を区別するために、国名をIDへ無理に足す必要はありません。台帳側の行キーをSKU＋販売者＋市場＋言語のようにして、データソースの設定と対応させます。

OpenAIへは承認された市場の行だけを出します。同じitem_idの日本円の行と米ドルの行を、同じフィードへ並べてはいけません。

044. 項目の対応表

ここがこの記事の中心です。それぞれの項目がどんな意味で対応するのか、主なものを表にしました。全項目が全経路で必須という意味ではありません。「直接同じ列がない」と「その事実が要らない」は別の話です。

4.1 識別とバリエーション

親IDを足したら、それで十分でしょうか？ 実は、選択軸（色なのかサイズなのか）は、それだけでは伝わりません。親IDだけで安心しないでください。

Googleにはvariant_optionとitem_group_titleがあり、色・サイズ以外の選び方も書けます。ただし、標準のcolorやsizeが必要なときに、省いて置き換えてはいけません。

4.2 価格・在庫・地域

通貨の書き方も違います。ページは数値21.60と通貨USDを別のプロパティに入れます。OpenAIは"21.60 USD"という1つの文字列です。記号だけの「¥」「$」は使いません。

4.3 在庫の値の対応

Googleは予約と取り寄せのとき、出荷できる日（availability_date）を必須としています。しかも、その日付はランディングページにも表示されている必要があります。

OpenAIの仕様には、pre_orderとbackorderは「将来の在庫変更を予約するものではない」とあります。入荷したら、availabilityを更新します。

「在庫10個」をin_stockに変換してよいかは、受注・引当・配送のルールに照らして決めてください。倉庫に在庫がゼロでも、取り寄せ注文を受けるお店はあります。反対に、数量が正でも、安全在庫のために注文を止めることもあります。

055. 通常価格・セール価格・税・送料

同じ価格かどうかは、意味をそろえて比べる

通常3,300円、セール中2,970円の商品なら、次の状態が「矛盾していない」ことになります。

ページの現在価格（2,970）と、フィードのprice（3,300）が違うだけでは、誤りと判定できません。「いまの有効な価格」に直してから比べます。

OpenAIのsale_priceには条件があります。0より大きく、priceより小さく、同じ通貨であること。条件に合わない値は使われません。

開始・終了の運用

Googleにはsale_price_effective_dateがあり、開始・終了とタイムゾーンを指定できます。一方、OpenAIの仕様は「セール開始・終了時にフィードを更新する」という書き方です。

運用はこうなります。

• 台帳：通常価格、セール価格、開始、終了、タイムゾーン、対象市場を別の列にする
• ページ：その時点で有効な価格を表示し、構造化データにも反映する
• Google：期間情報を出す。ページとカートの金額も合わせる
• OpenAI：開始時にsale_priceを送り、終了時に外す
• 記録：開始直後と終了直後に、3経路の値をスクリーンショットで残す

税と送料

Googleの価格のルールでは、米国・カナダ向けとそれ以外で税の含め方が違います。日本向けの税込価格を、そのまま米国向けの販売価格にしないでください。台帳には「税込か税別か」「対象国」「チェックアウトで足される金額」を書きます。これは商品データ提出の仕様の話で、税務の判断ではありません。

送料は商品価格と別に管理します。Googleでは日本向けも送料情報の提出が必要です。OpenAIのshipping_priceが空欄なら、「無料」ではなく「不明」の意味になります。

会員価格、クーポン、初回限定、定期購入、分割払いは、通常の価格に混ぜません。最初の整備では、一般の購入者が払う通常の販売条件だけを優先してください。

066. 対象国：5つの「国」を分ける

「日本向け」と一言でいっても、何が日本向けなのかで話が変わります。ここでは5種類の国を分けて考えます。

サイズ表記のJPはサイズ体系で、通貨のJPYは金額の単位です。どちらも販売対象国の設定ではありません。

公開資料で確認できた範囲

OpenAIの仕様の言葉を借りると、「通貨、商品URL、サイズ体系は、販売対象国を選ばない」です。

日本向けの直接フィードに対応しているかは、公開の仕様では確認できませんでした。 これは「日本の商品がChatGPTの商品結果に一切出ない」という意味ではありません。直接フィードの参加と、商品が見つかるかどうかは別の話です。地域の情報は変わるので、実際に導入する前に、窓口へ確認してください。

077. 共通の商品台帳を作る

新しい専用システムを買う必要はありません。いまのEC、PIM（商品情報管理）、在庫管理が正本なら、その出力を台帳として使えます。価格と在庫を更新するためだけの、手入力の別台帳は増やさないでください。 二重管理はほぼ確実に食い違います。

商品共通の列

市場ごとの販売条件の列

台帳に「JP・JPY・日本語」と書くことと、Google・OpenAIのアカウントに対象市場を設定することは、別の作業です。項目対応表と、設定票の両方を持ちましょう。

市場別の台帳の例（架空）

固定の為替で自動換算した値ではありません。市場ごとに決めた販売価格です。同じSKUでも、市場が違えば価格も在庫も違ってかまいません。そろえるのは、その市場のページ・フィード・購入画面の間です。

088. 同じ台帳から3経路へ出力する例

ここからは、米国向けの架空のお店「Example Home」の例です。使うのは台帳のUS行だけ。青はセール中、白は在庫切れという条件で比べます。ドメインや画像は説明用なので、そのまま送るファイルではありません。

非エンジニアの方は次の4つだけ見れば大丈夫です。

• 青の現在価格が21.60、通常価格が24.00
• 白の在庫が切れている
• 親IDはMUG350、子IDはMUG350-BLUEとMUG350-WHITE
• 3か所とも同じ内容になっている

8.1 商品ページ（JSON-LD）

{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "Example Home ceramic mug 350 mL",
  "productGroupID": "MUG350",
  "url": "https://example.com/us/mug350",
  "brand": {"@type": "Brand", "name": "Example Home"},
  "variesBy": ["https://schema.org/color"],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "MUG350-BLUE",
      "name": "Example Home ceramic mug 350 mL - Blue",
      "description": "Glazed ceramic mug, 350 mL, blue.",
      "color": "Blue",
      "image": "https://example.com/images/mug350-blue.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/us/mug350?color=blue",
        "price": 21.60,
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "itemCondition": "https://schema.org/NewCondition",
        "priceSpecification": {
          "@type": "UnitPriceSpecification",
          "priceType": "https://schema.org/StrikethroughPrice",
          "price": 24.00,
          "priceCurrency": "USD"
        }
      }
    },
    {
      "@type": "Product",
      "sku": "MUG350-WHITE",
      "name": "Example Home ceramic mug 350 mL - White",
      "description": "Glazed ceramic mug, 350 mL, white.",
      "color": "White",
      "image": "https://example.com/images/mug350-white.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/us/mug350?color=white",
        "price": 24.00,
        "priceCurrency": "USD",
        "availability": "https://schema.org/OutOfStock",
        "itemCondition": "https://schema.org/NewCondition"
      }
    }
  ]
}

Googleの価格のルールでは、いま払う金額はpriceTypeなしの価格です。2つ目の価格をStrikethroughPriceとして添えると、自動的にセール価格として扱われます。「いま払う金額」にpriceTypeを付けてはいけません。

GTINは架空の番号を作らず、省略しました。実物に番号が付いているなら、正しい番号を足してください。

8.2 Google Merchant Center（タブ区切りの商品ファイル）

列の間は実際のタブです。販売対象国US・言語enと、米国向けの配送・返品は、別に設定済みという想定です。価格やURLだけで、国を指定したことにはなりません。

id	item_group_id	item_group_title	title	description	link	image_link	brand	color	variant_option	condition	price	sale_price	availability
MUG350-BLUE	MUG350	Example Home ceramic mug 350 mL	Example Home ceramic mug 350 mL - Blue	Glazed ceramic mug, 350 mL, blue.	https://example.com/us/mug350?color=blue	https://example.com/images/mug350-blue.jpg	Example Home	Blue	color:Blue	new	24.00 USD	21.60 USD	in_stock
MUG350-WHITE	MUG350	Example Home ceramic mug 350 mL	Example Home ceramic mug 350 mL - White	Glazed ceramic mug, 350 mL, white.	https://example.com/us/mug350?color=white	https://example.com/images/mug350-white.jpg	Example Home	White	color:White	new	24.00 USD		out_of_stock

表計算で保存するときは、タブ区切りのまま保存します。単純なカンマ区切りCSVに変えると、列がずれます。

8.3 OpenAI商品フィード（Stable、JSONLの2行）

米国向けの連携が確認済みという条件の例です。

{"item_id":"MUG350-BLUE","group_id":"MUG350","listing_has_variations":true,"variant_dict":{"color":"Blue"},"offer_id":"STORE1-MUG350-BLUE","title":"Example Home ceramic mug 350 mL - Blue","description":"Glazed ceramic mug, 350 mL, blue.","url":"https://example.com/us/mug350?color=blue","brand":"Example Home","seller_name":"Example Home Store","image_url":"https://example.com/images/mug350-blue.jpg","price":"24.00 USD","sale_price":"21.60 USD","availability":"in_stock","is_eligible_search":true}
{"item_id":"MUG350-WHITE","group_id":"MUG350","listing_has_variations":true,"variant_dict":{"color":"White"},"offer_id":"STORE1-MUG350-WHITE","title":"Example Home ceramic mug 350 mL - White","description":"Glazed ceramic mug, 350 mL, white.","url":"https://example.com/us/mug350?color=white","brand":"Example Home","seller_name":"Example Home Store","image_url":"https://example.com/images/mug350-white.jpg","price":"24.00 USD","availability":"out_of_stock","is_eligible_search":true}

必須の9項目（item_id、title、description、url、brand、seller_name、image_url、availability、price）はすべて入れています。バリエーションなので、group_id・listing_has_variations・variant_dictも付けました。

実際に送信するときは、parquetなどのファイルをSFTPで送ります。jsonl.gz、csv.gz、tsv.gzも使えます。上の平文のJSONLは、中身が読めるように載せた例です。

8.4 3つの出力で確認すること

この例のJSON、JSONL、TSVの構文と、2つのバリエーションのID・価格・在庫・URLの突き合わせは、ローカルで確認しました。Rich Results TestやMerchant Center、OpenAIの実サービスでの検査はしていません。

099. 12手順の点検

ここからは、公式仕様を踏まえて組み立てた運用案です。所要時間や反映を保証するものではありません。

1. 対象とゴールを1枚に書く。 店舗、対象国、言語、通貨、販売者、商品範囲。「Googleの無料リスティング」「ChatGPTでの商品発見」「広告」「ChatGPT内の購入」は、別の欄にします。
2. いまの連携経路を調べる。 EC標準機能、連携アプリ、フィード代行、自作、手動シート。複数の経路が価格を上書きしていないか見ます。
3. 正本と担当を決める。 商品IDはEC、価格は販売管理、在庫は受注・引当後のシステム。マーケ担当が直したCSVを、次の自動出力が古い値へ戻す状態を防ぎます。
4. 例外を含む少数の商品を選ぶ。 通常品、バリエーション2つ以上、セール、在庫切れ、予約・取り寄せ、地域で条件が違うもの。OpenAIの導入サンプルは約100商品が目安ですが、人手の確認は数件で十分です。
5. IDと親子を固定する。 3経路のIDを対応表へ。重複、再利用、先頭ゼロの消失、親と子の混同を直します。
6. ページを購入者の状態で開く。 シークレットウィンドウで、選択済みのURL・言語・通貨・価格・在庫・画像・カートを見ます。
7. 構造化データを読む。 実装担当に、そのURLのID・価格・通貨・在庫・親子関係を取り出してもらいます。Rich Results Testの合格は、在庫が正しい証明ではありません。
8. 提供先ごとの値を並べる。 その時刻の有効な価格を計算し、同じSKU・市場の画面と照合します。preorderとpre_orderのような変換も確認します。
9. 国・配送・機能の設定を見る。 Googleの商品詳細で国別の問題を確認します。OpenAIについては、承認・形式・市場・通貨の回答を保存します。
10. 送信結果を行ごとに見る。 ファイル転送の完了だけで、全商品の成功とは言えません。処理結果と拒否理由を確認します。
11. 変更を1巡させる。 値上げ、セールの開始と終了、在庫切れと復帰、掲載停止。予約商品は出荷開始も別の変更として扱います。
12. 全件に広げ、継続点検を決める。 重複、必須の欠落、価格、通貨、在庫値は自動検査に任せます。人の目では変更・拒否・例外の商品を確認します。

ページを開いたときの6つのチェック

URLの文字列が違うだけでは、まだ確認は終わりません。ページを開いた直後の状態で、次を見ます。

1. 対象の色・サイズが最初から選ばれている
2. 画像、商品名、価格、在庫がその選択と合う
3. 別のバリエーションへ勝手に切り替わらない
4. 同じ選択のまま、カートに入れられる
5. 国・言語・通貨が送信値と合う
6. ログインや過去のCookieがない状態でも、再現できる

Googleは各バリエーションを直接選べる固有のURLを求めています。OpenAIも可能なら選択済みのページを求めています。

なお、バリエーションへのリンクと、検索エンジンに伝える代表URL（canonical）は別の役割です。「色ごとにリンクできるように」と、canonicalまで色ごとに分けるよう頼むのは早合点です。サイトの構成に合わせて、実装担当に判断してもらいます。

コピー用の点検票

1010. よくある不一致と、最初に疑う場所

Googleの自動更新は小さな食い違いを直す手助けをしてくれる仕組みです。定期的な同期の代わりにはなりません。

1111. 更新と削除の決め方

在庫切れ・停止・削除は別の操作

「検索対象から外すフラグ」は、すでに生成された回答や、他の経路にある情報まで、即座に消す保証ではありません。法的な削除や緊急の停止を、この手順だけで完了扱いにしないでください。

OpenAIのファイル経路は「全件スナップショット」

• 毎回、カタログ全体を送る。少なくとも毎日が推奨
• ファイル名を毎回同じにして、上書きする（日付入りの別名で積み上げない）
• 複数ファイルなら、間を空けずに全部アップロードする
• OpenAIはファイル名ではなくitem_idで商品を照合する

「毎日送る」ことと、「価格・在庫がいつも新しい」ことは別です。変化の速いお店では、更新の間隔や失敗の通知、連携が認めるAPIなどの別経路について、担当者と合意しておきましょう。

1212. 担当者への依頼テンプレート

そのままコピーして使えます。

A. 商品管理・在庫・価格の担当へ

件名：AI検索向けの商品データ整備に使う正本の確認

対象店舗：
対象国・言語・通貨：
対象商品／SKU：
確認期限：

商品ページ・Google Merchant Center・OpenAI向けに、同じ商品と販売条件を
説明できるようにしたいです。以下の正本と確認担当を教えてください。

1. 子SKU、親商品ID、既存連携で使っているIDの対応
2. 色・サイズ・容量など、購入できる選択肢と親子関係
3. JAN/GTIN、メーカー型番、ブランド。確認元と「未割当」「未確認」の区別
4. 通常価格、一般向けセール価格、期間、タイムゾーン、税の扱い
5. 受注できる在庫、予約／取り寄せ／欠品の区分、出荷予定日
6. 国・配送地域ごとの販売可否、送料、納期、返品条件
7. 各値の更新元システム、更新時刻、変更を承認する担当

不明な値は推測で埋めず、理由と確認先を書いてください。
価格変更・在庫切れでIDを変えない前提も確認してください。

B. ECシステム・制作会社・フィード担当へ

件名：商品台帳からページ構造化データ・Google・OpenAIへの項目対応の確認

対象店舗：
対象国・言語・通貨：
確認するSKUとURL：
商品台帳の場所：
現在の連携アプリ・データソース：
確認期限：

以下を、実際の出力値と処理結果を添えて確認してください。

1. SKU → Product.sku／Google id／OpenAI item_id の対応と、既存IDの維持
2. 親ID、選択軸、子の色・サイズ・画像・価格・在庫の対応
3. URLを直接開いたときの、バリエーション・国・通貨の再現
4. 現在価格と通常価格の変換
   （ページのOffer.priceは現在価格、フィードのprice/sale_priceは仕様どおり）
5. preorder／pre_order などの値の変換、予定日、不明値の扱い
6. ページ、構造化データ、カート、Google送信値の、同じ時点での照合
7. Googleの販売国・配送設定、OpenAIの承認市場・通貨
8. 更新の間隔、失敗の通知、手動修正を上書きするデータソースの有無
9. セール開始／終了、欠品／復帰、恒久終了の、経路ごとの更新・削除方法

OpenAIは現行Stableのファイル仕様だけを参照し、Draftや別APIの項目を
混ぜないでください。OpenAIの導入が未承認なら、送信せず、対応表と
未解決事項を提出してください。

返却物：項目対応表、国・掲載先・連携の設定票、少数商品の実値の比較、
検査結果、送信・処理時刻、不一致の修正元／担当／期限。
ファイル転送の成功、商品の処理成功、表示、購入は、別々に報告してください。

C. OpenAI・連携プラットフォームの窓口へ

件名：商品フィード連携の提供条件と日本向けの利用範囲の確認

事業者所在地：
EC基盤／店舗URL：
販売対象国・配送地域：
言語・通貨：
商品カテゴリ・SKU数・主な変動頻度：
希望する機能：商品発見／広告／ChatGPT内購入（それぞれ選択）

以下を、現行の契約・連携仕様に沿って回答してください。

1. 当社の国・事業者・商品カテゴリで参加できる経路と、承認の条件
2. OpenAI形式Stable、API、ECプラットフォーム連携のどれを使うか
3. 日本の加盟店、日本の購入者、日本への配送、それぞれの対応可否
4. 有効な対象国・通貨・言語と、市場を決める登録設定
   （target_countries／store_country 列が有効になる条件）
5. 商品IDの一意性の範囲、複数販売者・複数市場の表現方法
6. 価格・在庫の更新方法、推奨頻度、失敗の検知、処理結果の確認方法
7. セール開始／終了、予約開始／出荷開始の更新方法
8. 検索対象からの除外、広告だけの停止、恒久削除の方法と保持期間
9. 検索・広告・購入フラグの有効範囲と、別に必要な導入作業
10. Shopify等の既存連携がある場合、追加のフィードが必要か

項目を送信できること、処理されること、商品が表示されること、
順位が決まること、購入が使えることを、分けて説明してください。

1313. 成果は、段階を分けて確かめる

「フィードを送った」で終わらせず、段階ごとに証拠を見ます。

OpenAIの商品結果は質問・文脈・商品データなどに応じて選ばれます。商品結果と広告についても、分けて説明されています。フィードを出すことを「推薦順位を買う」ことや「順位が上がる保証」と説明してはいけません。

最初の指標として、データの整合率、処理された行数、拒否の理由、更新の遅れ、代表SKUの価格・在庫の誤りを見ると、直す場所が分かります。売上やAIの推薦にどれだけつながったかを知るには、別の観測と比較が必要です。

1414. 仕様を読むときの落とし穴

• OpenAIはStableを選ぶ。 この記事はファイル仕様のitem_id・group_id・variant_dictなどで統一しました。別のガイドにある入れ子のvariantsやseller.nameを、このファイルの列名へそのまま混ぜてはいけません。
• 検索で出てくる断片ページに注意。 古い断片にはGoogle互換の形式など、別の説明があります。現行ページのStableを基準にしました。
• GoogleのMerchant Center仕様、Search Central、Schema.orgは別の文書。 Schema.orgにあるプロパティを足すだけで、Googleの機能が対応するわけではありません。
• Googleの列名は商品ファイル用。 Merchant APIのコードへそのまま移せる名前とは限りません。

1515. 参考にした一次資料

すべて2026-10-27に確認しました。取得日は仕様の制定日ではありません。

Google

• Introduction to Product structured data
• Merchant listing structured data
• Product variant structured data
• ID／Item group ID／GTIN
• Price／Sale price／Availability
• Product data specification
• Set up your target country of sale／Supported languages and currencies
• Allow Merchant Center to update product information automatically
• Variant option／Item group title
• AI features and your website

OpenAI

• Products: Stable（公式Markdown版）
• File upload overview
• Ads product feeds
• Commerce best practices
• Shopping with ChatGPT Search

16まとめ：最初の1週間でやること

全件をいきなり直さなくて大丈夫です。

1. 通常品・色違い・セール・在庫切れ・予約・地域違いの商品を、1つずつ選ぶ
2. その商品の「台帳・画面・構造化データ・Googleの送信値」を横に並べる
3. 食い違いを、表の「最初に疑う場所」で切り分ける
4. OpenAIは参加の経路と対象市場を窓口に確認してから足す

数件でも食い違いが分かれば、全件の点検を依頼する文面も書けます。この記事の依頼テンプレートを、ぜひ使ってください。

AIに商品を正しく伝える近道は、特別なタグではなく、同じ商品を、同じ条件で、同じ時点で、どこからでも説明できる台帳です。