x402とは何か
Web開発に関わっている方であれば、404 Not Foundや401 UnauthorizedというHTTPステータスコードは見たことがあると思います。では、402 Payment Requiredはどうでしょうか。
名前だけ見ると「支払いが必要です」というかなり直接的な意味を持つステータスコードです。しかし実際には、長い間あまり使われてきませんでした。HTTP仕様であるRFC 9110でも、402は将来の利用のために予約されていると説明されています。
この、長らく眠っていた402 Payment Requiredを、いま改めて決済プロトコルとして使おうとしているのがx402です。
x402は、Coinbaseが開発したオープンな決済プロトコルです。HTTP通信の中で、APIやデジタルコンテンツに対する支払いを行えるようにする仕組みで、CoinbaseのドキュメントではHTTP上で即時・自動のステーブルコイン決済を可能にするプロトコルとして説明されています。
一言で言えば、x402はHTTPに支払い機能を足すためのプロトコルです。もう少しビジネス寄りに言うなら、x402はAPI、データ、記事、AIツールを1回単位で売りやすくする仕組みです。
これまでのWeb決済は人間向けに作られていた
これまで、Web上で何かを買うときには、基本的に人間が画面を操作していました。クレジットカードを入力する、アカウントを作る、メールアドレスを認証する、ログインする、サブスクリプションに申し込む、APIキーを発行する、といった流れです。
こうした流れは、人間がブラウザを見ながら操作する前提では自然です。しかし、AIエージェントや自動化されたプログラムにとっては扱いづらいものです。
たとえば、AIエージェントがこの企業の財務データを取得したい、この専門記事を1本だけ読みたい、この有料APIを1回だけ使いたいと判断したとします。従来の仕組みでは、人間がクレジットカードを登録したり、月額契約を結んだり、APIキーを設定したりする必要がありました。
これは、AIエージェントが自律的に動く世界とは相性がよくありません。x402が解こうとしているのは、まさにこの問題です。
x402の基本的な流れ
x402の仕組みは、考え方としてはかなりシンプルです。有料APIや有料コンテンツにアクセスしようとしたクライアントに対して、サーバーがまず402 Payment Requiredを返します。
そのレスポンスには、価格、受け入れるトークン、ネットワーク、支払い先などの条件が含まれます。クライアントはその条件を読み取り、ウォレットで支払い情報に署名し、支払い情報を付けて同じリクエストを再送します。
サーバーまたはファシリテーターが支払いを検証・決済し、問題がなければリソースを返します。Coinbaseのドキュメントでは、この流れがリクエスト、402応答、支払い作成、支払い付き再リクエスト、検証、決済、リソース返却として整理されています。
ざっくり書くと、クライアントが有料APIにアクセスし、サーバーが402を返し、クライアントが支払い情報に署名し、支払い情報付きで再リクエストし、支払いが検証されたら200 OKでデータが返る、という流れです。
ポイントは、支払いがWebの外側にあるのではなく、HTTPのリクエスト・レスポンスの流れに組み込まれていることです。Cloudflareのドキュメントでも、x402はHTTP 402を中心にした決済標準であり、サービスは支払い指示を含む402レスポンスを返し、クライアントはアカウント、セッション、APIキーなしにプログラムから支払えると説明されています。
x402が変えるのは課金の単位
x402が面白いのは、単に暗号資産で支払えるという点ではありません。より重要なのは、課金の単位が変わることです。
これまでのWebサービスやAPI課金は、月額契約やAPIキー発行が中心でした。もちろん従量課金のAPIもありますが、多くの場合は事前登録、アカウント作成、請求設定、APIキー管理が必要です。
一方でx402は、HTTPリクエスト単位での支払いに向いています。たとえば、天気データAPIなら1リクエスト0.01ドル、企業データAPIなら1社取得0.05ドル、ニュース記事なら1記事0.10ドル、専門レポートの要約なら1回0.50ドル、AIエージェント用MCPツールなら1ツール呼び出しごとに課金、といった設計が考えられます。
Coinbaseは、x402で開発者が構築できる例として、有料API、プレミアム機能のオンデマンド解放、実利用に応じたメータードサービスを挙げています。特に、有料APIではAPIコールごとのマイクロペイメントにより、サブスクリプション型モデルの摩擦を減らせると説明しています。
つまり、x402は月額で売るには小さすぎるものを売りやすくします。1回だけ使いたい、少額だけ払いたい、人間ではなくプログラムから呼び出したい、APIキーを発行するほどではない、サブスク契約するほどではない。こうした場面で、x402は選択肢になります。
AIエージェントとの相性がよい理由
x402が注目される理由のひとつは、AIエージェントとの相性が非常によいことです。AIエージェントは、人間のように画面を見てクリックする存在ではありません。基本的には、APIを呼び出し、ツールを使い、データを取得し、結果を判断しながらタスクを進めます。
そのAIエージェントが外部サービスを使うとき、毎回人間が決済画面を開いて承認する設計では、自律性が失われます。
x402では、エージェントがHTTPレスポンスとして返ってくる支払い条件を読み、ウォレットで署名し、支払い付きで再リクエストできます。Coinbaseは、x402の対象を人間、スクリプト、AIエージェントまで含めて説明しており、クライアントが支払いプロンプトに対してステーブルコインで即時に応答できるとしています。
たとえば、ユーザーがある会社について競合・市場・財務の観点から調べてほしいと依頼した場合、AIエージェントは無料のWeb検索を行い、必要に応じて有料の企業データAPIを呼び、402 Payment Requiredを受け取り、事前に許可された上限額の範囲で支払い、データを取得して分析をまとめることができます。
人間が途中でカードを入力するのではなく、エージェントが必要なAPIやデータに、その場で少額支払いを行う。これが、x402が見据えている世界です。
MCPツールの有料化にも使える
AIエージェントとの関係で、もうひとつ重要なのがMCPです。MCPは、AIエージェントやLLMアプリケーションが外部ツールやデータソースと接続するための仕組みとして注目されています。x402は、このMCPツールの有料化とも相性があります。
Cloudflareは、Agents SDKやMCPサーバーとの統合でx402をサポートしており、有料MCPツールを定義する例を公開しています。その例では、1回0.01ドルの有料ツールを定義し、クライアントが支払いなしで呼び出した場合には402が返り、クライアントがx402で支払って再試行すると結果を受け取れる流れになっています。
これは、AI時代のツール販売にとって大きな変化です。これまでは、SaaSを売るには管理画面、ログイン、課金プラン、請求管理、ユーザー管理が必要でした。
しかし、AIエージェント向けの小さなツールであれば、必ずしもフル機能のSaaSにする必要はありません。このMCPツールを1回呼ぶたびに0.01ドル、この分析ツールを1回使うたびに0.5ドル、このデータ検索ツールを1回使うたびに課金、というツール単位・呼び出し単位の収益化が現実的になります。
AIクローラー課金という文脈
x402と近い文脈で語られるものに、AIクローラーへの課金があります。生成AIの普及により、Web上の記事やドキュメントは、人間だけでなくAIクローラーにも読まれるようになりました。ここで問題になるのが、コンテンツ提供者に対価が戻りにくいことです。
Cloudflareは、Pay Per Crawlという取り組みで、AIクローラーが有料URLをリクエストした際にHTTP 402 Payment Requiredと価格情報を返し、クローラーが支払い意思を示して再リクエストできる仕組みを説明しています。
CloudflareのPay Per Crawlはx402そのものとは異なる仕組みですが、HTTP 402を使って読むなら支払うという関係を作ろうとしている点で、同じ問題意識を持っています。
この流れは、メディア企業、専門情報サイト、調査会社、データベース事業者にとって重要です。これまでのWebは、無料公開して広告で回収するか、ログイン・サブスクで囲い込むかの二択になりがちでした。
AIエージェントやAIクローラーが情報を取得する時代には、読むたびに払う、使うたびに払うという第三の選択肢が必要になります。
AP2との関係
AIエージェント決済の文脈では、Googleが発表したAgent Payments Protocol、AP2も重要です。
AP2は、AIエージェントがユーザーの代理で支払いを行う際の認可や責任の枠組みを扱うプロトコルです。Google Cloudの発表では、AP2はエージェント主導の支払いを安全に開始し、取引するためのオープンプロトコルとして説明されています。
この関係を整理すると、AP2はエージェントが支払う権限・認可・責任を扱い、x402はHTTP上で実際に支払いを行う仕組みを提供し、MCPはエージェントが外部ツールを呼び出す接点になり、ウォレットやファシリテーターが支払いの署名・検証・決済を担う、という見方ができます。
AIエージェント決済は、単一の技術だけで完結するものではありません。誰が支払いを許可したのか、いくらまで使ってよいのか、どのサービスに支払ってよいのか、実際の支払いはどのレールで行うのか、支払い後に本当にサービスが提供されたのかを組み合わせて設計する必要があります。
その中でx402は、HTTPベースの支払いレールとして位置づけられます。
ビジネスへのインパクト
x402が普及した場合、最も影響を受けるのは、API、データ、コンテンツ、AIツールを持つ事業者です。
APIを持っている企業では、天気、地図、金融、企業情報、不動産、求人、特許、論文、法務、ニュースなどのデータAPIが候補になります。これまでAPIを有料化するには、契約、請求、APIキー、利用量管理などが必要でした。x402を使えば、より小さな単位でAPIを売れる可能性があります。
専門コンテンツを持っている企業でも、記事単位、レポート単位、要約単位で支払える仕組みがあると、コンテンツの収益化モデルが広がります。AIエージェントが情報収集を行うとき、無料情報だけでなく、信頼できる専門情報にアクセスしたくなる場面があるためです。
AIエージェント向けツールを作る企業にとっても重要です。競合分析、社内ドキュメント検索、コード解析、データ整形、リサーチ補助などのツールは、月額SaaSだけでなく、AIエージェントから呼び出されるたびに課金するモデルを取り得ます。
さらに、AIエージェントの支出管理を提供する企業にも機会があります。エージェントごとの支出上限、利用できるAPIの範囲、承認が必要な金額、ログの保存、不正利用の検知、経理処理、監査対応といった周辺レイヤーは、BtoBビジネスとして重要になる可能性があります。
すぐに何でもx402化すればよいわけではない
x402は有望な技術ですが、現時点ではまだ新しい領域です。企業が導入する場合は、決済手段、会計処理、税務、セキュリティ、法務、UX、監査を慎重に見る必要があります。
たとえば、ステーブルコインや対応ネットワークをどう扱うか、少額・高頻度の支払いをどう記録するか、どの時点で売上・費用として扱うか、ウォレット、署名、秘密鍵、支出上限をどう管理するか、といった論点があります。
利用規約、返金、サービス不提供時の責任、人間の承認をどこまで残すか、AIエージェントが何にいくら使ったかを追跡できるかも重要です。
技術的にはHTTPに支払いを足すだけに見えます。しかし、実際に企業で使う場合には、支払い、権限、監査、経理、法務、セキュリティを含めた設計が必要です。ここを軽く見ると、PoCは動いても本番導入で止まります。
まずは売れるHTTPリソースがあるかを見る
x402を検討するとき、最初に見るべきなのは技術ではありません。自社に、AIエージェントや外部プログラムが支払ってでも使いたいHTTPリソースがあるかです。
候補になるのは、独自データ、専門記事、調査レポート、業界データベース、社内外向けAPI、AIエージェント用ツール、MCPサーバー、分析ロジック、検索・要約・変換機能などです。
これらがある場合、x402は新しい販売方法になります。逆に、支払ってでも使いたいリソースがない場合、x402を入れても意味は薄いです。
x402は魔法の収益化装置ではありません。価値のあるAPIやデータを、より小さな単位で売りやすくするプロトコルです。
企業が試すなら小さなPoCからで十分
x402の検証は、いきなり大規模に始める必要はありません。まずは、1つの有料APIや1つのMCPツールで試すのが現実的です。
たとえば、1つの社内データ検索APIを用意し、1回あたり0.01ドルから0.10ドル程度の価格を設定し、x402で支払い要求を返し、AIエージェントまたはテストクライアントから呼び出し、支払い、ログ、エラー、再試行、上限管理を確認する、といったPoCです。
この程度の小さな検証でも、AIエージェントが支払い条件を正しく解釈できるか、支払いエラー時にどう振る舞うか、少額決済のログをどう扱うか、どの価格なら使われるか、人間の承認をどこに入れるべきか、経理やセキュリティ上の論点はどこに出るかが分かります。
x402の本質は、単に決済を実装することではありません。AIエージェントが外部サービスを使うときの市場設計を考えることです。
まとめ
x402は、長らく使われてこなかったHTTP 402 Payment Requiredを、現代のWeb決済、とくにAIエージェント時代の決済に使おうとするプロトコルです。
重要なのは、暗号資産そのものではありません。重要なのは、API、データ、コンテンツ、AIツールを、HTTPの流れの中で、1回単位・少額単位で売れるようにすることです。
これにより、AIエージェントが必要なAPIに自動で支払う、MCPツールを1回単位で販売する、専門記事やデータをAIクローラーに有料提供する、小さなAPIやデータ資産を収益化する、企業がAIエージェントの支出を管理する、といった世界が見えてきます。
もちろん、実運用には会計、法務、セキュリティ、支出管理といった課題があります。それでも、x402が示している方向性は明確です。
Webはこれまで、人間が読む・クリックする前提で作られてきました。これからは、AIエージェントが読み、判断し、APIを呼び、必要に応じて支払う前提で設計されていきます。そのとき、HTTP上で支払いを扱えるx402は、AIエージェント時代の重要な構成要素になる可能性があります。
まず見るべきは、x402を導入するかではありません。自社に、AIエージェントが支払ってでも使いたいデータ、API、ツールがあるか。そして、それを小さく検証できるか。x402の検討は、そこから始めるのがよいです。
参考文献・参照元
プロトコル、プラットフォーム、HTTPステータスコードに関する情報は、2026年6月4日に確認しました。