AIエージェントが自らのAPI呼び出し料金を支払うときに起きること

あなたのAIエージェントはフライトを検索する必要があります。リアルタイムの株価が必要です。レシート画像をOCRする必要があります。これらそれぞれには、異なるAPI、異なる認証フロー、異なる請求アカウントが必要です。

エージェントがただ…各呼び出しを自分で支払うだけだとしたら？ サブスクリプションなし。APIキーの管理なし。人間がループに入ることなし。

それが私が作ったものです。以下がその仕組みです。

問題点: API統合はすべてのエージェントビルダーに課されるコスト

現実世界と相互作用するAIエージェントを構築しているなら、すでに痛みを知っているはずです：

• Amadeus には double-base64 エンコードを用いた OAuth2 が必要です
• Finnhub はクエリパラメータのトークンを使用します
• Serper は X-API-KEY ヘッダーを要求します
• NASA は URL に ?api_key= を使用します
• いくつかの API は呼び出しごと、他は月額、他は文字数ごとに料金が発生します

各プロバイダーごとに、認証コード、エラーハンドリング、リトライロジック、レート制限、請求の統合を実装しています。それを10件のプロバイダー分掛け合わせると、実際のエージェントロジックよりも配線（パイプライン）作業に時間を取られてしまいます。

私は、私のエージェントがツール呼び出しを送り、USDC で支払い、データを返す、1つのエンドポイントが欲しかった。サインアップフォームも、ダッシュボードも、請求書もなし。

解決策: MCP + x402 を1つのパイプラインで

46 の上流 API プロバイダを1つのエンドポイントの背後にラップする MCP サーバを構築しました。エージェントは https://apibase.pro/mcp に接続し、203 の利用可能なツールを検出し、任意のツールを呼び出します。支払いは x402 プロトコル — Base 上の USDC を用いた HTTP 402 — で自動的に行われます。

エージェントの観点から見た、単一ツール呼び出しの例は次のとおりです：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "stocks.market.quote",
    "arguments": {
      "symbol": "AAPL"
    }
  }
}

レスポンスは株価を返します。舞台裏では $0.001 USDC がエスクローされ、Finnhub API が呼ばれ、支払いが決済されました — すべて 400ms 未満で。

13段階のパイプライン

すべてのツール呼び出しは、厳格な順序で13段階を通過します。いかなる段階もスキップできず、再順序もできません：

AUTH → IDEMPOTENCY → CONTENT_NEG → SCHEMA_VALIDATION → TOOL_STATUS → CACHE_OR_SINGLE_FLIGHT → RATE_LIMIT → ESCROW → PROVIDER_CALL → ESCROW_FINALIZE → LEDGER_WRITE → CACHE_SET → RESPONSE

最も重要な段階を順にご案内します。

Stage 1: AUTH

エージェントは Bearer トークンで認証します。最初のリクエスト時、システムは自動的にエージェントを登録し、APIキーを返します — 人間のサインアップは必要ありません。

curl -X POST https://apibase.pro/api/v1/agents/register \

  -H "Content-Type: application/json" \

  -d '{"agent_name": "my-agent", "agent_version": "1.0.0"}'

返されるのは api_key: ak_live_... — PostgreSQL に SHA-256 ハッシュとして保存され、プレーンテキストでは保存されません。

Stage 4: SCHEMA_VALIDATION

すべてのツールには各フィールドに .describe() を持つ Zod スキーマがあります。エージェントはガーベジを送ることはできません — 無効なパラメータはこの段階で、金銭が動く前に明確なエラーメッセージとともに拒否されます。

const search = z.object({ q: z.string().min(1).describe('Search query'), gl: z.string().max(2).optional().describe('Country code (e.g. "us")'), num: z.number().int().min(1).max(100).optional().describe('Results count'), }).strip();

Stage 8: ESCROW

ここが本題です。上流プロバイダを呼ぶ前に、ツールの価格を USDC で固定します：

USDC はエージェントの残高から PostgreSQL の取引で予約されます。プロバイダ呼び出しが失敗した場合、ステージ 10 が自動的に払い戻します。

Stage 9: PROVIDER_CALL

以降で実際に上流 API を呼び出します。各プロバイダには認証、リクエスト作成、レスポンス正規化を処理する専用のアダプターがあります。

エージェントが送るもの：

{"symbol": "AAPL"}

私たちのアダプターが Finnhub に送るもの：

GET https://finnhub.io/api/v1/quote?symbol=AAPL&token=xxxxx

エージェントに返ってくるもの（正規化済み）：

{"price": 249.94, "change": -4.06, "change_percent": -1.60, "high": 254.94, "low": 249.00, "open": 253.78, "previous_close": 254.00}

エージェントは上流 API のフォーマット、認証ヘッダ、エラーコードを見ることは決してありません。すべてのツールは同じ正規化された構造を返します。

Stage 10: ESCROW_FINALIZE + LEDGER_WRITE

もしプロバイダ呼び出しが成功した場合：エスクローを決済し、追記可能な元帳に書き込みます。失敗した場合：USDC を払い戻し、REFUNDED の元帳エントリを書き込みます。これは単一の PostgreSQL トランザクションで行われます — 部分的な状態は発生しません。

元帳は追記専用です。行を UPDATE したり DELETE したりすることは決してありません。これにより、すべての支払いの完全な監査証跡を得ることができます。

What 46 Providers Look Like Through One Pipe

この単一の MCP エンドポイントを通じてエージェントができることのサンプルは以下のとおりです：

各ツールの料金は1回の呼び出しにつき0.001〜0.070ドルの範囲です。エージェントはタスクに基づいて呼ぶものを決定します。サブスクリプションなし、最低利用料なし。

キャッシュ層: なぜほとんどの呼び出しがほぼ無料になるのか

Stage 6はアップストリームプロバイダに接続する前にRedisを確認します。各ツールには設定済みのTTLがあります:

• finnhub.quote — 5秒（株価は急速に変動します）
• walkscore.score — 7日間（歩行性スコアはほとんど変わりません）
• news.latest — 1分（ニュースは頻繁に更新されます）
• courtlistener.search — 1時間（判例は歴史的です）

同じ5秒のウィンドウで100人のエージェントがAAPLの株価を要求すると、アップストリームの呼び出しは1回だけです。ほかの99人はキャッシュ結果を即座に取得します— 請求は発生しますが、キャッシュヒット価格は低く、アップストリームプロバイダには1件のリクエストしか伝わりません。

シングルフライトのデデュプリケーションは雷の群衆を防ぎます。 同時に同一のリクエストは、すべてがプロバイダを同時に叩くのを待つのではなく、最初のリクエストが完了するのを待ちます。

これを作る上で学んだこと

1. エスクロー優先は譲れない。 初期のバージョンはプロバイダ呼び出しの直後に課金していました。しかしエージェントが応答の途中で切断されると、支払いなしでアップストリームコストを負うことになります。呼び出し前のエスクローはこれを完全に排除します。

2. 冪等性は二重請求を防ぎます。 タイムアウト時にエージェントは再試行します。冪等性キーがなければ、1回のフライト検索でエージェントに二重請求される可能性があります。 Stage 2は作業が始まる前に重複を検出します。

3. Fail-closedはFail-openより堅牢です。 Redisがダウンした場合、レート制限とキャッシュを無効にするのではなく、すべてのリクエストを拒否します。これは過激に聞こえるかもしれませんが、1つのRedis再起動が未処理のアップストリーム呼び出しの連鎖を防ぎます。

4. 13段階はオーバーヘッドのように思えるが、それぞれが実際の本番環境のバグを防ぐ。 私たちは1度だけ1つの段階を削除しました（コンテンツ交渉） そしてすぐにエージェントがXMLをJSONのみのプロバイダへ送信するようになりました。 各段階は、それが防ぐバグを避けるために存在します。

自分で試してみる

任意のMCPクライアントをエンドポイントに接続して、ツールを探ってみてください:

curl -X POST https://apibase.pro/mcp \\
  -H "Content-Type: application/json" \\
  -d {"jsonrpc":"2.0","method":"initialize","id":1,"params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

また Claude Desktop / Cursorへ追加するには:

{
  "mcpServers": {
    "apibase": {
      "url": "https://apibase.pro/mcp"
    }
  }
}

203 tools. One endpoint. The agent pays for what it uses.

Built with APIbase — open source on GitHub.