5分で読めます
x402とAP2解説：エージェント決済プロトコルの役割分担
100社を超える決済プロバイダーおよびテクノロジー企業が、すでにAP2の後ろに集まっています。Coinbaseのx402はBase上で1億1,900万件を超える取引を処理しました。エージェント向けの決済インフラを構築しているなら、理解すべきはこの2つのプロトコルです。
x402は、Coinbaseが開発したHTTPベースの決済プリミティブです。サーバーがHTTP 402ステータス（「Payment Required」）を返すと、エージェントはレスポンスに埋め込まれた支払い指示を読み取り、ステーブルコイン取引に署名し、証明を添付してリクエストを再送します。ユーザーセッションもログインフローも不要です。決済は数秒でオンチェーンにて完了します。
AP2（Agent Payments Protocol）は、エージェントが開始するコマース向けのGoogleのオープン標準です。その役割は、セッションレベルでの信頼と承認です。エージェントが何かを支出する前に、ユーザーは意図を証明する暗号署名済みのMandateを発行しなければなりません。AP2には、Coinbase、Ethereum Foundation、MetaMaskと共同開発されたx402拡張が含まれており、x402がAP2内のクリプト/ステーブルコイン決済手段となります。
この2つは競合関係にはありません。同じ問題の異なるレイヤーを解決するものです。
x402とは何か、どのように動作するか
x402は、マシン間のAPI呼び出し向けの決済プロトコルです。設計は意図的にミニマルにされています。1991年から仕様に存在しながら、これまで標準化されることのなかったHTTP 402ステータスコードを再活性化するものです。
フローは次のとおりです。
- エージェントがAPIエンドポイントを呼び出します。
- サーバーは、支払いペイロード（金額、通貨、送金先アドレス、受け入れ可能なステーブルコイン、ネットワーク）とともにHTTP 402を返します。
- エージェントのウォレットが、これらの条件を満たすステーブルコイン取引に署名します。
- エージェントは、ヘッダーに支払い証明を添えて元のリクエストを再送します。
- サーバーは証明を検証し、リクエストに応じます。
ログインなし。クレジットカードなし。OAuthトークンなし。支払いそのものがクレデンシャルです。
2026年3月時点で、x402はプロトコル手数料ゼロ、BaseとSolana全体で年換算取引高約6億ドルとなっていました。その後Coinbaseは、Google、Stripe、Visaの支援を受けてx402をLinux Foundationへ移管しました。この動きは運用面で重要です。ガバナンスは中立になり、プロトコルのリスクは単一企業のスポンサーの下にある場合より低くなります。
APIでエージェントに直接サービスを提供し、サブスクリプションやセッション管理のレイヤーを構築せずに、従量制で摩擦のない決済を実現したいなら、x402がその仕組みです。ただし、セッションをまたいだ信頼の管理、ユーザー意図の検証、行動するエージェントがエンドユーザーに承認されているかの把握は行いません。これは意図的にスコープ外とされています。
AP2とは何か、どのように動作するか
GoogleのAP2ローンチには、Coinbase、Mastercard、PayPal、American Express、Revolut、Shopee、Salesforce、Worldpay、Adyen、Etsy、JCB、UnionPayなど、60社を超える創設パートナーが名を連ねています。6週間以内に、この連合は100社を超えるパートナーに達しました。仕様は公開されており、こちらからご覧いただけます。
AP2の中心概念はMandateです。これは、取引が開始される前に、ユーザーがエージェントに何を許可したかを記録する暗号署名済みのデジタル契約です。Mandateでは、支出限度額、承認済み加盟店、有効時間枠、支払い方法を指定できます。有効なMandateがなければ、エージェントはAP2の下で支払いを開始できません。
信頼モデルは次のように機能します。
- ユーザーまたは企業がMandateを設定します。スコープ、限度額、有効期限です。
- Mandateに署名され、エージェントに発行されます。
- エージェントは支払いを開始する際にMandateを提示します。
- 決済プロバイダーは処理前にMandateを暗号学的に検証します。
AP2は、従来の決済レール（カード、銀行送金）に加え、AP2 x402拡張を通じてステーブルコインとオンチェーン決済にも対応します。この拡張こそ、2つのプロトコルが直接交わる場所です。
AP2は、大規模なエージェントコマースのための承認および信頼レイヤーです。エージェントがユーザーの代理として商品やサービスを購入し、有料APIを呼び出し、定期的な支払いを実行するためのインフラを構築するなら、Mandateフレームワークが必要です。x402決済は、そのフレームワークの中で決済手段として機能できます。
x402とAP2の連携方法
この関係を最も明確に理解する方法は、プロトコルスタックで見ることです。
AP2はセッションと承認のレイヤーで動作し、「このエージェントは支出を許されているか、誰の代理で、どの制約の下でか」という問いに答えます。x402は呼び出しのレイヤーで動作し、「このエージェントは今、この特定のAPI呼び出しに対してどう支払うのか」という問いに答えます。
AP2 x402拡張はこの2つを融合させます。AP2 Mandateの下で動作するエージェントがステーブルコインでAPI呼び出しの支払いを必要とするとき、x402の仕組みが呼び出しごとの決済を処理します。MandateはAP2に承認のコンテキストを与え、x402が決済のメカニズムを担います。
どちらのプロトコルも実行レイヤーではありません。インターフェース、メッセージフォーマット、検証ロジックを定義します。支払いリクエストがどのような形で、有効なレスポンスに何を含む必要があるかを規定します。取引を実行するには、プロトコルの下にある作業が必要です。鍵の保持、監査可能な記録を伴う署名、送金先アドレスのスクリーニング、資金の送出。そのすべては、両者の下に存在するウォレットインフラの中で行われます。
適切なインフラがない場合とある場合のシナリオ
企業からデータAPIの呼び出しとクエリ単位の支払いを許可されたAIエージェントを考えてみてください。エージェントはAP2 Mandateの下で動作し、呼び出しごとにx402支払いを発行します。
十分なウォレットインフラがない場合：エージェントが支払い証明を生成して送信します。バックエンドには署名済みのステーブルコイン取引リクエストが届きます。出金パイプラインに自動署名、設定可能な承認しきい値、リアルタイムKYTスクリーニングがなければ、手動レビュー（レイテンシモデルを完全に壊す）と盲目的な実行（コンプライアンスと不正のリスクにさらされる）という選択を迫られます。
下部にWaaSの基盤がある場合：リクエストはCoinSendに届き、送出前にCoinSignへルーティングされてRSA/HMAC-SHA256による承認を受けます。CoinGetの自動KYTが、資金が移動する前に送金先アドレスをスクリーニングします。署名、スクリーニング、送出はすべてプロトコルレイヤーの下のインフラレイヤーで行われ、x402の設計思想である1秒未満のレイテンシモデルを壊しません。
これが実行レイヤーの違いです。x402とAP2はインターフェースを規定し、CoinGet、CoinSend、CoinSignがその基盤を担います。
CoinsDo WaaSはノンカストディアルです。秘密鍵はCoinsDoではなく運用者の手元に残ります。CoinSignのRSA/HMAC-SHA256署名は、取引ごとに改ざん不可能な承認記録を提供します。プラットフォームは、ETH/ERC-20、TRX/TRC-20、BNB/BEP-20、Polygon、Solanaなど多数のチェーンにまたがるエージェント展開ウォレットのユースケースに対応し、クライアントから要望されたチェーンの統合は約1ヶ月サイクルで進められています。
エージェントがクロスチェーンで動作するなら、このカバレッジが重要です。x402はBaseとSolanaで始まりました。AP2はフレームワークレベルでチェーン非依存です。インフラは、エージェントが実際に使うチェーンに対応している必要があります。
WaaSの文脈でこれがどのように機能するかについて、詳しくはこちら
これらのプロトコルから派生するインフラの意思決定（鍵のカストディ、承認フロー、コンプライアンスの自動化、チェーンカバレッジ）について、詳しくはこちら
よくある質問
x402とAP2の両方を実装する必要がありますか？
必ずしもそうではなく、同時にである必要もありません。ユースケースが、エージェントが呼び出しごとに支払うAPIマネタイズであり、セッションレベルの承認が不要なら、x402だけで十分な場合があります。ユーザー意図と支出限度額を複数取引にわたって暗号学的に検証可能にする必要のある、エージェント対加盟店のコマースを構築するなら、AP2がMandateフレームワークを提供します。意味のある規模のステーブルコイン決済によるエージェントコマースでは、最終的に両方を実装することになるでしょう。信頼と承認にはAP2を、決済メカニズムには（AP2 x402拡張経由の）x402を使います。
ウォレットインフラはスタックのどこに位置しますか？
ブロックチェーンの上、プロトコルの下です。x402とAP2はメッセージフォーマットと検証ロジックを定義します。鍵を保持せず、取引に署名せず、取引相手のスクリーニングもしません。その作業はウォレットレイヤーの担当です。入金アドレスの生成、取引の署名、KYTスクリーニング、自動送出。どちらのプロトコルも、そのレイヤーがどのようなものかは規定しません。持ち込むのはお客様自身です。
x402は現在、構築の基盤として十分安定していますか？
Stripe、Google、Visaを後ろ盾としたLinux Foundationへの移管は、プロトコルの安定性を示す強いシグナルです。x402 GitHubと、Base上での1億1,900万件超の取引実績は、コアメカニズムが実験段階を過ぎたことを示唆しています。ガバナンスモデルは現在、中立です。ただし、AP2 x402拡張はAP2自体の成熟に合わせて進化すると想定すべきです。特定ベンダーの実装ではなく、仕様に沿って構築してください。
AP2のMandateはどうやって不正なエージェントの支出を防ぐのですか？
Mandateは単なるトークンゲートではなく、暗号署名されています。エージェントはAP2準拠の支払いを開始するために有効なMandateを提示する必要があり、決済プロバイダーは処理前に暗号署名を検証します。支出限度額、加盟店制限、有効期限ウィンドウは、アプリケーションレイヤーで強制されるのではなく、Mandate自体に組み込まれています。プロバイダー側の検証が、承認されたパラメータを超える取引をすべて拒否するため、エージェントが侵害された場合であっても、Mandateのスコープ外で支出することはできません。
