MCPサーバーにx402決済を追加する方法:エージェント決済のビルダーガイド

2026年8月26日公開読了時間 3 分

多くのAPIは、まずサインアップを求める形で課金している。アカウントを作成し、キーを取得し、後で請求される、という流れだ。x402はこれを全て省く。サーバーはサインアップもキーも請求書も無しに、リクエスト単位で課金できる。しかもすでに本番環境で動いている。Coinbaseは2025年5月にこれを出荷し、CloudflareはAgents SDKに組み込み、我々のagent gatewayはRPCとデータアクセスに対してagentに課金するのに使っている。

このガイドは、この取引のどちら側を構築するにしても役に立つ。呼び出しごとに課金したいMCPサーバーやAPIを作る側、あるいはそれに支払う必要があるagentを作る側だ。リクエストとレスポンスのループを説明した後、ツール呼び出しへの課金、呼び出しごとのUSDCでの計測と決済、agentに支払い用のウォレットを与える方法、そしてAP2のような他の決済プロトコルがどこに位置づけられるかについて、実際のコードを示す。

x402は実際に何をするのか

HTTP 402 Payment Requiredは1990年代からHTTP仕様に存在していたが、実装されたことはなかった。x402はついにこれを使うプロトコルだ。

サーバーは未払いのリクエストに対してステータス402と、機械可読な価格を返す
クライアントは署名済みの支払いを添付して再試行する
サーバーは検証し、決済し、同じ取引の中でリソースを返す

セッションも、保存されたカードも、ダッシュボードも存在せず、ウォレットがアカウントそのものになる。x402 v2では、関連する情報はHTTPヘッダーに格納される。

Header	Direction	Carries
`PAYMENT-REQUIRED`	Server to client	Price, destination address, network, and accepted payment schemes, base64-encoded
`PAYMENT-SIGNATURE`	Client to server	The signed payment payload, base64-encoded
`PAYMENT-RESPONSE`	Server to client	The settlement result, base64-encoded

この3つのヘッダー自体は変わらない。変わるのはPAYMENT-REQUIREDが運ぶJSON内のschemeフィールドで、これがクライアントに対してその呼び出しがどの課金モデルを使っているかを伝える。どのスキームでも、検証と資金移動を行うのは同じ第三者だ。facilitatorと呼ばれるサービスがクライアントの署名済み支払いを検証し、オンチェーンでの決済を提出する。これにより、売り手もクライアントも自分でその作業をする必要がない。スキームごとに異なるのは、facilitatorが何をチェックし、いつ決済するかだけだ。

ほとんどの呼び出しはexactを使う。価格は固定で事前にわかっているため、クライアントはその正確な金額に署名し、その正確な金額で決済される。ペイロードは以下のようになる(重要なフィールドのみ抜粋)。amountは10,000 atomic unitsで、これは$0.01 USDCに相当する。

jsonCopied
{
"accepts": [{
  "scheme": "exact",
  "amount": "10000",
  "asset": "0x036C...F7e",
  "payTo": "0x2096...87C"
}]
}

一部の呼び出しでは、トークン生成数で課金されるLLM出力のように、作業が終わった後にしかわからない可変の金額がかかる。こうしたケースでは、サーバーはuptoを使う。ペイロードはほぼ同じ見た目だが、amountは今や価格ではなく、クライアントが同意する上限を意味する。ここではその上限は$5.00だ。

jsonCopied
{
"accepts": [{
  "scheme": "upto",
  "amount": "5000000",
  "asset": "0x036C...F7e",
  "payTo": "0x2096...87C"
}]
}

クライアントはその上限に対して一度だけ署名する。サーバーが作業を終えた後、facilitatorは実際の金額(例えば実使用分の$1.20)で決済し、資金を動かす前にそれが署名済みの上限以下であることを確認する。クライアントが二度署名することはなく、決済ステップでのみ実際の数値が埋め込まれる。

3つ目のスキームであるbatch-settlementは、呼び出しごとにガス代を払うとその呼び出し自体より高くつくような、高頻度かつサブセントの課金を対象とする。x402のスキームでは、買い手はエスクローコントラクトに一度だけデポジットし、リクエストごとにオフチェーンのバウチャーに署名し、売り手はそれをバッチでオンチェーン償還する。Circle Gatewayは同じ用途に関連するナノペイメントのパターンを使っている。

facilitator自体は資金を保有しない。署名済みの指示をチェックし、それを実行するだけだ。x402.orgは無料の公開facilitatorを運用しており、これは開発およびテストネット専用だ。一方CoinbaseのCDPはコンプライアンススクリーニング付きのホスト型本番facilitatorを運用している。コードはどちらにも向けられる。

x402のリクエストとレスポンスのループはどう動くのか

このハンドシェイクは9ステップだ。

クライアントは支払いを添付せずにリソースをリクエストする。
サーバーは価格、送金先アドレス、受け入れ可能な支払いスキームとともに402 Payment Requiredで応答する。
クライアントは受け入れ可能なスキームの1つに対して支払いに署名し、署名を添付してリクエストを再試行する。
サーバーはfacilitatorに、宣言済みの要件に対して署名済み支払いを検証するよう依頼する。
facilitatorは検証結果を返す。
サーバーは作業を行う(クエリを実行する、モデルを呼び出す、レポートを生成するなど)。
サーバーはfacilitatorに支払いのオンチェーン決済を依頼する。
facilitatorは決済結果を返す。
サーバーは決済レシートとともにリソースを返す。

HTTP上では、このループはHTTPヘッダー(PAYMENT-REQUIRED、PAYMENT-SIGNATURE、PAYMENT-RESPONSE)を通じて実行される。MCP上では、同じ9ステップがJSONを通じて実行される。

支払いなしの呼び出しは、isError: trueとPaymentRequiredペイロードを含む結果を返す(PAYMENT-REQUIREDに相当)
クライアントは署名済み支払いを_meta["x402/payment"]に添付して同じ呼び出しを再試行する(PAYMENT-SIGNATUREに相当)
サーバーは決済情報とともに_meta["x402/payment-response"]で実際の結果を返す(PAYMENT-RESPONSEに相当)

MCPサーバーにx402の支払いを追加するには

この例は、一般的な実際のケースを反映している。無料のツールと有料のツールが混在するMCPサーバー、例えば無料の基本検索を提供しつつ、より深い生成レポートには課金するリサーチやデータのサーバーだ。

この例では、generate_reportは1呼び出しあたり$0.01かかり、pingは無料のままとなる。オープンなx402 Foundation SDKs(facilitatorに依存しない構成なので、無料の公開facilitatorに対して開始し、後で商用のものに差し替えられる)を基盤とし、支払いを受け取るアドレスとしてWallet APIsのスマートアカウントを使う。

まず、支払いを受け取るウォレットをプロビジョニングする。@alchemy/wallet-apis(v5)は、サーバー上で秘密鍵に触れることなくスマートアカウントのアドレスを提供する。

tsxCopied
// wallet.ts
import { createServerSigner } from "@account-kit/signer";
import { createSmartWalletClient, alchemyWalletTransport } from "@alchemy/wallet-apis";
import { baseSepolia } from "viem/chains";

const signer = await createServerSigner({
auth: { accessKey: process.env.ALCHEMY_ACCESS_KEY! },
connection: { apiKey: process.env.ALCHEMY_API_KEY! },
});

const walletClient = createSmartWalletClient({
transport: alchemyWalletTransport({ apiKey: process.env.ALCHEMY_API_KEY! }),
chain: baseSepolia,
signer,
});

export const receiverAccount = await walletClient.requestAccount();
// receiverAccount.address is the payTo address for every quote you issue below

次に、そのアドレスをx402でゲートされたMCPツールに組み込む。@x402/coreは支払い要件を構築・検証し、@x402/evmはEVMチェーン向けにexactスキームを実装し、@x402/mcpはツールハンドラをラップして、単なる関数を有料のものに変える。

tsxCopied
// server.ts
import { createServer } from "node:http";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { x402ResourceServer } from "@x402/core/server";
import { HTTPFacilitatorClient } from "@x402/core/facilitator";
import { createPaymentWrapper } from "@x402/mcp";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { z } from "zod";
import { receiverAccount } from "./wallet";

// Base Sepolia for testing; swap to eip155:8453 for Base mainnet
const NETWORK = "eip155:84532";

// Start against the free public facilitator, then swap the url for a
// commercial facilitator (compliance screening, higher throughput, an
// SLA) for production.
const facilitator = new HTTPFacilitatorClient({
url: "https://x402.org/facilitator",
});

const resourceServer = new x402ResourceServer(facilitator);
resourceServer.register(NETWORK, new ExactEvmScheme());
await resourceServer.initialize();

const accepts = await resourceServer.buildPaymentRequirements({
scheme: "exact",
network: NETWORK,
payTo: receiverAccount.address,
price: "$0.01",
});

const paid = createPaymentWrapper(resourceServer, { accepts });

const server = new McpServer({
name: "paid-report-server",
version: "1.0.0",
});

server.tool(
"generate_report",
"Generate a research report on a topic. Costs $0.01 in USDC.",
{ topic: z.string() },
paid(async ({ topic }) => ({
  content: [
    {
      type: "text",
      text: "Report on " + topic + ": trending up, no anomalies.",
    },
  ],
})),
);

server.tool("ping", "Free health check", {}, async () => ({
content: [{ type: "text", text: "pong" }],
}));

const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined,
});
await server.connect(transport);

createServer((req, res) => {
const path = new URL(req.url ?? "/", "http://localhost").pathname;
if (path === "/mcp") {
  void transport.handleRequest(req, res);
  return;
}
res.writeHead(404).end();
}).listen(3000);

server.connect(transport)はプロトコルをトランスポートに接続するだけだ。実際にポート3000を開き、/mcpをtransport.handleRequest(...)に転送しているのはNode HTTPリスナーで、これが以下のクライアントが呼び出すエンドポイントになる。

paid(...)でラップしなかったものはすべて無料のままなので、同じサーバー上で有料・無料のツールを混在させることができる。まず支払いを添付せずにcurlや任意のMCPクライアントでテストしてみるといい。レポートの代わりに支払いが必要な旨の結果が返ってくるはずで、これは支払うクライアントを接続する前にゲートが機能していることを確認するものだ。

facilitatorとの関係を自分で構築したくなく、かつx402以外の新興agent決済プロトコルも1つに絞らず対応したい場合は、それがAgentPayの役割だ。既存のエンドポイントに向けるだけで、x402、ACP、MPP、AP2にまたがるプロトコル変換を1つの統合で処理してくれる。

agentへの呼び出しごとの課金をどう計測し請求するか

呼び出しごとに一律の価格を設定するのが基本パターンだ。本番サーバーでは、誰がいくら払ったかを追跡する必要もあり、facilitatorの決済レポートだけを実際に資金が動いた唯一の証拠として信頼すべきでもない。検証のためには、以下を把握しておく。

価格設定の形。一律の呼び出し単価には上述のパターンであるexactを使う。呼び出しごとにコストが変わる場合(長いレポートは短いものより多くのトークンを消費する)で、事前に上限を承認しつつ実使用分で決済したい場合はuptoを使う。呼び出しが頻繁かつ安価で、個別にオンチェーン決済するとその呼び出し自体より高くつく場合はbatch-settlementを使う。
帰属付けと台帳管理。クライアントが署名する支払いペイロードには支払い元アドレスが含まれる。呼び出しが決済されるたびに、それをツール名、価格、決済結果と紐づけてログに記録すれば、agentごとの使用量台帳が自動的に得られる。

tsxCopied
const paid = createPaymentWrapper(resourceServer, {
accepts,
hooks: {
  onAfterSettlement: async ({ toolName, settlement }) => {
    await usageLedger.record({
      payer: settlement.payer,
      tool: toolName,
      amountUsd: 0.01,
      txHash: settlement.transaction,
      settledAt: new Date(),
    });
  },
},
});

決済レスポンスを唯一の信号として信頼するだけで止めてはいけない。facilitatorはsettled: trueを報告しつつリクエストが依然として200以外を返すこともあれば、その逆もあり得る。収益として計上する前に両方を確認すること。定期的な照合には、our Transfers APIを使えば、受け取りアドレスに実際に着金したものを独立して確認できる。これはfacilitatorの決済レポートとオンチェーンの実態が食い違う稀なケースを捕捉する。

tsxCopied
const res = await fetch("https://base-sepolia.g.alchemy.com/v2/" + apiKey, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
  jsonrpc: "2.0",
  method: "alchemy_getAssetTransfers",
  params: [{
    toAddress: receiverAccount.address,
    category: ["erc20"],
    contractAddresses: [USDC_ADDRESS],
    withMetadata: true,
  }],
  id: 1,
}),
});
const { result } = await res.json();
// result.transfers is the ground truth for what actually arrived onchain,
// independent of what any single facilitator reported settling

agentにUSDCで支払わせるウォレットをどう与えるか

有料エンドポイント(自分のものでも他人のものでも)に支払う必要があるagentには、資金のあるウォレットと、402に当たったときに支払いに署名できるコード(あるいはCLI)が必要だ。

人間が操作する、あるいはローカルでテストするagentには、Alchemy CLIが最も速い方法だ。これは、agentが秘密鍵に一切触れることなく使える、スコープの限定されたウォレットセッションを作成する。

bashCopied
npm i -g "@alchemy/cli@latest"
alchemy auth
alchemy wallet connect --mode session --instance-name "my-agent"

# decode a quote without paying anything, useful for a first look at an unfamiliar endpoint
alchemy x402 request "https://api.example.com/report" --estimate

# pay it for real, with a hard spend cap; required for any non-interactive run
alchemy --json --no-interactive x402 request "https://api.example.com/report" --max-payment 0.01

--max-paymentはCLIが支払う最大額を設定し、サーバーが返してくる何であれ、この数値を超えて押し上げることはできない。承認する人間が誰もいない状態でコマンドを実行し(--no-interactive)、--max-paymentを設定し忘れた場合、CLIは支払わずに単に停止する。402レスポンス内の価格は自分が制御していないサーバーから来るものであり、上限のチェックを経ずに何かが支払うべきではないからだ。コマンド全体についてはx402 payments CLIのドキュメントを参照。

各セッションを人間が承認することなく支払う必要がある、完全に自律的なバックエンドagentには、fetch(または使っているMCPクライアント)を、署名者に裏打ちされた支払いハンドラでラップする。agentが有料のHTTPエンドポイントを呼び出す場合は、@x402/fetchを使う。

tsxCopied
import { x402Client } from "@x402/core/client";
import { wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(process.env.AGENT_WALLET_KEY as `0x${string}`);
const client = new x402Client();
registerExactEvmScheme(client, { signer });

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const response = await fetchWithPayment("https://api.example.com/report");

agentが素のHTTPエンドポイントではなくMCPサーバー上の有料ツールを呼び出す場合は、fetchの代わりに同じ方法でMCPクライアントをラップする。CDPはMCPの買い手向けに同じパターンを文書化している。

tsxCopied
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { x402Client } from "@x402/core/client";
import { wrapMCPClientWithPayment } from "@x402/mcp";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(
process.env.AGENT_WALLET_KEY as `0x${string}`,
);
const paymentClient = new x402Client();
registerExactEvmScheme(paymentClient, { signer });

const mcp = wrapMCPClientWithPayment(
new Client(
  { name: "my-agent", version: "1.0.0" },
  { capabilities: {} },
),
paymentClient,
{ autoPayment: true },
);

await mcp.connect(
new StreamableHTTPClientTransport(
  new URL("http://localhost:3000/mcp"),
),
);

const report = await mcp.callTool({
name: "generate_report",
arguments: { topic: "USDC on Base" },
});

環境変数に生の秘密鍵を置くのは、テストネットでの最初のテストとしては問題ないかもしれないが、本番環境では許容できない。本番のagentでは、同じ署名者インターフェースの裏側にWallet APIsのスマートアカウントやAgent Walletのセッションを置くことで、agentが自ら秘密鍵を保持することなく、設定したルールの下で署名できるようにする。

agentにガスを持たせずにUSDCで決済するには

すべてのオンチェーントランザクションにはガスが必要だ。ガスとは、トランザクションを送信する側が保有する、ネットワークにその処理を依頼するためのETHのようなネイティブトークンだ。これはAPI呼び出しごとに支払うagentにとって問題になる。$0.01の支払いのたびに立ち止まってガストークンを調達することはできないし、念のためにその備蓄を保有しておくというのは、自動化されたフローの意味を損なってしまう。

USDCの決済はEIP-3009(transferWithAuthorization)によってこれを回避する。これによりagentは、自らトランザクションを提出することもガストークンを保有することもなく、転送に署名できる。agentは署名するだけで、実際にそのトランザクションをオンチェーンに提出し、ガスを支払うのはfacilitatorの方だ。exactとuptoの決済は通常、USDCについてはEIP-3009を、EIP-3009に対応していないその他のERC-20についてはPermit2を使う。batch-settlementでは、依然としてagentがリクエストごとに署名し、売り手が後でオンチェーンでバッチ償還するという形になり、呼び出しごとに個別決済するわけではない。Circle Gatewayは、その同じ高頻度ケース向けに関連するナノペイメントのパターンを使っている。USDCがドル建てであることも、その上でものごとをシンプルに保つ。どちらの側も$0.01の請求に対して為替レートの計算をする必要がない。

ここまでが支払いそのものについてだ。受け取りアドレスが単なる外部所有ウォレットであれば、話はこれで終わりだ。単にUSDCを受け取るだけで、デプロイのステップは関わってこない。もしこのガイドの前半で構築したようなスマートアカウントであれば、x402のフローの外側で、もう2つの場面でガスに触れることになる。最初に資金を受け取った時のオンチェーンデプロイの際と、集まったUSDCをトレジャリーウォレットに送る際だ。我々のGas Managerは、この2つの場面でガスをスポンサーできる。いずれにせよ、Gas Manager自体はx402の支払いの決済には関与しない。それはすでにfacilitatorがカバーしているからだ。

Baseはほとんどのツールでデフォルトのネットワークになっている。これは、元々のリファレンスfacilitatorが動いている場所であり、既存のx402の統合の大半がすでに存在している場所だからだが、x402 v2はBase専用ではない。EthereumメインネットやPolygonを含む任意のEVMチェーン、さらにSolana、TON、Algorand、Stellar、Aptos、Hedera、Keeta、NEAR、Concordium、XRPLもカバーしており、facilitatorが対応を追加するにつれて対応チェーンは増えていくと見られる。「Ethereum上でUSDCで支払う」ことが具体的に今日機能するかどうかは、プロトコル自体ではなく、選んだfacilitatorがそのネットワークを実装しているかどうかにかかっている。

x402は、より広いagent決済のスタックのどこに位置づけられるのか

x402は急速に変化するこの分野における1つのプロトコルであり、唯一のものではない。

StripeとTempoが構築したMPPは、同じ402のパターンをステーブルコインに縛られない形にしたバージョンで、売り手は同じフローの下でカードとステーブルコインの両方を受け付けられる(そしてMPPはx402のexactフローと後方互換性があり、片方向けに構築されたクライアントは通常もう一方向けに構築されたサーバーと話せる)。
OpenAIとStripeのACPは別の側面をカバーしている。リクエストごとのAPI支払いではなく、AI主導のショッピングにおけるチェックアウトだ。
GoogleのAP2はまったく別の問題をカバーしている。支払い方法がカードであれ、銀行振込であれ、ステーブルコインであれ、署名済みのCheckoutおよびPayment mandateを使い、ユーザーがagentに支出する権限を与えたことを証明するというものだ。AP2は競合する決済レールではない。AP2のフローがステーブルコインでの決済を必要とする場合、それはGoogleがCoinbase、Ethereum Foundation、MetaMaskと共に構築したA2A x402拡張を通じて行われる。つまりx402はその下にある暗号資産のレールであり、代替ではない。

Protocol	Steward	Payment type	Primary job	Settles per request?
x402	x402 Foundation (originally Coinbase)	Onchain stablecoins	Pay per API call, tool call, or piece of content over HTTP or MCP	Yes
MPP	Stripe and Tempo	Cards or stablecoins, same flow	Pay per request, payment-method-agnostic	Yes
ACP	OpenAI and Stripe	Cards (via Stripe checkout)	Agent-driven shopping checkout, not per-request API payment	No, one checkout per purchase
AP2	Google, with industry partners	Payment-agnostic: cards, bank transfers, stablecoins	Prove a user authorized an agent to spend; settles through x402 or a card/bank rail underneath	No, authorizes a rail rather than settling itself

プロトコルの状況が進化する中で、AgentPayはプロトコルに依存しないプロキシとして存在し、加盟店が一度の統合ですべてに対応できるよう支援する。

特定のビルドでx402とMPPのどちらを選ぶか検討している場合は、x402とMPPの比較を参照。インフラプロバイダーを選ぶ場合は、Alchemy、CoinbaseのDeveloper Platform、Circle、Crossmint、Privy、Turnkeyを比較したウォレット、ガス、データ層の比較を参照。

避けるべきよくある間違い

自分で確認していない見積もりには決して署名しないこと。402レスポンスは、自分が制御していないサーバーから送られてきた単なる数字にすぎない。署名する前に、ネットワーク、アセット、金額を確認する。Alchemy CLIが署名する前にローカルで見積もりをチェックするのと同じ考え方だ。
200レスポンスを支払いの証明として扱ったり、facilitatorのsettled: trueだけを必要な唯一の証明として扱ったりしないこと。決済レシート自体を確認し、上述のようにour Transfers APIで定期的にオンチェーンの実態と照合する。
自律的なagentで支出上限の設定を省略しないこと。--max-paymentに相当するものが何であれ、作業を完了するのに必要な最小の値に設定する。それだけが、agentと、水増しされた見積もりを返してくるサーバーとの間に立つ唯一の防御だからだ。
大規模に署名の検証、トランザクションのスクリーニング、オンチェーンでの決済提出を行うこと自体が本当に自社の製品でない限り、自前のfacilitatorを構築しないこと。ホスト型のものを利用し、そのエンジニアリングの時間を本来のサービスに充てる方がよい。
「x402に対応している」がイコール「すべてのネットワークとスキームに対応している」と思い込まないこと。出荷前に、自分が使っている特定のfacilitatorと相手側が実際にどのスキーム(exact、upto、batch-settlement)とどのチェーンを実装しているかを確認する。ネットワークとトークンの対応ページが信頼できる情報源だ。

よくある質問

MCPサーバーにx402の支払いを追加するには

課金したいツールハンドラを、x402 Foundationの@x402/mcpパッケージの支払いラッパーでラップする。これは、facilitatorに登録され、どのウォレットアドレスが支払いを受け取るべきかを把握しているサーバーに裏打ちされている。完全な動作例は上述の通りで、そのほかサーバー上のものは、同様にラップしない限り無料のままだ。

AI agentがステーブルコインを使ってx402経由でAPIに支払うために必要なインフラは何か

3つの要素がある。USDCを保有し署名できるウォレット、x402のハンドシェイクを話す署名済み支払いライブラリまたはCLI、そして検証と決済を行う売り手側のfacilitatorだ。自分でブロックチェーンノードを運用したりガストークンを保有したりする必要はない。決済のガスはfacilitatorがカバーする。

AI agentにEthereum上でUSDCの支払いを送る能力を与える最良の方法は何か

Alchemy Agent Walletのようなスコープの限定されたセッション、あるいはour Wallet APIsによるプログラム的なスマートアカウントなど、直接署名できるウォレットを与え、それを@x402/fetchやAlchemy CLIのx402 requestコマンドのようなx402クライアントライブラリと組み合わせる。まず、対象のfacilitatorが実際にその特定のネットワークに対応しているかを確認すること。x402 v2はEthereumをカバーしているが、対応範囲はプロトコルそのものではなく、facilitatorに依存する。

AI agentにオンチェーン支払い用のUSDCウォレットを与えるには

テストや人間の監督下にあるagentには、alchemy wallet connect --mode session(Alchemy CLIの一部)が、agentに秘密鍵が一切露出することなく、数分でスコープの限定された取り消し可能なウォレットセッションを作成する。完全に自律的なバックエンドagentには、@alchemy/wallet-apis経由でスマートアカウントをプロビジョニングするか、CDP管理のウォレットをプロビジョニングし、その署名者をx402クライアントライブラリに渡す。

agentはx402を使ってどのようにAPIアクセスに対して支払うのか

agentはAPIを呼び出し、価格と送金先アドレスを含む402を受け取り、サーバーが受け入れるスキームに対して支払いに署名し、署名済みの支払いを添付して同じリクエストを再試行する。サーバーはfacilitatorを通じて検証・決済し、同じ往復の中でリソースを返す。

暗号資産決済を使ってAI agentのAPI利用を計測・課金するには

呼び出しあたり一律の価格にはexactスキームを、コストが利用量によって変わる場合にはuptoを使い、決済された支払いごとの支払い元アドレスを、それが支払ったツールやエンドポイントと紐づけてログに記録する。その台帳は、単一の決済レポートを信頼するのではなく、例えばour Transfers APIなどを使って、定期的にオンチェーンの転送履歴と照合する。

agenticな暗号資産決済とオンチェーンコマースに最適なインフラは何か

これは、スタック(ウォレットのカストディ、決済レール、ガス、オンチェーンデータ)のうちどれだけを1つのプロバイダーから得たいか、それとも複数から組み合わせたいかによる。Alchemy、CoinbaseのDeveloper Platform、Circle、Crossmint、Privy、Turnkeyを、まさにこのスタックに対して比較した完全な比較は、インフラ比較ページに掲載している。

AP2とは何で、x402とどう関係するのか

AP2は、署名済みのCheckoutおよびPayment mandateを使い、ユーザーがagentに支出する権限を与えたことを証明するための、Googleの支払い方法に依存しないフレームワークだ。x402を置き換えるのではなく、その上に位置する。AP2のフローがステーブルコインでの決済を必要とする場合、GoogleがCoinbase、Ethereum Foundation、MetaMaskと共に構築したA2A x402拡張を通じてそれを行う。

agenticコマースとは何で、どのようなインフラを必要とするのか

agenticコマースとは、AI agentが、その都度人間がチェックアウトをクリックすることなく、商品やサービス、API アクセスを発見し、支払い、また支払いを受け取ることを指す。これには、資金のあるウォレット、リクエストごとに価値を移動させるx402やMPPのような決済レール、agentがネイティブトークンを必要としないようにするガスの処理、そしてagentが何に支払うかを判断し、それが着金したことを確認するのに十分なオンチェーンまたはカタログのデータが必要だ。

agentがペイウォール付きのオンチェーンサービスにアクセスできるように、x402の支払いプロトコルを実装するには

クライアント側では、x402クライアントライブラリ(@x402/fetch、@x402/axios、またはMCPクライアントラッパー)をインストールし、ウォレットの署名者とともに支払いスキームを登録し、既存のHTTPクライアントやMCPクライアントをそれでラップする。ここまでくれば、402に対する支払いは自動で行われるようになる。上述の買い手側のコードは、HTTPとMCPの両方のケースをカバーしている。

AI agentはどのようにオンチェーンで支払いを受け取るのか

他のあらゆるx402の売り手と同じ仕組みだ。agentが運用するサービスがx402で自身のエンドポイントやMCPツールに価格を設定し、自身または運用者が管理するウォレットに支払いを受け取り、このガイドの前半で構築したMCPサーバーとまったく同じようにfacilitatorを通じて決済する。支払いを受け取ることと支払うことは、リクエストの反対側から見た同じプロトコルにすぎない。

有料MCPツールの構築を始める

Alchemy CLIでagentにスコープの限定されたウォレットを与え、x402でツールをゲートし、our Transfers APIで決済を確認する。あるいはfacilitatorの配線をスキップして、AgentPayを通じてagentの支払いを受け付ける。より広いスタック(カストディ、レール、ガス、データ)については、best infrastructure for agentic paymentsから始めるとよい。

ブロックチェーンで魔法を生み出す

Alchemyは、最も強力なweb3開発者向けプロダクトとツールを、豊富なリソース、コミュニティ、そして卓越したサポートと組み合わせて提供します。

APIキーを取得する

MCPサーバーにx402決済を追加する方法:エージェント決済のビルダーガイド

x402は実際に何をするのか

x402のリクエストとレスポンスのループはどう動くのか

MCPサーバーにx402の支払いを追加するには

agentへの呼び出しごとの課金をどう計測し請求するか

agentにUSDCで支払わせるウォレットをどう与えるか

agentにガスを持たせずにUSDCで決済するには

x402は、より広いagent決済のスタックのどこに位置づけられるのか

避けるべきよくある間違い

よくある質問

MCPサーバーにx402の支払いを追加するには

AI agentがステーブルコインを使ってx402経由でAPIに支払うために必要なインフラは何か

AI agentにEthereum上でUSDCの支払いを送る能力を与える最良の方法は何か

AI agentにオンチェーン支払い用のUSDCウォレットを与えるには

agentはx402を使ってどのようにAPIアクセスに対して支払うのか

暗号資産決済を使ってAI agentのAPI利用を計測・課金するには

agenticな暗号資産決済とオンチェーンコマースに最適なインフラは何か

AP2とは何で、x402とどう関係するのか

agenticコマースとは何で、どのようなインフラを必要とするのか

agentがペイウォール付きのオンチェーンサービスにアクセスできるように、x402の支払いプロトコルを実装するには

AI agentはどのようにオンチェーンで支払いを受け取るのか

有料MCPツールの構築を始める

関連する概要

エージェント決済に最適なインフラ:2026年版比較

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

エージェントペイメントとは?AIエージェントがAPI、データ、コンピュートの支払いを行う仕組み

ブロックチェーンで魔法を生み出す