AgentCore paymentsとは？x402・MPPの仕組みと料金、SDK 1.26での実装と支出統制【2026年11月】

AgentCore paymentsは、Amazon Bedrock AgentCore上のAIエージェントが、有料のAPI・MCPサーバー・Webコンテンツに実行中のままUSDCで支払うためのAWSのマネージド機能です。2026年5月7日にプレビューとして発表され、2026年8月18日に一般提供（GA）になりました。

この記事は、2026年11月13日時点の公式ドキュメントと、Python SDK（bedrock-agentcore 1.26.0）・AgentCore CLI 1.0.2を手元で動かした結果をもとに書いています。支払いの流れ、ウォレット事業者の選び方、料金、日本から使うときのリージョン、実装手順に加え、10月のSDK更新で入った「署名前ポリシー」を使った支出統制まで扱います。

まとめ：AgentCore paymentsの要点

• 役割：有料リソースが返す「402 Payment Required」を引き取り、予算の確認、ウォレットでの署名、支払い証明の生成までを代行します。対応する方式はx402（v1・v2）とMPP（Machine Payments Protocol）です
• 料金：AWSの追加料金はなく、課金はウォレット事業者の操作料だけです。Coinbase CDPは1操作0.005米ドル（毎月5,000操作まで無料）、Stripe Privyはウォレット作成が無料です
• リージョン：2026年11月13日時点で12リージョン。東京・大阪は対象外で、日本から近いのはシンガポールとシドニーです
• 統制の要：セッションの米ドル建て上限（有効期限15〜480分）、セッション作成と支払いを別のIAMロールに分けること、SDK 1.25.0以降の pre_sign_policy で支払先と金額を署名前に検査すること、の3つを重ねます
• 最近の変更：SDK 1.25.0（2026年10月23日）で決済まわりのセキュリティ強化、AgentCore CLI 1.0（2026年10月28日にGA告知）で agentcore payment コマンドが加わりました

AgentCore paymentsの定義とGA以降の変更

AWSの開発者ガイドは、AgentCore paymentsを、AIエージェントが有料API・MCPサーバー・コンテンツにアクセスするためのマイクロトランザクション決済を可能にするフルマネージドサービスと定義しています。1回の支払いが1ドル未満、ときに1セント未満になる用途では、最低手数料のあるカード決済は採算が合いません。そこでステーブルコインとHTTP 402を使う規格に乗せ、提供元ごとに請求契約を結ぶ手間を省きます。

GAの告知では、厳選したCoinbase x402 BazaarのMCPサーバーをGateway経由で使えることも案内されました。MPPはStripeとTempoが公開した規格で、AgentCore paymentsの中ではx402と並ぶ選択肢です。規格そのものの仕組みはMPP（Machine Payments Protocol）とは？AIエージェントの402決済・x402との違い・Stripe実装【2026年11月】で扱っています。

PaymentManagerから支払いまでの5つのリソース

AgentCore paymentsは5つのリソースを組み合わせて動きます。誰がどれを作るかを先に決めると、後のIAM設計がそのまま決まります。

PaymentManagerはデータプレーンの認証方式として AWS_IAM か CUSTOM_JWT を選びます。Instrumentの種類は EMBEDDED_CRYPTO_WALLET だけで、ネットワークは ETHEREUM と SOLANA の2値です。ETHEREUM にはEthereumメインネットに加えてBaseやArbitrumなどのEVM互換L2が含まれるため、1つのInstrumentで対応するEVMチェーンを払えます。Solanaで払うには別のInstrumentが要ります。

402応答から支払い完了までの流れ

x402で支払う7つの段階

開発者ガイドが示すx402の流れは次のとおりです。予算の確認が署名より前にあるので、上限を超える支払いはウォレットに届く前に止まります。

1. エージェントが有料のツールやエンドポイントを呼ぶ（Gateway経由か直接）
2. 提供元が402を返し、金額・支払先・資産・ネットワークを提示する
3. AgentCore paymentsがセッションの残り予算と照合し、超えるなら拒否する
4. AgentCore Identityからウォレットの認証情報を取り出し、事業者側で署名する
5. エージェントが署名済みの証明をヘッダに付けて再リクエストする
6. 提供元が証明を検証してオンチェーンで決済し、コンテンツを返す
7. AgentCore paymentsが支出台帳を更新する（失敗時は予約分を戻し FAILED を記録）

ProcessPaymentの説明では、応答の PROOF_GENERATED は「署名済みで証明が含まれる」という意味です。オンチェーンの決済は6段目で提供元が行うため、PROOF_GENERATEDだけを見て支払い完了と記録しないでください。経理と突き合わせるなら、提供元の応答（x402 v2なら PAYMENT-RESPONSE ヘッダ）やチェーン上の取引を別に保存しておきます。

MPPとx402で異なるヘッダ

MPPでも流れは同じで、違うのは支払い要求と証明を載せるヘッダです。ProcessPayment APIでは paymentType を CRYPTO_X402 か MPP にして、提供元から受け取った内容を加工せずに渡します。

MPPで使えるのは1回払いの charge とpullモードだけで、methodは evm（正規のUSDCのみ）、tempo、solana の3つです。solana はStripe Privyでしか使えず、ガス代を販売側が負担するチャレンジに限られます。tempo でチャレンジが販売側負担を示していなければ、buyerPaysGasFees=true を明示しないと署名されません。なお、トラブルシューティングには「MPPの処理がこのアカウントで有効になっていない場合はAWSサポートに連絡する」というエラーが載っています。MPPを使う予定なら、検証の初日にこのエラーが出ないかを確かめておくと手戻りがありません。

exactとuptoの使い分けとPermit2のガス代

x402の exact は提示された定額を払う既定のスキームです。GAで加わった upto は上限までの範囲で実際の使用量を払う方式で、x402 v2かつEVMネットワークでしか使えません。upto はPermit2コントラクト経由で決済するため、ウォレットが事前にPermit2へERC-20の許可を与えておく必要があります。permit2AllowanceLimit を指定するとAgentCore paymentsがオンチェーンの approve を先に送りますが、そのガス代はウォレットのネイティブトークン残高から引かれます。approve は加算でなく上書きなので、指定は初回だけにします。

Coinbase CDPとStripe Privyの選び方

接続できるウォレット事業者は2社で、請求の経路、認証情報の登録方法、MPPのsolana対応が違います。

Coinbaseを使うには、AWS Marketplaceの「Coinbase Wallets for AgentCore Payments」の購読が必須です。購読がないと、Connectorの作成もウォレット操作も SubscriptionRequiredException（HTTP 403）で拒否されます。Quick createはOAuthの同意だけで認証情報を自動発行する方式で、返される認可URLは約10分で失効します。請求をAWSに一本化したい企業ならCoinbase、自社アプリのUIにウォレット操作を組み込みたい、またはSolanaのMPPを使いたいならPrivyが合います。

Stripe Privyでは、AgentCore専用のPrivyアプリを作り、App ID・App SecretとP-256鍵ペアを登録します。保管先のシークレットには、AgentCoreのサービスロール以外の GetSecretValue を拒否するリソースポリシーを付けます。他のIAM主体が秘密鍵を取り出せると、予算統制と監査の外でウォレットを操作できてしまうためです。

どちらの事業者でも作成直後のウォレット残高は0 USDCです。エンドユーザーは事業者の画面で、外部ウォレットからのUSDC送金か、メインネットに限りカード（Coinbaseはクレジット・デビットカード、Apple Pay、Google Pay、ACHにも対応）でのUSDC購入によって入金し、エージェントへの署名権限を付与します。テストではCircleのfaucetから、EVM用にBase Sepolia、Solana用にSolana DevnetのテストUSDCを受け取れます。

料金：paymentsの追加料金とウォレット操作料

AgentCoreの料金ページでは、AgentCore payments自体にAWSの追加料金はかかりません。課金されるのは、ウォレットを作る CreateInstrument と、署名する ProcessPayment が発生させる事業者側のウォレット操作で、セッション作成や残高照会は無料です。総費用としては、これに提供元への代金、条件によってはガス代（uptoのapproveや販売側が負担しないMPP）、CloudWatchなど関連サービスの料金が加わります。Coinbase CDPの料金は1操作0.005米ドルで、毎月最初の5,000操作は無料です。

AWSが料金ページに載せている例は、200体のエージェントを動かす金融機関のものです（無料枠を差し引く前の金額）。

ProcessPaymentの回数は「200体×1日15リクエスト×1リクエスト3回の支払い×30日」です。提供元に払う代金そのものは操作料と別に、ウォレットのUSDC残高から出ていきます。料金ページの例は代金を「270,000回×平均2.50ドル÷3」と書きながら675,000ドルと示しており、式どおりなら225,000ドルです（2026年11月13日時点でも未修正）。稟議には例を転用せず、自社の呼び出し回数で計算し直してください。

単価が安いほど操作料の比率は上がります。0.01ドルのAPIなら1回ごとに代金の半分にあたる0.005ドルがかかるため、こうしたAPIを大量に呼ぶ用途では、提供元との月額契約のほうが安くなる場合があります。

提供リージョンと東京から使うときの構成

AgentCoreのリージョン対応表（2026年11月13日時点）で、AgentCore paymentsが使えるのは次の12リージョンです。10月から増減はありません。

• 米国：バージニア北部、オハイオ、オレゴン
• 欧州：フランクフルト、アイルランド、ロンドン、ミラノ、パリ、スペイン、ストックホルム
• アジアパシフィック：シンガポール、シドニー

東京リージョンはAgentCore RuntimeやGatewayには対応していますが、paymentsは対象外です。エージェント本体を東京で動かし、payments APIだけシンガポールかシドニーを呼ぶ構成は取れます。ただし支払い履歴やセッション情報は東京の外で処理されるので、データの所在に社内規程があるなら先に確認してください。ManagerやCredentialProviderを作ったリージョンと呼び出すリージョンが揃っていないと「CredentialProvider not found」になります。

Python SDKとCLIで実装する手順

Python SDKの導入要件とインストール

Python 3.10以上とAWSの認証情報を用意します。Strands Agentsと組み合わせるならextrasを付けます（LangGraph向けは bedrock-agentcore[langgraph]）。後述の署名前ポリシーには1.25.0以上が必要です。次の例は、この記事で検証した1.26.0に固定しています。

pip install boto3 'bedrock-agentcore[strands-agents]==1.26.0' strands-agents

Coinbaseを手動登録で使う場合は、CDPポータルで「Delegated signing」を有効にしておきます。忘れると支払いの段階で「Delegated signing is not enabled for your Coinbase project」が返ります。

Manager・Connector・Instrument・Sessionの作成

管理者がManagerとConnectorを作り、アプリのバックエンドがユーザーごとにInstrumentとSessionを作ります。開発者ガイドのクイックスタートに沿った例です（Coinbase Quick createの場合）。実運用では3つの段を別の認証情報で実行します。

import time
from bedrock_agentcore.payments.client import PaymentClient
from bedrock_agentcore.payments import PaymentManager

REGION = "us-west-2"

# 管理者: Manager と Connector（Quick create は認証情報を渡さない）
pc = PaymentClient(region_name=REGION)
mgr = pc.create_payment_manager(
    name="researchAgentPayments",
    authorizer_type="AWS_IAM",
    role_arn="arn:aws:iam::111122223333:role/AgentCorePaymentsResourceRetrievalRole",
    wait_for_ready=True,
)
conn = pc.create_payment_connector(
    payment_manager_id=mgr["paymentManagerId"],
    name="coinbase",
    connector_type="CoinbaseCDP",
    credential_provider_configurations=[],
    provision_mode="QUICK_CREATE",
)
print(conn["authorizationUrl"])  # 約10分以内にブラウザで開いて承認する
input("Coinbaseで承認したらEnter: ")
for _ in range(120):
    state = pc.get_payment_connector(
        payment_manager_id=mgr["paymentManagerId"],
        payment_connector_id=conn["paymentConnectorId"],
    )
    if state["status"] == "READY":
        break
    if state["status"] not in ("PENDING_AUTHENTICATION", "PROVISIONING", "CREATING"):
        raise RuntimeError(f"Connector setup failed: {state['status']}")
    time.sleep(5)
else:
    raise TimeoutError("Connector did not become READY")

# バックエンド: ユーザーごとのウォレットとセッション
pm = PaymentManager(payment_manager_arn=mgr["paymentManagerArn"], region_name=REGION)
inst = pm.create_payment_instrument(
    user_id="user-123",
    payment_connector_id=conn["paymentConnectorId"],
    payment_instrument_type="EMBEDDED_CRYPTO_WALLET",
    payment_instrument_details={"embeddedCryptoWallet": {
        "network": "ETHEREUM",
        "linkedAccounts": [{"email": {"emailAddress": "[email protected]"}}],
    }},
)
sess = pm.create_payment_session(
    user_id="user-123",
    limits={"maxSpendAmount": {"value": "5.00", "currency": "USD"}},
    expiry_time_in_minutes=60,  # 15〜480分
)

Instrumentを作ったら、レスポンスの paymentInstrumentDetails.redirectUrl でユーザーをWalletHubへ案内し、入金と署名権限の付与を済ませてもらいます。ここが終わるまで支払いは通りません。

402応答からの支払い証明ヘッダ生成

独自のHTTPクライアントで有料APIを呼ぶ場合は、402応答を generate_payment_header に渡すと、方式の判別から署名済みヘッダの組み立てまでSDKが処理します。

import uuid
import httpx

url = "https://example-x402-merchant.com/paid-api"
r = httpx.get(url)
if r.status_code == 402:
    header = pm.generate_payment_header(
        user_id="user-123",
        payment_instrument_id=inst["paymentInstrumentId"],
        payment_session_id=sess["paymentSessionId"],
        payment_required_request={
            "statusCode": 402,
            "headers": dict(r.headers),
            "body": r.json() if "json" in r.headers.get("content-type", "") else {},
        },
        client_token=str(uuid.uuid4()),
    )
    r = httpx.get(url, headers=header)

Strands Agentsなら AgentCorePaymentsPlugin、LangGraphなら AgentCorePaymentsMiddleware をエージェントに渡すと、ツール呼び出しで受けた402をこの処理で自動的に払い直します。Strands Agents自体の使い方はStrands Agentsとは？読み方・意味とPython SDKの使い方【1.62対応・2026年10月】で解説しています。

AgentCore CLI 1.0による残高・設定の確認

2026年10月28日にGAが告知されたAgentCore CLI 1.0（npmの @aws/agentcore、11月13日時点の最新は1.0.2）には、プロジェクトを作らずに既存リソースを扱う agentcore payment コマンド群があります。1.0.2で --help を確かめると、中身は参照と運用に絞られていました。

agentcore payment manager    get | list
agentcore payment connector  get | list | rotate-credentials
agentcore payment session    get | list
agentcore payment instrument get | list | balance

# 残高の照会（--chain は BASE | BASE_SEPOLIA | ETHEREUM | SOLANA | SOLANA_DEVNET）
agentcore payment instrument balance --manager-id <ID> --connector-id <ID> \
  --instrument-id <ID> --user-id user-123 --chain BASE_SEPOLIA

セッションを作るコマンドはありません。リソースの作成はプロジェクトの agentcore add payment-manager と agentcore deploy が担い、--default-spend-limit の既定値は10.00ドルです。CLI 0.19で案内されていた agentcore invoke の --auto-session は1.0.2のヘルプに無く、クイックスタートはセッションIDとInstrument IDをRuntimeへのリクエストヘッダで渡す方式に変わっています（Runtime側でヘッダの許可リストに2つを加える）。CLIとRuntimeのデプロイ全体はAgentCore APIの使い方：SDK・CLI 1.0・InvokeAgentRuntimeでエージェントを本番に載せる手順【2026年10月】を参照してください。

SDK 1.26.0で確かめたヘッダ名とネットワーク選択

開発者ガイドの支払いフローの説明は、x402の再リクエストヘッダを一律に X-PAYMENT と書いています。一方、SDKのソースはx402 v2で PAYMENT-SIGNATURE を返す実装です。そこでProcessPaymentとInstrumentのネットワーク取得だけをモックに差し替え、AWSに接続せずに generate_payment_header の挙動を確かめました。条件はPython 3.12とbedrock-agentcore 1.26.0で、実際の署名と決済は対象外です。1.24.1で同じスクリプトを動かした結果と一致しました。

# accepts に Solana Devnet / Ethereum Sepolia / Base Sepolia の順で並べて呼んだ結果
v2 header name: ['PAYMENT-SIGNATURE']
v2 selected network: eip155:84532
v1 header name: ['X-PAYMENT']
solana-only -> PaymentError: Accept Selection: No matching accept ... | ProcessPayment calls added: 0
MPP challenges: ['c-sol', 'c-evm'] -> ETHEREUM selects: c-evm
MPP header name: ['Authorization']

• ヘッダ名をハードコードしない：v2の提供元に X-PAYMENT で送ると受け付けられない可能性があります。SDKが返した辞書をそのままヘッダに使います
• 選ばれるネットワークは提示順でなくSDKの優先順：Ethereum Sepoliaを先に提示しても、既定の優先リストでBase Sepoliaが上にあるためBaseが選ばれました。既定リストの先頭はSolanaメインネットで、EVMではBaseがEthereumより先です。優先順は network_preferences で変えられますが、許可リストではありません。Base Sepoliaだけを指定し、Ethereum Sepoliaしか提示しない402を渡すと、Ethereum Sepoliaが選ばれました。使うチェーンを限定したいなら、署名前ポリシーでネットワークも検査します
• 払えない402は予算を消費しない：Instrumentのネットワークに合う選択肢がない場合、SDKはProcessPaymentを呼ぶ前に PaymentError を出しました。MPPとx402を両方提示された場合はMPPを優先し、MPPの選択段階で失敗したときだけx402に切り替わります

署名前ポリシーによる支払先・金額の制限（SDK 1.25.0以降）

セッションの上限が守るのは「合計いくらまで」です。上限の範囲内なら、プロンプトインジェクションを受けたエージェントが攻撃者の指定した支払先へ払うことまでは防げません。2026年10月23日公開のSDK 1.25.0は、この穴に向けた変更をPR #706として取り込みました。11月13日時点の開発者ガイドにはまだ載っていないため、SDKのソースと実行で確かめた内容を書きます。

pre_sign_policy は、署名の直前に402の内容を受け取る同期関数です。True を返したときだけ署名に進み、それ以外はすべて止まります。1.26.0で確かめた結果は次のとおりです。

async def            -> TypeError（構築時に拒否）
return True          -> allowed
return 1             -> blocked (pre_sign_policy did not return True ...)
return {'ok':True}   -> blocked
return None          -> blocked
raise KeyError       -> blocked (pre_sign_policy raised KeyError.)
configured u1, tool says u2 -> u1

非同期関数を構築時に拒否するのは、待たれないコルーチンが真と評価されて署名が通ってしまうのを防ぐためです。最後の行は、エージェントがツール引数で別の user_id を渡しても、設定済みのIDが使われることを示しています（JWT認証で user_id を設定しない場合は、サーバー側がトークンから利用者を決めます）。

支払先の許可リストを作るときに気を付けたいのは、支払先と金額の置き場所が方式ごとに違う点です。x402 v1は本文の accepts、v2は Payment-Required ヘッダの中のbase64、MPPは WWW-Authenticate の request の中のbase64urlにあります。本文の accepts だけを見る関数では、v1は通る一方でv2とMPPはすべて止まりました（実行ログで確認）。3方式を読む例です。

import base64, json, re
from bedrock_agentcore.payments.integrations.config import AgentCorePaymentsPluginConfig

ALLOWED = {"0x1111111111111111111111111111111111111111"}  # 許可する支払先
MAX_UNITS = 100000  # 0.10 USDC（小数6桁の最小単位）

def _b64(s):  # v2は標準base64、MPPはbase64urlの両方を受ける
    s = s.replace("-", "+").replace("_", "/")
    return json.loads(base64.b64decode(s + "=" * (-len(s) % 4)))

def offers(req):  # 3形式を全部集める（x402とMPPが混在した402も全候補を検査）
    h = {k.lower(): v for k, v in (req.get("headers") or {}).items()}
    body = req.get("body")    # x402 v1は文字列でも辞書でも来る
    body = json.loads(body) if isinstance(body, str) and body else body
    accepts = []
    if "payment-required" in h:   # x402 v2
        accepts += _b64(h["payment-required"])["accepts"]
    if isinstance(body, dict):    # x402 v1
        accepts += body.get("accepts", [])
    # uptoは上限がmaxAmountRequiredに入る
    out = [(a["payTo"], int(a.get("maxAmountRequired") or a["amount"])) for a in accepts]
    for m in re.findall(r'request="([^"]+)"', h.get("www-authenticate", "")):  # MPP
        r = _b64(m)
        out.append((r.get("recipient"), int(r["amount"])))
    return out

def policy(req):
    o = offers(req)  # 提示された選択肢がすべて条件内のときだけ通す
    return bool(o) and all(p in ALLOWED and amt <= MAX_UNITS for p, amt in o)

PAYMENT_MANAGER_ARN = mgr["paymentManagerArn"]
INSTRUMENT_ID = inst["paymentInstrumentId"]
SESSION_ID = sess["paymentSessionId"]

config = AgentCorePaymentsPluginConfig(
    payment_manager_arn=PAYMENT_MANAGER_ARN,
    user_id="user-123",
    payment_instrument_id=INSTRUMENT_ID,
    payment_session_id=SESSION_ID,
    pre_sign_policy=policy,
)

この関数で4形式（v1の辞書と文字列、v2、MPP）を試すと、許可した支払先への0.01 USDCは通り、別の支払先と0.50 USDCはどれも止まりました。SDKはx402とMPPを両方提示されるとMPPを優先するため、片方の方式だけを検査すると、許可先のx402を見て許可外のMPPに署名する抜け道が残ります。上の例は全候補を集めるので、許可先0.01 USDCのx402と許可外0.50 USDCのMPPが混ざった応答も止まりました。読み取りで例外が出ても止まる側に倒れるため、未知の形式は「払わない」になります。

LangGraphを使うなら allow_unmarked_402_detection=False も検討します。既定の True では、統合が用意した支払い用ツール以外の出力からも402らしい内容を推定して支払いに進みます。SDKの設定の説明はこれをCWE-863（認可の誤り）に当たるとし、Falseにするか pre_sign_policy を併用するよう書いています。取得したWebページの中身に支払い要求を仕込まれる経路を塞ぐ設定です。

支出統制の設計：セッション上限とIAMの分離

PaymentSessionの説明は、セッションを「支出の予算を任意で強制する、期限付きの支払いの文脈」としています。limits を省くと効くのは期限だけなので、本番では必ず maxSpendAmount を入れます。通貨はUSDだけです。上限はエージェントのプロンプトでなくサービス側で判定されるため、エージェントが指示を誤解しても上限を超えては払えません。

ただし、この上限は「エージェントが新しいセッションを作れない」ことが前提です。AWSは管理者・エージェント開発者・支払い実行・サービスロールにMarketplace購読を加えた5つの役割でIAMを分ける設計を示しています。

• ManagementRole（Instrument・Sessionの管理）には ProcessPayment の明示的なDenyを入れる
• ProcessPaymentRole（支払い実行）には ProcessPayment とInstrument・Sessionの読み取りだけを許可する
• CreatePaymentSession などのSession書き込み権限と ProcessPayment を同じロールに入れない

この点で注意したいのが、LangGraph統合の auto_session=True です。1.26.0のソースでは、最初の402を受けたときにミドルウェア自身が create_payment_session を呼びます（既定は予算1.00ドル・60分）。開発者ガイドの例でも使われていますが、エージェントの実行ロールにセッション作成の権限が要るため、上の分離が成り立ちません。試作では便利でも、本番ではバックエンドで作ったセッションIDを渡す構成にします。

監視にはCloudWatchのメトリクス OperationSuccess・OperationFailure・SpendAmount・Throttles などと、X-Rayのスパンを使います。ProcessPaymentのスパンには残り予算（aws.payments.session_remaining_budget）や支払先アドレス（aws.payments.merchant）が付くので、許可リストに無い支払先が出たら通知する監視を組めます。エージェントで支払いを受け付ける社内システムまで含めた設計は、AIエージェント開発の支援でも相談を受けています。

採用を見送るべき場面と、よく出るエラー

AgentCore paymentsが向くのは、支払先がx402かMPPに対応し、1回数セント〜数ドルの支払いを多数こなす用途です。次の条件に当てはまるなら、現時点では見送るか別の手段と併用するのが妥当です。

• 支払先が既存のAPIキー＋月額請求しか用意していない：402で支払いを要求しない相手には使えません
• 経理が円建ての請求書払いしか扱えない：代金はUSDCでウォレットから出ていくため、ステーブルコインの保有と会計処理を社内で認められることが前提です
• 処理を国内リージョンに閉じる必要がある：東京・大阪が対象外のため要件を満たせません
• 人の承認を毎回挟みたい：セッションの範囲内の支払いは、1件ごとの承認なしに署名されます。毎回承認させるなら、承認を待つツールを自前で作り、承認後に支払いへ進む設計が要ります

導入時に出やすいエラーと原因は次のとおりです。

よくある質問

AgentCore paymentsの利用にAWSの料金はかかりますか？

かかりません。課金はウォレット事業者の操作料だけで、Coinbase CDPは1操作0.005米ドル（毎月5,000操作まで無料）です。提供元に払う代金は別にUSDC残高から出ていきます。

AgentCore paymentsは東京リージョンで使えますか？

2026年11月13日時点では使えません。アジアパシフィックの対応はシンガポールとシドニーで、エージェントを東京で動かしpayments APIだけ対応リージョンを呼ぶ構成は取れます。

x402とMPPのどちらに対応していますか？

両方です。x402はv1とv2（exactとupto）、MPPはv1のcharge intentです。SDKの generate_payment_header は402応答から方式を自動で判別し、両方を提示された場合はMPPを優先します。

AIエージェントが勝手に高額を払うのをどう防ぎますか？

セッションに maxSpendAmount を入れ、セッション作成と支払いの権限を別のIAMロールに分けたうえで、SDK 1.25.0以降の pre_sign_policy で支払先と1回あたりの金額を署名前に検査します。合計額・権限・支払先の3段で止める形です。

AP2やACPなど他のAIエージェント決済の規格とはどう違いますか？

AgentCore paymentsは規格ではなく、x402やMPPで支払いを実行するAWSのマネージド機能です。AP2は利用者の承認を署名で残す規格、ACPやUCPは商品のチェックアウトを扱う規格で、担う段が違います。規格どうしの比較はUCPとは？Universal Commerce Protocolの仕組みと試し方、ACP・AP2との違い【v2026-08-25対応】で整理しています。

関連記事

• MPP（Machine Payments Protocol）とは？AIエージェントの402決済・x402との違い・Stripe実装【2026年11月】
• AP2（Agent Payments Protocol）とは？v0.2のマンデートとx402・ACPとの違い
• EIP-3009（ERC-3009）とは？transferWithAuthorizationの仕組みと署名実装・チェーン別対応表【2026年11月】
• Circle Agent Stackとは？Agent Wallets・Nanopaymentsの仕組みとCLIでの使い方【CLI 1.2.0対応】
• AgentCore APIの使い方：SDK・CLI 1.0・InvokeAgentRuntimeでエージェントを本番に載せる手順【2026年10月】