AgentCore paymentsの支出上限——予算を設定する権限と使う権限を分ける

AIエージェントに「有料のページやAPIにお金を払ってよい」と任せるとき、考えることは大きく二つあります。

一つは、設定した額を超えて支払わせないための仕組みです。

もう一つは、何の業務に、どの相手へ、いくらまでの支出を認めるかという判断です。

Amazon Web Services（AWS）は2026年10月13日、機械学習ブログで、クラウド型のブラウザ自動化サービス Anchor Browser と、AgentCore payments を組み合わせてエージェントに支払いをさせる構成を紹介しました。

本稿はこの記事と、関連する公式ドキュメントを手がかりに、この二つをどう分けて設計するかを考えます。

扱うのは、HTTP 402 を利用した少額の自動支払いです。

AgentCore payments はステーブルコイン（米ドルなどに価値を連動させた暗号資産）による支払いを扱いますが、暗号資産の制度や会計上の扱いは本稿の対象外です。

AWSが公表した内容：支出上限はセッション単位で、エージェントの外で適用される

AWSの説明によれば、AgentCore payments は、x402 などのプロトコルで保護されたAPI・MCPサーバー・Webコンテンツに対して、エージェントが支払えるようにするマネージドサービスです。

x402 は、サーバーが HTTP 402（支払いが必要）を返し、クライアントが支払いの証明を付けて同じリクエストを再送する仕組みです。

ブログが示す流れは、おおむね次のとおりです。

1. x402 を有効にしたブラウザセッションが始まると、Anchor Browser が AgentCore payments に PaymentSession を作る。
2. ブラウザが HTTP 402 の応答を受け取り、要求された支払い方法をセッションに紐づく支払い手段と照合する。
3. AgentCore payments が金額をセッションの支出上限と照らし、範囲内なら支払いの証明に署名する。
4. ブラウザが証明を付けて元のリクエストを一度再送し、販売側が検証・決済する。

PaymentSession は、有効期間を持つ支払い用の単位で、支出上限も設定できます。

ここでいう署名は、ウォレットから支払うことを認める暗号学的な証明を作る処理を指します。

AWSは、支出上限をインフラ層で適用すると説明しています。

署名は AgentCore payments の内部で行われ、鍵情報はブラウザにもエージェントの実行環境にも渡らないとされています。

AgentCore payments のセキュリティガイドも、上限と有効期間はインフラ層で適用されるため、プロンプトインジェクションやモデルの出力の揺らぎでは上書きできないとしています。

公開されている制約：Anchorの組み込み機能と、AgentCoreを直接使う場合

ブログ本文には具体的な上限額や期間は書かれていませんが、関連する公式ドキュメントには記載があります。

2026年10月14日に確認した Anchor Browser のガイド「Automatic x402 Payments」では、この機能はプレビューとされ、1ブラウザセッションあたりの x402 の支出上限は 0.01 米ドル、支払いの許可はブラウザが開いていても480分で失効すると説明されています。

同じガイドは、x402 の設定は第三者のリソースへの支払いに使うもので、ブラウザセッション自体の料金は支払わないとしています。

一方、AgentCore payments を直接使う場合は、セッションの有効期間を指定し、支出上限も設定できます。

API リファレンスでは、有効期間は15分から480分の範囲で必須、支出上限の指定は任意とされています。

Anchor のガイドからは、利用者が上限額や期限を変更できるかは確認できませんでした。

この 0.01 米ドルという上限は Anchor の機能についての記載であり、AgentCore payments 全体の上限ではありません。

また、支出上限の指定が任意である以上、上限を付けずにセッションを作る構成も API 上はありえます。

自社の構成で、誰がどの条件を設定・変更できるかを、導入前に確かめておくことになります。

予算内で支払えることと、業務上必要な支出であることは別

AgentCore payments が支払い前に確かめるのは、上限だけではありません。

トラブルシューティングの資料によれば、x402 の支払い要求について、形式、ネットワーク、通貨、金額、受取先アドレスの形式などを署名前に検証し、形式に誤りがある支払い要求や未対応の要求は、予算を消費せずに拒否します。

ただし、受取先が「会社として支払いを認めた相手か」は、これとは別の話です。

AgentCore payments のセキュリティガイドは、受取先ウォレットを示す payTo の制限をサーバー側では強制しないため、アプリケーションが支払いを実行する前に検証する必要があると明記しています。

事前に確認した受取先の許可リストを持つこと、モデルに受取先アドレスを作らせないこと、ウォレット事業者側のポリシーで送金先を制限することなどが挙げられています。

同ガイドは、セッションの上限が制限するのは「いくら払えるか」であって「誰に払えるか」ではない、とも書いています。

同ガイドは、AgentCore Gateway を使い、ツールの呼び出しをポリシーで制限する方法も紹介しています。

どのツールを使えるかという制限と、いくらまで・いつまで支払えるかという制限を組み合わせる考え方です。

支出上限や支払い要求の形式が適切であっても、それだけでは、その購入が業務に必要か、同じ内容を重複して購入していないかまでは分かりません。

MIFは、支出上限とあわせて、支払いを認める目的と対象を明確にすることを重視しています。

予算を設定する権限と、予算を使う権限を分ける

AgentCore payments の IAM（誰にどの操作を許すかを管理する仕組み）の資料は、支払い手段やセッションを管理するロール（許可する操作をまとめた役割）と、支払いを実行するロールを分ける構成を示しています。

資料の設定例では、管理側のロールで支払いの実行を明示的に拒否しています。

そのうえで、セッションを作る権限と支払いを実行する権限を同じロールに与えないよう注意を促しています。

理由として挙げられているのは、支払い側が新しいセッションを作れると、より大きな予算のセッションを新たに作り、意図した支出制限を回避できてしまうことです。

支払う側が新しいセッションを作って支出枠を増やせる設定では、当初の上限だけでは支出を制限できません。

MIFは、支出枠を設定する処理と、その枠を使って支払う処理を分けることを重視しています。

導入時には、支払いを行うエージェントや処理が、自分で予算を増やしたり、別の支出枠を作ったりできないかを確認します。

予算の配分は、承認済みの業務ルールに従って、管理側のプログラムが行う形でも構いません。

支払いを実行する側が、承認された支出枠を独自に変更・追加できないようにします。

秘密情報の扱いも同じ観点で確認します。

前提条件の資料は、Stripe（Privy）の秘密情報に AgentCore payments のサービス用ロール以外がアクセスできると、AgentCore の予算管理や監査の外でウォレットを操作されうると注意しています。

セッションの上限と、業務全体の支出は別に管理する

AgentCore payments のセッションの上限は、そのセッションで使える最大額です。

複数のセッションにまたがる合計額とは、区別して考える必要があります。

仮に1セッションの上限を10ドルとし、100のセッションを認めれば、各セッションが上限を守っていても合計は最大1,000ドルになります。

業務全体や日次・月次の支出も管理する場合は、セッションをまたぐ合計額を確認します。

そのため、どの単位で支出を管理するかを先に決めておきます。

• 1回の支払い
• 1セッション
• 1つの業務や依頼
• 日次・月次の合計

また、支払いが拒否されても、ブラウザやモデルが動き続ければ、支払いとは別の利用料金が発生する可能性があります。

支払い額の上限と、再試行回数・実行時間の制限は、分けて設定しておくことを勧めます。

支払いが拒否された後の処理を決める

Anchor のガイドによれば、販売側の応答が不正な場合、対応するネットワークがない場合、予算を使い切った場合、AgentCore が支払いを拒否した場合には、元の 402 応答がページへそのまま返されます。

AgentCore payments の資料でも、セッションの期限切れや上限到達で拒否されるのは、そのセッションでの以後の支払い要求だとされています。

つまり、まず止まるのはそのセッションでの支払いであり、エージェントの作業全体が自動的に止まるわけではありません。

そこから仕事を止めるか、別の情報源を使うか、人に確認するかは、呼び出し側で決めて組み込む必要があります。

ページに返る 402 応答だけでは、予算不足、期限切れ、支払い方法の不一致などの原因を区別できるとは限りません。

AgentCore payments には、セッションID、支払額、残りの予算、受取先などを含む記録を CloudWatch に出す仕組みがありますが、利用するにはログやトレースの配信を設定する必要があります。

支払いサービス側の状態や記録と対応づけたうえで、次の点を決めておきます。

• 再試行を止める条件と、回数・時間の上限
• 人に通知する条件と、通知先
• 情報の取得に失敗した場合に、成功として次の工程へ進めない方法

ブログが説明する「一度だけ再送する」は、402 応答に対するブラウザ側の支払い処理の話です。

上位のエージェントが同じ仕事を何度繰り返せるかまで、一回に制限されるという意味ではありません。

また、AgentCore payments の支払い実行 API が返す PROOF_GENERATED は、署名済みの支払い証明が生成されたことを示します。

決済やコンテンツの取得が完了したかは、別に確認します。

再実行する前に、証明を生成した段階なのか、決済が済んだのか、必要な内容を取得できたのかを確認します。

セキュリティガイドも、再試行で支払いが重複しない仕組みを設け、無制限に再試行しないよう求めています。

持ち帰り：予算を渡す前に決める項目（一例）

以下はMIFが提案する確認項目です。

利用する製品の制約と、自社の業務・承認ルールに合わせて具体化してください。

決める項目	確認すること	設定・確認先の例
支出の目的と上限	何の業務に使うか。1回・1セッション・業務全体で、いくらまで認めるか	社内の予算承認、利用サービスの制約、支出管理
有効期間と追加枠	いつまで使えるか。延長や新しいセッションの作成を誰が認めるか	セッション設定、管理側の処理、承認記録
支払先	許可するサイト・APIと受取先を、どこで確認・制限するか	アプリ側の検証、接続先・ウォレットのポリシー
資金元と費用範囲	どこから支払い、誰へ請求されるか。第三者への支払いと実行基盤の費用をどう管理するか	利用契約、ウォレット接続、経理記録
権限の分担	予算を設定する側と支払いを実行する側を、どう分けるか	IAMなどの権限設定、社内の役割分担
支払い失敗後の処理	再試行をいつ止め、誰へ知らせるか。結果が不明な支払いをどう確認するか	エラー処理、実行時間・回数の制限、業務手順
記録と見直し	支払先、金額、結果、セッション、業務上の依頼をどう追跡し、誰が見直すか	支払いの記録、承認記録、監視・見直し手順

上限額は、業務の目的と必要な支出に照らして決めます。

少額で失っても影響が小さいことと、その支出を会社として認めてよいことは別だからです。

AgentCore payments のセキュリティガイドも、上限はその仕事に必要な最小限にし、有効期間を短くし、控えめな予算から始めて信頼性を確認しながら引き上げるよう勧めています。

まとめ——予算の決定と、支払いの実行を分ける

AWSが紹介した構成は、セッションごとの支出上限を、エージェントの実行環境とは別の仕組みで適用し、鍵情報をエージェントに渡さない設計の具体例です。

そのうえで、支出の目的と許可範囲を先に定め、予算を設定する処理と、その予算を使う処理を分けることが重要だと私たちは考えます。

確認するのは、一つのセッションの上限だけではありません。

複数のセッションを通じた支出、許可する相手、追加の予算を認める条件も、自社の運用に合わせて整理します。

支払いが拒否された場合や結果が不明な場合には、再試行の条件、通知先、業務を保留する方法を決めます。

予算の配分や支払い条件の適用をシステムに任せる場合も、何を許可し、誰がその条件を承認・変更するかは、会社として明確にしておきます。

採用した条件が実際の設定へ反映されていることと、支払いの状況を記録から確認できることを確かめてから、利用を始めることを勧めます。

情報確認について

本記事は2026年10月14日確認時点で、次の公開情報を主な参照元として作成しています。

• Amazon Web Services の AWS Machine Learning Blog「Building agents that transact with Anchor Browser and AgentCore payments」（2026年10月13日付）
• Anchor Browser のドキュメント「Automatic x402 Payments」
• AWS の Amazon Bedrock AgentCore 開発者ガイド「Create a payment session」「IAM roles for AgentCore payments」「Security in Amazon Bedrock AgentCore payments」「Troubleshooting AgentCore payments」「Observability with Amazon CloudWatch」、および API リファレンス「CreatePaymentSession」「ProcessPayment」

製品に関する記述はAWSとAnchor Browserの公表資料に基づき、MIFが実際の動作や制御の有効性を独立に検証したものではありません。

予算の管理方法、権限分担、確認項目の表は、公開資料をもとにしたMIFの整理・提案です。

Anchor の自動支払い機能はプレビューとされており、上限額・有効期間・提供状況・仕様・料金・対応するウォレット事業者は今後変更される可能性があります。

導入を検討される際は、最新の公式情報をご確認ください。