MPP（Machine Payments Protocol）とは？HTTP 402の仕組みとx402との違い・Stripeでの実装【2026年10月】

MPP（Machine Payments Protocol）は、AIエージェントやプログラムがAPIやデータの利用料を、HTTPのやり取りの中でそのまま支払うための規格です。StripeとTempoが共同で書き、2026年3月18日に公開しました。アカウント登録やAPIキーの発行を経ずに、1リクエスト単位で課金できるのが狙いです。

この記事では、IETFに出ている仕様書、Stripeの導入ドキュメント、公式SDK（mppx 0.13.1）を手元で動かした結果をもとに、支払いの流れ、x402との違い、Stripeで受け付ける手順、日本の事業者が使うときの条件を整理します。

まとめ：MPPの要点

• 定義：HTTP 402 Payment Requiredに、WWW-Authenticate・Authorization・Payment-Receiptの3ヘッダーで支払いを載せる規格。中核仕様はIETFに個人提出されたInternet-Draft（draft-httpauth-payment-01、2026年9月9日。旧名のdraft-ryan-httpauth-paymentは失効）で、まだ標準ではありません
• 支払い手段を選ばない：Tempoのステーブルコイン、Stripe経由のカード、Visaのカード、Lightningなどを、同じエンドポイントで並べて提示できます。ただし公開ディレクトリの129サービス中126はTempo払いです（2026年10月8日時点）
• 課金の型：1回払いのcharge、事前に預けた資金から少額を積み上げるsession、定額の定期払いを扱うsubscription（仕様は2026年10月時点で初版の段階）
• x402との違い：x402はブロックチェーン上の支払いに絞った規格、MPPはHTTP認証の枠組みでカードも含めて扱う規格です。mppxは1つのエンドポイントで両方を受けられます
• Stripeで受ける条件：カード（SPT）は1回0.50米ドル以上、ステーブルコインは0.01 USDC以上。SPTの対象は米国・カナダ・一部の欧州で、ステーブルコインは米国外の事業者だと個別申請が必要です。日本の事業者がStripe経由で受け取る場合は、対象可否と利用承認の確認が必要です

MPPの定義と、エージェント決済規格の中での位置

MPPは「エージェントがAPIを呼ぶ → サーバーが支払いを要求する → エージェントが払って呼び直す」という往復を、HTTPの認証の仕組みに乗せて標準化したものです。Stripeの発表記事は、エージェントが購入のたびにアカウント作成、料金ページの確認、プラン選択、支払い情報の入力を求められる現状を課題に挙げ、その代わりにプログラムから支払える経路として位置づけています。

仕様の管理は2層に分かれています。402のやり取りを定める中核仕様はIETFのInternet-Draft（draft-httpauth-payment）として提出し、どの決済網でどう払うか（method）はその網の持ち主が書きます。たとえばカードの方式はVisa、Lightningの方式はLightsparkが著者です。誰の承認も得ずに新しい方式を追加できる設計で、仕様本文はCC0、SDKはApache 2.0かMITで配布されています。

エージェントの買い物には複数の規格が関わりますが、MPPが担うのは最後の「お金を動かす」段だけです。

人が商品を選んでエージェントが代わりに買う場面はACPやUCPの領域で、規格全体の役割分担はエージェンティックコマースの仕組みとACP・UCP・AP2の違いで扱っています。利用者の承認を署名で残す仕組みはAP2のマンデートとx402・ACP・UCPとの違いを参照してください。

HTTP 402で支払う流れ：チャレンジ・クレデンシャル・レシート

やり取りは3段です。サーバーは支払いの無いリクエストに402を返し、WWW-Authenticate: Paymentヘッダーに支払い条件（チャレンジ）を入れます。クライアントは支払いを済ませ、その証明（クレデンシャル）をAuthorization: Paymentヘッダーに入れて同じリクエストを送り直します。サーバーは支払いの検証・精算後、200などの成功応答でリソースを返します。成功応答にはPayment-Receiptヘッダーを付けることが推奨されています。

mppx 0.13.1でTempoテストネット向けに0.01ドルのエンドポイントを立て、何も付けずにリクエストしたときの応答が次です（チャレンジは2通り返ったうち1つを残し、値を短くしています）。

HTTP/1.1 402 Payment Required
cache-control: no-store
content-type: application/problem+json
www-authenticate: Payment id="UwYi00LvOjktRBfE...", realm="localhost", method="tempo",
  intent="charge", request="eyJhbW91bnQiOiIxMDAwMCIs...", description="demo",
  expires="2026-10-08T01:38:24.295Z"

{"type":"https://paymentauth.org/problems/payment-required","title":"Payment Required","status":402,...}

request値はJSONをBase64URLにしたもので、デコードすると金額・通貨・受取先が入っています。

{"amount":"10000","currency":"0x20c0000000000000000000000000000000000000",
 "methodDetails":{"chainId":42431},"recipient":"0x742d35Cc6634c0532925a3b844bC9e7595F8fE00"}

amountの10000は、小数6桁のステーブルコインで0.01ドルを表します。chainIdの42431はTempoのテストネット（Moderato）で、メインネットは4217です。mppx 0.13.1のTempoサーバーは、通貨を指定しない場合、テストネットではOUSD・pathUSD、メインネットではOUSD・USDC.eの順に提示します（0.12.0で変わった挙動）。上の応答でチャレンジが2つ返ったのはこのためで、1つ目がOUSD、デコードした2つ目がpathUSDです。

失敗時の応答も仕様で決まっています。エラーの詳細はRFC 9457のProblem Details形式で本文に入ります。支払い検証の失敗では402と新しいチャレンジを返しますが、未対応の支払い手段は400です。

APIキーで認証しているAPIでは、Authorizationヘッダーがすでに埋まっています。その場合サーバーはチャレンジにheader="Payment-Authorization"を付け、支払いの証明だけを別ヘッダーで受け取れます。

チャレンジの改ざんを防ぐHMACバインディング

仕様は、チャレンジのIDをrealm・method・intent・request・expiresなどに結びつけるようサーバーに求めており、推奨方式はHMAC-SHA256です。クライアントが金額を書き換えて送り直しても、IDと中身が一致しなくなります。

実際に、受け取ったチャレンジのamountを10000から1へ書き換えてクレデンシャルを組み立てると、サーバーは支払いの検証に入る前に「challenge was not issued by this server」としてinvalid-challengeを返しました。壊れたBase64を送った場合はmalformed-credentialです。このHMACの鍵（mppxではsecretKey）が漏れると任意の条件でチャレンジを作れるため、mpp.devはシークレット管理への保管、ログに出さないこと、漏えい時の即時ローテーションを求めています。

POST本文の差し替え防止と再送制御：digest・Idempotency-Key

本文のあるリクエストでは、チャレンジにdigestパラメータ（RFC 9530のContent-Digest）を入れることが推奨されています。支払った後に本文を差し替えて別の処理を実行させる攻撃を防ぐためです。

通信が途中で切れたときの再送について、仕様はPOST・PUT・DELETEでIdempotency-Keyヘッダーを受け付けるようサーバーに推奨しています。同じキーと有効な支払いで再送されたら、処理をやり直さず最初の結果を返す設計です。キーの保存期間や再生の実装は冪等キー（Idempotency-Key）の発行・保存・再生の実装で詳しく扱っています。

charge・session・subscriptionの違いと使い分け

チャレンジのintentは、どういう形で払うかを表します。仕様リポジトリ（tempoxyz/mpp-specs）には2026年10月時点で次の3つがあります。

chargeが基本形で、x402の「exact」と同じ働きです。毎回の支払いが決済網に記録されるため、1回あたりの手数料と待ち時間がそのまま乗ります。mpp.devのFAQは、chargeの典型的な価格帯を1リクエスト0.01〜0.10ドルとしています。

sessionは、クライアントが先に資金をエスクローに預けて支払いチャネルを開き、以後はEIP-712で署名した「累計いくらまで払った」という伝票を送るだけで次々にリクエストする方式です。サーバーは貯まった伝票をまとめて決済網で精算します。LLMの出力トークンごとの課金などでは、sessionで少額を積み上げると、各リクエストのオンチェーン精算を省けます。Stripeで受ける場合も1セント未満の単位で請求できますが、精算は0.01 USDC以上です。

subscriptionは2026年10月時点で初版（-00）の仕様で、定額を期間ごとに請求する権限をクライアントがサーバーに与える形です。Stripe向けとTempo向けの方式も同じく初版のため、本番の課金をこれに乗せるのは版が進んでからにするのが無難です。

支払い手段（method）の一覧と実際の利用状況

methodは、どの決済網でどう払うかを表します。mpp.devのFAQで本番稼働とされているのは、Tempoのステーブルコイン、CardまたはStripe経由のカード、Lightningの3系統です。そのほかの方式も仕様リポジトリに並んでいます。

VisaとMPPの関係は、このcardメソッドです。Tempoはメインネット公開時の発表で、デザインパートナーのVisaがカード決済の方式をMPPに追加したと書いています。エージェントにカード番号そのものを渡さず、暗号化したネットワークトークンで支払う方式です。

仕様上は手段を選びませんが、公開ディレクトリの登録サービス数ではTempo対応が多数を占めています。mpp.devが公開しているサービス一覧のAPI（/api/services）を2026年10月8日に集計すると、登録129件のうち126件がtempoメソッド、stripeは10件、evmは1件でした（重複あり）。methodごとの対応intentを延べ集計するとchargeが131件、sessionが8件です。同一サービスの複数methodを重複計上しており、サービス数とは異なります。カテゴリはdataが71件と最も多く、web・ai・searchが続きます。

一覧にはAnthropicやOpenAIの名前もありますが、integration欄はthird-partyで、接続先はanthropic.mpp.tempo.xyzのようなTempo側のプロキシです。各社が自社APIでMPPを直接受け付けているわけではない点に注意してください。

MPPとTempoの関係：仕様の独立性と実装上の結びつき

Tempoは、StripeとParadigmが立ち上げた決済向けのブロックチェーンで、メインネットはMPPと同じ2026年3月18日に始まりました。チェーンIDは4217です。合意形成にはSimplex Consensusを使い、通常時は1秒未満でファイナリティに達するとしています。ネットワーク手数料はTIP-20規格のステーブルコインで払うため、ガス代用に別の暗号資産を持つ必要がありません。手数料を第三者が肩代わりするfeePayerの仕組みもあり、Stripeはこれを使って本番環境のTempo手数料を負担するオプション（hostedFeePayer）を出しています。

mpp.devのFAQは「Tempoを使う必要はない」と明記したうえで、確定的なファイナリティ、混雑に左右されにくい手数料、決済専用のレーン、ステーブルコインを中心に据えた設計を、Tempoを決済層に推す理由に挙げています。仕様の上では独立していても、SDKの既定値、Stripeの入金アドレス、サービス一覧の実態はいずれもTempoが前提です。他チェーンで受けたい場合、StripeではSolanaのUSDCが選べます。

払う側の資金の入れ方も、Tempo寄りに整備されています。2026年6月17日に始まったMPP Creditsは、Tempo Walletでカードやデビットカードからクレジットを買い、エージェントにMPPサービスで使わせる仕組みです。発行はライセンスを持つ決済事業者のCoinflowで、売り手にはTempo上のUSDC.eで精算されます。クレジットは前払いで返金・出金・法定通貨への換金ができず、使えるのはTempoがプロキシするMPPサービスに限られます。

x402との違いと、同じエンドポイントでの併用

x402もHTTP 402で支払いを要求する規格で、Coinbaseが2025年に公開し、現在はx402 Foundationが仕様を管理しています。ヘッダーの使い方と対象とする決済網が主な違いです。

この比較はmpp.dev側の整理で、MPPが「本番向け」「既定で選ぶべき」と書いている点は割り引いて読む必要があります。x402側もupto（上限内の従量課金）やEVMのbatch-settlement（チャネルとオフチェーン伝票）を持っており、少額の積み上げ課金ができないわけではありません。

両者は排他ではありません。mppxはx402互換のEVM chargeをMPPのルートと同じ場所で処理でき、サーバーはMPPとx402の両方のチャレンジを出して、届いた形式に合わせて受領ヘッダーを返します。クライアント側のmppx CLIも、既定ではMPPを優先し、無ければx402で払います。x402のEVM支払いが使うUSDCの署名方式はEIP-3009のtransferWithAuthorizationの仕組みと署名実装で解説しています。

どちらか一方を選ぶなら、判断基準は支払い手段です。カードの利用者も取り込みたいならMPPです。Stripeの売上管理への連携はx402でも利用できます。受け取りをオンチェーンで完結させ、x402対応ウォレットを持つクライアントだけを相手にするならx402で足ります。

StripeでMPPの支払いを受ける実装手順

StripeのMPP導入ガイド（Stripe-Version 2026-07-29.preview）に沿った手順です。ステーブルコインで受けた分も含め、支払いは法定通貨でStripe残高に入り、返金・レポートは通常の決済と同じ扱いです。エージェントに受け取る側のStripe操作（返金や顧客照会など）をさせる場合の接続と権限設計はStripe MCPの使い方：接続手順とエージェントAPIキーの権限設計で扱っています。

前提：Stripeプロフィールと利用できる国・最低金額

最初にダッシュボードでStripeプロフィールを作り、profile_で始まるIDを控えます。これがエンドポイント設定のnetworkIdになります。

受け付けられる条件は支払い手段で異なります。SPT（Shared Payment Token）によるカード決済は米国全州の事業者が対象で、SPT自体は米国・カナダ・一部の欧州で使えます。最低額は0.50米ドルです。ステーブルコインはニューヨーク州を除く米国の事業者が対象で、米国外の事業者は[email protected]にアカウントIDを送り、30か国以上を対象とした利用を申請します。最低額は0.01 USDCです。

SPTは、エージェントが利用者のカードを使う権限を、通貨・上限金額・有効期限を付けて売り手に渡すトークンです。使用済み・期限切れ・取り消しのいずれかで無効になり、その時点で受取側にはWebhookのshared_payment.granted_token.deactivatedイベントが届きます。

mppxによる課金エンドポイントの実装

依存パッケージはmppxとstripeの2つです（npm install mppx stripe）。Stripeのガイドにあるエンドポイントは次のとおりで、1リクエスト0.50米ドルを請求し、未払いなら402のチャレンジを、支払い済みなら受領付きの応答を返します。チャレンジを結びつけるHMACの鍵は、Stripeのシークレットキーから導出しています。

import crypto from 'crypto';
import StripeClient from 'stripe';
import { Mppx, Store, stripe } from 'mppx/server';

const mppSecretKey = crypto.createHmac("sha256", process.env.STRIPE_SECRET_KEY!).update("mpp-challenge-signing").digest("base64");

const stripeClient = new StripeClient(process.env.STRIPE_SECRET_KEY!);

const stripeMachinePayments = stripe.create({
  client: stripeClient,
  networkId: process.env.STRIPE_PROFILE_ID!,
  livemode: !process.env.STRIPE_SECRET_KEY!.includes('_test_'),
  store: Store.memory(),
});

const mppx = Mppx.create({
  methods: stripeMachinePayments.defaultMethods(),
  secretKey: mppSecretKey,
});

export async function handler(request: Request) {
  const response = await mppx.charge({ amount: '0.50' })(request);
  if (response.status === 402) return response.challenge;
  return response.withReceipt(Response.json({ data: '...' }));
}

Stripeのガイドに載っているコード（2026年10月8日時点）にはstoreの行がありません。mppx 0.13.0からstripe.create()は支払いの使い回しを防ぐ共有ストアを必須にしており、ガイドのまま0.13.1で動かすとstripe.create() requires a shared atomic `store` for replay protection.という例外で起動しません。手元でstoreを足した版を動かすと、method="stripe"・amount=50（セント）のチャレンジ付きで402が返りました。

Store.memory()はプロセス内のメモリに置くだけなので、使えるのは1プロセスで動かす場合に限られます。複数台やサーバーレスで動かすなら、mppxが用意しているStore.redis()・Store.upstash()・Store.cloudflare()のうち、原子的な更新（update）を持つものを全インスタンスで共有してください。この状態ではSPTによるカード払いだけを受け付けます。手段ごとに金額を変えたい場合はmppx.compose()を使います。

Tempoの入金アドレスとガスレス設定

ステーブルコインも受けるには、Stripeで入金アドレスを作り、設定に足します。

curl https://api.stripe.com/v1/crypto/deposit_addresses \
  -u sk_test_...: \
  -H "Stripe-Version: 2026-07-29.preview" \
  -d network=tempo

返ってきたaddressを環境変数TEMPO_DEPOSIT_ADDRESSに入れ、stripe.create()にdepositAddresses: { tempo: ... }を加えると、defaultMethods()がTempoを追加し、同じ0.50米ドルでSPTとTempoの両方を提示するようになります。入金アドレスの作成はリクエストのたびに呼ばず、起動時や運用手順の側で済ませておくのがStripeの推奨です。

mppx 0.9.2以降ではhostedFeePayer: trueを足すと、StripeがTempoのネットワーク手数料を負担します。使えるのはTempo入金アドレスを使う本番環境で、入金アドレスとAPIキーが同じアカウントのものである必要があります。Stripe Connectの実装では使えません。

mppx validateとlink-cli・Tempo CLIでの動作確認

一通りの確認は、npx mppx@latest validate http://localhost:4242 で自動化できます。ディスカバリ、チャレンジの形式、エラー処理、支払いの往復までを検査し、サンドボックスではテスト取引を自動で完了します。本番環境に向けると実際の資金が動きます。

手動で試す場合、カード側はStripeのlink-cli（npx @stripe/link-cli mpp pay ...）でテスト用のSPTを発行して支払います。ステーブルコイン側はTempo CLI（tempo wallet login、tempo request ...）を使いますが、サーバーが本番の入金アドレスを使っていると実際にお金が動きます。サンドボックスのAPIキーを使えば、mppxがlivemodeをfalseにし、Tempoのテストネットを自動で設定します。

SDKの版と、エージェントに見つけてもらう仕組み

公式SDKはTypeScript・Python・Rust・Go・Rubyがあり、2026年10月8日時点の最新はnpmのmppxが0.13.1（2026年10月2日公開・変更履歴）、PyPIのpympp（MPPのPython SDK）が0.11.0です。どちらも0.x系で、mppxは開発版が毎日のように出ています。Stripeのガイドが「0.9.2以降」と版を指定する機能もあるので、package.jsonでは版を固定し、上げるときは変更履歴を読んでからにしてください。TypeScript版にはHono・Express・Next.js・Elysia向けのミドルウェアがあります。

エージェントがどのAPIが有料で、いくらかかるかを知る手段として、仕様リポジトリにはディスカバリ拡張（draft-payment-discovery-01）があります。サービスがOpenAPI文書を公開し、各操作にx-payment-info拡張で価格と支払い手段を書く方式です。ただし最終的な条件は実際の402チャレンジが優先されます。MCPのツール呼び出しに同じ流れを載せるトランスポート仕様もあり、MCPサーバーがツール単位で課金できます。

MPPを採用しないほうがよい場面

MPPはAPIを従量課金で売りたい開発者向けの規格で、次の条件に当てはまるなら、いま採用する理由は薄いです。

• 日本の事業者としてStripe経由で受け取りたい：SPTの対象国に日本は入っておらず、ステーブルコインも米国外は個別申請です。対象可否と利用承認が確認できるまでは、検証環境での試作にとどめる判断になります。Stripeを介さず自社のウォレットでステーブルコインを受け取る構成も仕様上は組めますが、国内での会計・法令上の扱いは別途確認が必要です
• 人が商品を選んで買うECを載せたい：カートや配送先のやり取りはMPPの範囲外です。ChatGPTやGoogleのAIモードでの購入はACPやUCPの領域で、規格の詳細はUCP（Universal Commerce Protocol）の仕組みとACP・AP2との違いにまとめています
• 1回数円の課金をカードで取りたい：カード（SPT）の最低額は0.50米ドルです。それより小さい単価はステーブルコインのchargeかsessionになり、払う側にウォレットが必要になります
• 仕様の変更に追従する体制が無い：中核仕様はIETFの個人提出段階、SDKは0.x系、subscriptionは初版です。決済の仕組みを年単位で固定したいなら、版が落ち着くのを待つほうが安全です

逆に、米国の利用者向けにデータやAPIを売っていて、すでにStripeで決済している事業者にとっては、対象地域と決済手段の利用条件を満たせば、既存の残高・レポートにエージェントからの売上を統合できる利点があります。

公開時の導入事例と、発表文の読み方

Stripeの発表記事が挙げた導入例は、ヘッドレスブラウザをセッション単位で売るBrowserbase、郵便物の印刷・発送を代行するPostalForm、ニューヨーク市内でサンドイッチの受け取り・配達を受け付けるProspect Butcher Co.、Stripe Climateへの寄付です。Parallel Web Systemsの創業者Parag Agrawal氏は、数行のコードで統合し、API呼び出しごとにエージェントから支払いを受けられるようになったとコメントしています。4件とも2026年10月時点のサービス一覧に残っています。

Tempoのメインネット発表はAnthropic・OpenAI・Shopify・Visaなど10社を「パートナー」に挙げ、公開時のディレクトリに100超のサービスが載ったと書いています。ただしパートナーはTempo全体の取り組みの相手で、各社がMPPで支払いを受け付けている意味ではありません。導入実績を判断に使うなら、発表文より/api/servicesの中身を確認してください。

よくある質問

MPPとは何の略ですか？

Machine Payments Protocolの略で、AIエージェントなどのプログラムがHTTP 402を使ってAPIやサービスの利用料を払うための規格です。StripeとTempoが共同で書き、2026年3月18日に公開しました。

MPPとx402はどちらを使えばよいですか？

カードも受けたいならMPPが候補です。オンチェーン決済だけならx402も選べ、Stripeの売上管理にはどちらも連携できます。mppxを使えば1つのエンドポイントで両方のクライアントから受け取れるため、片方に決め打ちする必要はありません。

VisaはMPPにどう関わっていますか？

MPPのカード決済方式（cardメソッド）の仕様をVisaが書いています。エージェントにカード番号を渡さず、暗号化したネットワークトークンで1回払いをする方式です。Tempoはメインネット公開時に、Visaをデザインパートナーとして紹介しています。

MPPはSolanaでも使えますか？

使えます。仕様リポジトリにSolana向けのchargeとsessionの方式があり、StripeもMPP経由でSolana上のUSDCを受け付けています。ただし2026年10月時点の公開サービスの大半はTempoで支払いを受けています。

MPPは日本で使えますか？

支払う側の利用条件は、使うウォレットやサービスの規約で決まります。受け取る側は、StripeのSPTの対象国に日本が入っておらず、ステーブルコインも米国外の事業者は個別申請が必要なため、Stripe経由の本番受領は対象可否と承認の確認が必要です。この制約はMPP全体の国内利用禁止を意味しません。

関連記事

• エージェンティックコマースとは？仕組みとACP・UCP・AP2の違い、日本の現状【2026年10月】
• AP2（Agent Payments Protocol）とは？v0.2のマンデートとx402・ACP・UCPとの違い
• UCPとは？Universal Commerce Protocolの仕組みとACP・AP2との違い【v2026-08-25対応】
• EIP-3009（ERC-3009）とは？transferWithAuthorizationの仕組みと署名実装・対応トークン
• AgentCore paymentsが切り拓くAIエージェント決済の新しい標準像