CodeGym /コース /ChatGPT Apps /Product Feed: 目的、データモデル、主要フィールド、ポリシー

Product Feed: 目的、データモデル、主要フィールド、ポリシー

ChatGPT Apps

レベル 14 , レッスン 1

使用可能

1. なぜ Product Feed が必要なのか

従来型の e‑commerce と比べると、Product Feed は次の中間に位置します。

商品の「ショーケース」（価格・在庫・リンク・メディア付きのカタログ）；
ChatGPT 経由で表示・販売してよい SKU を定義する技術的な契約。

OpenAI の仕様では、feed は検索・レコメンデーション・チェックアウト準備が依拠する唯一の真実の情報源と明示されています。

通常のオンラインストアでは、ユーザーが自分でページを移動し、カテゴリをめくり、フィルタします。AI‑commerce では逆で、ユーザーはモデルに「ボードゲームが好きなエンジニアの友人向けに、30ドル以内のデジタルギフトを選んで」と言うだけで、ChatGPT があなたの Product Feed からどの SKU が適しているか、どの順序で見せるか、カード表示や Instant Checkout までを判断します。

したがって Product Feed は複数の役割を同時に果たします。

第一に、ChatGPT に検索用の構造化データを提供します。モデルは商品名や説明だけでなく、カテゴリ、タグ、価格、在庫、ロケール、国・地域制限にも依拠します。

第二に、チェックアウトのデータソースとして機能します。 ChatGPT が checkout_session を用意するとき、SKU の ID、価格、通貨、seller URL などの商用情報はフィードから取得されます。

そして最後に、Product Feed はプラットフォームとあなたとの間の正式な契約です。あなたは明示的に「これが SKU の一覧で、これらは検索（discovery）のみ、これらは Instant Checkout まで可能」と伝えます。

これを可視化するために簡単な図を描きます。

flowchart TD
  A[GiftGenius DB] --> B[Feed Builder]
  B --> C["Product Feed (CSV/JSON/...)"]
  C --> D[OpenAI Ingestion]
  D --> E[検索インデックス + ランキング]
  E --> F[ChatGPT/Agent がギフトを選定]
  F --> G["Instant Checkout (ACP)"]

左はあなたの内部データベース（本物のカタログ）。右はユーザーに見せる ChatGPT。中央が Product Feed とその取り込み・インデックス機構です。本講義で扱うのは A と D のちょうど間の領域です。

2. Product Feed のフォーマットと「物理」

OpenAI の仕様はファイル形式に柔軟で、TSV・CSV・XML・JSON をサポートします。これは、既存システム（自社モノリスから Shopify まで）の多くがフィードを無理なくエクスポートできるようにするためです。

典型的な流れは次のとおりです。

自社の HTTPS サーバーに Product Feed のファイルまたはエンドポイントを設置する；
その URL を ChatGPT Merchants ポータルに登録する；
OpenAI が定期的に取得・検証して商品をインデックスする。

ドキュメントではフィードの定期更新（10〜15分ごとでも可）が求められています。特にセールやピーク時には、最新の価格と在庫をユーザーに見せるためです。

学習用の GiftGenius では JSON を使います。TypeScript 開発者に馴染みがよいからです。ただし仕様レベルで OpenAI が JSON に固定されているわけではありません。今回は都合がよいというだけです。

最小の JSON フィードは次のようになります。

[
  {
    "id": "gg-coffee-sub-1m-usd",
    "title": "1カ月のコーヒーサブスクリプション",
    "description": "エンジニア向けの月替わりコーヒー豆ボックス。",
    "price": 2900,
    "currency": "usd",
    "availability": "in_stock",
    "link": "https://giftgenius.app/gifts/coffee-subscription-1m",
    "image_link": "https://cdn.giftgenius.app/images/coffee-1m.png",
    "enable_search": true,
    "enable_checkout": true
  }
]

実際にはフィールドはもっと多く、必須、推奨、任意に分かれます。どのように整理されているかは後述します。

3. 製品 vs バリアント（SKU）: どうモデリングするか

よくある質問のひとつが「1 つの製品にサイズ・パッケージ・サブスク期間などのバリアントがある場合、Product Feed ではどう表現するのか？」です。

Product Feed の仕様では各行（レコード）が販売可能な 1 つの構成を表します。業界が推奨し（OpenAI のフィードとも相性がよい）アーキテクチャパターンはこうです。サイズ、サブスク期間、プラン、地域などそれぞれの構成はフィードの別レコード、つまり別 SKU として扱う。

基礎となる「製品」は自社の内部モデルに存在し、フィードでは SKU レベルで扱います。

例えばサービスがあり、1・3・6カ月のサブスクリプションがあるとします。product feed の観点ではこれらはすべて別の SKU です。1 つのサービスを 20 通りの条件で購入できるなら、product feed には 20 個の SKU があるべきです。

TypeScript では次のように表せます。

// 自社（GiftGenius）の内部モデル
export interface GiftProduct {
  id: string;              // product_123
  name: string;
  description: string;
  baseImageUrl: string;
}

// Product Feed に出す SKU
export interface GiftSkuFeedItem {
  id: string;              // product_123_usd_1m
  productId: string;       // GiftProduct.id への参照
  title: string;
  description: string;
  price: number;           // 最小単位（セント）で
  currency: string;        // "usd"
}

GiftGenius 内部では GiftProduct と GiftSkuFeedItem が 1 対多で結ばれるかもしれません。フィード側は「フラットな」SKU リストを返します。

ChatGPT が同一製品に属する SKU（例：1・3・12カ月のサブスク）を理解できるよう、しばしば item_group_id のようなグルーピング用のフィールドを使います。これはパターンであって、厳密な必須要件ではありません。

例:

{
  "id": "gg-coffee-sub-1m-usd",                // 1カ月のサブスクリプションの SKU
  "item_group_id": "gg-coffee-sub",            // あなたの製品
  "title": "コーヒーのサブスクリプション — 1カ月",
  "price": 2900,
  "currency": "usd",
  "enable_search": true,
  "enable_checkout": true
}

3カ月のサブスクリプションでは:

{
  "id": "gg-coffee-sub-3m-usd",                // 3カ月のサブスクリプションの SKU
  "item_group_id": "gg-coffee-sub",            // 同じ製品 ID
  "title": "コーヒーのサブスクリプション — 3カ月",
  "price": 7900,
  "currency": "usd",
  "enable_search": true,
  "enable_checkout": true
}

このアプローチはモデルにもバックエンドにも優しい設計です。SKU の ID が一意キーとなり、ユーザーが購入した正確な構成を常に特定できます。

4. Product Feed の必須フィールドと UX への影響

OpenAI の Product Feed 仕様はフィールドを大まかに必須（required）、推奨（recommended）、任意（optional）に分けています。

具体的な名称・一覧は常に最新ドキュメントを参照すべきですが、学習用に次の「最小セット」を土台にできます。

フィールド	目的	欠如した場合の影響
`id`	マーチャント内で一意な SKU 識別子	商品を一意に特定できない
`title`	カード用の短い名称	モデルが商品を理解しにくい
`description`	詳細説明	回答が一般的になり、パーソナライズが弱まる
`price`	最小単位での価格	チェックアウトを準備できない
`currency`	ISO 4217 の通貨コード。通常は小文字	プラットフォームが通貨を解釈できない
`link`	マーチャント側の商品ページの URL	ユーザーがサイトへ遷移できない
`availability`	在庫ステータス（in_stock、out_of_stock など）	在庫切れの商品が表示されうる
`enable_search`	検索に利用してよいか	true でなければ検索結果に出ない
`enable_checkout`	Instant Checkout で購入可能か	discovery/link‑out のみになる

重要な点：enable_search と enable_checkout はロジック上別モードを表します。

enable_search が = true、かつ enable_checkout が = false の場合、商品は検索結果に出ますが、購入しようとするとユーザーはあなたのリンク（link）で自社サイトへ遷移し、ChatGPT 内の Instant Checkout（カード登録済み）にはなりません。

一方で enable_checkout が = true なら、他の条件（対応地域・通貨・有効な ACP backend）が満たされているとき、ChatGPT 内でワン・ツークリックの購入が可能になり、コンバージョンが大きく改善します。

GiftGenius の「最小限のチェックアウト対応」オブジェクト例:

{
  "id": "gg-dev-notebook-plain-usd",
  "title": "ミニマルなエンジニア用ノート",
  "description": "黒、無地、120ページ。手書きで仕様を書く人向け。",
  "price": 1500,
  "currency": "usd",
  "availability": "in_stock",
  "link": "https://giftgenius.app/gifts/dev-notebook",
  "image_link": "https://cdn.giftgenius.app/images/dev-notebook.png",
  "enable_search": true,
  "enable_checkout": true
}

注：この例でも画像（image_link）を入れています。形式上は推奨であって必須ではない場合もありますが、画像がないと UX は大きく損なわれます。

5. 推奨・任意フィールド: フィードを「魅力的」にする

必須フィールドは「動かすための最低限」です。そこだけで止めると、会計用の最小限 CSV のようなものになり、魅力的な AI ショーケースにはなりません。

推奨フィールドの例:

メインおよび追加の画像 URL；
カテゴリ（タクソノミーに基づくことが多い。例：「gifts > experiences > online courses」）；
ブランド／マーチャント名；
色・サイズ・素材などの属性；
アダルトフラグ、年齢制限など。

商品説明が豊富であるほど、モデルは意味のある回答を生成できます。たとえば「再生紙使用で、地球に配慮する開発者をサポート」と明記すれば、エコフレンドリーなギフトを求めるユーザーに対して ChatGPT は意図をもって推薦できます。

GiftGenius の SKU を拡張する例:

{
  "id": "gg-dev-notebook-plain-usd",
  "title": "エコ・エンジニアノート",
  "description": "ミニマルな無地ノート。再生紙を使用した120ページ。",
  "price": 1500,
  "currency": "usd",
  "availability": "in_stock",
  "link": "https://giftgenius.app/gifts/eco-dev-notebook",
  "image_link": "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
  "category": "gifts > office > notebooks",
  "brand": "GiftGenius Originals",
  "enable_search": true,
  "enable_checkout": true
}

category や brand のような追加属性は検索品質を高めるだけでなく、分析にも役立ちます。どのカテゴリが ChatGPT 経由でよくコンバージョンするかを把握できます。

任意フィールドは、地理別価格（後述）やカスタムメタデータなど、より特定のシナリオに紐づくことが多いです。プロジェクトの成熟に応じて追加し、単なる「チェックボックス化」は避けましょう。

6. 商用フラグと discovery‑only モード

enable_search と enable_checkout のロジックをもう一度明確にしておきます。これは次回の ACP と Instant Checkout の講義への橋渡しとなります。

あなたが ChatGPT マーチャントとしての第一歩を踏み出したところだとします。カタログはあるが、ACP backend と Delegated Payment は開発中。今のうちから ChatGPT に SKU を見つけさせ、支払いは自社サイトへ送りたい場合。

このときは次のようにします。

対象 SKU に対して enable_search = true で Product Feed を公開する；
ACP 連携の実装と認証が完了するまで、enable_checkout は = false のままにする。

この場合、ChatGPT はあなたのギフトを回答に含め、カードを表示し「GiftGenius のサイトへ移動」というリンクを提示できますが、内部の Instant Checkout UI は構築しません。

Agentic Checkout と Delegated Payment を実装したら、特定商品を「Instant Checkout 可能」へ移行できます。enable_checkout を = true にし、加えて（価格・通貨・seller URL など）データ要件を満たします。

仕様レベルでは、Product Feed のフィールドが line_items や checkout_session の合計額を埋めるために使われます。

こうしてフィードは微調整のレバーになります。ChatGPT があなたに代わって販売してよい SKU とその扱いを制御できるのです。

7. ロケール・通貨・地域とマルチリージョン価格

世界は en-US とドルだけではありません。ローカリゼーションのモジュールで locale と userLocation がビジネスロジックに影響することを述べました。ここでは特に重要です。ドイツでは米国と価格が違うかもしれず、国によって販売自体が不可のギフトもあります。

Product Feed の仕様はこれを複数の仕組みで考慮します。

まず通貨：currency は ISO 4217 の有効なコード（例：usd、eur、gbp）である必要があります。

次に、地理依存の価格と在庫を表すフィールドを使えます。ドキュメントでは geo_price のような属性や、ISO 3166 に基づく地域コードの例が示されています。

アーキテクチャ上の基本アプローチは 2 つあります。

アプローチ1：地域ごとに別フィード。

product-feed-us-en.json（米国向け）；
product-feed-de-de.json（ドイツ向け）；
product-feed-br-pt.json（ブラジル向け）。

各フィードで SKU は適切な通貨・ロケールに正規化されています。ChatGPT にとって簡潔な一方、あなたは複数フィードの保守作業が増えます。

アプローチ2：geo フィールド付きの単一フィード。

各レコードで価格の配列や追加属性を持たせます。

{
  "id": "gg-dev-notebook-multi",
  "title": "エコ・エンジニアノート",
  "description": "あなたのクリーンコード愛と地球への配慮を後押しします。",
  "prices": [
    { "region": "US", "currency": "usd", "price": 1500 },
    { "region": "DE", "currency": "eur", "price": 1400 }
  ],
  "availability_by_region": [
    { "region": "US", "availability": "in_stock" },
    { "region": "DE", "availability": "out_of_stock" }
  ],
  "enable_search": true,
  "enable_checkout": true
}

マルチリージョンのフィールド構造は仕様バージョンによって異なりますが、狙いはひとつです。SKU がどの国で存在し、いくらかをプラットフォームが理解できるようにすること。

GiftGenius の観点では、次のマッピングを設計することが重要です。

ChatGPT が知る locale と userLocation；
どのフィード部分から価格とテキストを取るか。

商用では「世界共通の 1 レコード」を返すより、国別に SKU を分けるのが一般的です。そのほうが税やポリシー、商品制限の遵守が容易です。

8. データ品質とポリシー: これなしでは Instant Checkout は成功しない

Product Feed は形式だけでなく、データ品質と OpenAI のポリシー遵守が重要です。

品質面で OpenAI が明示的に求めるもの:

正確で安定した識別子；
HTTPS で 200 を返す有効な URL；
価格と通貨の整合；
最新の在庫（実在しない in_stock を残さない）。

またテキスト長の要件もあります。例えば title は長すぎないこと、description にも現実的な上限があり、カードが整然と見えるようにします。小説のような長文は不要です。

別枠として Prohibited Products Policy があります。Instant Checkout や ChatGPT 全体で販売できない商品・サービスカテゴリのリストです。違法品、武器、特定の医療サービスなどは当然含まれます。詳細は常に最新のポリシーで確認する必要があります。要は、Product Feed は形式だけでなく内容面の許容性もチェックされるということです。

カタログにグレーなカテゴリ（酒、ギャンブル、子ども関連など）がある場合は特に注意が必要です。多くは enable_checkout を = false にして、法的整備の整った自社サイト販売に留めるほうが簡単です。

9. 実践: GiftGenius 向けに最小の Product Feed を組む

ここまでを踏まえて、GiftGenius の 3 つの SKU の簡単なフィードを作ってみます。前提として次の 3 商品があります。

エンジニア向けエコ・ノート。
1カ月のコーヒーサブスクリプション。
「大人のための TypeScript」コースのギフト券。

まずフィード生成に使う TypeScript 型を定義します。

export interface GiftGeniusFeedItem {
  id: string;
  title: string;
  description: string;
  price: number;         // セント単位
  currency: "usd" | "eur";
  availability: "in_stock" | "out_of_stock";
  link: string;
  image_link?: string;
  enable_search: boolean;
  enable_checkout: boolean;
}

次に複数要素の配列をコードで作成し、JSON にシリアライズします。

export const giftGeniusFeed: GiftGeniusFeedItem[] = [
  {
    id: "gg-eco-notebook-usd",
    title: "エコ・エンジニアノート",
    description: "再生紙を使ったミニマルな無地ノート。",
    price: 1500,
    currency: "usd",
    availability: "in_stock",
    link: "https://giftgenius.app/gifts/eco-dev-notebook",
    image_link: "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
    enable_search: true,
    enable_checkout: true
  },
  {
    id: "gg-coffee-sub-1m-usd",
    title: "エンジニア向けコーヒー — 1カ月サブスク",
    description: "月替わりのコーヒー豆ボックス。締め切りのお供に。",
    price: 2900,
    currency: "usd",
    availability: "in_stock",
    link: "https://giftgenius.app/gifts/coffee-subscription-1m",
    image_link: "https://cdn.giftgenius.app/images/coffee-1m.png",
    enable_search: true,
    enable_checkout: true
  },
  {
    id: "gg-ts-course-gift-usd",
    title: "TypeScript コースのギフト券",
    description: "ついに generics を理解したい開発者向けのオンラインコース。",
    price: 9900,
    currency: "usd",
    availability: "in_stock",
    link: "https://giftgenius.app/gifts/ts-course",
    image_link: "https://cdn.giftgenius.app/images/ts-course.png",
    enable_search: true,
    enable_checkout: false // いまは discovery のみ
  }
];

あとは、この構造から product-feed.json を N 分ごとに生成して HTTPS サーバーへ配置する簡単なユーティリティを作れます。

import { writeFile } from "node:fs/promises";
import { giftGeniusFeed } from "./feed-data";

// 最も単純な JSON フィードジェネレーター
async function buildProductFeed() {
  const json = JSON.stringify(giftGeniusFeed, null, 2);
  await writeFile("public/product-feed.json", json, "utf8");
}

buildProductFeed().catch(console.error);

実プロジェクトではフィード全体をコードに直書きはしません。通常は DB から取得します。ただし最初はこの学習用サンプルでも十分にパイプライン（生成 → 配置 → 検証）を試せます。

10. アンチパターン: 「悪い」 Product Feed の例

仕様や UX の要件感覚をつかむために、形式上ほぼ動いてしまうが実務では問題になるフィード例を見てみます。

{
  "id": "1",
  "title": "ギフト",
  "description": "イケてるギフト",
  "price": 12.333333,
  "currency": "usdollars",
  "availability": "yes",
  "link": "http://giftgenius.local/gift/1",
  "enable_search": "true",
  "enable_checkout": "maybe"
}

ここには複数の問題があります。

第一に、id = "1" は不安定で情報量の少ない識別子です。将来 DB を移行したりシャーディングしたりすると脆くなります。マーチャント内で一意で十分に長く意味のある ID を使いましょう。

第二に、price が無限小数のような値になっています。仕様や決済システムは通常、最小単位（セント、最小通貨単位）の整数を期待し、浮動小数や丸めの問題を避けます。

第三に、currency が = "usdollars"、availability が = "yes" のように、期待される形式（ISO 4217 と許容ステータス）に合っていません。

第四に、link が http かつローカルドメインを指しています。どちらも本番では不適切です。仕様では HTTPS と公開到達性が要求されています。

第五に、enable_search と enable_checkout はブール値であるべきで、文字列ではいけません。OpenAI のパーサーがフィードを拒否するか、デフォルト値に強制され予期せぬ動作を招きます。

この種の問題は、厳密なバリデーションエラー（フィードが拒否される）だけでなく、より厄介な状況、すなわちフィードが形式上は受け付けられるが一部 SKU が無視されたり期待通り動かない、といった事態を招きます。だからこそ自社側での内部バリデーションに投資すべきです。

11. Product Feed 運用での典型的なミス

誤り1: フィードを「一度きりの CSV インポート」と捉える。
Product Feed を「統合作業のために一回だけ生成して終わり」という認識は誤りです。AI‑commerce においてフィードは生きた情報源であり、定期的に更新されるべきものです。価格変更、販売停止、プロモの開始などはタイムリーにフィードへ反映してください。でないと ChatGPT は実在しない商品や古い価格を推薦し、ユーザーの不満を招きます。

誤り2: 製品モデルと SKU を混同する。
単一の基礎製品に多数のオプションを、1 レコードの中で「size1/size2/size3」「duration1/duration2」のように詰め込もうとすることがあります。結果としてモデルは「何が売られているか」を理解しづらく、ACP backend はチェックアウト時の展開で苦しみます。はるかに簡単で堅牢なのは「SKU 1 つにつきフィードのレコード 1 つ」です。たとえ同一製品のバリアントであってもそうすべきです。

誤り3: ロケールと地域を無視する。
初期 MVP で開発者が currency = "usd"、enable_checkout = true を無差別に設定し、あなたの地域で Instant Checkout が使えないことや、国ごとの販売禁止・法規制を考慮しないことがあります。新市場に出ようとしたときに破綻します。最初から SKU を地域と通貨に紐づけるのが賢明です。市場が 1 つでも同様です。

誤り4: 説明文を旧来の SEO テキストと同一視する。
自社サイトの古い説明（キーワード詰め・ロボット向け）を Product Feed へ流用するチームがあります。ChatGPT には逆効果になりがちです。モデルは文章生成が得意であり、それよりも構造化された正確な事実のほうが重要です。冗長なdescription ではなく、簡潔で要点を押さえた内容にしましょう。

誤り5: 自前のバリデーションを行わない。
OpenAI 側のバリデーションに全面的に頼るのは危険です。自社バックエンドや CI に簡単なバリデータを用意し、フィールドスキーマ、許容値、URL と通貨の形式を検査しましょう。TypeScript なら Zod などや独自チェックで実現できます。これにより本番投入前に問題を検知できます。

誤り6: Product Feed に「何でもかんでも」入れる。
将来のためにと数千の SKU を詰め込みたくなるかもしれませんが、デバッグ・分析・品質管理が困難になります。本当に ChatGPT で売りたい、目を配れるカテゴリと SKU に絞って開始するのが賢明です。残りは discovery モードに留めるか、統合自体を見送っても構いません。

誤り7: Product Feed と ACP backend を同期しない。
フィードと ACP API は表裏一体です。フィードに新しい SKU を載せたのに backend が未対応（あるいはその逆でフィードから外したのに backend は存在すると信じている）だと、非同期が発生し、バグやサポート工数を増やします。カタログのドメインモデルを一元化し、フィード生成とチェックアウト処理の両方で同じモデルを使うのが上策です。

前へ前のレッスン

次へ次のレッスン

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION