「自社の 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 は「叩かれる」から「AI に呼ばれる」へ
これまで API は人間（フロントエンド・バッチ）から叩かれる前提で設計されてきました。しかし MCP の登場で、「AI エージェントから自然言語で呼ばれる」を前提にした再設計が必要になっています。
A〜D のどのパターンに寄せるかは、API の本数ではなく、AI に任せてよい操作の線引き——ホワイトリストに何を載せないか、どの操作に HITL を挟むか——で決まります。ここは既存 API の作りと社内の承認フローを見ないと判断できないため、決まった型はありません。手元のエンドポイントの規模感と「まず自然言語で叩けるようにしたいユースケース」を お問い合わせフォーム に書いていただければ、どこから切り出すかの当たりを一緒に付けるところから始められます。
