- 2026/01/22 掲載
x402とは何かをわかりやすく解説、AIエージェントで「必須級」決済プロトコルの詳細
x402とは:HTTPへ決済情報を埋め込む
x402とは、HTTP通信の中で「支払い要求→支払い→再試行」を完結させる、オープンなインターネットネイティブ(Web標準に沿った)な決済プロトコルのこと。つまり、HTTP通信を有料化する仕組みと言える。世界最大級の暗号資産取引プラットフォームのコインベース(Coinbase)が開発し、オープンソースで公開された。仕組みとしては、サービス側が有料エンドポイントへのアクセスを受けると、まずHTTP 402を返し、JSONで支払い条件(金額、受取先、利用できる決済手段など)を提示する。クライアントは条件を満たす支払いを実行し、支払い情報をHTTPヘッダーに載せて同じリクエストを送り直す。
結果として、会員登録やカード入力、請求書処理といった「人間の手」を前提にした工程を減らし、APIやデジタルコンテンツを呼び出した分だけ課金しやすくする。「支払い=別画面」という常識を、HTTPの往復だけで置き換える発想が核になる。
x402の要点:402応答を“請求書”にして自動支払いを促す
x402の要点は、Webの基本であるリクエスト/レスポンスの枠内に、課金の合図と支払い証明を組み込むことだ。
サーバは「未払い」のアクセスに対してHTTP 402を返し、どの資産で、いくらを、どこに払えばよいかを機械が読める形式で示す。クライアントは提示内容に従って支払いを作成し、支払い結果(署名付きの支払い情報)をヘッダーに付けて再送する。
サーバは受領を検証できたら200で応答し、失敗なら再び402や4xxで返す。なおx402でよく使われるステーブルコインは、法定通貨などに価値を連動させて価格変動を抑えた暗号資産のことだ。価格が大きく動くトークンよりも、APIの単価表示や会計処理を組み立てやすい。
- HTTPだけで完結:別の決済画面やセッション管理を前提にしない
- 自動化前提:クライアントがプログラムで支払い処理を実行できる
- 小額課金と相性:1リクエスト単位の従量課金に寄せやすい
- 実装は段階的:自前検証も、ファシリテーター利用も選べる
- 認証と課金を分離:ログインは必要な場面だけに戻せる
生成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往復と検証で“支払い済み”を判定する
決済・キャッシュレスのおすすめコンテンツ
PR
PR
PR