PayPalのAI買い物対応とは？Store SyncとAgent Readyの役割

PayPalのAI買い物向けサービスは、会話で商品を探す人に店の商品を届け、そのまま購入や支払いにつなぐためのものです。日本のEC担当者にとっては、既存の商品・注文管理や決済をどこまで活用できるかを考える材料になります。[1][5]

PayPalボタンを設置済みでも、AIへの商品連携やAI内の購入対応まで完了したとはいえません。 まず商品・注文をつなぐ「Store Sync」と、支払いを担う「Agent Ready」を分け、自社に不足する連携を整理しましょう。

本記事は2026年9月10日時点の公式案内に基づく基礎解説です。日本の事業者の参加資格は確定できていないため、導入完了までの手順ではなく、サービスの選び分けとPayPal掲載の接続例を説明します。

1. 商品連携と支払いは別の役割

Store Syncは、商品カタログを参加AIチャネルへ届け、カートの作成・管理や既存の注文管理への接続を担います。商品を見つけてもらうところから、購入後の処理までをつなぐ役割です。[1][5]

Agent Readyは、AIの買い物画面で支払いを受け付け、処理するための基盤です。現行のPayPal.aiは、Agent Readyの単独利用と、Store Syncとの併用の両方を案内しています。[5]

自社で実現したいこと	主に見るサービス・資料	追加連携を判断するポイント
AIに商品を見つけてもらう	Store Sync	商品カタログや在庫・価格を渡す経路があるか
AI側のカートや注文を店につなぐ	Store Sync	既存のカート・注文管理とどう接続するか
AI内で始まる支払いを受ける	Agent Ready	自社の契約と対象AIチャネルに合う決済経路があるか
Braintreeの既存処理を活用する	Agent ReadyのACP・UCP接続資料	トークンの受信処理と決済処理を追加できるか

Store SyncとAgent Readyは、商品・注文と支払いをそれぞれ担います。すでに商品や注文をAIにつなぐ経路がある店は、その連携を踏まえてAgent Readyの単独利用を検討できます。[1][5]

組み合わせを選ぶ際は、商品連携の有無と決済契約を別々に確認します。サービスを選ぶことと、各AIチャネルで販売できる条件を満たすことも別です。

2. 契約と相談窓口を分ける

PayPal.aiは、Agent Readyについて既存のPayPalアカウントを基盤とする広い案内をしています。一方、開発者向けのAgent Ready概要と本記事で扱うACP・UCP接続資料は、Braintree加盟店向けです。Agent Ready全体を「Braintree必須」と定義するのではなく、以下の技術例の前提がBraintreeだと捉えてください。[2][3][4][5]

通常のPayPalボタンだけを利用している店は、まず契約情報からBraintreeの利用有無を確認します。Braintreeを使っていない場合、以下のコード例をそのまま追加する計画には進めません。

Store Syncの相談を検討する場合

PayPal.aiには「Get Started」リンクと、Store Syncについて営業担当者に相談するフォームがあります。Store Syncの相談を進める場合は、次の順で必要情報を用意できます。[5]

1. PayPal.aiの「Get Started」から相談フォームを探します。
2. 氏名、電話番号、業務用メール、会社名、会社サイトURLを準備します。
3. 国と年間売上見込みの欄で、自社に合う選択肢を確認します。
4. マーケティングメールや電話での連絡に関する同意とプライバシーポリシーを読み、送信する場合は「Submit」を選びます。

フォームは全項目必須と表示されています。これはStore Syncの営業相談窓口であり、送信だけで利用承認や接続が完了するわけではありません。[5]

旧来の全体概要にはAIチームへのアクセス申請リンクがあり、その旧リンクは確認日時点でPayPal.aiへ転送されます。ただし、現在のStore Sync相談フォームがAgent Ready共通の申請窓口であるとは確認できません。[1][5]

下の図は、Braintreeを使う接続例です。Agent Ready全体の利用条件を表すものではありません。

3. マグカップ1個の買い物を追う

ここからは、Braintreeを使うPayPal掲載の二つの接続例を読みます。ChatGPTアプリ向けのACP例と、Google Payを使うUCP例は、同じ商品を買う別経路として比較します。[3][4]

説明用の買い物は次のとおりです。USDは資料の課金例に合わせたもので、日本の店がこの通貨・条件で参加できることを示してはいません。

情報	説明用の値
商品・商品ID	マグカップ、mug-demo-01
数量・商品価格	1個、USD 8.00
送料・税・総額	送料USD 2.00、税USD 0.00、総額USD 10.00
購入手続きID	checkout-demo-01
店の注文ID	注文保存時に発行するorder-demo-01

商品IDや数量、送料・税をこの購入手続きIDに結び付ける部分は、店側の説明用設計です。税額ゼロも例の仮定であり、実際には販売先などに応じて計算します。

商品を探す段階では、PayPalのChatGPTアプリ例に、product_titleを受けて店の商品検索処理を呼び、商品情報をstructuredContentで返す構成があります。今回なら「マグカップ」を検索し、mug-demo-01の商品情報を返す場面に相当しますが、商品ID・在庫・価格の完全な項目定義を示す例ではありません。[3]

店側では、選ばれた商品1個をcheckout-demo-01に対応付け、配送先から送料と税を計算して総額USD 10.00を確定する設計にします。配送先が決まらず送料が未確定なら、商品価格USD 8.00を最終請求額として扱わないことが重要です。

Store Syncを使う場合、公式概要から商品カタログ連携とカート操作の資料へ進めます。本記事は概要と決済接続例を対象としており、この商品を登録・更新する完全なAPI手順までは扱いません。[1]

4. ChatGPTアプリから支払う例

ここで扱うPayPalのACP接続例は、Apps SDKを使ったカスタムChatGPTアプリ向けです。店側に、AIから処理を呼び出す接続口であるMCPサーバーと、支払い情報を受け取るcomplete_checkoutを用意し、アプリからrequestCheckout()を呼びます。これはACP全体の必須構成を示すものではありません。[3]

アプリからChatGPTの購入画面へ渡す情報には、購入手続きID、決済会社、加盟店ID、通貨、総額があります。公式例の一部を今回の買い物に置き換えると、次のようになります。[3]

{
  "id": "checkout-demo-01",
  "payment_provider": {
    "provider": "braintree",
    "merchant_id": "YOUR_BRAINTREE_MERCHANT_ID",
    "supported_payment_methods": ["card"]
  },
  "status": "ready_for_payment",
  "currency": "USD",
  "totals": [
    { "type": "total", "display_text": "Total", "amount": 1000 }
  ],
  "payment_mode": "test"
}

idは店の購入手続きとの対応、merchant_idは決済を処理するBraintree加盟店の識別に使います。amountはこの例ではセント単位なので1000がUSD 10.00、ready_for_paymentは支払いを受け付けられる状態であり、支払い済みではありません。

これは公式例のlinksなどを省いた説明用抜粋で、完成したリクエストではありません。payment_mode: "test"はテスト用の指定であり、この抜粋の動作確認結果を表すものでもありません。[3]

送る側 → 受け取る側	入力・返却値	次に進む条件
店のアプリ → ChatGPTの購入画面	requestCheckout()へ上記の購入情報を渡す	店側で総額と購入内容を確定している
ChatGPT側 → 店のcomplete_checkout	checkout_session_id、buyer、payment_data	本人の許可を受けた支払い情報を受信する
店のサーバー → Braintree	payment_data.tokenと金額"10.00"	対象の購入手続き・加盟店・金額を対応付ける
Braintree → 店のサーバー	成功・失敗、成功時の取引ID	結果を判定して購入完了応答へ進む

受信したcheckout_session_idがcheckout-demo-01なら、店に保存した総額USD 10.00と対応させます。payment_data.tokenはBraintreeで「payment method nonce」と呼ぶ一度限りの支払い情報で、transaction.saleまたはGraphQLのchargePaymentMethodに渡します。[3]

購入画面の1000セントと課金時の"10.00"は同じ金額にそろえます。PayPalの掲載例では購入画面が330セント、後段の課金がUSD 10.00なので、別々の例をそのまま一つの取引として接続しないよう注意が必要です。[3]

トークンには加盟店、金額上限、通貨、有効期限の制約があります。今回の許可上限がUSD 10.00なら、数量を2個に変えて総額USD 18.00になったときは、同じ許可のまま課金せず、購入内容と許可を更新する設計が必要です。[3]

なお、この接続資料の現在の対応値はcard、applepay、googlepayです。paypal_walletとvenmo_walletは「coming soon」とされており、Agent Readyという名称だけでPayPalウォレットもこの経路で利用可能とは判断できません。[3]

図は、両経路とも購入内容・総額USD 10.00について本人の確認・許可を事前に得た前提で、支払い情報の受信後だけを比較しています。ACPではpayment_data.tokenを使い、UCP例ではcredential.tokenを解析してnonceを取り出します。[3][4]

5. Googleから支払う例

PayPal掲載のUCP例では、Google側のサーバーでGoogle Payの支払い情報をトークン化し、店が受け取ってBraintreeへ渡します。前提は、有効なBraintree加盟店アカウント、BraintreeでのGoogle Pay有効化、GoogleへのUCP加盟店登録と有効化です。[4]

店はGoogleへの登録時にGoogle Pay決済ハンドラーを定義し、その設定にgateway: "braintree"、braintree:merchantId、braintree:clientKeyなどを含めます。clientKeyに入れるのはBraintreeのtokenization keyで、本人の購入許可ではなく、トークン化に使う設定情報です。[4]

今回の説明では、Google側の購入手続きも店のcheckout-demo-01に対応させます。以下は総額USD 10.00について本人の確認・許可を事前に得た想定で、具体的な画面や許可の手順を示すものではありません。

送る側 → 受け取る側	入力・返却値	店側で行う処理
Google → 店の完了処理	/checkout-session/{id}/completeへ支払い情報を送信	説明例では{id}をcheckout-demo-01に対応付ける
店の受信処理 → 解析処理	payment.instrumentsの先頭要素のcredential.token	JSON文字列を解析し、例のコードではandroidPayCardsの先頭要素のnonceを取得する
店のサーバー → Braintree	取り出したnonceと金額"10.00"	保存済みの購入総額と照合して課金する
Braintree → 店のサーバー	成功・失敗、成功時の取引ID	決済結果を購入手続き・注文に対応付ける

このエンドポイントと解析方法は、PayPal掲載のGoogle Pay・Braintree連携例のものです。UCP全体で同じ決済経路や項目が必須という意味ではありません。[4]

また、掲載された受信例では、トークン内の値に対応するキーが空文字になっており、後続コードが読むnonceと一致しません。実装時は実際の受信形式と仕様を照合し、値を取得できなければ課金へ進めないようにします。[4]

支払い情報を受け取ったことと、決済が成功したことは別です。店はBraintreeの応答を確認してから、購入結果の返却と注文管理への反映を行います。

6. 決済と注文を結び付ける

マグカップ1個の決済が成功したら、購入手続きIDcheckout-demo-01、店の注文IDorder-demo-01、Braintreeの取引IDを対応付けて保存する設計にします。これにより、問い合わせや処理失敗を調べるとき、どの注文に対する支払いかを追えます。

PayPalのACP成功応答例はstatus: "completed"と注文情報を返し、order.idにはBraintreeの取引IDを使っています。自社の注文管理が別の注文IDを発行する場合は、それらを同一の識別子として扱わず、対応関係を持たせます。[3]

運用設計では、決済成功後に注文保存だけが失敗した場合と、応答が途切れて要求が再送された場合を分けて考えます。担当者は開発側と「どの記録で決済済みと判定するか」「再送時に二重課金をどう防ぐか」を決めておく必要があります。

Google Pay由来の一度限りの支払い情報は、未使用でも3時間で失効すると説明されています。同じ値を課金と将来利用のための保存の両方に使う流れも避けるよう注意されているため、失敗時に同じトークンを無条件で再利用する設計にはできません。[4]

7. 自社に何を追加するか

判断する単位は「商品」「購入手続き・注文」「支払い」の三つです。 まず運用担当者は、商品情報の管理元、AIへ渡す既存経路、注文の保存先、PayPalとBraintreeの契約状況を一覧にしましょう。

• 商品やカートをAIへつなぐ経路がないなら、Store Syncの対象範囲を調べる。
• 商品・注文連携がすでにあるなら、Agent Ready単独利用の条件を調べる。
• Braintreeを利用中なら、対象AIに応じてACP例かGoogle Pay・UCP例を開発担当者と読む。
• PayPalボタンのみなら、Braintree例の実装を先行せず、自社に適用できるAgent Readyの利用条件を確認する。

確認範囲

Store Sync相談フォームは項目名まで確認できていますが、国の選択肢、日本の参加資格、送信後の表示・承認条件、Agent Readyの現行申請窓口は未確認です。フォーム送信や実決済は行っていません。

技術節はPayPalの公開例を読むためのもので、商品登録から認証・購入完了までの実装手順や、ACP・UCP全スキーマへの適合を保証するものではありません。開発へ進む際は、対象仕様の版、受信データ、決済結果、注文保存と再送時の処理をそろえて検証する必要があります。