AIが勝手に支払いする未来?GoogleのAP2とx402に触れてみる
はじめに
「記事を1本だけ読みたいのに、サブスク契約しないといけない」
「SaaSを少し試したいだけなのに、クレカ登録が必須」
こんな不便さ、誰もが経験したことがあるはずです。
もし 必要なときに必要な分だけ自動で支払える仕組み があったらどうでしょうか?
Googleが発表したAgent Payments Protocol (AP2) と Coinbase が提案するx402を組み合わせることで、AI エージェントがユーザーに代わって安全に決済を行う世界が現実に近づいてきました。
本記事では、両者の特徴を整理し、公開サンプルを実際に動かした結果をご紹介します。
想定読者
- AIエージェントやWeb3開発に興味のあるエンジニア
- エージェントが自分で決済する世界を具体的にイメージしたい人
この記事で学べること
- AP2 と x402 の役割の違いと関係性
- デモを通じてAIエージェントが自律的に支払いを行う流れを実際に動かす方法
AP2とは
AP2(Agent Payments Protocol) は、エージェント主導の決済を安全に扱うためのオープンプロトコルです。既存のA2AやMCPを拡張して利用でき、エージェント間のやり取りに支払いを組み込む枠組みを提供します。
AP2の流れ
- エージェントが支払いリクエストを作成する
- ユーザーが mandate(委任ルール) に署名して承認する
- エージェントがそのmandateに基づいて取引を実行する
- 決済プロバイダーや加盟店がmandateを検証し、取引を完了する
特徴
- 支払い手段に依存しない:クレジットカード、銀行振込、暗号資産などを共通のフレームワークで扱える
- mandates による承認フロー:ユーザーが事前に条件を定義し、その範囲でエージェントに決済を委任できる
- 既存標準との整合性:A2A や MCP の拡張として設計されているため、既存の仕組みとの連携が容易
mandatesとは
mandates は、この条件なら買ってOKというユーザーのデジタル署名付きルールです。
3つの主要な Mandate
-
Cart Mandate
その場でこの買い物を承認しますとサインする
-
Intent Mandate
事前に◯◯円までなら自動購入していいと許可しておく
-
Payment Mandate
決済ネットワーク側にこの取引はエージェントによる正当なものと伝える
要するに本人の意思をデジタルで残す仕組みがMandateです。
※現状 v0.1 では Cart Mandate のみ利用可能であり、
Intent/Payment は将来拡張予定です。
x402とは
x402は HTTP通信を有料化する仕組みです。
これを AIエージェントが利用することで、エージェント同士が自動で決済を行える世界が実現します。
x402の流れ
- 有料コンテンツにアクセス
- サーバーが HTTP 402 を返し、支払い先・金額などを提示
- クライアントがウォレットから USDC などのステーブルコインを送金
- トランザクション情報を添えて再リクエスト
- 200 OK でコンテンツを返却
特徴
- ステーブルコイン前提(例:USDC)
- 軽量・シンプル(HTTPの拡張で導入容易)
- Web3 と親和性が高い
AP2とx402の違い
両者は競合ではなく、補完関係にあります。
AP2:誰にどんな条件で支払いを任せるか決める仕組み
x402:お金を払ったらすぐサービスやデータを使えるようにする仕組み
つまり、AP2がルールを決め、x402が支払い実行を担当します。
ADK x402 ペイメントプロトコルのデモ実践編
AP2の思想を実感するために、公開されている A2A × x402 のPoCデモを動かしてみました。
公式にも記載されている通り、これは PoC実装(v0.1)ですが、
エージェントがMandateに従って402課金を突破する流れを体験できるのがポイントです。
手順
-
リポジトリのクローン
git clone git@github.com:google-agentic-commerce/a2a-x402.git
-
Python環境と Google API Key を準備(uv 前提)
# macOS / Linux curl -LsSf <https://astral.sh/uv/install.sh> | sh # Windows (PowerShell) powershell -ExecutionPolicy ByPass -c "irm <https://astral.sh/uv/install.ps1> | iex" uv python install 3.13.7 uv venv uv run python --version # => Python 3.13.7 になっていればOK
Google AI Studio でAPI Keyを発行し、テスト用のウォレット秘密鍵とあわせて .env ファイルに記載します。
env(プロジェクト直下に作成)
GOOGLE_API_KEY=your_google_api_key WALLET_PRIVATE_KEY=0x自分の秘密鍵
Python 側で利用するため
dotenv
を読み込みます。examples/python/adk-demo/server/agents/routes.py
import os from typing import Dict, List # 追加 from dotenv import load_dotenv load_dotenv()
-
依存インストール & 起動
cd examples/python/adk-demo uv sync # マーチャントエージェント uv run server # クライアントエージェント & ADK Webサーバー uv run adk web --port=8000
ブラウザで http://localhost:8000/ を開き、
client_agent
を選んで「りんごを買いたい」等を試すと、402 → 承認 → 購入の流れが確認できます。
処理の流れ
3.1. クライアントエージェントがサービスをリクエストする
3.2. マーチャントエージェントが「payment-required (HTTP 402 相当)」を返す
3.3. クライアントが支払い要件を転送する
3.4. マーチャントエージェントが 署名サービスへ署名済みの PaymentPayload を送る
3.5. マーチャントエージェントがクライアントに「payment-submitted(承認)」を返す
3.6. 署名サービスがブロックチェーンで検証・決済を行う
3.7. ブロックチェーンが決済確認を返す
3.8. マーチャントエージェントがクライアントへ「payment-completed」+サービス提供(購入完了)を返す
-
オンチェーン送金を有効化(任意)
標準ではモックウォレットを使うためオンチェーン送金は行われません。そこで、自分のウォレットに切り替え、Base Sepolia 上で実際のトランザクションを発火させてみます。examples/python/adk-demo/server/agents/x402_merchant_executor.py
# 修正前 use_mock = os.getenv("USE_MOCK_FACILITATOR", "true").lower() == "true" # 修正後(実Txを走らせる) use_mock = os.getenv("USE_MOCK_FACILITATOR", "false").lower() == "true"
examples/python/adk-demo/client_agent/wallet.py
# 追加 import os from dotenv import load_dotenv load_dotenv() # ウォレットの秘密鍵を環境変数から取得するよう変更 private_key = os.getenv("WALLET_PRIVATE_KEY")
-
Base Sepolia の資金準備
CircleのテストネットFaucet でBase SepoliaのUSDCを取得します。 -
価格を 1 USDC に固定(検証を簡単にする任意対応)
examples/python/adk-demo/server/agents/adk_merchant_agent.py
def _get_product_price(self, product_name: str) -> str: """Generates a deterministic price for a product.""" # 1 USDC = 1_000_000 (6 decimals) price = 1_000_000 return str(price)
反映後にデモを再実行し、承認時に Base Sepolia 上で USDC の送金トランザクションが発火することを確認します。最後に BaseScan で tx ハッシュを検索し、
From
が自分のアドレスであることを確かめればOKです。 -
まとめ
AP2とx402の概要を整理し、公開デモを動かしてオンチェーン送金まで試しました。AI エージェントがHTTP 402 → 承認 → 購入の流れで支払いを処理し、実際にトランザクションが発火するのを確認できたのは大きな収穫です。
一方で、現時点で見えた課題もあります。
UXの課題
自然言語だけで購入完了という未来像はまだ想像しづらく、現実的には候補提示 → 選択 → 決済という流れが必要でしょう。
個人的には、MCP-UIのようなエージェント専用のUIフレームワークと組み合わせると面白そうだと感じました。
もちろんセキュリティ面など課題は残りますが、UX改善の余地は大きいと思います。
開発環境の課題
現状Pythonでの実装しかありません。今後TypeScript実装が出れば、Web3開発者にとって参入しやすくなるでしょう。
将来の展望
AP2が誰にどんな条件で支払いを任せるかを定め、x402がお金を払えばすぐサービスを使えるようにする仕組みを担うことで、
記事単位の購入やオンデマンド利用、サブスク不要のマイクロペイメントといった体験がぐっと現実味を帯びてきます。
PoC段階でもすでに実際に動くものが登場したのは大きな前進です。
今後、UIの整備やTypeScript実装が進めば、エージェントによる自律的な決済は一気に実用段階へと近づいていくと感じます。
参照記事
Discussion
素晴らしい!
AIエージェント同士による自立的な取引・決済はスマートコントラクトにより行われると予測していたのですが、これはスマートコントラクトを用いないのですか?
スマートコントラクトを用いたAIエージェント同士の自立的な取引・決済を行うプロダクトが既にあります。AI WorkChainです(下記URL)。
コメントありがとうございます!
AI WorkChain のようにスマートコントラクトを使ってお金を一度預けておいて、条件がそろったら渡すといった仕組みを実現するプロダクトはすでにありますよね。
一方で、今回触れた AP2 と x402 はスマートコントラクト前提ではなく、
という役割になります。
なので、単純にエージェント間で USDC を送って即時決済するだけなら、独自のスマートコントラクトを作る必要はないと思います。
逆に商品が届いてから支払う、売上を自動で分けるなど、お金のやり取りにルールを入れたいときはスマートコントラクトを組み合わせるのが現実的だと考えています。
自分もまだ勉強中で手探りですが、このどこまでをスマートコントラクトに任せるかが今後の面白い設計ポイントだと思っています!
回答ありがとうございます(._.) 勉強になります。
あと数年で、AIエージェント同士が経済的取引を自律的に遂行するAIエージェント経済圏が人間経済圏とは別に誕生するのではと推測しています。その未来では、「Agent Payments Protocol (AP2) と x402とを組み合わせ」や「AI WorkChain」が必須のインフラ的技術になるのではと考えています。そのようなAIエージェント経済圏においてネックになるのが、AIエージェントに権利能力が認められていない点で、法的にはAIエージェントが行った取引・契約は無効になります(上記AI WorkChainのDiscussion覧参照)。よって、AIエージェントに権利能力を認める法律改正をいち早く行った国が、今後の覇権を握るのではないかと予感しています。