AIエージェント向け商品フィードは、そのために作られたはずの決済ボタンよりも長く生き残りました。OpenAI と Stripe は 2025年9月下旬に Agentic Commerce Protocol を公開し、チャット内購入をそこに紐づけました。ところが 2026年3月、OpenAI はチャット内決済を終了し、フィードだけを残しました。これは些細な出来事ではありません。この標準のうち今もあなたに関係があるのは地味なほうの部分——AIアシスタントが、そもそもあなたの商品に触れるかどうかを決める前に読み込む、構造化された商品データの列だということです。
家具、金物、建材を扱っているなら、この仕様の中に記事一本分の価値がある一行があります。「サイズは合うのか」に答える項目が、任意扱いになっているという一行です。
ここに至るまでの4つの動き
| 時期 | 何が起きたか | 事業者にとっての意味 |
|---|---|---|
| 2025年9月下旬 | Stripe と OpenAI が Agentic Commerce Protocol を公開し、米国の Etsy 出品者と Shopify 事業者を皮切りに ChatGPT で Instant Checkout を開始 | 商品フィードの送信と、エージェント起点の決済接続という2つの作業が同時に発生 |
| 2025年後半から2026年初頭 | 買い物客はアシスタントで調べ、購入は事業者自身のサイトで行う流れが続き、チャット内購入の普及は伸び悩む | 発見のほうは機能していて、決済のほうは機能していない |
| 2026年3月 | OpenAI が Instant Checkout を終了し、ChatGPT 内の商品発見と小売事業者連携へ軸足を移す | 決済連携の緊急性が消える |
| 現在 | Product Feed Specification が、カタログとアシスタントをつなぐ接点として残る | フィードの品質がすべて |
この流れが示す教訓は、華やかさはないものの長持ちします。期限切れになったのは決済まわりの配管工事で、積み上がったのはデータのほうでした。
AIエージェント向け商品フィードとは何か
AIエージェント向け商品フィードとは、識別子、タイトル、説明、価格、在庫、メディア、配送情報、物理属性をまとめた、定期的に更新される機械可読なカタログファイルです。AIアシスタントはこれを取り込み、会話の中であなたの商品を提示し、絞り込み、比較します。サイトのクロール結果ではありませんし、ストアフロントの HTML でもありません。商品またはバリエーション1件につき1行の、こちらから引き渡すフラットファイルです。
仕組みとしては、現行仕様ではそのファイルは UTF-8 の区切りテキスト——.txt、.tsv、.csv、タブまたはカンマ区切り、gzip 可——で、小文字とアンダースコアで構成されたヘッダー行を持ちます。ファイル内のすべての URL は HTTP 200 を返す必要があります。事業者はまず検証用のサンプルフィードを送り、その後は日次スナップショットを送ります。システムは最短15分間隔の更新まで受け付けます。
この HTTP 200 の要件は、それだけで一拍置く価値があります。画像 URL が死んでいると、その行の順位が下がるのではなく、その行が無効になります。CDN のリンク切れは、アシスタントの回答から最も静かに消える方法です。
無視したときの代償で並べた項目一覧
これが現行仕様のおおまかな形です。重要なのは一覧そのものではなく、どの項目がどの階層に置かれているかです。
| 階層 | 項目 | 補足 |
|---|---|---|
| 必須 | item_id、title、description、url、brand、image_url、price、availability、seller_name、seller_url、target_countries、store_country、および is_eligible_search / is_eligible_checkout / is_ads_eligible のフラグ |
title は150文字、description は5,000文字、brand と seller_name は70文字が上限 |
| 条件付き必須 | identifier_exists を no にしていない限り gtin または mpn、予約注文と入荷待ちの availability_date、return_policy、決済を有効にしている場合は販売者のプライバシーポリシーと利用規約 |
識別子の欠落は、他のあらゆるフィード標準から持ち越された典型的な「黙って除外される」不具合 |
| 推奨 | group_id、listing_has_variations、variant_dict、size、size_system、q_and_a、reviews、relationship_type を伴う related_product_id |
relationship_type は part_of_set、required_part、often_bought_with、substitute、accessory といった値を取る |
| 任意 | dimensions、length、width、height、dimensions_unit、weight、item_weight_unit、material、condition、product_category、additional_image_urls、video_url、model_3d_url、return_rate、popularity_score、warning、age_restriction |
商品の物理的な情報はすべてこの階層にある |
最後の行をもう一度見てください。image_url は必須です。length、width、height、dimensions_unit は任意です。買い物客がアシスタントに投げる質問のうちほとんど何より多いもの——この部屋に、この車に、今使っている枠に収まるか——は、多くのフィードで空欄のままの項目に依存しています。
寸法の空白地帯が好機である理由
任意とは、無視されるという意味ではありません。強制されないという意味です。そしてフィードの経済学において、これは項目が取りうる最も面白い状態です。競合はみな省略してよく、実際ほとんどが省略します。数千 SKU に length / width / height / dimensions_unit を埋めるのは相応の手間で、しかも埋めなくても誰の決済エラーログにも何も出ないからです。
「アルコーブに入る幅80cm以下の本棚」と聞かれたアシスタントは、幅の値が存在して解析できる行しか候補に挙げられません。美しい写真があっても width が空の行は、その質問で順位が下がるのではなく、そもそも候補になりません。写真は代替になりません。あなたの JPEG を測るアシスタントはいないからです。
実務上の帰結は3つあります。
- 他の最適化より先に物理項目を埋める。
dimensionsは12x8x5 inのような短い文字列を取り、length、width、heightは個別の値を取ってdimensions_unitがinまたはcmを担います。データが許すなら複合形と個別項目の両方を埋めてください。読み手によって解析する項目が違います。 dimensions_unitを全行に明示する。 単位のない80は寸法ではありません。これは商品ページ自体でも起きる同じ失敗で、商品寸法の構造化データで扱っています。material、weight、item_weight_unitを同じブロックとして扱う。 素材は「突板ではなく無垢のオーク」で絞り込むための手がかりです。重量は、階段を一人で運べるかを気にする買い手が使う絞り込み条件です。
仕様にはさらに、パーセンテージで表す任意項目 return_rate があります。アシスタントがこのシグナルをどう扱うにせよ、それがスキーマに存在するという事実自体をよく考える価値があります。返品実績はいまや、社内だけの数値ではなく、構造化されて比較可能な商品属性になったということです。SKU 単位で返品がいくらのコストになっているかを数字にしたことがなければ、返品率計算ツールが最短の方法です。
フィードでは解決しないこと
フィードのデータは候補に残るところまで運んでくれます。しかし成約はしません。買い手は結局あなたのページに着地するからです。
その受け渡しの場所で、せっかくのフィード作業が静かに漏れていきます。アシスタントは「この棚は幅78cm」と伝える。買い物客がクリックした先の商品ページには、演出された部屋の写真だけがあって寸法はどこにもない。聞いた話を裏付けるものが何もない。よくある結末は2つです。手作業で答えるしかない購入前の問い合わせか、期待だけで買われてサイズ違いの返品として戻ってくる注文か。
このループを閉じるのはデータの仕事ではなく、見せ方の仕事です。つまり商品ページに、実測した寸法が商品そのものに描き込まれた画像を載せるということ——フィードで申告したのと同じ数字を、買い手がすでに見ている場所に出すということです。ここでは測定が決定論的であることが、かつてないほど重要になります。フィードの数字とあなたの画像の数字は、いまや機械同士で突き合わせ可能で、それらしい寸法を勝手に作り出す AI 生成画像は、自分の構造化データと公然と矛盾することになります。
効果の順に並べた次の一手
今四半期に本当に終えられる階層を1つ選んでください。全部に手をつけるより、1つを完全にやり切るほうが効きます。
- まず無効な行を洗い出す。 HTTP 200 を返さない
urlやimage_urlは、その行ごと落とします。半日で書けるスクリプトで済み、たいていは単発として最大の回復量になります。 - 識別子を直す。
gtinかmpnを埋めるか、identifier_existsを正直に設定します。黙って除外されるほうが、目に見えるエラーより厄介です。 - 物理ブロックを埋める。
length、width、height、dimensions_unit、weight、item_weight_unit、materialを、まず売れ筋 SKU から、その後は売上順に下へ。 - バリエーションを正しく構造化する。
group_id、listing_has_variations、variant_dictは、60cm 版と 80cm 版が同じ商品だとアシスタントに理解させ、収まるほうを提示させるための仕組みです。 - フィードの数字とページ画像を一致させる。 社内のデザイン工程でやるか、代理店に出すか、実測寸法を写真に固定して各プラットフォームの画像サイズで書き出すソフトを使うかは問いません。目的は同じで、アシスタントが引用した数字が、買い手を送り込む先のページ上で見えていることです。同じカタログを複数チャネルで販売しているなら、マルチプラットフォーム販売で示した進め方の順序がここでも当てはまります。
- そのあとで初めて
reviews、q_and_a、popularity_scoreなどの拡充階層を気にしてください。
よくある質問
Instant Checkout が終了した今も商品フィードは必要ですか
必要です。むしろ以前より必要になりました。フィードは連携の半分ではなく、連携のすべてになったからです。チャット内購入は 2026年3月に終了しましたが、商品発見は終了していません。アシスタントがあなたのカタログの存在を知る手段はフィードで、決済は引き続き自社サイトで行われます。
Agentic Commerce Protocol とは何ですか
Agentic Commerce Protocol は OpenAI と Stripe が共同で策定し、2025年9月下旬に公開したオープン仕様で、事業者が AI エージェントと商品データ、カート、注文情報をやり取りする方法を定めています。そのうち Product Feed Specification が、カタログの記述方法を規定する部分です。
AI ショッピングエージェントがサイズで絞り込むのに使う項目はどれですか
dimensions_unit を伴う length、width、height、複合文字列の dimensions、そして item_weight_unit を伴う weight です。いずれも仕様上は任意階層にあり、だからこそ多くのカタログはサイズで絞り込めません。そして、だからこそ埋めることが、フィード作業に残された数少ない安価な優位になります。
AIエージェント向け商品フィードはどれくらいの頻度で更新すべきですか
事業者はまず検証用のサンプルフィードを送り、その後は日次スナップショットを送ります。更新は最短15分間隔まで受け付けられます。実務上の基準は日次で、15分という上限は価格と在庫の変動のためにあり、変わっていないカタログを言い直すためにあるのではありません。
良い商品写真があれば寸法項目の欠落は補えますか
補えません。そして、これは真っ先に捨てるべき思い込みです。写真は人間向けに描画されるもので、候補に残るかどうかを決める絞り込みはテキスト項目の上で行われます。マッチングを行う仕組みは写真を測れません。写真にできるのは、項目がすでに主張した内容を人間に対して確認させることだけです。