ChatGPTに商品を載せるには？ACPの商品連携から注文まで

ChatGPTに自社の商品を載せたいなら、まず商品情報を届ける「商品連携」から始めます。 商品名・画像・価格・在庫などをまとめたデータを「商品フィード」と呼びます。OpenAIは、ACPの導入手順として、このデータを送る方法を案内しています。ACP（Agentic Commerce Protocol）は、AIとお店が商品情報や注文内容をやり取りするための共通ルールです [8]。

たとえば、水筒を売る店なら、商品名、写真、価格、在庫、購入ページのURLを用意します。ChatGPTが商品を探したり比較したりするときに、その情報を使えるようにする準備です。商品フィードの直接連携は承認済みパートナー向けで、最初に利用申請が必要です [8][12]。

記事は、申請する → 商品情報を送る・更新する → 購入ページにつなぐ → 必要なら注文APIを用意する、の順で説明します。自社の商品を掲載したいEC担当者が、最初に行う操作と、追加開発が必要になる条件を確認できます。

2026年9月9日に作成し、9月10日に公式案内を再確認した導入解説です。今日の新発表ではありません。前半で商品連携の申込先と送信方法を説明し、後半で2026-04-17版の注文API、支払い、失敗時の確認へ進みます。

1. ChatGPTに商品情報を届けるための申請をする

まずは、自社の商品一覧をChatGPTへ送る「商品連携」の申請を確認します。 注文APIの開発を始める前に、自社が使える連携方法を選びます [8][12]。

OpenAI：商品情報を受け取り、ChatGPTの商品探しに使う

OpenAIは、店から商品名・画像・価格・在庫などを受け取る仕組みを提供しています。商品一覧のデータを「商品フィード」と呼びます。ChatGPTが商品を探したり比較したりするときに、店が渡した情報を利用します [8]。

たとえば、水筒の価格や在庫を更新して渡せば、古い情報だけに頼らず商品を紹介するための材料になります。商品情報を送る窓口はOpenAI側にあり、第6章の「店が注文を受け付けるAPI」とは役割が違います。

2026年9月10日に確認した販売者向けページでは、購入は基本的に店のサイトやアプリで行う案内です。 商品フィードの申し込みだけで、ChatGPT内の決済まで使えるようになるわけではありません。購入用プラグインは、承認済みパートナーとの試験提供として別の開発資料に説明されています [9][12]。

OpenAIの商品連携に申し込む操作

1. OpenAIの販売者向けページ（日本語）を開き、「商品フィードの共有を申し込む」まで進みます。この見出しの下が申込フォームです。英語表示では「Apply to share your product feed」です [12]。
2. 先に対象を読みます。同日の案内では、Shopify・Etsyのカタログは連携済みで、追加の設定・申請は不要とされています。すでに申請した人は待機リストに入っているため、重複申請をしません。これは商品カタログの案内であり、すべての地域で購入機能が使えるという意味ではありません。
3. 自社で申請する場合は、下表の情報を入力・選択します。日本語ページと英語ページで表示名が異なるため、下表では入力する内容を示します。

画面の入力欄	入れる情報
氏名・職種・LinkedIn・仕事用メール	申請を担当する人の情報とLinkedInのURL
会社・本社所在国・店舗サイト	会社名、本社のある国、自社のECサイトURL
主な商品カテゴリ	自社が販売する商品のカテゴリ
希望する連携	商品フィードを連携してChatGPTの商品検索に載せる選択肢
商品フィードの準備状況	OpenAIの仕様に合ったデータを準備済みか。未確認なら準備済みと申告しない
商品数	商品を識別する番号で数えた種類数。販売個数や在庫の合計ではない
その他の連絡事項	追加で伝えたいこと。自由記入欄

1. 入力内容を確認し、画面下の「送信する」（英語表示では「Submit」）で申請します。ここで終わるのは利用申請です。商品情報の送信や掲載開始ではありません。 承認後に案内された接続方法で連携します [8][12]。

同日の販売者向けページでは、買い物機能は米国の利用者向けと説明されています。本社所在国の欄があることだけで、日本での提供や自社の承認を保証するものではありません [12]。

2. 承認後に商品データを送り、価格や在庫を更新する

承認後は、OpenAIの開始ガイドで、商品一覧をファイルで渡す方法か、APIで送る方法を選びます。商品データの形式を確認し、必要な項目をそろえて送信します。全件を1日1回ファイルで渡し、日中の変更をAPIで更新する方法が一般的な案として示されています [8]。

この時点で店が用意するのは、商品一覧と更新する仕組みです。申し込み前に、すべての注文APIを完成させる手順としては案内されていません。

商品を登録・更新するAPIは公開されている？

商品一覧を作り、商品を追加・更新するAPIの仕様が公開されています。 APIは、システム同士で情報を送る窓口です。ここでは店の商品情報をOpenAIへ送り、ChatGPTの商品探しに使ってもらいます [14][15][16]。

順番	行うこと	公開されているAPI
1	商品一覧の入れ物を作り、そのIDを受け取る	POST /product_feeds
2	その一覧へ商品を追加する。既存の商品は同じ商品IDで更新する	PATCH /product_feeds/{id}/products
3	一覧に入っている商品データを取得する	GET /product_feeds/{id}/products

URLの {id} は、最初に受け取った商品一覧のIDです。商品一つひとつのIDとは区別します。商品情報には商品名、説明、商品ページのURL、画像、色やサイズごとの価格・在庫などを持たせられます。APIでは、送らなかった商品を変更せず、送った商品だけを追加・更新します [15][16]。

たとえば、水筒の価格を変えたら、その商品のIDを指定して新しい価格を送ります。売り切れたら在庫状況を更新します。初回に送って終わりにすると、商品を見た人が店へ来たときに価格や在庫が違う、ということが起きます。

接続にはAPIキーによる認証が案内されています [14]。ただし、申込フォームを送っただけでキーが発行されるとは案内されていません。実際の送信先や利用できる認証情報は、承認後の案内で確認します。上のパスに想像したドメインを付けて送信しないでください。

商品送信APIの成功応答にある accepted は、送ったデータを受け付けたかどうかを表します。商品がどの回答でも紹介されることや、掲載順位を保証する項目ではありません [16]。

商品情報を送らないと、ChatGPTには出ない？

サイトを巡回して商品を見つける場合もあります。販売者向けページでも、すでにサイトが巡回されている場合、商品フィードは必須ではないと説明しています。フィードは、より正確で新しい情報を店から渡すための方法です [12]。

「申請した」「データが受け付けられた」「実際の回答で紹介された」は、同じ状態ではありません。申請や送信の記録を残し、商品名・価格・在庫が正しく渡っているかを確かめます。

3. 商品を選んだ人が、どこで購入するかを決める

2026年9月10日時点の基本の流れは、ChatGPTで商品を見つけ、店のサイトやアプリで購入する形です。 まずは、送った商品ページのURLから、正しい価格・在庫を確認して購入まで進めるかを確かめます [12]。

この流れなら、ChatGPTで商品を紹介してもらうために、次章以降の注文APIをすべて実装する必要はありません。自社ECでの購入を目指す担当者は、ここまでの商品連携と購入ページの確認から始められます。

AIとのやり取りの中で、注文まで進めたい場合

購入用プラグインは、承認済みパートナーとの試験提供として説明されています。商品データの連携に加え、MCPサーバーという接続用の仕組みや、指定の購入用ツールを用意する案内があります [9]。

その方法を使う場合は、参加できるか、どの接続方式を使うかを確認してから注文処理を用意します。次章以降は、ACPの公開された注文APIを使う構成についての説明です。このAPIだけを作れば、ChatGPTの購入機能が使えるわけではありません。

Stripeでできること：AIの商品紹介から支払いまでつなぐ

StripeのAI向け販売機能を使うと、対応するAIに商品情報を届け、そのAIで商品を選んだ人の購入・支払いにつなげられます。 お店にとっては、AIで商品を探す人に販売するための接続方法になります。利用申請が承認され、商品連携や購入の設定を終えた場合の機能です [10][17]。

Stripeは、ネット上の支払いを処理するサービスです。AI向けの販売機能では、支払いに加えて、商品一覧をAIへ届ける処理や、購入手続きを進める仕組みも提供しています [10][17]。

たとえば、お客さんが対応するAIで水筒を探し、気に入った商品を選んだとします。そのAIがStripeへ購入手続きの開始を依頼し、配送先や支払い情報を受け取って購入を進めます。購入が完了すると、お店側のシステムに通知が届き、発送の準備へ進めます。これはStripeの公式ガイドに沿った流れの例です [10]。

ここでいう「対応するAI」は、利用できる販売先として設定したAIサービスです。Stripeへ申し込めば、ChatGPTを含むすべてのAIでこの購入方法が使える、という案内ではありません。前述のChatGPTの商品連携とは、使える購入方法や参加条件をそれぞれ確認します [10][12]。

Stripe、AI、お店は何を担当する？

商品を選ぶ人とのやり取りはAI、商品情報の受け渡しと購入・支払いの処理はStripe、商品の管理と発送はお店側が担当します。 役割を購入の順に並べると、次のようになります [10]。

購入までの流れ	担当すること
商品をAIへ届ける	お店側が商品一覧をStripeへ渡し、Stripeが有効にしたAIの販売先へ届ける
商品を選ぶ	お客さんがAI上で商品を選び、購入へ進む
注文内容を確認する	Stripeが購入手続きを進め、必要な税金・手数料や注文の最終確認をお店側のシステムへ依頼する
支払いを完了する	Stripeが設定された方法で購入・支払いを処理し、AIへ結果を返す
商品を発送する	Stripeから購入完了の通知を受け、お店側が発送する

お店側には、正しい商品情報を用意し、価格や在庫を更新する作業が残ります。税金はStripe Taxに計算を任せる方法と、自社の計算結果を接続処理で返す方法を選べます。 運営会社の手数料や注文の最終確認も、採用する構成に合わせて設定します。Stripeを利用しても、商品管理や発送業務まで自動で代行されるわけではありません [10]。

複数のお店をまとめて連携する場合

ここで取り上げるStripeの公式ガイドは、複数のお店が使うECサービスの運営会社向けです。Stripeでは、この運営会社を「プラットフォーム」と呼びます。各店のStripeアカウントを接続し、運営会社が店ごとの商品一覧と購入処理を連携します [10]。

たとえば、複数の雑貨店が使うECサービスなら、運営会社が各店の商品一覧を送り、注文時の確認と購入完了の通知を受ける仕組みを用意します。各店は販売するAIの接続先への参加を選びます。以下は、この構成を使う会社の申請と設定の手順です。自社商品をOpenAIへ直接送るだけなら、Stripeへの申請も必須になるわけではありません [8][10]。

Stripeの利用申請で、最初に行う操作

1. Stripeの待機リスト申込ページを開きます。ページ名は「Join the waitlist for the Agentic Commerce Suite」です [13]。
2. 「Work email」に仕事用メールを入力し、「Country/Region」で事業を行う国を選びます。2026年9月10日に確認した最初の画面では、選択肢はカナダと米国でした。日本は選べません。 日本の事業者は別の国で代用せず、このフォームでは先に進めないと判断してください。
3. 対象国に該当する場合は「Continue」で次へ進み、表示された申請項目に沿って手続きします。今回確認したのは最初の画面までで、次画面の必須項目や送信完了画面は未確認です。

申込ページは北米向けの案内ですが、指定のプラットフォーム用ガイドは米国の事業者向け・待機リストの承認が必要と明記しています。カナダがフォームに表示されても、そのガイドの全機能がカナダで利用可能とは判断しません。申込ページは、個々の販売者、複数の店を支える会社、購入機能を組み込みたいAIサービスを受付対象として挙げています [10][13]。

Stripeで承認された後は、何を設定する？

承認後、対象のStripeアカウントでAgentic commerceの設定ページを開きます。未ログインならログイン画面へ進みます。以下は公式ガイドが説明する設定順で、今回、承認済みアカウントの画面内を操作した結果ではありません [10]。

1. 事業者情報の「Stripe Profile」を作る。
2. 購入者から受け取る代金の流れを設定する。店のStripeアカウントで決済する方式（direct charges）か、運営会社のアカウントで決済して店へ送金する方式（destination chargesとon_behalf_of）を選ぶ。どちらも購入者に商品を売る主体は店です。
3. 商品を販売するAIの接続先を有効にする。
4. 購入完了などの通知を受けるURL、領収書の形式、問い合わせ対応の方針を設定する。

その後、店ごとの商品一覧を用意し、テスト環境で読み込みを確かめます。税金をStripe Taxに任せるか、自社の計算を使うかを選び、必要な手数料や注文確認の接続処理も設定します。ここまで進めて初めて、商品情報と購入処理を自社の運用につなぐ作業になります。待機リストへの登録、利用承認、設定完了、本番での注文成功は、それぞれ別の段階です。

今行う操作は、自社の目的に合う申込ページを開き、対象条件を読むことです。対象なら事業情報を入力して申請し、対象外なら提供国や受付条件の更新を待ちます。

4. 注文APIを使う場合は、接続先と対応する版を確認する

ACPの正式名はAgentic Commerce Protocolです。商品情報の連携に加え、注文をやり取りするための公開仕様もあります。ここからは、注文APIの実装を検討する担当者向けです [5][6]。

OpenAIとStripeが管理するACPの公開リポジトリで、APIの仕様とデータの例を読めます。READMEではbetaとされています。すべてのAIサービスが共通で使える最終仕様、という意味ではありません [5]。

注文APIは、2026年9月10日時点でどこまで決まっている？

今できるのは、公開版を使った注文処理の試作と、販売したいAIサービスへの参加条件の確認です。 接続先を案内する仕組みまで、すべて完成しているわけではありません。

調べること	確認した状態	読者が今できること
注文APIと送受信データ	2026-04-17の公開版あり。ACP全体はbeta [5][6][7]	この版でテスト用の注文を作る。第6〜8章の形式検査と注文テストを使う
注文APIの認証	本稿のOpenAPIにはBearer方式の定義あり [6]	接続相手と、認証情報の発行・受け渡し・失効の担当を決める
APIの場所をAIに知らせるファイル	/.well-known/acp.json はProposal / unreleased（提案・未リリース）[11]	設計案として読み、接続先のサービスが採用しているか確認する
ChatGPTへの商品連携・購入機能	商品連携は承認済みパートナー向け。購入用プラグインは承認済みパートナーとの試験提供 [8][9]	公式案内の申請窓口で、自社が参加できるか確認する
外部サービスによる代理実装	Stripeには対象国・参加承認の条件付きで提供案内あり [10]	第3章で提供機能・対象国・申込画面を確認する

「公開版あり」は、その版を実装の基準にできるという意味です。今後変更されない最終仕様、どのAIでも利用できるという意味ではありません。「提案段階」の項目は、接続先から採用を確認できるまで、本番で動く前提にしません。

APIは、ECサイトと同じドメインに置く必要がある？

販売者の注文を処理できるAPIが必要ですが、販売者自身のサーバーで動かすこととは限りません。 確認した公開仕様には、商品ページとAPIを同一ドメインに置くことを必須とする条件は見当たりませんでした。APIを外部サービスに任せる構成も考えられます。実際に採用できる接続先は、参加するAIサービスの条件と合わせて確認します [6][10]。

「店側がAPIを作る」という説明の「店側」は、店の注文を処理する側という意味です。店が自社開発する場合も、ECサービスや外部事業者に実装・運用を任せる場合もあります。

構成の例	商品ページ	ACPのAPIを動かす場所
店が自分で用意	shop.example.com	店が管理するサーバー
店の専用サブドメインで外部に任せる	shop.example.com	外部サービス。接続用ドメインや証明書も設定する
外部サービスのドメインで受ける	shop.example.com	外部サービスの共通API

この表は構成の選択肢です。どのドメインでも無条件に接続が認められる、という保証ではありません。Stripeには、プラットフォームが複数の販売者の商品連携や購入処理を支える仕組みが公開されています。ただし、その案内では米国の事業者向けで、参加承認も必要です [10]。

エンドポイントを書けば、AIが自動で使ってくれる？

URLをページに書くだけでは、利用開始の設定は完了しません。 接続するAIサービスと、販売者の情報、APIの接続先、認証、支払い方法をそろえる必要があります。ChatGPTへの参加条件も別に確認します [8]。

ACPの公開リポジトリには、/.well-known/acp.json で接続先の api_base_url を案内する設計文書もあります。外部プラットフォームが複数の店を支える構成も記載されていますが、確認した文書の状態は Proposal / unreleased（提案・未リリース） です [11]。

提案されているのは「APIの場所と対応機能を、AIが決まった場所から調べられるようにする」仕組みです。 この文書では、接続先を知らせる共通の方法がない場合、APIのURLを別途伝える必要があると説明しています。購入を許可する認証や、AIの登録は、このファイルが扱う範囲には含まれていません [11]。

2026年9月10日に確認した文書には、正式提供の日付は示されていません。ファイルを置くだけで、ChatGPTが発見して注文を始めると期待する段階ではありません。

今は、販売したいAIサービスの窓口に「APIのURLはどの手順で登録するか」「この案内ファイルを採用しているか」を確認します。回答がない間も、店の商品ID・在庫・送料を使ったテストは進められます。採用が分かったら、そのサービスが指定する版と設定へ合わせます。公開リポジトリの状態と、接続相手の対応状況の両方が、見直しの判断材料になります。

最初のテストでは、受けたい注文を一つ決めます。たとえば「国内配送の水筒を一つ、通常価格で買う」と範囲を絞ります。名入れ、定期購入、複雑な割引などは、その後に必要性を確かめます。

これはACPが扱える商品の制限ではなく、初回の確認範囲を小さくするための進め方です。売りたい商品と注文の条件が決まれば、今ある機能で足りる部分も調べやすくなります。

5. 価格や在庫を決めるのは店側

AIが注文を進めても、販売条件を決めるのは店側です。 公式の説明でも、価格、税金、送料、在庫、支払い、発送は販売者が管理する役割になっています [1]。

ここからの金額は説明用の例です。水筒が3,000円、送料が500円なら、「お客さんが見る合計」と「店が請求する合計」が3,500円で一致するかを確かめます。配送先を変えて送料が上がった場合も、古い金額で進めてはいけません。

在庫にも同じ確認が必要です。AIが商品を紹介した時点では在庫があっても、注文するときには売り切れているかもしれません。紹介時の情報をそのまま信じるのではなく、受け付ける段階で買えるかを確認します。

変わる条件	店側で確かめたいこと
配送先	送料と配送できる地域が正しいか
商品の数量	合計額と在庫が更新されるか
割引の条件	対象外の商品まで値引きされないか
注文の時刻	受付の締め切りを過ぎていないか

この表は、自社の商品に合わせて作る確認表の例です。すべての店に同じ割引や締め切りがあるわけではありません。今の通販サイトで使っている条件を書き出し、AI経由でも同じ結果になるかを見ます。

6. 店側には、注文を扱う5つの窓口を作る

実装するのは、AIからの注文を今の通販システムへつなぐAPIです。 APIはシステム同士が情報をやり取りする窓口です。ACPの公開仕様には、その窓口の名前と、送受信するデータの形が書かれています [5][6]。

ここからは実装担当者と一緒に読む部分です。参照する版は 2026-04-17 に固定します。開発中の unreleased や、別の版のコード例を混ぜません。以下のURLは店側に作るAPIのパスで、OpenAIのAPIへ送信するものではありません。

店側に作るAPI	店のシステムで行う処理
POST /checkout_sessions	商品を調べ、購入手続きを作る。作成成功は201で返す
GET /checkout_sessions/{id}	保存した手続きの現在の状態を返す
POST /checkout_sessions/{id}	配送先などを更新し、在庫と金額を確かめ直す
POST /checkout_sessions/{id}/complete	支払いを処理し、注文の結果を返す
POST /checkout_sessions/{id}/cancel	完了前の手続きを取り消す

{id} には作成時に返した手続きのIDを入れます。これは注文番号とは別に管理します。既存のECに価格計算や受注の機能があれば、APIの内側からその機能を呼び出します。別の価格表を二重に作ると、サイトで買う場合との金額差が生まれやすくなります。

最初に送るデータ

次は、説明用の商品 bottle_001 を指定する作成リクエストです。JSONというデータ形式で送ります。currency は通貨、capabilities はAI側が扱える機能を伝える項目です。空の {} は、この例では追加機能を申告していないという意味です [6][7]。

{
  "line_items": [{"id": "bottle_001"}],
  "currency": "jpy",
  "capabilities": {}
}

この版の作成データでは、line_items、currency、capabilities が必須です。公開されている例を、そのままコピーすれば動くとは限りません。 同じ仕様ファイル内にも items を使った例が残っていますが、必須項目の定義とは一致しません [6][7]。

数量も確認が必要です。この版の作成用 Item には quantity の定義がなく、応答用 LineItem にはあります。次の応答例は店側で数量1とした説明用のケースです。複数個の注文を扱うときは、接続先が受け付ける形式を確認し、推測で項目を足さないようにします。

上のJSONを create.json として保存し、店側のテスト用APIへ送る場合は、次の形になります。接続先と認証情報を用意してから使うコマンド例です。記載したホスト名とキーはダミーです。

curl --request POST 'https://merchant.example.com/checkout_sessions' \
  --header 'Authorization: Bearer TEST_MERCHANT_TOKEN' \
  --header 'Content-Type: application/json' \
  --header 'API-Version: 2026-04-17' \
  --header 'Idempotency-Key: 94a2f603-c15c-4bf6-87b4-e36b43d7de90' \
  --data-binary @create.json

Authorization は相手を確認するための認証情報、API-Version は使う仕様の版です。Idempotency-Key は、同じ処理の再送を見分ける番号です。この版では、すべてのPOSTに必要とされています [6]。新しい操作には新しい番号、同じ操作の再送には同じ番号を使います。

店が計算して返すデータ

店側は商品IDから価格と在庫を調べ、手続きを保存して返します。下は、商品が3,000円で、まだ配送先が決まっていない段階の応答例です。金額は説明用の仮定です。送料確定前なので、支払いに進める状態にはしていません。

{
  "id": "cs_demo_001",
  "protocol": {"version": "2026-04-17"},
  "status": "not_ready_for_payment",
  "currency": "jpy",
  "line_items": [{
    "id": "li_demo_001",
    "item": {"id": "bottle_001"},
    "name": "水筒",
    "quantity": 1,
    "unit_amount": 3000,
    "totals": [{"type": "total", "display_text": "商品代金", "amount": 3000}]
  }],
  "totals": [{"type": "total", "display_text": "送料確定前の金額", "amount": 3000}],
  "fulfillment_options": [],
  "messages": [],
  "links": [],
  "capabilities": {}
}

totals は金額の内訳を並べる配列です。amount は通貨の最小単位で表す整数で、日本円なら3,000円を 3000 とします [7]。AIが送ってきた金額を請求額として採用せず、店の商品データから計算します。

この例はデータの形を示すものです。実際の応答では、足りない情報の案内、配送方法、利用規約へのリンク、対応する支払い方法も、自社の条件に合わせて返します。配送先と支払い方法がそろい、金額を確定できてから ready_for_payment に進めます [1][3]。

配送先と送料を更新する

配送先の入力後は、同じ手続きIDに対して更新します。たとえば POST /checkout_sessions/cs_demo_001 に、次のようなデータを送ります。住所と氏名はテスト用の例です。

{
  "fulfillment_details": {
    "name": "テスト購入者",
    "address": {
      "name": "テスト購入者",
      "line_one": "テスト町1-1",
      "city": "千代田区",
      "state": "東京都",
      "country": "JP",
      "postal_code": "1000001"
    }
  }
}

店は配送可能な地域かを調べ、配送方法と送料を返します。AI側が配送方法を選ぶ場合は、返された方法のIDを使って selected_fulfillment_options を更新します [6]。送料が500円なら、先ほどの商品代金と合わせて3,500円になることを確かめます。

更新のたびに在庫、送料、税金、適用する割引を計算し直します。古い送料や期限切れの割引が残らないよう、作成時と更新時で同じ計算処理を使う設計にします。

7. 支払いをつなぎ、注文ができたことを確かめる

支払い用の情報を受け取った後も、決済と受注の処理は店側で実装します。 ACPのデータを受け付けただけでは、請求も発送も完了しません [1][2]。

まず応答の capabilities.payment.handlers で、店が扱える支払い方法を伝えます。各方法にはID、方式の名前、版、決済サービス、設定内容などが必要です。実際に契約・接続した方法だけを返します [6][7]。

購入を完了するAPIには、次の形の payment_data が届きます。card_tokenized は店が事前に提示した支払い方法のIDと一致させます。spt_TEST_ONLY は説明用の文字列で、実際には決済できません。

{
  "payment_data": {
    "handler_id": "card_tokenized",
    "instrument": {
      "type": "card",
      "credential": {
        "type": "spt",
        "token": "spt_TEST_ONLY"
      }
    }
  }
}

この例は、カード番号そのものに代わる支払い用の情報を渡す形式です [7]。店は handler_id が提示済みのものかを確かめ、対応する決済サービスの処理へつなぎます。spt に対応しているか、どの認証情報で処理するかは、その決済サービスの案内で確認します。

実装担当者には、次の処理を依頼します。これは本番用の完成コードではなく、既存の受注・決済処理へ組み込むための設計例です。

1. 手続きの所有者と現在の状態を確認する。取り消し済みや完了済みの手続きで、新しい支払いを始めない。
2. 同じ Idempotency-Key の処理記録を調べる。完了済みなら保存した応答を返す。同じ番号で内容が違えば拒否する。
3. 在庫と最終金額を確認し、支払い処理のIDを保存する。同時に同じ注文が進まないよう、データベースの一意制約やロックを使う。
4. 決済サービスへ支払いを依頼する。この呼び出しにも、そのサービスの再送防止の仕組みを使う。
5. 結果を保存し、成功が確認できたら注文を一度だけ作る。手続きを completed にし、注文情報を付けて返す。

注文情報の order には、注文IDの id、元の手続きIDの checkout_session_id、注文確認ページの permalink_url が必要です [7]。自社の注文テーブルと手続きIDを結び付け、AIから照会されたときも同じ注文を返せるようにします。

支払いに成功した直後に店のシステムが止まることも想定します。復旧後に決済記録から結果を確かめ、注文の保存を再開できる設計が必要です。店のデータベースだけを元に戻しても、外部の決済まで取り消されるわけではありません。

通信はHTTPSで暗号化し、認証済みの相手の依頼だけを受け付けます。公式のセキュリティ案内には署名付きの通信も記載されています。上のcurl例は、署名を含む本番の接続設定をすべて示したものではありません。接続相手が指定する署名方式と検証手順も確認します [4][6]。支払い用トークンや住所を、調査用の記録へ丸ごと残さないことも決めます。

8. 買えなかったときの案内を先に決める

成功する注文だけでなく、途中で止まる注文を試します。 住所の入力不足、在庫切れ、支払いの失敗など、止まる理由によって次の案内が変わるからです。

ACPでは、情報が足りない状態、支払いへ進める状態、支払い中、完了、取り消しなどを区別します。完了した手続きを、完了前と同じ取り消し操作で戻すことはできません [3]。購入後の返品や返金は、店の対応手順として別に確認します。

たとえば、支払いの途中で通信が切れた場面を考えます。お客さんの画面に完了と出ていなくても、店側では注文ができているかもしれません。すぐにもう一度注文を作ると、二重の受注になるおそれがあります。

この場合に備え、どの注文を照会すれば結果が分かるかを決めておきます。結果が不明なまま再注文を勧めず、注文記録と決済の記録を確かめる手順を用意します。これは、AIを使うかどうかにかかわらず必要な運用上の確認です。

試す場面	確認できればよいこと
住所の一部が抜けている	足りない情報が分かり、入力を直せる
最後の在庫が別の人に売れた	買えないことを返し、注文を成立させない
支払いの結果が返らない	注文と決済を照会してから次を決められる
同じ依頼がもう一度届く	注文や請求が重複しないことを確認できる
注文後に返品を希望する	問い合わせ先と返品の手順へ案内できる

確認はテスト用の注文で行い、期待した結果と実際の結果を残します。「エラーが出た」で終わらせず、お客さんが何を見て、店には何が残ったかまで確認すると、問い合わせ対応にも使えます。

データの形式と、実際の注文を別々にテストする

ACPデータチェックで、この記事のJSON例や自社のテストデータを検査できます。最初は「サンプルで試す」から始めてください。入力はブラウザ内で処理します。商品をChatGPTに登録する機能ではなく、注文データの形式を確認するツールです。

掲載した4つのJSONは、参照した版のOpenAPI内の定義とJSON Schemaの両方で、必須項目と型を検査しています。これは、実際にChatGPTへ接続したり、決済を成功させたりした結果ではありません。

手元で作成データを検査する場合は、先ほどの create.json と、次のコードを保存した check_payload.py を同じフォルダーに置きます。この処理は公開仕様を取得してJSONの形を調べるだけで、注文や決済は行いません。

import json
from urllib.request import urlopen
from jsonschema import Draft202012Validator

commit = "7fdd78df677a94dce04c770644b0fbbb1401272b"
url = (
    "https://raw.githubusercontent.com/"
    "agentic-commerce-protocol/agentic-commerce-protocol/"
    f"{commit}/spec/2026-04-17/json-schema/"
    "schema.agentic_checkout.json"
)
with urlopen(url, timeout=30) as response:
    schema = json.load(response)
with open("create.json", encoding="utf-8") as source:
    payload = json.load(source)
validator = Draft202012Validator({
    **schema, "$ref": "#/$defs/CheckoutSessionCreateRequest"
})
validator.validate(payload)
print("作成データの形式を確認しました")

Python 3が使える環境で、次の順に実行します。専用の環境へ検査用ライブラリを入れる例です。

python3 -m venv .acp-check
.acp-check/bin/python -m pip install jsonschema
.acp-check/bin/python check_payload.py

成功したら items に書き換えたり、capabilities を削ったりして、エラーになることも試します。正しい例だけが通ることを確かめると、項目の変更を見逃しにくくなります。

実装時は、この形式検査に加えて、テスト環境で5つのAPIを順に呼びます。作成時の201、更新後の金額、完了後の注文番号、照会時の状態を確認します。取り消しは別の手続きを作って試します。

再送のテストも必要です。この版では、POSTの再送番号がなければ400、同じ番号の処理が進行中なら409、同じ番号で内容が違えば422という応答が定義されています [6]。同じ内容を再送した場合に、注文と請求が一つのままかも確かめます。

9. 売上は注文の記録で確かめる

AIからの訪問が増えたことと、ACP経由の注文が増えたことを分けて記録します。 AIとのやり取りの中で注文が進み、自社のページを人が開かない買い方も想定されるためです。

たとえば、AIの紹介からサイトに来た人が10人いても、その10人が注文したとは限りません。逆に、ページの訪問を記録できなくても、店のシステムには注文が届く場合があります。この数字は説明用であり、実測値ではありません。

AgentSignalでは、自社サイトへのAI経由の訪問や、ページ内の操作を確認する用途があります。ただし、サイトの計測タグだけでACPの注文や支払いをすべて把握できるわけではありません。購入の確認には、EC側の注文記録と決済の記録を使います。

まずは、受け付けた注文、完了した注文、失敗した注文を同じ期間で確認できるようにします。二重の受注や取り消しをどう数えるかも決めておけば、後から担当者が変わっても比較できます。

商品ページのHTMLや構造化データなど、AIが情報を読み取るための準備はAIO診断で確認できます。この診断はページの状態を調べるもので、ChatGPTの商品掲載や回答内容を確認する機能ではありません。まず商品情報と購入ページを整え、必要な接続方式が決まったら注文処理へ進みます。

申し込みへ進む方は、第1章のOpenAIのリンクから対象条件と入力欄を確認してください。商品情報を送り、価格や在庫を更新し、購入先へつなぎます。複数の店を支えるサービスは、第3章のStripeの方法も確認できます。注文APIが必要な場合に、第4〜8章の接続・実装・テストへ進みます。