MCPの未来：常時起動からオンデマンドローディングへ
Claude Codeの次の進化に関するアーキテクチャ提案 - セッション開始時にすべてを読み込むのではなく、特定のAgentやSkillにMCPサーバーを割り当てる。
問題：コンテキスト予算への圧迫
複数のMCPサーバーでClaude Codeを使用している場合、おそらく気づいているでしょう：最初のメッセージを入力する前に、コンテキストウィンドウがすでに埋まり始めています。
典型的なシナリオはこちらです：
| MCPサーバー | おおよそのトークンコスト | ソース |
|---|---|---|
| GitHub (27 tools) | ~18,000 | Issue #11364 |
| AWS MCPサーバー | ~18,300 | Issue #7172 |
| Cloudflare | ~15,000+ | コミュニティ報告 |
| Sentry | ~14,000 | コミュニティ報告 |
| Playwright (21 tools) | ~13,647 | Scott Spence |
| Supabase | ~12,000+ | コミュニティ報告 |
| ツールあたり平均 | ~550-850 | Issue #11364 |
実測影響：7つのMCPサーバーがアクティブな場合、ツール定義だけで**67,300トークン（200kコンテキストの33.7%）**を消費します。最小限の3サーバー構成でも42,600トークン（21.3%）を消費します。
皮肉なことに、これらのMCPの多くは特定のセッションで使用されません。14,000トークンを占めるSentry統合？今日は必要ないかもしれません。しかし、毎回そこにあり、コンテキストを消費しています。
観察：フォークアーキテクチャはすでに存在する
Claude Code 2.1.xは強力な機能を導入しました：スキルのcontext: fork。これにより、スキルは独自のツール権限と状態を持つ隔離されたコンテキストで実行できます。
# フォークされたコンテキストを持つスキル
---
description: 本番環境にデプロイ
context: fork
allowed-tools: [Bash, Read]
---このスキルが実行されると、独自のコンテキストバブルを取得します。変更はメインの会話を汚染しません。クリーンで、隔離されており、機能します。
ここでの洞察：コンテキストをフォークできるなら、MCPアクセスもフォークできるのではないでしょうか？
提案：MCPコンテキスト隔離
重要な違い：この提案は、一般的な「遅延ロード」アプローチとは根本的に異なります。メインコンテキストへの動的なランタイムロードを提案しているのではありません。代わりに、MCPをフォークされたエージェント/スキルコンテキストに隔離し、メインコンテキストを永続的にクリーンに保つことを提案します。
| アプローチ | メインコンテキスト | ロードタイミング | 複雑さ |
|---|---|---|---|
| 従来の遅延ロード | 必要時にMCPで埋まる | ランタイム動的 | 高（状態管理） |
| 私たちの提案：コンテキスト隔離 | 常にクリーン | フォーク作成時に一度 | 低（既存のcontext: forkを使用） |
従来の遅延ロード:
Main Context ──[MCPが必要]──> MCPロード ──> Main Context（占有される）
私たちの提案（コンテキスト隔離）:
Main Context（クリーンなまま）
└── Fork Agent Context ──> MCPsロード ──> 隔離されたContext
└── 完了後に解放このアーキテクチャを想像してください：
# agents/database-specialist.md
---
name: database-specialist
description: データベース操作エキスパート
tools: [Read, Bash, Grep]
mcp: [postgres, redis] # ← このエージェント実行時のみロード
context: fork
---# skills/deploy/SKILL.md
---
description: 本番環境にデプロイ
mcp: [vercel, github] # ← /deploy実行時のみロード
context: fork
---メインセッションはスリムに保たれます：
メインセッション（スリム）
│
├── 基本MCPのみ：filesystem, memory
│ （20,000+ではなく~1,300トークン）
│
├── Task: database-specialist（フォーク）
│ └── ロード：postgres, redis（ここでのみ）
│
└── Skill: /deploy（フォーク）
└── ロード：vercel, github（ここでのみ）実例：現代のワークハブ問題
多くの人が日々直面するシナリオです：
マルチプラットフォームの現実
現代のナレッジワーカーは膨大な数のプラットフォームを同時に管理しています：
| カテゴリー | プラットフォーム |
|---|---|
| コードホスティング | GitHub, GitLab, Bitbucket |
| プロジェクト管理 | Jira, Linear, Asana, Notion |
| コミュニケーション | Slack, Discord, Teams, Email |
| CI/CD | Vercel, Netlify, AWS |
| モニタリング | Sentry, Datadog, PagerDuty |
| CRM/ビジネス | Salesforce, HubSpot, Stripe |
これらすべてにMCPがあります。このジレンマを想像してください：
オプションA：すべてインストール
セッション開始時にすべてのMCPをロード：
- github (~2,000トークン)
- gitlab (~2,500トークン)
- slack (~3,000トークン)
- jira (~4,000トークン)
- notion (~2,500トークン)
- sentry (~14,000トークン)
- ...さらに10個以上
合計：50,000+トークン、作業開始前に消費。
コンテキスト予算の50%が消えます。オプションB：プロジェクト別に分離
プロジェクトA: github + vercel
プロジェクトB: gitlab + jira
プロジェクトC: slack + notionこれでは本末転倒です。Claude Codeの強みは統一されたコマンドセンター - すべてのツールを一箇所で統合することです。プロジェクト別に分けると：
- 常にコンテキスト切り替えが必要
- クロスプラットフォームの洞察を失う
- 統一ワークフロー自動化ができない
オプションC：オンデマンドの未来
# skills/work-hub/SKILL.md
---
description: 統一ワーク管理ハブ
mcp:
communication: [slack, discord]
code: [github, gitlab]
projects: [jira, notion]
monitoring: [sentry]
context: fork
---これでClaude Codeは本来あるべき姿になります：デジタルワークライフの真の中枢神経系統。必要なこと：
- GitHub PRチェック + Slack通知 + Jira更新？1コマンド。
- GitLab MRレビュー + Discord投稿 + Notion記録？1コマンド。
- Sentryエラーデバッグ + GitHub issue作成 + Linearアサイン？1コマンド。
各ワークフローは必要なMCPだけをロードします。メインコンテキストはクリーンなまま。
現在の回避策（理想的ではない）
はい、今日でもスキルを使ってMCPなしで機能をラップできます - bash/curlで直接APIを呼び出す方法です。しかし、それは：
- より脆弱（MCPのエラーハンドリングがない）
- より冗長（生のAPI vs セマンティックツール）
- 本質を見失っている（MCPには存在理由がある）
最も重要な問題は認証です：
| 側面 | MCP | Skills + Scripts |
|---|---|---|
| 認証管理 | settings.json に集中 | .env、スクリプト、環境変数に散在 |
| セキュリティ | 環境隔離 | ログ/シェル履歴への漏洩リスク |
| トークン更新 | 自動処理 | 手動実装が必要 |
| エラー処理 | 標準化されたレスポンス | API ごとに異なる |
# MCP アプローチ - クリーンで安全
mcp: [github]
# 認証は settings.json に、隔離され、決して露出しない
# スクリプトアプローチ - 認証があちこちに散在
# オプション 1：.env ファイル（管理が必要）
# オプション 2：スクリプトにハードコード（危険）
# オプション 3：毎回渡す（面倒、エラーが起きやすい）MCP の価値はツールだけではありません—集中的で安全な認証管理です。コンテキスト隔離はこの利点を維持しながら、コンテキスト消費の問題を解決します。
オンデマンドアーキテクチャは単なる最適化ではありません。Claude Codeのユニバーサルワークオーケストレーターとしての潜在能力を解き放つ鍵です。
なぜこれが理にかなっているか
1. コンテキスト効率
メインの会話は完全なコンテキスト予算を維持します。MCPは、それを必要とする特定のエージェントまたはスキルが実行されたときにのみロードされます。
2. 細かい権限制御
「このセッションはすべてにアクセスできる」ではなく、階層的な制御が得られます：
レイヤー0：メインコンテキスト（最小限）
└── filesystem（読み取り専用）, memory
レイヤー1：開発エージェント
└── code-reviewer: + git（読み取り）
└── debugger: + bash（サンドボックス）
レイヤー2：専門スキル
└── /deploy: + vercel, github（プッシュ）
└── /db-migrate: + postgres（書き込み）
レイヤー3：管理操作
└── /production-access: すべて（確認付き）3. 段階的セキュリティ
「全か無か」の権限ではなく、多層防御が得られます。コードレビューにはデータベース書き込みアクセスは不要です。デプロイにはSentryアクセスは不要です。
4. エコシステムのスケーラビリティ
MCPエコシステムは爆発的に成長しています。毎週数十の新しいサーバーが登場します。「開始時にすべてをロード」モデルは単純にスケールしません。
実装の可能性
理想的なソリューションは、最大の柔軟性と後方互換性のために双方向の設定を組み合わせます：
MCP側：遅延ロードフラグ
settings.jsonで、各MCPがセッション開始時にロードするかどうかを宣言できます：
{
"mcpServers": {
"memory": {
"command": "...",
"lazy": false // 常にロード（デフォルト、後方互換）
},
"github": {
"command": "...",
"lazy": true // リクエストまでロードしない
},
"postgres": {
"command": "...",
"lazy": true // リクエストまでロードしない
}
}
}後方互換性：lazyを省略するか、lazy: falseを設定すると、現在の動作が維持されます。
Agent/Skill側：Frontmatter宣言
エージェントとスキルは必要なMCPを宣言します：
# agents/database-specialist.md
---
name: database-specialist
description: データベース操作エキスパート
tools: [Read, Bash, Grep]
mcp:
required: [postgres] # 必須
optional: [redis] # あれば良い
context: fork
---ロードロジック
MCP lazy 設定 | Agent/Skill 宣言 | 結果 |
|---|---|---|
false（または省略） | - | ✅ セッション開始時にロード（現在の動作） |
true | 宣言なし | ❌ ロードしない |
true | mcp: [xxx] | ✅ Agent/Skill実行時にロード |
この双方向アプローチにより：
- 段階的移行：大きなMCPを順次
lazy: trueに変更 - 破壊的変更ゼロ：既存の設定はそのまま動作
- 細粒度制御：インフラ層とアプリケーション層の両方で設定可能
証拠：Claude Codeはこの方向に向かっている
進化を見てください：
| バージョン | 機能 | トレンド |
|---|---|---|
| 2.0.65 | Context awareness, status line | コンテキスト使用量の追跡 |
| 2.1.0 | スキルのcontext: fork | 隔離アーキテクチャ |
| 2.1.1 | Agent frontmatter | 設定可能なエージェント |
| 2.1.3 | Skills = Commands統一 | 簡素化 |
| 2.2.x? | オンデマンドMCP？ | 論理的な次のステップ |
ピースは揃っています。アーキテクチャはそれをサポートしています。ニーズは明確です。
考慮すべき課題
| 課題 | 可能な解決策 |
|---|---|
| MCP起動遅延 | ウォームプール、最初の言及時に事前接続 |
| フォーク終了後の状態 | ステートレス設計、セッションレベルキャッシュ |
| ツール検出 | 遅延マニフェスト - ツールは宣言済みだが未ロード |
| 資格情報スコープ | 制限付きの環境継承 |
これらは解決可能な問題です。フォークアーキテクチャはすでにそのほとんどを処理しています。
ビジョン：Claude Codeをユニバーサルワークオーケストレーターに
この提案は単にトークンを節約することだけではありません。Claude Codeが真になり得るものを解放することです。
今日、Claude Codeは強力なコーディングアシスタントです。オンデマンドMCPローディングにより、それはより野心的なものに変わります：デジタルワークライフ全体のユニバーサルオーケストレーター。
アーキテクチャのピースはすでに揃っています：
context: forkが隔離を提供- Agent/Skill frontmatterが宣言を提供
- MCPエコシステムが統合を提供
足りないのは接続です：エージェントとスキルが自身のMCPを宣言し、オンデマンドでロードできるようにすること。
これは自然な次のステップです。問題はこれが起こるかどうかではなく、いつ、どのように起こるかです。
この提案は、Claude Codeのアーキテクチャの可能性を探求する継続的な取り組みの一環としてclaude-world.comで公開されています。