Cloudflare Walletsとは AIエージェントに支出をどこまで任せるか

「この先は有料です」でエージェントが止まる。

調べさせた仕事が支払いの一歩手前で人間の承認待ちになる場面は、もう珍しくありません。

Cloudflareが2026年8月4日に発表した Cloudflare Wallets はそこを埋める製品ですが、読みどころは決済手段が増えたことではなく、「いくらまで使わせるか」を設定値で縛る仕組みが最初から付いてきたことです。

Cloudflare Walletsとは 人の口座とエージェントの口座を分ける

構造は単純で、口座を2階建てにしただけです。

要点は下の2行に集約されます。

エージェントは払えるけれど、原資を自分では増やせない。

法人カードと、用途を絞って発行するバーチャルカードの関係に近いですね。

カードの枚数がいくら増えても、口座を握っているのは人のままです。

位置づけとしては Cloudflare Agents SDK に追加される新機能で、買える対象はAPI、MCPツール、コンテンツ。

資金はステーブルコインで保持します。

Cloudflare Walletsを発表：エージェント型インターネットのためのプログラム可能なウォレット

Cloudflare Walletsは、AIエージェントにWeb上で利用できるネイティブな決済機能と、検証可能なデジタルIDを提供します。x402プロトコルを利用することで、エージェントはあらかじめ設定された安全な利用制限の範囲内で、APIやコンテンツを自律的に購入できます。

blog.cloudflare.com

売り手は先にできていた 買い手がいなかった

APIやコンテンツを売る側の仕組みは、x402プロトコル対応として先に出ていました。

HTTPのやり取りに支払いを埋め込む規格で、有料エンドポイントを立てる道はすでに用意されていた。

欠けていたのは買う側です。

売り場は立ったのに、財布を持った客がいない状態が続いていました。

今回埋まったのがその反対側で、エージェント側にウォレットが付き、x402で払える相手なら自律的に買えるようになる。

プロダクトに関わる立場で意味が変わるのはここからです。

「技術的には可能」と「社内で通せる」のあいだには、だいたい上限設定と承認フローの有無という距離があります。

規格が製品になるというのは、その距離が縮むということです。

3つの上限が社内ルールの代わりになる

Virtual Wallet に設定できるのは3つです。

1. 利用可能な予算
2. 利用を許可する販売先のリスト
3. 1回あたりの最大利用金額

公式が挙げている例が「従業員全員にAI推論用として週100ドルまでの予算を設定」というもの。

日本円で週1.5万円ほどの枠を、全員に配るイメージです。

上限を超えた支払いは通りません。

エージェントは Account Wallet を管理する権限を持つ人に、上限の変更か追加資金を申請する形になります。

人間の承認を挟む動線が、製品側に最初から埋まっている。

「AIに勝手に課金させない」を文章のルールとして配ると、だいたい形骸化します。

読まれない、解釈がぶれる、例外が積み上がる。

設定値は解釈がぶれません。

超えたら止まる、それだけです。

分け方もよくできていて、予算が総量を、販売先リストが行き先を、1回あたりの上限が事故1件の大きさを抑えます。

暴走1回で溶ける金額を、月の総枠とは別に縛れる。

もう1つ、Cloudflare Walletハンドルという識別子があります。

research.example.cloudflare.pay のような形で、売り手は相手がどの組織のエージェントかを確認できる。

ただし身元を出すかどうかは完全に任意です。

売る側から見ると、与信の材料は「出してくれた相手にだけある」ことになります。

匿名のエージェントにどこまで売るかは、売り手側の判断として残りました。

導入を判断する前に決めておきたいこと

先に前提を書いておくと、まだ本番投入の話ではありません。

現時点でできるのは Cloudflare Wallet ハンドルの取得までで、実際に支払う機能はこれからです。

料金や手数料も公表されていません。

そのうえで、先に片付けておくと動き出しが早くなる論点が3つあります。

1. どの業務のどの金額から任せるか

いきなり基幹の仕入れにつなぐ話ではありません。

候補になるのは、月に数千円で収まる従量課金APIを叩く調査系の仕事です。

データ取得、要約、外部ツールの単発利用。

失敗しても金額で殴られない領域から、上限の効き方を確かめる順番になります。

2. 事故ったとき誰が責任を持つか

この構造だと、責任は上限を設定した人に寄ります。

エージェントは与えられた枠の中で動いただけなので、枠が広すぎたなら設定した側の判断ということになる。

曖昧なまま配ると、後から「誰が承認したのか」を探す時間が生まれます。

Account Wallet を誰が持ち、誰が上限変更を承認するのか。

技術検証より先に決まっていたほうがいい部分です。

3. ステーブルコインを自社が扱えるか

資金はステーブルコインで持ちます。

法定通貨での入出金は、対応地域から順次提供する予定という段階です。

開発チームだけで判断できる話ではありません。

経理と財務に「うちはこれを保有できるのか」を確認するところからで、会社によってはここが一番時間を食います。

技術検証を始める前に投げておく質問ですね。

決めるのは金額ではなく権限の置き場所

この製品を決済手段として見ると、たぶん判断を間違えます。

新しく決められるようになったのは支払い方法ではなく、権限の置き場所です。

総額はいくらか、行き先はどこまでか、1回の上限はいくらか。

この3つをどこに置くかで、エージェントに任せられる仕事の範囲がそのまま決まります。

一度、自社のエージェントが今どこで止まっているかを見てみるといいと思います。

判断ができなくて止まっているのか、権限がなくて止まっているのか、単に払う手段がなくて止まっているのか。

3番目だけなら、この流れで近いうちに解けます。

そのとき次に来る問いが「いくらまで許すか」で、これは製品が決めてくれません。