「自社の REST API を AI エージェントから使えるようにしたい」——4 月以降、この相談が急増しています。きっかけは、Block（旧 Square）が決済・在庫管理 API 全体を MCP 対応させた事例です。販売事業者が「先月のフィッシュタコスの売上を教えて」と Claude に話しかけると、Square API 経由で売上分析が返ってくる——この体験が現場で衝撃を持って受け止められました。
ProofX の調査記事 でも報告されているように、海外フィンテックを起点に「既存の業務 API を MCP サーバーで包み直す」動きが本格化しています。本記事では、手元の REST/GraphQL API を MCP サーバー化するときの設計パターンを、受託案件の指針として整理します。
なぜ「API ラッパー」では不十分か
「OpenAPI 仕様から MCP サーバーを自動生成すればいい」——最初に皆が考える解決策ですが、ほぼ確実に失敗します。理由は 3 つあります。
- ツール数が爆発する：1 つの SaaS で数百のエンドポイントを持つことは珍しくなく、AI エージェントがツール選定で迷子になる
- スキーマが冗長：OpenAPI のレスポンスをそのまま渡すと、トークン消費が一気に膨らむ
- 副作用の説明がない：「DELETE /users/{id}」が”何を”消すのかは、ドキュメントを読まないと分からない
私たちが Drizzle ORM への移行ガイド で書いたように、「機械が読みやすい」と「AI が動きやすい」はイコールではありません。MCP サーバー化では、ツール定義を人間がユースケース起点で設計し直す必要があります。
4 つの設計パターン
弊社が受託で MCP サーバー化を進めるとき、案件特性に応じて次の 4 パターンから選定します。
パターン A: ユースケース集約型（推奨）
複数 API を 1 つのツールに集約し、ユースケース単位で公開します。
// NG: 自動生成された薄いラッパー
tools: [
"get_customer", "get_order", "get_invoice",
"list_payments", "list_refunds", "list_disputes" // … 100 個続く
]
// OK: ユースケース集約
tools: [
{
name: "summarize_customer_billing",
description: "顧客の請求状況サマリ（請求・入金・未収・係争中）を取得",
arguments: { customer_id: "string", period: "string?" }
}
]「summarize_customer_billing」の中で、内部的に複数 API を順に叩いて整形します。AI からは 1 ツールに見え、トークン消費もレスポンスも最小化できます。
パターン B: SDK ラッパー方式
公式 SDK が成熟している API（Stripe / Salesforce / GitHub など）は、SDK の関数を MCP ツールとして再エクスポートします。
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_KEY);
server.tool("create_customer", async (args) => {
return await stripe.customers.create(args);
});メリットは認証・リトライ・レート制限を SDK に任せられる点。デメリットはツール数の爆発で、これは事前にホワイトリストを決めて緩和します。
パターン C: GraphQL クエリビルダ型
GraphQL API を持つ社内サービスは、MCP に「クエリ片」を渡してもらうのが効率的です。フィールドを AI に選ばせ、必要なデータだけ取得します。
server.tool("graphql_query", {
description: "社内 GraphQL に対し、許可されたフィールドのみクエリ実行",
schema: ALLOWLISTED_SCHEMA,
});ただしクエリ深度や計算量に制限を必ず入れてください。AI が悪気なく N+1 クエリを生成して、本番 DB を落とす事故が実例として報告されています。
パターン D: イベントストリーム型
Webhook や SSE で AI に「状況の変化」を渡すケース。MCP の Resource として実装し、定期的に AI にコンテキストを供給します。在庫アラート・障害通知などに向きます。
トークン節約のスキーマ整形
API が返す JSON をそのまま AI に渡すと、トークンが致命的に膨らみます。MCP サーバー側で 3 段階の整形を入れるのが定石です。
| 整形ステップ | 削減率の目安 | 例 |
|---|---|---|
| 不要フィールド除去 | 30〜50% | created_at_unix など重複情報を捨てる |
| 列挙値の短縮 | 10〜20% | "PAYMENT_STATUS_SUCCEEDED" → "ok" |
| 表形式への要約 | 50〜80% | 100 件のレコードを Markdown テーブル 5 行に要約 |
私たちが pgvector の本番運用ガイド で書いたコスト最適化の考え方は、MCP サーバーのレスポンス整形にもそのまま適用できます。
HITL（人間承認）が必須の操作を設計する
破壊的・金銭的・対外的な操作は、MCP ツールに「確認待ち」状態を持たせる設計が安全です。
server.tool("send_invoice", async (args, ctx) => {
if (!ctx.userApproved) {
return {
kind: "approval_required",
summary: `${args.customer} に ¥${args.amount} の請求書を送ります`,
approval_token: issueApprovalToken(args),
};
}
return await invoiceClient.send(args);
});クライアントの UI 側で「承認ボタン」を表示し、承認後に approval_token を添えて再呼び出しします。この設計は Anthropic Computer Use を業務に組み込むガイド でも触れた、エージェントに対する HITL の標準手法です。
受託案件の型
API → MCP サーバー化を起点とした案件で、いま動きやすい型は次の 3 つです。
| 案件の型 | 期間 | 単価帯 | 提供物 |
|---|---|---|---|
| ユースケース MCP 設計 + 実装 | 6〜10 週間 | 400〜800 万円 | ツール仕様・実装・テスト |
| 既存 SDK の MCP ラップ | 3〜5 週間 | 200〜400 万円 | ホワイトリスト + ラッパー |
| MCP ホスティング基盤構築 | 8〜12 週間 | 600〜1,500 万円 | 認証・監査・スケーリング |
ホスティング基盤までセットで取れると、運用フェーズも含めた長期パートナー化が成立します。
まとめ — API は「叩かれる」から「AI に呼ばれる」へ
これまで API は人間（フロントエンド・バッチ）から叩かれる前提で設計されてきました。しかし MCP の登場で、「AI エージェントから自然言語で呼ばれる」を前提にした再設計が必要になっています。
弊社では、SaaS API の MCP サーバー化、MCP ホスティング基盤構築、ユースケース設計支援をワンストップで提供しています。「自社 API をエージェント時代に対応させたい」というご相談は、お問い合わせフォーム からお声がけください。
