AIエージェントは今、x402とHTTP 402のおかげで自律的に支払うことができます

1997年1月です。 THE (インターネット・エンジニアリング・タスク・フォーラム) Just Released 正式に定義 この仕様は、Web Pioneersによって作成されました。 で、 で、 で、 そして、 インターネットがどのようにコミュニケーションするかを形作った建築家。 IETF RFC 2068 HTTP/1.1 ロイ・フィールディング ジム・ゲティス ジェフリー・モグール ヘンリー・フライスティック ティム・バーナーズ・リー IETF RFC 2068 ロイ・フィールディング ジム・ゲティス ジェフリー・モグール ヘンリー・フライスティック ティム・バーナーズ・リー 仕様導入 以前は、すべての HTTP リクエストに新しい TCP 接続が必要でした. Persistent connections solve this, allowing multiple HTTP requests to flow through a single, long-lived TCP connection. No more establishing separate connections for every image, CSS file, or JavaScript snippet on a web page. 以前は、すべての HTTP リクエストに新しい TCP 接続が必要でした。 persistent connections There is also Web サーバーがコンテンツをストリーミングするための新しい方法は、完全なサイズを事前に知ることなく、もはやサーバーが動的に生成されたコンテンツの総サイズを事前に計算する必要はありません。 chunked transfer encoding しかし 新しいステータスコード: RFC 2068 quietly introduces something intriguing HTTP 402 Payment Required This code is reserved for future use. これは、世界のウェブの創設者の父親が、お金が最終的にインターネットの大きな部分になる方法を予測したことを示しています。 . even if they had no clear path on how it would actually play out 今日、2025年、およそ30年後、複数のHTTPバージョン( 2015年、 2022年、 フィンテックの革命、オンライン決済の増加、インターネット取引に基づく経済全体にもかかわらず、誰もそれをどうするか分からなかった。 HTTP/2 HTTP/3 Status Code 402 still sits there with the exact same note: 'reserved for future use.' Until now. 先月(2025年5月) 解放 提供するオープンソースプロトコル 最初の本物の仕事:ネイティブを可能にする HTTPリクエスト内での支払い コインベース x402 HTTP 402 onchain 今日、エージェントは作る必要がある。 (機械対機械) 支払いは、削減された Web を通じて (ヒューマン・イン・ザ・ループ)介入ですが、伝統的な支払いフローはこの場合うまく機能しません。それらは、AIエージェントが自動的に取引を行う必要があるときに単に動作しない複数の人間の相互作用、リダイレクト、および手動のステップを必要とします。 M2M HITL これは、HTTPプロトコル内でネイティブに実装された自動オンチェーン支払いフローを提案します。 . x402 making them as seamless as any other web request しかし、これは実際にはどう見えるのでしょうか。 アーキテクチャとコンポーネント of x402 x402 4つのコアコンポーネントを中心に構築されています。 x402 ♪ A 支払いイニシエーターとして機能し、アクセスに必要なものを発見し、適切な支払いパイロットを構築します。単純に言えば、これは、HTTPリクエストを有料のリソースに変換するものです。これは、プレミアムコンテンツのリクエストを作成するブラウザ、AIエージェントの購入APIアクセス、またはモバイルアプリのロック解除機能かもしれません。クライアントは、ユーザーのプライベートキーを使用して暗号署名を処理し、支払いが必要なときにリクエストを自動的にリリースします。 client THE コアビジネス論理に焦点を当てながら、エンドポイントの支払いポリシーを執行します. これは、購入されているコンテンツまたはサービスをホストするWebサーバーまたはAPIです. それはコストにエンドポイントをマッピングするシンプルな価格表を維持します。 resource server ブロックチェーン論理は、 コンポーネント:暗号署名の検証、ノンセ・トラッキングを通じて再生攻撃を防止し、実際のチェーン決済を管理する。 facilitator は 最終的な決済層に位置し、支払いが不変で透明であることを保証し、スマートコントラクトやstableコインを通じてプログラマブルな資金を可能にする。 . blockchain but its complexity is completely hidden from the application layer by the facilitator : Client 主な責任:支払い開始 Key Features:EIP-712 署名、自動リトリ、支払い発見 It does: Makes requests, handles wallets, retries with payment. それは何をしますか? リクエストを作成し、財布を処理します。 : Resource Server 主な責任:支払い執行 Key Features: 価格表、HTTP 402 応答、ミドルウェア統合 何をしているか:価格を設定し、支払いをチェックし、コンテンツを提供します。 : Facilitator 主な責任:支払い確認 Key Features: 署名検証、ノンセ・トラッキング、ガス抽象化 それは何をしているのか:署名を検証し、ブロックチェーンに話す : Blockchain 主な責任:支払い決済 Key Features:USDC移転、スマートコントラクト、不変レコード What it does: チェーンで支払いを決める 原則 このアーキテクチャは、いくつかの基本的なソフトウェアエンジニアリング原則を示しています。 それぞれの構成要素には、単一で明確に定義された責任があります。 . separation of concerns Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction 制度が達成 コンポーネントは標準化された HTTP および REST インターフェイスを介してのみ相互作用する。 この孤立化は、コンポーネントを交換できることを意味します(例えば、別のブロックチェーンを使用し、ファシリテータープロバイダーを変更したり、サーバーの論理を変更したり) システムの残りの部分に影響を与えずに。 loose coupling A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementation The facilitator embodies the すべてのブロックチェーンの複雑さを一つの専門サービスに分離することで、支払い論理がビジネスアプリケーションに漏洩するのを防ぎ、懸念を適切に分離させます。 single responsibility principle 最後に、このアーキテクチャは、 高レベルのコンポーネントは、具体的な実装よりも抽象的な実装に依存します。サーバーとクライアントは、特定のブロックチェーンAPIではなく、HTTPインターフェイスに依存します。 dependency inversion 支払流 AI エージェントまたはユーザーがヒットした場合 -enabled API, here is the four-step flow that happens. -enabled API, here is the four-step flow that happens. -enabled API, here is the four-step flow that happens: x402 初期リクエスト:クライアントは、一部のリソースにアクセスするための標準の HTTP リクエストを作成します。 Payment Required Answer: If no payment is attached, the server responds with HTTP 402 and includes payment details. 支払いが必要な回答 : 支払いが添付されない場合は、サーバーがHTTP 402で応答し、支払い詳細を含みます。 支払い認可 : クライアントは暗号化署名された支払いを作成し、要求をリリースします。 検証とアクセス:サーバーは支払いを検証し、それをブロックチェーンに送信し、アクセスを与えます。 これを強力なものにするのは、すべてHTTPプロトコルレベルで起こることです. No redirect to third-party payment processors, no フローなし、アカウント作成なし。 OAuth Just standard HTTP with extra headers: X-PAYMENT はクライアントからサーバーに流れ、署名済みの支払い負荷を含み、支払い詳細(金額、受領者、トークン)と、クライアントが支払いを承認したことを証明する暗号署名を含む。 flows from server to client after successful payment and contains , providing transparency about what happened on-chain. X-PAYMENT-RESPONSE transaction receipt information ♪ サーバー側の実装 支払いミドルウェアアーキテクチャ The core server-side implementation revolves around a payment filter (AKA middle-ware) that intercepts HTTP requests and enforces payment requirements. When integrated into your web server, this middle-ware checks incoming requests against a price table that maps endpoints to their costs. ミドルウェアは、単純な決定の木に従う:要求が支払いなしに保護されたエンドポイントに到達した場合、それは対応します。 詳細な支払い手順. 支払いが含まれている場合 ヘッダーは、要求を進めることを許可する前に、ファシリテーターサービスで支払いを確認します。 HTTP 402 X-PAYMENT 以下はJava実装の基本構造です。 public class PaymentFilter implements Filter { private final String payTo; private final Map priceTable; // path → amount private final FacilitatorClient facilitator; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String path = req.getRequestURI(); String paymentHeader = req.getHeader("X-PAYMENT"); if (!priceTable.containsKey(path)) { chain.doFilter(request, response); // Free endpoint return; } if (paymentHeader == null) { send402Response(resp, path); // Request payment return; } // Verify payment, process request, then settle VerificationResponse verification = facilitator.verify(paymentHeader, requirements); if (verification.valid) { chain.doFilter(request, response); facilitator.settle(paymentHeader, requirements); } } } あなたは単に支払いフィルターをあなたの中間品ステックに追加し、どのエンドポイントが支払いを必要とするかを定義します。 The beauty of this approach is that it requires minimal changes to existing applications. 応答 PaymentRequirements クライアントが支払いなしで保護されたエンドポイントに到達すると、サーバは詳細な支払い要件オブジェクトを構築します。 )、受信財布のアドレス、ブロックチェーンネットワーク、および再生攻撃を防ぐための有効期限。 USDC private void send402Response(HttpServletResponse response, String path) throws IOException { response.setStatus(HttpStatus.PAYMENT_REQUIRED); response.setContentType("application/json"); PaymentRequirements requirements = PaymentRequirements.builder() .paymentRequirement(List.of( PaymentRequirement.builder() .kind(new Kind("exact", "base-sepolia")) // Payment scheme + blockchain network .receiver(payTo) // Wallet address to receive payment .amount(priceTable.get(path)) // Cost for this specific endpoint .asset(" ") // USDC token contract .expiry(Instant.now().plus(Duration.ofMinutes(5))) // Payment window .nonce(UUID.randomUUID().toString()) // One-time use identifier .build() )) .build(); response.getWriter().write(Json.MAPPER.writeValueAsString(requirements)); } それぞれのフィールドで、 以下のように記述されている。 PaymentRequirements 種類:支払いスケジュール(固定金額のための正確)とターゲットブロックチェーンネットワーク(Base-sepolia for Base testnet)を定義します。 受信者: 支払いが送られる財布のアドレス. これは、資金を受け取るあなたのビジネス財布です。 金額:この特定のエンドポイントにアクセスするためのコストは、あなたの価格表から取得されます. USDC の場合、これは通常 wei (最小単位) で表されます。 資産: 支払に使用するトークンのスマート契約アドレス. 例では、Base Sepolia testnet で USDC を示しています。 期限切れ:この支払い要件が無効になる後のタイムスタンプで、古い支払い要請が再利用されるのを防ぎ、再生攻撃に対するセキュリティを追加します。 nonce: 各支払い要件を確保するユニークな識別子(UUID)は、同じクライアントが同じエンドポイントに複数のリクエストを提出する場合でも、一度だけ満たされることができます。 クライアント側の実装 自動決済手続き クライアント ライブラリは、標準の HTTP クライアントを包装して、402 応答を自動的に処理します。クライアントが支払い要請を受け取るとき、(1)クライアントは支払い有効負荷を構築し、(2)ユーザのプライベート キーで署名し、 (3)付属の支払いで元の要請をリリースします。 public HttpResponse makeRequest(String url, String method) throws Exception { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .build(); HttpResponse response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); // Handle 402 Payment Required if (response.statusCode() == 402) { PaymentRequirements requirements = Json.MAPPER.readValue( response.body(), PaymentRequirements.class); // Create payment payload matching the requirements PaymentPayload payment = PaymentPayload.builder() .receiver(requirements.getPaymentRequirement().get(0).getReceiver()) .amount(requirements.getPaymentRequirement().get(0).getAmount()) .asset(requirements.getPaymentRequirement().get(0).getAsset()) .nonce(requirements.getPaymentRequirement().get(0).getNonce()) .expiry(requirements.getPaymentRequirement().get(0).getExpiry()) .build(); // Sign using EIP-712 structured data signing String signature = signer.sign(payment.toSigningMap()); // Retry with payment header String paymentHeader = encodePaymentHeader(payment, signature); HttpRequest paidRequest = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .header("X-PAYMENT", paymentHeader) .build(); return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString()); } return response; } 署名プロセスは、The ハッシュ化と署名の前に、支払いデータの構造化された、人間が読める表示を作成する標準で、これは支払いが暗号的に安全であり、特定の要請に結びついていることを保証します。 EIP-712 支払い流れの確認 統合の促進者 Facilitator サービスは、ブロックチェーンの複雑さが存在し、クライアントとサーバーの両方から抽象化します. When a server receives a payment, it forward the payment payload to the facilitator for verification. public class HttpFacilitatorClient implements FacilitatorClient { private final HttpClient http; private final String baseUrl; @Override public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) throws Exception { // Construct verification request with payment and requirements VerifyRequest body = VerifyRequest.builder() .paymentHeader(paymentHeader) // The X-PAYMENT header from client .requirements(requirements) // What the server expects .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/verify")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, VerificationResponse.class); } @Override public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) throws Exception { // Settlement happens after successful verification SettleRequest body = SettleRequest.builder() .paymentHeader(paymentHeader) .requirements(requirements) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/settle")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, SettlementResponse.class); } } ファシメーターはいくつかのことをチェックします: 署名は有効ですか? Does the payment amount match the requirements? この支払いは以前使われていたのでしょうか。 支払い期限はまだ終了ウィンドウ内にありますか? 検証が通過した場合、ファシメーターはまた、取引を選択したブロックチェーンに送信することによって決済を処理します。 インターフェイスは、あらゆるファシリテータークライアントが実装しなければならない契約を定義します。 FacilitatorClient public interface FacilitatorClient { VerificationResponse verify(String paymentHeader, PaymentRequirements requirements); SettlementResponse settle(String paymentHeader, PaymentRequirements requirements); } あなたのアプリケーションは、このインターフェースの具体的な実装を提供する必要があります。 統合の例 個々のコンポーネント(支払いフィルター、ファシリテーターの統合、クライアントの取り扱い)を見た今、これらのパーツが実際のアプリケーションでどのように組み合わされるかを見てみましょう。 example that demonstrates the complete flow. Spring Boot まず、Aを作る。 注記: @PaymentRequired @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface PaymentRequired { String price(); String currency() default "USDC"; String network() default "base-sepolia"; } その後、改造。 スタートアップでこれらの注釈をスキャンするには: PaymentFilter @Component public class PaymentFilter implements Filter { private final Map priceTable; private final String payTo; private final FacilitatorClient facilitator; public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) { this.payTo = payTo; this.facilitator = facilitator; this.priceTable = buildPriceTableFromAnnotations(context); } private Map buildPriceTableFromAnnotations(ApplicationContext context) { Map prices = new HashMap<>(); // Scan all @RestController beans for @PaymentRequired annotations Map controllers = context.getBeansWithAnnotation(RestController.class); for (Object controller : controllers.values()) { Method[] methods = controller.getClass().getMethods(); for (Method method : methods) { PaymentRequired payment = method.getAnnotation(PaymentRequired.class); if (payment != null) { String path = extractPathFromMapping(method); BigInteger amount = new BigInteger(payment.price().replace(".", "")); prices.put(path, amount); } } } return prices; } } 現在、コントローラーの方法を直接注釈できます: @RestController public class WeatherController { @GetMapping("/weather") @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia") public WeatherData getWeather(@RequestParam String city) { // Your existing business logic return weatherService.getWeatherForCity(city); } @GetMapping("/premium-forecast") @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia") public ExtendedForecast getPremiumForecast(@RequestParam String city) { return weatherService.getExtendedForecast(city); } } @Configuration public class PaymentConfig { @Bean public PaymentFilter paymentFilter(ApplicationContext context) { return new PaymentFilter( context, " ", // Your wallet address new HttpFacilitatorClient(" ") ); } @Bean public FilterRegistrationBean paymentFilterRegistration(PaymentFilter filter) { FilterRegistrationBean registration = new FilterRegistrationBean<>(); registration.setFilter(filter); registration.addUrlPatterns("/*"); registration.setOrder(1); return registration; } } THE annotation handles pricing configuration declaratively. annotation handles pricing configuration declaratively. annotation handles price configuration declaratively. スタートアップ時にこれらの注釈を自動的に発見し、価格表を構築します。 コントローラーの方法における既存のビジネス論理は完全に変更されません。 構成は、支払いフィルターを登録し、ファシリターサービスに接続することによってすべてを結びつける。 コスト 0.001 USDC 料金は 0.01 USDC で、すべての支払い処理は HTTP レイヤーで透明に行われます。 @PaymentRequired PaymentFilter /weather /premium-forecast 安全と生産の考慮事項 シンプルでエレガントで、複雑さを隠しています. これはプロとコンです. 統合を容易にしますが、重要な側面も隠しています: . x402 putting AI agents in charge of money creates new attack vectors たとえ サインとノンセの管理は再生攻撃を扱うが、エージェントが脅かされるとどうなるのか? 従来の詐欺検出は人間の行動パターンに依存するが、 妥協したエージェントは、いかなる人間の詐欺師よりも速く資金を流すことができます。 EIP-712 AI agents don't follow human spending habits Facilitator コンポーネントは、署名を検証し、ノンセスを管理しているため、もう一つの高価値のターゲットとなっています。 . blockchain settlements are final 以来 チェーン上の取引に基づき、ブロックチェーン取引の運用リスクを相続します。ガス料金は激しく変動し、時にはマイクロ支払いを経済的に不便にすることもあります。ネットワークの渋滞は取引を遅らせることができます。 x402 もう一つの重要な側面は規制です。規制の遵守は、自動化された支払い、暗号通貨の使用、およびデータ保存に関する異なる規則で、管轄区域によって異なります。 国境を越えて大量のマイクロトランザクションを行うAIエージェントは、AML警告を引き起こしたり、現地の規制に違反したりすることがあります。 次は何 何がおもしろいか AIエージェントは自主的な支払い能力を必要とし、stablecoinsはプログラミング可能なマネー層を提供し、ブロックチェーンインフラストラクチャはスケーラブルなアプリケーションを処理するのに十分に成熟している。 x402 プラグマティックなアプローチのおかげで、現存するHTTPインフラストラクチャを再発明するのではなく、既存のHTTPインフラストラクチャを拡張しています。 x402 セキュリティと運用上の課題は現実的ですが、それらは可能な解決策を持つエンジニアリングの問題です。 約30年後、 ようやくその目的を果たすことができる:インターネット上で物の支払いを要求するのと同じくらい簡単にする。 HTTP 402 The foundation is set. Now it's time to build. ありがとう エリック・レッペル ロニー・カッパーズ ケヴィン・レフウ ダニー・オーガンとチーム全員が コインベース このプロトコルをオープンソースするために。 エリック・レッペル ロニー・カッパーズ ケヴィン・レフ ダニー・オーガン コインベース . ありがとう エリック・レッペル そして ユガ・コーラー 見直しのために 私の貢献 2位 x402 エリック・レッペル ユガ・コーラー 私の貢献 リソース & Further Reading HTTP 402 Payment Required - RFC 2068 - 1997 オリジナル HTTP 仕様 x402 プロトコル仕様 - 公式プロトコル文書 x402 GitHub Repository - Coinbaseのオープンソース実装 - The PR that introduced the Java implementation of the protocol x402 Java implementation EIP-712:Ethereum Typed Structured Data Hashing and Signing - x402で使用される署名規格 Base Network Documentation - Layer 2 ブロックチェーン プラットフォーム 例で使用 USDCドキュメント - USD Coin stablecoin契約の詳細 Spring Boot Filter Documentation - Java Middleware Implementation Java HTTP Client API - クライアント側の HTTP 処理 Machine-to-Machine (M2M) Communication Standards - 自動システム通信 Autonomous AI Agent Architectures - AI Agent Design Patternsに関する研究 Google Approach to Secure AI Agents - Google proposals of a secure, human-guided AI agent framework セキュアなAIエージェントへのGoogleアプローチ