今日は前日Previewがアナウンスされた Amazon Bedrock AgentCore payments を試していきます。
Amazon Bedrock AgentCore payments とは？
従来のAIエージェントは、有料のAPIやデータサービスにアクセスする際に大きな課題を抱えていました。クレジットカードには最低手数料があるため数セント以下のマイクロ決済が経済的に成立せず、外部サービスごとに個別の請求関係を構築するコストが高く、エージェントが際限なく支出しないようにするガバナンスの仕組みを一から作らなければならない、といった様々な問題です。
AgentCore Paymentsはこれらの課題をまとめて解決するAWSのフルマネージドサービスです。一言で表すなら、「AIエージェントが自律的にお金を払いながら外部サービスを使えるようにする、予算管理付きのマイクロ決済基盤」 です。
x402プロトコルとは
AgentCore Paymentsの核心となる技術が x402プロトコル です。HTTPのステータスコード 402 Payment Required を活用したオープン規格で、以下のような流れで動作します。
- エージェントが有料エンドポイントにリクエストを送る
- サーバーが
402を返し、「いくら・どこに・何のトークンで払え」という支払い情報を返す{ "scheme": "exact", "network": "eip155:84532", "amount": "100000", "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e", "payTo": "0x99935f281d3ED1E804bF1413b76E0B03e1fed4F9", "maxTimeoutSeconds": 300, "extra": {"name": "USDC", "version": "2"} } - AgentCore Paymentsがウォレットから署名付きの支払い証明を生成する
- エージェントが支払い証明を付けて再リクエストする
- サーバーが検証してデータを返す
# 1回目のリクエスト（支払いなし） GET https://drvd12nxpcyd5.cloudfront.net/market-recap # サーバーからの402レスポンス HTTP/1.1 402 Payment Required X-Payment-Required: {"scheme":"exact","network":"eip155:84532","amount":"100000",...} # AgentCoreが署名付き支払い証明を生成 # 2回目のリクエスト（同じURL、支払い証明付き） GET https://drvd12nxpcyd5.cloudfront.net/market-recap X-Payment: {"version":"2","payload":{"署名済みトランザクション..."}} # サーバーが証明を検証してデータを返す HTTP/1.1 200 OK {"market-recap": ...}この一連の流れが人間の介入なしに自動で完結します。
主要なコンポーネント
AgentCore Paymentsは以下の4つの概念で構成されています。
Payment Manager はすべての支払いリソースを束ねるトップレベルのリソースです。IAMによるアクセス制御や、後述のConnectorを管理します。
Payment Connector は外部の決済プロバイダーとの接続設定です。現在はCoinbase CDPとStripe（Privy）の2つに対応しており、ウォレット操作のための認証情報をAWS Secrets Managerに安全に保管します。
Payment Instrument はエージェントが実際に使うクリプトウォレットです。EthereumまたはSolanaネットワーク上のウォレットアドレスが払い出され、ユーザーがここに資金をチャージします。
Payment Session はエージェントの支出を制御するセッションです。maxSpendAmount（上限金額）と有効期限を設定することで、エージェントが使いすぎないようにガードをかけられます。
セキュリティ設計
AgentCore Paymentsは4つのIAMロールを分離することでセキュリティを担保しています。Payment Managerを作る管理者、Payment SessionやInstrumentを管理する開発者、実際に支払いを実行するエージェント、そしてAWSサービスが認証情報を取得するためのサービスロールをそれぞれ独立させています。
これにより「セッションの予算を無制限に設定しながら支払いも実行する」といった操作を一つの権限では行えないようになっており、エージェントの暴走を防ぐ設計になっています。
さっそくやってみる
現在まだ東京リージョンでは機能が提供されていませんので、バージニアを使います。
初期設定
pip install boto3 --break-system-packages
pip install "bedrock-agentcore[strands-agents]" --break-system-packages
pip install strands-agents-tools --break-system-packages次に aws sts get-caller-identity を実行してクレデンシャルを確認しておきます。このクレデンシャルはIAMロールの作成とBedrockAgentCoreの作成を行いますので必要な権限を付与しておきます。
{
"UserId": "AIDA5LIXG4WVI3YHNJ4WX",
"Account": "917561075114",
"Arn": "arn:aws:iam::917561075114:user/payment"
}AWSのアカウントIDを環境変数にセットしておきます。
export ACCOUNT_ID="917561075114"IAMロールの作成
AgentCore Paymentsが必要とする4つのIAMロールを作成します。
python3 << 'EOF'
import json, os, subprocess
account_id = os.environ['ACCOUNT_ID']
# ResourceRetrievalRole用トラストポリシー（bedrock-agentcore.amazonaws.comがAssumeできる）
retrieval_trust = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "bedrock-agentcore.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": account_id
}
}
}
]
}
# 残り3ロール用トラストポリシー（AWSアカウントルートがAssumeできる）
account_trust = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": f"arn:aws:iam::{account_id}:root"
},
"Action": "sts:AssumeRole"
}
]
}
# ファイル書き出し
with open('/tmp/retrieval-trust-policy.json', 'w') as f:
json.dump(retrieval_trust, f, indent=4)
with open('/tmp/account-trust-policy.json', 'w') as f:
json.dump(account_trust, f, indent=4)
print("トラストポリシー生成完了")
print("\n--- retrieval-trust-policy.json ---")
print(json.dumps(retrieval_trust, indent=4))
print("\n--- account-trust-policy.json ---")
print(json.dumps(account_trust, indent=4))
EOF# 1. ResourceRetrievalRole
aws iam create-role \
--role-name AgentCorePaymentsResourceRetrievalRole \
--assume-role-policy-document file:///tmp/retrieval-trust-policy.json
# 2. ControlPlaneRole
aws iam create-role \
--role-name AgentCorePaymentsControlPlaneRole \
--assume-role-policy-document file:///tmp/account-trust-policy.json
# 3. ManagementRole
aws iam create-role \
--role-name AgentCorePaymentsManagementRole \
--assume-role-policy-document file:///tmp/account-trust-policy.json
# 4. ProcessPaymentRole
aws iam create-role \
--role-name AgentCorePaymentsProcessPaymentRole \
--assume-role-policy-document file:///tmp/account-trust-policy.json以下のコマンドで４つ表示されれば作成成功です。
aws iam list-roles --query "Roles[?contains(RoleName, 'AgentCorePayments')].RoleName" --output text
AgentCorePaymentsControlPlaneRole AgentCorePaymentsManagementRole AgentCorePaymentsProcessPaymentRole AgentCorePaymentsResourceRetrievalRole 次に作成されたロールにポリシーをアタッチします。
# ロール作成後にポリシーをアタッチする
python3 << 'EOF'
import json, os
account_id = os.environ["ACCOUNT_ID"]
policy = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["bedrock-agentcore:CreateWorkloadIdentity"],
"Resource": [
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:workload-identity-directory/default",
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:workload-identity-directory/default/workload-identity/*"
]
},
{
"Effect": "Allow",
"Action": ["bedrock-agentcore:GetWorkloadAccessToken"],
"Resource": [
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:workload-identity-directory/default",
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:workload-identity-directory/default/workload-identity/*"
]
},
{
"Effect": "Allow",
"Action": ["bedrock-agentcore:GetResourcePaymentToken"],
"Resource": [
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:token-vault/default",
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:workload-identity-directory/default",
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:workload-identity-directory/default/workload-identity/*",
f"arn:aws:bedrock-agentcore:us-east-1:{account_id}:token-vault/default/paymentcredentialprovider/*"
]
},
{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue"],
"Resource": [
f"arn:aws:secretsmanager:us-east-1:{account_id}:secret:bedrock-agentcore-identity*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": account_id
}
}
}
]
}
with open('/tmp/retrieval-policy.json', 'w') as f:
json.dump(policy, f, indent=4)
EOF
aws iam put-role-policy \
--role-name AgentCorePaymentsResourceRetrievalRole \
--policy-name AgentCorePaymentsRetrievalPolicy \
--policy-document file:///tmp/retrieval-policy.jsonCredential Providerの作成
Credential ProviderはAgentCoreがCoinbaseのAPIを呼び出すための認証情報を安全に保管する仕組みです。
具体的には、CoinbaseのAPIキーやWallet SecretといったシークレットをAWS Secrets Managerに暗号化して保存し、AgentCoreがそこから取得できるようにします。アプリケーションのコードや環境変数に認証情報を直接書く必要がなくなるため、情報漏洩のリスクを大幅に減らせます。
Coinbase CDP（Coinbase Developer Platform）は、Coinbaseが提供する開発者向けのブロックチェーン基盤サービスです。
一般的にCoinbaseと聞くと仮想通貨の取引所をイメージしますが、CDPは開発者がアプリケーションにブロックチェーン機能を組み込むためのAPIやSDKを提供するプラットフォームです。AgentCore Paymentsにおいては、CDPが以下の役割を担います。
エージェント用のクリプトウォレットの作成と管理
ユーザーがウォレットを所有しながらも、エージェントが代わりに署名・送金できる「Delegated signing」という仕組みを提供
x402プロトコルに基づく支払いトランザクションの署名と実行を担当つまりAgentCore Paymentsは「支払いの管理・制御」を担当し、CDPは「実際のブロックチェーン上の署名・送金処理」を担当するという役割分担になっています。
AgentCoreが支払い処理を行う際は、このCredential Providerを経由してCoinbaseのAPIにアクセスします。開発者はシークレットの管理をAWSに任せ、アプリケーション側はARN（リソースの識別子）だけを扱えばよい設計になっています。
CoinbaseのAPIキーをAWS Secrets Managerに安全に保存します。AgentCoreが支払い処理を行う際に、このCredential Providerを通じてCoinbaseのAPIにアクセスします。平文でAPIキーを管理する必要がなくなります。
cat > /tmp/create_credential_provider.py << 'EOF'
import os, json
import boto3
client = boto3.client("bedrock-agentcore-control", region_name="us-east-1")
response = client.create_payment_credential_provider(
name="MyCoinbaseCDPProvider",
credentialProviderVendor="CoinbaseCDP",
providerConfigurationInput={
"coinbaseCdpConfiguration": {
"apiKeyId": os.environ["CDP_API_KEY_ID"],
"apiKeySecret": os.environ["CDP_API_KEY_SECRET"],
"apiKeySecretSource": "MANAGED",
"walletSecret": os.environ["CDP_WALLET_SECRET"],
"walletSecretSource": "MANAGED",
}
}
)
print(f"Credential Provider ARN: {response['credentialProviderArn']}")
EOFpython3 /tmp/create_credential_provider.py
Credential Provider ARN: arn:aws:bedrock-agentcore:us-east-1:917561075114:token-vault/default/paymentcredentialprovider/MyCoinbaseCDPProvider無事作成されました。
Payment Manager の作成
Payment Managerはすべての支払いリソースを束ねるトップレベルのリソースです。
イメージとしては「支払い専用の管理部門」です。エージェントが支払いを行う際は必ずこのPayment Managerを経由します。Payment ConnectorやPayment Instrument、Payment SessionといったすべてのリソースはこのPayment Managerに紐付いており、ARN（AWSリソースの識別子）を通じて管理されます。
また、authorizerType に AWS_IAM を指定することで、IAMロールによるアクセス制御が有効になります。誰がPayment Instrumentを作成できるか、誰が支払いを実行できるかといった権限管理をIAMポリシーで一元管理できます。
Step 1で作成した ResourceRetrievalRole をここで紐付けることで、AgentCoreサービスがCredential ProviderやSecretsManagerから認証情報を取得できるようになります。
ARNは皆さんごとに置き換えてください。上のStepで出力されています。
cat > /tmp/create_payment_manager.py << 'EOF'
import os
import boto3
account_id = os.environ["ACCOUNT_ID"]
client = boto3.client("bedrock-agentcore-control", region_name="us-east-1")
response = client.create_payment_manager(
name="MyPaymentManagerCDP",
authorizerType="AWS_IAM",
roleArn=f"arn:aws:iam::{account_id}:role/AgentCorePaymentsResourceRetrievalRole",
)
print(f"Payment Manager ARN: {response['paymentManagerArn']}")
print(f"Payment Manager ID: {response['paymentManagerId']}")
EOF
python3 /tmp/create_payment_manager.pyPayment Manager ARN: arn:aws:bedrock-agentcore:us-east-1:917561075114:payment-manager/mypaymentmanagercdp-qi17byjw73
Payment Manager ID: mypaymentmanagercdp-qi17byjw73Payment Connectorの作成
Payment Managerが「支払い管理部門」だとすると、Payment Connectorは「Coinbaseへの専用回線」にあたります。作成したCredential Provider（Coinbaseの認証情報）とPayment Managerを紐付けることで、Payment ManagerがどのCoinbaseアカウントを使って支払い処理を行うかが決まります。
現在AgentCore Paymentsが対応している決済プロバイダーはCoinbase CDPとStripe（Privy）の2種類です。今回はCoinbase CDPを使うため type: "CoinbaseCDP" を指定しています。将来的に複数のプロバイダーを使い分けたい場合は、Payment Managerに複数のConnectorを追加することも可能です。
ARNとIDは皆さんごとに置き換えてください。上のStepで出力されています。
cat > /tmp/create_payment_connector.py << 'EOF'
import boto3
PAYMENT_MANAGER_ID = "mypaymentmanagercdp-qi17byjw73"
CREDENTIAL_PROVIDER_ARN = "arn:aws:bedrock-agentcore:us-east-1:917561075114:token-vault/default/paymentcredentialprovider/MyCoinbaseCDPProvider"
client = boto3.client("bedrock-agentcore-control", region_name="us-east-1")
response = client.create_payment_connector(
paymentManagerId=PAYMENT_MANAGER_ID,
name="CoinbaseCDPConnector",
type="CoinbaseCDP",
credentialProviderConfigurations=[
{
"coinbaseCDP": {
"credentialProviderArn": CREDENTIAL_PROVIDER_ARN
}
}
]
)
print(f"Connector ID: {response['paymentConnectorId']}")
print(f"Status: {response['status']}")
EOFpython3 /tmp/create_payment_connector.py
Connector ID: coinbasecdpconnector-zebxmhwobw
Status: READYPayment Instrument の作成
Payment InstrumentはエージェントがX402プロトコルで支払いを行う際に実際に使うクリプトウォレットです。
銀行口座に例えると、Payment Managerが「銀行」、Payment Instrumentが「口座」にあたります。エージェントはこのInstrumentを通じてブロックチェーン上でUSDCを送金します。
Coinbase CDPがウォレットアドレスを払い出すため、作成すると walletAddress（例：0x5E9E261C57e7bCCBc3183b902646b3765b54485F）が返ってきます。このアドレスがブロックチェーン上の実際の送金先・送金元となります。
また redirectUrl も返ってきます。これはCoinbaseのWalletHubへのURLで、ユーザーがウォレットへの資金チャージとエージェントへの署名権限付与を行うために使います。
userId はアプリ内でユーザーを識別するための任意の文字列です。同じユーザーが複数のInstrumentを持つことも可能で、Payment SessionやProcess Paymentの際にどのウォレットを使うかを指定するために使います。
ARNとID、メールアドレスは皆さんごとに置き換えてください。上のStepで出力されています。
cat > /tmp/create_instrument.py << 'EOF'
import boto3, uuid
PAYMENT_MANAGER_ARN = "arn:aws:bedrock-agentcore:us-east-1:917561075114:payment-manager/mypaymentmanagercdp-qi17byjw73"
PAYMENT_CONNECTOR_ID = "coinbasecdpconnector-zebxmhwobw"
client = boto3.client("bedrock-agentcore", region_name="us-east-1")
response = client.create_payment_instrument(
userId="test-user-001",
agentName="MyAgent",
paymentManagerArn=PAYMENT_MANAGER_ARN,
paymentConnectorId=PAYMENT_CONNECTOR_ID,
paymentInstrumentType="EMBEDDED_CRYPTO_WALLET",
paymentInstrumentDetails={
"embeddedCryptoWallet": {
"network": "ETHEREUM",
"linkedAccounts": [
{"email": {"emailAddress": "harunobukameda@gmail.com"}}
]
}
},
clientToken=str(uuid.uuid4())
)
instrument = response["paymentInstrument"]
print(f"Instrument ID: {instrument['paymentInstrumentId']}")
print(f"Wallet Address: {instrument['paymentInstrumentDetails']['embeddedCryptoWallet']['walletAddress']}")
print(f"Redirect URL: {instrument['paymentInstrumentDetails']['embeddedCryptoWallet']['redirectUrl']}")
EOF
python3 /tmp/create_instrument.pypython3 /tmp/create_instrument.py
Instrument ID: payment-instrument-0ucUIWKfE8hCrUa
Wallet Address: 0xE9CafFd637a2147030Cdf7D4906cE7de69AA4574
Redirect URL: https://hub.cdp.coinbase.com/7cfb8a6c86d3WalletHubでの権限付与
上記URLにブラウザでアクセスしてメールアドレスでログインします。
Grant permission をクリックします。
Payment Session の作成
Payment Sessionはエージェントがいくらまでどのくらいの期間支払いを行えるかを制御する「支出枠」です。
銀行口座に例えると、Payment Instrumentが「口座」だとすると、Payment Sessionは「この口座から今日は1ドルまでしか引き出してはいけない」という引き出し制限にあたります。
maxSpendAmount で上限金額を設定することで、エージェントが意図せず大量の支払いを行うことを防ぎます。また expiryTimeInMinutes で有効期限を設定すると、期限が切れたセッションでは支払いが拒否されます。
Payment Sessionは使い捨てで、予算を使い切るか期限が切れたら新しいセッションを作成する必要があります。これにより会話ごと・タスクごとに支出を明確に管理でき、エージェントの暴走を防ぐガバナンスの仕組みとして機能します。
PAYMENT_MANAGER_ARN の値は上記で生成されたものに置き換えてください
cat > /tmp/create_session.py << 'EOF'
import boto3, json
PAYMENT_MANAGER_ARN = "arn:aws:bedrock-agentcore:us-east-1:917561075114:payment-manager/mypaymentmanagercdp-qi17byjw73"
client = boto3.client("bedrock-agentcore", region_name="us-east-1")
response = client.create_payment_session(
userId="test-user-001",
agentName="MyAgent",
paymentManagerArn=PAYMENT_MANAGER_ARN,
limits={
"maxSpendAmount": {
"value": "1.00",
"currency": "USD"
}
},
expiryTimeInMinutes=60
)
session = response["paymentSession"]
print(f"Session ID: {session['paymentSessionId']}")
print(f"利用可能残高: {session['availableLimits']['availableSpendAmount']['value']} USD")
EOF
python3 /tmp/create_session.pySession ID: payment-session-Y9PR9xOsZ7JlKQ0
利用可能残高: 1.00 USDテスト用有料APIへアクセス
これで支払いの準備が出来ました。テスト用有料APIへアクセスを行います。
payment_manager_arn,payment_instrument_id,payment_session_id は皆さんの値に置き換えます.。
cat > /tmp/payment_agent.py << 'EOF'
from strands import Agent
from strands_tools import http_request
from bedrock_agentcore.payments.integrations.config import AgentCorePaymentsPluginConfig
from bedrock_agentcore.payments.integrations.strands.plugin import AgentCorePaymentsPlugin
config = AgentCorePaymentsPluginConfig(
payment_manager_arn="arn:aws:bedrock-agentcore:us-east-1:917561075114:payment-manager/mypaymentmanagercdp-qi17byjw73",
user_id="test-user-001",
payment_instrument_id="payment-instrument-0ucUIWKfE8hCrUa",
payment_session_id="payment-session-Y9PR9xOsZ7JlKQ0",
region="us-east-1",
)
plugin = AgentCorePaymentsPlugin(config=config)
agent = Agent(
system_prompt="You are a helpful assistant that can access paid APIs.",
tools=[http_request],
plugins=[plugin],
)
result = agent("access https://drvd12nxpcyd5.cloudfront.net/market-recap")
print(result)
EOF
python3 /tmp/payment_agent.pyI'll access that URL for you right away!
Tool #1: http_request
Received 402 after successful signing for tool http_request — post-payment failure: invalid_exact_evm_insufficient_balance
It seems the payment failed due to an **insufficient balance** error (`invalid_exact_evm_insufficient_balance`). Let me check your payment instrument's balance to understand the situation better.
Tool #2: get_payment_instrument
[{'id': 'v1:before_tool_call:tooluse_AHz3XrXlMuJBqtnKztmXkv:fa27b4fe-5c0d-552c-acb3-e13786a1f621', 'name': 'payment-failure-tooluse_doTZTQ5ZlC0T5Ipf3Zaf0m7d46ec64-cc96-42ed-a269-71c86184d880', 'reason': {'tool': 'http_request', 'toolUseId': 'tooluse_doTZTQ5ZlC0T5Ipf3Zaf0m', 'exceptionType': 'PaymentError', 'exceptionMessage': 'Payment rejected after signing: invalid_exact_evm_insufficient_balance', 'retryAttempt': 1, 'maxRetries': 3, 'timestamp': 1780210431.4860187}, 'response': None}]https://drvd12nxpcyd5.cloudfront.net/market-recap はAWSが準備している HTTP402をテスト可能なURLです。
上記ではエラーが出ていますが、これはこの手順で作成したWalletに支払い用のトークンがチャージされていないためです。
AgentCore Paymentsとテストネット
ブロックチェーンにはメインネットとテストネットの2種類の環境があります。
メインネットは実際に価値のある暗号資産が流通する本番環境です。ここでの送金には実際のお金が必要で、取引は本物のブロックチェーン上に永久に記録されます。
テストネットはその名の通りテスト用の環境です。メインネットと同じ仕組みで動いていますが、ここで使われるトークンは価値を持たない偽物です。「Faucet（蛇口）」と呼ばれるサービスから無料でテスト用トークンを入手でき、開発者がお金をかけずにアプリケーションの動作確認を行うために使います。Web開発で言えばステージング環境に相当します。
ではテストネットからトークンを20ドル分補充してみます。
Wallet Address をコピーします。
次に https://faucet.circle.com/ にアクセスします。
先ほどコピーしたアドレスを入力して Network に Base Sepolia を指定してUSDボタンを押します。そうすると２０ドル分のテスト用トークンが送金されます。Base Sepoliaがテストネットを意味しています。
ただし以下の画面ではメインネットの口座しか確認できませんので、バランスに反映されないことに注意してください。
再度送金を実行すると以下が表示され送金が成功します。
python3 /tmp/payment_agent.py
I'll access that URL for you right away!
Tool #1: http_request
Here's the **Market Recap** from the prediction market ecosystem (generated at **2026-05-31 07:06 UTC**):
---
### 📊 Prediction Market Ecosystem — 24-Hour Recap
**Total Volume:** $372.4M | **Active Markets:** 22,382
---
#### 🏆 Top Sector: Sports
- **$113.8M** in volume
- Top contract: **"Western Conference Champion"** (Kalshi) — $40.6M
- Runner-up: **"Champions League Winner: PSG vs Arsenal"** (Kalshi) — $11.1M
---
#### 🏛️ Exchange Breakdown
| Exchange | Markets | Volume | Share |
|----------|---------|--------|-------|
| **Kalshi** | 10,783 | $97.5M | ~26.2% |
| **Polymarket** | 9,342 | $23.6M | — |
| LMTLESS, Gemini, MEXC, OKEX | — | Modest | Niche |
---
#### 📌 Key Insights
1. **Sports dominates** — Traders are heavily focused on high-visibility sporting event outcomes.
2. **Crypto & financial markets** account for a smaller portion of activity.
3. **Geopolitics & Society** sectors show lower engagement.
4. **Kalshi received CFTC approval** to launch Bitcoin Perpetual Futures Contracts — a positive headline correlating with Kalshi's strong volume.
5. A **negative court ruling** headline may be dampening crypto speculation relative to sports markets.
---
> *Volume change vs. prior session: Not provided. Data sourced via LLM synthesis.*Here's the **Market Recap** from the prediction market ecosystem (generated at **2026-05-31 07:06 UTC**):
---
### 📊 Prediction Market Ecosystem — 24-Hour Recap
**Total Volume:** $372.4M | **Active Markets:** 22,382
---
#### 🏆 Top Sector: Sports
- **$113.8M** in volume
- Top contract: **"Western Conference Champion"** (Kalshi) — $40.6M
- Runner-up: **"Champions League Winner: PSG vs Arsenal"** (Kalshi) — $11.1M
---
#### 🏛️ Exchange Breakdown
| Exchange | Markets | Volume | Share |
|----------|---------|--------|-------|
| **Kalshi** | 10,783 | $97.5M | ~26.2% |
| **Polymarket** | 9,342 | $23.6M | — |
| LMTLESS, Gemini, MEXC, OKEX | — | Modest | Niche |
---
#### 📌 Key Insights
1. **Sports dominates** — Traders are heavily focused on high-visibility sporting event outcomes.
2. **Crypto & financial markets** account for a smaller portion of activity.
3. **Geopolitics & Society** sectors show lower engagement.
4. **Kalshi received CFTC approval** to launch Bitcoin Perpetual Futures Contracts — a positive headline correlating with Kalshi's strong volume.
5. A **negative court ruling** headline may be dampening crypto speculation relative to sports markets.
---
> *Volume change vs. prior session: Not provided. Data sourced via LLM synthesis.*いろいろ表示されています。これはテスト用APIが戻しているResponseです。つまり支払いが成功したためAPI呼び出しが成功したことを示しています。