MCPツールのスケーリング

Overview

なぜMCPのスケーリングが問題になるのか

MCPの普及により、AIエージェントは多数の外部システムに接続できるようになりました。しかし接続先が増えるほど、エージェントの実行効率は低下します。根本原因は2つあります。

第一に、ツール定義がコンテキストウィンドウを圧迫する問題です。 MCPクライアントは通常、接続している全MCPサーバーのツール定義を事前にロードします。 ツール1つあたり数百トークンを消費するため、50ツールで約55,000トークン、100ツール超では10万トークン以上が、ユーザーの指示を処理する前に消費されます。 Anthropicの内部テストでは、最適化前のツール定義だけで134,000トークンを消費したケースが報告されています。

第二に、中間結果の往復がトークンを浪費する問題です。 従来のツール呼び出しでは、各ツールの実行結果がそのままLLMのコンテキストに蓄積されます。 たとえば「Google Driveから議事録を取得してSalesforceに添付する」という処理では、議事録の全文がコンテキストを2回通過します。2時間の会議の議事録なら、それだけで追加50,000トークンの消費です。

これらの問題は、PoCでは顕在化しにくく、本番環境でツール数が増えた段階で深刻化します。 2025年後半、AnthropicとCloudflareが独立して提唱した3つのアプローチが、この構造的課題への実践的な解法を示しました。

Approach 01

Code Mode — ツール定義を不要にする

Code Modeは、MCPの最も根本的なスケーリング問題——ツール定義のコンテキスト消費——を解決するアプローチです。 Cloudflareが2025年9月に提唱し、Anthropicも同様のパターンを「Code execution with MCP」として発表しました。

仕組み: search() と execute() の2ツール

Code Modeでは、数千のツール定義を渡す代わりに、わずか2つのメタツールだけをエージェントに提供します。 エージェントはsearch()でAPIスキーマをコードで検索し、execute()でAPI操作をコードで実行します。

実行例: エージェントが書くコード

たとえば「WAFとDDoS防御を有効化して」というユーザー指示に対し、エージェントはまずsearch()で関連エンドポイントを探索します。

async () => {
  const results = [];
  for (const [path, methods] of Object.entries(spec.paths)) {
    if (path.includes('/zones/') &&
        (path.includes('firewall/waf') || path.includes('rulesets'))) {
      for (const [method, op] of Object.entries(methods)) {
        results.push({ method: method.toUpperCase(), path, summary: op.summary });
      }
    }
  }
  return results;  // 2,500件 → 必要な10件だけ返す
}

2,500以上のエンドポイントから必要な10件だけを抽出し、全スキーマがコンテキストに入ることはありません。 続けてexecute()で、複数のAPI呼び出しを1回のコード実行にまとめます。

async () => {
  // DDoS L7のルールセットを取得
  const ddos = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets/phases/ddos_l7/entrypoint`
  });
  // WAFマネージドルールセットを取得
  const waf = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets/phases/http_request_firewall_managed/entrypoint`
  });
  return { ddos: ddos.result, waf: waf.result };
}

サーバーサイドCode Mode vs クライアントサイドCode Mode

Code Modeには2つの実装パターンがあります。 サーバーサイドではMCPサーバー自体が2ツールを提供し、エージェント側の変更が不要です。 クライアントサイドではエージェント側のSDKがMCPツールをTypeScript APIに変換し、エージェントはそのAPIに対してコードを書きます。

Approach 03

Programmatic Tool Calling — 中間結果をコンテキストから排除する

Programmatic Tool Calling（PTC）は、ツールの呼び出しと結果処理をコード実行環境内で完結させ、最終結果だけをLLMに返すアプローチです。 Anthropicが2025年11月にClaude APIのベータ機能として公開しました。

従来方式の問題: ツール呼び出しの「細切れ往復」

従来のツール呼び出しでは、各ツールの結果がそのままLLMのコンテキストに蓄積されます。 「チームメンバー20人の経費を確認して予算オーバーの人を報告して」という処理では、 全員の経費明細（2,000行以上、50KB超）がコンテキストを通過し、LLMがそのデータを「目視」で確認して集計しなければなりません。

team = await get_team_members("engineering")

# 全メンバーの経費を並列取得
expenses = await asyncio.gather(*[
    get_expenses(m["id"], "Q3") for m in team
])

# 予算取得 & 超過者の抽出（コンテキストには入らない）
budgets = {level: await get_budget_by_level(level)
           for level in set(m["level"] for m in team)}
exceeded = []
for member, exp in zip(team, expenses):
    total = sum(e["amount"] for e in exp)
    if total > budgets[member["level"]]["travel_limit"]:
        exceeded.append({"name": member["name"],
                         "spent": total,
                         "limit": budgets[member["level"]]["travel_limit"]})

print(json.dumps(exceeded))  # ← これだけがLLMに返る

Programmatic Tool Callingの追加メリット

Enterprise Considerations

エンタープライズ環境での実装考慮事項

これらの技術を本番環境に適用する際には、セキュリティ・ガバナンス・運用の3軸で追加の検討が必要です。

MCP活用ガイド — シリーズ内ナビゲーション

関連する他シリーズのガイド