AIエージェントにウォレットを持たせる

エージェントウォレットとは、AIエージェントがオーナーに代わって支出できる、範囲を限定した残高のことです。支出はオーナーが設定した上限の範囲内に限られます。これにより、エージェントはオーナーのカードを預かることなく、API、ツール、コンテンツの代金を支払えます。

エージェントが次のように動く場面を見たことがあるでしょう。ドキュメントを読み、適切なエンドポイントを選び、リクエストを組み立てたところで、クレジットカードの入力を求めるサインアップフォームに行き当たって止まってしまう。そして残りの作業はあなたに戻ってきます。

2026年8月4日に発表されたCloudflare Walletsは、この考え方を具体化した一例です。本記事では、エージェントウォレットとは何か、Cloudflareがどのような制御機能を説明しているか、HTTP上で支払いがどのように流れるか、そしてどのような課題が未解決のまま残っているかを解説します。エージェントによる決済がどこへ向かっているのかを示すものであり、本番環境での利用を推奨するものではありません。この製品はまだ初期段階にあり、仕様変更や提供終了の可能性があります。

エージェントにカードを渡すのがうまくいかない理由

カード番号を渡すと、エージェントは個々のタスクに必要な範囲をはるかに超える権限を持つことになります。加盟店の制限も、タスクごとの予算もなく、どのエージェントが何に支出したかの記録も残りません。その権限を取り戻すにはカードを解約するしかなく、そうすると同じカードに紐づく他の支払いもすべて止まってしまいます。

ユーザーに代わってブラウジングや操作を行うエージェントは、この問題に頻繁に直面します。Cloudflareの発表は、欠けている要素として2つを挙げています。エージェントにはサインアップに使える固定のIDがなく、エージェント自身の支払い手段もありません。そのため、エージェントはたいてい途中で止まり、サインアップ、支払い、APIキーの取得を人間に引き渡します。これでは、エージェントが多数の有料サービスを自律的に試し、比較することは困難です。

エージェントウォレットとは:Account WalletとVirtual Wallet

エージェントウォレットは、資金そのものと、それを支出する権限とを分離します。資金は人間が保有し、各エージェントには自律的に支出できる限られた枠が割り当てられます。Cloudflareの設計は2層構造になっています。

Cloudflare Walletsのドキュメントによると、Virtual Walletの目的は、支出額に厳格な上限を設けつつ、ステップごとに人間の承認を得なくてもエージェントが作業を進められるようにすることです。発表では、エージェントがAPI、コンテンツ、MCPツールの購入にこれを利用するとしています。MCPツールとは、MCPエコシステムに関するガイドで取り上げたものと同じサーバーサイドのツールです。

ただし、その大半はまだリリースされていません。

WalletsのFAQには、いくつかの条件が追記されています。ハンドルを予約しても、ローンチ時にウォレットを利用できる保証はありません。一度予約したハンドルは、変更、解放、移管ができません。Cloudflareは予約を拒否または回収できます。プレスリリースでは、ウォレットの全機能は「今後数か月以内」に提供されるとしていますが、具体的な日付は示されていません。

エージェントウォレットにはどのような制御機能があり、何が欠けているのか

Cloudflareの発表では、オーナーがVirtual Walletに設定する3つのガードレールと、エージェントが上限に達した場合の手動オーバーライドが挙げられています。いずれもまだ提供されていません。ドキュメントでは「権限(permissions)」と支出上限に触れているのみで、個々の制御機能の名称は記載されていません。

Cloudflareの発表にもドキュメントにも、エージェントの支出権限の有効期限や、それを取り消すためのAPIについての記述はありません。また、Cloudflareは、想定外に速いペースでの支出など、通常と異なるアクティビティを人間が確認できるようにするとしています。ただしこれは意図の表明にすぎず、文書化された制御機能ではありません。トリガーや仕組みは公開されていません。

エージェントの支払い方法:x402とHTTP 402

x402は、HTTPリクエストに支払いを付加するオープンプロトコルです。HTTPで古くから予約されていながら、実際には挙動が定義されてこなかった402 Payment Requiredステータスコードを再利用します。CloudflareのMonetization Gatewayに関する記事では、フローを次のように説明しています。

1. エージェントが、x402に対応したエンドポイントにリソースをリクエストする。
2. サーバーが、価格と支払い方法を含めて402を返す。
3. エージェントが支払いを行い、今度は支払いの証明を付けて再度リクエストする。
4. ファシリテーターが支払いを検証し、その後サーバーが要求されたリソースを返す。

Cloudflareのウォレットは、当初はステーブルコインで決済されます。これはCloudflareの選択であり、x402の要件ではありません。Monetization Gateway自体も、発表時点ではウェイトリスト形式での受付開始となっていました。

cloudflare.payハンドルにより、加盟店は誰が支払っているのかを確認することもできます。ハンドルが、エージェントがどの組織に属しているかを示すためです。発表では、research.example.cloudflare.payというリサーチエージェントが例として挙げられています。このアイデンティティを提示するかどうかはエージェント側の任意であり、身元が明らかなエージェントを異なる扱いにするかどうかは各加盟店が判断します。

エージェントが誤った買い物をした場合、誰が責任を負うのか

エージェントが誤った買い物をした場合に誰が責任を負うのかについて、現時点で公開されている情報源はありません。情報源には、次の3つの疑問が未解決のまま残されています。

チャージバックはどうなるのか? Monetization Gatewayの記事では、ステーブルコインによる決済はチャージバックがなく、資金が売り手に直接渡るものとして説明されています。Walletsの発表にもドキュメントにも、エージェントが誤って行った購入について、購入者がどのように異議を申し立てるのかは説明されていません。

監査証跡には何が記録されるのか? 支払いログには、何が支払われたかが記録されます。しかし、エージェントがなぜ支払うことを選択したのかの記録については、どの情報源にも記述がありません。

誰が過失の責任を負うのか? アカウントの所有者、エージェントの開発者、加盟店のいずれも考えられます。情報源はこの点に触れていません。

InfoQによるローンチの分析は、構造的な論点を加えています。これらの制御機能は予算を設定するものであって、ポリシーではないという点です。各チェックは、1件の支払いを固定の数値と比較するだけです。そのため、「同じデータセットを今週2回購入しない」といったルールは、過去の支払いに依存するため、どの制御機能でも表現できません。InfoQは同時実行の問題も指摘しています。エージェントが複数の支払いを同時に送信すると、他の支払いが差し引かれる前に、それぞれが利用枠全体に対してチェックされる可能性があり、合計が上限を超えてしまうおそれがあります。この場合に利用枠がどう振る舞うのか、Cloudflareは公表していません。

エージェント決済をめぐる広がる競争

エージェント決済に取り組んでいるのはCloudflareだけではありません。Coinbaseのx402プロトコルや、Stripeのエージェント向けLinkウォレットは、同じ課題に異なるアプローチで取り組んでいます。x402はCoinbaseが開発し、Linux Foundationに寄贈されました。x402 Foundationは2026年7月に活動を開始し、40のメンバーが参加しています。

Stripeは逆のアプローチを取っています。ローンチ時点では、エージェント向けLinkウォレットは、人間が支出リクエストを1件ずつ承認した後にのみ、使い捨てカードまたはShared Payment Tokenをエージェントに付与します。Stripeは、ユーザーが設定できる上限機能を今後追加するとしています。決済は、エージェント向けツールからなる、より大きなスタックの1つのレイヤーにすぎません。そのスタックには、AIエージェント向けのDocker MCPや、サイトが自らのアクションをエージェントに公開できるWebMCPといった構成も含まれます。

まとめ

エージェントウォレットは、「カードを渡す」というやり方を、上限付きの委任された権限に置き換えるものです。Cloudflareの方式では、こうした上限は支払い単位で設定されます。一方で、責任の所在、異議申し立て、同時実行時の挙動はまだ文書化されていません。資金のチャージや支払い機能がリリースされるまでは、実際に行えるのはハンドルの予約だけです。エージェントを開発しているのであれば、それまでの間に、自分たちの支出ルールをどこに置くべきか(ウォレット側か、アプリケーション側か)を検討しておくとよいでしょう。

よくある質問

x402はCloudflareやステーブルコインでしか使えないのですか?

いいえ。x402はHTTP上の決済のためのオープン標準です。Coinbaseが開発し、現在はLinux Foundation傘下のx402 Foundationが管理しています。同財団はAWS、Google、Stripe、Visa、Mastercard、Cloudflareを含む40のメンバーとともに発足しました。Linux Foundationによると、x402は従来のカードからステーブルコインまで、さまざまな支払い手段に対応しています。ステーブルコインを採用したのはCloudflareが自社のウォレットについて選択したことであり、プロトコルがそれを必須としているわけではありません。

HTTP 402 Payment Requiredは正式なステータスコードですか?

はい。ただし、その挙動は仕様で定義されていません。HTTPセマンティクスの仕様であるRFC 9110では、402は将来の利用のために予約されたものとされており、MDNも402には標準的な慣例がないと記しています。ブラウザーやHTTPクライアントは、402を他の4xxクライアントエラーと同様に扱います。x402は、この欠けていた慣例、つまり402レスポンスに何を含めるか、クライアントがどのように支払うか、支払いの証明を付けてどのように再試行するかを補うものです。

Cloudflare WalletsとStripeのエージェント向けLinkウォレットの違いは何ですか?

人間による承認を置くポイントが異なります。Cloudflareによると、Virtual Walletでは、事前に設定された利用枠、加盟店許可リスト、最大取引額の範囲内で、エージェントが自律的に支出できるようになる予定です。一方、2026年4月にローンチされたStripeのエージェント向けLinkウォレットは、人間が支出リクエストを1件ずつ承認した後にのみ、使い捨てカードまたはShared Payment Tokenをエージェントに付与します。Stripeは、ユーザーが設定できる上限機能を今後提供するとしています。

エージェントウォレットの上限機能では表現できない支出ルールを、どのように適用すればよいですか?

エージェントが支払う前に実行されるポリシーチェックを、自身のアプリケーションに追加します。過去の購入履歴を台帳として保持し、同じデータセットを1週間に2回購入するといった重複をチェックで拒否できるようにします。また、データベーストランザクションやエージェントごとの単一の支払いキューなどを使い、チェックの際に資金をアトミックに確保するようにします。これにより、並行して行われた複数の支払いが、いずれも同じ未使用の利用枠に対するチェックを通過してしまうことを防げます。