x402とMPP — マシン間決済レールの全貌

x402とMPPとは何か

x402は、Coinbaseが開発しLinux Foundation傘下で運営されるオープンな決済プロトコルです。HTTPの「402 Payment Required」ステータスコードを活用し、AIエージェントがWebリソースにアクセスする際にステーブルコイン（USDC）で即時決済を行う仕組みを提供します。アカウント登録やAPIキーが不要で、支払い証明そのものがアクセス資格になるのが特徴です。

MPP（Machine Payments Protocol）は、StripeとTempo Labsが共同開発したセッションベースの決済プロトコルです。AIエージェントが1秒間に数千回のAPIコールを行うような高頻度シナリオ向けに設計されており、オフチェーンのストリーミング決済でマイクロペイメントを効率的に処理します。

どちらも「AIエージェントがサービスに対して自律的に支払いを行う」ためのインフラですが、設計思想と対象領域が異なります。以下でその違いを詳しく見ていきます。

マシン間決済レールを巡る2つのアプローチ

AIエージェントが1時間に数千回のAPIコールを実行し、それぞれに0.01ドルの対価を支払う。この「マシン間決済」を成立させるインフラとして、2つのプロトコルが急速に形を整えています。CoinbaseがインキュベートしLinux Foundation傘下に移管されたx402と、StripeとTempo Labsが共同開発したMPP（Machine Payments Protocol）です。

どちらもHTTPの402 Payment Requiredステータスコードをトリガーとして利用しますが、そこから先の設計思想は根本的に異なります。x402はリクエスト単位のステートレスな決済を、MPPはセッションベースのストリーミング決済を志向しています。この違いは単なる実装の差ではなく、「マシン経済のどの領域を担うか」という棲み分けに直結するものです。

エージェンティックコマースの決済インフラは、従来のカード決済とは根本的に異なる要件を持ちます。サブセント単位のマイクロペイメント、ミリ秒単位のレイテンシ、人間の介在なき自律決済。x402とMPPは、この要件にそれぞれ異なる角度から応えています。

x402 — HTTPに決済を織り込むプロトコル

30年越しのステータスコードが動き出す

HTTPの仕様に「402 Payment Required」が予約されたのは1997年のことです。「将来の利用のために」という一文とともに30年近く眠り続けたこのコードを、Coinbaseのエンジニアリングチームが2025年5月に目覚めさせました。

x402の決済フローは4ステップで完結します。エージェントが有料リソースにHTTPリクエストを送ると、サーバーがHTTP 402レスポンスで支払い条件（価格、トークン、チェーン、受取ウォレット）を返します。エージェントのウォレットがUSDCトランザクションに署名し、PAYMENT-SIGNATUREヘッダーに支払い証明を添えてリクエストを再送信。サーバーはファシリテーター経由で決済を検証し、リソースを返却します。

この設計の核心は、支払い証明そのものがアクセス資格証明になる点です。アカウント登録もAPIキーも不要で、決済が完了した瞬間にアクセス権が発生します。WorkOSの比較分析が述べるように、「支払いの証拠がそのままクレデンシャルになる」というパラダイムです。

V2で何が変わったか

2025年12月にリリースされたx402 V2は、V1の最大の弱点に手を入れました。V1ではすべてのAPIコールに個別のオンチェーントランザクションが必要で、高頻度ワークフローでは実用性に欠けていたのです。

V2の改善は多岐にわたりますが、最も重要な変更は3つです。

第一に、ウォレットベースのセッション導入です。一度認証したクライアントはセッション内で決済ハンドシェイクを省略でき、レイテンシとオンチェーンコストの両方を削減します。第二に、プラグイン駆動のSDKへの再設計です。チェーン、アセット、決済スキームを内部コードを変更せずに登録できるモジュラー構造により、Base・Solana・Polygon、さらにACH・SEPA・カードネットワークといったレガシーレールへの拡張が容易になりました。第三に、マルチファシリテーター対応です。SDKが複数のファシリテーターから最適なものを自動選択する仕組みにより、単一障害点が排除されています。

この改善の結果、x402は2025年5月のローンチ以降、1億件以上の決済を処理しています。

MPP — セッションで決済を「流す」プロトコル

毎秒数千回のAPIコールという現実

x402がリクエスト単位の決済に最適化されているのに対し、MPPが見据えるのは別の風景です。データフィードを毎秒ポーリングするAIエージェント、ヘッドレスブラウザを連続起動するオートメーション、LLM推論の結果を逐次受け取るストリーミングワークロード。こうした高頻度シナリオでは、1回ごとにブロックチェーンへ書き込むモデルはコスト的にも速度的にも成り立ちません。

2026年3月18日、StripeとTempo Labsが共同発表したMPPは、この課題にセッションという概念で応えました。エージェントは事前にエスクローへ支出上限を預託し、セッション内では暗号署名されたバウチャー（オフチェーンの支払い証書）をストリーミングし続けます。サーバーはバウチャーを蓄積し、セッション終了時にまとめてオンチェーン決済する仕組みです。

"

誰でも許可なく拡張できる、最もエレガントで最小限のプロトコルを目指した。

出典: Matt Huang（Paradigm共同創業者）

Tempoチェーンの役割

MPPのストリーミング決済を支える決済レイヤーが、Tempo Labsが構築した専用L1ブロックチェーンです。

Tempoが従来のブロックチェーンと決定的に異なるのは、ネイティブガストークンを持たない点です。手数料はステーブルコインで支払われます。これによりエージェントがETHやSOLといったボラタイルなトークンを保有・管理する必要がなくなり、決済レイヤーとしての予測可能性が確保されています。

さらに、Tempoはトランザクションレベルのアカウントアブストラクションを実装しています。人間のユーザーが暗号学的に拘束された委任（使用可能トークン、累積上限額、有効期限）をエージェントに付与し、エージェントはその範囲内で自律的に支出を実行します。毎秒数万件のトランザクション処理とサブ秒のファイナリティにより、ストリーミング決済のバックエンドとして機能しています。

フィアットとの橋渡し

MPPのもう一つの特徴は、ステーブルコインとフィアットのハイブリッド決済をプロトコルレベルでサポートしている点です。サーバーはHTTP 402レスポンスで複数の決済オプションを同時に提示でき、エージェントはTempo上のステーブルコイン、Stripe SPT経由のカード決済、Lightning Networkなどから選択します。

この設計により、MPPはステーブルコインを受け入れないマーチャントに対してもフィアットで決済でき、逆にクリプトネイティブなサービスにはオンチェーン決済で対応できます。Crossmintの比較分析が指摘するように、「MPPは決済レールの選択をエージェントに委ねる」設計であり、マーチャント側の対応負荷を最小化しています。

技術的核心の対比 — ステートレス vs セッション

では、x402とMPPは技術的にどう違うのか。最も本質的な差異は、状態管理のモデルにあります。

x402はステートレスです。各リクエストが独立した決済を含み、前後のリクエストと関係を持ちません。RESTfulアーキテクチャの原則に忠実であり、サーバーはクライアントの状態を一切保持しません。この設計はシンプルさとパーミッションレス性をもたらします。サーバーにとっては1行のミドルウェア追加で決済対応が完了し、エージェントにとってはウォレットさえあればどのリソースにもアクセスできます。

MPPはセッショナルです。エージェントとサーバーの間に継続的な決済チャネルが開かれ、そのチャネル内でマイクロペイメントがストリーミングされます。この設計は効率性と柔軟性をもたらします。QuickNodeの技術分析によれば、MPPはプロトコルレベルでcharge（リクエスト単位課金）とsession（従量課金）の2つのビリングインテントを区別しており、ユースケースに応じた最適な決済パターンを選択できます。

この対比から浮かび上がるのは、両プロトコルが同じ問題の異なる部分を解いているという構図です。x402はロングテールの決済アクセスを、MPPは高頻度の決済効率を最適化しています。

x402 Foundation — オープンガバナンスへの移行

2026年4月2日、Linux Foundationがx402 Foundationの設立を発表しました。Coinbaseがインキュベートしたx402をベンダー中立なオープン標準として発展させるための組織です。

注目すべきは参加企業の顔ぶれです。Cloudflare、Stripeが共同創設メンバーとして名を連ね、AWS、Google、Microsoft、Visa、Mastercard、American Express、Shopify、Adyen、Circle、Solana Foundationなど22の組織が初期参加しています。

ここで見逃せないのは、Stripeが双方に参加している事実です。StripeはMPPの共同開発者であると同時に、x402 Foundationの共同創設メンバーでもあります。Stripeのエージェンティックコマース戦略から読み取れるのは、MPPとx402を競合ではなく決済インフラの異なるレイヤーとして扱う姿勢です。MPPがStripeの商用決済スタック上で動作し、x402がオープンネットワーク上のパーミッションレス決済を担う。この棲み分けは、Linux Foundationという中立的なガバナンス構造のもとで制度化されつつあります。

Google Cloudの担当者は「エージェンティックコマースへの移行には、それを支えるプロトコルと同じくらいオープンなクラウドインフラが必要だ」とコメントしています。

実装の現在地 — 数字が語る採用状況

プロトコルの設計思想がどれほど洗練されていても、問われるのは実際のトラクションです。

x402は2026年3月時点で日次約13.1万件の取引、約2.8万ドルの処理額を記録しています。1件あたりの平均決済額は0.20ドル。累積ではBase上で1億1,900万件、Solana上で3,500万件、年率換算で約6億ドルの処理量に達しています。ただし、CoinDeskの分析が指摘するように、取引の約半数はインフラテストや自己取引であり、実需ベースのトラクションはまだ限定的です。

一方のMPPは2026年3月18日にローンチしたばかりで、ローンチ時点で100以上のサービスが統合されています。BrowserbaseやPostalFormといった実装パートナーが稼働していますが、意味のある取引量データはまだ公開されていません。

両プロトコルとも「インフラが先行し、実需が追いつく過程」にあることは共通しています。ただし、x402が1年近い実績データを持つのに対し、MPPはStripeの既存マーチャントベースという強力な配布チャネルを持つ点で、今後の成長軌道は異なる可能性があります。

決済プロトコルスタックの中での位置づけ

x402とMPPは、エージェンティックコマースの決済スタックにおいて「決済実行層」を担うプロトコルです。この位置づけを理解するには、上位レイヤーとの関係を見る必要があります。

GoogleのAP2（Agent Payments Protocol）は、暗号署名されたMandateによるエージェント決済の認可フレームワークです。AP2が「誰が・何を・いくらまで」の認可を定義し、x402やMPPが実際の決済実行を担います。Crossmintの比較が示すように、本番環境では複数プロトコルの要素が組み合わさって機能する設計です。

では、開発者はどちらを選ぶべきか。WorkOSの推奨は明快です。パーミッションレスなAPIやインディー開発者向けサービスにはx402。ベンダー登録不要、ウォレットとミドルウェアだけで決済を受け入れられる手軽さが強みです。既にStripeを利用しておりエージェントトラフィックを受け入れたい場合はMPP。既存の決済スタックを再構築せず、設定変更レベルでマシン間決済に対応できます。

そして多くの場合、最終的な答えは「両方」になるでしょう。x402 Foundationにおける Stripeの参画が示唆するように、2つのプロトコルは同じインフラの異なるレイヤーとして共存する方向に進んでいます。

まとめ

x402とMPPは、マシン間決済という同じ領域に異なるアーキテクチャで取り組んでいます。x402がHTTPプロトコル層にステートレスな決済を埋め込み、MPPがセッションベースのストリーミング決済で高頻度ワークロードに対応する。x402 Foundation設立とStripeの双方参画は、両者の補完関係を制度的に裏付けるものです。マシン経済のインフラ整備はまだ始まったばかりですが、決済レールの基本構造は定まりつつあります。