Bedrock AgentCore Payments (Preview) — エージェントが財布を持って x402 で支払う時代へ

AIエージェントに「財布」を持たせるアップデートが出ました。Bedrock AgentCore に AgentCore payments（プレビュー）が追加され、エージェントが API・MCP サーバー・有料コンテンツを 自律的に発見して支払って取得することができるようになりました（2026年5月7日 AWS What’s New）。決済の裏側は Coinbase が主導する x402 プロトコルで、ウォレットは Coinbase CDP か Stripe Privy を選択できます。

これは面白いですね。re:Inventで発表されたAgentCoreのスタックに、ついに「金を扱う層」が乗ってきた形です。AIエージェント周辺の業界トレンドとしてもAgentic Commerceは2026年の最重要テーマの一つで、AWSがこのタイミングで参戦してきた意味は大きいと感じます。

自分も CLI をアップデートして実機で API スキーマを確認しつつ、x402 プロトコルと業界全体の動向をネットワーク屋ではなくAI/ML屋の目線で整理しておきます。

なにが起きたのか

要点は3つです。

1. エージェントが自分のウォレットで支払えるようになった。Coinbase CDP もしくは Stripe Privy のステーブルコインウォレットを AgentCore に接続し、エージェントの実行ループ内で自動的に支払いが完結します。エンドユーザーは事前にウォレットへ資金を入れて、エージェントに使用許可を付与しておくだけ。
2. HTTP の標準である x402 を採用。新しい独自プロトコルではなく、Coinbase が主導するオープン仕様の x402（HTTP 402 Payment Required を復活させる仕組み）をそのまま使います。すでに Cloudflare、Google、Vercel などが対応しており、業界標準化が進んでいるプロトコルです。
3. 支出ガードレールがインフラ層で強制される。PaymentSession 単位で maxSpendAmount と有効期限が設定でき、上限到達やセッション失効後はリクエストが拒否されます。エージェントの推論ループが暴走してもインフラ層で止まります。

公式ブログには以下のように記載されています（2026年5月7日 AWS Blog）。

When an agent sends a request to a paid endpoint and receives an HTTP 402 “Payment Required” response, payment processing authenticates with the configured wallet, executes the stablecoin payment, attaches payment proof, and delivers the content back to the agent, all within the execution loop.

つまり、エージェントが課金エンドポイントにリクエストを送って 402 が返ってきたら、AgentCore 側で（1）ウォレット認証、（2）ステーブルコインによる支払い、（3）支払証明の添付、（4）コンテンツの取得 までを全て実行ループ内で完結させる、ということです。エージェントの推論コード側からは「お金が絡んでいる」ことを意識する必要すらありません。

なぜ今、エージェントに決済が必要なのか

ここで一歩引いて業界の文脈を整理します。AWS自身が金融業界向けブログで以下のように書いています（2026年5月7日 AWS Industries Blog）。

AI agents transact autonomously on behalf of businesses and consumers. McKinsey estimates this agentic commerce will mediate $3-5 trillion in global commerce by 2030.

McKinsey が「2030年までに3〜5兆ドルの取引をエージェントが仲介する」と試算しており、これは agentic commerce という独立した経済領域として成立しつつあります。エージェントが本当に「経済主体」として動くためには、お金を持って動けないと話になりません。Privy（Stripe傘下）の Henri Stern CEO のコメントもまさにこの論点です（2026年5月7日 Stripe Newsroom）。

For agents to become meaningful economic actors, they need a way to hold and spend money.

ただ、ここで「クレジットカードを使えばいいじゃない」とはなりません。エージェントの取引は典型的に 1セント未満のマイクロトランザクション で、API 1コール 0.001 USDC、データ取得 0.0005 USDC、というレベル。クレジットカードのインターチェンジ手数料（最低でも数十セント）では成立しない経済性です。AWSの開発者ガイドにもこの点が明記されています（2026年5月時点 AWS Documentation）。

Transactions are typically microtransactions (often under $1 or fractions of a cent), making traditional payment methods cost-prohibitive due to high minimum transaction fees.

ここでステーブルコインと x402 の登場です。USDC 建てなら 1セント未満の支払いがほぼゼロコストで通り、為替変動のリスクもありません。

x402 プロトコルの仕組み

x402 は Coinbase が主導する HTTP ネイティブの決済標準で、長年休眠していた HTTP 402 Payment Required ステータスコードに新しい役割を与えるものです。フロー自体は素直で、4ステップで完結します。

1. クライアント（エージェント）が課金リソースにリクエスト送信
2. サーバーが 402 Payment Required を返し、PAYMENT-REQUIRED ヘッダーに支払い情報（金額、宛先、資産、ネットワーク）を含める
3. クライアントが支払いペイロードを署名し、X-PAYMENT ヘッダーに載せて再送
4. サーバーが Facilitator 経由で検証・決済し、コンテンツを返却

公式コンセプトドキュメントでは以下のように説明されています（2026年5月時点 AWS Documentation）。

The x402 protocol is an open, HTTP-native payment standard that repurposes the HTTP 402 status code for direct, programmatic payments. When an agent requests a paid resource, the merchant responds with HTTP 402 Payment Required including a payment payload that specifies the amount, recipient, asset, and network. The agent signs the payment and retries the request with the signed proof in the X-PAYMENT header.

Facilitator はオンチェーンの検証と決済を代行するサービスで、Coinbase 提供のホスト型 Facilitator は月1000トランザクションまで無料、超過分は 1件あたり $0.001 という料金体系になっています（2026年5月時点 Coinbase x402 Documentation）。対応ネットワークは Base、Polygon、Arbitrum、World、Solana で、ERC-20 トークン全般（USDC を含む）に対応しています。

x402 自体は AWS 専用の仕様ではなく、Cloudflare、Google、Vercel が支援する x402 Foundation が標準化を進めているオープン仕様です。2026年3月時点で Base 上で1億1900万トランザクション、Solana 上で3500万トランザクション、年間流通量で約6億ドルというボリュームに達しており、AWSが対応するに足る勢いの標準になりつつあります。

AgentCore Payments のリソースモデル

ここから AWS 側の実装に入ります。AgentCore Payments には5つの主要リソースがあり、それぞれが下のような関係になっています。

リソース	役割	プレーン
PaymentManager	最上位リソース。認可方式（IAM/JWT）と IAM ロールを持つ	Control
PaymentConnector	外部の決済プロバイダ（Coinbase / Stripe Privy）への接続	Control
PaymentCredentialProvider	認証情報を AgentCore Identity 経由で Secrets Manager に保管	Control
PaymentInstrument	実体としてのウォレット（ネットワークごとに分離）	Data
PaymentSession	1回の対話に対応する支出スコープ。上限と有効期限を持つ	Data

PaymentManager がワークロード単位、その下に PaymentConnector がぶら下がって外部プロバイダごとに分かれ、PaymentInstrument がチェーンごと（Ethereum / Solana）に分かれて実体のウォレットを表現する、という階層構造です。コンセプトドキュメントには以下のように記載されています（2026年5月時点 AWS Documentation）。

A PaymentSession is a scoped payment context that tracks spending for a single agent interaction. Each session has a configurable expiry duration and can optionally include spending limits (maxSpendAmount, currency) that enforce payment limits. When the session expires or the payment limit is reached, further payment requests within that session are denied. If a payment signing fails after a deduction, the amount is automatically rolled back.

注目したいのは「セッション単位の上限」と「失敗時の自動ロールバック」です。エージェントが暴走して上限を超えそうになっても拒否される、署名失敗時には差し引かれた残高が自動で戻る、というガードレールがインフラ層で効きます。これはアプリ側で実装するとそれなりに大変な部分で、マネージドで提供されるのは助かります。

自分の環境で API スキーマを確認してみる

AgentCore Payments の発表は5月7日でしたが、対応リージョンが us-east-1 / us-west-2 / eu-central-1 / ap-southeast-2 の4つだけで、自分の検証用環境（ap-northeast-1）には来ていません。実リソース作成は試せませんが、CLI に追加された API スキーマを確認できる範囲で見てみました。

検証環境

• AWS CLI: aws-cli/2.34.46 Python/3.14.5 Darwin/25.4.0
• リージョン: 検証は ap-northeast-1（API スキーマ確認のみ。実リソース作成は未対応リージョン）

CLI バージョン要件

AgentCore Payments のサブコマンドは AWS CLI v2.34.45 で追加されました（2026年5月7日 CHANGELOG 2.34.45）。CHANGELOG にも明記されています。

api-change:bedrock-agentcore-control: Launching AgentCore payments - a capability that provides secure, instant microtransaction payments for AI agents to access paid APIs, MCP servers, and content. It handles payment processing for x402 protocol, payment limits, and 3P wallet integrations with Coinbase CDP and Stripe (Privy).

2.34.44以下のCLIでは関連サブコマンドが存在しないので、これから検証する人は最初にCLIを更新する必要があります。自分も最初2.34.35だったので、brew upgrade awscli で2.34.46に上げました。

追加されたサブコマンド一覧

コントロールプレーンとデータプレーンの両方に、合計26個のサブコマンドが追加されています。

$ aws bedrock-agentcore-control help | grep payment
+o create-payment-connector
+o create-payment-credential-provider
+o create-payment-manager
+o delete-payment-connector
+o delete-payment-credential-provider
+o delete-payment-manager
+o get-payment-connector
+o get-payment-credential-provider
+o get-payment-manager
+o list-payment-connectors
+o list-payment-credential-providers
+o list-payment-managers
+o update-payment-connector
+o update-payment-credential-provider
+o update-payment-manager

$ aws bedrock-agentcore help | grep payment
+o create-payment-instrument
+o create-payment-session
+o delete-payment-instrument
+o delete-payment-session
+o get-payment-instrument
+o get-payment-instrument-balance
+o get-payment-session
+o get-resource-payment-token
+o list-payment-instruments
+o list-payment-sessions
+o process-payment

最後の process-payment がデータプレーン側の「実際の決済を実行するAPI」で、これがエージェント実行中に AgentCore SDK 経由で呼ばれます。

create-payment-credential-provider の中身

これが特に面白い部分です。Coinbase CDP と Stripe Privy で必要な認証情報の形が違うのを、credentialProviderVendor と Tagged Union 構造で表現しています。

$ aws bedrock-agentcore-control create-payment-credential-provider help
...
--credential-provider-vendor (string) [required]
   Possible values:
   +o CoinbaseCDP
   +o StripePrivy

--provider-configuration-input (tagged union structure) [required]
   coinbaseCdpConfiguration -> (structure)
      apiKeyId -> (string) [required]
      apiKeySecret -> (string) [required]
      walletSecret -> (string) [required]
   stripePrivyConfiguration -> (structure)
      appId -> (string) [required]
      appSecret -> (string) [required]
      authorizationPrivateKey -> (string) [required]
      authorizationId -> (string) [required]

Coinbase 側は apiKeyId / apiKeySecret / walletSecret の3つ、Stripe Privy 側は appId / appSecret / authorizationPrivateKey / authorizationId の4つで、API 設計の上では完全に対等な選択肢として扱われています。コンセプトドキュメントによれば、保管された認証情報は AWS Secrets Manager に裏側で保存され、AgentCore Identity が ARN で参照する形になります（2026年5月時点 AWS Documentation）。

A PaymentCredentialProvider is a specialized credential provider in AgentCore Identity designed for cryptocurrency payment protocols. It securely stores vendor-specific credentials (such as Coinbase CDP API keys and wallet secrets, or Privy app credentials and authorization keys) in AWS Secrets Manager. At runtime, the Payments service retrieves authentication tokens through the AgentCore Identity GetResourcePaymentToken data plane API.

ここで AgentCore Identity が出てくるのが重要なポイントです。エージェントが直接 Coinbase API キーを触ることはなく、ランタイムでは GetResourcePaymentToken API 経由で短期トークンを取得して使う、という設計になっています。Workload Identity と OAuth2 ベースのスタックを既に持っている AgentCore Identity の上に綺麗に乗っています。

create-payment-session の支出ガードレール

セッション作成時に、上限と有効期限を必須として入れることができます。

$ aws bedrock-agentcore create-payment-session help
...
--payment-manager-arn <value>                    [required]
--limits <value>                                 (optional)
--expiry-time-in-minutes <value>                 [required]

--limits 構造:
  maxSpendAmount={value=string,currency=USD}

制約:
  expiry-time-in-minutes: 15〜480 minutes
  currency: USD のみ

セッションの有効期限は 15分〜8時間 にハードキャップされていて、最大でも8時間より長くは引っ張れません。これは設計判断として面白いです。エージェントが「永久に動き続ける財布」を持たないようにするための制約だと思います。

通貨も現在は USD のみ。ステーブルコインは USDC ベースなので、自然な選択ではあります。

Strands Agents との統合

ドキュメントの Quick start に Strands SDK の最小コードが載っているのですが、API 直叩きと比べてかなり薄く書けます（2026年5月時点 AWS Documentation）。

from strands import Agent
from strands_tools import http_request
from bedrock_agentcore.payments.integrations.config import AgentCorePaymentsPluginConfig
from bedrock_agentcore.payments.integrations.strands.plugin import AgentCorePaymentsPlugin

config = AgentCorePaymentsPluginConfig(
    payment_manager_arn="arn:aws:bedrock-agentcore:us-west-2:123456789012:payment-manager/pm-abc123",
    user_id="test-user-123",
    payment_instrument_id="payment-instrument-xyz789",
    payment_session_id="payment-session-def456",
    region="us-west-2",
)

plugin = AgentCorePaymentsPlugin(config=config)
agent = Agent(
    system_prompt="You are a helpful assistant that can access paid APIs.",
    tools=[http_request],
    plugins=[plugin],
)

agent("Access the premium endpoint at https://example.com/paid-api")

ポイントは「エージェント側のコードが http_request ツールを使うだけで、402が返ってきたときの処理を一切書いていない」ことです。プラグインを差し込んでおけば、HTTP リクエスト経路上で 402 を検知して x402 のネゴシエーションが自動で走ります。

このあたりは AWS が公開しているサンプル（2026年5月時点 aws-samples/sample-agentcore-cloudfront-x402-payments）を見ると、CloudFront + Lambda + AgentCore + Strands を組み合わせた 「売り手」と「買い手」両方のエージェント を CDK で立てる構成になっていて、boto3 で create_payment_credential_provider → create_payment_manager → create_payment_connector → create_payment_instrument → create_payment_session の5ステップを通すサンプルコードもあります。料金体系も明示されていて、get_premium_article が 0.001 USDC、get_dataset が 0.01 USDC、というレンジでした。

AgentCore スタック上の位置付け

AgentCore Payments は単体では成立せず、既存の AgentCore コンポーネントと組み合わせて使う前提です。公式ドキュメントの “Related services” セクションに、明確に4つの連携先が並んでいます（2026年5月時点 AWS Documentation）。

• AgentCore Identity - Securely store and federate payment credentials to help implement least permissions principle for access. Your Coinbase API keys and Stripe/Privy Wallet credentials will be securely stored here as a PaymentCredentialProvider.
• AgentCore Gateway - Connect to paid MCP servers ensuring your agents have secure access to them via AgentCore Gateway. You can also leverage pre-existing integration of Coinbase x402 Bazaar through AgentCore Gateway to discover thousands of existing paid MCP tools.
• AgentCore Browser - AgentCore Browser, together with AgentCore payments, helps you autonomously and securely access paywalled websites that support x402.
• AgentCore Observability - Helps you trace, debug, and monitor AI agents’ performance in production environments. AgentCore payments provides metrics and traces for you to observe for your AI agent.

特に Gateway 経由で利用できる Coinbase x402 Bazaar が要注目です。これは Coinbase が運営する x402 対応エンドポイントの「マーケットプレイス」で、すでに 10,000以上の有料 MCP ツールが登録されているとのこと。AgentCore Gateway のターゲットとして登録すれば、エージェントが検索・発見・支払いまで自律的に行えます。エージェントが「いま必要な機能を実行時に動的に買ってくる」ような世界観です。

Browser との組み合わせも面白くて、これは x402 に対応した有料記事サイト等を、エージェントがブラウザで踏み込んで自動的に支払って読む という用途。新聞社の有料記事を AI が代理で読む、というシナリオが現実味を帯びてきました。

ユースケース

開発者ガイドが5つの具体的なユースケースを挙げています（2026年5月時点 AWS Documentation）。

1. Research — Research agents can operate with allocated budgets, intelligently selecting and purchasing access to specialized paid data sources on demand to deliver insights while staying within cost constraints.
2. Financial analysis — Financial analysts can use agents to pay for access to real-time market data behind paywalls.
3. Browser agents — Browser-based UI or browser agents can navigate and extract content from websites that monetize or restrict bot access.
4. Pay-per-intelligence — Agents can dynamically route tasks to the optimal AI model, paying only for actual token usage rather than maintaining subscriptions across multiple model providers.
5. On-demand storage — Agents can provision temporary storage resources on demand with granular pay-per-use pricing.

個人的に一番気になるのは Pay-per-intelligence です。今は LLM プロバイダごとに API キーと請求関係を別々に持つ必要がありますが、これが x402 ネイティブで提供されると、エージェント自身が「このタスクなら Claude 4.7、こっちは Gemini」と動的に選んで支払えるようになります。マルチモデル基盤のコスト最適化が、エージェント実行時の判断に組み込まれる。これは2026年後半〜2027年に向けて大きく動きそうな領域だと感じます。

エンドユーザーへの資金の流し方

ここまでエージェント目線で見てきましたが、実際に使うときに重要なのは「誰が、どうやってウォレットに金を入れるか」です。コンセプトドキュメントの persona セクションを読むと、設計が明確に分離されています（2026年5月時点 AWS Documentation）。

End user: End users interact with the agent to achieve a specific goal. They can top up agent balance through crypto-based stablecoins or traditional payment methods like Credit cards (limited availability due to geographical restrictions), Debit cards, Apple Pay, Google Pay, or ACH so that agents can execute transactions on their behalf, with spending permissions, configurable spending limits, and full transparency into how their funds are used.

ステーブルコインだけでなく、デビットカード / Apple Pay / Google Pay / ACH からの資金供給に対応している、というのが地味に大きなポイントです。エンドユーザーは「暗号通貨を扱う」感覚なく、馴染んだ決済手段でエージェント用ウォレットにチャージできる。クレジットカードは「地理的制約により限定的」とわざわざ注記されているのが正直で好印象でした。

Coinbase 側の発表でも同じ思想が読み取れます。「ウォレットを持つ」のは内部実装の話で、ユーザー体験としては既存の決済手段が裏でステーブルコインに変換されてエージェントが使える、という形になります。

競合の動きと位置付け

Agentic Commerce の決済プロトコル戦争は2026年に入って急加速していて、AWS の今回の動きはその文脈で読み解く必要があります。

プレイヤー	動き
Coinbase	x402 プロトコル策定、CDP ウォレット、Facilitator サービス、x402 Bazaar
Stripe / Privy	埋め込み型ウォレット基盤、AWS と提携
Cloudflare	x402 Foundation 共同設立、エッジでの x402 トランザクション処理
Google	x402 Foundation サポート
Vercel	x402 Foundation サポート
AWS	AgentCore Payments で x402 ネイティブ統合（今回）

x402 Foundation の発足と、Cloudflare・Google・Vercel・AWS が揃って x402 を採用したことで、HTTP ネイティブ決済 = x402 という業界標準のポジションがほぼ確定しました（2025年9月23日 Cloudflare Blog - x402 Foundation）。AWSが独自プロトコルではなく x402 をそのまま採用したのは、自分から見ると珍しい判断です。AgentCore Gateway が MCP（Anthropic 主導）を採用したのと同じ流れで、プロトコル層は標準に寄せて、価値はマネージドサービス側で出す、という戦略に見えます。

事例としては Warner Bros. Discovery と Heurist AI が早期利用者として名指しで挙がっています。Heurist のコメントは以下（2026年5月7日 AWS Blog）。

we were able to integrate payments quickly to our agent with low effort and few lines of code

「短期間でエージェントに決済を組み込めた」というよくある先行事例コメントですが、Strands プラグインのコード量を見る限り、誇張ではなさそうです。

現時点での注意点

プレビューなので、まだいくつか制約があります。

• 対応リージョンが4つだけ。us-east-1 / us-west-2 / eu-central-1 / ap-southeast-2 のみ。東京（ap-northeast-1）は未対応です（2026年5月時点 AWS Documentation）。
• 通貨は USD のみ。create-payment-session の currency 列挙型は USD のみが許可されています。
• セッション有効期限は最長8時間（15〜480分）。長時間バッチ処理する場合は明示的に再作成が必要。
• マイクロペイメント中心。発表時点では「APIコール・データフィード・ペイウォール記事」が主用途で、より大きな取引（ホテル予約等）は将来拡張予定とアナウンスされています。
• Terraform AWS Provider は未対応。terraform-provider-aws のCHANGELOG（2026年5月時点）には payment_manager 系のリソースは未追加です。GitHub Issue #43424 で AgentCore全般のサポートが議論されている段階で、Gateway / Memory / Runtime は既に対応していますが、Payments はこれから。IaC 派の人は CDK か CloudFormation 経由でしばらく我慢する形になります。
• 料金体系は未公開。AgentCore Payments 自体の手数料、Coinbase Facilitator 経由のオンチェーン手数料、ステーブルコイン送金手数料の3層構造になるはずですが、AgentCore 側の手数料の明示はまだありません。

そして大前提として、ウォレットを使う以上は Coinbase CDP もしくは Stripe Privy のアカウントが必要 です。AWS だけで完結する話ではなく、外部の暗号通貨基盤事業者との契約・運用が前提になる点はエンタープライズで導入する際の確認事項として大きいと思います。

自分の感想

AgentCore に決済層が乗ってきたことで、AI/ML 屋として「エージェントの実装」と「経済活動の実装」が並列で進む時代になったなと感じます。これまでも boto3.client("bedrock-runtime").invoke_model() で何でもできましたが、ここから先は「エージェントが何にいくら使ったか」をオブザーバビリティで監視しながら、その上でモデル選定・ツール選定の最適化を回す、という新しい運用が増えてくるはずです。

特に Pay-per-intelligence のアイデアは熱いと思います。今は推論コスト最適化を「事前に Bedrock のモデル選択を仕込む」「Prompt Caching を有効化する」みたいな手作業でやっていますが、エージェントが実行時に「このタスクは Haiku で十分、こっちは Opus を呼ぶ」と判断して その場で支払って使う ようになると、最適化のレイヤーが一段上がります。コスト最適化が好きな自分としてはここに大きな可能性を感じています。

ただし、エージェントが財布を持つ世界はガバナンスが難しくなります。maxSpendAmount と8時間上限のセッションだけでは、組織全体の支出を追えません。CloudWatch / X-Ray で全 process-payment を可観測にしているのは正しい設計ですが、「誰がいつ何を買ったか」を BI 系のダッシュボードに流して人間が見られる形にする運用は、各社で自前で組む必要が出てくると思います。

東京リージョン対応は早めに来てほしいところですが、決済（特にステーブルコイン）絡みは規制対応もあるので、GAまでは少し時間がかかりそうです。それまでに us-west-2 でサンプルを動かしておいて、業界トレンドを追いつつ、自分の社内ユースケースに合わせた設計を考えておくのが良いと感じました。

x402 自体は AWS の中だけの話ではないので、AgentCore Payments を使わなくても 自分の API を x402 対応にしてエージェントから課金で売る側に回る という選択肢も出てきます。「AI エージェント向けに API を売る」というビジネスモデルが現実的になった、というのが2026年の景色の変化として一番大きいかなと感じています。