ChatGPT が商品を推薦する際に読み取る情報は何か？EC サイトは商品カタログと商品データをどう準備すべきか？

タイトルの問いに直接回答します。ChatGPT が商品を推薦する際に読み取る入力は主に2種類あります。

第一は、事業者が自ら提出する構造化された商品 Feed です。OpenAI の商品 Feed の仕様説明によれば、Feed は商品データの単一の真実の情報源であり、タイトル、価格、在庫、メディア素材、物流情報を網羅し、商品検索、商品発見、および条件を満たす場合の即時決済を支えるために用いられます。これらのデータはクローラーによって取得されるのではなく、事業者が構造化ファイルをセキュアなエンドポイントにプッシュし、高頻度の更新によって正確性を保つものです（ChatGPT Product Feed 仕様説明）。

第二は、公開ウェブページ上で解析できる商品ページ情報です。商品名、現在の価格、仕様パラメータ、適用シーン、配送・返品ポリシーなどが含まれます。ユーザーがショッピングリサーチの場面で得る購買ガイドには、通常、人気製品の推薦、主要な差異の比較、長所と短所の分析、小売業者へのリンクが含まれます（ChatGPT ショッピングリサーチ機能の報道）。

したがって、実際に結果を決めるのは2つの層です。Feed はあなたの商品が候補プールに入れるかどうかを決め、商品ページは引用される際に正しく説明されるかどうかを決めます。両者が一致しないことが、最もよくある問題の原因です。

ChatGPT が商品情報を取得する3つの経路

• ショッピングリサーチ：消費者の意思決定に向けた対話型リサーチで、まず予算、利用者、重視する機能を確認し、その後比較と提案を出力します。結果にはクリック可能な小売業者へのリンクが示されます。
• 商品 Feed：事業者が商品カタログを構造化して提出し、検索・比較・推薦が可能な商品エントリを形成します。フィールドの完全性が、フィルタリングされるかどうかを直接左右します。
• Feed 広告：2026年5月12日、OpenAI は ChatGPT 内で product feed 広告フォーマットを開始しました。事業者は商品カタログを接続し、フィルタ条件を設定すると、システムが商品名、画像、価格、属性を用いて広告を自動生成します。報道によれば、1広告主あたり最大100万 SKU をカバーでき、新たに参加する EC パートナーはまず100商品のサンプルを提出する必要があり、使用する Feed ファイルは Google Shopping に提出する構造化ファイルとほぼ同一です（product feed 広告開始の報道）。

3つの経路に共通する点は明確です。入力はすべて構造化フィールドであり、データの正確性に敏感で、キーワード密度では勝負が決まりません。

商品 Feed とは何か

Feed は機械可読な商品リストファイルです。1行に1商品または1バリエーション、フィールドは固定、フォーマットは固定、定期的に更新されます。「商品ページを美しく作る」こととは別のものです。商品ページは人の閲覧とコンバージョンに奉仕し、Feed は機械間のマッチングと比較に奉仕します。

仕様説明には見落とされがちな細部があります。Feed は商品データの単一の真実の情報源と定義されています。つまり、同じ商品の Feed 内のタイトル、価格、在庫は、ランディングページに表示されるものと一致していなければならず、そうでなければプラットフォームとユーザーは2つの異なる事実を見ることになります。

表で一目でわかる準備すべきフィールド

名称、価格、在庫は必ず一致させる

電子製品モールの事例で説明します。同じ「AuraSound NC-700 ワイヤレスノイズキャンセリングヘッドホン」が3箇所に出現します。公式サイトでは1299元で在庫ありと表示され、商品 Feed ではまだ1499元で在庫切れとマークされ、あるサードパーティプラットフォームでは1199元で掲載されています。ユーザーが「1500元以内のノイズキャンセリングヘッドホンのおすすめ」と尋ねると、システムは Feed 価格が予算超過のためスキップするかもしれませんし、公式ページで1299元を読んで推薦し、ランディング時に別の情報セットを表示するかもしれません。

対処法は3つあります。価格と在庫を1つのマスターデータソースに収束させること。価格と在庫に更新時刻を付与し、タイムスタンプに基づいてどのデータが有効かを決めること。公開前にクロスチャネルの一貫性検証を一度実行し、名称、価格、在庫、リンクの4種類のフィールドを項目ごとに比較することです。

バリエーションと仕様の整理方法

まず「1つの商品」を明確に定義してから、データについて語ります。多仕様商品には親子構造を推奨します。親商品はスタイルやシリーズを表し、子 SKU は具体的な色、容量、型番を表し、価格と在庫は子 SKU に紐づけます。属性名と単位は統一します。例えばバッテリー持続時間は「時間」、重量は「グラム」で統一し、同じパラメータが異なる商品で「約30h」「30時間程度」「1.2kg/1200g」と混在しないようにします。仕様はキーバリュー形式で記述し、長い説明文に詰め込みません。

商品画像と説明文の役割

説明文の最初の3行は、何であるか、誰に使うか、何の問題を解決するかを答えるべきで、その後に詳細を展開します。本当に効果的な書き方は、使用シーン、対象人群、制限を明確に書くことです。例えば「通勤や長距離フライトに適しており、アクティブノイズキャンセリングは低周波騒音に顕著な効果があるが、環境音の感知が必要なサイクリングシーンには適さない」といった具合です。キーワードの詰め込みは大規模モデルのマッチングではほとんど収益がなく、むしろ可読性を低下させます。画像については、メイン画像はクリーンでプロモーション文言を含まず、多角度画像と比率参照のあるシーン画像がサイズと形態の判断を助けます。

商品ページに構造化データは必要か

必要ですが、それだけに頼ってはいけません。商品ページは schema.org の Product、Offer を出力し、必要に応じて評価やよくある質問のマークアップを補足し、ページ上の価格、在庫が Feed と完全に対応していることを保証します。同時に、これらの情報が初期 HTML で取得可能であり、フロントエンドスクリプトのレンダリング後にのみ出現するものではないことを確認します。各商品には安定した長期的にアクセス可能な独立 URL が必要で、バリエーション間は正規リンクで区別し、すべてが同一アドレスを指さないようにします。

AI が異なる製品の違いをより正確に理解する方法

類似商品は最も混同されやすいものです。方法は差異を比較可能な尺度とブール属性に変換することです。3つのヘッドホンを同じパラメータ次元（ノイズキャンセリング深度、バッテリー持続時間、重量、Bluetooth バージョン、マルチポイント接続対応の有無）に置き、各製品に「誰に適さないか」を一言補足します。世代を跨ぐ製品は前世代との違いを明示的に書き、例えば「NC-700 は NC-600 と比較してバッテリー持続時間が増加し、重量が減少」とします。同名で異なる構成の型番は、必ずタイトルに区別識別子を含め、2つの異なる SKU が同じ名称を共有しないようにします。

価格と在庫の変更後の同期方法

同期は手作業の修正ではなく、チェーンを見る必要があります。第一に、価格と在庫の変更は統一的にバックエンドで商品マスターデータに書き込み、エクスポートファイルを直接変更してはいけません。第二に、マスターデータから対外的な商品 Feed とページ表示を生成し、両者は同じ書き込みから生まれます。第三に、更新頻度を区別します。価格と在庫は高頻度更新、説明と仕様は低頻度更新とし、全量再プッシュによる揺らぎを避けます。第四に、変更記録とロールバック能力を保持し、異常時には直前の安定バージョンに戻せるようにします。第五に、監視指標を設定します。例えばフィールド欠損率、クロスチャネル価格差異件数、最終更新時刻からの経過時間などです。

統一商品データソースの構築：5ステップの実践

1. 棚卸し：商品データが現在どこに存在するか（公式サイトバックエンド、ERP、表計算、各プラットフォームのセラーセンター）をリストアップし、どれが正確かをマークします。
2. モデリング：フィールド辞書を定義し、必須項目、型、単位、値の列挙を明確にします。
3. 書き込みの収束：書き込み入口を1つだけ残し、他のシステムはインターフェースを通じてデータを取得し、それぞれが1部を維持しないようにします。
4. マルチチャネルエクスポート：同じマスターデータから商品ページ表示、Feed ファイル、サードパーティプラットフォームデータを生成し、フィールドマッピングを集中的に維持します。
5. 検証と監視：公開前に比較、公開後に監視し、不一致を欠陥として処理し、運用の場当たり的な修正にしないようにします。

付随する意思決定チェックリストは次のように定められます。運用が直接価格を変更することを許可するか、バリエーションの分割粒度はどの層までか、在庫切れ商品を Feed に残すか、ポリシー条項は誰が維持するか、Feed プッシュ失敗時のフォールバック方案は何か。

企業が今すべきこと

• まずデータを直し、それからチャネルを語る。商品タイトル、カテゴリ、画像、価格、在庫の完全性を高めることが、すべての機械推薦シーンの前提です。
• 商品データを検索エンジンに見せるキーワード集合ではなく、機械が読む入力として扱う。シーン、人群、属性タグは同義語の積み重ねよりも有用です。
• 紹介元の測定を確立し、対話型入口からの訪問がコンバージョン率と客単価でどう表れるかを個別に観察してから、投資を決めます。
• 商品ページと Feed が同じマスターデータを共有し、一貫性をプロセスの制約にします。

We0 の EC 独立サイトは、商品、カテゴリ、仕様、在庫を同じバックエンドで維持し、CMS バックエンドで商品コンテンツを継続的に更新でき、フルスタックコード生成で必要に応じて商品データインターフェースと同期ロジックをカスタマイズでき、SEO と GEO 最適化で商品ページの情報構造を整理します（We0 EC 独立サイト）。注意すべきは、OpenAI 商品 Feed の直接接続は資格、エンドポイント、フィールドマッピングに関わり、依然として個別の検証と開発が必要であり、既に内蔵された能力と見なすことはできません。

よくある質問

ChatGPT は私の EC サイトを能動的にクロールしますか？
商品 Feed の経路は事業者が自ら構造化ファイルをプッシュするもので、クロールによるものではありません（仕様説明）。公開ウェブページ上の商品情報は検索・引用される可能性があるため、商品ページには事実を明確に書く必要があります。

商品名、価格、在庫は Feed と完全に一致させる必要がありますか？
必須です。Feed は商品データの単一の真実の情報源と定義されており、価格、在庫がランディングページと一致しないと推薦と注文体験に直接影響します。

製品仕様はどのような形式で整理すべきですか？
キーバリュー形式の技術パラメータを用い、属性名と単位を統一し、パラメータを長い段落に書き込まず、色ごとに独自のフィールドセットを捏造しないようにします。

構造化データだけでは不十分ですか？
不十分です。構造化データは機械が商品ページを正しく解析するのを助けますが、商品が候補プールに入れるかどうかは完全な商品 Feed を提出したかにも依存し、両者は同じマスターデータを共有する必要があります。

価格が変わったらどう同期しますか？
バックエンドから商品マスターデータに書き込み、マスターデータからページ表示と Feed ファイルを同時に生成し、更新時刻、変更記録、ロールバック方案を保持し、エクスポートファイルの手動変更を避けます。

関連ツール

• EC 独立サイトバックエンド：商品、カテゴリ、バリエーション、在庫を統合維持
• CMS バックエンド：商品説明、ポリシー、コンテンツページを継続更新
• フルスタックコード生成：商品データインターフェースと同期ロジックをカスタマイズ
• SEO と GEO 最適化：商品ページの情報構造と引用可能な段落を整理
• 構造化データ検証：Product と Offer のマークアップがページと一致するかチェック

関連リンク

• ChatGPT Product Feed 仕様説明（Lengow）
• ChatGPT ショッピングリサーチ機能の報道（中華網ソフトウェア）
• OpenAI が product feed 広告フォーマットを開始した報道（Stellagent）
• We0 EC 独立サイト

まとめ

ChatGPT が商品を推薦する際に読み取るのは構造化された商品の事実です。事業者がプッシュする商品 Feed が商品の候補プールへの参加を決め、公開解析可能な商品ページ情報が引用時の正確性を決めます。EC サイトがすべきはキーワード密度の最適化ではなく、名称、価格、在庫、バリエーション、仕様、画像、ポリシーを1つの統一マスターデータに収束させ、ページ表示と Feed を同時に生成し、検証と監視でクロスチャネルの一貫性を保証することです。Feed の直接接続と広告接続は独立した作業項目であり、プラットフォームの要件に従って個別に検証する必要があります。