x402とは何かをわかりやすく解説、AIエージェントで「必須級」決済プロトコルの詳細(2/4)

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親和性・低コストを同時に狙う