調査エージェントが有用なデータセットを見つけても、最後の購入段階で止まることがある。AWS と Anchor Browser は、汎用ウォレットをエージェント内に置かずにこの問題へ対応する。10月13日発表の連携では、管理ブラウザーが x402 の支払い要求を認識し、Amazon Bedrock AgentCore Payments で承認を受け、元の要求を一度だけ再送する。
重要なのは資金に関する権限の分離だ。何を要求するかはエージェントが選び、設定された支払い手段とセッション予算で決済できるかは別サービスが判断する。支払い成功は資料の購入価値も調査結果の正確さも証明しない。
支払い要求をブラウザー操作として扱う
Anchor Browser は既に Playwright、Puppeteer、Chrome DevTools Protocol のために認証状態、ページ移動、ネットワークイベント、操作録画を管理する。開発者はセッションへ x402: true を設定する。既定値が false なのは、有効化すると模擬取引ではなく、設定済みの支払い手段から実際の支出を認めるためだ。
AWS の連携説明では、販売者がまず金額、支払い方法、ネットワーク、宛先を含む HTTP 402 Payment Required を返す。AgentCore はデータと支払い手段、残額を確認する。承認後、ウォレット事業者が支払い証明へ署名し、ブラウザーが付加して元の要求を一度再送する。販売者は検証と精算を行い、リソースを返す。
x402 第2版のヘッダーは PAYMENT-SIGNATURE、第1版は X-PAYMENT だ。エージェント自身がヘッダーを作り、ウォレット SDK を動かし、決済再試行を管理する必要はない。ページ移動だけでなく fetch、XMLHttpRequest、ブラウザー内の有料 POST、PUT も対象になる。
不正な形式、未対応ネットワーク、予算切れでは元の 402 が通常の HTTP エラーとして残る。一度だけの再試行は単一要求の無限決済ループを防ぐが、計画エージェントが別々の要求を多数出すことまでは防がない。そこには上位の制御が必要だ。
AWS によれば機能は AWS Marketplace の Anchor Browser で提供され、Generative AI Innovation Center Partner Agent Factory と開発された。導入可能な連携であることと、販売者への普及や本番信頼性が測定済みであることは別である。
支出指示と制御プレーンは異なる
AgentCore の構成は複数の管理リソースへ責任を分ける。Payment Manager が AWS アカウントの境界を定め、PaymentConnector が外部ウォレットへ接続する。PaymentCredentialProvider は AgentCore Identity 経由で事業者の認証情報を扱い、PaymentInstrument はウォレットアドレスを示す。
PaymentSession は支払い手段を特定の操作へ結び付け、最大金額、通貨、有効期限を設定する。上限到達後や期限切れでは拒否される。ウォレット事業者として Coinbase Developer Platform と Stripe Privy が挙げられている。秘密情報と承認キーはエージェントの実行環境ではなく、管理された認証・秘密管理基盤に置く。
これは短期クラウド権限に近い。永久的な口座支配を渡さず、限定した作業を許す。「節約せよ」というプロンプトは同等の制御ではない。実行環境が任意送金へ署名できれば、プロンプトインジェクション、環境変数漏えい、依存関係の侵害、ツール誤用が直接金銭被害につながりやすい。
ただし隔離は免責ではない。侵害されたブラウザーは承認済みセッションの要求を操作できる。IAM 権限が広すぎて事業者の秘密へ直接アクセスできれば、予算と監査の経路を迂回する。ロール、コネクター権限、秘密へのアクセス、保管期間も安全境界の一部だ。
CloudWatch は試行、承認、拒否、精算を記録する。ブラウザーの録画と通信履歴を使えば、費用を発生させた操作やタスクと対応付けられる。複数の購入を行う長時間エージェントでは、孤立した取引記録より有用な証拠になる。
従量アクセスは新しい調達課題を生む
x402 はページ、ファイル、API、MCP ツールの取得を、要求・支払い要求・証明の交換へ変える。任意の仲介サービスが検証と送信を行う。アカウント作成や定期購読の代わりに、個別リソースを購入できる。
実行開始後に未知の有料サービスを発見する動的な調査に適する。市場データ、開示文書分析、企業記録を順に買うことはそれぞれ合理的でも、重複取得や価値の低い追加購入で全予算を使い切る可能性がある。
予算上限は最大損失を限定するだけで、上限内の浪費は防がない。正しい支払い要求は内容の正確さ、新しさ、価格の公平性、必要性を保証しない。販売者の許可リスト、取引別上限、品目ルール、重複決済検知、人の承認条件が必要だ。
購入した証拠には出所、保存、アクセスの管理も要る。許諾済みの結果をキャッシュすれば再購入を減らせるが、再利用は提供者の条件に従う必要がある。取引層は情報管理まで代替しない。
AWS によれば Anchor は第三者の x402 料金をブラウザー料金にまとめ、作業ごとに暗号資産残高を管理する必要を減らす。これは Anchor のサービス契約であり、x402 共通の性質ではない。領収書、税、会計、返金は別途確認が必要だ。オンチェーン精算の取消しや紛争処理はカード決済と異なる場合がある。
決済規格は一つに統一されていない
Stripe と Tempo の Machine Payments Protocol は HTTP 認証要求を使い、販売者向け報告、返金、不正対策、既存残高への精算を重視する。Google の AP2 は60超の参加組織と発表され、利用者、エージェント、販売者、決済事業者の委任関係を扱う。
重なる部分はあるが交換可能ではない。x402 は HTTP リソースや従量 API に直接適し、AP2 は複数手段を使う広い委任購入を扱う。商取引規格には商品一覧、注文、履行、販売者との関係も含まれる。AgentCore の x402 と MPP 対応は、複数規格の共存を認めるものだ。
複数規格への対応は同じ保護を保証しない。ステーブルコインとトークン化カードでは精算、プライバシー、不正、規制上の意味が違う。企業には各方式を技術的に接続するだけでなく、全経路で一貫した方針が必要だ。
管理型設計では Anchor Browser、AgentCore、ウォレット事業者、販売者、精算ネットワークへの依存も増える。AWS 固有の Payment Manager、Identity、IAM、CloudWatch を使うため、移行時に方針と可観測性を再構築する可能性がある。
未提示なのは運用の証拠
AWS の説明は構成を示すが、決済成功率や販売者別遅延の比較ベンチマークはない。Cloudflare、Coinbase の対応や精選 Bazaar の発見機能も、有用なリソースの供給量を証明しない。ディレクトリの大きさより品質が重要だ。
実際の閲覧には認証、リダイレクト、JavaScript、通信障害、精算遅延がある。短いセッションと承認済み有料 API 一つで試し、録画、決済ログ、結果の質、総費用を突き合わせるべきだ。成功件数だけでなく再購入、拒否、遅延、人の介入も評価に入れる。
既知の販売者への少額要求は事前承認に適する一方、新規販売者、異常額、契約上の約束、個人情報、規制対象データでは明示的審査が必要になり得る。その制御はプロンプトの外で実施する。貢献は意図と資金権限の分離であり、作業の改善は購入内容、得られる証拠、障害処理によって決まる。
作業の文脈を整理・保存するための関連資料：技術文書のナレッジベース ; AI支援の週次報告ワークフロー.