メインコンテンツまでスキップ

エージェント決済：x402、MPP、AgentCore GA

上級

この 2 年間、エージェントは何かを買うと決めることは非常に得意で、実際に支払うことは非常に苦手でした。回避策はいつも同じでした — API キーを事前に発行し、共有のクレジットカードをエージェントに渡し、取り消せない請求を積み上げないことを祈る。2026 年にそのギャップは閉じました。ひとつの大きなアイデア — HTTP 402 を、本来意図されていた通りに使う — を中心に小さなスタックが登場し、実際のビジネスが必要とするガードレールで包んだ、一般提供（GA）の本物の AWS サービスが今や存在します。このページはそのスタックの実践的なフィールドガイドです。x402 がワイヤ上でどう動くか、なぜ upto スキームが興味深いのか、AgentCore Payments が GA で実際に何を提供するのか、そしてどこに鋭いエッジがあるのか。

What you'll learn
  • 生の x402 チャレンジを読み、3 つのヘッダー、2 つのファシリテーター呼び出し、3 つの決済スキームを理解する
  • exact と upto を区別し、自分のエンドポイントがどちらを広告すべきか判断する
  • 悪いプロンプトでエージェントにウォレットを空にされないよう、決済セッションの支出上限と有効期限を設定する
  • AgentCore Payments 内で Coinbase Privy（暗号資産レール）と Stripe Privy（カードレール）を選び分ける
  • 3 つの現実的な脅威を認識する：購入へのプロンプトインジェクション、ファシリテーターの不正、そして「upto」の過剰決済

なぜ「エージェントがそのまま支払う」は思ったより難しいのか​

エージェントが実際の支出権限を持った瞬間、4 つのことが同時に壊れます。

  • API キーモデルは回避策だった。 今日の「エージェントフレンドリー」な API はどれも、キーを発行し、残高をチャージし、その文字列をエージェントに渡すよう求めます。会計をしているのは人間で、エージェントは単なるクライアントです。エージェントが買うものはすべて、人間が事前にコミットした資金プールから支出されます。
  • カードはセッションごとに買い手 1 人を想定して設計された。 カードは「支払う」をクリックする人がいることを前提にしています。エージェントはファンアウトしたい — 1 時間で 30 サイトにわたって 200 個の小さなものを買う — そして各購入はアトミックで、安く、可逆であるべきです。
  • ディスカバリーが存在しない。 人間の買い手は料金ページを読めます。エージェントには、機械可読な「これがこの価格で、こう支払う」がレスポンスの中にインラインで必要です。
  • ガードレールはエージェント以外の場所で強制されなければならない。 唯一の制限が「10 ドル以下で支出せよ」というプロンプトなら、エージェントはいつかそれに逆らいます。制限は、モデルが言い逆らえないインフラの中に存在しなければなりません。

x402 はディスカバリーの問題に取り組みます。AgentCore Payments はガードレールの問題に取り組みます。両者は競合ではなく補完関係です。

ワイヤ上の x402 — プロトコル全体をひとつのフローで​

x402 は、GitHub 上の x402-foundation/x402 組織が維持するオープンプロトコルです（Apache-2.0、執筆時点で約 6.5k スター）。その仕掛けのすべては、HTTP ステータスコード 402 Payment Required に、人々がずっとそこにあると思い込んでいた意味論を与えることです。

完全なフローはちょうど 6 手です。セッションも、ログインも、キーもありません。

Guided walkthrough1 of 6
  1. エージェントが有料エンドポイントに通常の HTTP リクエストを行います。認証ヘッダーもウォレットもなし。

立ち止まって考える価値のある設計ポイントが 2 つあります。第一に、いつ決済するかを決めるのはクライアントではなくサーバーです。ステップ 4 の後にリクエストが失敗すれば、サーバーは /settle を呼ばないので、エージェントには課金されません。署名は短い有効期限を持つ承認であり、単にタイムアウトします。これこそが、x402 をエージェントにとってそもそも使えるものにしている性質です：失敗したダウンロードは無料のダウンロード。第二に、ファシリテーターはクライアントの資金を決して保管（カストディ）しません。プロトコルが明示する不変条件は「すべての決済スキームは、ファシリテーターがクライアントの意図の外で資金を動かすことを許してはならない」です。不正なファシリテーターは決済を拒否できますが、過剰決済はできません。

3 つのスキーム — そしてなぜ upto が興味深いのか​

x402 はスキームを、どの通貨を使うかではなく、金額がどう合意されるかとして定義します。現在の安定した集合は次の通りです。

  • exact — サーバーが固定価格を広告し、クライアントがちょうどその金額に署名します。読むごとのコストが分かっているコンテンツに最適：「この記事は 0.02 ドル」。シンプルで、退屈で、正しい。
  • upto — サーバーが上限を広告します。クライアントはその上限までを承認する署名をし、サーバーは決済時に上限以内で実際の請求額を選びます。興味深い経済性を解き放つのはこれです。
  • batch-settlement（EVM） — 高頻度利用向け。クライアントはエスクロー預託を一度行い、その後多数のオフチェーンバウチャーを積み上げ、それらは単一のバッチ化されたオンチェーン決済で償還されます。信頼モデルは同じで、リクエストあたりのガス代は劇的に低くなります。

upto は推論ごとの課金（pay-per-inference）と動的価格設定を可能にするスキームです。トークン単位で推論を売るなら、リクエスト時点では補完が何トークン使うか分かりません。分かるのはレスポンス時点です。exact では、過剰請求する（上限に切り上げて返金する — 2 回目のオンチェーン操作が必要）か、過少請求する（クライアントは 4k トークン分を支払い、あなたは 10k 生成する）かのどちらかです。upto では、クライアントが*「最大 10k トークン分まで請求してよい」*と署名し、あなたがレスポンスを生成し、それから実際の使用量で決済します。AWS の AgentCore Payments GA リリースは、これをローンチが可能にするパターンとして特に強調しています：「x402 内の upto スキームにより、エージェントは固定価格にコミットするのではなく、支出上限を設定できる」。

失敗モードに注意してください：サーバーが実際の使用量ではなく上限で決済した場合、クライアントには差額に対するオンチェーンの救済手段がありません — 署名がそれをカバーしているからです。 /settle 呼び出しの金額パラメータは信頼されます。実務ではこれが、自分で運用するか信頼できるファシリテーターを使いたい理由です。詳しくは後述します。

実際に出会うチェーンと SDK​

現在の x402 モノレポは EVM、SVM（Solana）、AVM、Aptos、Stellar、TVM、Hedera、Keeta 向けの SDK パッケージを公開していますが、今日のトラフィックは Base（Coinbase の EVM L2）と Solana に大きく集中しており、どちらも USDC で決済されます。TypeScript で実際にインポートするパッケージは @x402/core、チェーンモジュールのいずれか（@x402/evm、@x402/svm、…）、そしてクライアントラッパー — 402→署名→再試行のループを透過的に処理する fetch() のドロップイン代替である @x402/fetch、またはサーバー側では @x402/express / x402-hono です。Python には単一の x402 pip パッケージがあり、Go には github.com/x402-foundation/x402/go/v2 があります。

Cloudflare はさらに短い道を提供しています。Agents パッケージ内の agents/x402 サブモジュールは x402 を組み込んだ MCP クライアントを与え、x402-hono は Worker 用のペイウォールミドルウェアです。つまり、ルートを有料エンドポイントに変える Cloudflare Worker はおおよそ次のようになります。

Hono のルートを x402 ペイウォールにする

import { Hono } from "hono";
import { paymentMiddleware } from "x402-hono";

const app = new Hono();

app.use("/premium/*", paymentMiddleware({
network: "base",
facilitator: "https://facilitator.x402.org",
routes: {
  "/premium/summary": {
    price: { asset: "USDC", amount: "0.05" },
    scheme: "exact",
    recipient: "0xYourMerchantAddress",
  },
  "/premium/inference": {
    price: { asset: "USDC", maxAmount: "0.50" },
    scheme: "upto",
    recipient: "0xYourMerchantAddress",
  },
},
}));

app.get("/premium/summary", c => c.text("The paid content."));
app.get("/premium/inference", c => c.text("The paid inference result."));
export default app;

@x402/fetch を使う呼び出し側は、このどれも知る必要がありません — ラッパーが 402 を見て、署名し、再試行し、通常の fetch と同じように最終的な 200 レスポンスを返します。

AgentCore Payments GA — AWS が 2026-08-18 に実際に出荷したもの​

x402 だけではプロトコルにすぎません。エージェントがどう支払うかは得られます。支払うべきかどうかは得られません。それこそが、Amazon Bedrock AgentCore Payments — 5 月のプレビューを経て 2026 年 8 月 18 日に GA — が実際に解決する問題です。

理解すべきプリミティブは**決済セッション（payment session）**です。エージェントが行うすべての支払いはその中で実行されなければならず、セッションにはちょうど 2 つの上限があります。

  • 指定通貨での最大支出額。
  • 有効期限。

どちらもインフラ層で決定論的にチェックされます — モデルの外、エージェントフレームワークの外、モデルが言い逃れできるあらゆるものの外で。累積支出が上限を超えることになるリクエストは、決済ペイロードに署名される前に拒否されます。有効期限後のリクエストも同じように拒否されます。それがガードレールです。これが機能するためにモデルが十分にアラインされている必要はありません。十分に制約されていればよく、制約はセッションの中にあります。

このプリミティブを中心に、AgentCore は次のものを GA にしました。

  • Coinbase と Stripe Privy ウォレット統合。 資格情報は AgentCore Identity Secrets Manager に置かれ、エージェントはそれを決して見ません。ウォレット操作を実際に承認するのは、短命の派生トークンです。エンドユーザーはカード（Stripe）または USDC（Coinbase）でチャージできます。
  • Coinbase の Quick Create。 プラットフォームを離れることなく、AgentCore コンソールまたは CLI の中から Coinbase の資格情報をプロビジョニングします。
  • Machine Payment Protocol（MPP） — x402 の上に載る決済抽象化で、エージェントが MPP 互換サービスと x402 エンドポイントの両方に、同じセッションと同じセッション上限で支払えるようにします。MPP はカードレールとステーブルコインレールの決済が出会う場所です。
  • キュレーションされた x402 対応 MCP サーバーディレクトリ — 「Coinbase Bazar」 — AgentCore Gateway を通じてエージェントに公開されます。有料エンドポイントの発見可能性は「ソーシャルプルーフ、メタデータの豊富さ、説明の質、可用性」でランク付けされます。これは、草コインの吸い取り屋のリストにならないよう努めている、という丁寧な言い方です。
  • フレームワークプラグイン。 Strands Agents プラグインと LangGraph ミドルウェアが GA で出荷され、x402 の HTTP クライアントを手書きすることなく、決済セッションのコンテキストがエージェントループを通して引き回されます。

Strands の配線は意図的に小さくなっています — payment-manager の ARN、ユーザー ID、payment-instrument ID、セッション ID を持つ AgentCorePaymentsPluginConfig を組み立て、プラグインをエージェントに追加します。セッションの強制はプラグインの下で行われます。

AgentCore Payments — Strands プラグインの最小構成

from agentcore_payments import AgentCorePaymentsPlugin, AgentCorePaymentsPluginConfig
import os

plugin = AgentCorePaymentsPlugin(
  config=AgentCorePaymentsPluginConfig(
      payment_manager_arn=os.environ["PAYMENT_MANAGER_ARN"],
      user_id="test-user-123",
      payment_instrument_id=os.environ["PAYMENT_INSTRUMENT_ID"],
      payment_session_id=os.environ["PAYMENT_SESSION_ID"],
  )
)
# Attach plugin to your Strands agent; the payment session caps
# (max spend + expiry) are set when you mint the payment session,
# NOT in the plugin config.

すべての支払い試行は CloudWatch のログエントリと AgentCore Observability のスパンを発行し、組み込みダッシュボードはエージェントごとの成功率、平均取引額、エンドツーエンドの健全性を表示します。これが、「エージェントが何か変なものを買った」を 1 週間後にも実際にデバッグ可能にする可観測性の部分です。

暗号資産だけではない — Stripe の位置づけ​

よくある誤読は、x402 と AgentCore Payments が*「エージェント向けの暗号資産」*だというものです。そうではありません。x402 がステーブルコインで最初に出荷されたのは、オンチェーン決済が、真に機械ネイティブでパーミッションレスなリクエスト単位の決済を持つ唯一のレールだからです。しかし AgentCore の MPP 抽象化と Stripe Privy 統合により、エージェントのセッションはカードから資金供給できます。この文脈で Stripe Privy が提供するのは、委任機能付きのカード裏付けウォレットです — 人間のユーザーがエージェントに、カードに対して支出するスコープ付きで取り消し可能な権限を渡し、AgentCore セッションがその上で支出上限を強制します。ステーブルコインのカストディをまったく望まないビジネスには、これが道です。

選び方：

  • Coinbase / Privy（Base または Solana 上の USDC）。 真のリクエスト単位のセント未満決済が必要なとき、チャージバックを望まないとき、取引相手が別のエージェントであるときに最適。
  • Stripe Privy（カード）。 マーチャントがオンチェーンレールを持たない普通のビジネスであるとき、平均単価がステーブルコイン手数料が支配的にならない程度に大きいとき、買い手にカードネットワークの異議申し立て権を持たせたいときに最適。

真剣に受け止めるべき 3 つの脅威​

自律的なエージェント決済は、小さく特定の攻撃面を開きます。設計で防ぐべき 3 つはこれです。

  • 購入へのプロンプトインジェクション。 エージェントのコンテキスト内の悪意あるページは、物を買うよう指示できます。防御は「モデルに拒否させる」ではなく、セッション上限です。正当なタスクを完了できる最小の支出上限と、最短の有効期限を設定してください。プロンプトインジェクションがエージェントに 10,000 ドル支出させようとしても、セッション上限が 5 ドルなら、インジェクションは失敗します。これは暗号学的コンテキストインジェクション：Grok とまったく同じ教訓です — 信頼境界はモデルの外に置く。
  • ファシリテーターの不正。 /verify 呼び出しは構造上正直です（悪い /verify は拒否しかできない）が、侵害された、あるいはビザンチンなファシリテーターは、サーバーがコンテンツを配信した後に /settle を拒否したり、upto モードで静かに過剰請求したり、ペイロードの有効期限を過ぎるまで決済を遅らせてクライアントの署名を無効にしたりできます。防御：マーチャント側の利用では自分で運用するファシリテーターを優先し、クライアント側では @x402/fetch の組み込みレシートチェックを使って、PAYMENT-RESPONSE が署名した内容と一致しなければ大きな音を立てて失敗させること。
  • upto の過剰決済。 upto では、決済額はサーバーが供給します。不正なサーバーは実際の使用量にかかわらず上限で決済できます。緩和策はプロトコルの外にあります：レスポンスボディに署名済みの使用量レシート（生成トークン数、ストリーミング秒数、配信バイト数）を含め、それと整合しない決済額を信頼しないこと。期待される最大値を返すコールバックを提供すれば、決済の受け入れを拒否するクライアントラッパーもあります。

これらは Cloudflare の WriteGuard が MCP 層で対処しようとしているものの形でもあります — 「お金がかかる」を、帰属と監査を伴う書き込みとして扱う — が、今日の荷重を支える制御は AgentCore のセッション上限です。MCP 層での WriteGuard 型の書き込み階層ポリシーとウォレット層での決済セッション上限を組み合わせることが、ほとんどの本番デプロイが落ち着くことになる二重の備えの姿勢です。

より広いエージェントの構図の中での位置づけ​

x402 はエージェントに取引する手段を与えます。MCP は、取引が起きるエンドポイントに到達する手段を与えます。A2A は、それ自身も支払いを受けるかもしれない別のエージェントに作業を委任する手段を与えます。実務では 3 つすべてが組み合わされます：A2A のハンドオフがピアエージェントを呼び出し、そのエージェントが MCP で x402 価格のツールに到達し、呼び出し側が AgentCore セッションを通じて支払う。人々が「エージェントのマネーレイヤー」と言うとき、意味しているのはこれです — 単一の製品ではなく、ディスカバリー、能力、決済のそれぞれにプロトコルがあり、そのどれも人間のループ介在を必要としないスタックのことです。

Check yourself

0/6
  1. x402 のやり取りで、サーバーは PAYMENT-REQUIRED ヘッダーに何を入れますか？
  2. なぜ `upto` スキームが推論ごとの課金を可能にするスキームなのですか？
  3. x402 プロトコルはファシリテーターについてどの不変条件を与えますか？
  4. Amazon Bedrock AgentCore Payments では、セッションの支出上限はどこで強制されますか？
  5. 成功した x402 の 200 レスポンスの `PAYMENT-RESPONSE` ヘッダーは何を運びますか？
  6. コンテキスト内の悪意ある Web ページ経由の購入へのプロンプトインジェクション攻撃から自律エージェントを守りたいとします。実際に効果を発揮する制御はどれですか？

覚えておく価値のある用語​

カードがまだありません — 追加して学習を始めましょう。🃏

出典と参考文献​

次へ​