Architecture

AP2 vs x402: 認可層と決済層。

AI エージェントの支払いにおける AP2 と x402 の比較: 委任、信頼、認可、HTTP 402 決済、ステーブルコイン、ハイブリッド スタック。

Updated May 8, 2026

#AP2 vs x402: 認可レイヤー vs 決済レイヤー

AP2 と x402 は、直接代替するものよりも補完的です。 AP2 は、エージェントが支払いを行う権限を持っているかどうかを回答します。 x402 は、保護された HTTP リソースが支払いを要求および検証する方法に答えます。本格的なエージェントの取引スタックには両方が必要になる場合があります。

混乱は「支払い」という言葉から生じます。 AP2 は許可、テスト、責任に関するものです。 x402 は決済とアクセスに関するものです。

ショートバージョン#

|基準 | AP2 | x402 |

主な機能
主要なアーティファクト
ベストフィット
有料鉄道
主要なリスクに対処

AP2 の設計目的#

Google は、プラットフォーム間でエージェントによる支払いをより安全にするために AP2 を導入しました。中心的な問題は支払いの実行だけではありません。それは認可です。

販売者、発行者、または支払処理業者は、人間が代理人に行動する権限を与えたという証拠を必要とします。証拠は最終的な車両と一致する必要もあります。ユーザーが 120 ドル未満のランニング シューズを注文した場合、エージェントは黙って 230 ドルのジャケットを購入すべきではありません。

AP2 は、義務の概念を通じてこれに対処します。このプロトコルは、後で検証できる方法でユーザーの意図と支払いコンテキストを記録します。 Google の最新の AP2 アップデートでは、事前の承認によっては人間が支払いの瞬間に立ち会っていない可能性がある自律型トランザクションのソリューションも導入されました。

それは信頼の層です。

x402 の設計目的#

x402 は、より具体的で非常に実用的な問題、つまりサーバーがリソースへのアクセスを許可する前に支払いをどのように要求できるかという問題を解決します。

クライアントがリソースを要求します。サーバーは、HTTP 402 Payment required と支払いの詳細で応答します。クライアントは支払いを行うか、支払い証明書を添付します。サーバーはリソースを検証して返します。

従来の支払いシステムでは小規模な自動トランザクションは面倒なため、このパターンはエージェントにとって特に便利です。エージェントは、API 応答を購入するためだけにアカウントを作成し、サブスクリプションを交渉するべきではありません。

AP2 と x402 を組み合わせられる理由#

ハイブリッド スタックでは、x402 が決済を処理している間に、AP2 が認可を実証できます。

フローの例:

  1. ユーザーは、定義された予算を上限としてプレミアム マーケット データを購入するエージェントを承認します。2. AP2 はユーザーの意図と認可制限を捕捉します。
  2. エージェントは、保護されたデータ エンドポイントを呼び出します。
  3. エンドポイントは支払い要件 x402 を返します。
  4. エージェントは、許可された制限内で x402 を介して解決します。
  5. 販売者またはサービスは、承認と支払いの両方の証拠を保持します。

このスタックは、どのレイヤー単独よりも強力です。

AP2 が強力なところ#

AP2 は、取引に法律、コンプライアンス、詐欺、責任リスクがある場合に最も強力になります。

AP2 の適切な使用例は次のとおりです。1. アシスタントによる小売購入 2. エージェントベースの取得 3. 旅行の予約 4.保険契約サービス 5. 事前に許可された制限のある高額購入 6. 責任が問題となる場合の代理店間の支払い

x402 が強力なところ#

x402 は、トランザクションが小規模でデジタルであり、リソースへのアクセスに直接リンクされている場合に最も強力です。

x402 の適切な使用例は次のとおりです。

  1. 有料 API 呼び出し
  2. MCP ツールの起動
  3. エージェント向けのプレミアム Web コンテンツ
  4. データパケット
  5. リクエストによる推論
  6. 機械可読研究ファイル

AEO への影響#

AEO チームは、支払いと承認の要件を機械可読形式で表示する必要があります。

支払われるアクションごとに、次のことを文書化します。

  1. アクションにユーザーの承認が必要かどうか
  2. 自律実行を許可するかどうか
  3. どのような支払いプロトコルがサポートされていますか?
  4. 支払いが受け入れられた場合 x402
  5. どのような権限または資格証明が必要ですか?
  6. エラーと返金の処理方法
  7. エージェントが完了を確認する方法

このドキュメントは、llms.txtプロトコル センター、および関連するアクション ページからリンクする必要があります。

よくある質問#

AP2 は x402 よりも優れていますか? AP2 は認可と説明責任に最適です。 x402 は直接 HTTP 支払い決済に最適です。それらはさまざまなレイヤーを解決します。

AP2 は x402 を使用しますか? AP2 は支払い方法に依存せず、さまざまなレールで動作します。 x402 は、AP2 準拠のフローの決済メカニズムとして使用できます。

API プロバイダーは AP2 を実装する必要がありますか? ほとんどの API プロバイダーは、最初に x402 または MPP を検討する必要があります。 API アクションに権限が委任されている場合、リスクが高い場合、または購入義務がある場合、AP2 はより重要になります。

e コマース販売者は x402 を実装する必要がありますか? ほとんどの場合、最初のプロトコルとしては使用されません。通常、e コマース販売者は、リクエストごとの生の決済の前に、何層もの取引と承認を必要とします。

ソース#

主な参考資料: Google Cloud AP2 の発表Google AP2 FIDO Alliance の更新x402 ドキュメント、および x402 Linux Foundation の発表

関連ガイド* エージェント コマース アーキテクチャ#