Backend for Agent：MCPをスケールさせるアーキテクチャパターン

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の128週目の記事です！
3年間連続達成まで残り31週となりました！

はじめに：MCPブームの次のステップ

2024年11月にAnthropicがModel Context Protocol（MCP）を発表して以来、AIエージェントの世界は大きく変わりました。2025年にはOpenAI、Google DeepMindも採用を表明し、MCPは事実上の業界標準となりつつあります。

「MCPサーバーを繋げば、AIはなんでもできるようになる」

そんな期待のもと、多くの開発者が複数のMCPサーバーを組み合わせたエージェント構築に取り組んでいます。しかし、実際に複数のMCPサーバーを接続してみると、新たな課題が見えてきます。

本記事では、複数MCPサーバー環境で発生する課題を分析し、マイクロサービス時代に生まれたBFF（Backend For Frontend）の考え方を援用した**BFA（Backend For Agent）**というアーキテクチャパターンを提案します。

問題提起：複数MCPサーバー直接接続の課題

よくあるアプローチ

MCPの導入において、最もよく見られるアプローチは以下のような「直接接続」です。

Agent ──┬── MCP Server A（Notion）
        ├── MCP Server B（Slack）
        └── MCP Server C（Google Drive）

各MCPサーバーを直接Agentに接続する構成。シンプルで、MCPの恩恵をすぐに受けられます。

発生する課題：精度低下の負のサイクルに陥るリスク

しかし、この構成には構造的な落とし穴があります。一見独立した課題が、実は連鎖する負のサイクルに陥る可能性があります。

1. 横断検索が困難で精度が出ない — 複数ソースを跨いだ操作がAgent任せになり、結果が安定しない
2. 決定論的ツールで個別対応→精度は安定 — 固定クエリ等でシナリオごとに安定させるが、体系的な設計なしではツールが増殖する
3. ツール爆発→精度低下 — ツール定義がコンテキストを圧迫し、利用ツール数のハードリミットにも到達。必要なツールが使えなくなり、再び精度問題に戻る

このサイクルの核心は、汎用MCPツールの精度不足を「安易な固定化」で補おうとすると、Agentの柔軟性を犠牲にし、結果としてツール爆発と精度低下を招きやすいという点にあります。

アプローチ	精度	柔軟性	本質的な問題
決定論的（固定クエリ等）	○ 安定	× 固定シナリオのみ	Agentの柔軟性が大幅に制限される
非決定論的（LLM任せ）	△ 不安定	○ 任意の要求に対応	精度が担保できない

この二択を超える方法はないか？——ここでBFAパターンが解を提示します。

ツール爆発問題：業界での認識

「ツール爆発」は単なる理論上の懸念ではありません。業界でも広く認識され、対策が講じられています。

ハードリミットの存在

主要なAI開発ツールは、MCPツール数に明示的な制限を設けています^[1]：

• Cursor: 40ツールのハードリミット
• GitHub Copilot: 128ツールのハードリミット

これを超えると、先頭のツールのみがAgentに公開され、残りはアクセス不能になります。

コンテキスト消費の実態

ツール定義自体がコンテキストウィンドウを圧迫します。Anthropicが公開した事例では、50以上のMCPツール定義だけで約72Kトークンを消費^[2]。これは200Kトークンのコンテキストウィンドウの36%に相当します。ツール定義を読み込んだ時点で、推論に使える領域が大幅に制限されるのです。

根本原因の指摘

Tool calling doesn't usually fail because "LLMs are bad at handling tools." It fails because we overload the model with too many tools or badly designed tools.^[3]

（ツール呼び出しの失敗原因はLLMの能力不足ではなく、ツール過多や設計不良である）

つまり、MCPサーバーを「繋げば繋ぐほど便利になる」という期待は、一定のスケールを超えると逆効果になり得ます。

具体例：横断検索の問題

例えば、こんなリクエストを考えてみましょう。

「NotionとSlackとGoogle Driveから "プロジェクトX" に関する情報を集めて」

直接接続の場合、Agentは以下のように動作します：

Agent → Notion MCP（検索） → Agent
Agent → Slack MCP（検索） → Agent
Agent → Drive MCP（検索） → Agent
Agent → （自分で結果を統合）

問題点：

• Agentが3つのMCPサーバーを順に呼び出す
• 各結果をAgentのコンテキストに展開
• Agentが自分で結果を統合・要約
• コンテキスト消費大、精度不安定、非効率

提案：Backend for Agent（BFA）パターン

BFFからBFAへ

マイクロサービス時代に生まれた**BFF（Backend For Frontend）**パターンは、クライアント特性（Web/Mobile/Desktop）ごとに最適化されたAPIを提供します。

同じ発想を適用します。**BFA（Backend For Agent）**は、MCPサーバー群の上に位置し、Agent向けに最適化されたオーケストレーションとツールを提供する抽象化レイヤーです。

パターン	展開	役割
BFF	Backend For Frontend	フロントエンドのためのバックエンド
BFA	Backend For Agent	エージェントのためのバックエンド

アーキテクチャ

ポイント：

• MCPサーバーはデータソース接続として維持
• BFAが横断的なオーケストレーションを担う
• BFA自体がMCPツールとしてAgentに公開
• 非MCPバックエンド統合はオプション

BFAの核心的価値：オーケストレーション

先ほどの横断検索をBFA導入後で見てみましょう。

Before: Agent → MCP_A → Agent → MCP_B → Agent → MCP_C → Agent（統合）
After:  Agent → BFA.unified_search("プロジェクトX") → 統合済み結果

ただし、本質は呼び出し回数の削減ではありません。BFAの真価は、ドメイン知識を使って複数データソースの結果を意味的に統合できる点にあります。

具体例で見てみましょう。Agentが「プロジェクトXの今週の進捗」を把握したいとき、Slack・Notion・GitHubの3つのデータソースに散らばった情報を相関付ける必要があります。

// Agentから見えるのはシンプルな1呼び出し
Agent → BFA.get_project_progress("project-x", period="this_week")

// BFA内部の処理フロー（Agentからは隠蔽）
1. プロジェクトマッピング解決
   "project-x" → Slack: #proj-x-dev, #proj-x-design
                → Notion: database PX
                → GitHub: org/project-x

2. 各データソースへクエリ発行（並列）
   Slack:  #proj-x-dev, #proj-x-design の今週の議論を要約取得
   Notion: database PX のステータス変更・完了タスクを取得
   GitHub: org/project-x の今週のPR・レビューを取得

3. 相関付け
   Notion PX-142 ←→ GitHub PR #387 ←→ Slack "PX-142の設計レビュー完了"
   → 同一作業項目として紐付け

4. 統合結果を構造化して返却

// Agentが受け取る統合済み結果
{
  "project": "project-x",
  "period": "2025-W20",
  "completed_items": [
    {
      "id": "PX-142",
      "title": "認証フロー再設計",
      "notion_status": "Done",
      "pr": "#387 (merged)",
      "discussion_summary": "設計レビュー完了、パフォーマンス懸念なし"
    }
  ],
  "in_progress_items": [...],
  "blockers": [...]
}

これがBFAのSubAgent的振る舞いです。BFA内部でドメイン知識（プロジェクトとチャンネル・データベース・リポジトリの対応関係、タスクIDとPRの紐付けルールなど）を使い、データソース間の相関を解決する。Agentはこの処理フローを知る必要がありません。

この設計により、Agentは推論トークンをデータの突き合わせに消費せず、本来の判断—優先度の評価、リスクの指摘、次のアクションの提案—に集中できます。

MCP Gatewayとの違い
MCP Gatewayの汎用的なファンアウト（複数サーバーへ同じリクエストを並列送信）とは異なり、BFAはドメイン知識に基づいて何をどう問い合わせ、どう統合するかを判断します。この違いの詳細は後述の「MCP Gatewayとの違い」セクションで解説します。

責務分解：Agent向けツール最適化

BFAのもう一つの価値は責務分解です。各MCPサーバーの汎用ツールを、Agent向けに最適化します。

MCPサーバー側（汎用）:
  notion.search(query, filters, ...)    # 汎用検索、フィルタ自由
  slack.search(query, filters, ...)     # パラメータ多い

BFA側（Agent最適化）:
  search_recent_discussions(topic, days=7)  # 直近の議論を検索
  get_project_context(project_id)           # プロジェクト文脈を取得
  find_related_documents(keyword)           # 関連ドキュメント検索

責務を分解した小ぶりなツールにより：

• LLMが「今必要な操作」を的確に選択できる
• パラメータ数が少なく、誤用リスクが低下
• 意図通りの挙動を実現しやすい

MCP Gatewayとの違い

「それ、MCP Gatewayでできるのでは？」という疑問があるかもしれません。

確かにMCP Gatewayも中間層として機能しますが、責務の焦点が異なります：

観点	MCP Gateway	BFA
ツールのフィルタリング・集約	○	-
ルーティング・認証	○	-
複数サーバーの応答集約	△（一部対応）	○
ドメイン知識に基づくオーケストレーション	×	○ 核心
Agent向けツール再設計（責務分解）	×	○ 核心
コンテキスト最適化（圧縮・整形）	×	○ 核心

MCP Gatewayの集約機能について
MCP Gatewayの中には、複数サーバーの応答を集約するAggregation Gateway機能を持つものもあります。しかし、これは汎用的なリクエスト集約であり、BFAが担う「ドメイン知識に基づく結果の統合」や「Agent特性に応じたツール再設計」とは異なります。

MCP GatewayとBFAは排他的ではなく、共存可能です。Gatewayがインフラ層の関心事（ルーティング、認証、集約）を、BFAがアプリケーション層の関心事（ドメイン知識に基づくオーケストレーション、ツール再設計）を担当する。これはAPI GatewayとBFFが共存するのと同じ構図です。

BFAの責務と設計原則

BFAの責務

責務	説明
1. 横断的オーケストレーション	複数MCPサーバーを跨いだ操作の実行
2. 責務分解	Agent向けに最適化されたツール設計
3. 結果の統合・圧縮	複数ソースの結果を整形（TOON等）
4. コンテキスト整形	エージェント特性に応じた情報の取捨選択

設計原則

1. BFAはビジネスロジックを持たない（薄いオーケストレーション層）
2. One BFA per Agent Type（エージェント種別ごとに分離も可能）
3. MCPサーバーの汎用性は維持（BFAがAgent特化を担う）

比較：直接接続 vs BFA設計

観点	MCPサーバー直接接続	BFA設計
横断的操作	Agent任せ（非効率）	BFAがオーケストレーション
ツール数	全ツールがコンテキストに	必要なツールのみ公開
責務分解	各MCPサーバーの設計次第	Agent向けに最適化
結果の統合	Agentが都度実施	BFAが事前に統合
運用複雑性	低い	中程度（レイヤー追加）

シナリオ別の判断基準

シナリオ	推奨
単一MCPサーバー	直接接続でOK
複数MCPサーバー、横断操作少ない	直接接続でOK
複数MCPサーバー、横断操作多い	BFA導入を検討
複数種類のエージェント	BFA導入を推奨

実践への道筋

段階的導入アプローチ

1. Phase 0: 直接接続でPoC実施、横断操作の課題を可視化
2. Phase 1: 最も頻出する横断操作からBFAツール化
3. Phase 2: 責務分解によるツール最適化
4. Phase 3: 結果の圧縮・最適化（TOON等）

評価指標

• 横断操作の成功率
• コンテキストウィンドウ使用率
• ツール選択の精度
• レイテンシー

批判的検討：BFAの弱点

公平を期すため、BFAパターンの弱点も明示しておきます。

追加レイヤーの複雑性

もう1つレイヤーが増えることで、デプロイ・運用・デバッグの複雑性が増します。小規模なプロジェクトや横断操作が少ない場合は、直接接続の方がシンプルで適切です。

責務境界の曖昧さ

「この操作はMCPサーバー側か、BFA側か」の判断が曖昧になることがあります。明確な設計指針を持つことが重要です。

標準化の不在

現時点でBFAは概念提案に過ぎず、標準化されたインターフェースやSDKは存在しません。

まとめ

• 複数MCPサーバーを直接接続すると、横断操作がAgent任せになり非効率
• BFA（Backend For Agent）はオーケストレーション層として機能
• MCPサーバーはデータソース接続として維持、BFAがAgent向け最適化を担う
• MCP Gatewayは「フィルタリング・ルーティング」、BFAは「オーケストレーション・責務分解」
• BFFの教訓をAIエージェント時代に活かす

「MCPサーバーを繋ぐ」前に「オーケストレーションを設計する」

過去の知見を、AIエージェント時代に活かしていきましょう。

---

参考文献

• Anthropic - Model Context Protocol
• Sam Newman - Backends For Frontends

脚注

1. Model Context Protocol and the "too many tools" problem - Stefano Demiliani

2. Advanced tool use - Anthropic Engineering Blog

3. Tool calling is broken without MCP Server Composition - Hackteam