2026.07.14

AIエージェントが自分でお金を払う時代の“配管” ── x402決済プロトコルの仕組みと実装

こんにちは、グループ研究開発本部 AI研究開発室のK.S.です。

2026年に入り、CloudflareがAIクローラー向けの従量課金システム「Monetization Gateway」を発表し、Visaが「約3年で決済から人間が消える」という見通しを示すなど、AIエージェントが自律的にお金を払う世界の話題が一気に現実味を帯びてきました。その多くの根っこにあるのが、本記事のテーマである決済プロトコル「x402」です。

世間の関心は「AIクローラーからコンテンツをどう守るか（＝壁）」に集まりがちですが、同じ仕組みは裏返せば「AIにどう買ってもらうか（＝レジ）」でもあります。まずx402というプロトコルの中身を解剖し、次にそれを実際に動く「途中から有料」記事APIとして実装、最後にx402をめぐる業界の動き（誰が主導し、AP2やコマース層とどう噛み合うのか）まで解説できたらと思います。

背景：Webトラフィックの多くが、もう人間ではない

x402が「なぜ今か」は、Webに流れるトラフィックの中身を見るとよく分かります。Cloudflareの計測によれば、検証済みボットのトラフィックのうちAIクローラーが約2割（2026年5月時点で20.3%）を占め、AI検索ボットがさらに6.5%を上乗せしています。

参考までに、あのGooglebot単体でも全HTMLリクエストの約4.5%です。AIボットの巡回はいまやWebの主要な負荷要因の一つで、しかもその約8割はモデルの学習目的のクロールと見られています。

別の計測でも傾向は同じで、Akamaiは直近1年でAI由来のボットトラフィックが約300%増加し、コマース領域だけでも2か月間に250億件を超えるAIボットのリクエストを観測したと報告しています。

問題は量だけではありません。従来の検索エンジンは「クロールする代わりに、検索結果から人間を送り返してくれる」関係でした。ところがAIクローラーはコンテンツを取り込む一方で、人をほとんど戻しません。Cloudflareが公表したクロール対リファラ比（crawl-to-refer ratio）が、この非対称性を生々しく示しています（2025年時点）。

事業者	クロール : リファラ	意味
Google	約 14 : 1	約14ページを巡回するごとに、1人のユーザーを送客する。
OpenAI	約 1,700 : 1	約1,700ページを巡回して、1人のユーザーを送客する。
Anthropic	約 73,000 : 1	約73,000ページ以上を巡回して、ようやく1人のユーザーを送客する。

（※ ネイティブアプリ経由のアクセスはRefererを持たないため、これらの比率は実際よりやや高く出ている可能性がある、とCloudflare自身も注記しています。それでも桁の違いは明白です。）

広告やサブスクで成り立ってきたWebにとって、これは「コンテンツは吸われるのに、対価（広告収入につながる訪問者）は返ってこない」状況です。コンテンツ提供者に残された選択肢は長らく「robots.txtでブロックするか、黙って受け入れるか」の二択でしたが、robots.txtは強制力のない紳士協定にすぎません。ここに第三の選択肢 ―― 「HTTPの仕組みに則って、アクセスに対価を求める」を用意しようというのが、x402の出発点です。

x402とは何か

27年間「予約済み」だったステータスコード

HTTPには、1997年から402 Payment Requiredというステータスコードが予約されていました。「いずれWebにネイティブな決済の仕組みが必要になるだろう」という予見のもとに確保された枠ですが、具体的な仕様は長らく定められず、”Reserved for future use”（将来のために予約済み）という注釈とともに眠り続けていました。

x402は、このステータスコードにようやく実装を与えたオープンプロトコルです。2025年5月にCoinbaseが公開し、その後2025年9月にCloudflareと共同で x402 Foundation を立ち上げました。Foundation には Coinbase、Cloudflare、Google、Visa、AWS、Circle、Anthropic、Vercel などが名を連ねており、「一企業の実験」ではなく業界横断の標準を目指す動きになっています。冒頭で触れた Cloudflare の Monetization Gateway も、この x402 を土台にしてAIクローラーへ課金する仕組みです。

設計思想：決済をHTTPの中で完結させる

x402の最大の特徴は、決済をHTTPリクエスト／レスポンスのサイクルの中で完結させることにあります。従来のWeb決済は、アプリのフローからいったん外へ出て、決済代行のページへリダイレクトして戻ってくる「離脱」を伴っていました。x402にはこれがありません。支払いは402レスポンスと、それに応答するヘッダー付きの再リクエストによって、同じHTTPの土俵の上で行われます。

ステートレス：支払い証明はHTTPヘッダーに載る。サーバー側にセッションやアカウントを持つ必要がない
チェーン非依存の抽象化：プロトコル本体は特定のブロックチェーンに縛られず、「scheme（決済方式）」と「network（ネットワーク）」の組み合わせで表現する
ガスレス（クライアント視点）：後述するfacilitatorとEIP-3009により、支払う側はガス代を負担せず、オフチェーン署名だけで済む
ステーブルコイン決済：主にUSDCやEURCを用いる。価格変動リスクを抑え、少額課金（マイクロペイメント）に適する

人間がフォームにカード番号を打ち込む決済は、機械には向きません。エージェントが自律的に、リクエストのフローの中で完結させられる決済 ―― それがx402の狙いです。

プロトコル詳細：402からsettleまで

ここからが本記事の主軸です。x402の決済が「HTTP上で」「オンチェーンの送金まで」どう繋がっているのかを、フィールド名レベルで追っていきます。

登場人物は3者

役割	説明
クライアント	有料リソースを取得したい側。AIエージェントなどが該当し、ウォレット（秘密鍵）を保持して支払いを行う。
リソースサーバー	有料コンテンツやAPIを提供するサーバー。HTTP 402を返して支払いを要求し、決済確認後にリソースを返却する。
ファシリテーター	署名の検証とオンチェーン決済を代行する仲介者。リソースサーバーはブロックチェーンを直接扱う必要がなくなる。

この3者の関係を図にすると、x402の面白さがはっきりします。署名する人（クライアント）とガスを払う人（ファシリテーター）が別で、資金はクライアントからサーバーへ直接移動する ―― この構図が「クライアントはガスレス」「サーバーはノード不要」を同時に成立させています。

図1：x402のアーキテクチャ。署名する人とガスを払う人は別。

全体フロー

図2：402からsettleまでの決済フロー。実線＝リクエスト、破線＝レスポンス。

クライアントが有料エンドポイントに素のGETを投げる
サーバーは402 Payment Requiredを返し、どう払えばよいかをPAYMENT-REQUIREDヘッダーで提示する
クライアントは条件をもとに、ウォレットの秘密鍵で支払い認可の署名を作る（この時点では送金は起きていない）
同じリクエストを、PAYMENT-SIGNATUREヘッダーに署名付きペイロードを載せて再送する
サーバーはファシリテーターのverifyを叩き、署名や残高が正当かを送金前に検証する
検証が通ればsettleを叩き、ファシリテーターがオンチェーンで実際の送金を実行する
決済が確定したら、サーバーは200 OKでリソースを返し、PAYMENT-RESPONSEヘッダーに決済結果（トランザクションハッシュなど）を添える

重要なのは、サーバー自身はブロックチェーンのノードを持つ必要がない点です。署名の検証もオンチェーンの実行もファシリテーターに委譲できます。この分業がx402の実装ハードルを大きく下げています。

3つのHTTPヘッダー

x402で使うヘッダーは3つだけです（利用するSDK／バージョンによりヘッダー名はX-PAYMENT系の場合もあります。本記事は後半の実装で用いる@x402 JavaScript SDKの挙動に合わせています）。

ヘッダー名	方向	タイミング	内容
`PAYMENT-REQUIRED`	サーバー → クライアント	402レスポンス時	価格・支払い先・対応ネットワークなどの支払い条件を通知する。
`PAYMENT-SIGNATURE`	クライアント → サーバー	支払い付きリクエスト時	ウォレットで署名した支払い認可情報を送信する。
`PAYMENT-RESPONSE`	サーバー → クライアント	200レスポンス時	決済完了の証明（トランザクションハッシュなど）を返却する。

各ヘッダーの値はBase64エンコードされたJSONです。これにより、HTTPヘッダーの制約内で構造化データを安全にやり取りできます。

402レスポンスの中身（PAYMENT-REQUIRED）

サーバーが返すPAYMENT-REQUIREDヘッダーをデコードすると、次のようなJSONになります。

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "maxAmountRequired": "10000",
      "resource": "/articles/1/full",
      "description": "有料記事の全文取得（Markdown形式・構造化メタデータ付き）",
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ]
}

注目すべきはacceptsが配列である点です。サーバーは「BaseのUSDCでも、PolygonのUSDCでも受け付けます」といった具合に複数の支払い方法を並べて提示でき、クライアントは自分が扱えるものを選べます。主要フィールドは次のとおりです。

フィールド	意味
`scheme`	決済方式。通常は `exact`（指定額ちょうどを支払う方式）を利用する。
`network`	ネットワーク識別子。CAIP-2形式で指定する（例：`eip155:84532` は Base Sepolia）。
`maxAmountRequired`	支払い金額。トークンの最小単位（atomic units）の文字列で表現する。USDCは小数点以下6桁のため、`"10000"` は 0.01 USDC を表す。
`resource`	支払い対象となるリソース（URLやAPIエンドポイントなど）。
`description`	何に対する支払いなのかを説明する文字列。AIエージェントが購入可否を判断するための重要な情報。
`payTo`	支払いを受け取るウォレットアドレス。
`asset`	支払いに利用するトークンのコントラクトアドレス（例：USDC）。
`maxTimeoutSeconds`	決済完了まで許容する最大時間（秒）。
`extra`	決済方式（scheme）ごとの追加情報。例えばEIP-3009ではトークン名やバージョンなどを含む。

金額を「最小単位の文字列」で持つのは、浮動小数点の丸め誤差を避けるためです。金銭を扱うシステムの定石であり、x402もこれを踏襲しています。なお、フィールド名（maxAmountRequired か amount かなど）はバージョンによって差異があるため、実装時は対象バージョンの仕様書とSDKの実挙動を正としてください。

支払い認可の中身（PAYMENT-SIGNATURE）

クライアントは条件を満たす支払いペイロードを組み立て、Base64エンコードしてPAYMENT-SIGNATUREヘッダーに載せます。デコードするとこうなっています。

{
    "x402Version": 1,
    "scheme": "exact",
    "network": "eip155:84532",
    "payload": {
        "signature": "0x2d6a7588d6acca505cbf0d9a4a227e0c52c6c34008c8e8986a1283259764173608a2ce6496...",
        "authorization": {
            "from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
            "to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
            "value": "10000",
            "validAfter": "1740672089",
            "validBefore": "1740672154",
            "nonce": "0xf3746613c2d920b5fdabc0856f2aeb2d4f88ee6037b8cc5d04a71a4462f13480"
        }
    }
}

payloadの中核が、EIP-3009による支払い認可です。authorizationの各フィールドは次の意味を持ちます。

from：署名者かつ資金の出どころ。支払う側のアドレス
to：受取先。PAYMENT-REQUIREDのpayToと一致する
value：転送額。maxAmountRequiredと一致する（exactなので「ちょうど」）
validAfter / validBefore：この認可が有効な時間窓（Unix timestamp）。期限切れの署名は使えない
nonce：一度きりの使い捨て値。リプレイ攻撃（同じ署名の使い回し）を防ぐ

signatureは、このauthorizationをEIP-712の型付きデータとしてハッシュ化し、秘密鍵で署名したものです。ここがx402の巧妙な点で、クライアントがやっているのは署名の生成だけ。自分でトランザクションをブロックチェーンへ送信（ブロードキャスト）してはいません。「この条件でなら送金してよい」という認可を暗号署名で発行しているだけです。

なぜ「ガスレス」が成立するのか ── EIP-3009

x402のexactスキームの土台にあるのがEIP-3009（transferWithAuthorization）です。

通常のERC-20送金では、送金する本人がトランザクションを発行し、ネイティブトークン（ETHなど）でガス代を払う必要があります。しかしEIP-3009は、「署名による転送認可」と「その認可を使った転送の実行」を分離します。transferWithAuthorization関数は from, to, value, validAfter, validBefore, nonce と署名を受け取り、第三者がこの関数を呼ぶことで from の資金を to へ動かせます。呼び出し者（＝ガスを払う者）と資金の持ち主が別でよい、というのが肝です。

クライアント（AIエージェント）は、ETHを一切持っていなくてもUSDCの署名を作るだけで支払える。ガス代の心配から解放される
ファシリテーターがtransferWithAuthorizationを呼び出し、そのガス代を立て替える

USDCとEURCはこのtransferWithAuthorizationをネイティブに実装しているため、x402のexact EVMスキームと素直にかみ合います。なお、ガスレスを実現する別のアプローチとして、EOAに一時的にコントラクトの振る舞いを持たせるEIP-7702を使う実装もあり、ファシリテーターの実装によってどちらを採るかが分かれます。EIP-3009を実装していないトークンを扱う場合は、Permit2を経由する別パスも用意されています。

ファシリテーターの役割 ── verifyとsettle

x402の設計で最も誤解されやすいのがファシリテーターです。位置づけを改めて整理すると、これはリソースサーバーとブロックチェーンの間に立ち、決済の「検証」と「実行」を代行する存在です。クレジットカードでいう決済代行会社（PSP）に近いのですが、後述するように資金は預かりません。これがあるおかげで、サーバー側はRPCノードもガス用のネイティブトークンも秘密鍵も持たずに、HTTPの世界だけで決済を完結できます。

ファシリテーターは実体としては/verifyと/settleという2つのHTTPエンドポイントを提供します。リソースサーバーは受け取ったPAYMENT-SIGNATUREを、基本的にそのままこのAPIへ転送するだけです。

① verify（検証）── 送金の前に、参照だけで正当性を確かめる

signatureがauthorization.fromのアドレスから復元できるか（＝なりすましでない本人の署名か）
fromのアカウントに、支払うvalue以上のトークン残高があるか
authorizationの各パラメータ（to・value・トークン・ネットワーク・validAfter/validBefore）が、402で提示した要件と一致するか
nonceが未使用か（使い回しの署名でないか）
transferWithAuthorizationをシミュレーション実行し、実際に成功する見込みか

verifyはチェーンの状態を読むだけで、送金トランザクションは発行しません。ガスもかかりません。サーバーはこの結果（isValid）を見て、「このあと課金すれば確実に取れる」と判断してからリソースの準備に進めます。決済を試みる前に成否がほぼ分かる点は、クレジットカードのオーソリ（与信）に似ています。

② settle（実行）── 署名を使って、実際にオンチェーン送金する

検証を通過したら、ファシリテーターがトークンコントラクトのtransferWithAuthorizationを、ペイロード内のsignatureとauthorizationを引数にして呼び出します。このトランザクションを発行するのはファシリテーターであり、ガスを負担するのもファシリテーターです（クライアントは署名しただけ）。完了すると、トランザクションハッシュや確定状況（pending / confirmed）が返り、サーバーはそれをPAYMENT-RESPONSEとしてクライアントへ返します。

なお、verifyが通ってもsettleが失敗することは原理的にあり得ます（検証と実行の間に残高が動く、同じnonceが別経路で先に消費される、など）。そのためsettleの結果は必ず確認し、失敗時はリソースを渡さない実装にします。verifyとsettleが分かれているおかげで、「まずverifyで弾ける分は弾き、settleは本当に必要なものだけ実行する」という制御ができます。

③ そのほかの機能（discovery・付加サービス）

多くのファシリテーターは、この2つに加えて自分がどの「scheme × network」やプロトコルのバージョンに対応しているかを返す照会用のエンドポイント（/supported などと呼ばれる discovery 機能）も備えています。クライアントやサーバーは、これを見て「このファシリテーターはBaseのUSDCを扱えるか」を事前に確認できます。さらに運営者によっては、コアの verify/settle の上に ガスの肩代わり・法定通貨への出金（オフランプ）・KYC/KYT・利用状況の可視化といった付加サービスを載せています。最小コアは共通で、その上に各社が独自の価値を積む ―― という構造です。

信頼境界とセキュリティ ── 「見えるが、盗めない」仲介者

ファシリテーターはノンカストディアル（資金を預からない）です。資金はクライアントのウォレットからサーバーのウォレットへ直接送られ、ファシリテーターの財布を経由しません。しかも、ファシリテーターにできるのは「クライアントが署名した通りの送金」を中継することだけです。署名はto・value・nonce・有効期間で縛られているため、金額を書き換える・別の宛先へ送る・二重に使う、といったことはできません。つまり支払い内容は見えるが、勝手には動かせない仲介者です。とはいえ、落ちれば決済できないという可用性の面と、支払いのメタデータを観測できる面では信頼ポイントになるため、「誰のファシリテーターを使うか」は立派な設計判断です。

誰が運営しているのか ── パーミッションレスな“市場”

/verify・/settle のインターフェースが標準化されているため、ファシリテーターは誰でも運営でき、利用者は自由に選んで差し替えられます。プロトコル自体がパーミッションレスで、「1社が独占する」ものではありません。いまは複数の事業者が競い合う市場になりつつあり、主なものを挙げると次のとおりです。

運営者	形態	特徴
Coinbase（CDP）	ホスト型	最初の本番ファシリテーター。Baseをはじめ複数のEVMチェーンとSolanaに対応。ファシリテーター手数料は無料で、月1,000件までの無料枠があり、まず試す環境として適している。
Cloudflare	エッジ型	Monetization Gatewayの内部で、Cloudflare自身がエッジ上のファシリテーターとして署名検証と決済処理を実施する。
その他多数	ホスト型	BNB Chain向け（Pieverse）、TRON向け（MERX）、SEPA出金対応の欧州向け（AsterPay／MiCA準拠）、超低遅延を特徴とするPrimevなど、チェーン・地域・用途に応じた20以上のサービスが登場している。
自前運用	セルフホスト	Rust実装の `x402-rs` をDockerなどで稼働させ、自社インフラ上で運用できる。手数料、ガス代、KYC/KYTポリシーを自社で柔軟に管理したい企業向け。

選び方の目安はシンプルです。手軽に始めるならホスト型（CDPなど）のURLを指定するだけ。特定チェーンに寄せたい・独自のコンプライアンス（KYC/KYT）を挟みたい・手数料やガスを自分で管理したいなら自前運用。いずれも標準インターフェースなので、あとから乗り換えられます。後半の実装例では、公式のホスト型（https://x402.org/facilitator）をBase Sepolia向けに使っています。

対応ネットワークとアセット

Coinbaseが運用するファシリテーターは、執筆時点で以下をサポートしています。

EVM系：Base / Polygon / Arbitrum / World
SVM系：Solana
アセット：USDC、EURC など（EIP-3009対応のステーブルコイン）

実装例：note風「途中から有料」記事APIを作る

仕様を追ったところで、実際に動かしてみます。ここではnoteのような「途中まで無料、ここから先は有料」を、AIエージェントが利用できるAPIとして実装します。Express.jsと@x402の公式SDK、テストネットのBase Sepoliaを使い、本物のファシリテーターを通して決済を行います。

全体構成

「発見される無料部分」と「支払って取得する有料部分」を、2種類のエンドポイントに分離するのが設計の要です。

エンドポイント	認証	返すもの	目的
`GET /articles`	不要	記事一覧（無料）	記事を発見・検索するための一覧を取得する。
`GET /articles/:id`	不要	プレビュー＋価格情報	コンテンツの内容と価格を確認し、購入するか判断する。
`GET /articles/:id/full`	x402決済	全文（構造化データ）	決済完了後に有料コンテンツの全文を取得する。

さらに、同じURLでもAcceptヘッダーで出し分けます。ブラウザ（人間）にはHTMLを、application/jsonを要求するAIエージェントには構造化JSONを返す ―― 人間には購入ボタンを、AIには402を、という共存です。

サーバー実装

x402対応の肝は、x402ResourceServerにスキーム（今回はBase SepoliaのExactEvmScheme）を登録し、有料化したいルートにpaymentMiddlewareを挟むことです。

// src/server.ts（抜粋）

import express from "express";
import {
  paymentMiddleware,
  x402ResourceServer,
} from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

import { articles } from "./articles.js";

const app = express();

const payTo = process.env.EVM_ADDRESS!; // 受取ウォレット
const facilitatorUrl = "https://x402.org/facilitator"; // 公式ファシリテーター

// -----------------------------------------------------------------------------
// x402 サーバーセットアップ
// -----------------------------------------------------------------------------

const facilitatorClient = new HTTPFacilitatorClient({
  url: facilitatorUrl,
});

const server = new x402ResourceServer(facilitatorClient).register(
  "eip155:84532", // Base Sepolia
  new ExactEvmScheme(),
);

// -----------------------------------------------------------------------------
// 有料エンドポイントを x402 で保護
// -----------------------------------------------------------------------------

app.use(
  paymentMiddleware(
    {
      "GET /articles/:id/full": {
        description:
          "有料記事の全文取得（Markdown形式・構造化メタデータ付き）",
        accepts: [
          {
            scheme: "exact",
            network: "eip155:84532",
            price: "$0.01",
            payTo,
          },
        ],
      },
    },
    server,
  ),
);

// -----------------------------------------------------------------------------
// 有料ルート本体（決済が通った後のみ到達）
// -----------------------------------------------------------------------------

app.get("/articles/:id/full", (req, res) => {
  const article = articles[req.params.id];

  res.json({
    id: article.id,
    title: article.title,
    format: "markdown",
    body: article.fullBody,

    metadata: {
      author: article.author,
      license: "CC BY 4.0",
      citation: `${article.author} (2026). ${article.title}. GMO Developer Blog.`,
    },

    references: article.references,
  });
});

ポイントは、paymentMiddlewareを1つ挟むだけで既存エンドポイントを有料化できることです。price: "$0.01"のような高レベルな指定から、SDKがトークンの最小単位やPAYMENT-REQUIREDヘッダーを組み立ててくれます。決済が失敗すれば、/articles/:id/fullのハンドラーにはそもそも到達しません。

クライアント実装（AIエージェント側）

クライアントはx402Clientにスキームと自分のウォレットを登録し、wrapFetchWithPaymentでfetchをラップします。あとは通常のfetchとほぼ同じ感覚で呼ぶだけで、402ハンドリング・署名・再送はSDKが吸収します。

// src/client.ts（抜粋）
import { x402Client, wrapFetchWithPayment } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(
  process.env.EVM_PRIVATE_KEY as `0x${string}`,
);

const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(account));

const fetchWithPayment = wrapFetchWithPayment(fetch, client);

// Step 1-2: 無料でプレビューを取得し、購入判断する
const preview = await (await fetch(`${SERVER_URL}/articles/1`)).json();

const taskKeywords = ["認証", "OAuth", "エージェント", "API"];
const matched = taskKeywords.filter(
  (kw) =>
    preview.preview.body.includes(kw) ||
    preview.title.includes(kw) ||
    preview.tags.includes(kw),
);

if (matched.length === 0) return; // タスクに無関係なら買わない

// Step 3: x402 で支払い＋全文取得（402→署名→再送は自動）
const res = await fetchWithPayment(`${SERVER_URL}/articles/1/full`, {
  method: "GET",
});

const fullArticle = await res.json();

// 決済結果は PAYMENT-RESPONSE ヘッダーに入っている
const decoded = JSON.parse(atob(res.headers.get("payment-response")!));

ここで面白いのは、無料プレビューの構造化データ（タイトル・目次・文字数・タグ）をもとに、AIエージェントが「この記事は今のタスクに必要か」を判断してから買う点です。人間がnoteでプレビューや目次を見て購入を決めるのと同じ判断を、機械可読なフィールドで行っています。

実際の通信フロー

このクライアントを動かすと、HTTP上では次のやり取りが発生します。

--- 有料コンテンツ取得（1回目：支払いなし） ---
GET /articles/1/full HTTP/1.1
Host: localhost:4021
Accept: application/json

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6MSwiYWNjZXB0cyI6W3...   ← Base64(JSON)

--- 有料コンテンツ取得（2回目：署名付き） ---
GET /articles/1/full HTTP/1.1
Host: localhost:4021
Accept: application/json
PAYMENT-SIGNATURE: eyJzY2hlbWUiOiJleGFjdCIsInBheWxvYWQiOns...  ← Base64(JSON)

HTTP/1.1 200 OK
PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0eEhhc2giOiIweGFi...  ← 決済結果
Content-Type: application/json

{
  "title": "...",
  "format": "markdown",
  "body": "# ...",
  "..."
}

1回目の402から2回目の200までの間に、裏では「クライアントがEIP-3009署名を生成 → サーバーがファシリテーターにverify／settleを依頼 → Base Sepolia上でUSDCが移動」という一連の処理が走っています。呼び出し側のコードからは、それがたった1回のfetchWithPaymentに畳み込まれて見えるわけです。

動かした様子

実際にサーバーとクライアントを起動すると、AIエージェントが「一覧取得 → プレビューで購入判断 → 402 → 署名 → 全文取得」を自律的にこなし、最後にPAYMENT-RESPONSEのトランザクション情報まで受け取れます。ブラウザで開けば、同じエンドポイントが人間向けのHTMLペイウォールとして表示されます。

図3：記事一覧（無料）。ここは誰でも・どのエージェントでも見られる「発見」の場。

図5：支払い前の`402 Payment Required`。支払い条件が返る。

「AIに買ってもらう」ための情報設計

x402の仕組み自体はシンプルですが、実際に売れるAPIにするには購入判断に必要な情報の設計が効いてきます。実装例から得られた勘所を短くまとめます。

descriptionを具体的に書く："Premium content"ではAIは判断できません。「全文・Markdown・約8,000字・認証パターン3種の比較と実装例」のように、何が得られるかを明示します
無料プレビューを構造化する：目次（sections）・文字数・フォーマット・タグを機械可読で出すと、AIが関連性を評価できます
売り物はHTMLではなくMarkdown＋メタデータ：本文はパースしやすいMarkdownで、出典・ライセンス・引用情報を添える。AIにとっての価値は「引用・再利用しやすさ」です
無料と有料の線引き：無料部分に「何について書かれているか」、有料部分に「具体的にどうするか（実装・比較・結論）」を置くと、発見可能性と課金を両立できます

そして、この設計は有料記事に限りません。「無料のドキュメント＋サンプル」→「有料の実データ」という構造は、API課金そのものと同型です。x402なら、天気予報APIも有料記事も、まったく同じpaymentMiddlewareで従量課金できます。事前のアカウント登録もAPIキーの発行も要らず、ウォレットと残高さえあれば初見のAPIをその場で叩ける ―― これがAIエージェント時代の課金として効いてくる部分です。

寄り道：「Agentic Commerce」と「Agentic Payments」は違う

ここから業界の動きを見ていきますが、その前に、混同されやすい2つの言葉を分けておきます。Agentic Commerce（エージェンティック・コマース）と Agentic Payments（エージェンティック・ペイメンツ）です。両者は包含関係にあります。

Agentic Commerce ＝取引の全行程：AIエージェントが代理で行う商取引そのもの。発見・検索 → 比較・交渉 → カート → 支払い → 履行・配送 → サポート、までの全体を指します。
Agentic Payments ＝そのうち「払う」部分だけ：支払いの認可（誰が・いくらまで許可したか）と実行（実際の送金・清算）に限定した話です。

お店にたとえるなら、Commerceは「棚を見て商品を選び、レジを通し、受け取り、必要なら返品する」買い物体験まるごと。Paymentsはそのうち「レジ／カード端末の一瞬」です。

図7：Agentic Payments は Agentic Commerce の一部。x402が担うのは“支払い”の中の【実行】だけ。

この区別が効くのは、x402が担うのは Agentic Payments の、さらに「実行」スライスだけだからです。x402は商品の発見もカタログもチェックアウトのオーケストレーションもしません。そこはコマース側の別プロトコル（例：OpenAIとStripeによる Agentic Commerce Protocol / ACP。ChatGPTのInstant Checkoutを支える規格）の領域です。「x402を入れれば代金を受け取れる」ようにはなりますが、「エージェントに発見・購入してもらえる」ようにするのは別の作業、というわけです。

そしてこの「コマース層の下でx402が決済を担う」構図は、すでに実在します。たとえば Virtuals Protocol ―― Base上で1.8万を超えるトークン化AIエージェントが動く経済圏 ―― は、エージェント同士が仕事を発注し合う ACP（Agent Commerce Protocol） を持ち、そのマイクロペイメント決済に x402 を採用しています（2026年にパブリックベータ）。Request → Negotiation → Transaction → Evaluation の4フェーズで取引を進め、pay-per-callの少額決済をx402で清算する、という構造です。ここでも役割分担は同じで、ACPが「コマース（取引の段取り）」、x402が「ペイメンツ（実行）」を担います。なお、Virtualsの「Agent Commerce Protocol」は、前述のOpenAI×Stripeの「Agentic Commerce Protocol」と名前は似ていますが別物なので注意してください。

整理すると、AIエージェントが払う場面には少なくとも3タイプあります ―― ①AIクローラーに課金する（Cloudflare）、②人間の代理でエージェントが買い物する（AP2）、③エージェント同士が売買する（Virtuals ACP）。用途は違えど、決済の“実行”レイヤーとしてはいずれもx402が共通の土台になり得る、というのが面白いところです。

実運用の最前線：この動きを主導するのは誰か

ここまで作ってきたのは「自分のサーバーにx402を組み込む」小さな実装でした。では業界全体では誰がこれを推し進めているのか。エージェント決済の主導権を握ろうとしているのは、いまのところ主にCoinbase・Cloudflare・Stripeの3社です。立ち位置がそれぞれ違うのが面白いところです（マッキンゼーはエージェント・コマースが2030年までに3〜5兆ドル規模を動かし得ると試算しており、主導権争いは熱を帯びています）。

図8：x402をめぐる勢力図。3社は狙いが違うが、「HTTPの中で自律的に払う」共通語としてx402に集まる。

Coinbase ── プロトコルの生みの親

x402そのものを2025年5月に公開したのがCoinbaseです。Cloudflareと共同でx402 Foundationを立ち上げ、公式のファシリテーターも運用しています。公開から半年で累計1億件超のトランザクションを処理したとされ、2025年12月のV2ではマルチチェーン対応を標準化し、ACHやカードといった既存の決済レールとの橋渡しにも踏み込みました。暗号資産の取引所という出自を活かし、「オンチェーン決済をHTTPに埋め込む」というプロトコルの中核を押さえています。

Cloudflare ── CDNの標準機能にする

そのx402を、CDNのレベルで数百万サイト規模に展開しているのがCloudflareです。冒頭で見たAIボットの激増とクロール対リファラ比の非対称は、まさにCloudflareが課金プロダクトを作る動機になりました。流れを追うと分かりやすいです。

Content Independence Day と Pay Per Crawl ── Cloudflareは2025年7月1日を「Content Independence Day」と称し、新規契約サイトではAIクローラーをデフォルトでブロックする方針へ舵を切りました。同時に発表されたのが Pay Per Crawl です。サイト運営者がAIクローラーに対してゾーン単位で価格を設定し、クロール1回ごとに課金できる仕組みで、まさにHTTP 402を使います。運営者はクローラーごとに3つの対応を選べます。

Allow：無料でアクセスを許可する
Charge：設定した価格を要求する（402を返す）
Block：完全に拒否する

この「Allow / Charge / Block」は、本記事の言い方に置き換えれば「歓迎する／レジに通す／壁で止める」の3択そのものです。

AI Crawl Control ── まず「誰が来ているか」を可視化する ── 課金や制御の前段として、CloudflareはどのAIボットが・どれだけ・何の目的で（学習／検索／エージェント操作）クロールしているかをダッシュボードで可視化し、目的カテゴリごとに扱いを変えられるようにしています。2026年9月15日からは新規ドメインについて、広告のあるページでは「学習(Training)」と「エージェント(Agent)」目的のクロールをデフォルトでブロックし、「検索(Search)」は許可するという新しいデフォルトが適用される予定です。

Monetization Gateway ── クローラーから「あらゆる呼び出し元」へ ── そして2026年、CloudflareはPay Per Crawlの次段階として Monetization Gateway を発表しました。課金対象が「AIクローラー」から「あらゆる呼び出し元による、あらゆるリソース」へ拡張されたのがポイントです。Cloudflareの背後にあるものなら、Webページ・データセット・API・MCPツールまで、まとめて課金できます。その土台がまさにx402で、仕組みは本記事で解剖したフローそのもの。Cloudflareがファシリテーターの役割を担い、支払い証明を検証してリソースを解放します。特徴を挙げると：

決済はステーブルコイン（Open USD や USDC）。手数料はごくわずかで、確定は1秒未満。売り手は貯めたステーブルコインをそのまま使うことも、銀行口座へ法定通貨として引き出すこともできる
ピアツーピア決済。資金は買い手のウォレットから売り手のウォレットへ直接入る（Cloudflareは資金を預からない）
柔軟な価格設定。「/api/premium/* への GET / POST 1回ごとに $0.01」のようにRESTの動詞・パス単位で課金でき、処理の重さに応じた変動価格や、「未認証ユーザーにだけ課金する」といった設定もできる

言い換えれば、本記事で自作したペイウォールを、CDNのエッジで・設定だけで・インターネット規模で実現するのがMonetization Gatewayです（執筆時点では既存顧客向けにウェイトリスト登録が必要）。自分でpaymentMiddlewareを書く道と、CDNに任せる道 ―― どちらもプロトコルはx402で共通しており、片方を理解すればもう片方も読み解けます。

Stripe ── 決済インフラ側からの参入

既存の決済インフラの雄であるStripeも、2026年のStripe Sessionsで「エージェント時代の決済」を前面に打ち出しました。特徴的なのは二正面作戦です。ひとつは、Stripeがパラダイムと共同でインキュベートした決済特化のL1ブロックチェーン Tempo を使う独自プロトコル MPP（Machine Payments Protocol）（2026年3月公開）。もうひとつが、オープンな x402 への対応です。実際、Stripe公式のサンプル stripe-samples/machine-payments には MPP版（Tempoテストネット）と x402版（Base SepoliaのUSDC）の両方の実装が同梱されており、「自前レールも、オープン標準も、どちらも押さえる」という姿勢がうかがえます。AWSの Bedrock AgentCore payments が Coinbase・Stripe と組んで提供されるなど、クラウド各社を巻き込む動きも出ています。

3社の狙いは少しずつ違います ―― Coinbaseはプロトコルとオンチェーン決済、CloudflareはコンテンツとCDNエッジ、Stripeは決済インフラと法定通貨との接続。それでも「AIエージェントがHTTPの中で自律的に払う」という一点では方向がそろっており、x402はその共通語の最有力候補になっています。

プロトコルか、プロダクトか ── 3社は対称ではない

ここで一つ注意点です。「Coinbase主導・Cloudflare主導・Stripe主導のものがそれぞれある」と聞くと、3社が横並びで独自の決済プロトコルを持っているように見えますが、実際は対称ではありません。「プロトコル（オープンな規格）」と「プロダクト（その上に載る製品・サービス）」を分けると、すっきり整理できます。

Coinbase：プロトコルそのものの主。x402というオープン規格を作り、公式facilitatorやCDPも運用する。
Stripe：独自プロトコルも持つ。Tempo(L1)上の MPP という自前の決済規格を主導しつつ、x402にも対応する二正面（加えてOpenAIと組んだコマース側の規格ACPもある）。
Cloudflare：独自規格は作らない。x402 Foundationの共同設立者ではあるが、自前のプロトコルは持たず、x402を製品として展開する（Pay Per Crawl・Monetization Gateway）。だから「Cloudflare主導のプロトコル」は存在せず、あるのは「x402を使ったCloudflare主導のプロダクト」です。

図9：規格を主導するのはCoinbase(x402)とStripe(MPP)、認可はGoogle(AP2)。Cloudflareは規格ではなく“製品”を主導する。

まとめると、独自の決済プロトコルを主導しているのは実質 Coinbase（x402）と Stripe（MPP）の2つ。Cloudflareは“製品”の主導者、Googleは“許可”という別レイヤー（AP2）の主導者です。そして規格としてはx402が事実上の共通語になりつつある ―― これが現在地です。

許可レイヤーとの関係：AP2とx402は「許可」と「実行」で噛み合う

もう一つ、x402の“位置”を正しく理解するうえで欠かせないのが、隣接する「許可」レイヤーとの関係です。x402は「HTTP／API上でどう支払うか」という実行（settlement）レイヤーの仕組みでした。一方で、AIエージェントがユーザーの代理で支払う世界では、「その支払いは本当にユーザーが許可したものか」「いくらまでなら払ってよいか」「誰が責任を持つのか」という認可・委任の論点が別に存在します。

ここを担うのが、Googleが2025年9月にCoinbaseと共に公開した AP2（Agent Payments Protocol） です。AP2はカード・銀行振込・暗号資産などに依存しない「決済手段非依存」の枠組みで、3つの署名付きマンデート（mandate）を連鎖させることで「誰が・何を・いくらまで許可したか」を暗号学的に証明できるようにします。

Intent Mandate：ユーザーがエージェントに権限を委任する（「この条件でなら買ってよい」）
Cart Mandate：具体的なカート内容と価格をユーザーが承認する
Payment Mandate：そこから導出され、決済ネットワークが実際に受け取る資格情報

さらに認可の隣には「そのエージェントは本当に信頼できる主体か」という身元・信頼の層もあります。VisaのTrusted Agent ProtocolとAkamaiの提携（2025年末）などがこの領域に取り組んでおり、いずれもx402が担う“実行”の手前に位置します。整理すると、身元・信頼 → 許可（AP2）→ 実行（x402）という重なりです。

そして重要なのが、このAP2の「許可」と、x402の「実行」がすでに接続され始めていることです。GoogleはCoinbase・Ethereum Foundation・MetaMaskと共同で A2A x402 拡張（google-agentic-commerce/a2a-x402）を開発し、AP2が出力した認可を、x402による決済（オンチェーンのステーブルコイン送金）へとつなぐ経路を用意しました。両者は競合ではなく、「AP2で許可し、x402で払う」という上下のレイヤーとして組み合わさるわけです。本記事で解剖したx402は、この積み木の“実行”側の部品にあたる、と捉えると全体像がつかみやすいはずです。では、この2つを実際に「合わせて使う」とどうなるのか ―― 実装者が最初に引っかかる疑問とあわせて、もう少し具体的に見てみましょう。

予算と許可は誰が決めるのか ── x402とAP2の合わせ技

実装を考えると、まず必ず引っかかる疑問があります。「エージェントはいくらまで払っていいのか」「人間はどこで承認するのか」です。ここは混乱しやすいので、順番に解きほぐします。

まず、x402自体には『予算』や『上限』の概念がありません。 x402がやるのは「1リクエストごとに署名して払う」実行だけで、402で提示された金額に対して署名する／しないをその都度決めるにすぎません。だから前半のデモでも、「買うかどうか」の判断はクライアントのコードに書いた素朴なロジックでした ―― プレビューがタスクに関連するかを見て、関連しなければ買わない。ここに「$0.10を超えるなら買わない」のような予算ガードを足したければ、それはアプリ側で自分で書くことになります。x402が面倒を見てくれるわけではありません。

そして、「人間が購入ボタンを押す」わけでもありません。 ここが従来のWeb決済との決定的な違いです。x402が狙うのは、購入のたびに人間がクリックする世界ではなく、人間が一度だけ「使ってよい範囲」を決めておけば、あとはエージェントが自律的に判断して払う世界です。毎回クリックが必要なら、そもそもエージェントに任せる意味が薄れてしまいます。

この「使ってよい範囲を、事前に、証明可能な形で決めておく」役割を担うのが、前節のAP2（許可レイヤー）です。人間がIntent Mandateで「この条件でなら・いくらまで買ってよい」を署名して委任し、エージェントはその枠の中で個々の購入を判断、実際の送金はx402が実行する ―― という重なりになります。

つまり「AIが判断する」ことと「事前にマンデートで縛る」ことは対立しません。マンデートがガードレールを引き、その中でエージェントが個別に判断するという関係です。他人（＝人間）のお金を責任を持ってエージェントに使わせるなら、この AP2（許可）＋x402（実行）の合わせ技がベストになります。

ただし、すべてのx402にAP2が要るわけではありません。 委任元の人間がいない場面では、AP2はむしろ過剰です。用途ごとに整理すると、予算・許可の決め方はこう変わります。

使い方	予算・許可はどう決めるか
人間の代理でエージェントが買い物（他人のお金を使う）	AP2＋x402。上限・責任・監査が必要なので、合わせ技が最適。
エージェント同士の売買（Virtualsなど）	委任元の人間がいないため、各自のロジックやエスクローで足りることが多い。
AIクローラーへの課金（Cloudflareなど）	クローラー運営側が自分で予算を管理するため、AP2は必ずしも介在しない。
自分の管理下の1体のエージェントにAPIを叩かせる	x402単体＋アプリ側に書いた予算ロジックで十分。

なお、AP2とx402をつなぐ実装（a2a-x402）はまだ新しく、現状動いているx402の多くはAP2なしで予算ロジックを自前で持っています。「まずはx402単体で作り、責任と上限の委任が必要になったらAP2を重ねる」という順序で考えると現実的です。認可レイヤー（AP2）そのものの掘り下げは、また別の記事に譲ります。

現時点で優勢なのはどこか

「結局どこが勝つのか」は誰もが気になるところです。2026年半ばの現状を総括すると、答えはレイヤーによって違うものの、決済（実行）レイヤーの標準争いに関してはx402が明確に優勢です。

なぜx402が優勢と言えるのか ── 最大の理由は、競合すら乗ってくるネットワーク効果です。

x402 Foundation に Coinbase・Cloudflare・Google・Visa・AWS・Circle・Anthropic・Vercel が名を連ねる
Cloudflareは自社の課金基盤（Monetization Gateway）の土台に採用
Googleは認可プロトコルAP2をx402に接続（A2A x402拡張）
Stripeは独自のMPPを持ちながら、x402にも対応 ―― 自前レール一本には賭けていない
Virtuals ProtocolのACPやAWS Bedrock AgentCoreも、決済にx402を利用
公開1年で累計1.6億件超のトランザクション（買い手59万・売り手10万、Coinbase公表）

つまりx402は「一社の製品」ではなく各社の共通語（デファクト標準）になりつつあり、対抗馬のはずのStripe MPPでさえx402対応でヘッジしている、という状況です。標準は「普及した者」が勝つので、この“みんなが乗っている”状態そのものがx402の勝ち筋になっています。

ただし「x402の一人勝ち」ではありません ── これはプロトコル（規格）の話であって、ビジネスの主導権はレイヤーごとに分かれるからです。積み木の各段で主役が違います。

身元・信頼：Visa（Trusted Agent Protocol）＋Akamai など
許可（authorization）：Google（AP2）が先行
コマース（取引の段取り）：OpenAI×Stripe（ACP）、エージェント間ならVirtuals
実行（settlement）＝x402：規格はCoinbase、facilitatorは競争市場、CDNエッジ配信はCloudflare、法定通貨接続はStripe

したがって「どこが優勢か」への一番正確な答えは、「決済プロトコルの共通語としてはx402が優勢。ただしスタック全体は一社の総取りではなく、身元 → 許可 → コマース → 実行の各層を別々の主役が分け合い、x402というレールの上で相互接続する」という形になります。

ひっくり返り得る要因も正直に挙げておきます。決済手段非依存を掲げる上位レイヤー（AP2など）が主導権を握れば、下位の実行はx402以外（Stripe MPPやカード網）にも振り分けられ、x402は「複数ある実行手段の一つ」に相対化される可能性があります。規制（特に受け取り側）やステーブルコインの扱い次第でも絵は変わるでしょう。とはいえ現時点では、「まずx402を押さえておけば大きく外さない」と言える状況です。

実際に使われているのか ── 実用例と現在地

ここまでの話は絵に描いた餅ではありません。すでに本番でx402を受け付けているサービスが登場しています。とくに多いのが、AIエージェント向けに「APIをリクエスト単位で売る」使い方です。

Hyperbolic：GPU推論。Llama・Mistral・Stable Diffusionなどのモデルを、APIキー契約なしでリクエストごとに課金して呼べる
Neynar：Farcaster／ソーシャルのデータAPI。投稿やインフルエンサー指標などを都度課金で取得
Firecrawl：Webスクレイピング／クロールAPI
Token Metrics：暗号資産の分析データ

さらに、こうしたサービスをエージェントが実行時に探して支払えるディレクトリも生まれています。x402 Bazaar はx402対応APIのマーケットプレイスで、開発者が事前に個別統合しなくても、エージェントがその場で見つけて呼び出せます（AWS AgentCore経由で1万を超えるエンドポイントが引けるとされます）。まさに本記事で作ったペイウォールの「発見 → 購入判断 → 支払い」を、サービス横断で成立させる仕組みです。

大手・エンタープライズの採用も進んでいます。

AWS：2026年5月に Amazon Bedrock AgentCore Payments をx402ネイティブで公開。世界最大級のクラウドでx402が既定の決済レールに
Cloudflare：エッジ（Monetization Gateway）でx402を実装。AWSと相次いで、数週間のうちにエッジ対応が出そろった
Visa：Trusted Agent Protocol にx402サポートを追加。Stripe：ACP経由でx402を統合し、既存の決済レールと接続
ChatGPTのInstant Checkout（ACP）：すでに稼働し、PayPal・Salesforce・Shopifyなどが採用

ただし規模は冷静に見るべきです。 前節で触れたトランザクション件数（公開1年で1.6億件超）は華々しいものの、額面通りには受け取れません。オンチェーンの実データを見ると、日次の決済額は数万ドル規模にとどまり、その多くはテストや“水増し”のトランザクションだと指摘されています（Chainalysisやartemisの分析）。「エージェント決済ブームはまだ大半が幻」という辛口の評価もあり、CoinDeskも「需要がまだ追いついていない」と報じました。つまり現状は、“配管”と大手の採用は急速に整う一方、実需（本物の商用トラフィック）はこれから、という段階です。前節で「x402が優勢」と述べたのはあくまで標準・採用の勢いの話であって、実取引のボリュームで勝負がついたわけではない ―― この温度差はセットで押さえておくべきです。

課題と、実装前に知っておくこと

ここまで良い面を中心に見てきましたが、x402は発展途上のプロトコルです。実際に導入を検討するなら、次の点は冷静に押さえておくべきです。

ファイナリティとレイテンシ：オンチェーンの確定を待つと、HTTPリクエストのレイテンシとしては重くなりがちです。高頻度のマイクロペイメントでは、確定を待たずに楽観的にリソースを返す、L2やSolanaのような高速なネットワークに寄せる、といった設計上の工夫が要ります。
オンランプ／オフランプ：エージェントがステーブルコインの残高を持っていなければ話が始まりません。ウォレットの用意・資金の供給・使い切った後の補充といった運用は、まだ人間の手が必要な領域です。
規制・税・KYC ── 受け取る側に残る宿題：x402は買い手（エージェント）側のアカウント登録やKYCを不要にしますが、それは「規制がなくなる」ことを意味しません。対価を受け取る売り手側には、マネーロンダリング対策・税務処理・地域によっては資金移動業に関わる要件が生じ得ます。「エージェント側が手軽」という話と「事業者側の法的義務」は分けて考える必要があります。
プロトコル本体と、トークン投機は別物：x402の周辺では関連トークンの相場が話題になることがありますが、それらの値動きはプロトコルとしての実用性とは切り離して評価すべきです。決済プロトコルとしてのx402を検討する際に、投機的な盛り上がりをそのまま採用根拠にしないよう注意が要ります。
ファシリテーターへの依存：検証と実行を委譲する以上、ファシリテーターは可用性（落ちれば決済できない）とメタデータ観測の面で信頼ポイントになります。ホスト型に乗るか、自前運用のコストを取るかは要判断です。
標準の乱立：x402・Stripe MPP・AP2などが並走しており、どれが事実上の標準になるか、相互運用のレイヤーが生まれるかはまだ見えていません。特定の一つに深く作り込む前に、抽象化して乗り換え余地を残す設計が無難です。

とはいえ、これらの多くは「時間が解決する成熟の課題」と「設計で吸収できる課題」です。プロトコルの筋の良さ ―― HTTPネイティブ・署名と実行の分離・ノンカストディアル ―― は、これらの課題を差し引いても十分に魅力的だと考えています。

まとめ

本記事では、x402というプロトコルの中身を解説し、それを動く有料記事APIとして実装しました。要点を整理します。

x402はHTTP 402を実装したオープンプロトコル。決済がPAYMENT-REQUIRED／PAYMENT-SIGNATURE／PAYMENT-RESPONSEの3ヘッダーだけで完結する
署名と実行が分離している。クライアントはEIP-3009の署名を作るだけで、オンチェーン送金とガス負担はファシリテーターが担う（＝クライアントはガスレス）
ファシリテーターがverify／settleを代行するため、サーバーはノードも秘密鍵も持たずに決済を扱える
実装は驚くほど軽い。paymentMiddlewareを1つ挟むだけで既存エンドポイントを有料化でき、クライアントはfetchとほぼ同じ感覚で支払える
「AIに買ってもらう」には、description・目次・Markdown・出典など機械可読な情報設計が効く
x402は決済の「実行」レイヤー。その手前の「許可」（AP2）やコマース層と積み重なり、Coinbase・Cloudflare・Stripeらが推す事実上の共通語になりつつある

世間の関心は「AIクローラーからどう守るか（壁）」に集まりがちですが、同じ402は「AIにどう買ってもらうか（レジ）」でもあります。AIエージェントが自律的にWebを巡回し、必要な情報やAPIを見つけて対価を払う世界 ―― その「配管」が、いままさに敷かれようとしています。次にHTTPステータスコードの一覧で402を見かけたら、もう “Reserved for future use” とは言えないかもしれません。

最後に

AI研究開発室では、データサイエンティスト/AIエンジニアを募集しています。AI/LLMを活用したシステム開発、AI×ロボットなどにご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。皆さんのご応募をお待ちしています。

参考リンク

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

Follow @GMO_RD