x402 とは

一言でいうと

「払うまで見せない。払えばすぐ見せる。」を、HTTP の標準の流れだけで実現する仕組みです。 アカウント登録もカード番号も要りません。サーバーが「これは有料です（402）」と返し、 買い手がその場で代金（jp402 の文脈では JPYC）を支払うと、 同じ URL からすぐに中身が返ってきます。

なぜ生まれたのか

これまでのオンライン決済は、すべて「人間がブラウザでカード番号を入れる」ことを前提に作られていました。 ところが AI エージェントが自律的に Web を使う時代になると、この前提が壁になります。

• エージェントはカード番号入力フォームや 3D セキュアの画面を操作できない（するべきでもない）。
• API 1 回・記事 1 本のような少額に、クレジットカードの手数料・最低課金は重すぎる。
• サービスごとにアカウント登録・APIキー発行をするのは、無数のサービスを横断する agent には現実的でない。

x402 は「支払いを HTTP リクエストの一部にしてしまう」ことでこれを解きます。 エージェントはページを取りに行く感覚で、そのまま代金を払えます。

仕組み — HTTP 402 の流れ

鍵は、ほとんど使われてこなかった HTTP ステータス402 Payment Required です。流れはこうなります。

① 買い手（AIエージェント）            ② 売り手のサーバー
   │  GET /article?id=42                  │
   │ ───────────────────────────────────▶ │
   │                                       │  「これは有料です」
   │   HTTP 402 Payment Required           │
   │   ＋ 支払い条件(いくら・どこへ・何で) │
   │ ◀─────────────────────────────────── │
   │                                       │
   │  条件どおり JPYC を送る署名を作る     │
   │  （ウォレットで EIP-3009 署名）       │
   │                                       │
   │  GET /article?id=42                   │
   │  ＋ 支払い署名を添付                  │
   │ ───────────────────────────────────▶ │
   │                          ┌──────────────────────────┐
   │                          │ ③ facilitator が         │
   │                          │   署名を検証し決済を実行  │
   │                          └──────────────────────────┘
   │   HTTP 200 OK ＋ 本文                  │
   │ ◀─────────────────────────────────── │
   ▼                                       ▼
 記事が手に入る                       JPYC を受け取る

• ① 普通に叩く — 買い手はまず欲しい URL を普通に GET します。
• ② 402 が返る — 有料リソースなら、サーバーは 402 と一緒に 「いくら・どのアドレス(payTo)へ・どの通貨で」という支払い条件を返します。
• ③ 払って再送 — 買い手はその条件どおりの支払い（署名）を作り、 その場の 402 が指定する支払いヘッダに載せて同じ URL をもう一度叩きます。
• ④ 検証して 200 — 支払いが正しければ、サーバーは 200 OK と本文を返します。

つまり「402 が返る → 払う → 200 が返る」という、たった 1 往復半の素直なやり取りです。 この最後の真実は常にその場の 402 応答であり、一覧や宣言ではありません （だから jp402 でも「価格・payTo は 402 を最終真実とする」と案内しています）。

登場人物は 3 者

• 買い手（client / AI エージェント） — リソースを取りに行き、402 を見て支払う側。
• 売り手（resource server） — 有料リソースを公開し、402 で条件を提示する側。 受け取り先アドレス（payTo）を持ちます。
• facilitator（決済の仲介者） — 売り手に代わって、買い手の署名を検証し、 実際のオンチェーン決済を実行・確定する役割。売り手はブロックチェーンの細部を知らなくても、 facilitator に「検証して」「決済して」と頼むだけで済みます。

x402 で専門性が要るのは主に facilitator です。売り手・買い手は「402 を返す／読む」だけでよく、 実装は驚くほど薄くなります。

従来の決済とどう違うか

• アカウント不要 — 事前登録もログインもなし。ウォレットさえあればその場で払えます。
• 少額に強い — 1 記事・1 API コールのようなマイクロペイメントが成立します。
• 機械が主役 — 画面操作でなく HTTP ヘッダで完結するので、AI エージェントが自分で払えます。
• オープン標準 — 特定企業の SDK に縛られず、HTTP と署名の規約に従えば誰でも実装できます。

x402 と JPYC

x402 自体は通貨を選びません。jp402 は、その支払い通貨をJPYC（日本円ステーブルコイン）、ネットワークをPolygon に絞った世界を扱います。理由は 3 つあります。

• 円建てで分かりやすい — 価格も会計も日本円のまま。為替を介しません。
• ガス不要の支払い体験 — JPYC は EIP-3009（署名による送金）に対応し、 買い手は「送金の許可に署名するだけ」。ガス代の支払いは facilitator 側に寄せられます。
• 適格請求書とつながる — 日本の経理（T 番号・適格請求書）と接続できる余地があり、 支払いと帳簿を地続きにできます。

JPYC (Polygon / eip155:137) · asset 0xe7c3d8c9a439fede00d2600032d5db0be71c3c29 · decimals 18

では jp402 は何をするのか

x402 は「払う仕組み」ですが、「どこで買えるか」を見つける仕組みは別に要ります。 jp402 はそのディスカバリー（発見）層です。 JPYC（Polygon）で支払える x402 リソースを台帳から集め、一覧・選別・詳細表示し、 買い手エージェントが最初に叩く発見の入口になります。

掲載台帳は GitHub に公開（jp402-registry）、 実績はチェーンが証明します。「載る」と「信頼される」は分けて扱い、判断は利用者・エージェントに委ねます。

もっと知る

• jp402 のよくある質問（FAQ） — 売り手の載せ方・買い手の使い方・信頼の考え方。
• トップで実際のリソース一覧と経済スナップショットを見る。
• x402 の公式情報（x402.org） — プロトコルの一次情報。