ChatGPT Merchants とマーチャントの道筋: 登録から責任まで

1. ChatGPT マーチャントとは何か、そして「普通のストア」と何が違うのか

開発者の視点で見ると階層を混同しがちです。Next.js アプリ、MCP サーバー、何らかの commerce バックエンドがあり、その先には OpenAI、ChatGPT、Stripe などの大規模サービスが並びます。つい「全部ひとつの大きなシステムだし、テストがグリーンなら OK」と言いたくなります。

しかし AI‑commerce の世界では法的・技術的な境界は厳密に分かれています。ChatGPT はあなたのストアにも支払処理業者にもなりません。知的なインターフェースを提供し、公開仕様に沿ってあなたの API を呼び出すだけです。マーチャントであり続けるのは、特定のカタログを持ち、ユーザーに対して責任を負う具体的な企業（または個人事業主）です。

マーチャントの役割理解は法務だけの話ではありません。設計判断に直結します。フィードのデータをどこに保存するか、どう注文を検証するか、何をログに残すか、チャットに表示された内容と実際にあなたのシステムで起きたことの不一致をどうデバッグするか、などです。

例

典型的な e‑commerce を想像してください。サイト、カート、チェックアウト、決済プロバイダとの統合があり、ユーザーはブラウザでアクセスしてクリックし、カード情報を入力します——わかりやすい世界です。

ChatGPT マーチャントは、同じストアでありながら、高度に自動化された AI ダイアログ経由で販売できるようになった形です。違いは 何を 売るかではなく、ユーザーが どう リクエストから支払いまで進むかというプロセスにあります。

OpenAI の観点で、マーチャントとは次のような組織（または個人事業主）です。

• OpenAI の仕様に従った Product Feed を提供する（SKU の構造化データを含む CSV/TSV/XML/JSON）。
• ChatGPT Merchants ポータルで登録し、カテゴリと法的要件の審査を受ける。
• 進んだ形では Agentic Checkout と Delegated Payment を実装し、ChatGPT の Instant Checkout があなたのサイトに遷移させずに決済を完了できるようにする。

つまりマーチャントとは「ウィジェットを書いた人」ではなく、品揃えと金銭的義務の所有者です。本講座では二つの役割を兼ねます。ChatGPT App としての GiftGenius を作るチームであり、その App を支えるマーチャントのバックエンドを作るチームでもあります。

2. ポータル ChatGPT Merchants: 申請から本番マーチャントまでの道のり

OpenAI には出品者向けの専用サイト（ポータル） ChatGPT Merchants があります。ここを通じて、販売者は Instant Checkout プログラムに参加し、自分のフィードやバックエンドを接続します。ここでは深い技術詳細に入る前の道筋を段階的に見ていきます（詳細は次回の講義）。

事前準備

チームの誰かが「Apply」ボタンを押す前に、既に用意しておくべき“レンガ”がいくつかあります。

法的主体 と サイト。マーチャントにはドメインとユーザーにとってわかりやすいストアフロントが必要です。たとえ最終的にすべてを ChatGPT 経由で販売する場合でも、OpenAI は公開のショーケースがあることを期待しています。

ポリシーに適合した品揃え。 前回の講義で Prohibited Products Policy に触れました。たとえば武器や一部の医療品は不可です。ChatGPT 経由で販売したい商品は、許容カテゴリの範囲に収まっている必要があります。

基本的な決済インフラ。 Delegated Payment によってカードを直接扱う必要は薄れますが、必ず PSP（Stripe など）との統合があり、自分たちのシステムで 注文や返金をどのように作成するか を理解しておく必要があります。

Merchants ポータルでの申請

技術的には退屈ですが重要なステップです。サイトにアクセスして Instant Checkout プログラムへの参加申請を行います。一般的に次のようなことを尋ねられます。

• あなたは誰か（法人情報、サイト、連絡先）。
• 何を売るのか（カテゴリ、価格帯、地域）。
• Product Feed をどのように提供するか（フォーマット、URL、更新頻度）。

この部分は TypeScript とはあまり関係ありませんが、ロードマップに強く影響します。マーチャントが基本審査を通過するまで、たとえコードが完璧でも Instant Checkout は有効になりません。

Product Feed の接続

申請が確認され概ね同意が得られたら、主な技術的フォーカスは Product Feed に移ります。ドキュメント上、フィードは統合に必須です。これがなければ ChatGPT はあなたが何を売っているのか分かりません。

この段階で行うことは次のとおりです。

1. フィードの形式を決める（多くは CSV か JSON）。
2. 配信方法を決める。S3 の pre‑signed URL や、定期的に更新を POST する HTTPS エンドポイントなど。
3. 各 SKU に最低限必要なフィールドを用意する: id, title, description, price, currency, availability, link、画像、およびフラグ enable_search / enable_checkout。

enable_checkout を = false にしている間は、 マーチャントは discovery‑only モードで動作できます。ChatGPT は商品を見つけて推薦しますが、購入時にはユーザーをあなたのサイトへ送ります。

ACP の統合（詳細は次回）

Product Feed が安定し、次へ進む準備ができたら、Agentic Checkout と Delegated Payment の統合を開始します。Merchants ポータルの観点ではこれは別枠の要件です。エンドポイント /checkout_sessions を実装し、委任された支払いトークン（Shared Payment Token）を受け取り、適切なステータス （not_ready_for_payment、ready_for_payment、 completed、canceled） でセッションを正しく完了させる必要があります。

本講義では「次の難易度」として触れるに留めます。プロトコルの詳細やリクエストスキーマは次回に扱います。

3.5. 認証と Instant Checkout の有効化

最後の段階は、あなたのバックエンドが実際のシナリオでどう振る舞うかの検証です。

• 注文が正しく作成されるか。
• フィードの価格と、実際に請求した価格が一致しているか。
• エラーや返金処理が正しく行われるか。
• あなたの ToS/Privacy のページが OpenAI と各国の法令の期待に合致しているか。

これらの後、マーチャントは「Instant Checkout の準備完了」というステータスを得て、 enable_checkout = true の商品の購入が ChatGPT 内で実際に可能になります。

全体の流れは次のシンプルな図としてイメージできます。

flowchart TD
  A[プロダクトとサイトがある] --> B[ChatGPT Merchants へ申請]
  B --> C[Product Feed 接続済み]
  C --> D["ACP backend 実装
(checkout_sessions + delegated payment)"]
  D --> E[認証
および Instant Checkout 有効化]

3. マーチャントの選択肢: Etsy/Shopify vs カスタム backend

朗報です。すべてのマーチャントが ACP バックエンドを自作する必要はありません。Shopify、Etsy など一部プラットフォームには、技術実装を肩代わりする統合が既にあります。

Shopify や Etsy で販売している場合の概略は次のとおりです。管理画面で「Show in ChatGPT」のようなオプションを有効にすると、プラットフォーム側が自動的に:

• 必要な形式の Product Feed を生成・維持する。
• ACP エンドポイントを実装する、またはプロキシする。
• Stripe などの PSP と接続する。

ストアオーナーであるあなたは、REST エンドポイントの実装よりも、品揃えや説明文の整備に多くの時間を使えます。

一方、本講座の GiftGenius のように、独自バックエンドを持つカスタム マーチャントを構築する場合は自由度が高い反面、作業量も増えます。フィード、チェックアウト、決済プロバイダ統合を自分たちで実装します。

次の表で比較すると便利です。

本講座では意図的に三番目の選択肢を選びます。そうすることで、フィードから webhook、そして堅牢な本番運用まで一通り経験できます。

4. マーチャントの責任: データ、注文、ポリシー、資金

ChatGPT マーチャントになると、新しい注文の喜びだけでなく、非常に具体的な義務のセットも引き受けることになります。層ごとに整理しましょう。

カタログデータと Product Feed の品質

Product Feed は ChatGPT にとっての唯一の真実の源です。そこで商品価格が 10 USD かつ在庫ありと示されていれば、ユーザーがチャットで見るのもその情報です。フィードが誤っていれば、よくて不満、悪ければポリシー違反で OpenAI との問題に発展します。

マーチャントに期待されること:

• 必須フィールドの正確さ（正しい価格フォーマット、通貨の ISO コード、有効な HTTPS リンク、正常な画像）。
• 十分な頻度でフィードを更新し、幽霊在庫を売らない。
• 識別子の一貫性。フィードの id（SKU）は、あなたのデータベースや注文システムの ID と一致し、何が購入されたかを一義に判別できること。

通常の e‑commerce にたとえると、ここでの Product Feed は「マーケットプレイス向けエクスポート」に相当します。ただし今回の“マーケットプレイス”はサイトではなく、ユーザーの頭の中に住み、不整合を容易に覚えてしまうスマートアシスタントです。

注文、配送、返金

ChatGPT はあなたのストアのサポート窓口に変身するわけではありません。ユーザーは確かに ChatGPT と対話しますが、法的には OpenAI ではなくマーチャントから商品を購入します。つまり次の責任があります。

• 注文があなたのシステムで作成され、倉庫へ確実に伝達されること。
• 配送物が Instant Checkout でユーザーが指定した住所に届くこと。
• 返金、キャンセル、部分返金などを適切に処理すること。

ACP の枠組みでは、checkout_session の成功後、通常は order オブジェクトが含まれます。 しかしそれはあなたのバックエンドで起きたことの反映にすぎません。テーブル orders のレコード構造やステータス、物流との関係をどう定義するかは、まさにあなたの責任です。

ポリシーと販売地域

Merchants ポータルでは、販売する国や商品タイプを申告します。OpenAI は次の観点で確認します。

• 禁止カテゴリを販売していないか。
• 各地域の法令（税制や年齢制限など）を遵守しているか。
• 分かりやすい Terms of Service と Privacy Policy を提供しているか。

後続モジュールで法的ページについても触れますが、すでに今の時点で「自分が何をどこで販売するのかを法務に説明できないなら、ChatGPT が代わりに売ってはくれない」と考える癖をつけておくと良いでしょう。

お金と決済プロバイダ

最後に最も怖いのはお金です。幸い、ACP と Delegated Payment は開発者の負担を大きく軽減します。

• ChatGPT と決済プロバイダ（例: Stripe）は、特定の金額とマーチャントに対する Shared Payment Token に合意します。
• あなたのバックエンドは complete リクエストでこのトークンを受け取り、カードの「生データ」を見ることなく自分の PSP で利用します。

つまり、PCI に過剰適合した怪物になる必要はなく、カード番号を保存したり、監査の悪夢に飛び込む必要もありません。あなたの責務は、委任トークンを正しく扱うこと（支払い作成・請求・返金）と、丁寧な会計管理を行うことです。

5. これを GiftGenius のアーキテクチャにどう落とし込むか

学習用アプリ GiftGenius に戻りましょう。モジュール 14 の後には、学生が次のレベルの図を描けるようになることを目指します。「ユーザー → ChatGPT → App ウィジェット → MCP Gateway → Product Feed / Agents / ACP backend」。

この図において、マーチャントの役割は私たちのバックエンドで実装され、ウィジェットや App は ChatGPT におけるそのマーチャントの「顔」として振る舞います。

コード内のマーチャント設定

まずは簡単なステップから。コードにマーチャント設定の構造を用意します。Next.js プロジェクト内の TypeScript モジュール lib/merchantConfig.ts としましょう。

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ACP/Stripe におけるマーチャントの ID
  name: string;              // 人間が読む名称
  feedUrl: string;           // Product Feed の配置場所
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // 後で有効化する
};

ここで第一に、これは マーチャント であって「ウィジェット」ではないことを明確に固定します。第二に、重要な値を環境変数に切り出しています——デプロイや環境に関するモジュールで、なぜこの種の値をハードコードすべきでないかを何度も思い出すことになるでしょう。

利便性のため、今すぐ Instant Checkout を使ってよいかをコードに伝える簡単な関数を追加できます。

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // dev と staging では常に Instant Checkout を無効化する
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

こうして、環境によって挙動が異なる前提をアーキテクチャに先回りして織り込み、誤って（あるいは GPT が）テスト環境から本番のチェックアウトへ進んでしまうことを防げます。

MCP ツールでマーチャント情報を取得する

モデルやウィジェットが現在のマーチャントの動作モードを知れるようにしておくと便利なことがよくあります。たとえば、Instant Checkout が無効なら GPT がそれを提案しないようにする、といった目的です。

MCP サーバー（前のモジュールで立ち上げたもの）に、次のような簡単なツールを用意できます。

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "GiftGenius のマーチャントに関する基本情報を返します",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

このツールは目新しいことはしませんが、「今はチャット内で購入できるのか、それともリンク遷移のみか？」をモデルが尋ねられる明確な場所を作ります。

ウィジェットでマーチャント情報を利用する

ウィジェット側では、既におなじみの Apps SDK のフックを使って get_merchant_info を呼び出し、モードに応じて UI を切り替えられます。最も簡単なコンポーネント例は次のとおりです。

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

この小さなコンポーネントは、ユーザー（そして開発中の自分たち）に今の統合状態を分かりやすく示します。

6. 実践的なミニ課題

講義が「言葉と図」だけで終わらないように、自分の GiftGenius プロジェクト（または同等のもの）で次を試してみましょう。

まず、merchantConfig.ts に似たマーチャント設定モジュールを追加し、 MERCHANT_ID と PRODUCT_FEED_URL を環境変数に切り出します。ローカル開発では .env.local を、production では Vercel などプラットフォームの設定を使うとよいでしょう。

次に、MCP サーバーで簡単なツール get_merchant_info を実装し、少なくとも name と instantCheckout を返すようにします。モデルにとって有用な追加フィールド（対応通貨や配送可能国のリストなど）が何かも考えてみてください。

さらに、ウィジェットに小さな UI 要素（バッジ、ステータス行、商品カードの注記など）を追加し、このツールを使って現在のマーチャントモード（推薦のみか、すでに完全な Instant Checkout か）を表示しましょう。これは UX に有益なだけでなく、デバッグにも役立ちます。

最後に、あなたの具体的なプロジェクトが「サイトとバックエンドがある」状態から ChatGPT マーチャントのステータスに至るまでのステップを文章で整理してみてください。どこで Product Feed を接続するか、いつ enable_checkout を有効にするか、いつ ACP エンドポイントの実装を始めるか——この種の演習は、方針を明確にし、返品ポリシーのような「好ましくないが重要な」事項を見落とさない助けになります。

7. ChatGPT マーチャントへの道でよくあるミス

誤り1: 「ChatGPT がそのまま自分のストアだ」と考える。
開発者がすべてを ChatGPT 側に「移す」つもりで考えてしまうことがあります。あたかもカタログを保持し、価格を計算し、注文を履行してくれるかのように。しかし現実には、ChatGPT はインターフェース兼オーケストレーターであって、あなたの ERP ではありません。これを忘れると、自前の健全な注文モデルが存在しない、データが「どこかのプロンプト」に漂っている、モデルの挙動変化が整合性崩壊に直結するといった設計になりがちです。

誤り2: 申請や ACP なしに Instant Checkout を期待する。
優れたウィジェットを作り、Product Feed を設定したという事実だけでは、Instant Checkout は自動的にオンになりません。Merchants ポータルでの申請、カテゴリ審査、Agentic Checkout と Delegated Payment の実装、テスト通過が必要です。Instant Checkout を「デフォルトで使える」と見込むと、GPT が実際には存在しない機能を提案したり、期待した決済画面の代わりにリンクを返したりする状況になりがちです。

誤り3: マーチャント ID や URL のベタ書きハードコード。
古典的な落とし穴です。たとえば MERCHANT_ID = "prod-123" がコードに直書きされ、フィードの URL もウィジェットのコンポーネント内に文字列で埋め込まれている、といった状況。staging 環境を追加したり、二つ目のマーチャントが必要になった途端、大規模な検索置換が始まります。こうした値は設定や環境変数に切り出し、MerchantConfig のような薄い抽象レイヤ経由で使うのが安全です。

誤り4: Product Feed が注文と無関係に独り歩きする。
もしフィード上の SKU GIFT_RED_MUG が 10 USD、しかし同じ識別子に対し注文データベースで何らかの理由により 12 USD を請求しているなら、遅かれ早かれ問題化します。価格と在庫の真実の源は、内部データから生成されるフィードか、フィードとチェックアウトの双方が信頼する共通レイヤのどちらかであるべきです。「ChatGPT 用」と「自社サイト用」で二重帳簿を持とうとすると、あっという間に破綻します。

誤り5: 決済プロバイダの役割や決済データ保護を軽視する。
Shared Payment Token を「覗き見る」誘惑に駆られたり、独自 UI でユーザーに追加の決済情報を求めたりすることがあります。これは Delegated Payment のモデルに反するだけでなく、PCI DSS と重いコンプライアンスの世界にあなたを巻き込みかねません。適切な実践は、Shared Payment Token を不透明な文字列として扱い、決済プロバイダの SDK 内でのみ利用し、ログやキャッシュに残さないことです。

誤り6: オンボーディングの多段性を甘く見て、計画を持たない。
最後に多い組織的ミスは、「ChatGPT に接続するだけでしょ、簡単でしょ」と考えることです。実際のマーチャントの道のりは多くのステップから成ります。技術的（フィード、バックエンド、テスト）なものと、非技術的（法的文書、カテゴリ合意、地域制限）なものです。あらかじめ道筋を書き出さないと、チームはタスク間を行き当たりばったりに飛び回り、締切は AI‑commerce への高揚感よりも速く「溶け」ていきます。