x402：HTTP 402 で実際に支払う
数十年間使い道が定まらなかったステータスコードで API 呼び出しに課金する。機械同士の支払いは、どのコストを変えるのか？
2026 年 9 月時点で確認。出来事を扱うページでは、まず最後の「古くなる情報」を読んでください。
何が起きたか
| 時期 | 出来事 |
|---|---|
| HTTP の初期 | 「支払いが必要」を意味するステータスコード 402 が予約されましたが、標準的な使い方は定まりませんでした |
| 2025 年 5 月 | 大手暗号資産取引プラットフォームが x402 プロトコルを公開しました。未払いの要求にはサーバーが 402 と支払い条件を返し、クライアントはステーブルコインで支払った後、支払い証明を添えて再要求します |
| 2025 年後半 | 複数のインフラ企業が対応を発表し、AI Agent 向けの従量課金インターフェースが登場しました |
講座のモデルで分解する
第 35 章で扱った問題そのもの
第 35 章では、機械同士が API 呼び出し一回分をどう支払うかを考えます。その章の「実例」には、「数十年間使い道が定まらなかったステータスコード」という展示があります。x402 は、その空白を埋める一つの方法です。
手順は四つだけです。
- 要求する
- 402 と支払い条件が返る
- チェーン上で支払う
- 証明を添えて再要求し、結果を受け取る
どのコストが変わるのか
第 35 章では、支払いの粒度を月額契約、前払い、毎回のオンチェーン支払い、記帳後の一括決済に分けています。x402 が選ぶのは毎回の支払いです。削減するのは支払い関係を作るコストです。Agent が初めて API にアクセスするとき、人が代わりにアカウントを登録し、カードを紐づけ、契約する必要がなくなります（第 33 章：身分証のないソフトウェアはどう口座を開くか）。
削減されないのは一件ごとの決済コストです。したがって、ステーブルコインの送金が十分に安く、決済も十分に速いことが前提になります。高頻度の呼び出しでは、第 35 章の「計測してまとめて決済する」方法のほうが、依然として安く済みます。
誰がリスクを負うのか
第 34 章の問いに沿って考えます。自動で支払うプログラムにウォレットを渡す前に、どこに安全装置を置くべきでしょうか。
- 限度額：一回、一日、受取人ごとの上限。
- 許可リスト：事前に許可したサービスにだけ支払う。
- 取り消せるセッション鍵を使い、主鍵は渡さない。
自分で支払える Agent にとって、よくある損失は盗難よりも、払うべきでないお金を払うよう誘導されることです。プロンプトインジェクションに、もっともらしい 402 応答が組み合わされます（T33、T34）。
持ち帰る仕組み
- 支払いをプロトコルに組み込むと、最初に下がるのは一件ごとの費用ではなく、「支払いを始める」費用です。
- 支払いの粒度が細かいほど、限度額と許可リストが重要になります。百万回の呼び出しを一件ずつ人が承認することはできません。
- 機械の支払いは、人とは異なる安全モデルを必要とします。リンクをクリックするよう騙されなくても、文章で説得されます。
十八の問い
人が関与せずに支払いを完了し、支払ったことを証明する必要があるからです。従来の方法では、どちらにも先に人が口座を開く必要があります。
許可リストにあるサービスだけに支払い、一回と一日の上限を設け、鍵をいつでも取り消せるようにします。権限が小さいほど、失敗時の損失も限定されます。
Agent が誘導されて支払うと、お金はすでにチェーン上で決済され、取り戻せません。損失の上限は事後の責任追及ではなく、安全装置を設ける人が事前に決めます。
自分で確かめる
仕様の原文を探し、402 応答に含まれる項目を書き出します。金額、通貨、受取アドレス、有効期限を確認します。
呼び出し一回のシーケンス図を描きます。クライアント、サーバー、チェーン、その間で支払いを検証する主体を入れます。
安全装置を置ける場所を三つ示し、第 34 章のチェックリストと照合します。
古くなる情報
- プロトコルのバージョン、対応チェーンと通貨、参加企業は急速に変化しています。
- 機械の支払いには競合する方式もあり、どれが標準になるかはまだ決まっていません。第 35 章の「標準はどう勝つのか」で扱うのは、まさにこの過程です。