2026年7月、ChatGPTのショッピング推薦は主要な情報源を切り替えました。カタログデータがその変化に対応していなければ、商品ページの最適化をどれだけ積んでも埋め合わせはできません。このワークフローは、カタログを検証済みで提出可能な状態まで持っていくものです。今日フィードを提出できるかどうかに関わらず機能します。
対象読者 | おおむね500〜100,000 SKUの商品データを担当するEコマースSEO担当者、フィード担当者、マーチャントオペレーション責任者 |
成果物 | 9つの必須フィールド検査をすべて通過した検証済みの商品ファイルと、ブロックされたSKUを担当者名つきでまとめた例外リスト |
前提条件 | カタログをCSV、TSV、またはJSONLでエクスポートできること。ステージング用ディレクトリ。 |
アクセス前提 | 今日フィードを提出できない可能性があります。OpenAIのフィードプログラムは限定公開で、チェックアウトは別途有効化が必要な連携、標準アップロードは現在US向けです。それでもこのワークフローはファイルを完成させます |
所要時間 | 5,000 SKU未満のカタログなら初回で4〜6時間。時間がかかるのは技術的なセットアップではなくフィールド監査です |
完了の定義 | すべての行が9つの必須フィールド検査を通過し、スキップしたSKUはすべて担当者名つきの例外リストに載り、OpenAIの検索クローラーがサンプルの商品URLを取得して実際のデータを読み取れ、その実行が保存済みエクスポートから再現できる |
何が変わり、それによって強いられる1つの判断
OpenAIは2026年7月9日にChatGPT 5.6モデルをリリースしました。その翌日、ChatGPTショッピングの推薦のうちオープンなウェブ検索ではなくマーチャントの商品フィードから引かれる割合が、8.26%から61.54%へ跳ね上がりました。これはProfoundが公表した調査によるもので、同社は2026年7月中のChatGPTショッピングプロンプト1,757,723件を追跡しています。わずか1日で、フィード連携による取得は少数派の情報源から支配的な情報源へと変わりました。
この数字は第三者による測定であり、OpenAIの開示ではありません。OpenAIは7月10日の変更を確認しておらず、取得比率も一切公表していません。何がデータで支持され何が支持されないかは、この記事の終盤のセクションで整理しています。方向性は真剣に受け止め、精度は緩くとらえてください。
この方向性が強いるのは、1つの発想の転換です。商品データは、コンテンツとしてだけでなく、データとして正しくなければならなくなった。 美しく書かれた商品ページでも、GTINのチェックディジットが欠けていれば、フィードベースの推薦エンジンにとっては検証に失敗した1行です。
以下はすべてワークフローです。7月10日の数字が持ちこたえるかどうかに関わらず、ここにある各ステップには取り組む価値があります。クリーンで完全な、機械可読なカタログは、これから関わるあらゆるショッピング面で役に立つからです。
自分がどのレーンにいるかを見極める
このワークフローは2つのレーンに分かれます。「完了」の意味がレーンによって変わるので、始める前に自分のレーンを知る必要があります。レーンAは取り込みを証明できます。レーンBが証明できるのは準備完了までです。どちらも同じファイルを生み出します。
4項目のアクセス判定
それぞれに正直に答えてください。
質問 | 「はい」と数えられるもの | 数えられないもの |
|---|---|---|
OpenAIに登録し、フィードアクセスの書面による確認を受け取りましたか？ | あなたのフィードを名指しした確認 | 「興味ありフォームを出した」 |
あなたのカタログはUS市場の対象ですか？ | 現在の標準アップロード範囲で対象であることの確認 | 自分の市場にも当てはまるという思い込み |
チェックアウト連携が別途有効化されましたか？ | オンボーディング時の明示的な確認 | 自分でフラグをオンにすること |
サンプルまたは完全なファイルを提出し、受理の応答を受け取りましたか？ | あなたの提出物に言及した応答 | 送ったが何も返ってこない |
どれか1つでも「指し示せるもの」に裏付けられていなければ、あなたはレーンBです。これは既定の位置であり、失敗状態ではありません。重要な補足が2つあります。適格性フラグを有効にしてもチェックアウトのオンボーディングは完了せず、登録で得られるのはマーチャント表示名だけで、フィードのその他の部分は得られません。
レーンA：フィードアクセスが確認済みの場合
登録固有のフィールドリストと、オンボーディングで確認された提出チャネルが渡されます。提出の仕組みそのものはオンボーディングで確認されます。 SFTPなのか、許可リストに載ったエンドポイントへの暗号化HTTPSプッシュなのか、公開されているベンダー各社の説明は一致していません。OpenAIからどちらが自分に当てはまると告げられるまで、どちらの説明に沿ってパイプラインを組まないでください。
レーンB：まだ持っていない場合、そして無駄にならないもの
今日、許可を必要とせずに開かれているものが3つあります。クローラーのアクセス、商品ページ自体の構造化データと説明文の品質、そして検証済みファイルです。この記事の中盤にあるカタログ作業には一切のゲートがありません。今のうちにファイルを作って検証し、アクセスが来た日にすでに通過するものを提出します。
Shopifyを使っている場合、商品データはShopify Catalog経由で追加のマーチャント側作業なしにChatGPTへ届きます。直接フィードが必要になるのは、鮮度と、既定では運ばれないフィールドのためです。注意点が1つあります。ある二次情報源はこの連携を2026年3月としていますが、その日付は未確認なので、計画の前提ではなく会話のきっかけとして扱ってください。
あなたの商品を読むクローラーのために扉を開ける
これは両方のレーンで即座に効く最初のステップであり、最も安く手に入る成果です。
robots.txt を開き、OpenAIのエージェント向けのディレクティブを確認してください。商品の可視性で重要なのは OAI-SearchBot です。これがブロックされていると、フィードがどれだけクリーンでもChatGPTの商品結果にあなたのコンテンツは表示されません。モデルの学習には使われないので、ブロックしても何も守れません。
明示的に判断すべきエージェント名は4つです。
エージェント | 役割 | 商品可視性への影響 |
|---|---|---|
| 検索面のためにコンテンツをインデックスする | ブロックするとフィード品質に関わらず商品が隠れる |
| ユーザーが明示的に尋ねたページを取得する | ブロックするとライブのページ読み取りが壊れる |
| 学習用クローラー | ショッピングの可視性とは無関係 |
| エージェント型ブラウジング | エージェント経由のチェックアウト経路に影響 |
ここで最も重要な品質チェックは `robots.txt` ではありません。 許可されたクローラーが実際に到着して何かを読めるかどうかです。クローラーのユーザーエージェントで代表的な商品URLを取得し、レスポンスボディを検査してください。サーバーレンダリングされたタイトル、価格、在庫状況、説明文のないアプリシェルしか返ってこないなら、クロールは成功して何も有益なものを返していません。多くのストアフロントは商品データをクライアント側でのみレンダリングしており、そうした店舗はロボットファイルに何と書かれていようと、フィードなしの発見経路からは見えません。
このチェックはAuspiaのOpenAI search crawler simulatorで実行できます。OpenAIのクローラーとして公開ページを取得し、何を読めるかを表示します。
復旧手順。 robots.txt がプラットフォームや代理店によってロックされている場合は、変更依頼を日付つきで記録し、先へ進んでください。このステップはブロッカーではなく、レーンBの記録のための証拠になります。
商品ページを機械可読にする
フィードはショッピング推薦への唯一の経路ではなく、レーンBのマーチャントにとっては現在そもそも利用できません。ページ上の構造化データは利用できます。
すべての商品テンプレートにJSON-LDで Product 構造化データを追加し、それをカタログのエクスポートと同じ情報源から生成してください。後半のこの条件が、チームが見落とす部分です。スキーマがテーマ内で手作業で保守され、フィードはPIMから来ていると、両者は四半期のうちに食い違い、価格と在庫状況のシグナルが食い違うのは、存在しないより悪いことです。
最低限、name、description、image、SKU、brand、そしてprice、price currency、availabilityを持つ offers ブロックを含めてください。フィードに入れるのと同じ値を反映させます。カタログにGTIN、condition、material、color、size、dimensionsがあればそれらも含めてください。これらは会話的なクエリが実際に使う属性だからです。
品質チェック。 最も性格の異なるカテゴリから1つずつ、商品URLを3つ選び、ログイン済みブラウザではなくクローラーが見るのと同じレンダリング経路で検証してください。
復旧手順。 プラットフォームが商品テンプレートへのJSON-LD注入を許さない場合は、タグマネージャ経由でheadに入れ、技術的負債として記録してください。動きますが壊れやすく、誰かが外す責任を持つべきです。
会話的なクエリのために説明文を書き直す
これはSEOの規律が積極的にあなたを傷つけるステップです。
カタログの説明文は通常、キーワードの網羅と棚での訴求のために書かれます。ブランドの語り口、キーワードを詰め込んだタイトル、訴求点の箇条書き。会話的なショッピングクエリはそれとは似ても似つきません。誰かが「オープンプランのオフィス向けで150ドル以下の静かなメカニカルキーボード」と尋ね、その問いに答える属性は騒音レベル、スイッチの種類、フォームファクタです。それらの属性は、抽出可能であるために存在しかつ事実でなければなりません。
商品説明は、短い人間向けの書き出しを伴う事実の仕様として書いてください。その商品が何で誰に向くかを1文で述べます。そのうえで属性を、マーケティングの修飾語なしに端的に示します。「重量: 780 g」は「驚くほど軽量な設計」に勝ります。主張をするなら、具体的で検証可能にしてください。
ここに大きく投資する前に1つ知っておくべきことがあります。OpenAIのショッピングに関するドキュメントは、ChatGPTが簡略化した商品タイトルと説明文を生成する場合があると述べています。あなたのコピーは推薦への入力であり、保証された出力ではありません。クリーンで事実に基づくソースデータを書き、表面がそれを言い換える可能性を受け入れてください。
品質チェック。 売上上位10商品を選び、それぞれについて購入者が判断に必要とする4つの属性を書き出してください。3つ未満しか説明文に現れないなら、その説明文は役割を果たしていません。
復旧手順。 説明文が自分でコントロールできないサプライヤーフィードから来ている場合は、売上上位1割を手作業で書き直し、ロングテールは後から追わせてください。部分的なカバレッジは、停滞したプロジェクトに勝ります。
1行に触れる前にフィールドの契約を書く
ここからがフィード本体です。何かをエクスポートする前に、「正しい」とは何かを一度だけ書き下してください。これで監査が議論ではなく機械的な処理になります。
9つの必須フィールドと、それぞれがどこで壊れるか
すべての行にこの9つが必要です。この表が契約です。
フィールド | 受け入れられる形式 | 最も多い失敗 | 結果 |
|---|---|---|---|
| 商品またはバリアントごとの安定した一意の文字列 | バリアント間で使い回す、またはエクスポートごとに再生成する | 重複行と孤立行 |
| プレーンな文字列、150文字以下を目安 | 単語の途中での切り詰め、または価格を含むタイトル | 行の拒否または誤マッチ |
| プレーンテキスト、最大5,000文字 | CMSから残ったHTMLやmarkdown | 行の拒否 |
| 商品ページのURL | トラッキングパラメータ、またはリダイレクトするURL | 行が何も解決しない |
| ブランド名の文字列 | ノーブランドSKUで完全に欠落 | 行の拒否 |
| マーチャント名の文字列 | カタログ全体での表記ゆれ | マーチャントシグナルが弱い |
| 画像への直接URL | プレースホルダ、またはセッションを要求するURL | ビジュアルのない行 |
|
| 社内在庫語彙からの独自の値 | 行の拒否 |
|
| 桁区切り、または通貨のない裸の数値 | 行の拒否 |
2つの項目は、静かに失敗して商品ライン全体を巻き込むため、強調に値します。
availability フィールドが受け入れる値はちょうど5つです。省略、空、または認識されない値は行を拒否します。プラットフォームが IN STOCK や available や 1 をエクスポートするなら、それらの行はすべて失敗します。社内の語彙を5つの受け入れ値に明示的にマッピングし、マッピングできないものは unknown に既定せず手動キューのほうへ流してください。unknown は合法な値ですが、意図的な状態であり、何でも入る受け皿ではありません。
price フィールドは 金額、空白、そして大文字の通貨コードです。つまり 79.99 USD であり、$79.99 でも、79,99 USD でも、7.999e1 でもありません。桁区切りも指数表記もなしです。
静かに行を拒否するルール
検証チェックに書き入れる価値のある制約がさらに4つあります。
GTIN。 有効なチェックディジットを含め、ちょうど8、12、13、または14桁。ISBN-10は受け入れられません。先頭のゼロを保持してください。つまり、それが通るすべての場所で列をテキストとして保つということです。これは仕様全体で最も多い静かな破壊要因です。表計算ソフトとCSVエクスポートは既定で先頭のゼロを落とすからです。
セール価格。 ゼロより大きく、同じ通貨で通常価格より厳密に小さいこと。セール価格が通常価格と等しい、または通常価格を空のままにしたプロモ行は失敗します。
タイトル長。 150文字以下を目安に。切り詰めるときは単語の境界で切ってください。
日付フィールドは何もスケジュールしません。 仕様は、契約内の日付が価格や在庫状況の変更をスケジュールしないことを明示しています。深夜にプロモーションを切り替えたいなら、パイプラインが新しい値をプッシュしなければなりません。
適格性フラグを意図的に決める
3つのフラグが、行が検証を通った後に何が起きるかを制御します。
フラグ | 省略または空のときの既定 | 役割 |
|---|---|---|
|
|
|
| 検索適格性が必要 |
|
| 無効 | 別系統の広告処理経路を制御する |
これらが enable_search、enable_checkout、is_eligible_ads として現れることもあります。別名なので、古い綴りを使うテンプレートを別のフィールドとして扱わないでください。
実務的な助言です。is_eligible_search は、商品が販売終了または非表示であることをすでに知っているシステムに同期させてください。別の「チャネルから隠す」リストを運用していてそれがフィードに届かないなら、古い掲載を推薦へ送り込むことになります。
どのオプショングループを、どの順で有効にするか
オプションフィールドはおおよそ50あります。仕様の順ではなく、作業1時間あたりの見返り順に並べます。
- バリアント（
group_id、listing_has_variations、variant_dict、offer_id、gtin、mpn）。アパレル、靴、ホーム、サイズや色のあるものを売っているなら最優先です。 - 商品情報（
condition、product_category、material、color、size、gender、age_group、および寸法と重量のフィールド）。これが会話的なマッチングを機能させます。 - メディア（
additional_image_urls）。 - 返品（
accepts_returns、return_deadline_in_days、return_policy）。 - レビュー（
review_count、star_rating）、加えてストアレベルのstore_review_countとstore_star_rating。 - フルフィルメント、マーチャント、地域（
shipping_price、shipping、seller_url、target_countries、store_country）。 - セットアップ時に限定されるフィールド。
marketplace_seller、size_system、accepts_exchanges、is_digital、広告のペア（is_ads_eligible、ads_metadata）、チェックアウトのペア（is_eligible_checkout、seller_privacy_policy、seller_tos）はすべてオンボーディング時の確認が必要です。セルフサービスではありません。初回のパスからは外しておいてください。
品質チェック。 9つの必須フィールドすべてが、SKUの少なくとも95%で実データに解決するカタログ列にマッピングされるべきです。その閾値を下回るフィールドはマッピングのタスクではなく、調達の判断です。
復旧手順。 必須フィールドに情報源がまったくない場合、例えばノーブランドのラインナップにおける brand なら、止まってファイルを作る前にビジネスオーナーと調達の問いを決着させてください。書式の作業では存在しないデータを直せません。
実際に送ることが許されるファイル形式
オンボーディングで登録済みフィードに対してOpenAIが確認した形式を使ってください。それとは別に、UTF-8のタブ区切り .txt または .tsv、あるいはカンマ区切り .csv を受け入れ、.txt.gz、.txt.gzip、.tsv.gz、.csv.gz のgzipをサポートするGoogle互換の経路があります。
JSON、表計算、XML、RSS、Atomはその互換経路ではサポートされていません。行ごとに形式を混ぜず、アップロード全体で1つの形式を使ってください。
最も多くの行を壊す4つのフィールドを正規化する
凍結したエクスポートを1つ取り出す
一度だけエクスポートし、ファイルにタイムスタンプを付け、ハッシュを計算します。以降のすべてのステップはその凍結ファイルに対して実行します。再現性があることで、3週間後に誰かが「なぜこのSKUが欠けているのか」と尋ねたとき、監査が弁明可能になります。
4つの正規化
GTINの先頭ゼロ。 列をテキストとしてエクスポートし、桁数が8、12、13、14のいずれかであることと、チェックディジットを検証します。静かな失敗の大多数はここに住んでいます。
価格の書式。 桁区切りを外し、小数点は残し、指数表記を取り除き、通貨コードを別トークンとして付加します。結果を ^\d+\.\d{2} [A-Z]{3}$ のみを受け入れる正規表現に通し、残りはキューに入れます。
在庫状況のマッピング。 社内の語彙を5つの受け入れ値へ明示的にマッピングします。各バケットに何行落ちたか、何行が手動レビューに落ちたかを数えます。手動レビューが多いということは、フィードが壊れているのではなく在庫語彙にマッピングテーブルが必要だということです。
タイトルと説明文のクリーンアップ。 タイトルは150文字で単語境界で切り詰めます。説明文からマークアップを外し、プレーンテキストで5,000文字に上限を設けます。
品質チェック。 正規化したファイルを新しい表計算に再取り込みし、GTIN列がまだ先頭ゼロを表示していることを確認します。これで、他のあらゆるチェックをすり抜ける数値エクスポートの罠を捕まえられます。
復旧手順。 フィードプラットフォームやPIMがこれらの正規化を行っているなら、成功メッセージを信じるのではなく、同じチェックでその出力を検証してください。
すべての行を監査し、例外リストを保つ
ここでファイル全体に対してチェックを走らせます。これはカタログを作業計画に変えるステップです。
バリデータなしで確認できる9つの機械的検査
すべての行について。9つの必須フィールドがすべて存在し空でないこと。availability が5値の列挙にあること。gtin の桁数とチェックディジットが有効であること。price が金額と通貨の形に一致すること。sale_price が price より厳密に小さくゼロより大きく、同じ通貨であること。title が150文字以下であること。description がプレーンテキストで5,000文字以下であること。url が200を返しサーバー側で商品データをレンダリングすること。image_url がプレースホルダではなく実際の画像に解決すること。
1つの行はすべてのゲートを通過するか、失敗したゲート名とともに例外ファイルへ落ちるかのどちらかです。最も多く行を拒否するのはavailabilityのゲートです。独自の在庫語彙がカタログが失敗する最も一般的な理由だからです。
完璧なカタログではなく例外ファイルを作る
2つの列と担当者1名。item_id、ブロッカー、そして誰が直すか。
品質チェック。 そこそこ整理されたカタログなら、例外ファイルは行の10%未満であるべきです。30%を超えるなら、問題は上流のデータガバナンスであり、ファイルにパッチを当てるのではなくソースシステムを直すのが誠実な一手です。
復旧手順。 必須フィールドが散発的なSKUではなくカテゴリ全体で欠けているなら、ビジネスオーナーを伴う調達の判断として扱ってください。監査を通すためにそれらの行を unknown にしないでください。unknown は特定の意味を持つ正規の値であり、チェックを通すために使うと自分のデータを汚染します。
更新についての正直な補足です。仕様は更新頻度を述べておらず、フィードが完全なスナップショットなのか増分更新なのかも述べていません。公開されているベンダーの説明はどちらについても自信をもって主張していますが、それはOpenAIのドキュメントにはありません。仕様が実際に指示しているのは、現在の価格を提出すること、セールが始まるか終わるときに更新すること、商品が売り切れるか戻ってきたときに在庫状況を更新することです。パイプラインはこの2つのイベントを軸に組み、更新頻度の問いはオンボーディングで確認してください。
プラットフォームと同じやり方でファイルを検証する
提出するつもりの正確なバイト列を、提出するつもりの形式で再パースし、入った行と出た行を数えます。
これで、表計算が隠してしまう失敗を捕まえられます。Excelで綺麗に開くファイルは、CSVとしてパースされるファイルと同じではありません。エスケープされていない区切り文字や説明文フィールド内の改行は、画面上は問題なく見えながらパースを壊すからです。
品質チェック。 入った行数と出た行数が等しく、自動チェックが手作業の監査と一致すること。両者に差があるならどちらかが間違っており、たいていは手作業の側です。
復旧手順。 エンコーディングの失敗はほぼ常にUTF-8で再エクスポートすれば解決します。クォートの失敗はほぼ常にエスケープされていない区切り文字か、説明文内の余分な改行です。
チームにコーディングエージェントがあるなら、ここが小さなスクリプトが元を取る唯一の場所です。監査を四半期ごとのプロジェクトから再実行へと変えるからです。
うまくいったことを検証する
何を証明できるかはレーンによって変わります。曖昧にせず、その違いについて正確である価値があります。
レーンAは取り込みを証明できます。レーンBは準備完了を証明できます。レーンも分岐もファイルを変えません。それが、アクセスを得る前にファイルを作る意味です。
アクセスがある場合（レーンA）
4つのチェック。提出が受理された。行レベルの拒否レポートを読み、すべての拒否を解決または記録した。サンプルのショッピングプロンプトがあなたの商品の1つを表示するようになった。サーバーログが商品URLを取得する取得エージェントを示している。
ない場合（レーンB）
4つのチェック。robots.txt の取得が OAI-SearchBot に商品URLを返す。そのURLのサーバーレンダリング取得にタイトル、価格、在庫状況、説明文が含まれる。9項目の監査が通る。凍結したエクスポートとチェックの実行が、次の人が再現できる場所に保存されている。
準備完了は本物の、反証可能な成果です。ただしまったく同じ成果が取り込みだというわけではなく、そうであるかのように報告すべきでもありません。
最後に重要な1つの数字
ChatGPTからの外部リンクには utm_source=chatgpt.com が自動で付きます。つまり、クリックが起きたことのファーストパーティの証明は自分のアナリティクスだけです。必要になる前に、今すぐフィルタを設定してください。
それが何を測っているのかを明確にしてください。クリックによるトラフィックの帰属であり、可視性の指標ではありません。商品は何度も推薦されて一度もクリックされないことがあり、適格でない商品はそもそもクリックされようがありません。
このワークフローが制御しないもの
フィードセット内の順位は制御しません。 仕様が定義するのは行の契約です。並び順のルールは定義していません。すべてのフィールド検査を通過することは、その商品が取得される適格性を得ることを意味します。適合した10行のうちどれが表示されるかについては何も述べていません。冒頭で引用した調査が測っているのは取得元であり、取得された集合内の順位ではありません。
7月10日の数字は観測値であり、1社のベンダーによるものです。 それらは実際の買い物セッションや購入経路ではなく、Profoundの追跡プロンプトパネルを記述しています。OpenAIはその変更を確認しておらず、取得比率も開示していません。2026年9月3日にGPT-6 Astraの展開が始まっており、それはこの調査の後半の測定ウィンドウと重なっており、紛れもない交絡要因です。
集中度の数字も同じ制約を抱えています。トップ10ストアの参照が22.5%から41.8%へ上昇したこと、ユニークマーチャント数が13,524から10,607へ減少したことは、どちらも同じパネルから来ています。そして取得元の変化が517の変動顧客にわたる可視性の変動の83%を説明したという知見は、そのパネル内での説明割合であり、計画の前提にすべき因果係数ではありません。
ベンダーブログに出回っている主張のいくつかは仕様にありません。 以下はそれぞれ慎重に扱ってください。
主張 | 出典 | 状態 |
|---|---|---|
フィードは15分ごとに更新され、日次フィードより96倍頻繁 | ベンダーブログ | OpenAIの仕様にはなく、仕様は更新頻度を述べていない |
フィードは増分更新ではなく完全なスナップショット | OpenAIのドキュメントを引用していない1社のベンダー | 未解決。オンボーディングで確認 |
約100商品のサンプルが必要 | ベンダーブログ | OpenAIのヘルプ文は数量に触れず、初回のサンプルまたは完全なフィードに言及 |
提出はSFTP経由 | 1社。別の1社は暗号化HTTPSプッシュと述べる | 出典が矛盾。仕組みはオンボーディングで確認される |
| 集約された1つの出典 | 仕様のフィールドリストにない。仕様のレビューフィールドは |
構造化フィードはスクレイピングデータより約2倍コンバージョンする | 出典のないベンダーの主張 | 前提にしないこと |
あなたのコピーがどう描画されるかは制御しません。 ChatGPTは簡略化した商品タイトルと説明文を生成する場合があります。また、ショッピング結果はChatGPTによって独立に選択され、広告ではありません。これは取得元ではなく商業的な影響についての問いに答えるものです。有料掲載を求めているなら、OpenAIは商品フィードから構築される別の広告経路を運用しています。それは別のワークフローであり、この記事の対象ではありません。
FAQ
今日ChatGPTに商品フィードを提出できますか？
オンデマンドではできません。アクセスはマーチャントごとに確認され、チェックアウトには別途有効化が必要な連携が要り、標準アップロードは現在US向けです。登録で得られるのはマーチャント表示名だけで、ライブのアップロードアクセスなしに登録済みであることはあり得ます。上記の4項目のアクセス判定を実行して自分の位置を確かめてください。
フィードはどのくらいの頻度で更新すべきですか？
仕様は更新頻度を述べていません。2つのベンダーブログが15分と主張していますが、その数字はOpenAIのドキュメントには現れません。実務的な答えは、仕様が明示的に最新に保つよう指示している2つ、つまり価格と在庫状況のイベントを軸に更新を駆動することです。
完全なファイルを送るのか、変更された行だけを送るのか？
未解決です。1社のベンダーが完全なスナップショットだと主張し、その根拠としてOpenAIのドキュメントを引用していません。どちらの答えにも依存するパイプラインを組む前に、オンボーディングで確認してください。
100商品のサンプル要件は本当ですか？
OpenAIのヘルプ文は数量を添えずに初回のサンプルまたは完全なフィード提出に言及しています。100商品という数字はベンダーブログから来ています。サンプルを用意するなら、特定の件数を狙うのではなく各オプショングループのケースを網羅して代表的なものにしてください。
良いフィードはChatGPTのショッピング結果で商品の順位を上げますか？
通常その質問が含意する意味では、いいえ。フィードは商品を適格で記述可能にします。取得された集合内の順位は文書化されておらず、公開されている調査が測っているのは並び順ではなく取得元です。フィールドの適合は前提条件として扱い、てことしては扱わないでください。
Shopifyで売っている場合、これは必要ですか？
基本的な連携には不要です。商品データはマーチャント側の作業なしにShopify Catalog経由でChatGPTへ届きます。直接フィードが必要になるのは、鮮度と、既定では運ばれないフィールドのためです。
著者: Eva Laurent、Auspiaで1万以上の商品ページを担当するEコマース検索ストラテジスト。Eコマース検索、商品ディスカバリー、そして商品データがAIショッピング面にどう届くかを執筆しています。
