ACPとUCPがAIエージェント駆動のコマースのためのインタラクションとカートのポータビリティ層を定義する方法
エージェンティックコマースプロトコル (ACP) とユニバーサルカートプロトコル (UCP): 2026年にコマースエンジニアが知っておくべきこと
目次
- ACPとUCPが実際に何であるか
- これらのプロトコルが今重要な理由
- エージェンティックコマースプロトコル (ACP): 技術的な内訳
- ユニバーサルカートプロトコル (UCP): 技術的な内訳
- ACP対UCP: どのように連携するか
- 両プロトコルをサポートするためにプラットフォームが必要なこと
- ACPとUCPに付随する支払い基準
- コマースチームが見落としがちな一般的な準備不足
- FAQ
- どこから始めるか
はじめに
AIエージェントはすでに製品カタログを見たり、価格を比較したり、実際の顧客の代わりに購入を開始したりしています。ほとんどのコマースプラットフォームはこれに合わせて設計されてはいませんでした。人間がクリックし、スクロールし、読むために設計されていたのです。エージェントはそのどれも行いません。
このギャップを埋めるために、エージェンティックコマースプロトコル (ACP) とユニバーサルカートプロトコル (UCP) という2つの新しい標準が登場しています。もしあなたがコマースブランドのエンジニアリングリーダーなら、これらのプロトコルはあなたのプラットフォームがエージェント駆動のトラフィックをどのように処理するかに影響を与えるでしょう。この文書では、それらが何であるか、どのように異なるのか、あなたのスタックがそれらをサポートするために必要なこと、そして現在多くのチームがどこで不足しているかを説明します。
ACPとUCPが実際に何であるか
ACPとUCPは、AIエージェントとコマースシステムとの相互運用性を高めるために設計されたオープンスタンダードです。これらはエージェントとコマースのインタラクションにおける異なるレイヤーを対象にしていますが、補完的です。
エージェンティックコマースプロトコル (ACP) は、AIエージェントがコマースシステムとどのように通信するかを定義します。具体的には、製品の発見、利用可能性の問い合わせ、ポリシーの読み取り、取引の開始までを網羅しています。これはインタラクションレイヤーです。
ユニバーサルカートプロトコル (UCP) は、カートの状態がプラットフォームやエージェント間でどのように表現され、転送されるかを定義します。これはデータポータビリティレイヤーです。一つのエージェントまたはシステムによって構築されたカートが、他のエージェントまたはシステムにより読み取られ、修正され、完了されることを保証します。
これらが組み合わさることで、エージェントが第一級の参加者となるコマース体験の基盤が形成されます。
これらのプロトコルが今重要な理由
この変化は仮定の話ではありません。ChatGPTやClaudeのようなシステムからのエージェントトラフィックは、サーバーログで今日確認可能であり、ChatGPT-User や Claude-Web といったユーザーエージェントストリングによって特定されます。これらのエージェントはすでにあなたのカタログを評価しています。問題は、あなたのプラットフォームが実際に役立つ方法で応答しているかどうかです。
ACPに対応したエンドポイントがなければ、エージェントはスクレイピングしたり推測したりする必要があります。UCPに対応したカートの状態がなければ、クロスプラットフォームでのチェックアウトフローは崩れます。どちらの結果も取引の損失を意味しますが、それは静かに起こり、あなたの標準分析には現れません。
プロトコルの早期採用に動くブランドは、構造的な優位性を持つことになります。従来の検索でランクが上がるからではなく、エージェントが実際に購入を完了できるプラットフォームだからです。
エージェンティックコマースプロトコル (ACP): 技術的な内訳
ACPが定義するもの
ACPは、エージェントとコマースとの通信のための構造化されたインターフェースを指定します。その核心では、以下の内容を含みます:
- ディスカバリー: エージェントが製品を見つけて問い合わせる方法。属性、価格範囲、可用性、履行オプションによるフィルタリングが含まれます。
- ポリシー解決: エージェントが機械的にパース可能な形式で返品ポリシー、保証条件、価格条件を読む方法。
- セッション管理: エージェントが人間のセッションを必要とせずにマルチステップのショッピングインタラクション全体でコンテキストを維持する方法。
- 取引の開始: エージェントがチェックアウトまたは購入アクションを要求する方法。委任された認証フローを含みます。
このプロトコルは、エージェントが特定のアクションを事前に承認されたユーザーを代表して行動していると仮定しています。その承認モデルは重要です。これが正当なエージェントトランザクションを認可されていない自動リクエストから区別します。
ACPがあなたのスタックにどのようにフィットするか
ACPは、既存のRESTまたはGraphQL APIとエージェントランタイムの間に位置します。必ずしも現在のAPIレイヤーを置き換える必要はありません。ACP準拠のエンドポイントを追加するか、既存の応答を期待されるスキーマに変換するアダプターを拡張します。
Shopify Plusチームの場合、これは通常カスタムアプリやミドルウェアレイヤーを構築することを意味します。commercetoolsやカスタムスタックの場合は、より直接的です。ACP準拠のルートハンドラーを追加し、製品データモデルがプロトコルが期待するフィールドを展開することを確認します。
ACP互換のための技術的要件:
- JSON-LDおよびschema.orgマークアップを使用した構造化された製品データ
- 200ms未満の応答ターゲットを持つリアルタイムの在庫および価格エンドポイント
- 機械が読み取れるポリシーオブジェクト（返品、履行ウィンドウ、保証条件）
- OAuth 2.0またはそれに相当する委任認証サポート
- 明示的なエージェントアクションスコープ（閲覧のみ対取引可能）
ユニバーサルカートプロトコル (UCP): 技術的な内訳
UCPが定義するもの
UCPは、カートの状態がポータブルなエージェント読み取り可能オブジェクトとして表現される方法を標準化します。UCP準拠のカートは以下を含みます:
- 標準の製品識別子を持つラインアイテム（プラットフォーム固有の内部IDではなく）
- カート作成時の価格（適用された割引や条件を含む）
- 履行の好みと可用性の確認
- カートの出所 — どのエージェントやシステムがカートを作成または最終更新したか
- マルチエージェントシナリオでのレースコンディションを防ぐための有効期限およびロックの意味論
目標は、どの準拠システムでも読み取って操作できるカートオブジェクトを作成することです。どのプラットフォームやエージェントが作成したかに関係なく。
実践的なクロスプラットフォームカートの相互運用性
あるユーザーがショッピングエージェントに特定のジャケットの最安値を見つけるように依頼したと仮定しましょう。エージェントは、3つの異なるコマースプラットフォームに問い合わせを行い、それぞれで候補カートを構築し、オプションを提示します。UCPがなければ、それぞれのカートは独自のデータの塊になります。エージェントは触れるすべてのプラットフォームに対してカスタムロジックを維持しなければなりません。
UCPを使うことで、エージェントは一貫したスキーマで作業できます。エージェントはカートを比較し、ラインアイテムをマージし、プラットフォーム特有の変換なしにチェックアウトフローを引き渡すことができます。あなたのプラットフォームにとって、それはカートAPIがUCP準拠のペイロードを発信し、受け入れる必要があることを意味します。
ACP対UCP: どのように連携するか
| レイヤー | プロトコル | 主な機能 |
|---|---|---|
| インタラクション | ACP | エージェントとコマースの通信、発見、ポリシー解決、取引の開始 |
| データポータビリティ | UCP | カートの状態の表現、クロスプラットフォームのカート転送、マルチエージェントカート管理 |
| 構造化データ | JSON-LD / schema.org | エージェントがパースするための製品、オファー、ポリシーのマークアップ |
| 支払い | Google AP2, Mastercard Agent Pay, Stripe Agentic Suite | 委任された支払い認可と実行 |
ACPは会話を処理します。UCPはカートを処理します。構造化データは会話が始まる前にあなたのカタログを読みやすくします。支払い基準が取引を完結します。
この4つのレイヤーが協力して機能する必要があります。一方に強く他方に弱いプラットフォームは、エージェント主導のトランザクションを失うことになります。
両プロトコルをサポートするためにプラットフォームが必要なこと
2026年の準備状況を評価しているエンジニアリングチームのための実用的なチェックリスト:
データレイヤー
- 製品の分類法がクリーンで一貫しており、schema.orgのタイプにマッピングされている
- SKUと属性がカタログ全体で一貫した命名規則に従っている
- 在庫がリアルタイムで同期されている — 古くなった在庫データはエージェントの信頼を即座に壊します
- 返品ポリシー、保証条件、履行ウィンドウが機械可読オブジェクトとして構造化されており、CMSフィールドに埋め込まれた文章ではありません
APIレイヤー
- RESTまたはGraphQLエンドポイントがリアルタイムの在庫、価格、および履行を公開している
- 応答のレイテンシターゲットが満たされている (200msはほとんどのクエリに対して妥当な上限です; エージェントは迅速かつ信頼できるエンドポイントを好みます)
- ACP準拠のルートハンドラーが存在するか、開発中である
- カートエンドポイントがUCP準拠のペイロードを発信する
認証レイヤー
- 委任認証がサポートされている (OAuth 2.0またはそれに相当するもの)
- エージェントアクションのスコープが定義されている: エージェントが閲覧できるもの、カートに追加できるもの、購入できるもの
- プロンプトインジェクションや無許可のトークン化された購入を防ぐためのガードレールが存在する
可観測性レイヤー
- エージェントトラフィックがあなたの分析において特定され、セグメント化されている (
ChatGPT-User,Claude-Webなどのユーザーエージェントストリング) - ゼロクリックAIトラフィックが人的セッションから別々に測定されている
- カート放棄率と取引の失敗率がトラフィックソースごとに追跡されている
ACPとUCPに付随する支払い基準
ACPとUCPはインタラクションとカートのレイヤーを定義しています。購入を完了するには、委任された認可を理解する支払いレイヤーが依然として必要です。
2026年には、3つの標準が主要なオプションとして浮上しています:
- Google AP2 (エージェントペイメントプロトコル v2): Googleのエコシステム内で動作するエージェント向けに設計され、AP2はユーザーの保存された資格情報による支払い認可を扱います。
- Mastercard Agent Pay: Mastercardによるエージェント主導の支払いへのアプローチで、トランザクションごとの認可コントロールを持つトークン化されたカード資格情報に焦点を当てています。
- Stripeエージェンティックコマーススイート: Stripeの実装は、委任された支払いフロー、スコープ付きのエージェント特定APIキー、および非人間のトランザクションパターンに対する内蔵の不正信号をカバーしています。
あなたの支払い統合戦略は、少なくともこれらのどれかに対応する必要があります。どれを選ぶかは、あなたの顧客基盤と、あなたのプラットフォームにトラフィックを駆動する可能性の最も高いエージェントに依存します。
コマースチームが見落としがちな一般的な準備不足
ほとんどのエンジニアリングチームは明らかな表面的な部分 — 製品データのマークアップやAPIパフォーマンス — に焦点を当てています。実際にエージェントトランザクションを妨げるギャップは、あまり目立たないことが多いです:
ポリシーデータは人間が読めるが機械が読み取れない。 返品ポリシーは顧客にとって明確に書かれているかもしれませんが、CMS内の非構造化されたテキストとして存在すれば、エージェントはそれを解析できません。ACPは、型付きフィールドを持つポリシーオブジェクトを期待します。段落ではありません。
カートの状態がプラットフォーム専有のものである。 もしあなたのカートAPIが内部IDやプラットフォーム特有の構造を返す場合、UCP準拠のエージェントはカスタム翻訳ロジック無しにはそれを扱うことができません。その摩擦は取引を損なうことになります。
認可スコープが定義されていない。 エージェントが何ができるかについて明示的なルールが必要です。それがなければ、すべてのエージェントトランザクションをブロックする（制限が厳しすぎる）か、無制限のエージェントの行動を許す（セキュリティリスク）ことになります。
可観測性が欠けている。 エージェントトラフィックを分析で見ることができなければ、プロトコルの採用の影響を測定したり、どこでエージェント主導のフローが失敗しているかを特定したりすることができません。
レイテンシターゲットが強制されていない。 エージェントは複数のプラットフォームを同時に照会し、最も迅速な応答を好みます。もしあなたの在庫エンドポイントが常に500msを超えているなら、エージェントがあなたの製品データに到達する前に評価を失っています。
これらのギャップを系統的に解決するチーム — 反応的にパッチするのではなく — は、エージェント駆動のコマースが拡大する際に好位置を確保するでしょう。CTO.LAはコマースエンジニアリングチームと協力して、この可能性を実現するためのアーキテクチャを構築しています。構造化されたデータの基盤を通じて、ACPとUCPの採用から支払いレイヤーの準備まで。
FAQ
エージェンティックコマースプロトコル (ACP) とは？ ACPは、AIエージェントがコマースシステムと通信する方法を定義する新たなオープンスタンダードです。製品の発見、ポリシー解決、セッション管理、取引の開始をカバーし、エージェントランタイムとコマースAPI間の構造化されたインターフェースを提供します。
ユニバーサルカートプロトコル (UCP) とは？ UCPは、カートの状態をポータブルでエージェント読み取り可能なオブジェクトとして表現するための標準です。これにより、1つのエージェントまたはプラットフォームによって作成されたカートが他のエージェントやプラットフォームによって読み取られ、修正され、完了されることができます。これにより、クロスプラットフォームのカートの相互運用性が促進されます。
ACPとUCPは既存のコマースAPIとどう違うのか？ 既存のRESTまたはGraphQL APIは、人的に起動されたセッションのために設計されています。ACPとUCPは、エージェント特有のセマンティクス — 委任された認可、機械可読のポリシーオブジェクト、標準的な製品識別子、カートのポータビリティを追加しています。一般的には、既存のAPIの上にACP/UCPサポートを構築することになります。
両方のACPとUCPをサポートする必要がありますか？ それぞれ異なるレイヤーに対処しています。ACPはエージェントとコマースシステム間のインタラクションを処理し、UCPはカートの状態のポータビリティを処理します。ACPはサポートしているがUCPをサポートしないプラットフォームは、エージェントによる探索と開始は扱えますが、クロスプラットフォームのカートシナリオで問題を抱えるかもしれません。ほとんどのチームは両方の計画を立てるべきです。
どの支払い基準がACPとUCPと連携しますか？ Google AP2、Mastercard Agent Pay、およびStripeのエージェンティックコマーススイートが2026年の主要オプションです。どれも、ユーザーがエージェントに代表して取引することを事前に承認した場合に必要な、委任された支払い認可をサポートしています。
コマースエンジニアリングチームは、ACPとUCPの準備をどこから始めるべきですか？ データ基盤から始めましょう。クリーンな製品分類法、リアルタイムの在庫同期、構造化されたポリシーオブジェクトです。その後、APIレイヤーのレイテンシとスキーマの整合性を監査します。認証と可観測性が次のステップです。
どこから始めるか
ACPとUCPの採用は一度きりのスプリントではありません。データモデル、APIレイヤー、認証システム、可観測性スタックに影響を与えるアーキテクチャの決定です。これを一連の孤立したチケットではなく、一貫したインフラストラクチャプロジェクトとして扱うチームが、より早く、より少ない後退で到達します。
あなたのプラットフォームが現在どの位置にあるかを評価している場合、CTO.LAの無料AIウェブサイト監査が具体的な出発点となります。あなたのサイトのカタログを評価しているAIシステムへの可視性をスコア化し、重要なエージェント準備のギャップを浮き彫りにします。
プロトコルは急速に進化しています。今下したアーキテクチャの決定が、12ヶ月後にエージェントがあなたのプラットフォームで取引できるか、さもなければすでに準備が整った競争相手に転送されるかを決定します。