エージェント型チェックアウト

TL;DR — エージェント型チェックアウトは、AIショッピングで「私の代わりに購入して」と頼む部分です。AIアシスタントが商品を見つけて購入を完了するとき、その最後の取引段階がエージェント型チェックアウトです。OpenAIの委任決済フローでは範囲限定の決済トークンを使い、ログインや追加認証など危険な処理では停止して人間へ制御を戻します。ACPとUCPという大きなプロトコルの一部であり、単独のものではありません。

エージェント型チェックアウトとは何か

AIショッピングの大部分は発見です。アシスタントに商品を探してもらうと、販売者の商品フィードを読み、選択肢を提案します。エージェント型チェックアウトはその後の段階で、エージェントが注文を作成し、配送方法を選び、税と送料を計算し、決済情報を渡して購入を確定します。

重要なのは段階だということです。エージェント型チェックアウトは独立した商品や会社ではありません。OpenAI と Stripe の Agentic Commerce Protocol (ACP)、Google と Shopify の Universal Commerce Protocol (UCP) に組み込まれた取引完了機能です。それぞれの概要は姉妹記事に譲り、このページではチェックアウトの仕組みに焦点を当てます。

よくある三つの誤解

• AIは人間の関与なしで購入する。 そうとは限りません。どちらのプロトコルにも、ログイン、追加カード認証、確認などで停止して人間に尋ねる段階があります。仕様は完全に手放しのチェックアウトを前提にしていません。
• AIはクレジットカードを見る。 いいえ。決済には範囲限定トークンが渡され、一つの販売者、一つの金額、一つの時間枠に固定され、一度だけ使えます。カード番号そのものがエージェントに届くことはありません。
• これはもう普通で、ほとんどの店舗が対応している。 これも違います。2026年半ばはまだ初期で、ChatGPTチェックアウトを開始したShopify店舗は約12店にすぎません。

問題が起きたときの責任者は誰か

購入先の店舗が引き続き販売者で、merchant-of-recordと呼ばれます。通常のオンライン購入と同じく、注文、返金、異議申立てを処理します。本当に難しいのは、買い手がAIエージェントだった場合に争われた請求をどう扱うかで、まだ完全な解決策はありません。詳しくはAdvancedタブで扱います。

状態機械、決済トークンの範囲、人間が介入する場所、導入前に販売者がテストすべき項目を知りたい場合は、Advanced に切り替えてください。

TL;DR — エージェント型チェックアウトは、チェックアウトセッションを作成・更新・完了またはキャンセルし、決済を委任して注文を確認する取引完了機能です。ACP と UCP の構成要素の一つであり、単独のプロトコルではありません。技術的な中核は 状態機械です。ACP は not_ready_for_payment → ready_for_payment → 必要なら requires_escalation / authentication_required → completed と進み、UCP の incomplete → requires_escalation → ready_for_complete に対応します。エスカレーション状態は人間参加の接点です。決済委任には販売者固定・金額上限・時間制限・単回使用の範囲限定トークンを使います。注文確認はプッシュ通知で、販売者は HMAC 署名付きの完全なオブジェクトを Webhook で POST します。チャージバックの証拠の枠組みは 2026 年半ば時点でも未解決です。

範囲: 全プロトコルではなく、取引の段階

エージェント型チェックアウトは一つの機能です。ACPではAgentic Checkoutブロックで、Product Feed、Delegate Payment、Delegate Authentication、Orders/Webhooksと並ぶ五つのブロックの一つです。UCPでは広い機能交渉型仕様の中にあるチェックアウト機能です。姉妹記事は周辺のプロトコルとビジネス背景を扱いますが、このページは取引完了の仕組み、つまりセッションのライフサイクル、決済委任、人間の介入、注文確認、責任に集中します。UCPの/.well-known/ucpプロファイルや、2026年3月の方針転換が発見に与えた影響はここでは再説明しません。

ACP の姉妹記事から引き継ぐ前提が一つあります。エージェントはクロールされた HTML ではなく、フィードと API に対して取引します。したがって最適化するのはページのコピーではなく、チェックアウトの 信頼性です。

チェックアウトセッションの状態機械

最も重要な点は、チェックアウトが 状態を持つセッションであり、その状態が定義された機械の中を進むことです。

ACPのCheckoutリファレンスには、incomplete、not_ready_for_payment、requires_escalation、authentication_required、ready_for_payment、pending_approval、complete_in_progress、completed、canceled、in_progress、expiredが記載されています。成功経路はnot_ready_for_payment → ready_for_payment → in_progress → completedで、もう一つの終端状態はcanceledです。ACPのライフサイクル概念では、必須のフルフィルメント選択肢を提供するとセッションがnot_ready_for_paymentからready_for_paymentへ移り、決済失敗時には再試行のためready_for_paymentへ戻ることがあります。

興味深いのは、成功経路にない状態です。

• requires_escalation / authentication_required — エージェントだけでは進められず、人間または追加認証が必要です。 - pending_approval — B2B の発注書承認などを待っています。 - expired — セッションがタイムアウトしました（CheckoutSession には expires_at が含まれます）。

UCPのチェックアウトもincomplete → requires_escalation → ready_for_completeと進み、requires_escalationを通じてcontinue_urlで人間に制御を戻します。別々の二つのプロトコルに収束した同じパターンです。**チェックアウトは、常に人間への確認なしで完了できるとは限りません。**これは後付けの制限ではなく、設計の中心です。

ACP に対する実務的な注意です。不正なリクエストは invalid_request、request_not_idempotent、processing_error、service_unavailable のいずれかを type に持つ HTTP レベルのエラーオブジェクトを返します。正しいセッション内のビジネスロジック上の問題は、HTTP エラーではなく messages[] 配列内の MessageError オブジェクトとして返ります。両方を処理する必要があります。

決済委任の仕組み

決済委任レイヤーの要点は、カード情報そのものがエージェントに届かないことです。カード番号を渡す代わりに、買い手の決済情報を 範囲限定トークンに変換します。

OpenAI の Delegated Payment 仕様では、委任決済のペイロードを販売者の PSP またはボールトへ直接送り、PSP またはボールトが PCI の範囲外で委任決済に限定した決済トークンを返します。そのトークンは四つの軸で制限されます。

• reason — 現在の値は"one_time"で、1回だけ使います。
• max_amount — チェックアウトの合計額を上限とし、過剰請求には使えません。
• expires_at（RFC 3339）— トークンには厳格な有効期限があります。
• merchant_id + checkout_session_id — 一つの販売者と一つのセッションに固定されます。

委任トークンは、販売者固定・金額上限・時間制限・単回使用です。これによりエージェントは、再利用可能なカード資格情報を保持することなく決済できます。ACPではStripeのShared Payment Tokenが最初の対応実装として説明され、今後さらにPSPが増える見込みです。UCPは決済instrumentとhandlerを分離する並行モデルを使います。

**PCI対象範囲はここで実際に判断すべき事項です。**OpenAIの仕様は、Delegated Payment Specとの直接統合ではカード会員データを直接扱うためPCI対象範囲に影響し得ること、また直接統合にはPCI DSSレベル1が必要なことを明記しています。多くの加盟店にとっては、ネットワークトークンや委任を処理するPSPによるトークン化経路が、カード会員データを自社環境から出しておく方法です。「CHDを直接扱う」か「PSPにトークン化させる」かが最初のアーキテクチャ判断で、Decisionタブで整理します。

人間が介入しなければならない場所

「買い物客が承認する」という説明は正しいものの曖昧です。プロトコルレベルのトリガーは具体的であり、名前を明示することで、行き止まりにせず引き継ぎを設計できます。

• 3-D Secure / step-up。 ACPはInterventionCapabilitiesでモデル化します。対応型は3dsとaddress_verification、enforcementはalways / conditional / optional、display_contextはnative / webview / modal / redirectです。結果はAuthenticationResultとして返り、authenticated、denied、rejected、abandoned、canceled、not_supportedなどになります。
• requires_escalation / authentication_required状態。 人間または追加チェックが必要だというセッション状態です。
• B2Bのapproval_required。 PaymentDataはB2Bフィールド（purchase_order_number、payment_terms、due_date、approval_required）を持ち、エージェント型チェックアウトはDTCだけではありません。
• UCPのcontinue_url引き継ぎ。 UCPのrequires_escalationは、買い手自身がログイン、確認、年齢チェックを完了するためのcontinue_urlを提示します。同じ接点でも、プロトコルは異なります。

要点は、きれいにエスカレーションする取引のほうが、黙って行き止まりになる取引より優れていることです。経路を第一級のフローとして設計してください。

注文確認はプルではなくプッシュ

購入後、エージェントのプラットフォームは注文状態を求めて API をポーリングし続けません。販売者が署名付き Webhook をプッシュします。

ACP の Webhook リファレンスによると、販売者は注文イベントを POST して同期を保ちます。イベント型は新規注文の order_create と状態変更の order_update です。注文状態には created、manual_review、confirmed、canceled、shipped、fulfilled が含まれます。実装上の重要点は三つです。

• リクエストは署名必須です。 Merchant-Signature ヘッダーの HMAC 署名を使います。署名なしまたは不正な署名は 401 です。 - data には完全な Order オブジェクトを入れます。 差分ではなく、毎回全状態を送ります。 - 処理するレスポンス: 200 は成功、401 は署名不正、429 はレート制限です。

注文が通ったことをプラットフォームはどう知るのでしょうか。署名付きの完全なオブジェクトをPOSTしてこちらから伝え、プラットフォームの429によるバックプレッシャーを処理します。

不正、チャージバック、責任 — 決着したことと未決着のこと

ここは最も率直で差別化される節です。決着済みと未解決の境界がどこにあるのかを、明確に説明します。 “settled” “open”

決着していること: merchant-of-record。 OpenAI 自身の決済仕様は、OpenAI が merchant-of-record ではないと述べています。ACP では販売者が自分の PSP を用意し、精算、返金、チャージバック、コンプライアンスは販売者と PSP に残ります。Rye の Arjun Bhargava も独立に、両プロトコルは販売者を merchant-of-record とし、フルフィルメント、チャージバック、異議申立ての責任を負わせると確認しています。

決着していないこと: チャージバックの証拠の枠組み。 merchant-of-record という立場は、既定では誰が異議申立ての負担を負うかを示すだけです。買い手が AI エージェントに仲介された場合に、どう勝つかは示しません。従来の防御は IP、端末、閲覧行動、人間が購入をクリックした記録など、人間が作った証拠に依存します。エージェント生成の認証ログは別種の証拠であり、カードネットワークのルールはそれを前提に書かれていません。業界の分析でも、カードネットワーク、発行者、プラットフォーム提供者がまだ答えを検討中です。 “customer” “buy”

新しい枠組みは登場中で、完成していません。 Visa の Trusted Agent Protocol は、利用者体験を損なわずに販売者がエージェントの身元と意図をリアルタイムで検証し、なりすましを防ぐ標準ベースの枠組みと説明されています。Mastercard の Agent Pay（2025 年 4 月発表）は Digital Enablement Service の拡張である Agentic Tokens を使います。第三者報道では、トークンが正しく発行され承認時に受け入れられた場合の不正責任は標準的なトークン取引と同じとされますが、Mastercard 自身の文書で確認されるまでは報告として扱います。Visa の消費者向け無過失責任保証はカード保有者を守るもので、販売者側のチャージバック問題は解決しません。

販売者が実装してテストすべきこと

既存の内容は、フィードの整理やロイヤルティプログラムなど戦略面の準備を扱います。ここでは、導入を有効にする前に実際に構築して検証する運用レイヤーを扱います。

• PCI の方針を決める。 トークン化またはネットワークトークンの経路と、CHD を直接扱う Level 1 の経路を比較します。多くの販売者は PSP に委任を保持させます。 - 再試行を冪等にする。 ACP に request_not_idempotent エラー型があるのは理由があります。エージェントや不安定なネットワークは作成・完了を再試行するため、冪等性キーを送り、同じキーの反復呼び出しを安全にして二重請求や二重注文を防ぎます。 - Webhook 署名を検証する。 受信する注文 Webhook ごとに Merchant-Signature HMAC を検証し、不一致を拒否し、負荷時も 200 / 429 を正しく返します。 - エスカレーションをサンドボックスで模擬する。 requires_escalation / authentication_required を強制し、3DS step-up を実行して、AuthenticationResult が denied / rejected / abandoned も扱うことを確認します。 - フィードとチェックアウトの価格を一致させる。 フィードの価格とチェックアウトの価格が違うと信頼が急速に失われます。 - エージェント注文の帰属を用意する。 完了したエージェント型チェックアウトには GA4 セッションがない場合があるため、訪問を待たず注文または OMS レベルで追跡します。 authenticated

テスト手順書とチートシートのタブで、これを具体的な合格判定に落とし込みます。

2026 年半ばの状況

宣伝資料ではなく導入の現実を見てください。Shopify の社長 Harley Finkelstein によると、AI チェックアウトツールを実際に使っていた Shopify 販売者は約 12 社で、全体の販売者数に比べれば無視できる規模でした。OpenAI も、導入、精度、複数商品カートの難しさを受け、2026 年 3 月に Instant Checkout の完全なチャット内版を発見とリダイレクトへ縮小しました。数千万 SKU のリアルタイムカタログ正規化は十年規模の問題であり、消費者は Apple Pay、Google Wallet、Amazon ワンクリックなど信頼するチェックアウトを今も選びます。

これはエージェント型チェックアウトが実体のないものだという意味ではありません。委任決済と署名付き注文Webhookを使ってセッションをプログラムから作成・更新・完了するプロトコル機能は、実在し、仕様化され、構築する価値があります。ただし「もう普通」ではなく、最後の段階をチャット内で閉じるかサイトで閉じるかは実装の選択で、すでに一度変わっており、今後も変わり得ます。

AI サマリー

Advanced 版の要約です。

• エージェント型チェックアウトは取引完了の段階です。 エージェントが買い手に代わってチェックアウトセッションを作成、更新、完了、キャンセルします。ACPとUCPの構成要素であり、独自プロトコルではありません。
• 状態機械です。 ACPはnot_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required) → completedと進み、成功経路外にはcanceled、expired、pending_approvalがあります。UCPのincomplete → requires_escalation → ready_for_completeにも対応します。
• エスカレーション状態は人間参加の接点です。 ログイン、3DS、住所確認、B2Bのapproval_required、UCPのcontinue_urlが該当し、完全自律の人間ゼロのチェックアウトを仕様は前提にしていません。
• 決済は範囲限定トークンです。 販売者固定（merchant_id + checkout_session_id）、金額上限（max_amount）、期限（expires_at）、単回使用（reason: one_time）で、エージェントはカード番号を保持しません。CHDの直接処理はPCI対象範囲（レベル1）に影響し、多くの加盟店はPSP／トークン化経路を使います。
• 注文確認はプッシュです。 販売者はMerchant-Signature付きHMAC署名の完全オブジェクトWebhook（order_create / order_update）をPOSTし、200 / 401 / 429を処理します。
• 責任。 販売者はmerchant-of-recordであり、精算・返金・チャージバックは販売者とPSPが担いますが、AIが行った購入のチャージバック証拠は2026年半ば時点で未解決です。Visa TAPとMastercard Agent Payは発展中で、完成した枠組みではありません。
• テスト。 冪等性を保つ再試行（request_not_idempotent）、Webhook署名検証、エスカレーション／3DS経路の模擬、フィードとチェックアウトの価格一致、エージェント注文の帰属（GA4セッションなし）を検証します。
• 導入は初期です。 OpenAIが2026年3月に発見とリダイレクトへ方針転換する前に、Shopifyで稼働していた加盟店は約12社でした。

公式ドキュメント

チェックアウトの仕組みに関する一次資料です。

ACP — チェックアウト、ライフサイクル、Webhook

• ACP Checkout APIリファレンス — チェックアウトセッションのエンドポイント、完全な状態enum、CheckoutSessionのフィールド、エラーとMessageError、RiskSignals、AuthenticationResult、InterventionCapabilities。
• ACP Checkoutのライフサイクルと概念 — フルフィルメント選択肢からready_for_paymentへの状態遷移と、決済失敗時の再試行。
• ACP注文Webhook — order_create / order_update、Merchant-Signature HMACの要件、完全なオブジェクトのペイロード、レスポンスコード。
• GitHubのACP仕様 — OpenAPI／JSON Schemaと日付ベースのバージョン。

OpenAI / Stripe — 決済委任

• OpenAI Delegated Payment仕様 — 範囲限定トークンの流れ、許可オブジェクト（max_amount、expires_at、merchant_id、checkout_session_id、reason）、PCI対象範囲の注記、merchant-of-recordの説明。
• OpenAI Commerceドキュメント — 販売者統合の概要。
• Stripe — エージェント型コマース（ACP） — Shared Payment Tokenと、最初のDelegated-Payment対応実装。
• Stripe — ACPプロトコル仕様 — チェックアウトエンドポイントの構築。

UCP（並行するチェックアウト機械）

• Google for Developers — UCPガイド — Google／Shopify側のmerchant-of-recordと適格性の考え方。

プラットフォーム／決済ネットワーク

• Shopify — Agentic Storefrontsの要件 — Supplemental Termsと、調査時点でのGoogle AI Mode／Gemini早期アクセス状況。
• Visa — エージェント型コマース：脅威とリスク — Trusted Agent Protocolの考え方。

原文からの引用

エージェント型チェックアウトの動作と未解決の問いについて、記録された発言を示します。ディープリンクは、出典ページで対応する引用箇所へ移動します。

ACP / OpenAI — 仕様

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (翻訳)「在庫、価格、税計算、決済処理を完全に管理するのは販売者です。」 — ACP Checkout APIリファレンス。 引用箇所へ
• チェックアウトの状態列挙（原文どおり）：“incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (翻訳)「未完了、決済準備前、エスカレーション要求、認証要求、決済準備完了、承認待ち、完了処理中、完了、キャンセル、処理中、期限切れです。」 — ACP Checkout APIリファレンス。 引用箇所へ
• “OpenAI is not the merchant of record.” (翻訳)「OpenAIはmerchant-of-recordではありません。」ACPでは販売者が自分のPSPを用意し、精算、返金、チャージバック、コンプライアンスは販売者とPSPに残ります。 — OpenAI Delegated Payment仕様。 引用箇所へ
• 決済トークンについて：PSPまたはボールトは、“payment token scoped to the delegated payment” (翻訳)「委任決済に範囲を限定した決済トークン」をPCI対象範囲外で返します。 — OpenAI Delegated Payment仕様。 引用箇所へ

業界の声 — 責任の問い

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (翻訳)「エージェント型コマースは効率をもたらしますが、従来のシステムでは解釈できない不正と混乱の新たな層も生みます。」 — Ben Herut（不正・チャージバック戦略担当、Chargeflow）。 報道を読む
• ルールが決着したかについて、Chargeflowの分析は*“there are no clean answers yet”* (翻訳)「まだ明確な答えはありません」と述べています。カードネットワーク、発行会社、プラットフォーム提供者は現在もこの問題に取り組んでいます。 報道を読む
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (翻訳)「どちらのプロトコルでも、販売者はmerchant-of-recordとして、フルフィルメント、チャージバック、紛争に責任を負います。」 — Arjun Bhargava（共同創業者兼CEO、Rye）。 報道を読む

決済ネットワーク — 発展中の枠組み

• Visaのアプローチについて：Trusted Agent Protocolは、“a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (翻訳)「利用者体験を損なわずに販売者がエージェントの身元と意図をリアルタイムで検証し、なりすましを防ぐ標準ベースの枠組み」です。 — Visa『エージェント型コマース：脅威とリスク』。 引用箇所へ

導入の現実

• 完全自律のチェックアウトが期待ほど速く進まない理由について：“Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (翻訳)「数千万SKUにまたがるリアルタイムのカタログ正規化は、GoogleがMerchant Centerですでに解決した10年規模の問題であり、消費者は今もApple Pay、Google Wallet、Amazonワンクリックなど信頼するチェックアウトを選びます。」 — Leigh McKenzie（Semrushオンライン可視性ディレクター、Search Engine Land経由）。 報道を読む

どの決済統合経路を選ぶべきか

エージェント型チェックアウトで最初の本格的なアーキテクチャ判断は、決済をどう委任するかです。PCI の範囲と構築量を直接決めるためです。順に検討します。

本番前のエージェント型チェックアウトテスト

本番で有効にする前に、サンドボックスまたはテストモードで実行します。戦略的なフィード整理の助言を、実際の運用レイヤーに落とし込むテストです。 “clean your feed”

1. チェックアウトセッションを作成し成功経路を進める。 POST /checkout_sessionsで201とnot_ready_for_payment（またはincomplete）のセッションを確認します。フルフィルメント選択肢を追加し、状態がready_for_paymentへ遷移することを確認します。
2. 合計額が正しいことを検証する。 セッションのtotals[]（小計／税／フルフィルメント／割引／合計）がバックエンドの計算と一致し、価格がフィードと一致することを確認します。
3. セッションを完了する。 POST /checkout_sessions/{id}/completeで決済が処理され注文が作成され、状態がcompletedになることを確認します。
4. セッションをキャンセルする。 POST /checkout_sessions/{id}/cancelで在庫が解放されることを確認します。
5. エスカレーション経路を強制する。 requires_escalation／authentication_requiredを模擬し、3DS step-upを実行して、AuthenticationResultがdenied、rejected、abandoned、canceled、not_supportedを扱い、authenticatedだけを成功として扱っていないことを確認します。
6. 冪等性をテストする。 同じ冪等性キーで作成／完了リクエストを二度送り、一つの注文になることを確認します。真に非冪等な再試行では二重請求ではなくrequest_not_idempotentが返ることも確認します。
7. ビジネスロジックエラーとHTTPエラーを分ける。 在庫切れなどのセッション内問題がmessages[]のMessageErrorとして返り、不正なリクエストがHTTPレベルのエラーオブジェクトとして返ることを確認します。
8. Webhook署名を検証する。 有効なorder_create WebhookではMerchant-Signature HMACを検証して200を返し、改ざんしたものは401で拒否します。差分ではなく完全なOrderオブジェクトを送ることも確認します。
9. Webhookのバックプレッシャーをテストする。 プラットフォームからの429に再試行とバックオフで対応し、イベントを捨てないことを確認します。
10. 帰属の記録を確認する。 完了した注文がOMSレベルでエージェント起点としてタグ付けされ、GA4セッションがなくても追跡できることを確認します。

よくある誤りと代替策

エージェント型チェックアウトを完全自律・人間なしの購入だと思う。 誤りです。実装には requires_escalation、authentication_required、3DS、B2B の approval_required という接点があります。対策は、continue_url、3DS、承認を第一級のフローとして設計することです。 “agentic checkout”

話題が大きいので既に普通だと思う。 2026 年 3 月の方針転換前に ChatGPT チェックアウトを開始した Shopify 販売者は約 12 社にすぎません。対策は、実在するプロトコル機能を使いながら先行導入者として計画することです。

merchant-of-record が決着したので不正責任も解決済みだと思う。 merchant-of-record は精算、返金、コンプライアンスの責任者を示しますが、AI が買い手のときに承認された取引だと証明するチャージバック証拠の枠組みは未解決です。エージェント認証ログとリスク信号を保存し、Visa TAP と Mastercard Agent Pay を発展中の枠組みとして扱います。 “merchant-of-record”

エージェントはサイトを飛ばすので、サイトのチェックアウトは重要でないと思う。 誤りです。ChatGPT Instant Checkoutの初期の売り文句とは異なり、ACPの旗艦実装は2026年3月に発見とリダイレクトへ移りました。プロトコルの機能は実装に依存しません。

エージェントが顧客のカード番号を扱うと思う。 設計上、カード情報そのものは届きません。範囲限定・委任トークンが決済委任の要点です。PSP 経由で販売者固定・金額上限・単回使用のトークンを使い、PCI の範囲を小さくします。

冪等性のない再試行を行う。 エージェントとネットワークは再試行します。ACP の request_not_idempotent は、再試行が二重請求や二重注文を作るためです。作成・完了に冪等性キーを必須にし、同じキーの再呼び出しを安全にします。

エージェント型チェックアウト — チートシート

ACP チェックアウトセッションの状態 enum

| 状態 | 意味 | | --- | --- | | incomplete / not_ready_for_payment | カートと詳細を組み立て中 | | ready_for_payment | フルフィルメント設定済みで決済可能 | | requires_escalation / authentication_required | 人間または追加認証が必要 | | pending_approval | 承認待ち（B2B の PO 承認など） | | complete_in_progress / in_progress | 完了処理中 | | completed | 終端 — 注文作成済み | | canceled | 終端 — 在庫解放済み | | expired | セッションがタイムアウト（expires_at） |

UCP の並行機械は incomplete → requires_escalation（continue_url 経由で人間）→ ready_for_complete です。

チェックアウトエンドポイント（ACP） - POST /checkout_sessions — 作成（201） - GET /checkout_sessions/{id} — 取得 - POST /checkout_sessions/{id} — 更新 - POST /checkout_sessions/{id}/complete — 決済処理と注文作成 - POST /checkout_sessions/{id}/cancel — キャンセルと在庫解放

範囲限定決済トークン — 四つの制限

• merchant_id + checkout_session_id → 販売者とセッションに固定
• max_amount → 金額上限
• expires_at（RFC 3339）→ 時間制限
• reason: "one_time" → 単回使用

注文Webhook（ACP）

• イベント: order_create、order_update
• 署名: Merchant-Signature HMACヘッダー（必須）
• ペイロード: 差分ではなく完全なOrderオブジェクト
• 応答: 200 成功・401 署名不正・429 レート制限
• 注文状態: created・manual_review・confirmed・canceled・shipped・fulfilled

人間介入のトリガー - requires_escalation / authentication_required 状態 - InterventionCapabilities（3ds、address_verification、always / conditional / optional） - AuthenticationResult の結果（authenticated / denied / rejected / abandoned など） - B2B の approval_required、UCP の continue_url

責任の概要 - Merchant = merchant-of-record → 精算・返金・チャージバックは販売者 + PSP が担当し、決着済み - エージェント買い手のチャージバック証拠ルール → 2026 年半ば時点で未解決 - Visa TAP / Mastercard Agent Pay → 発展中で未完成

エージェント型チェックアウトのスニペット

これはライブ購入を実行するものではなく、自分の統合を検査・テストするためのものです。サンドボックスまたはテスト資格情報を使います。

Webhook 署名を検証する（Node.js、HMAC）

Merchant-Signature が一致しないものは拒否します。定数時間で比較してください。

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

チェックアウトセッションの状態をポーリングする（shell）

テスト中にサンドボックスセッションが状態機械を進む様子を監視します。

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

冪等性キー付きの作成呼び出しを送る（Python）

同じキーでの再試行が二つではなく一つの注文になることを証明します。

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

.well-known UCP プロファイルを描画ページから探すコンソールスニペット

販売者が UCP の発見情報を公開しているかを、販売者のオリジン上のブラウザコンソールに貼り付けて確認する簡単な DevTools チェックです。

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

ACP ドキュメントのチェックアウト状態 enum へ移動するブックマークレット

状態一覧を開くブックマークに貼り付けます。

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

エージェント型チェックアウトのよくある失敗

再試行で二つの注文または請求が作られる

症状: タイムアウトやネットワーク再試行の後、同じチェックアウトセッションが重複注文を作ります。原因候補: 作成または完了の呼び出しがキー付けされず、再生安全でありません。対策: 冪等性キーを必須にし、同じキーの再試行で元の結果を返し、同一のサンドボックス呼び出しが一つのセッションと一つの注文になることを確認します。

チェックアウトが決済可能にならない

症状: セッションが not_ready_for_payment または incomplete のままです。原因候補: 必須のフルフィルメント選択、住所フィールド、業務ルールが未解決です。対策: 必須フィールドと messages[] を調べ、不足する選択肢を渡し、ready_for_payment または ready_for_complete へ進むことを確認します。

有効なリクエストが成功したように見えるのにカートを完了できない

症状: HTTP リクエストは成功したのに、セッションには在庫切れなどのビジネスエラーがあります。原因候補: クライアントが HTTP エラーだけを処理し、MessageError を無視しています。対策: 転送エラーとセッションメッセージの両方を処理し、利用者またはエージェントが実行可能な失敗内容を受け取ることを確認します。

人間による認証が黙って行き止まりになる

症状: チェックアウトが requires_escalation または authentication_required に入り、戻りません。原因候補: 3DS、ログイン、承認、continue_url の引き継ぎを、対応可能な状態ではなく例外エラーとして扱っています。対策: 引き継ぎをまたいでセッションを保持し、すべての認証結果を処理し、成功と中断の両方がきれいに解決することを確認します。

決済後に注文状態の更新が止まる

症状: 販売者には注文があるのに、エージェント画面は保留または古い状態のままです。原因候補: Webhook 署名が失敗した、差分だけ送った、または 429 を捨てています。対策: 正確なペイロードに署名し、完全な Order オブジェクトを送り、レート制限イベントをバックオフ付きで再試行し、受信側が受け入れることを確認します。

エージェント型チェックアウトのメンタルモデル

チェックアウトは単一 API 呼び出しではなく状態機械

すべてのレスポンスはセッションを既知の状態へ進めるか、進めない既知の理由を示すべきです。一つの購入リクエストではなく、遷移、終端状態、再試行、エスカレーションを中心にクライアントを設計します。 “buy”

権限は販売者に残る

エージェントは意図を表しますが、価格、在庫、税、フルフィルメント、注文状態、merchant-of-record の義務については販売者が権威を持ちます。エージェントが要求したカートは入力とし、販売者が返したカートを真実として扱います。

委任は権限を狭める

範囲限定決済トークンが安全なのは、販売者固定、セッション固定、金額上限、時間制限、単回使用だからです。委任された機能ごとに、何ができ、誰に対して、いくらまで、どれだけの期間できるかを確認します。

エスカレーションは成功する分岐

人間の介入は自律チェックアウトの失敗ではありません。3DS、ログイン、住所、B2B 承認をきれいに引き継ぐことは、仕様どおりにプロトコルが動いている状態です。

完了後の配送は非同期

決済の完了で統合は終わりません。署名付きの完全な Webhook がチェックアウト後の注文の真実を運ぶため、署名検証、再生安全性、再試行処理はチェックアウトの信頼性の一部です。

エージェント型チェックアウトの指標

終端状態ごとのチェックアウト完了

• 指標: 開始したセッションのうち、完了、キャンセル、期限切れになったセッションの割合。 - 分かること: チェックアウト状態機械がどこで終わり、注文前にどれだけ意図が失われたか。 - 取得方法: コマース API または注文プラットフォームから状態変更を集計し、プロトコルと販売者の面で分けます。 - ベンチマーク / 現実的な範囲: 自社の商品構成の基準値を作り、同条件のフローを比較します。導入段階では普遍的な率を正当化できません。 - 頻度: 毎日監視し、毎週トレンドを確認します。

エスカレーション回復率

• 指標: 3DS、ログイン、住所、承認の介入後に戻って完了したエスカレーションセッション。
• 分かること: 人間への引き継ぎが使える経路か行き止まりか。
• 取得方法: エスカレーションイベントと後続の状態遷移をチェックアウトセッションIDで結合します。
• ベンチマーク／現実的な範囲: 認証とB2B承認では摩擦が異なるため、介入型ごとに基準値を作ります。
• 頻度: 毎週、また引き継ぎフロー変更後に確認します。

重複注文と Webhook 失敗率

• 指標: 同じキーの再試行による重複注文と、拒否または枯渇した Webhook 配信。 - 分かること: 障害時に冪等性と非同期注文同期が安全か。 - 取得方法: アプリケーションログで冪等性キー、注文 ID、署名失敗、401、429、再試行、デッドレターイベントを比較します。 - ベンチマーク / 現実的な範囲: 重複注文はゼロにし、通常の一時再試行の基準値を作り、継続的な逸脱を調べます。 - 頻度: 直ちに警告し、毎週まとめます。

時間を使う価値のあるリソース

関連する私の執筆 - このサイトでは、エージェント型チェックアウトを含む二つのプロトコルを詳しく扱っています。Agentic Commerce Protocol (ACP) と Universal Commerce Protocol (UCP) を参照してください。このページは両方の下にあるチェックアウトの仕組みの深掘りです。 - The Beginner’s Guide to Ecommerce SEO — エージェント向けチェックアウトが e コマース全体のどこに入るかを説明します。

私の講演 - How Search Works（SlideShare）— 発見、インデックス、ランキングの解説です。エージェントが仲介する取引レイヤーがその上にどう載るかを理解する背景になります。 “This is my understanding of systems… not going to be 100% complete or accurate.”

業界周辺の資料

• エージェント型コマース・プロトコル — チェックアウトリファレンス（OpenAI／Stripe）— 権威ある状態enum、セッションフィールド、介入・認証オブジェクト。
• OpenAIのDelegated Payment仕様 — 範囲限定トークンの流れとmerchant-of-record／PCI対象範囲の説明。
• ACP注文Webhookリファレンス（OpenAI／Stripe）— プッシュ型、HMAC署名付き、完全オブジェクトによる注文同期の仕組み。
• エージェント型コマースのチャージバック：AIが購入したときの責任は誰にあるか（Chargeflow）— 証拠問題について「まだ明確な答えがない」という率直な分析。
• エージェント型コマース：脅威とリスク（Visa）— Trusted Agent Protocolとエージェントの身元に関する説明。
• OpenAIのChatGPT Instant Checkout計画が変更された（Search Engine Land）— 2026年3月の方針転換と導入現実に関する引用。
• エージェント型チェックアウトとは？（Rye）— 独立した明確な定義とmerchant-of-recordの裏付け。
• 深掘り：Mastercard Verifiable IntentとVisa Trusted Agent Protocol（Fintech Wrap Up／Finextra）— 決済ネットワークの枠組みを比較し、責任配分は確認済みではなく報告として扱います。

引用する価値のある統計

エージェント型チェックアウトの現在地を示す数字です。販売者の報告や伝聞の数字は方向性として扱い、重視する前に確認してください。

• 約12社。 Shopifyの社長の説明をSearch Engine Landが伝えたもので、AIチェックアウトツールを実際に使っていたShopify加盟店は約12社にとどまり、全加盟店数に比べれば無視できる規模でした。出典
• 2026年3月の方針転換。 OpenAIは導入、精度、複数商品カートの摩擦を受け、ChatGPTのInstant Checkoutを完全なチャット内購入から発見とリダイレクトへ移しました。出典
• トークンの範囲は四つ。 委任決済トークンはmax_amount、expires_at、merchant_id／checkout_session_id、reason: one_timeで制限され、カード番号をエージェントから遠ざけます。出典
• Webhookのルールは常に完全オブジェクト。 ACPはWebhookのdataフィールドに差分ではなく完全なOrderオブジェクトを入れ、すべてのリクエストにHMAC署名を要求します。出典

自分で確認する: エージェント型チェックアウト

チェックアウトの仕組みに関する簡単な五つの質問です。回答を選んでから確認してください。

変更履歴