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

大きな変化

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

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

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

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

開発者が有効にする設定

ブラウザーのスイッチは明示的です。チュートリアルのセッションリクエストでは、session.x402の既定値はfalseです。trueに設定すると、構成済みの手段からの実際の支払いが許可されます。ブラウザーセッションの作成にはAnchor APIキーも必要です。このフラグは決済権限への最後の接続であり、権限設定そのものの代わりにはなりません。

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

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

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

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

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

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

出典・参考資料

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