AIコマースの全体像とOpenAIの役割

1. AIコマースとは何か

従来型のeコマースが「サイトにアクセス — カタログを開く — カートに入れる — 3つのフォームを抜ける」という体験だとすれば、AIコマースでは、主役のインターフェースがChatGPTとの対話になります。ユーザーは自然言語で要望を述べ、ChatGPT内のエージェントがコンサルタント、マーチャンダイザー、そして一部はプロダクトマネージャーの役割を担います。

問い合わせは「category=socks&price_max=20」のような形ではなく、「ちょっと面白いけど痛くない同僚向けのギフトで、20ドル以下、メールで送れるものを選んで」のようになります。エージェントは要望を解釈し、必要事項を確認し、商品カタログを参照し、選択肢の長所短所を説明し、その後、ユーザーを購入完了まで案内します。しかもユーザーは「カート」という別ページを目にする必要がありません。

アーキテクチャの観点では、ChatGPT Appはこの時点で「賢いギフトカタログ」からコマースアプリへと変わり、次のことができます。

1. ユーザーの意図と制約（予算、ギフトの種類、国、デジタル/物理商品）を理解する。
2. Product feedから具体的なSKUを選定し、その理由を説明する。
3. 標準化されたプロトコル ACP（Agentic Commerce Protocol）経由で購入手続きを開始する。

AIコマースの要点は、「catalog + checkout」が独立したサイトではなく、すでにユーザーがGPTと行っている対話の論理的な延長になる、ということです。

2. 従来型eコマースとAIコマースの比較

違いを体感するために、2つのアプローチを並べてみましょう。以下は完全網羅ではない簡略表ですが、パラダイムの転換点がよく分かります。

実務的な帰結として、AIコマースでは『カタログとカート』のビジュアルデザインから、データの構造と品質、そしてChatGPT・自社バックエンド・決済プロバイダ間の正式なプロトコルへと重心が移ります。Product feedとACPエンドポイントは、ウィジェットそのものと同じくらい重要な「UI」になります。

従来型ではブラウザ側でUXの一部を調整できますが、AIコマースでは、モデルはあなたが与えたデータとスキーマ（商品説明からチェックアウトセッションのステータスまで）にほぼ全面的に依存します。

3. OpenAI Commerceの構成要素

OpenAIは「魔法の決済システムGPTPay」を提供しているわけではありません。代わりに、既存のマーチャントと決済プロバイダをChatGPTの世界に正しく接続する方法を定めた仕様とガイドのセットがあります。この中で特に重要な4つのブロックがあります。

まずはProduct Feed Specification。これは販売者が自分のカタログを記述するための公式フォーマットです。 id、title、description、価格、通貨、在庫、画像など。 フィードは「構造化された単一の情報源」として機能し、OpenAIが検証・インデックス化し、ChatGPT内での検索、ランク付け、チェックアウトに利用します。

次にAgentic Checkout Specification。これはエンティティcheckout_sessionを扱うためのREST契約です。 APIは、支払いセッションの作成、更新（たとえば住所や配送方法の変更時）、完了方法、そしてバックエンドが返すべきフィールド（合計、税、フルフィルメントの選択肢、返品ポリシーへのリンク等）を定義します。

三つ目はDelegated Payment Specification。これは、エージェントのプラットフォーム（ChatGPT）が決済プロバイダ（例: Stripe Shared Payment Token）から委任された決済トークンを受け取り、支払い情報自体を開示せずにあなたのバックエンドへ渡すためのプロトコルです。トークンは金額、有効期限などの制限があり、あなたのバックエンドがPSPにおける実際の支払いを作成するために使用します。

そしてChatGPTのInstant Checkoutは、これらの仕様の上に成り立つUXレイヤーです。チャット内にコンパクトなチェックアウトインターフェースが現れ、選択された商品、価格、住所、支払い方法を表示します。内部ではProduct Feedに依拠し、Agentic Checkout Specに従ってあなたの/checkout_sessionsを呼び出し、Delegated Paymentを使ってPSPでトランザクションを実行します。

良いニュースは、これらが「ChatGPTの秘密API」ではなく、公開仕様のACP（Agentic Commerce Protocol）であることです。つまり、ACPをサポートする他のAIプラットフォームでも、同じバックエンドが理論上は動作し得ます。

4. 役割と責任範囲

ここからが本題です。お金が絡むと、規制当局や法務が突然あなたの最良の友人になります。混乱を避けるために、役割を明確に分けることが重要です。

最も重要な役割はエージェントのプラットフォーム、ここではChatGPTです。チャット、ウィジェット、Instant Checkout UIといったユーザー体験を握っています。プラットフォームはコマースフローを開始し、Product Feedから商品を選び、あなたのACPエンドポイントを呼び出し、結果をユーザーに表示します。とはいえ、ChatGPTは商品の所有者でも決済プロバイダでもなく、あなたのproductデータを「自前のカタログ」として保持しません。渡されたフィードをそのまま利用するだけです。

二つ目の役割はマーチャント（seller, merchant‑of‑record）です。これは商品やサービスの所有者。マーチャントは、product feed（構造、品質、価格と在庫の最新性）、ACPエンドポイント（/checkout_sessions、webhooks）の正しい実装、注文の作成と保管、配送、サポート、返品に責任を持ちます。ACPのドキュメントは、法的にも販売者はプラットフォームではなくマーチャントであることを強調しています。

三つ目は決済プロバイダ（PSP）、例えばStripe。PSPは決済処理、PCI DSSなどの要件順守、支払い情報の保管、不正対策やチャージバック対応を担います。Delegated Paymentの文脈では、PSPはエージェントのプラットフォームに特別なトークン（SPT）を発行し、それをあなたのサーバーが用いて実際の支払い（例: StripeのPaymentIntent）を作成します。

四つ目で最も重要なのはユーザーです。ユーザーは要望を定義し、最終的な購入判断を下し、支払いに同意し、理想的にはあなたがチェックアウトUIで真摯に提示するTerms / Privacy Policyを読みます。信頼性と透明性を高めるために、Product feedにはこれらの文書や返品ポリシーへのリンクを含めることができます。

分かりやすく小さな表にまとめます。

責任範囲の分離は法務だけでなくアーキテクチャ上も重要です。例えば明日、第二のPSPを接続しても、ChatGPT Appを書き換える必要はありません。自分のバックエンドのDelegated Payment層を適応させるだけで足ります。また、ACPに対応する第二のAIプラットフォームが現れた場合でも、product feedとチェックアウトエンドポイントを再利用できます。

5. すべてが対話の中で完結する購入シナリオはどう見えるか

ここまでを統合し、ChatGPTでデジタルギフトを購入するend‑to‑endのシナリオをアーキテクチャ視点で見てみましょう。簡略化していますが、本質を捉えています。

sequenceDiagram
  participant U as ユーザー
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as マーチャントバックエンド
  participant P as PSP (Stripe)

  U->>C: "50ドル以下のデジタルギフトを買って"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: 適合するSKUの一覧
  G-->>C: ギフト候補＋メタデータ
  C-->>U: 選定理由を説明し、オプションを提案
  U->>C: "これにする"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: 支払いトークン（SPT）を要求
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: 支払いを実行
  B-->>C: 注文作成のWebhook
  C-->>U: 購入を確認

ACPの素朴な言い方をすると、ここでは次のことが起きています。

1. エージェントはProduct Feed（あなたのバックエンド経由）を用いて適切なSKUを選ぶ。
2. 「購入する」と決まったら、ChatGPTはAgentic Checkout Specに従ってあなたの/checkout_sessionsを通じてcheckout_sessionを作成する。
3. Instant Checkoutの間、ChatGPTはPSPから特定の金額とマーチャントに対する委任決済トークンを取得する。
4. このトークンをPOST /checkout_sessions/{id}/completeに渡し、あなたのバックエンドがPSPでの支払いを作成し、注文を生成する。
5. 注文が用意できたら、あなたのサーバーがWebhookでOpenAIに通知し、その後ユーザーは最終確認を目にする。

この講義で重要なのは、エンドポイント名を暗記することではなく、構造を捉えることです。 フィード → SKU選定 → checkout_session → 支払い → 注文 → Webhook。次回以降、フィードのフィールド、チェックアウトセッションのフィールド、委任決済の形式をそれぞれ掘り下げます。

6. GiftGenius: 私たちのAppはAIコマースにどう適合するか

ここまでGiftGeniusは「ギフト選定アシスタント」の役割でした。できることは:

• ユーザーに、誰にどんな目的でギフトが必要かを尋ねる。
• MCPツールを使って自社カタログを検索する。
• ウィジェットで候補カードを表示し、チャットにfollow‑upボタンを送る。

コマース観点では、これは実購入のない「スマートなディスカバリー」でした。OpenAI commerceの世界では、このモードはSKUに対して enable_search = true, だが enable_checkout = false に設定されたフィードに相当します。 商品は見つけて議論できるが、Instant Checkoutは無効です。

AIコマースモジュールでは、GiftGeniusを段階的に完全統合されたマーチャントへ変えていきます。

• OpenAI仕様に沿った構造化Product Feedを追加する。
• checkout_sessionsを扱えるACPバックエンドを設計する。
• Stripe Shared Payment Tokenを用いてDelegated Paymentを接続する。
• アプリに「選ぶだけでなく、そのままチャットで購入できる」ことをユーザーへ示させる。

これを「ブラックマジック」に見せないため、コマースフローの役割とステップを明示的にモデル化する小さな技術レイヤーをコードに加えましょう。ログや社内テストにも役立ちます。

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

これらの型は、TypeScriptレベルでも「誰が何をするか」を頭の中で切り分ける助けになります。テストやウィジェット内のデバッグUIで使えます。

「50ドル以下のデジタルギフト」シナリオの小さなステップ配列の例:

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "要望と予算を定義する" },
  { id: "search", role: "chatgpt", description: "Product FeedからSKUを選定する" },
  { id: "checkout", role: "merchant", description: "checkout_sessionを作成する" },
  { id: "payment", role: "psp", description: "トークンで支払いを実行する" }
];

このコードはまだ誰ともネットワーク通信しませんが、今後の講義で実際のACPコードを積み上げるための有用な「座標軸」を作ります。

7. ミニ課題: 「50ドル以下のデジタルギフトを買って」のフローを分解する

講義の最後に、いま話したことを自分の手で分解してみましょう。ユーザーのリクエストを取り上げます。

「50ドル以下のデジタルギフトを買って」。

課題 — その後に起きることを3〜5の論理ステップで記述し、各ステップを誰が実行するか（ChatGPT、あなたのマーチャントバックエンド、決済プロバイダ、ユーザー）を明示してください。上の図や配列digitalGiftFlowを参考にしても構いませんが、完全一致である必要はありません。

例えば、ChatGPTがリクエストを解釈し、ユーザーに詳細（デジタルギフト券、受取人の地域、誰向けか）を確認するステップから始められます。次に、あなたのバックエンドがProduct Feedで適切なSKUを探し、その後 — checkout_sessionの作成、PSPからの支払いトークン取得、購入完了へと進みます。

望むなら、これをそのままコードとして表現しても構いません。digitalGiftFlowにいくつかのステップを追加し、ウィジェット内の小さなデバッグコンポーネントでレンダリングしてください。この演習は「コード」だけでなく、プロトコルにおける役割について考える習慣を養うのに有効です。

このような「フロープラン」を受け取り、（本物のコマースなしで）ログ出力するだけのシンプルなAPIエンドポイントの例:

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

実運用ではconsole.logの代わりに構造化ログを書き、こうしたシナリオをドキュメントやテストの一部として保存するかもしれません。しかし、こんな小さな例でも、抽象的なアーキテクチャとあなたのNext.jsアプリにおける具体的なTypeScriptコードを結びつける助けになります。

本講義で整理した役割の全体像を頭に入れておけば、以降の技術詳細 — Product Feedのフィールド、チェックアウトセッションのスキーマ、委任決済の構造 — も「全能のGPT」という幻想に振り回されることなく、ずっと楽に理解できます。

8. AIコマースと役割理解における典型的な誤解

誤り №1: 「ChatGPTが全部やってくれる」と思い込むこと。
開発者の中には、「Stripeをつなぎ、モデルにAPIアクセスを何となく与えれば、あとはGPTがうまくやってくれる」と考える人がいます。実際には、ChatGPTを中心としたAIコマースは、Product Feed、Agentic Checkout、Delegated Paymentといった正式な仕様に基づいています。商品を構造化フィードで記述せず、/checkout_sessionsを実装せず、Delegated Paymentを設定しないなら、どんなモデルもそれを勝手に補ってはくれません。

誤り №2: ChatGPTとマーチャントの役割を混同すること。
よくある混同は、ChatGPTが「店」になり、あなたは「カタログをつなぐだけ」だと考えることです。現実は逆で、あなたはマーチャントのままです。product feedを保持し、注文を作成・運用し、返品を処理します。ChatGPTは対話UXと、あなたのACPエンドポイントを正しく呼び出す責任だけを負います。「GPTが自らサブスクリプションを付与し、商品を配送する」かのように設計すると、法的にも技術的にも袋小路に陥ります。

誤り №3: 決済プロバイダを独立した存在として扱わないこと。
ときにPSPをバックエンドの内側に「隠し」、他のREST APIと同様に扱いたくなりますが、決済レイヤーには固有のルール（PCI、不正、チャージバック、各種制限）が存在します。ACPアプローチで独立したDelegated Payment Specがあるのは偶然ではありません。エージェントのプラットフォームはPSPと自分たちのレベルでやり取りし、SPTトークンを取得してあなたに渡し、あなたが支払いを作成します。これを迂回してAppでカード情報を直接受け付けると、コンプライアンス要件によってすぐに自滅します。

誤り №4: product feedを「マーケ設定」と見なし、LLM向けのAPIだと理解しないこと。
Google Shoppingの背景を持つ人は、フィードを広告管理画面のためのものと捉えがちです。AIコマースの世界では、フィードは本質的にモデルのための品揃えナレッジベースです。画像リンクが壊れていたり、属性が不整合だったり、単位がバラバラで、事実ではなく誇張的なマーケ文句が並んでいれば、モデルは望ましくない提案をし、コンバージョンは落ち込みます。

誤り №5: Instant Checkoutを「一足飛び」に導入しようとすること。
誘惑は大きいでしょう。「enable_checkoutをすぐにONにして、チャットから買ってもらおう」と。しかし、優れたディスカバリー（質の高いフィード）、堅牢なチェックアウトバックエンド、PSPとの周到な統合がないと、注文の半分が途中で止まるような脆いシステムになりかねません。OpenAIが提案するステップを踏むのが賢明です。まずは高品質なProduct Feed、次にACPエンドポイントのデバッグ、その後にDelegated Payment、そして最後に本番でInstant Checkoutを有効化するのです。