Cloudflare Wallets: エージェント型インターネットのためのプログラマブルウォレット

今日、AIエージェントが新しいAPIを試すことは困難です。多くの場合、人間向けに設計されたログインページをナビゲートし、人間に追加の支払い方法の登録を依頼し、APIキーを生成してからAPIの呼び出し方法を理解する必要があります。このフローは、エージェントにとって2つの理由で非常に困難です。エージェントはAPIにサインアップするための安定した識別子を持たず、APIの支払いをネイティブに行う方法もありません。これらのものが欠けているため、ソフトウェアへのオンボーディングに苦労することが多く、エージェント型コマースの成長を制限しています。AIエージェントはこれらのタスクを完全に断念し、登録、支払い方法、APIキー生成を人間に戻すことがよくあります。これにより、エージェントが多くのAPIを試したり比較したりすることが非常に困難になります。 これを解決するために、Cloudflare Walletsを作成しました。本日より、アカウント用のCloudflare Walletハンドルを請求できるようになります。これにより、マーチャントとの連携をより良くするためのユニークなユーザー名が提供されます。まもなく、Cloudflare Walletを設定・使用して、APIやコンテンツの支払いが可能になります。 今月初め、Cloudflareは顧客がウェブサイトやアプリケーションから収益を得るのを支援するMonetization Gatewayを発表しました。Monetization Gatewayは、HTTPリクエストに支払いを含めることができるx402プロトコルを使用したマイクロペイメントをサポートします。これらのマイクロペイメントは、AI推論からデータ、コンテンツまで、さまざまな用途の支払いに使用できます。Monetization Gatewayやその他のx402互換エンドポイントの背後にあるサービスを支払う、または支払いを受けるには、ウォレットが必要です。Cloudflare Walletsを使用すると、ステーブルコインを保管し、サービスを購入し、ウェブ全体で資金を受け取ることができます。ウォレットを持つ各アカウントは、エージェントがAPI、MCPツール、コンテンツなどを購入できるように、仮想ウォレットを作成することもできます。仮想ウォレットのガードレール（許容額、許可リスト、最大トランザクションサイズなど）を設定できるため、エージェントがアカウントから安全にお金を支出できるようになります。これにより、エージェントは低摩擦かつ管理されたリスクで多くのAPIを試すことができます。ウォレットユーザーはCloudflare Walletハンドルを共有するオプションがあり、マーチャントとのやり取りで安定したIDを提供できます。 二者間エージェント型市場の構築 CloudflareのMonetization Gatewayにより、適格なCloudflare顧客は、リソース（コンテンツやAPIなど）をエージェント型のバイヤーにヘッドレスで販売できるようになります。しかし、その市場が真に発展するためには、エージェントが機械ネイティブな方法でマーチャントから購入するためのツールが必要です。WalletsはCloudflareのAgents SDKに別のツールを追加し、AIエージェントがマイクロペイメントを使用して必要なAPIやコンテンツを簡単に購入できるようにします。 Cloudflare Walletsには2種類あります。アカウントウォレットと仮想ウォレットです。 アカウントウォレットは、Cloudflareアカウントのオーナーおよびユーザーである人間向けに設計されています。これらは、資金の追加、エージェントが管理する仮想ウォレットへの支出の委任、必要に応じた資金の引き出しが可能です。対照的に、仮想ウォレットはエージェント向けに設計されており、APIキーを介して動作します。仮想ウォレット内では、エージェントは権限に従って資金を支出できます。その最大支出額は、アカウントウォレットのオーナーによって設定された制限によって上限が定められます。このフレームワークは、エージェントに継続的な手動承認なしにユーザーの代わりに自由に行動する能力を与えつつ、エージェントの過剰支出能力を制限します。 探求の自由 仮想ウォレットは、エージェントが得意なこと、つまり数十または数百のサービスを探索して特定のユースケースに最適なものを見つけることができるため、エキサイティングです。x402を介したステーブルコインのマイクロペイメントにより、アカウントなしでAPIを簡単に試すことができ、エージェントはほとんど摩擦なく新しいオプションをテストできます。仮想ウォレットの支出上限は、人間が安全な支出制限内でエージェントが自律的に探索できるように設計されています。これらの制限は制約のように見えるかもしれませんが、直感に反してエージェントにより多くの自由を与えます。エージェントが10ドルの責任を持つ場合、1,000ドルの責任を持つ場合よりも支出について心配することが少なくなります。APIの試用が数セントしかかからない場合、10ドルは多くのオプションを追求し評価するには十分です。 あなたまたはあなたのアカウントが使用するAPIを選択したら、アカウントウォレットで設定したポリシーが仮想ウォレットのコスト制御として機能します。AI推論のために、すべての従業員に週100ドルの予算を与えたいですか？適切な残高を持つアカウントウォレットをプロビジョニングし、そのルールで各従業員に仮想ウォレットを作成するだけです。仮想ウォレットの制限を超えた人は誰でも、アカウントウォレットの変更を許可された人間から手動オーバーライドをリクエストできます。 アカウントウォレットが、毎日アクティブな監視を必要としない、柔軟でありながら確実な支出ポリシーを簡単に設定できるようにしたいと考えています。異常なことが発生した場合、例えば予期せぬ急速な支出など、人間がレビューしてすべてが意図通りに動作しているかを確認できるようになります。支出が意図的であった場合、アカウントウォレットの管理者は制限を引き上げたり、一度限りの資金注入を承認したりできます。支出が意図的でなかった場合、仮想ウォレットへの資金追加の支出ポリシーは、上限を課すことでその役割を果たしました。 これらのウォレットの資金調達と使用を可能な限り容易にするために取り組んでいます。サポートされている地域内での資金のオンランプとオフランプの簡単な方法から始め、適格なユーザーにはステーブルコインによる自己資金調達を代替手段として提供します。インターネットが一夜にして完全に移行することはありませんが、ウェブトラフィックの大部分が現在ボットによって駆動されているため、エージェントとマーチャントにエージェント型コマースのためのファーストクラスのツールを提供できることを楽しみにしています。 支払いだけにとどまらない 人間がエージェントにサービスを簡単に売買する権限を委任できるようにすることは、役立つ出発点です。しかし、マーチャントがエージェントとやり取りする際に、この委任は必ずしも明白ではありません。今日、エージェントがあなたのウェブサイトに来た場合、エージェントが個人または組織の代わりに活動しているにもかかわらず、ユーザーとしての彼らについてほとんど知らないかもしれません。この帰属の欠如は、多くの従来のウェブビジネスモデルに課題をもたらします。人間に1週間の無料トライアルやサインアップクレジットを与えるのは簡単です。安定したIDを持たず、1人の人間が管理下で数十のエージェントを起動できるエージェントに、これらの同じ特典を与えるのは困難です。 cloudflare.payを介してウォレットをCloudflareアカウントにリンクすることで、この問題を解決します。cloudflare.payにより、エージェントはオプションで自分自身を識別できるようになります。なぜなら、彼らのIDはアカウントの委任だからです。リサーチエージェントはresearch.example.cloudflare.payで動作し、マーチャントはそれが特定の組織のエージェントであることを知ることができます。このアプローチにより、エージェントは一貫した永続的なIDを維持できるようになり、すべての関係者にとってエクスペリエンスが向上します。エージェントがIDを宣言するかどうかは完全にオプションであり、ビジネスが既知のエージェントとの取引を優先したいかどうかを決定することになります。 エージェント識別子は人間が読めるべきです エージェントに対処するためのアプローチは、VPNに対処するためのアプローチに似ていると考えています。もし誰かが識別されていない場合、それは本質的に信頼できないわけではありませんが、彼らは自分自身をもっと証明する必要があります。だからこそ、Bot Management内でボットを検出するためのTurnstileなどのイニシアチブがあります。私たちのIDプリミティブは、この以前の作業の上に構築されます。例えば、Web Bot Authはすでにエージェントがキーペアを介してIDを登録できるようにしています。Cloudflare Walletsに添付されたIDにより、このキーペアは人間が読めるようになります。 エージェント型IDの標準は急速に変化していることを知っているため、アプローチをシンプルに保ちたいと考えました。DNSで使用されるURLとIPアドレスのペアリングに似た、あまり読めないキーペアの人間が読める識別子を提案しています。特定のスキーマやその他の検証システムを定義しようとしているわけではありません。IDを覚えやすく、宣言しやすいものにしたいだけです。エージェント型IDをリッチにするためのスキーマが開発されるにつれて