x402とは：HTTPへ決済情報を埋め込む

　x402とは、HTTP通信の中で「支払い要求→支払い→再試行」を完結させる、オープンなインターネットネイティブ（Web標準に沿った）な決済プロトコルのこと。つまり、HTTP通信を有料化する仕組みと言える。世界最大級の暗号資産取引プラットフォームのコインベース（Coinbase）が開発し、オープンソースで公開された。

　仕組みとしては、サービス側が有料エンドポイントへのアクセスを受けると、まずHTTP 402を返し、JSONで支払い条件（金額、受取先、利用できる決済手段など）を提示する。クライアントは条件を満たす支払いを実行し、支払い情報をHTTPヘッダーに載せて同じリクエストを送り直す。

　結果として、会員登録やカード入力、請求書処理といった「人間の手」を前提にした工程を減らし、APIやデジタルコンテンツを呼び出した分だけ課金しやすくする。「支払い＝別画面」という常識を、HTTPの往復だけで置き換える発想が核になる。


x402の要点：402応答を“請求書”にして自動支払いを促す

　x402の要点は、Webの基本であるリクエスト／レスポンスの枠内に、課金の合図と支払い証明を組み込むことだ。

　サーバは「未払い」のアクセスに対してHTTP 402を返し、どの資産で、いくらを、どこに払えばよいかを機械が読める形式で示す。クライアントは提示内容に従って支払いを作成し、支払い結果（署名付きの支払い情報）をヘッダーに付けて再送する。

　サーバは受領を検証できたら200で応答し、失敗なら再び402や4xxで返す。なおx402でよく使われるステーブルコインは、法定通貨などに価値を連動させて価格変動を抑えた暗号資産のことだ。価格が大きく動くトークンよりも、APIの単価表示や会計処理を組み立てやすい。

誕生の背景：AIが外部サービスを買う時代に“決済のAPI”が足りない

　生成AIの普及で、AIが外部のAPIやデータベースを呼び出し、結果を統合してタスクを進める構成が現実になった。

　ところが支払いは、依然として人間がカード登録し、請求先を設定し、権限を付与する流れが中心だ。この前提だと、エージェントが必要な時だけ有料APIを使う、といった細かな最適化が難しい。たとえば、短時間だけ気象データを買って文章を生成したい場合でも、サブスクリプション契約やAPIキー発行が先に来てしまう。

　AIエージェントは「予算内で最短の手順を選ぶ」性質があるため、決済もプログラムから扱える形に寄せる必要が出てきた。ここでいうAPIキーは、呼び出し元を識別するための長い文字列で、漏えいすると第三者が不正利用できる。また、月額課金は使わない月でも固定費が出るため、エージェントが大量の小タスクを試行錯誤する状況ではコストが読みづらい。

　x402は「未払いなら402で止める」という単純な合図を共通化し、必要になった瞬間だけ支払って先へ進む選択肢を用意する。

HTTPステータスコード402との関係

　HTTP 402（Payment Required）は、ブラウザや一般的なWebアプリで広く使われてこなかった特殊なステータスコードだ。

　x402は、この“空いていた番号”を支払い要求の合図として復活させ、サーバが支払い条件を返すための慣習を定めた。ポイントは、402を単なるエラーメッセージではなく、次に取るべき行動（支払って再試行）を機械に示すプロトコルとして扱うことにある。

　結果として、HTTPクライアントは「402なら支払い処理を走らせる」という分岐を書けるようになり、決済をUIの外へ追い出せる。この設計は、認証（誰か）と課金（払ったか）を分け、必要に応じて組み合わせる余地も残す。

　4xxは一般に「クライアント側の条件不足」を表すため、未払いという不足条件を示すのに合う。さらに、サーバ実装としては“支払いが整えば同じリクエストを通す”だけなので、既存のAPIゲートウェイやミドルウェアにも組み込みやすい。

x402の基本：HTTP往復と検証で“支払い済み”を判定する

　x402の実装は、決済画面の代わりに「402応答」と「支払い証明」をHTTPで往復させる点に集約される。

　サービスは有料エンドポイントにミドルウェアを挟み、未払いなら402で支払い要件（支払う資産、金額、宛先、期限など）を返す。クライアントは要件に従って支払いを作成し、支払い情報をX-PAYMENTなどのヘッダーに付与して同じリクエストを再送する。サーバは取引の成立を自前で検証するか、ファシリテーター（検証を代行する外部サービス）に照会して「支払い済み」を判定する。

　このとき、同じリクエストが複数回届いても同じ結果になるように設計する（冪等性：何度実行しても結果が変わらない性質）と、再試行が増える環境でも事故を減らせる。

　また、支払い確認が取れた後にだけデータを返すため、無料枠と有料枠をURLで分けなくてもよい。課金単位を「1回のGET」「1回の推論」などに切り出しやすいのも、HTTPに寄せた利点だ。

リクエストから決済完了まで：402→支払い→再リクエストの最短ループ

　基本フローは驚くほど短い。クライアントが有料URLへ通常のHTTPリクエストを送ると、サーバは402で返し、ボディに支払い条件を載せる。

　クライアントは条件を解析し、ウォレット（暗号資産を送受信するための鍵と残高を管理する仕組み）で支払いトランザクションを生成する。支払いが完了したら、取引ハッシュや署名などの証明をHTTPヘッダーに入れて同じリクエストを再送する。

　サーバはその証明を検証し、支払いが確認できれば200で本来のデータを返す。

段階	HTTP応答/動作	実装の勘所
1	クライアントがリクエスト	価格表示はサーバ側で固定しやすい
2	サーバが402で要件提示	期限やリプレイ対策の情報を含める
3	クライアントが支払い実行	失敗時は再取得や別手段にフォールバック
4	ヘッダー付きで再送	同一リクエストIDで二重課金を防ぐ
5	検証後200で返す	検証結果をログに残し監査しやすくする

Solanaが採用される理由：低手数料と高速確定で“1リクエスト課金”を成立させる

　x402自体はネットワーク非依存を掲げるが、実装はいくつかの手法がある。その一例として非常によく利用されるのがSolana（ソラナ）だ。

　Solanaが使われるのは、1回の支払いコストを極小化しやすいから。Solanaの基本手数料は署名1つ当たり5000ラムポートで、最初の署名者が支払う。また1SOLは10～9ラムポートであるため、単純計算では0.000005SOLが基本手数料になる。

　すなわち、数円以下のマイクロペイメントでも手数料負けしにくい。さらに優先手数料を上乗せできる設計なので、混雑時だけ追加コストで処理優先度を上げる運用も可能だ。

x402の補完技術：AP2とは何か？何が違う？

　AP2（Agent Payments Protocol）とは、グーグルが提唱したエージェント主導の決済を安全に扱うためのオープンプロトコルのこと。既存のMCP（AIモデルをつなぐための標準プロトコル）やA2A（Agent to Agent））を拡張して、エージェント間のやり取りに支払いを組み込む枠組みを提供する。

開発・推進する企業

　グーグルの発表によれば、マスターカード、ペイパル、アメリカン・エクスプレスなど60社以上の業界パートナーが関わっているという。

AP2はx402を補完するもの

　AP2はx402と競合する規格ではなく、補完関係にある。x402はHTTPを支払いに利用できる仕組みなのに対し、AP2は誰にどんな条件で支払いを任せるのかを決める仕組みである。

x402の強み：自律決済・Web親和性・低コストを同時に狙う

　x402の強みは、決済を「人が行う手続き」から「ソフトウェアが呼び出す処理」へ落とし込む点にある。HTTP 402を合図にすれば、APIクライアントは支払い処理を共通化でき、サービスごとにバラバラな購入画面や請求書フローを用意しなくてよい。

　支払いに必要な情報がHTTPレスポンスとして返るので、AIエージェントは“必要になった瞬間”に支払いを実行し、すぐに次のタスクへ進める。また、支払い情報はヘッダーで渡せるため、REST APIやWebhookなど既存のWeb設計と衝突しにくい。結果として、従量課金の表現力が増し、低単価のデータや機能を売りやすくなる。とくに“ツールを選んで買う”エージェントには、この粒度が効く。

自律決済の設計：エージェントが条件を読んで払える“機械可読な請求”

　AIエージェントが自律的に決済できるためには、支払い条件が曖昧でなく、プログラムが安全に解釈できる必要がある。x402では、サーバが402応答で支払い要件をJSONとして返すため、金額や受取先をテキストの説明から推測する必要がない。

　エージェントは、与えられた予算やポリシー（例：1回当たり上限、許可する通貨、許可する宛先）に照らして支払うかどうかを判断できる。

　さらに、支払い証明をヘッダーで返すだけなので、ブラウザのフォーム入力や二要素認証のようなUI依存の手続きが入りにくい。ここでノンスについても説明しておく。ノンスとは、同じ支払い情報を何度も使い回す攻撃を防ぐための一度きりの識別子だ。サーバがノンスの未使用を確認してから受領とみなせば、再送が多い環境でも二重利用を避けられる。


API・Webサービスとの親和性：HTTP標準の延長で課金を扱える

　x402が扱う対象は、APIだけではない。HTTPで提供できるあらゆるリソースに「支払いが必要」という状態を付与できる。

　サーバ実装は、未払いなら402で返すだけなので、APIゲートウェイやリバースプロキシの段階で課金判定を差し込める。クライアント側も、既存のHTTPライブラリーに「402なら支払い処理を実行して再試行する」というハンドラーを追加すればよい。

　この構造は、OAuthのようにユーザー同意画面やトークン更新を伴う認証フローと比べ、決済に必要な分岐が少ない。さらに、ヘッダーで支払い証明を渡すため、コンテンツ配信（CDN）やキャッシュとの相性も設計次第で確保できる。

　Solanaのガイドが示す通り、HTTPレスポンスとヘッダーの往復で支払いを表現できるのが肝になる。CDNは、静的ファイルをユーザー近くのサーバに複製して配信を高速化する仕組みだ。有料リソースをCDNに載せる場合、支払い済みかどうかの判定をどこで行うかが問題になる。x402なら、オリジン側で検証して署名付きトークンを返し、そのトークンを短い有効期限でキャッシュキーに組み込む、といった構成が取りやすい。

マイクロペイメント向き：オンチェーン決済だけに頼らず“まとめ払い”もできる

　小額課金で難しいのは、決済の固定コストが単価を食ってしまう点だ。x402はHTTPの合図を決めるだけなので、実際の支払い方式を複数用意できる。

　オンチェーンとは、ブロックチェーン上に取引を記録して確定させる方式のことだ。たとえば毎回オンチェーン送金すると検証は単純だが、リクエスト回数が増えるほど手数料と待ち時間が積み上がる。

　そこでペイメントチャネル（当事者間で残高を更新し、最後にまとめて精算する方式）を使えば、リクエストごとの支払いは署名メッセージで済み、オンチェーン精算回数を減らせる。Solana上のx402ペイメントチャネル実装をうたうサイトでは、オンチェーン取引と比べてコストを99.8%節約できると説明している。


　チャネル型は、相手が途中で離脱した場合に備えて有効期限や最終状態の証明を持つ設計が欠かせない。その分、マイクロペイメントを“実用のコスト”に落とす余地が広がる。