はじめに
2026 年 8 月 4 日、Cloudflare は AI エージェント向けのプログラマブルなウォレット「Cloudflare Wallets」を発表しました。
ここでいうウォレットは、単に暗号資産を保管するための財布ではありません。人間が管理する資金の一部を AI エージェントに委譲し、予算や利用先を制限しながら API、MCP ツール、コンテンツなどを購入させる仕組みです。さらに、人間が読めるハンドルを通じて「どのアカウントから委譲されたエージェントか」を任意で示す役割も想定されています。
この記事では、Cloudflare の発表をもとに、次のポイントを整理します。
- Cloudflare Wallets が解決しようとしている課題
- Account Wallet と Virtual Wallet の違い
- x402 を使ったマイクロペイメントの流れ
- 決済とエージェントのアイデンティティを組み合わせる理由
- 開発者が期待できるユースケースと、現時点での注意点
2026 年 8 月 4 日時点で利用できるのは、Cloudflare アカウントに紐づく Wallet ハンドルの取得です。ステーブルコインの保管・支払い、Account Wallet、Virtual Wallet、入出金などは今後提供予定の機能として発表されています。
AI エージェントは人間向けの購入フローが苦手
AI エージェントが新しい API を試すには、現在も人間向けに設計された手順を通る必要があります。
- サインアップ画面を開く
- メールアドレスなどを登録する
- 支払い方法を追加する
- API キーを発行する
- SDK や API の呼び出し方を確認する
人間にとっても手間のかかる流れですが、エージェントにはさらに大きな壁があります。エージェント自身にはサービスを横断して使える安定した識別子がなく、API の利用料を自律的に支払う標準的な手段もないからです。
そのため、途中で人間に登録や決済を依頼することになり、複数の API を少額ずつ試して比較するようなタスクは効率が落ちます。
Cloudflare Wallets は、この問題を次の 2 つに分けて解こうとしています。
- 支払い: エージェントが HTTP 経由で少額決済できるようにする
- アイデンティティ: エージェントが必要に応じて継続的な識別子を提示できるようにする
Cloudflare Wallets の全体像
Cloudflare Wallets では、人間向けの Account Wallet と、エージェント向けの Virtual Wallet という 2 種類のウォレットが計画されています。
| 項目 | Account Wallet | Virtual Wallet |
|---|---|---|
| 主な利用者 | Cloudflare アカウントの所有者 | AI エージェント |
| 役割 | 資金の追加・引き出しと委譲元の管理 | 委譲された範囲内での支払い |
| 操作方法 | 人間が管理 | API キーを通じてエージェントが操作 |
| 支出制御 | Virtual Wallet ごとのポリシーを設定 | 設定された上限と権限に従う |
| 想定する購入対象 | — | API、MCP ツール、コンテンツなど |
Account Wallet：人間が資金とルールを管理する
Account Wallet は、Cloudflare アカウントを所有する人間や組織のためのウォレットです。資金を追加し、その一部を Virtual Wallet に委譲し、必要に応じて資金を戻す役割を持ちます。
たとえば、社内のリサーチエージェントごとに週 10 ドル、画像生成エージェントに月 100 ドルといった予算を割り当てる使い方が考えられます。
Virtual Wallet：制限付きの支払い権限をエージェントに渡す
Virtual Wallet は AI エージェントが API キー経由で利用するウォレットです。Account Wallet の残高全体を自由に使えるわけではなく、所有者が設定したポリシーの範囲内で支払います。
発表では、次のようなガードレールが挙げられています。
- 一定期間に使える予算（allowance）
- 支払いを許可する相手のリスト（allow list）
- 1 回の取引で支払える上限
- 上限超過時の人間への例外申請
- 急激な支出など、異常が起きた場合の人間による確認
ここでの重要な設計は、エージェントに秘密鍵や口座全体をそのまま渡すのではなく、限定された支払い権限を委譲することです。
支出上限はエージェントの自由を狭めるだけの機能にも見えます。しかし、損失の最大値が事前に決まっていれば、人間は少額の範囲でエージェントを自律的に動かしやすくなります。数セントで試せる API なら、10 ドルの予算でも多数の候補を比較できます。
x402 で API の利用と支払いを 1 つの HTTP フローにする
Cloudflare Wallets の支払いには、HTTP の 402 Payment Required を利用するオープンな決済プロトコル x402 が使われます。
従来の API では、利用前にサービスごとのアカウントと API キーを作るのが一般的です。x402 では、サーバーが HTTP レスポンスで価格や支払い先を提示し、クライアントが署名済みの支払い情報を付けてリクエストを再送します。
Cloudflare の x402 ドキュメントに基づく概念的な流れは次のとおりです。
GET /api/weather HTTP/1.1
Host: api.example.com
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <Base64 でエンコードされた価格・トークン・ネットワーク・支払い先>
GET /api/weather HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <署名済みの支払いペイロード>
HTTP/1.1 200 OK
PAYMENT-RESPONSE: <決済結果>
処理を分解すると、次の 5 ステップになります。
- エージェントが有料リソースをリクエストする
- サーバーが
402と支払い条件を返す - エージェントが条件を確認し、ウォレットで支払いを承認する
- サーバーまたは Facilitator が支払いを検証・決済する
- サーバーがリソースと決済結果を返す
支払い条件と証明が通常の HTTP リクエスト／レスポンスに含まれるため、別のチェックアウト画面へ移動する必要がありません。Cloudflare Agents SDK は x402 に対応しており、AI エージェントから有料 API や MCP ツールを呼び出すための土台はすでに公開されています。
x402 は Cloudflare Wallets 専用の仕組みではありません。x402 Foundation のリポジトリで仕様と SDK が Apache-2.0 ライセンスにより公開されている、HTTP ベースのオープンプロトコルです。
売り手の Monetization Gateway と買い手の Wallets
Cloudflare は Wallets に先立ち、Web ページ、API、データ、MCP ツールなどに x402 の支払い条件を設定する「Monetization Gateway」を発表しています。
両者の役割は次のように整理できます。
| 役割 | Cloudflare の仕組み | 提供する機能 |
|---|---|---|
| 売り手 | Monetization Gateway | リソースの価格設定、支払いの検証、アクセス制御 |
| 買い手 | Cloudflare Wallets | 資金の保管、エージェントへの予算委譲、支払い |
| 接続レイヤー | x402 | HTTP 上で支払い条件・証明・結果を交換 |
これらが揃うと、エージェントはサービスごとに事前登録しなくても、有料リソースを発見し、価格を確認し、許可された予算内で購入できるようになります。Cloudflare が目指しているのは、売り手とエージェントが人間向けの画面を介さずに取引できる「ヘッドレスな市場」です。
ウォレットのハンドルがエージェントの身元になる
支払いができるだけでは、取引相手から見たエージェントの身元はわかりません。1 人のユーザーが多数のエージェントを作れるため、同じ相手に無料トライアルを何度も付与してしまう問題も起こります。
Cloudflare Wallets は、Cloudflare アカウントに紐づく cloudflare.pay のハンドルを、この問題へのシンプルな識別子として使います。発表では、組織のリサーチエージェントを次のような名前で表す例が示されています。
research.example.cloudflare.pay
Cloudflare の Web Bot Auth は、Ed25519 の鍵ペアと HTTP Message Signatures を使い、リクエストが登録済みのエージェントから送られたことを検証します。Wallet のハンドルは、その読みにくい暗号学的な識別子に、人間が覚えやすい名前を対応付ける位置付けです。
ただし、ハンドルの提示は任意です。また、Cloudflare 自身も特定のアイデンティティスキーマや新しい本人確認方式を定義するものではないと説明しています。
つまり、ハンドルからわかるのは主に「継続して参照できる Cloudflare アカウントの委譲先であること」です。ハンドルがあるだけで、エージェントの行動や取引相手としての信用まで保証されるわけではありません。
開発者にとって何が変わるのか
Cloudflare Wallets と x402 が普及すると、API の提供方法やエージェントの設計に次のような変化が考えられます。
API を契約ではなく 1 リクエスト単位で試せる
エージェントは、API ごとにアカウントを作る代わりに、数セントを支払って結果を評価できます。価格、品質、レイテンシを比較し、タスクに最適なサービスを実行時に選ぶ設計が現実的になります。
MCP ツールを従量課金で提供できる
データ検索、画像生成、ブラウザー操作のような MCP ツールを、呼び出し単位で販売できます。月額契約に向かない専門的なツールも、エージェントから直接購入される可能性があります。
組織の AI 予算をポリシーとして配布できる
部署や従業員、用途ごとに Virtual Wallet を分ければ、AI 推論や外部データ購入の予算をコードから扱えるようになります。単なる請求集計ではなく、支払い前に上限や利用先を制限できる点が特徴です。
コンテンツがエージェントから直接収益を得られる
記事、データセット、検索結果などを 1 件単位で販売できれば、広告や人間からの購読だけでなく、エージェントによる利用を収益源にできます。これは Monetization Gateway が掲げる売り手側の構想とつながります。
導入前に確認したいこと
Cloudflare Wallets は興味深い構想ですが、発表段階では判断材料が揃っていない部分もあります。
提供済み機能とロードマップを分ける
現時点で公開されているのは Wallet ハンドルの取得です。実際の入出金方法、対応地域、手数料、対応するステーブルコインやネットワーク、監査ログ、鍵の管理方式などは、正式提供時のドキュメントで確認する必要があります。
API キーを支払い権限として厳重に扱う
Virtual Wallet の損失は上限で抑えられても、API キーが漏えいすれば許可された範囲内で不正利用される可能性があります。正式提供時に有効期限やローテーションの仕様を確認し、用途ごとの分離と異常検知を組み合わせる設計が必要です。
ガードレールだけでタスクの正当性は保証できない
許可リストや取引上限は「いくら、どこへ支払えるか」を制御します。しかし、「その購入がユーザーの意図に沿っているか」は別の問題です。高額な購入や取り消しにくい取引では、人間による承認や監査可能な実行履歴を残すべきです。
オープンプロトコルと製品依存を区別する
x402 はオープンなプロトコルですが、Cloudflare Wallets のアカウント管理、ポリシー、ハンドルは Cloudflare の製品です。将来の移行性が重要なシステムでは、決済プロトコルとウォレット事業者の境界を意識して設計するとよいでしょう。
まとめ
Cloudflare Wallets の本質は、AI エージェントに暗号資産を持たせることだけではありません。人間が管理する資金から、制限付きの支払い権限と継続的な識別子をエージェントへ委譲することにあります。
- Account Wallet で人間が資金とポリシーを管理する
- Virtual Wallet でエージェントに限定的な支払い権限を渡す
- x402 で API 利用と決済を HTTP のフローに統合する
-
cloudflare.payと Web Bot Auth で任意のアイデンティティを提示する - Monetization Gateway と組み合わせ、売り手と買い手の両側をつなぐ
一方で、2026 年 8 月 4 日時点では決済機能の多くが今後提供予定です。まず注目すべきなのは、Cloudflare がウォレットを単独の決済製品ではなく、エージェントの権限管理・アイデンティティ・Web 上の取引をつなぐ基盤として設計している点でしょう。