AIエージェントが有料APIに自律決済できる時代へ — AWSのAgentCore paymentsで秘密鍵なしにx402プロトコルを活用する

10月14日、AWSが「Building agents that transact with Anchor Browser and AgentCore payments」と題した記事を公開した。AIエージェントがHTTP 402で保護された有料APIやWebコンテンツに自律的に決済しながらアクセスできる仕組みを、Anchor BrowserとAmazon Bedrock AgentCore paymentsを組み合わせて実装する方法が詳しく紹介されている。

AIエージェントが「支払い」でつまずく問題

AIエージェントが有料リソースにアクセスしようとすると、サーバーはHTTP 402 Payment Required を返す。エージェントには支払い機構が組み込まれておらず、タスクはそこで止まり、人手による介入が必要になる。

この問題は今後さらに顕在化する。プレミアムデータセットのクエリ課金、APIの従量制、有料パブリッシャーのコンテンツゲートといったモデルが広がっており、エージェントが自律的に動くためには支払い能力が不可欠になりつつある。

x402プロトコルとは

本記事で中心的に扱われるのが x402プロトコル だ。x402は、HTTP 402ステータスコードをベースにしたオープンなマシン間決済標準で、Coinbaseが主導して策定・公開している（x402仕様）。サーバーが402レスポンスに決済条件（金額・支払い方法・送金先）を含め、クライアントが暗号証明をヘッダーに添付して再リクエストするという、シンプルかつHTTPネイティブな設計が特徴だ。

現時点ではまだ普及段階にあるプロトコルだが、AIエージェントによる自律的なAPI消費が増加する中で、マシン間の少額決済を標準化する手段として注目が高まっている。AgentCore paymentsはこのx402プロトコルのv1・v2双方に対応している。

開発者が自前で実装すると何が大変か

記事では、開発者が自前で決済スタックを構築しようとした場合の課題を4つに整理している。

ペイメントプロトコルの処理：402レスポンスのパース、暗号証明ヘッダーの構築、複数の支払いスキームへの対応
セキュリティと鍵管理：秘密鍵の安全な保管、鍵のローテーション、プロバイダー切り替え
運用上の堅牢性：セッション状態を維持したままのリトライ、べき等性の担保、同時実行時の予算管理
監査とコンプライアンス：全決済試行・承認・拒否・決済のログ記録

さらに深刻なのがセキュリティリスクだ。秘密鍵をエージェントランタイム内に置くと、信頼できないWebページや外部依存と同じ実行環境に鍵が存在することになる。バグやリトライループ、プロンプトインジェクションが誤った支払いを連鎖させるリスクも現実的に存在する。

Anchor Browser + AgentCore paymentsによる解決策

この構成の核心は「決済スタック全体をマネージドインフラに移す」という設計方針にある。

AgentCore payments は以下を担う：

PaymentManager：AWSアカウント単位で決済操作を統括するトップレベルリソース
PaymentConnector：外部ウォレットプロバイダーとの接続。対応するのは Coinbase CDP（Coinbaseが提供する開発者向けウォレット・オンチェーンインフラ）と Stripe Privy（Stripeが提供するエンベデッドウォレットソリューション）の2種類
PaymentCredentialProvider：ウォレット認証情報をAgentCore Identity内に安全に保管
PaymentInstrument：支払い元となるウォレットアドレスの特定

エージェントランタイムには秘密鍵もウォレット情報も入らない。暗号証明の署名はAgentCore側で完結し、ブラウザやエージェントにはkey materialが一切渡らない設計だ。

Anchor Browser はクラウドベースのブラウザ自動化基盤で、ログイン状態の維持、ナビゲーション、ネットワークリクエストの処理、セッション録画をすべて同一ブラウザセッション内で管理する。決済もそのセッション内で完結するため、録画と実際の操作が一致する。

エンドツーエンドの決済フロー

Anchor Browserがブラウザセッション開始時にAgentCore PaymentSession を作成し、支払い手段と予算を紐付ける
エージェントがURLにアクセス、サーバーが402チャレンジ（金額・支払い方法・送金先）を返す
Anchor Browserが402ペイロードを読み取り、PaymentSessionに紐付いた支払い方法と照合
AgentCore paymentsが予算を検証し、設定済みウォレットプロバイダーを通じて暗号証明を生成・署名
ブラウザが署名済みプルーフをヘッダー（x402 v2: PAYMENT-SIGNATURE、v1: X-PAYMENT）に添付してリクエストをリトライ
マーチャントが証明を検証・決済し、保護されたコンテンツを返す

実装はシンプル

開発者側のコードは驚くほどシンプルだ。セッション作成時に session.x402: true を指定するだけで、決済に関するコードは一切不要になる。

セッション作成（JavaScript）

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

自動化コード（Playwright）

const { chromium } = require('playwright');
// x402有効セッションにCDP経由で接続
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// 通常のページと同様にナビゲート
await page.goto('https://premium-research.example.com/market-report');
// 決済は自動処理済み、コンテンツをそのまま取得
const content = await page.textContent('article');

ウォレットロジックも、ペイメントヘッダーの構築も、リトライコードも不要だ。既存のPlaywright・Puppeteer・Chrome DevTools Protocol（CDP）ベースのワークフローをそのまま流用できる。

前提条件と注意点

ANCHOR_API_KEY（Anchor Browser APIキー）が必要。Anchor Browserの公式サイトで取得できる
session.x402: true はサードパーティリソースへの支払いを制御するもので、Anchor Browser自体の利用料には影響しない
マーチャントのレスポンスが不正・予算超過・対応ネットワーク不一致の場合は、元の402レスポンスがそのままページに返る。自動化コード側で通常のHTTPエラーとして処理できる
AgentCore paymentsによる決済の可視性はAmazon CloudWatch経由で確認できる

詳細はBuilding agents that transact with Anchor Browser and AgentCore paymentsを参照していただきたい。