AIエージェントは、リクエストごとに課金されるWebリソースにアクセスする必要がますます高まっています。たとえば、プレミアムデータセットはクエリ単位で課金され、研究用APIは呼び出し単位で従量課金され、ペイウォールを設けた出版社はコンテンツを支払いの背後に隠しています。AIエージェントがこうしたリソースに遭遇すると、サーバーはHTTP 402 Payment Requiredを返します。エージェントには組み込みの支払いメカニズムがなく、セッションに紐付けられた予算もなく、この要求を満たすためのプログラム的な手段もありません。タスクは停止し、手動での介入が必要になります。
Anchor Browserとエージェント決済 エージェントに代わってマシン間決済ワークフローを処理します。以下との協業により開発されました。 AWS Generative AI Innovation Center Partner Agent Factory、現在利用可能となっています AWS Marketplace。本記事では、 Anchor Browser が Amazon Bedrock AgentCore payments と統合し、AIエージェントがx402で保護されたページやAPIを自律的に支払えるようにする仕組みについて解説します。x402プロトコルは、HTTPベースのマシン対マシン決済のためのオープン標準です。サーバーは402 Payment Requiredとともに、金額、受け入れ可能な決済手段、およびエージェントが取引を完了するために使用する支払いアドレスを返します。
Anchor Browserは、AIエージェント向けに特化して構築されたクラウドベースのブラウザ自動化ソリューションです。各エージェントセッションは管理されたブラウザ環境で実行され、認証状態の維持、ナビゲーションの処理、ネットワークリクエストのキャプチャ、ページ操作のライブビューの提供を行います。
Amazon Bedrock AgentCoreは、大規模にエージェントを構築、接続、最適化するための機能を提供します。Amazon Bedrock AgentCore paymentsはAgentCore内の完全マネージド型の機能で、AIエージェントがAPI、Model Context Protocol (MCP) サーバー、およびウェブコンテンツを自律的に検出、アクセス、支払うために使用できます。AgentCore paymentsはウォレット接続を管理し、インフラストラクチャ層で設定可能な支出上限を強制し、x402プロトコルを通じて決済を処理します。また、Amazon CloudWatchを通じて、決済試行、承認、拒否、および清算に関する可観測性も提供します。
Anchor Browserで実行されているエージェントが402レスポンスに遭遇すると、AgentCore paymentsが設定された予算内で取引を承認し、完了させます。ワークフローは中断されることなく続行されます。
課題
自律エージェントがx402で保護されたリソースに遭遇すると、ワークフローが停滞します。エージェントが、プレミアム調査レポートの取得や有料のデータエンリッチメントAPIの呼び出しなどのリクエストを行うと、サーバーはHTTP 402 Payment Requiredで応答します。支払いの仕組みがない場合、自律的に実行されるはずだったタスクには人間の介入が必要になります。
現在、開発者は決済スタック全体を構築する必要があります。この取り組みには、4つのカテゴリーの複雑さが伴います。
決済プロトコルの処理
- HTTPレスポンスから402チャレンジを検出して解析し、支払い必須のレスポンスを他の4xxエラーと区別すること。
- マーチャントが期待する正確な形式で暗号学的証明を含む正しい決済ヘッダーを構築すること。
- ベンダー固有のロジックをエージェントにハードコードすることなく、複数の 決済スキーム (exact、upto、およびプロトコルバリアント)をサポートすること。
- チャレンジ形式、サポートされるステーブルコイン、または清算のタイミングが異なる可能性のある、x402マーチャント実装間の互換性を維持すること。
セキュリティと鍵管理
- 決済に署名するための秘密鍵を保存すること。これは、信頼できない入力にさらされる環境での安全な鍵の保存を必要とします。
- 鍵のローテーション、認証情報の更新、プロバイダーのフェイルオーバーを含む、ウォレットのライフサイクル操作の管理。
運用上の耐障害性
- セッション状態、Cookie、およびリクエストコンテキストを保持しながら、決済ヘッダーを付けて元のリクエストを再送信すること。
- ウォレット操作に不可欠な冪等性の提供。
- 同時に実行されるエージェント間でリアルタイムの予算トラッキングを行いながら、セッションごとおよびトランザクションごとの支出制限を強制すること。
オブザーバビリティとコンプライアンス
- コンプライアンスと突合のために、すべての支払い試行、承認、拒否、決済を監査ログに記録すること。
管理された決済サービスがない場合、エージェントは決済スタック全体を内部に取り込む必要があります。402 レスポンスを返す x402 で保護された呼び出しのたびに、エージェントは支払いフロー全体を内部でオーケストレーションしなければなりません。これには以下が含まれます。
- Proof への署名。
- 正しいヘッダーの添付。
- リクエストの再試行。
- トランザクションの決済。
- 結果のログ記録。
これらの各ステップには、開発者が構築・保護・保守しなければならないカスタムコードが必要です。図 1 はこのアーキテクチャを示しています。エージェントには密結合した8つのコンポーネント(Wallet、Private Keys、Budget Controls、Sign Proof、Attach Header、Retry Logic、Settle Payment、Logging)が含まれています。エージェントは x402 API に接続しており、402 チャレンジが逆方向に、リトライが順方向に流れています。
図1: エージェント決済スタック
セキュリティ上の考慮事項は、エンジニアリングの取り組みにとどまらない。
管理されていない支出。 インフラレベルで強制される支出の上限がない場合、バグ、リトライループ、プロンプトインジェクション、あるいは不注意なアクセスによって意図しない支払いが発生する可能性があります。有料のエンドポイントをループでリトライし続けるエージェントは、手動での介入が行われるまで支払いを承認し続けます。
鍵の漏えい。 秘密鍵がエージェントのランタイム内に存在する場合、信頼されていないWebページ、サードパーティのツール、外部依存関係と同じ実行環境を共有することになります。これらの攻撃経路は、実際の資金を管理する認証情報を意図せず漏えいする恐れがあります。
サインアップフローの露出。 署名インフラにランタイムからアクセス可能な場合、脅威アクターが鍵へのアクセスや、不正な支配下にあるアドレスへの支払いのリダイレクトを試みる可能性があります。効果的な緩和策には、そもそも鍵をランタイムに入れないことが必要です。
ブラウザベースのエージェントには追加の制約が伴います。支払いは同じブラウザセッション内で行われなければなりません。そうでなければ、セッションの記録やライブビューが実際に実行された内容と一致しなくなります。
解決策
Anchor BrowserとAgentCore paymentsは、決済スタック全体をマネージドインフラに移行することで、この複雑さに対処します。
ステートレスなツール呼び出しとは異なり、Anchor Browserは永続的なアイデンティティ、再現可能で決定論的なワークフロー、そしてログイン、ナビゲーション、タスクを確実に完了するために必要なセッションコンテキストを備えた本物のクラウドブラウザを提供します。認証、ナビゲーション、ネットワークリクエスト、録画、ライブビューはすべて同じブラウザセッション内で行われます。支払いが必要な場合、取引はそのセッション内で実行されます。録画には、リクエストから402、支払い、コンテンツ配信に至るまでの一連の流れがすべて記録されます。Anchorのエージェントには、ブラウザコンテキスト内で有料API呼び出しをネイティブに処理するx402ツールが組み込まれています。この組み込みツールを使用しても、既存のPlaywright、Puppeteer、Chrome DevTools Protocolベースのワークフローに変更を加える必要はありません。
AgentCore Payments は決済レイヤーとして機能します。このサービスの中心となるのは Payment Manager であり、AWS アカウントの決済オペレーションを調整する最上位のリソースです。Payment Manager の作成には、オーソライザータイプと IAM ロールの指定が必要です。その後、AgentCore は Amazon Bedrock AgentCore Identity 内に対応するワークロード ID をプロビジョニングします。
残りのコンポーネントは、Payment Managerを外部ウォレットインフラに接続します:
- A PaymentConnector Payment Managerと外部ウォレットプロバイダー(Coinbase Developer Platform(Coinbase CDP)またはStripe Privyのいずれか)を統合します。
- A PaymentCredentialProvider AgentCore Identity にウォレットプロバイダーの資格情報を安全に保存します。
- A PaymentInstrument 資金が引き出される特定のウォレットアドレスを識別します。
Anchor Browserは、対応するウォレットプロバイダーを通じてAgentCore paymentsでウォレットをセットアップします。ウォレットのシークレットや秘密鍵をエージェントランタイム内に置くことはありません。AgentCore paymentsは、設定されたプロバイダーを通じてウォレット操作を処理します。エンドポイントの検出については、AgentCoreは厳選された Amazon Bedrock AgentCore Gateway 経由での Coinbase x402 Bazaar MCP サーバーそのため、エージェントは利用可能なペイパーユースのx402エンドポイントをプログラムによって発見できます。
AgentCore payments は決済アーキテクチャを再構築します。機密性の高い操作はエージェントランタイムの外部にある管理対象サービス層へ移されます。Anchor Agent が保持する決済関連コンポーネントは、予算セッションと x402 ツールの2つだけです。認証、ウォレットシークレット、決済上限、オブザーバビリティ、決済証明の署名を含むインフラは、AgentCore payments 層に配置されます。Figure 2 は、Anchor Agent が AgentCore payments の管理対象層に接続する様子を示しており、この層が Coinbase CDP または Stripe Privy とのウォレットプロバイダ統合を処理します。
Figure 2: Anchor Browser の AgentCore payments との統合
支払いフローの仕組み
以下のステップは、ブラウザセッションがx402で保護されたリソースに遭遇した瞬間から、エージェントがレスポンスを受け取りタスクを続行する瞬間までの、エンドツーエンドの流れを説明するものです。
- Anchor Browserは、ブラウザセッション専用のAgentCore PaymentSessionを作成します。 x402 が有効な状態でセッションを開始すると、Anchor Browser は AgentCore payments を通じて PaymentSession をプロビジョニングし、ブラウザセッションを設定済みの支払い手段と予算に紐付けます。
- ブラウザは HTTP 402 Payment Required レスポンスを受け取ります。 エージェントはURLにナビゲートするか、fetchまたはXMLHttpRequest（XHR）リクエストを行います。マーチャントは、金額、受け入れ可能な支払い方法、および支払い先アドレスを指定した402チャレンジで応答します。
- ブラウザが互換性のある支払い方法を選択します。 Anchor Browserは402チャレンジのペイロードを読み取り、要求された支払い方法をPaymentSessionにリンクされた決済手段と照合します。
- AgentCoreはセッション予算を検証し、暗号化された支払い証明を生成します。 AgentCore paymentsは、支払い金額がセッションの支出限度額の範囲内であることを検証します。その後、サービスは設定されたウォレットプロバイダー(Coinbase CDP または Stripe Privy)を使用してトランザクションに署名し、暗号学的証明を返します。鍵素材がブラウザやエージェントランタイムに渡されることはありません。
- ブラウザは支払いヘッダーを付けて元のリクエストを再試行します。 ブラウザは署名済みの証明を次として添付します。
PAYMENT-SIGNATUREx402 v2 の場合、またはX-PAYMENTx402 v1 向けの場合は、その後、元のリクエストをちょうど1回だけ再試行します。 - 加盟店は決済を検証・処理した後、保護されたリソースを返します。 加盟店は暗号学的証明を検証し、トランザクションをオンチェーンで決済して、コンテンツを提供する。エージェントはタスクを続行する。
このフロー全体を通じて、ウォレットの認証情報は AgentCore および設定されたウォレットプロバイダー内に保持されます。
前提条件
始める前に、有効な Anchor Browser API キーをお持ちであることを確認してください(ANCHOR_API_KEY）。作成方法については、Anchor Browserの クイックスタート ガイド。
自動x402支払いの設定
Anchor Browser にエージェント型決済を設定するには、セッションプロパティが1つ必要です。設定します。 session.x402 to true。このプロパティのデフォルトは次のとおりです: false。有効にすると、ブラウザセッションは、AgentCore paymentsによって署名された支払いを使用してx402で保護されたウェブサイトに自動的にアクセスし、同じブラウザセッション内で再試行できるようになります。有効化により session.x402 設定された支払い手段から実際の支払いを行うことをブラウザーに許可します。
以下の例は、cURLとJavaScriptを使用してAnchor Browserの支払い対応セッションを作成する方法を示しています:
cURL
curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"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);Chrome DevTools Protocolで接続した後、エージェントは通常どおりナビゲーションを行います。自動化コードにウォレットキーや支払いヘッダーを含める必要はありません。ブラウザーが402チャレンジ、支払い署名、再試行を透過的に処理し、ドキュメントナビゲーション、fetch、XHRリクエストに対応します。
支払いセッションの制限と動作
Anchor Browserは、AgentCoreペイメント統合を通じて、セッションレベルで以下のガードレールを適用します。支払い対応の各ブラウザセッションは、設定された支出制限と時間制限の中で動作します。具体的な制限については、次を参照してください。 Anchor Browser 技術ドキュメント.
merchant応答が不正な形式である場合、互換性のあるネットワークが提供されない場合、予算が枯渇した場合、または AgentCore payments が支払いを拒否した場合、ブラウザは元の 402 レスポンスをそのままページに返します。その後、自動化コードは 402 を標準的な HTTP エラーとして処理できます。
x402 セッションプロパティは、サードパーティのリソースへの支払いのみを制御します。このプロパティは Anchor クレジットの代わりになるものではなく、ブラウザセッションの支払いにも使用されません。
Anchor Browser向け自動化コード
Anchor Browser用の自動化コードは変更されません。次の例は、支払いに固有のコードが不要であることを示しています:
const { chromium } = require('playwright');
// Connect to the x402-enabled session via CDP
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// Navigate to an x402-protected resource exactly as with a free page
await page.goto('https://premium-research.example.com/market-report');
// The page loaded, the payment was handled automatically
// Extract content as normal
const content = await page.textContent('article');ウォレットロジックも、支払いヘッダーの構築も、リトライコードも不要です。エージェントはURLにアクセスします。サーバーが402を返した場合、Anchor BrowserがAgentCore paymentsと連携して支払い証明に署名し、適切な支払いヘッダーを付けてリクエストを再試行し、ページにコンテンツを届けます。自動化コードには、支払いが行われたことを示す表示のない、最終的にレンダリングされたページが渡されます。
このパターンは、ペイウォール付きのジャーナリズム、ライセンスされた金融データ、アクセス制限付きのAPIドキュメント、従量制の研究データベース、そして402チャレンジによってコンテンツへのアクセスを制限するその他のリソースに対して、一様に適用されます。
API呼び出し用の組み込みx402ツールを使用する
有料リソースはウェブページに限りません。多くは POST、PUT、その他の HTTP メソッドを前提とする API です。よくある例としては、データエンリッチメントサービス、プレミアム推論エンドポイント、ライセンスされたコンテンツ API などがあります。こうしたユースケースのために、Anchor Browser のエージェントには x402 ツールが組み込まれており、ブラウザコンテキスト内で標準的な HTTPS API のように呼び出すことができます。
あなたのエージェントは fetch または XHR を通じて API 呼び出しを行います。サーバーが 402 チャレンジを返した場合、ブラウザは AgentCore payments を通じて支払い署名を調整し、署名済みの支払いヘッダー付きでリクエストを再試行します。あなたのコードは、そのエンドポイントが無料であるかのようにレスポンスを受け取ります。このツールは特定のベンダー、モデル、フレームワークに縛られません。支払いは既存のツール群の下で動くセッションレベルの機能として動作し、エージェントコードの変更は不要です。
// Fetch call to a paid API endpoint within the x402-enabled session
const response = await page.evaluate(async () => {
const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({ company_domain: 'example.com' }),
});
return res.json();
});
// If the API returned 402, AgentCore handled payment automatically
// The response contains the enriched data
console.log(response);あなたの自動化コードはウォレットの認証情報を受け取りません。自動支払いが利用できるのは session.x402 〜する予定である true 「また、前項で説明した支出制限および有効期限の制限の対象となります。」
主なメリット
この統合により、支払いはアプリケーションコードからインフラストラクチャ層へと移行されます。
構築すべき支払いインフラストラクチャはありません。 統合すべきウォレットSDKも、書くべき402レスポンスパーサーも、実装すべきリトライループも、維持すべきヘッダー構築ロジックも、構築すべきカスタム監査ロギングもありません。AgentCore paymentsが支払いスタック全体を管理します。
既存のツールへの変更は不要です。 Anchor BrowserのPlaywrightスクリプト、Puppeteer自動化、Chrome DevTools Protocolコマンド、およびエージェントフローは、以前とまったく同じように機能し続けます。支払いはブラウザに付随するセッション機能であり、エージェントロジック、プロンプト、ツール定義の変更ではありません。
秘密鍵はランタイムに入りません。 署名と決済はAgentCore paymentsの内部で行われます。このサービスは、AgentCore Identityのセキュアな認証情報ストレージを通じてCoinbase CDPまたはStripe Privyと通信します。エージェントランタイムは、資金を移動できる鍵マテリアルにアクセスできません。
予算はインフラストラクチャレベルで強制されます。 すべてのセッションは、AgentCoreが支払いを承認する前に強制する、定義された支出限度額の範囲内で動作します。Amazon Bedrock AgentCore Observabilityは、Amazon CloudWatchを通じて完全な支払い監査証跡を提供します。セッションが支出限度額に達すると、AgentCore paymentsは支払いを拒否します。
有料タスクは正常に完了します。 有料のGETページが読み込まれます。有料のAPI呼び出しはレスポンスを返します。エージェントは402レスポンスで停止して手動介入を必要とするのではなく、ワークフローを完了させます。
請求は一元化されます。 Anchor Browserは、サードパーティのx402料金を、ブラウザセッション時間と同じ請求書のクレジットで決済します。管理すべき別個の暗号資産カストディはなく、監視すべきUSDC残高もなく、財務チームが消し込むべきオンチェーン決済もありません。
まとめ
Anchor BrowserはAgentCore決済と統合され、有料のウェブページや有料APIエンドポイントにおけるx402決済の課題に、AIエージェントが自律的に対応できるようにします。ウォレットの認証情報はエージェントコードの外に置かれ、カスタム決済インフラは不要です。
ウェブの多くがリクエストごとの課金モデルへ移行するにつれ、決済メカニズムを持たないエージェントは有料リソースを伴うタスクを完了できません。この統合はそのギャップを解消します。エージェントは定義された予算内で動作し、AgentCore Observabilityによる完全な可観測性を備え、ランタイムに暗号鍵材料を置かないまま、有料ワークフローをエンドツーエンドで完了します。
始めるには、以下のリソースをご覧ください: