AI-translated from English; not yet reviewed by a fluent editor.

# Anchor BrowserとAgentCoreの決済：エージェントがx402ペイウォールを通過する仕組み

> 開発者がセッションを有効にし、認可済みで予算を設定した決済手段を構成すると、Anchor BrowserはAgentCore paymentsを通じてx402課金ページやAPI呼び出しを再試行できます。

By BIG CHANGE Editorial

Published: 2026-10-14T05:55:23.177Z
Updated: 2026-10-14T05:55:23.177Z
Canonical: https://bigchange.ai/blog/anchor-browser-agentcore-x402-payments

![A payment card and blank purchase order sit on a track beside an adjustable mechanical stop with an orange knob.](https://bigchange.ai/api/media/file/payment-authority-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. Delegating a purchase still requires a boundary around payment authority. The intact card, order and adjustable stop are a conceptual illustration, not a depiction of a specific product.

AWSとAnchor Browserは[統合を文書化しました](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)。ブラウザーエージェントが既存のセッション中にx402で保護されたページやAPIの料金を支払えるようにします。ブラウザーはHTTP 402の決済チャレンジに応答し、Amazon Bedrock AgentCore paymentsから署名済みの支払い証明を取得してリクエストを再試行できます。開発者にとって重要な変更は処理の場所です。ブラウザーがチャレンジと再試行を担い、別途構成された決済サービスが支出権限を確認します。

## 大きな変化

- **何が変わったか：**x402チャレンジの後、課金されるWebリクエストをエージェントのブラウザーセッション内で完了できます。自動化コードにウォレットキーや決済ヘッダーを入れる必要はありません。開発者はそのセッションで決済を明示的に有効化する必要があります。
- **なぜ重要か：**リクエスト単位で課金されるデータやコンテンツを使うエージェントは同じワークフローを続けられます。一方、決済手段、ID権限、支出上限はページやエージェントの実行環境の外で管理されます。実際の購入判断が、運用担当者が設定・監視するインフラへ移ります。
- **注目点：**重要な境界は最初の402応答です。不正なチャレンジ、非対応の決済ネットワーク、予算切れ、支払い拒否が起きると、自動化からリソースにアクセスできません。開発者は引き続きその応答を処理する必要があります。

## 課金ページでブラウザーが行うこと

AWSとAnchorの[チュートリアル](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)は、Anchor Browserセッション内のドキュメントナビゲーション、`fetch`またはXMLHttpRequestの流れを説明しています。販売者は決済チャレンジ付きのHTTP`402 Payment Required`を返します。Anchorは条件を読み、セッションに紐づく決済手段と互換性のある方法を探します。AgentCoreはセッションの残予算を確認し、構成済みのウォレットプロバイダーで証明に署名します。ブラウザーは証明を**元のリクエスト**に加えて1回だけ再試行します。x402 v2では`PAYMENT-SIGNATURE`、v1では`X-PAYMENT`を使用します。販売者はリソースを返す前に支払いを検証し、決済します。

これは文書に記載された手順であり、BIG CHANGEが課金エンドポイントをテストした結果ではありません。AWSによると、ブラウザーは支払いと再試行の間もセッションのコンテキストを維持します。既存のPlaywright、Puppeteer、Chrome DevTools Protocolのワークフローは、決済ヘッダーを自分で構築せずにブラウザー経由でナビゲーションやAPI呼び出しを続けられます。支払いに成功しても、すべてのペイウォールを読めるわけではありません。サイトが対応するx402チャレンジを提示し、販売者が証明を受け入れて応答を提供する必要があります。

## 開発者が有効にする設定

ブラウザーのスイッチは明示的です。[チュートリアルのセッションリクエスト](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)では、`session.x402`の既定値は`false`です。`true`に設定すると、構成済みの手段からの**実際の支払い**が許可されます。ブラウザーセッションの作成にはAnchor APIキーも必要です。このフラグは決済権限への最後の接続であり、権限設定そのものの代わりにはなりません。

AWSの[AgentCore決済ガイド](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html)は基盤となるリソースを説明しています。Payment ManagerはAWSアカウントの決済構成を定義し、IAMロールとオーソライザーを使用します。Payment ConnectorはCoinbase Developer PlatformまたはStripe Privyに接続します。Payment Credential ProviderはAgentCore Identityを通じてプロバイダーの認証情報を保持します。Payment Instrumentは購入に使うウォレットとネットワークを指定します。ブラウザーセッションは支出上限と有効期限を持つAgentCore Payment Sessionに紐づきます。AWSの[クイックスタート](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html)では、決済手段への入金と、支払い前にユーザーがエージェントへ委任署名権限を付与することも求めています。

これらは別々の制御です。IAMはサービスへのアクセスを管理し、ユーザーのウォレット許可は署名を可能にし、決済手段は資金源とネットワークを決め、セッション上限は期間内の支出を制限します。AWSによると、セッション期限切れまたは上限到達後、AgentCoreは追加の支払いを拒否します。可観測性サービスは支払いの試行と結果をCloudWatchに表示します。統合によってプロバイダーの秘密情報はブラウザーやエージェント実行環境の外に保たれますが、運用担当者は作業に適した手段と上限を選ぶ必要があります。

## 自動化フローが止まる場所

Anchorが文書化した失敗時の挙動は具体的です。402チャレンジが不正、互換ネットワークが提示されない、予算切れ、またはAgentCoreによる支払い拒否が起きると、ブラウザーは**元の402応答**を変更せずページに返します。有効化済みのセッションでも402は起こり得るため、自動化はそれを想定すべきです。AWSの[トラブルシューティングガイド](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html)は、IAM権限の不足、委任署名許可の無効化、プロバイダー認証情報の不備、Coinbase Marketplaceサブスクリプションの未登録など、ほかの設定エラーも挙げています。

この`session.x402`スイッチは第三者リソースへの支払いに適用されます。AWSによると、Anchor Browserセッションの料金を支払うものでも、Anchorクレジットに代わるものでもありません。チュートリアルはセッションの支出・時間制限に触れていますが、具体的な上限はAnchorの技術文書を参照しており、本記事では確認できませんでした。第三者への個別リクエスト料金は、販売者のチャレンジと実際の決済によって異なります。請求書や取引を最初から最後まで検証していないため、有効化したセッションの共通価格は示せません。

開発者は、エージェントが課金URLに到達する前に実務上の判断を行います。入金済みで認可された手段を接続し、ブラウザーセッションの予算を設定し、購入を意図する場合にだけx402を有効にします。ブラウザーはナビゲーション経路から決済プロトコルのコードを取り除けますが、支出権限、失敗したリクエスト、販売者が実際に請求した金額の確認に関する運用担当者の責任はなくなりません。この権限の問題は、[AIエージェントの決済手段に関する幅広い検討](https://bigchange.ai/blog/ai-agent-payments-stablecoins-bank-deposits)にも関わります。

## 出典・参考資料

- [AWS、Anchor Browser「Building agents that transact with Anchor Browser and AgentCore payments」](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)（2026年10月13日）。統合チュートリアルは、ブラウザーでのオプトイン、x402チャレンジ、バージョン別の決済ヘッダー、失敗時に元の402を返す挙動を記録しています。想定されたフローの説明であり、課金セッションはテストしていません。
- [AWS「How AgentCore payments works」](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html)（開発者ガイド、2026年10月14日閲覧）。Payment Manager、プロバイダー接続、ID認証情報、決済手段、支出セッション、可観測性を説明しています。ブラウザー専用チュートリアルと併せて読む一般的なサービス設計資料です。
- [AWS「AgentCore payments quick start」](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html)（開発者ガイド、2026年10月14日閲覧）。プロバイダー認証情報、入金済みで認可された決済手段、決済セッションの設定手順を示しています。予算や期間の例は説明用であり、検証済みのAnchor既定値ではありません。
- [AWS「Troubleshooting AgentCore payments」](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html)（開発者ガイド、2026年10月14日閲覧）。支払いを妨げる可能性があるIAM、プロバイダー、ウォレット許可、サブスクリプション、x402ペイロードのエラーを列挙しています。これらのエラーは再現していません。

## Sources

- [AWS Machine Learning Blog, Building agents that transact with Anchor Browser and AgentCore payments](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) — 主要な統合チュートリアルです。session.x402の既定値と実支払いの有効化、ブラウザーとAgentCoreの手順、1回のみの再試行、列挙された失敗時に元の402を変更せず返す挙動を記載しています。これはベンダーが説明する動作であり、BIG CHANGEは課金セッションを実行していません。Anchorクレジット／請求の統合に関する別の主張は、AgentCoreのウォレット入金資料と独立に照合されておらず、一般的な請求モデルとしては繰り返していません。
- [AWS, How AgentCore payments works](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) — サービスの構成と制御に関する継続更新される資料。Payment Manager、コネクター、ID認証情報プロバイダー、手段、セッション上限と期限、ユーザーのウォレット許可、決済フロー、可観測性を定義しています。一般的なx402フローはX-PAYMENTを使い、Anchor専用チュートリアルはx402 v2のPAYMENT-SIGNATUREヘッダーを区別しています。
- [AWS, AgentCore payments quick start](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) — CoinbaseまたはStripe Privyプロバイダーとの接続、入金済みの手段、委任署名の許可、時間制限付き決済セッションなど、設定手順と前提条件を説明しています。例示額・期間はAnchorの既定値や上限ではありません。
- [AWS, Troubleshooting AgentCore payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) — 権限、サブスクリプション、ウォレット許可、認証情報、x402ペイロードの問題を記録しています。サービス側のエラーはAnchor Browserチュートリアルの元の402を返す挙動を補足しますが、ここでは失敗経路をテストしていません。