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

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

ほとんどのAPIは、まずサインアップさせることで課金する仕組みになっている。アカウントを作成し、キーを取得し、後で請求される。x402はそれらすべてを省略する。サーバーはリクエストごとに課金でき、サインアップもキーもインボイスも不要だ。そしてすでに本番環境で稼働している。Coinbaseは2025年5月にこれを出荷し、CloudflareはそれをAgents SDKに組み込み、我々のエージェントゲートウェイはRPCとデータアクセスに対してエージェントに課金するためにこれを使っている。

このガイドは、その取引のどちら側を構築する人にも向けている。呼び出しごとに課金したいMCPサーバーやAPI、あるいはそれに支払う必要のあるエージェントだ。リクエストとレスポンスのループを説明し、その後、ツール呼び出しへの課金、呼び出しごとのUSDCでの計測と決済、支払いに使うウォレットをエージェントに与える方法、そして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アトミック単位であり、$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は呼び出しごとに$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との関係を自分で構築したくない、かつ他の新興のエージェント支払いプロトコルも1つに絞らずx402と合わせて受け入れたい場合、AgentPayがまさにそのためのものだ。既存のエンドポイントに向けるだけで、x402、ACP、MPP、AP2にまたがるプロトコル変換を1つの統合で処理できる。

エージェントごとに呼び出しを計測し課金するにはどうすればいいのか

呼び出しごとの単一の均一価格が基本ケースだ。本番のサーバーでは、誰がいくら支払ったかを追跡する必要もあり、資金が実際に移動した唯一の証明としてfacilitatorの決済レポートだけに頼るべきではない。検証のために、以下を記録しておく。

価格の形態。均一の呼び出しごとの価格には、上記のパターンであるexactを使う。呼び出しによってコストが変わる場合(長いレポートは短いものよりトークンが多くかかる)で、上限をあらかじめ承認しつつ実際の使用量で決済したい場合はuptoを使う。呼び出しが頻繁かつ安価で、それぞれをオンチェーンで個別に決済するとその呼び出し自体よりコストがかかってしまう場合はbatch-settlementを使う。
帰属と台帳管理。クライアントが署名する支払いペイロードには、支払い元のアドレスが含まれる。呼び出しが決済されるたびに、それをツール名、価格、決済結果と紐づけて記録すれば、エージェントごとの使用量台帳が自然と手に入る。

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を返す、あるいはその逆のこともあり得る。収益として計上する前に両方を確認すべきだ。定期的な照合パスとして、我々の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

エージェントに支払い用のUSDCウォレットを持たせるにはどうすればいいのか

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

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

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ドキュメントを参照してほしい。

各セッションを人間が承認することなく支払う必要のある、完全に自律的なバックエンドエージェントの場合は、fetch(またはMCPクライアント)を、署名者に裏付けられた支払いハンドラでラップする。エージェントが有料の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");

エージェントがプレーンな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" },
});

環境変数に生の秘密鍵を置くことは、テストネットでの最初のテストであれば問題ないかもしれないが、本番環境では受け入れられない。本番のエージェントには、同じ署名者インターフェースの背後に、Wallet APIsのスマートアカウントかAgent Walletセッションを置くべきであり、そうすればエージェントは、自分では一度も秘密鍵を保持することなく、設定したルールの下で署名できる。

ガスをエージェントに保有させずにUSDCで決済するにはどうすればいいのか

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

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

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

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

x402はエージェント支払いスタック全体の中でどこに位置するのか

x402は、急速に動いているこの分野の1つのプロトコルであり、唯一のものではない。

StripeとTempoが構築したMPPは、同じ402パターンのバージョンでありながら、ステーブルコインに縛られていない。売り手は同じフローの下でカードまたはステーブルコインを受け入れることができる(また、MPPはx402のexactフローと後方互換性があるため、一方向けに構築されたクライアントは通常、もう一方向けに構築されたサーバーと通信できる)。
OpenAIとStripeのACPは異なる領域をカバーしている。リクエストごとのAPI支払いではなく、AI主導のショッピングにおけるチェックアウトだ。
GoogleのAP2は、まったく異なる問題をカバーしている。支払い方法がカードであれ、銀行振込であれ、ステーブルコインであれ、署名済みのCheckoutおよびPaymentマンデートを使って、ユーザーがエージェントに支払いを許可したことを証明することだ。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を唯一必要な証明として扱ったりしないこと。決済レシート自体を確認し、上記で示したように我々のTransfers APIを使って定期的にオンチェーンの実態と照合すること。
自律的なエージェントにおいて支出上限の設定を省略しないこと。--max-paymentに相当するものが何であれ、それを目的を達成できる最小の値に設定すること。それが、エージェントと、過大な見積もりを返してくるサーバーとの間に立つ唯一のものだからだ。
署名の検証、トランザクションの審査、規模を伴うオンチェーンでの決済提出が実際に自分のプロダクトでない限り、自分でfacilitatorを構築しないこと。ホスト型のものを利用し、そのエンジニアリング時間を実際のサービスに費やすこと。
「x402をサポートしている」ことが「すべてのネットワークとスキームをサポートしている」ことを意味すると想定しないこと。導入前に、どのスキーム(exact、upto、batch-settlement)、どのチェーンを、自分が使う特定のfacilitatorと相手が実際に実装しているかを確認すること。ネットワークとトークンのサポートページが正式な情報源だ。

よくある質問

MCPサーバーにx402の支払いを追加するにはどうすればいいのか

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

AIエージェントがx402を使ってステーブルコインでAPIに支払うには、どんなインフラが必要か

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

AIエージェントにEthereum上でUSDC支払いを送信させるには、どうするのが最善か

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

AIエージェントにオンチェーン支払い用のUSDCウォレットを持たせるにはどうすればいいのか

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

エージェントはx402を使ってどのようにAPIアクセスに対して支払うのか

エージェントはAPIを呼び出し、価格と宛先アドレスを伴う402を受け取り、サーバーが受け入れるスキームに対して支払いに署名し、署名済みの支払いを添付して同じリクエストを再試行する。サーバーはfacilitatorを通じて検証と決済を行い、同じラウンドトリップの中でリソースを返す。

暗号資産での支払いを使ってAIエージェントのAPI使用量を計測し課金するにはどうすればいいのか

呼び出しごとの均一な価格にはexactスキームを使い、使用量によってコストが変わる場合はuptoを使う。そして、それぞれの決済済みの支払いから支払い元のアドレスを記録し、それが支払われたツールやエンドポイントと紐づける。単一の決済レポートを信頼するのではなく、その台帳を定期的にオンチェーンの送金履歴と照合すること。たとえば我々のTransfers APIを使うとよい。

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

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

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

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

エージェント型コマースとは何で、どんなインフラが必要か

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

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

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

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

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

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

Alchemy CLIを使ってエージェントにスコープの限定されたウォレットを与え、x402でツールをゲートし、我々のTransfers APIで決済を確認する。あるいは、facilitatorの配線を省略して、AgentPayを通じてエージェントの支払いを受け入れることもできる。より広範なスタック(カストディ、レール、ガス、データ)については、エージェント型決済のための最適なインフラから始めてほしい。

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

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

APIキーを取得する

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

x402は実際に何をするのか

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

MCPサーバーにx402の支払いを追加するにはどうすればいいのか

エージェントごとに呼び出しを計測し課金するにはどうすればいいのか

エージェントに支払い用のUSDCウォレットを持たせるにはどうすればいいのか

ガスをエージェントに保有させずにUSDCで決済するにはどうすればいいのか

x402はエージェント支払いスタック全体の中でどこに位置するのか

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

よくある質問

MCPサーバーにx402の支払いを追加するにはどうすればいいのか

AIエージェントがx402を使ってステーブルコインでAPIに支払うには、どんなインフラが必要か

AIエージェントにEthereum上でUSDC支払いを送信させるには、どうするのが最善か

AIエージェントにオンチェーン支払い用のUSDCウォレットを持たせるにはどうすればいいのか

エージェントはx402を使ってどのようにAPIアクセスに対して支払うのか

暗号資産での支払いを使ってAIエージェントのAPI使用量を計測し課金するにはどうすればいいのか

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

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

エージェント型コマースとは何で、どんなインフラが必要か

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

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

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

関連する概要

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

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

エージェント決済とは？AIエージェントがAPI、データ、コンピュートの料金を支払う仕組み

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