Cloudflare Wallets発表まとめ｜AIエージェントが「自分で支払う」ためのウォレットとx402

AIエージェントの開発をご検討中ですか？ AIエージェント開発サービスを見る →

Cloudflareが2026年8月4日、AIエージェント向けのプログラマブルウォレット「Cloudflare Wallets」を発表しました。人間の代わりに調べ物や作業をこなすAIエージェントに、人間が設定した上限の範囲内で自律的に支払いを行う手段と、取引相手から見て検証可能な身元を持たせる仕組みです。

「AIが勝手にお金を使う」と聞くと不安が先に立ちますが、発表の中身はむしろ逆で、「エージェントに支払いをさせるなら、どう制限し、どう身元を確かめるか」という管理の枠組みが主役です。この記事では、Cloudflare Walletsの要点を「背景」「ウォレットの2層構造」「x402プロトコル」「身元識別」「ガードレール」「提供状況」の順で、実務目線で整理します。

背景：エージェントは働けるのに「支払えない」

今のWebの決済は、徹頭徹尾「人間が操作する」前提で作られています。クレジットカードの入力フォーム、ログインページ、CAPTCHAによる本人確認、月額サブスクリプションの契約画面——どれも人間がブラウザの前に座っていることを想定した設計です。

一方で、Webトラフィックの過半はすでにボット由来とされ、AIエージェントが人間の代わりにAPIを叩き、データを取得し、サービスを比較する場面は急速に増えています。ここで問題になるのが、エージェントは「使いたいAPIやコンテンツ」を見つけられても、その場で対価を支払う手段がないことです。

有料APIを試すには、人間がサインアップしてAPIキーを発行し、クレジットカードを登録する必要がある
従量課金ではなく月額契約が基本のため、「1回だけ試す」「複数サービスを比較する」ことのコストが高い
売り手側から見ると、アクセスしてくるエージェントが「誰の代理か」を確かめる方法がない

Cloudflare Walletsは、この「エージェント経済の決済の穴」を埋める買い手側のインフラとして位置づけられています。

ウォレットの2層構造：Account WalletとVirtual Wallet

Cloudflare Walletsは、人間用とエージェント用の2種類のウォレットを分けた設計になっています。

ウォレット	使う主体	できること
Account Wallet	Cloudflareアカウントを持つ人間・組織	資金の追加、Virtual Walletへの支出委任、資金の引き戻し
Virtual Wallet	AIエージェント	APIキーで動作し、委任された権限・上限の範囲内でのみ支払い

ポイントは、エージェントが直接お金を持つのではなく、人間のAccount Walletから「使ってよい枠」を委任される構造にしたことです。エージェントは毎回の支払いに人間の承認を仰がずに動ける一方、使える金額・範囲はあらかじめ人間側が決めた枠を超えられません。

Cloudflareが挙げる例では、「従業員1人に週100ドルのAI推論予算を与える」といった企業ポリシーを、そのままウォレットの委任設定として表現できます。予算の付け替えや引き戻しもAccount Wallet側から行えるため、経費管理の考え方に近い運用が可能です。

x402プロトコル：HTTPリクエストに支払いを添付する

支払いの実行を担うのがx402プロトコルです。名前の由来はHTTPステータスコード「402 Payment Required」で、1997年のHTTP/1.1以来「将来の利用のため予約」とされたまま眠っていたコードを、エージェント決済の標準として実装したものです。

決済フローはシンプルです。

エージェントが有料リソース（APIやコンテンツ）にHTTPリクエストを送る
サーバーが402ステータスと価格情報を返す
エージェントが支払い証明を添付して再リクエストする
サーバーが支払いを検証し、リソースを返す

従来のように「チェックアウトページに進む」「APIキーを事前に交換する」手順がなく、支払いそのものが認証情報の役割を果たす設計です。決済にはステーブルコイン（主にUSDC）が使われ、BaseやSolanaといったブロックチェーン上で1セント未満の手数料・数秒以内に完了します。クレジットカードのように最低手数料が数十円かかる仕組みでは成立しない、1回数円以下のマイクロペイメントを前提にできるのがステーブルコイン採用の理由です。

x402は2026年4月にLinux Foundation傘下で「x402 Foundation」として標準化団体が発足しており、Cloudflareのほか、AWS、Anthropic、Coinbase、Circleなど20社以上が参加しています。初年度で約1億6,900万件の支払い、59万の買い手、10万の売り手を記録したとされ、AWSもCloudFrontのWAF Bot Controlに「Monetize」アクションとしてx402対応を組み込むなど、エッジ事業者の間で対応が広がっています。

cloudflare.pay：エージェントに「名乗れる身元」を与える

決済と並ぶもう1つの柱が、エージェントの身元識別です。

売り手にとって、支払い能力のあるエージェントでも「どこの誰の代理か」が分からなければ、優遇も警戒もできません。Cloudflare Walletsでは、ウォレットにcloudflare.payドメインの人間可読なハンドル（例：research.example.cloudflare.pay）を紐づけられます。これにより売り手側は、

「このエージェントはexample社のresearchエージェントだ」と識別したうえで取引できる
特定のエージェントに対してトライアル期間やサインアップクレジットを提供できる
継続的な取引履歴を、一貫した身元に対して蓄積できる

といった、人間の顧客に対して行ってきた関係構築をエージェント相手にも行えるようになります。技術的には、エージェントが鍵ペアで身元を登録するWeb Bot Authの仕組みと統合されており、ウォレットの識別子はその鍵ペアを人間が読める形にしたものと説明されています。なお身元の宣言は任意で、匿名のまま取引することも可能です。識別子のスキーマは、x402 Foundationで進むアイデンティティ仕様の標準化に追従する方針が示されています。

ガードレール：暴走と攻撃を「決済レイヤー」で止める

エージェントに支払い権限を持たせるうえで最大の懸念は、バグや悪意ある指示（プロンプトインジェクション）によってエージェントが意図しない支出をすることです。Cloudflare Walletsは、この対策をエージェントの判断力ではなく決済レイヤーの構造で担保しようとしています。

支出上限（allowance）：Virtual Walletが使える総額を人間が設定
許可リスト（allow list）：支払い先を特定のマーチャントに限定
最大取引額：1回あたりの支払いサイズを制限
異常検知：通常と異なる支出パターンは人間のレビューに回す

たとえ攻撃者がプロンプトインジェクションでエージェントを騙せたとしても、「許可リスト外への送金」「上限超過の支出」はウォレット側で拒否されます。エージェント本体のガードレール（プロンプトでの制約）はすり抜けられる可能性が常にありますが、決済レイヤーの制約はエージェントがどう判断しようと物理的に超えられない、という点がこの設計の肝です。

Monetization Gatewayと合わせて「両面市場」が完成する

Cloudflare Walletsは単体の機能ではなく、Cloudflareが構築を進めるエージェント向け商取引（agentic commerce）の両面市場の片翼です。

売り手側：2026年7月1日発表の「Monetization Gateway」。Cloudflare配下のサイトやAPIが、WAFルールと同じ記述方法で「このリソースはいくらで売る」という価格ルールを設定し、世界330以上の都市のエッジでx402決済を処理する。未払いのリクエストはオリジンサーバーに届かない
買い手側：今回の「Cloudflare Wallets」。エージェントが上限内で自律的に支払う手段を提供する

売り手が値付けし、買い手が支払う——この両方が揃うことで、人間のチェックアウト画面を介さない「ヘッドレスなマーケットプレイス」が理屈のうえでは成立します。Cloudflareは世界のWebトラフィックの約2割を扱うため、売り手側の裾野を一気に広げられる立場にあり、そこが単なる決済スタートアップとの違いです。

冷静に見る：インフラ先行で、実需はこれから

一方で、現時点の実態は「インフラの完成」であって「市場の立ち上がり」ではない点も押さえておくべきです。

x402の取引量の大半は実需ではなく試験的な少額送金（シグナリング）で、実際の商取引は日次数万ドル規模にとどまるという分析があります
消費者調査では「AIに購買の実行を任せられる」と答えた人は14%程度という報告もあり、信頼の獲得はこれからです
Cloudflare Wallets自体も、現在できるのはcloudflare.payハンドルの取得申請までで、API経由のVirtual Wallet提供は「近日中」、売り手側のMonetization Gatewayも待機リスト段階です

「エージェントが予算を持てるようになった。次の問いは、その予算で買う価値のあるものが揃うか」——これが現在地です。

実務への示唆：いま何を準備すべきか

日本企業の実務目線では、すぐに何かを導入する段階ではありませんが、次の3点は押さえておく価値があります。

API・コンテンツを売る側の企業：エージェントからのアクセスを「ブロックすべきボット」と「支払い能力のある顧客」に分けて扱う発想への転換が始まっています。自社のAPIやコンテンツを従量で売る場合の値付けを考えておくと、対応が早くなります
エージェントを業務に組み込む側の企業：「エージェントに予算を委任し、上限とレビューで統制する」という管理モデルは、決済に限らずエージェント運用全般の統制設計の参考になります。権限は本体のプロンプトではなく、外側のレイヤーで縛るのが原則です
標準の動向：x402はLinux Foundation傘下で標準化が進み、Cloudflare・AWSの両エッジ大手が実装済みです。エージェント間決済の標準争いは、現時点でx402が最有力とみて追いかけるのが効率的です