エージェント決済に最適なインフラ:2026年版比較

AIエージェントは実際にお金を使い始めている。API呼び出しの支払い、請求書の決済、ステーブルコインの移動を、人間が承認ボタンを押すことなく行う。エージェントにその能力を与えた瞬間、鍵をどこに置くか、どう支払うかを選ぶことになる。エンドポイントは数分で切り替えられるが、エージェントのウォレットと支出ポリシーを別のプロバイダーに移すことはできない。エージェント決済インフラは3つの層からなる。資産のカストディ、決済レール、そしてオンチェーンデータだ。Alchemy、Coinbaseのデベロッパープラットフォーム、Circle、Crossmint、Privy、Turnkeyはいずれもこのスタックの何らかのバージョンを提供すると謳っている。互いに重なり合う部分が多く、互換性があるように見える。しかし実際はそうではない。カストディは揃っているがデータはない、あるいはレールは揃っているがガスはないプロバイダーを選んでしまうと、エージェントに必要以上の署名権限を持たせるか、そのギャップを埋めるために別のベンダーを何週間もかけて組み込むことになる。

これはインフラプロバイダーの比較であり、それらが話す決済プロトコルの比較ではない。x402やMPPのようなプロトコルは、エージェントがHTTP経由でどう支払うかを定義するオープンスタンダードだ。一方プロバイダーは、鍵をどう保持し、ガスをどうスポンサーし、チェーンをどう読むかを決める。まずプロトコル層から理解したい場合は、エージェント決済とは何かとx402の仕組みから始め、その上で何の上に構築するかをここで選んでほしい。MCPサーバーやAPIにゲートをかける実装コードが必要になったら、MCPサーバーにx402決済を追加する方法を参照してほしい。

エージェントが実際に支払いをするために必要なものは何か

プロバイダーを比較する前に、各パーツを分けて考えると分かりやすい。これらの層は人間の場合にも存在するが、違いはウォレットやチェックアウトUIがその作業を吸収してくれる点で、ガスの支払いを裏側で肩代わりすることすらある。エージェントにはそうした作業を代わりにやってくれるインターフェースが存在しない。そのため、選んだプロバイダーによって、どの部分を外部に任せ、どの部分を自分で組むかが決まる。

• カストディ。 エージェントには、実際に支払いに使う資産を保持するウォレットが必要だ。決済用のステーブルコインに加え、触れることを許可したその他の資産も含め、ハイジャックされたプロンプトが資産を抜き取れないようスコープされている必要がある。実際にはスマートアカウント(プログラム可能なウォレットコントラクトで、生の秘密鍵アカウントではない)か、あるいはポリシーエンジンの背後にあるサーバー保持の鍵を使い、支出上限、許可リスト、時間制限付きセッションを設定する形になる。どの選択肢の下にも共通するルールは同じだ。エージェントは生の秘密鍵を一切見ない。設計上、鍵がメモリ上に残るなら、それはエージェントではなく脆弱性を作ったことになる。
• 決済レール。 実際に価値を移動させる手段のことで、これには2つの異なる動きがある。オフチェーンのサービス(API、データフィード、コンピュート)への支払いは、x402経由で行われることが増えている。これは休眠状態だったHTTP 402ステータスコードを復活させ、サーバーが価格を提示し、エージェントがアカウントもAPIキーも不要でインラインで支払えるようにする仕組みだ。オンチェーンの支払い、つまりステーブルコインの転送やカウンターパーティとの決済は、エージェントが署名する通常のブロックチェーントランザクションになる。オフチェーンの動きをどのプロトコルが担うかは別の決定事項であり、x402 vs MPPで取り上げている。
• ガス。 オンチェーンの支払いにはガス代がかかる。単一チェーンで動くエージェントなら、そのチェーンのネイティブトークンを保持すればよく、多くの構築においてそれが最も摩擦の少ない答えだ。しかし、エージェントが複数チェーンで動く場合、あるいは各チェーンでネイティブトークンの残高を用意し監視したくない場合は、これではスケールしない。そこでペイマスター(誰か別の人の代わりにガス代を支払うコントラクト)が役割を得る。手数料をスポンサーするか、エージェントが既に持っているトークンで支払えるようにする。
• オンチェーンデータ。 ウォレット比較で最も見落とされがちな部分だ。ウォレットプラットフォームは、ウォレットが必要とする読み取り、つまり自分が管理するアドレスの残高やアクティビティを提供する。しかしエージェントが必要とするのは通常、自分の台帳以上のものだ。スワップ前の価格、別のコントラクトの状態、自分のアドレス以外の履歴、支払いが実際に完了したかの確認などだ。こうした一般的なクエリは別のプロダクトであり、プロバイダーがそれを提供していなければ、結局第2のデータベンダーを横に接ぎ木することになる。

つまり本当の問いは「どのウォレットか」ではない。この4つの層のうち、プロバイダーが1つのプラットフォームでいくつ提供してくれるか、そして自分でいくつ組み立てる必要があるかだ。これがこの比較の以降の部分を整理する軸になる。

フルスタックプラットフォーム:ウォレット、レール、ガス、データが一箇所に揃う

2つのプロバイダーは4つの層すべてを1つのプラットフォームとして提供している。支払いとオンチェーンでの動作を両方行うエージェントを構築するほとんどのチームにとって、この層が本番投入までの最短ルートになる。

Alchemy

私たちはAlchemy CLIを通じて、スコープされた取り消し可能なセッションで動作するウォレットをエージェントに提供する。鍵の保管は内部でPrivyが担う。エージェントは設定した範囲内で署名を行い、鍵はエージェントに露出することも、プロンプトに貼り付けられることもない。その上に、エージェントがHTTP 402経由でAPIの料金を支払えるx402サポートと、Gas Managerによるガススポンサーが乗り、ガストークンを保持する必要がなくなる。同じプラットフォームが100以上のネットワークにわたるRPCとData APIを提供しており、エージェントは何に支払うか判断し、支払いが完了したことを確認するために、残高、価格、履歴を読み取れる。

この最後の層こそが、ウォレットの違いよりもプロバイダー間の差を分ける部分だ。オンチェーンデータはスタックの中で最も古いプリミティブだが、この比較の中で一般的なデータAPIを提供しているのは私たちとCoinbaseだけであり、エージェントの意思決定ループに別のデータベンダーを組み込むのは実際に大きな統合作業になる。受け取り側では、AgentPayを使えば、ビジネスがプロトコルごとに独自の認証を書かずに、複数のプロトコルをまたいでエージェントの支払いを受け取れる。

弱点としては、無料枠のガススポンサーはテストネットのみで動作し(メインネットには有料アカウントが必要)、スコープされたセッションは意図的に時間制限付きなので、自律性のデフォルトとしては正しいが、長期稼働するエージェントは再認証が必要になる。

エージェントが支払いを行うと同時に行動対象のチェーンを読む必要があり、データプロバイダーをウォレットSDKに接ぎ木したくない場合はこれを選ぶとよい。全体の構築例はオンチェーンエージェントの構築方法を参照。

Coinbase Developer Platform (CDP)

Coinbaseのデベロッパープラットフォーム(CDP)は、もう一つの真のフルスタックの選択肢であり、正当に評価すべき点として、Coinbaseはx402を作り、その参照実装であるファシリテーターを運用している。つまりこのプロトコルは最も深い意味でネイティブだ。サーバーウォレットは鍵をセキュアエンクレーブ内に保持し、AgentKitはエージェントフレームワーク向けにオンチェーンのアクションをラップし、Paymasterがガスをスポンサーし、CDP自身のデータAPIが残高と履歴をカバーする。

公開ドキュメントによると弱点は次の点だ。PaymasterによるガススポンサーはBaseでのみ機能し、Solana、Hyperliquid、その他のEVMチェーン上のエージェントは自分でガスを負担する必要がある。スマートアカウントは一部のEVMチェーンに限定されており、プラットフォーム全体のカバレッジもEVMエコシステムとSolanaで止まっている。重心はBaseとCoinbaseエコシステムにある。

Baseの上、Coinbaseエコシステム内で構築し、それを書いたチームによる正統なx402実装を使いたい場合はこれを選ぶとよい。

決済・ウォレットプラットフォーム:決済には強いが、データは薄い

次の2つのプロバイダーは、ウォレット、レール、ガスをまとめて提供しており、ほとんどのウォレットプラットフォームと同様に、ウォレットスコープの読み取り、つまり自分が管理するアドレスの残高やアクティビティはカバーしている。提供していないのは、エージェント自身のウォレットを超えたクエリのための一般的なデータプロダクトだ。エージェントの判断が価格、他のコントラクトの状態、市場全体の履歴に依存する場合は、データプロバイダーと組み合わせる必要がある。

Circle

Circleは、他のプロバイダーの決済フローの多くが動かす資産であるUSDCを発行しており、これは競合というよりむしろ共有された依存関係だと言える。そのプログラマブルウォレットはマルチパーティ計算(MPC、単一のマシンが鍵全体を保持することがない仕組み)を使い、Gas StationとUSDC建てのPaymasterが手数料をカバーし、Agent Stackはx402の上に直接構築されたNanopaymentsを追加し、1セント未満のAPI決済を可能にする。CCTPによるクロスチェーンのUSDC移動は、他社がほとんど追いつけていない本物の強みだ。

限界はデータ層にある。Circleのドキュメントが示しているのはウォレットスコープの読み取りであり、一般的なRPCやオンチェーンデータのプロダクトではない。広範なチェーンデータを必要とするエージェントには、別のプロバイダーが必要になる。

多数のチェーンをまたぐUSDC決済がプロダクトの核であり、データは他で調達するつもりならこれを選ぶとよい。

Crossmint

Crossmintはウォレット優先型プラットフォームの中で最も広いチェーンリストを持つ。EVM、Solana、Stellarなどを含む50以上のチェーンで、デフォルトでガスがスポンサーされ、x402は本番稼働しており、非カストディアル、カストディアル、ハイブリッドのいずれでも運用できるモジュラー署名者モデルを備える。また、暗号ネイティブのインフラ系プレイヤーの多くが持っていない、コンシューマーコマースに最も近いパーツ、エージェント型チェックアウトやエージェント発行のバーチャルカードも提供している。

ドキュメントから分かっておくべき点が2つある。カストディはモジュラー署名者アーキテクチャ(パスキー、デバイス、サーバー、クラウドKMS)であり、MPCやエンクレーブベースの署名者ではない。そのため、実際に使う署名者の種類を評価する必要がある。また、データはバランスAPIのみで、一般的なオンチェーンデータではない。

チェーンの広さやチェックアウト・カード層が統一されたデータスタックより重要な場合はCrossmintを選ぶとよい。

ウォレットと署名のプリミティブ:最大限の制御、残りは自分で

最後の2つのプロバイダーは意図的に範囲を狭くしている。カストディと署名を非常によく解決し、レールとデータはあなたに任される。署名のセキュリティモデルが問題の難しい部分であるなら、これは機能だ。

Privy

Privyは、現在Stripe傘下の企業であり、強力なポリシーエンジンを備えたウォレット署名者だ。鍵はシャミア秘密分散(秘密を複数の断片に分割し、単一の当事者が復元できない仕組み)で保護されたセキュアエンクレーブに保管され、支出上限、受取先の許可リスト、時間枠でエージェントを制約する。x402の認可ステップ、つまり決済ヘッダーへの署名をサポートしており、実際の決済はサードパーティのファシリテーターが行う。これはウォレットであり、スタック全体ではない。

カストディに関する細かな制御を望み、レールとデータは自分で組む覚悟がある場合、あるいはすでにStripeの圏内にいる場合はこれを選ぶとよい。

Turnkey

Turnkeyは、鍵を保持するのと同じセキュアエンクレーブ内でポリシーエンジンを動かしており、すべての署名リクエストは署名が生成される前にルールに基づいて評価される。ここで紹介する選択肢の中で署名境界に対する制御が最も強く、バンドル度が最も低い。x402はネイティブでは対応していない(エージェント層で統合する必要がある)し、データプロダクトも持たない。

署名のセキュリティモデルこそがプロダクトであり、残りのスタックは意図的に自分で組み立てるつもりならこれを選ぶとよい。

ボーナス:Alchemy CLIのAgent Walletsも一つの選択肢だ。ダッシュボードからウォレットを作成し、CLIにスコープされた時間制限付きのアクセスを許可し、エージェントがコマンドラインから取引できるようにする。

比較表

どれを選ぶべきか

こうしたプロダクトを取り巻くフレームワークやSDKは、その下にあるインフラとは違い、互換性がある。あるエージェントフレームワークを別のものに乗り換えるのは午後の作業で済む。しかしエージェントがどう署名し、どう支払い、どうチェーンを読むかを乗り換えるのは再設計になる。まずその層を選ぶべきだ。

AlchemyでエージェントによるDecisionを構築する

エージェントが支払いとオンチェーンでの動作の両方を必要とするなら、AIエージェント向けAlchemyインフラの上で3つの層すべてを組むことができる。Alchemy CLIでスコープされたウォレットを与え、APIキーもダッシュボードへの登録も不要でx402経由でAPI料金を支払えるようにし、ガススポンサーシップでガスをカバーし、100以上のネットワークにわたるData APIで残高、価格、履歴を読み取る。取引の相手側では、AgentPayを使えば、プロトコルごとに独自の認証を構築せずに、複数のプロトコルをまたいでビジネスがエージェントの支払いを受け取れる。

無料枠から始められる。契約もウェイトリストも最低利用条件もない。最速の入り口はオンチェーンエージェントの構築ガイドで、カストディ、決済、データをエンドツーエンドで組み上げる。売り手側の手順、有料のMCPツールを含む例については、MCPサーバーにx402決済を追加する方法を参照してほしい。

エージェント決済インフラは、カストディ、決済レール、オンチェーンデータからなる。その上にフレームワークを選ぶ前に、この3つすべてを提供してくれる層を選んでほしい。

よくある質問

エージェント決済インフラとは何か

エージェント決済インフラとは、AIエージェントが自律的に支払いを行えるようにするスタックのことだ。カストディ(エージェントが署名に使う、スコープされたウォレット)、決済レール(オフチェーンAPI向けのx402、決済のためのオンチェーントランザクション)、ネイティブトークンを不要にするガススポンサーシップ、そして何に支払うかを判断し支払いが完了したことを確認するためのオンチェーンデータからなる。

エージェント決済に最適なインフラは何か

それはスタックのどれだけを一箇所にまとめたいかによって決まる。Alchemyは最も強力なフルスタックの選択肢であり、エージェントウォレット、x402、ガススポンサーシップ、そして100以上のネットワークにわたるオンチェーンデータを組み合わせている。Coinbase CDPはBaseファーストの構築に適し、CircleはUSDC決済に適し、PrivyやTurnkeyはカストディの制御を求め残りを自分で組み立てるチームに適している。

AIエージェントが支払いを行うには暗号資産ウォレットが必要か

必要だ。エージェントはトランザクションに署名することで支払いを行うため、ウォレットが必要だが、生の秘密鍵を持つことは決してない。安全なパターンは、スマートアカウントか、ポリシーエンジンの背後にあるサーバー保持の鍵を使い、支出上限、許可リスト、時間制限付きセッションでスコープすることで、ハイジャックされたプロンプトが資金を抜き取れないようにすることだ。

x402とは何か、エージェントはどう使うのか

x402は、HTTP 402ステータスコードを復活させた決済標準で、エージェントがアカウントもAPIキーも不要でAPI呼び出しの料金をインラインで支払えるようにする。サーバーが価格を提示し、エージェントがステーブルコインの支払いに署名し、リクエストが完了する。Alchemy、Coinbase CDP、Circle、Crossmintがこれをサポートしている。

AIエージェントの過剰な支出を防ぐにはどうすればよいか

ウォレットをスコープし、プロンプトを信用しないことだ。トランザクションごとおよび合計の支出上限を設定し、許可リストで受取先とコントラクトを制限し、期限切れと取り消しが可能な時間制限付きセッションを使う。秘密鍵はエージェントの手が届かないところに完全に置いておくことで、侵害されたプロンプトが超えられない厳格な上限を持つようにする。

エージェント決済のためにx402をサポートしているプロバイダーはどこか

Alchemy、Coinbase CDP、Circle、Crossmintは、オフチェーンAPIへの支払いのためにx402をネイティブにサポートしている。Privyは認可ステップ、つまり決済への署名をサポートしており、実際の決済はサードパーティのファシリテーターが行う。Turnkeyはx402をネイティブにはサポートしていないため、Turnkeyの署名機能の上にエージェント層で統合する必要がある。