2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

2026/5/7(木)頃に、Amazon Bedrock AgentCoreの新機能として「Payments」がプレビューで追加されました。

正直なところ決済系は未知の領域ではありますが、せっかくなので決済エージェントに入門してみたいと思います。
ただ、いきなり決済してみるのも怖いので、今回はモックAPIを使って決済を行います。

1. AIエージェントと決済の話

本題のAgentCore Paymentsの話へ入る前に、イメージがつきやすいよう軽く決済の話をします。

デジタルコンテンツの普及や収益化の多様化

近年では、以下のようなサービスの普及により、「サービスを使った分だけ支払う」という考え方が身近になってきているかなと思います。

  • 動画や音楽やコンテンツ
  • 有料記事
  • AWSなどクラウドやSaaS

例えば、以下のようなコンテンツの支払いではどうでしょうか。

  • 有料記事を1つだけ購入する
  • 有料WebAPIを1リクエスト単位で課金する

いずれも1回の購入というより、少額の支払いを何度も行うことになります。
数円やそれ以下の少額に対して、クレジットカード決済などでは手数料の方が大きくなってしまいます。

マイクロペイメントの登場

マイクロペイメントは、数円〜十数円、それ以下という「ごく小さな金額」の支払いのための仕組みです。
手数料もタダとはなりませんが、クレジットカードなどよりは断然安く済みます。

上記のように少額の取引を何度も行う際に便利な仕組みです。

ステーブルコインで支払おう

では、マイクロペイメントはどうやって実現するのでしょうか。

選択肢の1つが暗号資産を使った決済です。
しかし、一般的な暗号資産は価格が毎日変動するため、「今日は$0.001のAPIだったけど、明日いくらになるかわからん!」という問題があります。

そこで使われるのが「ステーブルコイン」です。

ステーブルコインは、法定通貨(米ドルや円など)と価値が連動するよう設計されており、価格が安定しています。
米ドルならUSDCがあります。日本円ならJPYCの取り組みが進んでいるようです。

JPYCについては、先日幕張で行われたAWS Summitでもセッションがありました。(オンデマンドならまだ見れます!)

AIエージェントに決済をさせて楽をしよう

では、誰がこの支払いを行うのでしょうか。
少額とはいえ、毎回人間が確認・承認するのは現実的ではありません。そこで、AIエージェントに自動で支払いを任せることが考えられます。

image.png

しかし、AIエージェントに決済を任せるには課題があります。

  • AIエージェントが勝手に高額な支払いをしないか
  • どの処理に対して、いくら支払ったのか追跡できるか

一番簡単なのは、人間が確認して、承認すればいいですよね。
ただ、AIエージェントが外部サービスを利用するたびに、人間が毎回画面を開いて認証・購入ボタンを押すのは現実的ではありません。

image.png

つまり、AIエージェントにマイクロペイメントなどで決済を任せるには、「支払える」だけでなく以下のような仕組みが必要です。

  • 支払い金額や支払い先を制御できる
  • 支払い履歴を監査できる

2. Amazon Bedrock AgentCore Payments とは

AgentCore Paymentsは、Amazon Bedrock AgentCoreの機能の1つであり、AIエージェントがマイクロペイメントを行う際の「お財布管理」機能を担ってくれます。

image.png

Amazon Bedrock AgentCore とは
「Amazon Bedrock AgentCore」は、AIエージェントを構築・デプロイするためのマネージドサービスです。
ただ構築できるだけでなく、認証・認可、運用監視といったエージェントを構築・運用するための機能が盛りだくさん組み込まれています。

AgentCore Paymentsの役割

AgentCore Paymentsは、あくまでお財布管理の役割であって、実際の支払い処理はAIエージェントの実装に依存します。

下図でいうと、ユーザーのお財布が「ウォレット」、有料コンテンツを提供する相手が「Merchant」です。
このとき、ウォレットの予算管理、ウォレットの先にある外部サービスとの連携などを行うのがPaymentsの役割です。

実際にMerchantに支払いを行う場合は、後述するStrandsAgents向けのプラグインを導入する、または自前で実装する必要があります。

image.png

Strands Agentsとは
「Strands Agents」は、AWSが提供するAIエージェントを実装するためのSDKです。
PythonまたはTypeScriptで記述できます。AWSを使っているならStrands Agentsでエージェントコードを書いて、AgentCore Runtimeにデプロイする流れが多いかなと思います。

Paymentsの構成要素

Paymentsの構成要素は以下の通りです。

image.png

image.png

PaymentConnectorの対象サービス

PaymentConnectorは、実際の決済サービスとの接続を管理します。
現在は、以下2つのサービスと連携しており、PaymentConnectorを設定する際にどちらかを選びます。

  • Coinbase
  • Stripe/Privy

Coinbase CDPとは
Coinbase Developer Platformが提供するウォレットのインフラです。
ウォレットの作成から秘密鍵管理、支払い署名まで、Coinbaseが一元的に管理してくれます。

Stripe/Privyとは
Privyがユーザーのウォレットの作成と秘密鍵管理を担い、Stripeがその上の決済処理を担います。
2つがセットで1つのPaymentConnectorとして動作します。

AWSリソースの管理範囲

上記で述べた構成要素ですが、セッション周りは支払いの都度作る必要がありますし、Connectorは事前にAWSリソースとして定義する必要があります。

種類 主なリソース 作るタイミング
初期設定
リソース
PaymentCredentialProvider
PaymentManager
PaymentConnector
決済基盤のセットアップ時
ユーザー単位のリソース PaymentInstrument ユーザーの
ウォレット作成・連携時
都度作るリソース PaymentSession タスク開始時
エージェント実行時
支払い枠が必要になった
タイミング

初期設定リソースを構築する場合、2026/6/24時点で以下のIaCなどで構築できます

Paymentsリソース CFn CDK AWS CLI AWS SDK AgentCore SDK
PaymentCredentialProvider 可(L1)
PaymentManager 可(L1)
PaymentConnector 可(L1)

StrandsAgents向けPluginを使った実際の決済処理(x402)

AgentCore Paymentsはあくまで「お財布管理」です。
実際にお金を支払うには別途実装が必要になります。

StrandsAgentsでエージェントを構築する場合、AgentCore SDKが「Payments Plugin」を提供してくれています。Pluginは「x402」という決済プロトコルでお金のやり取りをします。

もう一度役割を見てみます。
下図の緑色の枠をPayments Pluginが担い、赤色の枠をAgentCore Paymentsが担います。

image.png

x402とは

x402は、HTTPを使った支払いのためのオープンなプロトコルです。

HTTPレスポンスとして支払い条件をHTTPステータス402で返し、クライアントがその条件に従って支払い情報を付与して再リクエストすることで成立します。

x402_flow.png

402 は、HTTPステータスコードの 402 Payment Required を指し、支払い処理向けにずっと前から予約されていたステータスコードです。

x402にはv1とv2があるようです。Payments Pluginはどちらにも対応しています。
本記事ではv2を前提に書いていこうと思います。

Payments Plugin とは

Payments Pluginは、StrandsAgentsがx402を使った決済を行うためのプラグインです。

Strands Agentsのプラグインとは
Strands Agentsが提供する仕組みで、ツールや前述のHooksなどをエージェントに追加して、エージェント全体の動作を制御することができます。
https://strandsagents.com/docs/user-guide/concepts/plugins/

このx402のやり取りをするために、以下のツールが提供されています。http_requestがメインでx402のリクエストに使います。

ツール名 用途 説明
http_request x402決済付きHTTPリクエスト HTTPエンドポイントを呼び出し、402レスポンスは自動的に決済される
getPaymentInstrument Instrumentsの照会 特定のウォレットの詳細を取得します。
listPaymentInstruments Instrumentsの一覧取得 ユーザーのすべてのウォレットを一覧表示します。
getPaymentSession Session照会 特定の決済セッションの詳細を取得します。

またプラグインには、以下のフックが含まれています。

種類 呼び出し
タイミング
役割
before_tool_call ツール呼び出し前 前の支払いが失敗していた場合、ツール実行を中断してLLMに通知
after_tool_call ツール呼び出し後 402レスポンスを検知し、PAYMENT-SIGNATUREヘッダーを生成して再送する

Strands AgentsのHooks とは
Strands Agentsが提供する仕組みで、ツール呼び出しの前後に任意の処理を差し込めます。
https://strandsagents.com/docs/user-guide/concepts/agents/hooks/

シーケンスにすると以下のような感じです。
payments_plugin_x402_flow.png

Faucetでお試し

PaymentsやPluginを駆使して、決済が出来そうなことは分かりました。
だけど、いきなり決済を試すのは怖い。。。

パッと思いつく方法としては、大きく2つあるかなーと思いました。後者の方はまだ試せていませんが...

  1. x402のAPIモックを作る
  2. 自前でx402対応のWebサイトを作る

2のx402の有料Webサイトを作る方法として、最近WAFのx402対応が発表されました。本記事で試したのは1のx402モックです。

Faucetで無料のテスト用トークンをもらう

Faucetは、開発者向けのテスト用に少量の暗号通貨(ETHやUSDC)を無料で配布してくれるサービスです。

Faucetにも色々と対応しているサービスが公開してくれているのですが、今回は以下のBaseのサイトから「Coinbase Developer Platform Faucet(以降CDP Faucet)」を選びました。

CDP Faucetについては、以下の公式を参照してみてください。

3. 実際に作ってみる

構成的には以下になります。
いきなり実際の決済を行うのは怖いので、x402のモックAPIを作ってます。

aws_architecture1.png

あとWebアプリのところはNext.jsをAmplifyでホスティングしてます。
こちらは現在開発者プレビューのdefineHostingを使用しています。
(この辺りの話は、次の記事で書く予定です。)
https://github.com/aws-amplify/amplify-backend/issues/3211

事前準備

AgentCore Paymentsを利用するには、以下の事前準備が必要です。(今回は、Privy/Stripeを使用する前提です)

  • Privyのセットアップ
  • Payment Managerの作成
  • Payment Connectorの作成(Stripe)

Privyのセットアップ

詳細はこちら

Privyのサイトを開いて、サインアップします。

image.png

https://www.privy.io

image.png

Get startedを選択します。
image.png

いくつか質問されるので答えます。
image.png

image.png

最後にアプリ作成を促されるので、作成します。
image.png

アプリができました。作成したアプリを選択します。
image.png

左のメニューから「設定」>「アプリ設定」を選択します。
image.png

「アプリID」と「アプリシークレット」を控えておきます。
image.png

左のメニューから「ウォレットインフラストラクチャー」>「認可」を選択します。
New keyから新たなキーを作成し、これも控えておきます。
image.png

Payment Manager を作成する

次にAWSマネジメントコンソールを開いて、AgentCore の画面を開きます。
左のメニューに「Payments」があるので、開きます。
image.png

プレビューなのでまだ東京リージョンには来ていないので、今回はus-east-1で試しています。

Payment Managerというリソースを作る必要があるので、「Payment Managerを作成」を選択します。
image.png

名前は初期値にして、許可のIAMアクセス許可には「新しいサービスロールを作成して使用」を選択します。
image.png

インバウンド認証は、IAMユーザーを使用のまま、支払いコネクタに任意の名前を入力します。そしてアウトバウンド認証を設定する必要があるので、新規作成を選択します。
image.png

プロバイダーに「Coinbase」or「Stripe(Privy)」を選択できますが、今回は「Stripe(Privy)」を選択します。
image.png

Stripe(Privy)を選択した場合、以下の4項目を入力します。各値は事前準備でPrivyで控えておいた値を使用します。

  • アプリケーションID:「設定」>「アプリ設定」の「アプリID」
  • アプリシークレット:「設定」>「アプリ設定」の「アプリシークレット」
  • 認証ID:「ウォレットインフラストラクチャー」>「認可」で作成したキーの「ID」
  • 認証プライベートキー:「ウォレットインフラストラクチャー」>「認可」で作成したキーの「秘密鍵」
    image-1.png

Payment Managerを作成を選択します。
image.png

これでPaymentManagerとPaymentConnectorが作成されます。
image.png

Strands Agentsに決済機能を実装する

次にStrandsAgentsの実装に入りますが、AgentCore SDKの「PaymentsPlugin」を使うことで、x402周りの処理のほとんどをPluginに任せることができます。

Pluginの設定にはAgentCorePaymentsPluginConfigを使います。

./agent-runtime/app.py
    config = AgentCorePaymentsPluginConfig(
        payment_manager_arn=payment_manager_arn,
        user_id=user.user_id,
        payment_instrument_id=payment_instrument_id,
        payment_session_id=payment_session_id,
        payment_connector_id=os.getenv("PAYMENT_CONNECTOR_ID"),
        region=os.getenv("PAYMENTS_REGION", "us-east-1"),
        payment_tool_allowlist=["http_request"],
        agent_name="strands_agent",
    )

    return AgentCorePaymentsPlugin(config=config)

user_idは、今回は認証にAmazon Cognitoを使用しているので、ユーザプールのSUBをidとして使っています。

payment_tool_allowlistは、after_tool_callフックの処理対象とするツールを指定できます。今回はPluginが提供するhttp_request のみを対象としています。(余計なツールがフックの処理対象にならないようにです)

作成したプラグインはpluginshooksに分けてStrands Agentsに渡します。

./agent-runtime/app.py
    plugins = [payments_plugin] if payments_plugin else []
    hooks = list(payments_plugin.hooks) if payments_plugin else []

    strands_agent = Agent(
        model=model,
        system_prompt=load_system_prompt(),
        tools=[
            create_payment_instrument,
            delete_payment_instrument,
            prepare_wallet_authorization,
        ],
        plugins=plugins,
    )

    return StrandsAgent(
        agent=strands_agent,
        name="strands_agent",
        description="Strands AgentCore runtime that streams native AG-UI events.",
        hooks=hooks,
        config=StrandsAgentConfig(emit_messages_snapshot=False),
    )

今回のAIエージェントは、フロントエンドとの通信をAG-UIで行います。
以下のアダプタを使用して、StrandsAgentsをAG-UI化しています。
https://github.com/ag-ui-protocol/ag-ui/tree/main/integrations/aws-strands/python

上記でpluginshooksに分けて渡している理由は、AG-UIのアダプタ側でPluginの中のhooksが引き継がれないためです。(おそらく分けて渡す設計思想?)

StrandsAgentsにPayments周りのツールを実装する

次にエージェントがPayments周りのリソースを操作するためのツール群を実装します。
今回実装したツールの一覧は以下の通りです。

prepare_wallet_authorizationは、フロントエンドでHuman-in-the-loopするための事前準備ツールになります。詳細は後述します。

ツール名 説明
create_payment_instrument ウォレットを作成する
delete_payment_instrument ウォレットを削除する
prepare_wallet_authorization フロントエンドの署名承認に必要なウォレット情報を取得する

各種ツールのコードは以下になります。

フロントエンドのHuman-in-the-loopでSigner承認UIを実装する

今回は、Payments Connectorに「Privy/Stripe」を使用しています。
Privyを使用する場合、ウォレットへエージェント向けのSignerを追加する必要があります。

少しややこしいですが、支払い署名が必要になるのは、x402の支払いヘッダーを作るタイミングです。
この時、支払い元のウォレットにSignerが追加されていないと、x402ヘッダーを作れなくなってしまいます。

この流れや実装は、PrivyとAWSが共同管理している以下のサンプル実装を参考にしました。

UI周りの実装では、assistant-uiのHuman-in-the-loopでSigner承認を行なっています。

エージェントが前述のprepare_wallet_authorizationツール呼び出しを行います。
その結果を使って、フロントエンドで定義した以下のrequest_wallet_authorizationツールを実行し、Signer承認UIを表示します。

その後、ユーザー操作で承認してもらって、結果をエージェントへ返します。

./app/components/paymentToolkit.ts
"use client";

import { type Toolkit } from "@assistant-ui/react";
import { WalletAuthorizationTool } from "./payment-tools/WalletAuthorizationTool";

export const paymentToolkit: Toolkit = {
  request_wallet_authorization: {
    type: "human",
    description:
      "Ask the signed-in user to explicitly authorize the Privy signer for an active payment wallet.",
    parameters: {
      type: "object",
      properties: {
        paymentInstrumentId: { type: "string" },
        walletAddress: { type: "string" },
        network: { type: ["string", "null"] },
      },
      required: ["paymentInstrumentId", "walletAddress"],
      additionalProperties: false,
    },
    render: WalletAuthorizationTool,
  },
};

実際に、request_wallet_authorizationツールで表示されるのは以下のWalletAuthorizationTool.tsxになります。

その中でもPrivyのuseSigners()が提供するaddSigners関数を使って、対象ウォレットにSignerを追加しています。

./app/components/payment-tools/WalletAuthorizationTool.tsx
    try {
      await addSigners({
        address: wallet.address,
        signers: [{ signerId: PRIVY_SIGNER_ID!, policyIds: [] }],
      });
      setState("authorized");
      onAuthorized("approved");
    } catch (caught) {

Faucetsの設定

テスト用の通貨で動作確認をするためにFaucetsの設定をする必要があります。
今回は、CDPのFaucetsを使用するので、以下の手順に従います。

x402対応モックAPIを実装する

疎通確認用にx402対応したAPIを実装します。
API自体はNext.jsのAPI Routesで構築してます。

HTTPFacilitatorClientを使って、Facilitatorのクライアントを設定します。

./app/api/paid/weather/route.ts
  const facilitatorClient = new HTTPFacilitatorClient({
    url: X402_FACILITATOR_URL,
  });

x402ResourceServerを使って、x402サーバーを設定します。この時に先ほど作成したFacilitatorのクライアントも設定します。

./app/api/paid/weather/route.ts
  const server = new x402ResourceServer(facilitatorClient).register(
    X402_BASE_SEPOLIA_NETWORK,
    new ExactEvmScheme(),
  );

最後にwithX402でAPIをラップします。
これでNext.jsのAPIをx402対応エンドポイントにできます。

./app/api/paid/weather/route.ts
  const protectedHandler = withX402(
    weatherHandler,
    {
      accepts: {
        scheme: "exact",
        price: X402_TEST_PRICE,
        network: X402_BASE_SEPOLIA_NETWORK,
        payTo,
      },
      description: "Get test weather data for AgentCore Payments validation.",
      mimeType: "application/json",
    },
    server,
  );

これで簡単な動きにはなりますが、エージェントがモックにx402で決済を行う動作ができるようになります。

まとめ

今回は、プレビューのAgentCore Paymentsを使ったAIエージェントを実装しました。

私自身、x402といった決済の仕組みも初めてだったので、敷居は高かったですが面白い領域だなと思いました。(最初は馴染みのない単語ばかりで、脳みそが理解するのを拒んでました...)

AgentCore Paymentsは、最初「支払いまで全部やってくれないの!?」と思ってましたが、Pluginがあったのでだいぶ助かりました。

今後は、WAFのx402対応とか試してみたいですね。あとは、本質的に決済や暗号資産回りの知識が無さすぎるので、基礎を勉強したいです...

そのほか参考

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?