t54、Amazon Bedrock AgentCore の支払い機能で信頼層を構築

エージェントシステムは調査、推論、そして多段階のワークフローの調整が可能ですが、有料壁にぶつかった瞬間に止まってしまいます。財布もカードもなく、支出制限もないからです。t54 はこの問題を解決しました。

Amazon Bedrock AgentCore は、あらゆるフレームワークやモデルに対応し、大規模なエージェントの構築・接続・最適化を行うプラットフォームです。その機能の一つである Amazon Bedrock AgentCore 決済の信頼層では、人間の承認を一度も経ずに、すでに 2000 万件を超えるエージェント発生の取引が処理されています 20 million agent-initiated transactions。各取引は 0.001 ドルから 0.01 ドルのマイクロペイメントで、人間がその速度で確認できるような高速かつ大量の呼び出しです。

課題：エージェントに財布を持たせるのは簡単だが、大規模な管理はそうではない

t54 の顧客は、サードパーティのサービスに対して自律的に支払いを行う必要があるエージェントシステムを運用しています。例えば、株式ポートフォリオを監視し、ポジションが変動した際にアナリストへアラートを送るエージェントシステムを運用する金融チームを考えてみましょう。このシステムには、有料 API からのリアルタイム市場データが必要です。

エージェントに財布へのアクセス権を与えるのは簡単です。しかし、その周辺の問題は非常に複雑です。単一の設定ミスによるループでアカウントが空にならないよう支出制限を適用したり、認証情報を分離してエージェントが生のキーに触れないようにしたり、コンプライアンスのためにすべての取引を検証したりする必要があります。これらを数十個のエージェントが数百のエンドポイントを呼び出す状況下で行わなければなりません。

ガバナンス層がなければ、チームは手動で取引をレビューして承認するか、管理されていないリスクを受け入れるかの二者択一を迫られます。取引量が少ない場合なら手動承認でも機能しますが、機械的な速度で1 時間に数千回の API 呼び出しが行われる環境では、この手法は崩壊します。そこで必要となるのは、組み込みの制御機能を備えた自律型決済です。

t54 はエージェント決済のための信頼インフラを構築しています。顧客から一貫して求められていたのは、ゼロからカスタムの決済オーケストレーションを構築することなく、安全でスケーラブルかつプロバイダーに依存しない形でエージェントが支払いを行える仕組みでした。これを実現するために、t54 はセッションごとの支出制限、認証情報の保管（クレデンシャル・ボーリング）、そしてマルチプロバイダー対応を組み込んだ決済基盤が必要でした。

Amazon Bedrock AgentCore payments が支出インフラを提供します。具体的には、セッションごとの上限設定、認証情報の分離、および決済実行機能です。一方、t54 の x402-secure は信頼の知能を提供し、リアルタイムでエンドポイントをスコアリングして「誰に支払っても安全か」を判断します。この 2 つを組み合わせることで、カスタム統合作業なしに管理されたエージェント決済が可能になります。

t54 が構築したもの

t54 は、AI エージェントがどのサービスに対して安全に支払いを行えるかを統制する信頼インフラを構築しています。同社の製品である x402-secure は、エンドポイントやオンチェーンの支払いアドレスをリアルタイムでスコアリングする信頼層です。エージェントがサービスに支払う前に、x402-secure がそのサービスの安全性を判断し、指示を出します。

基盤となるプロトコルは x402 です。これは HTTP 402 ステータスコードを活用し、クライアントが HTTP を介して直接 API に支払いを行えるようにするオープンな決済標準規格です。エージェントが有料エンドポイントを呼び出して 402 レスポンスを受け取った際、Amazon Bedrock AgentCore Payments が署名と決済処理を担当します。エージェント側で秘密鍵を直接扱う必要はありません。

x402-secure の背後にあるスコアリングエンジン「Trustline」は、決済が確定する前に 5 つの独立したシグナルを評価します。具体的には、支払いアドレスのブロックチェーン履歴、宛先ウェブページの正当性、サービスのソーシャルメディアでの存在感、API のリアルタイムな健全性ステータス、そしてこれら 4 つを統合して算出される総合リスクスコアです。各シグナルは異なる種類の信頼できないエンドポイントを検知するために設計されています。t54 が構築したリスクモデルでは、単一の弱いシグナルだけで取引が承認されることはありません。

製品スイートには、エージェントネイティブな信用供与機能「ClawCredit」も含まれています。Amazon Bedrock AgentCore Payments はセッションごとの支出上限を強制し、ClawCredit はその範囲内で動作するクレジット裏付けの資金源を提供します。この 2 つの層はそれぞれ独立して支出を管理しています。

「AgentCore にはすでに多くの優秀な開発者がいます。彼らにとって最適な体験とは、独自の決済オーケストレーションを構築させるのではなく、Trustline をプラットフォームに組み込んで提供することだと私たちは考えました。開発者たちが本当に懸念しているのは、エージェントが現実の金銭的損失をもたらすような行動をとることです。私たちの役割は、その安心感を提供することにあります。」

— Chandler Fang、t54 創業者

アーキテクチャ：信頼性と決済がどう連携するか

図 1: 信頼性チェックに合格した後にのみ Amazon Bedrock AgentCore Payments が取引を完了させる、x402 決済フローの概要

この図は、アプリケーションバックエンド、Amazon Bedrock AgentCore ランタイム（Amazon Bedrock AgentCore の機能）、決定論的な信頼ゲートを持つ Strands エージェント、外部有料サービス、そして Amazon Bedrock AgentCore Payments という 5 つのレイヤーにわたる一連の流れを示しています。決済が実行されるには、まず信頼性チェックを通過する必要があります。AWS Identity and Access Management (IAM) による認証、AWS Secrets Manager を用いた資格情報の保存、Amazon CloudWatch による観測機能を含む Amazon Bedrock AgentCore Payments の完全なアーキテクチャについては、技術的深掘り：AgentCore Payments とエージェント型コマースの革新 をご覧ください。

この設計における中核となる原則は「役割の分離」です。お金を使う側と、支出ルールを設定する側を同一にしてはいけません。t54 では IAM による厳格なロール分離を通じてこれを担保しています。システムを 4 つの役割に分割することで、エージェントランタイムが決済を実行することは可能ですが、自らの制限を変更したり、新しいウォレットをプロビジョニングしたり、資格情報を直接アクセスしたりすることはできません。

実際には、エージェントは呼び出し時にセッション ID とインストゥルメント ID のみを取得し、それ以外の情報は受け取りません。開発者の認証情報は、Amazon Bedrock AgentCore Identity（Amazon Bedrock AgentCore の機能）を通じて AWS Secrets Manager で暗号化され、API からは返却されません。エンドユーザーのウォレット署名鍵は、引き続きウォレットプロバイダー（Coinbase）が管理します。エージェントが取得できるのは、セッション限定のトークンだけです。もしエージェントが支出制限に達すれば、処理は即座に停止されます。エージェント内部からリフィルやセッションの再作成を行う経路はありません。

「最も難しい判断の一つは、リスクチェックを『ProcessPayment』の実行前に必ず通す必須ゲートとして設計した点です。これはサイドプロセスではなく、各エンドポイントでスコアリングするインライン処理としました。わずかなレイテンシの増加は許容しますが、相手側の身元を確認する前に決済が確定してしまう選択肢は、実金を取り扱うエージェントにはあり得ません。そのため、私たちはわずかな追加の遅延を受け入れ、一つの保証を優先します：新鮮なリスク判断が行われるまで、決して決済が確定しないこと。」

— t54 での統合を主導した Frank He, PhD

信頼ゲートの重要性

Frank が説明するこの保証こそが、アーキテクチャ上の決定的な選択です。信頼チェックはモデルのプロンプトに基づく提案ではなく、確定的なゲートとして機能します。エージェント型システムは、各支払い実行前に x402 で保護された API を呼び出します。もしエンドポイントがスコア閾値を満たさず、詐欺と判定されたり、URL の不一致が発生したりすれば、コードレベルで決済はブロックされます。モデルがこの判断を覆すことはできません。

スケールした環境では、事前の支払い承認なしに未知の API を呼び出すエージェントは管理不能なリスクを生み出します。これを防ぐのが、決定論的な信頼ゲートです。

この設計思想は、本番環境でも確実に機能しています。

Demo: x402-secure の実演

*この動画では、エンドツーエンドのフローを示しています。エージェントシステムが有料エンドポイントを検出すると、Trustline を介してリアルタイムにスコアリングされます。その後、Amazon Bedrock AgentCore payments がセッション内の支出制限内で取引を実行します。

結果

ローンチ以降、x402-secure は 2,000 万件以上の AI エージェントが開始したトランザクション を処理してきました。決定論的な信頼ゲート、IAM ロールの分離、そしてセッションごとの支出制限により、人間の介入なしにすべての取引が適切に管理されています。

"2,000 万件のトランザクションは、エージェント間の支払いがデモの域を超えて実際に大規模に行われていることを示しています。それぞれの取引額は 0.001 ドルから 0.01 ドルのマイクロペイメントで、データや API を呼び出すような高速かつ小規模な処理です。これらを人間がリアルタイムに確認することは不可能です。その過程で、リスクスコアが高いエンドポイントへの支払いをブロックし、セッションの支出制限を守りながら、エージェントをより安全な場所へ誘導しています。"

— Chandler Fang, t54 創業者

自律型 AI 向けの金融基盤はすでに本番環境で稼働しています。今問われるべきは、AI エージェントが支払いを必要とするかどうかではありません。重要なのは、不適切な取引が発生する前にガバナンス層が整っているかどうかです。

仕組みの深掘り：コントロールプレーンとデータプレーン

同様の統合を実装したい開発者のために、t54 が Amazon Bedrock AgentCore の支払い機能における2つのレイヤーをどのようにマッピングしたかをご紹介します。

セットアップ（コントロールプレーン）

カスタム統合コードを各プロバイダーごとに記述する必要なく、以下の3つのリソースが支払いインフラストラクチャを構築します。

• Credential Provider：認証情報をトークン vault に格納します。エージェントランタイム上では、認証情報が平文で表示されることはありません。
• Payment Manager：認可、ID 管理、および支払いコネクタを統合します。t54 では、OpenID Connect (OIDC) のディスカバリーエンドポイントをバックエンドに持つ CUSTOM_JWT 認証者を設定して構成しました。

Payment Connector は、支払いプロバイダの種類（CoinbaseCDP）を指定し、Credential Provider を参照することで、Payment Manager と外部プロバイダを結びつけます。

ランタイム時（データプレーン）

ライブトランザクションを処理する 3 つのオペレーションがあります：

「CreatePaymentSession」は、支出上限、有効期限（15〜480 分）、およびユーザー ID を指定してセッションを開始します。Amazon Bedrock AgentCore payments は、利用可能な残高をリアルタイムで追跡します。 （原文の技術表記: userId）

「CreatePaymentInstrument」は、指定されたネットワークに対応した埋め込み暗号ウォレットをプロビジョニングします。このレスポンスには、ウォレットアドレスとオンボーディング用のリダイレクト URL が含まれます。

「ProcessPayment」は決済を実行します。決済が確定する前に、Trustline がエンドポイントのスコアリングを行います。承認された場合、Amazon Bedrock AgentCore payments は processPaymentId、ステータス、および完全な監査証跡を返します。もしフラグが立った場合は、x402-secure によって決済がブロックされ、支出制限は維持されます。

MCP マーケットプレイスの統合

t54 はまた、Coinbase の x402 Bazaar（有料 AI ツールサーバーのマーケットプレイス：Model Context Protocol、通称 MCP サーバー）に対しても同様の統合テストを行いました。エージェント型システムは Amazon Bedrock AgentCore Gateway（Amazon Bedrock AgentCore の機能の一つ）を介して接続し、有料ツールを発見して呼び出します。ツールが x402 による支払い要件を返した場合、ProcessPayment が取引に署名を行います。Amazon Bedrock AgentCore payments の設定一つで、直接の API エンドポイントとマーケットプレイスに登録されたツールの両方をカバーでき、追加の設定は不要です。

信頼シグナル

表 1 は、決済前にスコアリング対象となる x402-secure エンドポイントをリストしています。

表 1：x402 セキュアな信頼スコアリングエンドポイント

オブザーバビリティと監査

すべての ProcessPayment コールは、セッション、インストゥルメント、金額、ステータスなどの構造化ログを Amazon CloudWatch に出力します。AWS CloudTrail はコンプライアンスレビュー用の完全な API 履歴を記録します。信頼判断と支払い結果は、Amazon CloudWatch Application Signals でセッションごとに相関付けられます。規制対象のワークロードでは、エージェントが支出するドルのすべてと、そのために使用された信頼シグナルについて、コンプライアンスチームが継続的な監査証跡を取得できます。

入門ガイド

支払い API を利用するエージェントを構築している場合:

t54 x402 セキュアユースケース では、本記事で説明した実装の全体像を確認できます。入門チュートリアル では、エージェントによる支払いをエンドツーエンドで体験できます。オープンソース SDK を使用して、既存の AgentCore エージェントに信頼スコア付きの支払い機能を追加しましょう:

pip install x402-secure

支払いエンドポイントを提供する API プロバイダーの場合:

x402 ファシリテーター URL を t54 プロキシに置き換えるだけで、信頼保護を追加できます。x402 API はそのままに、設定を 1 つ変更するだけです:

Before: https://x402.org/facilitator
After: https://x402-proxy.t54.ai

さらに詳しく

本サービスのアーキテクチャとパートナーネットワークについては、以下のランチブログをご覧ください。

Agents that transact: Introducing Amazon Bedrock AgentCore payments

初めてのエージェント型決済のステップバイステップ解説は、以下のチュートリアルをご覧ください。

Amazon Bedrock AgentCore payments Getting Started Tutorial

一般的な決済パターンに関する参考実装については、以下のユースケースページをご覧ください。

Amazon Bedrock AgentCore payments Use Cases

API リファレンスと設定ガイドの詳細は、以下のドキュメントをご覧ください。

Amazon Bedrock AgentCore payments documentation

サービスの概要や料金プランについては、Amazon Bedrock AgentCore ページをご覧ください。

MIT ライセンスで公開されている x402-secure SDK をインストールしてください。

リアルタイムのリスクインテリジェンスについては、x402-secure dashboard をご覧ください。

Trustline や ClawCredit に関する詳細は t54.ai でご確認ください。

執筆者について

Chris Wajule

Chris は AWS で 11 個の認定を取得したソリューションアーキテクトです。インフラストラクチャ、エージェント AI、Web3 が交差する領域で、効率的かつスケーラブルな知的クラウドシステムの構築に取り組んでいます。顧客への影響や倫理的なイノベーションを推進することを使命としています。

Chethan Shriyan

Chethan は AWS のシニアプロダクトマネージャー（技術担当）です。製品およびビジネスマネジメントの経験は 12 年以上に及びます。顧客の生活に実りある影響をもたらすテクノロジー製品の開発と提供に情熱を注いでいます。

Chandler Fang

Chandler は t54 の創業者です。自律型エージェント経済における信頼インフラの構築という同社のミッションを率いています。x402-secure、Trustline、ClawCredit を含む、t54 エージェントネイティブサービス全体の製品戦略を統括しています。

Frank He, PhD