買う商品を薦める仕事から、購入を完了する仕事へ
買い物AIに「雨の日にも使える上着を、送料込みで2万円以内で探して」と頼む。候補を比べるだけなら、説明の質が中心になる。購入まで任せると、サイズ、在庫、配送、税や送料を含む金額、支払い手段、返品条件を確定し、どこまで利用者が許可したかを残す必要がある。会話の中の希望を、販売店と決済サービスが検証できる取引へ変える仕事が加わる。
Googleが1月に発表したUniversal Commerce Protocol（UCP）は、商品発見から購入後の対応までをつなぐ共通仕様として登場した。UCPの現行文書では、販売店が提供する機能を宣言し、アプリやエージェントが対応範囲を見つけて利用する構成が示されている。個々のAIサービスに合わせて販売店が別々の接続を作る負担を減らす狙いだ。
筆者は、この変化を「AIが商品を理解する能力」と「取引を実行する権限」をつなぐ試みと捉える。接続の共通化は、同じ購入条件を複数の参加者が扱うための土台になる。ただし、同じ仕様を掲げるだけで、全販売店の決済方法や追加認証が通るわけではない。どの機能と版を双方が扱えるかは、取引ごとに確認しなければならない。
価格と注文の事実は、販売店から受け取る
Agentic Commerce Protocol（ACP）の構成では、AI側が希望を読み取り、購入画面を表示し、注文手続きを進める。販売店側は在庫、価格、税、送料、決済処理、商品の発送を管理する。AIが購入の窓口になっても、販売店の既存の処理を置き換える設計ではない。
ACPのCheckout APIは、商品の追加や配送方法の変更のたびに、販売店が管理する最新の注文手続きの内容を返す。さらに注文手続きの状態には、必要な情報が不足している段階、支払い可能な段階、決済処理中、支払いが成功して注文が作成された段階がある。支払いに失敗すれば、支払い可能な段階へ戻る場合もある。
この区別は会話の表示にも効く。「候補が見つかった」「購入条件がそろった」「支払い中」「注文が確定した」は別の事実である。AIの返答が流暢でも、決済処理中に購入完了と言ってはいけない。利用者へ示す金額と完了表示は、販売店や決済側の応答に基づく必要がある。モデルは説明を作れても、取引が成立した事実を自分の文章だけで作れない。
注文への許可と支払いへの許可を結び付ける
販売店が提示した注文内容に対して、誰が何を許可したのか。その証拠を扱うのがAgent Payments Protocol（AP2）の現行v0.2仕様だ。中心になるのは、注文内容の購入を許可するCheckout Mandateと、その注文への支払いを許可するPayment Mandateの二つである。販売店が署名した注文データのハッシュを使い、購入と支払いを同じ注文に結び付ける。
AP2は、利用者が同意する画面を、LLMに判断を委ねないTrusted Surfaceとして定義する。許可や制約の検証も、決定的に動くコードで実行するよう求めている。AIが「この支払いは許可された」と説明するだけでは足りず、受け取った側が署名や対象の注文を確認する構成である。
ここで確かめられるのは、購入・支払いが許可された条件に対応することだ。利用者に合う商品を選べたか、広告の説明が正確か、商品が約束通り届くかは、署名とは別の問題として残る。筆者は、取引の許可を確認する処理と、商品の適合性を評価する処理を、同じ「AIの信頼性」という言葉でまとめない方がよいと考える。
毎回確認する購入と、条件を先に許可する購入
AP2の実行例は、利用者が特定の注文と支払いを直接確認する方式と、許可した条件の中でAIが購入する方式を分ける。後者では、利用者が先に未確定の注文に対する制約を承認し、AIが後から具体的な注文に結び付ける。確認なしで自由に買えるのではなく、先に与えた許可から今回の購入までを追えるようにする。
Checkout Mandateの文書には許可する販売店や商品・数量の制約があり、Payment Mandateの文書には金額の範囲、通貨、支払先などの制約がある。許可の検証規則では、解釈できない制約を不合格として扱う。分からない条件を読み飛ばして購入してよい、という設計ではない。
決済側の具体的な仕組みとして、StripeのShared Payment Token（SPT）は、販売店を指定し、通貨、最大金額、有効期限を付けた支払い手段へのアクセスを渡す。追加の本人認証が必要になれば、利用者の操作を待つ状態にもなる。トークンの発行は購入完了を意味しない。また、金額上限は守れても、「雨の日にも使える」という希望を満たすかは、その制限だけでは判断できない。
このため、曖昧な希望を具体的な許可へ変換する段階が重要になる。商品候補を利用者に示して許可範囲を狭めるか、仕様として検証できる条件を定めるか。条件にできない好みが残るなら、購入前に確認へ戻す設計が妥当だ。AP2の実行例にも、未解決の制約を理由に利用者の直接確認へ戻す方法が示されている。
送料の変更と応答の遅れを、上着の購入で考える
冒頭の上着を購入する仮想例で、許可の境界を見てみる。利用者が確認した候補は1万8,000円でも、配送先を入れると送料が3,000円になるかもしれない。AIは、商品価格だけを見て予算内だと判断せず、販売店が返した合計を確認する。送料込み2万円という条件を満たさなければ、別の商品を探すか、予算変更を利用者に確認する。
すでに特定の注文を確認してもらった後で、サイズ、数量、配送方法、合計額が変わった場合も、同じ許可で処理できると決めつけない。今回の内容が許可した条件に含まれるかを検証する。この例は、すべての変更で確認画面が必要だという意味ではない。先に許可した範囲で自動購入できる場合と、範囲を超えて確認が必要な場合を分けるための例である。
決済完了の応答が遅れた場合には、さらに別の判断がある。画面に結果が届かないことと、販売店が注文を作っていないことは同じではない。ACPのAPIには重複処理を防ぐ再試行用の識別子がある。実装では取引の識別子を保ち、現在の注文内容と状態を照会してから再試行する必要がある。利用者には結果が未確定であることを伝え、二重注文を作らずに復旧する経路を用意したい。
ACPの対応機能の調整も、この経路に関係する。双方が扱える追加認証や決済方法を確認することで、購入の最後に必要な操作を表示できない事態を早めに見つけられる。共通仕様の価値は、成功時の呼び出しをそろえることに加え、どこで止まり、誰が続きの操作をするかを説明できることにある。
購入後も、約束と実際の出来事を追う
注文が確定しても、買い物は終わらない。UCPのOrder仕様は、購入した商品、配送の予定、実際の配送イベント、返品や返金などの注文後の変更を記録する。予定と実際の出来事を別に扱うので、「金曜に届く予定」と「金曜に配送済み」を区別できる。返金の情報も、配送とは独立して扱われる。
ACPの注文通知では、販売店が署名付きで注文の全体を送信し、購入窓口へ現在の情報を渡す。これは購入後にAIが利用者へ説明するための具体的な接続である。ただし、返品や返金を表現できることから、あらゆる店でAIが返品を自動実行できるとは言えない。対応する操作、店の規則、実際に完了した結果を確認する必要がある。
利用者にとっては、何を承認したかと、何が実際に起きたかを同じ注文からたどれることが役立つ。支払いの許可、販売店の注文番号、配送の更新、返金の結果を結び付ければ、会話が途中で終わっても確認先が残る。ここまでつながることで、購入を代行するAIは、購入後の問い合わせにも根拠を持って答えられる。
便利さは、購入完了と復旧までで測る
以上の仕様から、購入を進める部品と許可を検証する部品が具体化していることは確認できる。一方、利用者の時間がどれだけ減るか、選んだ商品への満足が上がるか、返品や確認の負担が減るかは、仕様書だけでは分からない。対応を表明した企業の数も、同じ条件で購入が完了する取引の割合を示すものではない。
筆者なら、まず利用者が毎回注文を確認する方式で、既存の購入画面と比較する。送料変更、在庫切れ、追加認証、応答待ち、返品・返金の更新までを含め、誤った完了表示や二重処理、途中で人がやり直した回数を記録する。自動購入は、利用者が理解して許可でき、受け手が機械的に検証できる条件から広げる。成功例だけを数えると、確認と復旧の手間が見えなくなる。
買い物AIに必要なのは、希望を理解して薦める力と、その希望から生まれた許可を注文・支払い・購入後の事実へつなぐ仕組みである。UCPとACPは販売店とのやり取りを、AP2は許可の証拠を、SPTは制限付きの支払い手段を具体化している。これらをつないだ後で、利用者が条件を確認しやすく、失敗しても同じ注文から復旧できるかを評価したい。