今では公開MCPサーバーが1万件を超えています。毎週のように新しいものが登場し、それぞれがAIコーディングエージェントにもう1つ機能を与えると約束しています。ウェブ検索？ MCPがあります。画像生成？ MCP。クラウドストレージ？ MCP。データベースアクセス？ MCP。
しかし、MCPサーバーを積み重ねることには見えにくいコストがあります。トークンの膨張、設定のずれ、認証情報の乱立、そして保守負担です。そこで登場しているのが、複数の機能を1つのエンドポイントにまとめたバンドル型の機能ランタイムです。
この比較は、あなたのワークフローにどちらが合うかを判断する助けになります。
MCPサーバー方式: 最高のものを1つずつ
仕組み
MCP (Model Context Protocol) サーバーは、AIエージェントにツールを公開する軽量プログラムです。.mcp.json ファイル、またはエージェントの設定で次のように構成します。
{
"mcpServers": {
"firecrawl": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {"FIRECRAWL_API_KEY": "key-1"}
},
"replicate": {
"command": "npx",
"args": ["-y", "mcp-replicate"],
"env": {"REPLICATE_API_TOKEN": "key-2"}
},
"filesystem": {
"command": "npx",
"args": ["-y", "@anthropic-ai/mcp-server-filesystem"],
"env": {"ALLOWED_DIRECTORIES": "/project"}
}
}
}
各サーバーは独自のツールを追加します。3つのサーバーがあれば、エージェントが使えるツールは15〜25個になるかもしれません。
メリット
専門性。 各MCPサーバーは1つのことに特化して優れています。Firecrawlはウェブスクレイピングが得意です。Replicateはモデルホスティングで強みがあります。Bright Dataはプロキシベースの検索に強いです。
エコシステム。 1万件以上のサーバーがあるということは、必要なものにはたいていMCPがあるということです。コミュニティは活発で、新しいサーバーも毎週リリースされています。
オープン標準。 MCPはAnthropicが支えるオープンプロトコルです。Claude以外にも広がっており、Cursor、Codex、Windsurf も対応しています。
プロセス分離。 各MCPサーバーは別プロセスとして動作します。1つがクラッシュしても他には影響しません。
デメリット
トークン膨張。 各MCPサーバーは、そのツールをエージェントのコンテキストに登録します。各ツールには名前、説明、パラメータスキーマが含まれます。典型的なMCPサーバーは、ツール説明だけで3,000〜8,000トークンを追加します。7台あれば、最初のプロンプトを送る前に30,000〜50,000トークンを消費しかねません。
典型的な構成での実データ:
| MCPサーバー数 | 推定トークンオーバーヘッド | 200Kコンテキストに対する割合 |
|---|---|---|
| 1台 | 3,000-8,000 | 1.5-4 % |
| 3台 | 9,000-24,000 | 4.5-12 % |
| 5台 | 15,000-40,000 | 7.5-20 % |
| 7台 | 21,000-56,000 | 10.5-28 % |
| 10台以上 | 30,000-80,000+ | 15-40 %+ |
7台を超えると、コンテキストウィンドウの4分の1をツール説明だけで使っていることになります。そのトークンは、本来なら実コード、推論、会話履歴に使えたはずです。
設定のずれ。 .mcp.json は時間とともに増えていきます。サーバーは更新され、APIは変わり、環境変数は期限切れになります。先月は動いていたサーバーが、今日は黙って失敗することもあります。
認証情報の乱立。 MCPサーバーが5つあればAPIキーも5つです。すべてにローテーションが必要で、すべてがセキュリティリスクになり得ます。新しいメンバーのオンボーディングもその分面倒になります。
インフラコスト。 MCPサーバーごとに必要なランタイムが異なることがあります。Python、Node.js、Rust、Docker などです。エージェントのツールチェーンを動かすだけで npx、uvx、python、docker を全部そろえる必要があるかもしれません。
出力形式の不一致。 あるサーバーはJSON、別のサーバーはプレーンテキスト、また別のサーバーはストリーミング応答を返します。エージェントはそれぞれを別の方法でパースしなければなりません。
バンドル型ランタイム方式: 1つのエンドポイントで多機能に
仕組み
機能ランタイムは、ウェブ検索、画像生成、動画生成、クラウドストレージ、公開など複数の機能を、1つのインターフェースの背後にまとめた単一のCLIツールまたはAPIエンドポイントです。
# 1回だけインストール
curl -fsSL https://anycap.ai/install.sh | bash
# 1つのツールで複数機能
anycap search "latest React changes"
anycap image generate "dashboard UI mockup"
anycap video generate "product demo 30s"
anycap drive upload ./build/
anycap page deploy ./docs/
メリット
最小限のトークンオーバーヘッド。 5つ以上のMCPサーバーがそれぞれツールを登録する代わりに、バンドル型ランタイムは単一ツール、または少数のツールとして登録されます。トークンオーバーヘッドは24,000+から2,000〜4,000へ下がります。
単一の認証情報。 APIキーもログインも1つで済みます。ローテーションも失効も1か所で完結します。
一貫した出力。 すべての機能が同じ形式の構造化JSONを返します。エージェントが5種類の応答形式を扱う必要はありません。
保守ゼロ。 サーバー間のバージョンずれも、依存関係の衝突も、ランタイムの不一致もありません。更新はランタイム内部で処理されます。
オンボーディングが速い。 新しいチームメンバーはインストールコマンドを1回実行するだけで5つの機能を使えます。5つのMCPサーバーを別々のAPIキー付きで設定する必要はありません。
デメリット
専門性はやや低い。 バンドル型ランタイムは、個別機能ごとの深さでは専用サーバーに及ばない場合があります。Firecrawl は、バンドルされた検索ツールより高度なウェブスクレイピング機能を持っているかもしれません。Replicate は、バンドルされた画像生成器より柔軟なモデル選択を提供するかもしれません。
ベンダー依存。 複数の機能を1社に依存することになります。ランタイムが停止すれば、5つの機能が同時に止まります。
選択肢が少ない。 MCPでは、仕事ごとに最適なツールを選べます。ランタイムは特定のモデルとサービスのセットをまとめているため、個別コンポーネントの差し替えはできません。
新しいカテゴリ。 バンドル型機能ランタイムはMCPサーバーより新しい概念です。エコシステムは小さく、コミュニティの成熟度もまだ高くありません。
判断フレームワーク: どちらを選ぶべきか?
個別のMCPサーバーを選ぶべき場合
- 各カテゴリで絶対的に最高のツールが必要なとき（品質のためなら設定の手間を受け入れられる）
- ワークフローで必要な機能が2〜3個だけのとき（トークンと保守コストを管理しやすい）
- 複数のAPIキーとサーバー設定を管理できるインフラがあるとき
- 個々のコンポーネント品質が重要な本番システムを構築しているとき
- バンドル型ランタイムに代替がない特定のMCPサーバーが必要なとき
バンドル型ランタイムを選ぶべき場合
- 数時間ではなく数分で始めたいとき
- エージェントに4つ以上の機能が必要なとき（MCPサーバーのトークン膨張が無視できなくなる）
- 専任DevOpsのいない個人開発者や小規模チームであるとき
- 開発体験を重視するとき（1回のインストール、1つの認証情報、1つの出力形式）
- 試作や高速な反復をしたいが、ツール基盤を保守したくないとき
ハイブリッドアプローチ
多くのチームは最終的にハイブリッドに落ち着きます。よく使う機能（検索、画像、動画、ストレージ、公開）はバンドル型ランタイムに任せ、独自要件（データベースアクセス、社内API統合、カスタムツール）には1つか2つの専門MCPサーバーを使う形です。
{
"mcpServers": {
"internal-db": {
"command": "python",
"args": ["-m", "internal_db_mcp"],
"env": {"DB_URL": "postgres://..."}
}
}
}
これを、検索、画像生成、動画、クラウドストレージ、公開などを扱うAnyCapのような機能ランタイムと組み合わせます。これで両方の良いところを得られます。必要な場所では専門的な深さを、その他の場所では最小限のオーバーヘッドを確保できます。
実世界での比較
| シナリオ | MCPスタックの推奨 | ランタイムの推奨 |
|---|---|---|
| 個人開発者のサイドプロジェクト | オーバーヘッドが大きすぎる | ✅ すぐに導入、認証情報は1つ |
| DevOps支援のある企業チーム | ✅ ベストオブブリード、管理可能 | 補完的に利用 |
| 小規模スタートアップ（3〜10人の開発者） | オーバーヘッドがすぐ増える | ✅ 保守負担が軽い |
| エージェントに5つ以上の機能が必要 | トークン膨張が現実になる | ✅ ツールを集約 |
| Slack、Jira、GitHubのような特定の企業向けMCPが必要 | ✅ ランタイムに相当品なし | メディア用途でランタイムを補完 |
| 新製品アイデアの試作 | 設定で勢いが削がれる | ✅ すぐに機能を使える |
| 本番CI/CDエージェントパイプライン | ✅ 信頼性のために個別サーバー | 補完的に使用 |
トークンコストの現実チェック
具体的に見てみましょう。Claude Sonnet 4 を使い、200Kのコンテキストウィンドウがあるとします。エージェントのやり取りは50往復です。
6つのMCPサーバーを使う場合（典型例）:
| 内容 | トークン |
|---|---|
| ツール説明（6サーバー） | ~28,000 |
| システムプロンプト | ~2,000 |
| ユーザーメッセージ（50往復） | ~25,000 |
| エージェント応答（50往復） | ~50,000 |
| ツール出力（6サーバー、使用はさまざま） | ~40,000 |
| 1セッション合計 | ~145,000 |
| 残りコンテキスト | 55,000 (27.5 %) |
1つの機能ランタイム + 1つの専門MCPを使う場合:
| 内容 | トークン |
|---|---|
| ツール説明（ランタイム1つ + MCP1つ） | ~6,000 |
| システムプロンプト | ~2,000 |
| ユーザーメッセージ（50往復） | ~25,000 |
| エージェント応答（50往復） | ~50,000 |
| ツール出力 | ~40,000 |
| 1セッション合計 | ~123,000 |
| 残りコンテキスト | 77,000 (38.5 %) |
差分: 実作業に使えるトークンが22,000増える。 これは会話を約15往復追加できる、あるいはコンテキスト制限に達する前にかなり大きなコードベースを処理できる、という意味です。
結論
MCPサーバーは強力で、エコシステムも活況です。しかし、10個も積み重ねる前提で設計されたわけではありません。トークンと保守のコストは、多くの開発者が思うより早く積み上がります。
バンドル型機能ランタイムはMCPの代替ではありません。補完です。特殊で独自性のある統合にはMCPサーバーを使い、検索、メディア生成、ストレージ、公開のように、すべてのエージェントに必要な共通機能にはAnyCapのようなランタイムを使ってください。
目標はどちらでも同じです。エージェントに本当に仕事をするためのツールを与えつつ、設定に溺れたり、インフラのためにコンテキストウィンドウを食い潰したりしないことです。