なぜx402と呼ばれますか？HTTPステータスコード402とは何で、支払いとどのような関係がありますか？
HTTPステータスコードはサーバーがクライアントに「このリクエストの結果は何か」を伝える数値コードです。誰もが知っているのは404（ページが見つからない）、200（成功）、500（サーバーエラー）です。
402はHTTP仕様でほとんど正式に使用されたことがないステータスコードで、公式の定義は「Payment Required（支払いが必要）」です。このステータスコードは1990年代にHTTP仕様に設計されましたが、当時は適切なデジタル支払いインフラがなかったため、402は眠り続けました。
x402プロトコルは30年間眠っていたこのステータスコードを覚醒させました。APIまたはサービスがアクセスに支払いを要求する場合、HTTP 402を返し、レスポンスヘッダーに支払い情報（支払い金額、受取アドレス、受け入れるトークン種類）を付属させます。x402対応のエージェントは402レスポンスを読み取り、自動的にオンチェーン支払いを完了し、支払い証明とともにリクエストを再送します。
この設計の優雅さ：「リクエスト→支払い要求→支払い→再リクエスト→サービスへのアクセス」のフロー全体が、既存のHTTPプロトコルフレームワーク内で完全に完了し、新しいネットワーク層や通信プロトコルは不要です。
x402トランザクションで、エージェントは二重請求（重複支払い）やサービスプロバイダーによる詐欺（支払ったがサービスを受けられない）をどう避けますか？
これらはx402設計における本物の課題です。現在のx402仕様はいくつかのメカニズムでこれを処理します：
重複支払いの防止：x402の支払いリクエストは一意のnonce（一度限りのランダム値）とタイムスタンプを使用します。サービスは支払いを検証した後、nonceを使用済みとしてマークします——同じ支払い認証情報は再度受け入れられません。
サービス未提供詐欺の防止：これはプロトコルレイヤーで完全に解決するのが難しいです。現在の緩和策：評判の高いサービスプロバイダーを使用；支払いごとの上限設定；ERC-8004を通じたサービスプロバイダーの評判照会；スマートコントラクトによる条件付き支払い（サービス提供確認後に資金解放）——この方向はまだ開発中です。
現実的な考慮事項：x402は現在、少額・標準化されたサービス支払い（API一回の呼び出し、レポート一件のダウンロード）に最適で、大規模または複雑な納品要件を持つ支払いには向いていません。
x402と従来のAPIキー課金モデルを比較すると、開発者とサービスプロバイダーそれぞれにどんなメリット・デメリットがありますか？
従来のAPIキー課金（月額サブスクリプション/従量課金）：サービスプロバイダーのメリット：予測可能な収益、成熟した課金システム。開発者のメリット：シンプルで直感的、明確なコスト上限。デメリット（両者）：アカウント作成とクレジットカードが必要；APIキー管理はセキュリティリスク；AIエージェントは独立してアカウントを作成できない。
x402課金：サービスプロバイダーのメリット：ゼロフリクションのアクセス（ウォレットを持つエージェントは誰でも支払え、KYCやアカウント作成不要）；グローバル（ステーブルコインを受け入れ、地域制限なし）；リアルタイム決済。エージェントのメリット：人間のアカウントを仲介とせずに自律的にサービスを選択・切り替えできる。デメリット：非常に小額の支払いではオンチェーン手数料がコスト効率を低下させる可能性；従来のカスタマーサービスや請求争議メカニズムがない；現在のエコシステム成熟度は従来のAPIよりはるかに低い。
x402はマルチエージェント（Agent-to-Agent）の支払いシナリオでどう機能しますか？なぜA2AマイクロペイメントがAIエージェント経済の重要なインフラと見なされていますか？
マルチエージェントシステムでは、「マスターエージェント」が複数の「サブエージェント」にサブタスクを委任し、各サブエージェントが仕事の一部を完了して、マスターエージェントが結果を集約するかもしれません。問題は：サブエージェントは本物の仕事と価値を提供している——どうやって報酬を得ますか？
従来のアプローチではこれを解決できません：サブエージェントが異なる組織や個人によって運営されている場合、すべてのAPIキーアカウントを事前に設定することはできず、従来の支払いで各マイクロ作業単位に支払うことも不可能です（1回のAPI呼び出しに$0.001を支払う——クレジットカードはその粒度の支払いをサポートしていない）。
x402がA2Aマイクロペイメントを技術的に可能にします：マスターエージェントがサブエージェントのサービスを呼び出す；サブエージェントのエンドポイントが402 Payment Requiredを返す；マスターエージェントがステーブルコインのマイクロペイメントを自動的に完了する；サブエージェントが受領を確認してサービスと結果を提供する。
なぜ重要なインフラと見なされるか：エージェントが真に「分散型サービス市場」を形成できるようにします——誰でも特定の専門サービスを提供するエージェントを展開し、作業量に応じて即時支払いを受け取れます。これが「機械自律経済」のインフラパズルです。
x402の実際の動作：クリプトリサーチエージェントがオンチェーン分析データの支払いをする
シナリオ：リサーチエージェントが過去30日間のETHウォレット資金フロー分析を取得する必要があります（このタイプのデータは通常支払いが必要）。
ステップ1：エージェントがリクエスト送信 GET /analytics/eth-whale-flow?days=30
ステップ2：サービスが402を返す：HTTP 402 Payment Requiredと支払い情報をヘッダーに附属（金額：0.50 USDC、宛先アドレス、ネットワーク：Base、nonce）
ステップ3：エージェントが自動的に支払い完了：エージェントのウォレットから0.50 USDCをサービスウォレットに送金、nonceを支払い識別子として添付。Base チェーンで確認。
ステップ4：エージェントが支払い証明とともに再リクエスト：トランザクションhashをヘッダーに添付して再送
ステップ5：サービスがデータを返す：HTTP 200とウォレット資金フロー分析データ
フロー全体は約5〜10秒（Baseチェーンの確認時間含む）、完全自動化で人間の操作なし。
x402の核心的なトレードオフは「分散型の自律性対成熟度とセキュリティ」です。
メリット：エージェントの真の自律的支払い能力、人間のアカウントやクレジットカード不要；超細粒度の従量課金（$0.001レベル）；グローバルで地域制限なし；A2Aマルチエージェントの経済モデルを実現可能にする。
デメリット：エコシステムはまだ未成熟で、x402をサポートするサービスプロバイダーの数が限られている；ガス代が超小額支払いのコスト比率を高くする；返金メカニズムがない；エージェントウォレット管理自体がセキュリティ課題；サービスプロバイダーやプロトコルに脆弱性があれば、エージェントのウォレットが自動的に枯渇する可能性がある。
現在最適なシナリオ：支払いごとの金額が$0.10以上（ガス比率を合理的に保つ）、オンチェーン評判を持つ信頼できるサービスプロバイダーの使用、エージェントウォレットには少額の運転資金のみ保管（主要資産ではない）。