x402 vs MPP:エージェント決済プロトコルの比較

2026年3月18日公開読了時間 1 分

自律型エージェントは支払いを行う必要がある。いつかではなく、今すぐにだ。エージェントがブロックチェーンデータをクエリするたび、LLMトークンをストリームするたび、有料APIを呼び出すたびに、誰かが課金を処理しなければならない。現状ではそれはAPIキー、課金ダッシュボード、人手によるプロビジョニングを意味する。この問題の解決を試みているのが2つのプロトコル、x402とMPPだ。

2024年後半、Coinbaseはx402を発表した。これはAIエージェントがAPIを呼び出し、「支払いが先」というレスポンスを受け取り、Base上のUSDCで決済し、リトライするというプロセスを、APIキー、課金アカウント、人手による介入なしで実現するオープンプロトコルだ。その後、TempoとStripeはこの発想をさらに推し進め、Machine Payments Protocol（MPP）を開発した。IETF Internet-Draftで定義されたMPPは、402パターンを一般化し、単一のプロトコルを通じてステーブルコイン、カード、銀行振込、そして将来のあらゆる決済手段をサポートする、支払い方法に依存しないフレームワークとしている。

この記事では、両プロトコルの比較、重なり合う部分、そしてどちらを選ぶべきかについて解説する。

概要

	x402	MPP
決済レール	Base上のUSDCおよび他ネットワーク	ステーブルコイン、カード、銀行振込：プラガブル
決済モデル	単発（exact）	単発（charge）+ セッション
セッション対応	なし	あり（エスクロー + 署名付きバウチャー）
プロトコルプリミティブ	実装依存	標準化済み（冪等性、有効期限、レシート、リプレイ防止）
トランスポート	HTTP	HTTP + MCP
標準化状況	オープンソース、コミュニティ採用	IETF Internet-Draft（TempoとStripeの共著）

x402とMPPは決済のコアフローをどう扱うか

両プロトコルの核となる部分は同じフローに従う。エージェントがAPIを呼び出し、サーバーが支払いチャレンジを返し、クライアントが支払いを行ってリトライし、レスポンスを取得する。シンプルで、洗練されていて、HTTPネイティブだ。

違いが出るのは、スコープ、柔軟性、そして各プロトコルが何を標準化することを選んでいるかだ。

x402とMPPは決済レールをどう扱うか

x402はオンチェーンのステーブルコイン決済、主にBase上や他のサポート対象ネットワーク上のUSDCを中心に構築されている。ユースケースがステーブルコインで支払うクリプトネイティブなエージェントであれば、x402はそこへの直接的な経路を提供する。

MPPは異なるアプローチを取る。プロトコル自体は支払い方法に依存しない。コア仕様はサーバーとクライアントがどのように交渉し、チャレンジし、決済するかを定義するが、実際の決済レールはプラガブルなレイヤーだ。現在、MPPは2つのプロダクション用の決済方法を提供している：Tempo（ステーブルコイン決済）とStripe（カード、ウォレット、その他の従来型決済方法）で、サーバーは両方を同時に提示できる。クライアントは自分がサポートする方法を選択する。

誰でもリクエストスキーマとペイロードスキーマを指定することで、新しい決済方法を定義できる。財団や仲介者からの承認は不要だ。決済方法は許可ではなく、採用度合いで競争する。

クリプトネイティブなオーディエンス向けに構築しているのであれば、x402が最速の経路となる。エンタープライズクライアント、従来型決済インテグレーター、あるいは混在するオーディエンス向けに構築しているのであれば、MPPのマルチレール対応によってどちらか一方を選ぶ必要がなくなる。従来型のマーチャントと直接取引する必要があるエージェントについては、AgentCardのようなプロジェクトが補完的なアプローチを取っている。エージェントがオンライン購入に使えるクレジットカードを発行し、支出上限とリアルタイム追跡を組み込んでいる。

それぞれどの決済モデルをサポートしているか

x402は「exact」決済モデルに焦点を当てている：1回のリクエスト、1回の支払い、1回のレスポンス。これはシンプルで理解しやすく、個々のAPI呼び出しに適している。

MPPはchargeインテントを通じて同じフローをサポートしており、実際、x402のexactフローはMPPのchargeに直接マッピングされるため、この層において両プロトコルは互換性がある。

しかしMPPはさらに、高スループットのユースケース向けに根本的に異なる決済モデルであるセッションも導入している。セッションでは、クライアントが一度だけエスクローコントラクトに資金をデポジットし、その後、オフチェーンの署名付きバウチャーを使って多数のリクエストを行う。サーバーは定期的に蓄積されたバウチャーをオンチェーンで決済する。

それぞれのフローの簡略化した図解は以下の通り：

X402：1回のリクエスト、1回の支払い

text

Copied

# Step 1: Call the API
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1

# Step 2: server responds with payment challenge
HTTP/1.1 402 Payment Required
X-Payment-Challenge: {"amount": "0.001", "currency": "USDC", "address": "0x..."}

# Step 3: client pays on-chain, retries with receipt
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
X-Payment: {"txHash": "0x...", "signature": "0x..."}

# Step 4: server verifies and responds
HTTP/1.1 200 OK

MPPセッション：一度のデポジットで数千回のリクエスト

text

Copied

# Step 1: Open a session (deposit funds to escrow once)
POST /mpp/sessions HTTP/1.1
{"amount": "10.00", "currency": "USDC", "method": "tempo"}

HTTP/1.1 201 Created
{"sessionId": "sess_abc123", "balance": "10.00"}

# Step 2: make requests with signed vouchers (no on-chain tx per request)
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
MPP-Session: sess_abc123
MPP-Voucher: {"amount": "0.0001", "nonce": 42, "sig": "0x..."}

HTTP/1.1 200 OK  # Sub-100ms, no waiting for chain confirmation

MPPセッションが可能にすること：

リクエストあたり**$0.0001**という小額の支払い
サブ100msのレイテンシー：リクエストごとのオンチェーン確認が不要
ほぼゼロに近いリクエストあたりの手数料：ネット決済のみがチェーンに反映される

重要な理由： トークン単位課金のLLMストリーミング、高スループットのデータフィード、リアルタイムのチェーン監視、これらすべてが経済的に成り立つようになる。すべてのやり取りごとにオンチェーンで支払うと、データの価値以上にガス代がかかってしまう。セッションはこの計算をひっくり返し、マイクロペイメントベースのアクセスを大規模に実用的なものにする。

それぞれどのプロトコルレベルのプリミティブを提供しているか

MPPはいくつかのプロダクション上の懸念事項をプロトコル仕様自体に組み込んでいるため、各実装はそれらを再発明することなく継承できる：

冪等性： 二重課金なしでの安全なリトライ
有効期限： チャレンジがタイムアウトし、古い支払いを防止
リクエストボディのバインディング： SHA-256ダイジェストがチャレンジと支払いの間の改ざんを防止
リプレイ防止： HMACに紐づけられたチャレンジID
構造化エラー： 機械可読なエラー処理のためのRFC 9457形式
ファーストクラスのレシート： 監査用に標準化された支払いレシート

x402はこれらの一部を実装レベルで扱っているが、残りは個々の開発者に委ねている。MPPはこれらを標準化しているため、サーバーとクライアントは初めから同じ言語で話すことができる。これは異なるベンダーのエージェントが確実に相互運用する必要がある場合に重要となる。

MPPはHTTP以外でも動作するか

x402はHTTP上で動作する。MPPもHTTP上で動作するが、それに加えてMCP（Model Context Protocol）のトランスポートバインディングを追加している。

これにより、MCPツールサーバーはツール呼び出しを直接マネタイズできる。有料ツールを呼び出すAIエージェントは、ツールのレスポンス内で支払いチャレンジを受け取り、支払いを行い、リトライする。すべてMCPのメッセージフロー内で完結する。OAuthは不要。アカウント設定も不要。HTTP層も不要。

これまで、AIツール呼び出しのマネタイズには帯域外の課金やプラットフォームとの契約が必要だった。MPPのMCPトランスポートによって、開発者はどんなMCP互換エージェントでも発見し、支払い、自律的に利用できる有料ツールを公開できるようになり、人手を介する必要がない。

標準化についてはどう比較されるか

x402はオープンソースのプロトコルで、コミュニティでの採用が拡大している。Coinbaseでの本番運用で実績があり、エコシステム全体でのサポートも広がりつつある。

MPPのコア部分であるPayment HTTP Authentication Schemeは、TempoとStripeの共著によるIETF Internet-Draftとして提出されている。決済方法とインテントは別個の仕様であり、誰でも独立に作成・公開できる。これはウェブ自体の仕組みを反映している：HTTPは標準化されているが、コンテンツタイプや認証スキームは独立に進化する。

Internet-Draftは作業中の文書であり、まだ標準化トラックのRFCではないが、IETFへの提出は長期的な相互運用性と安定性に向けた意図を示すものだ。

x402とMPPには互換性があるか

ある。MPPはx402と後方互換性がある。x402のコアである「exact」決済フローはMPPのchargeインテントに直接マッピングされるため、MPPクライアントは既存のx402サービスを利用できる。すでにx402の上に構築している場合、MPPはそれを置き換えるのではなく拡張する。

Alchemyで構築を始める

AlchemyはそのAPIプラットフォーム全体でx402とMPPの両方をサポートしている。つまり、エージェントはブロックチェーンデータ（トークン残高、NFTメタデータ、トランザクション履歴、スマートコントラクトの読み取り、価格フィードなど）にアクセスし、いずれかのプロトコルを使ってリクエストごとに支払うことができる。APIキーは不要。課金ダッシュボードも不要。ウォレットとHTTP呼び出しだけで済む。

x402では、エージェントはSIWE（Sign-In with Ethereum）またはSIWS（Sign-In with Solana）で認証し、Base上のUSDCで支払い、Alchemyのエンドポイントにアクセスできる。MPPでは、同じエージェントが決済方法間で交渉し（Tempo経由のステーブルコイン、Stripe経由のカード）、インデックス作成パイプラインやリアルタイムのチェーン監視といった高スループットのワークロードにはセッションを利用できる。

構築できるもの：

自律型ブロックチェーンエージェント：オンチェーンデータをクエリし、人手によるプロビジョニングを必要とせず、呼び出しごとに支払いを行う
マルチチェーンデータパイプライン：Ethereum、Base、Polygon、Solanaなどからデータを取得し、MPPセッションを通じてリクエストごとにセント未満のレートで支払う
AI搭載ウォレットとコパイロット：ポートフォリオデータの取得、トランザクションのシミュレーション、アドレスの監視をすべて自己資金で行う
MCPツールサーバー：Alchemyのエンドポイントを有料ツールとしてラップし、どんなMCP互換エージェントでもオンデマンドでブロックチェーンインフラにアクセスできるようにする

ターミナルから試してみる

Alchemy CLIをインストールし、Alchemy Skillsを追加してMCPサーバーを接続する：

bashCopied
npm i -g @alchemy/cli@latest
alchemy auth
npx skills add alchemyplatform/skills --yes

# Claude Code
claude mcp add alchemy --transport http https://mcp.alchemy.com/mcp

# Codex
codex mcp add alchemy --url https://mcp.alchemy.com/mcp

alchemy --json --no-interactive balance vitalik.eth -n eth-mainnet

始める準備はできたか？alchemy.com/agentsにアクセスして、プラットフォームを確認し、自身のインフラ費用を自ら支払うエージェントの構築を始めよう。

FAQ

x402とMPPを両方一緒に使えるか？

使える。MPPのchargeインテントはx402と後方互換性があるため、両方を同時にサポートできる。サーバーは両方のプロトコルを提示し、クライアントがサポートする方をそれぞれ選択できるようにすることができる。

どちらを選ぶべきか？

ステーブルコインで支払うクリプトネイティブなエージェントを構築していて、本番環境への最もシンプルな経路を求めるなら、x402から始めるとよい。マルチレール決済対応、高スループットワークロード向けのセッション、MCPトランスポート統合、あるいは標準化されたプロトコルプリミティブが必要なら、MPPの方が適している。そのためにx402への投資を放棄する必要はない。

x402はMPPに置き換えられつつあるのか？

いいえ。MPPはx402を置き換えるためではなく、x402と互換性を持つように設計されている。MPPはx402が当初提供する予定のなかった機能を追加する進化形と考えるとよい。x402コミュニティは独立して成長を続けている。

MPPは現在どの決済方法をサポートしているか？

MPPは2つのプロダクション用決済方法を提供している：ステーブルコイン決済用のTempoと、カード、ウォレット、その他の従来型決済方法用のStripeだ。決済方法はプラガブルであるため、誰でもリクエストスキーマとペイロードスキーマを指定することで新しい決済方法を定義・公開できる。

これらのプロトコルを使うために自前のインフラを運用する必要があるか？

その必要はない。AlchemyはそのAPIプラットフォーム全体でx402とMPPの両方をサポートしているため、独自の決済インフラを運用することなく、ブロックチェーンデータに支払いを行うエージェントの構築を始めることができる。alchemy.com/agentsから始めよう。