MCP 2026 ロードマップまとめ — Linux Foundation化したAIツール標準プロトコルの進化
MCP（Model Context Protocol） は、AIモデルとツール／データソースをつなぐためのオープン標準で、Claude / Cursor / Windsurf / Zed などの主要AI製品がネイティブ対応しています。2026年現在、コミュニティMCPサーバーは 200+ 公開されており、AIインテグレーションの 事実上の標準 になりつつあります。
2025年に Linux Foundation 配下のプロジェクトとなった MCP は、2026年に体制を組み替え、「日付ベースのリリース計画」から「Working Group ベースの開発」 へ進化しました。この記事では、2026 ロードマップの重点と、開発者として何をウォッチすればよいかを整理します。
MCP の基本
| 項目 | 内容 |
|---|---|
| 仕様の最新版 | 2025-11-25（2025年11月公開） |
| ガバナンス | Linux Foundation 配下のプロジェクト |
| メッセージ形式 | JSON-RPC 2.0 |
| プリミティブ | Resources（データ）／ Tools（関数）／ Prompts（テンプレ） |
| サーバー数 | 200+ コミュニティ実装（2026年3月時点） |
| 主な対応クライアント | Claude / Cursor / Windsurf / Zed ほか |
「AIモデルが、外部のツール・データに 統一された方法でアクセスできる ようにする」という発想で、各AI製品ごとに違っていた接続方式を共通化するのが狙いです。
なぜ標準化が重要なのか
LLM単体ではできることが限られます。実際のサービスでは、
- データベースを参照
- GitHub / Slack / Notion を操作
- Web ブラウザを動かす
- ファイルシステムを読み書き
といった連携が前提になります。各AIアプリ（Claude / Cursor / Zed など）がそれぞれ独自に統合方式を作ると、ツールベンダー側が N×M の対応 を強いられます。MCP はそこを 1×M に圧縮 する標準で、エコシステム全体の効率を一気に押し上げています。
2026 ロードマップ — 4つの重点領域
1. トランスポートの進化とスケーラビリティ
Streamable HTTP トランスポートを改良し、ステート管理なしで水平スケール できるようにする方向です。サーバー側が状態を持たないため、ロードバランサーで素直にスケールアウトできます。
加えて、.well-known を使ったサーバー能力のディスカバリ が標準化される見込み。ライブ接続を貼らなくてもサーバーの提供能力が分かる仕組みで、運用が大きく楽になります。
2. エージェント間通信（Tasks primitive の強化）
Tasks プリミティブに対して、リトライセマンティクスや有効期限ポリシー が強化されます。プロダクション運用での信頼性向上が狙いです。長時間タスク・非同期タスクを安全に流す設計が、より自然に書けるようになります。
3. セキュリティ・認可
OAuth 2.1 ベースの認可フローが標準化され、スコープ単位でツール呼び出しを許可 するようなきめ細かな制御が可能に。エンタープライズ用途で大きな意味を持ちます。
4. 仕様の安定化と相互運用性
主要クライアント（Claude / Cursor / Windsurf / Zed）と主要サーバーが 同じスペックで噛み合う こと自体が課題で、Working Group 体制によって相互運用性を継続的に検証していく構えです。
クライアント・サーバー側エコシステム
クライアント（AIアプリ）側：
| クライアント | MCP対応 | 補足 |
|---|---|---|
| Claude Desktop / Code | ◎ | Anthropic がMCP発案元 |
| Cursor / Cursor 3 | ◎ | エージェントウィンドウから利用 |
| Windsurf | ◎ | デフォルト統合 |
| Zed | ◎ | エディタネイティブ統合 |
| ChatGPT Desktop（一部） | △ | ベンダー側の動向次第 |
サーバー側（一部のみ）：
| サーバー | 用途 |
|---|---|
| github / git | リポジトリ操作 |
| slack / teams / chatwork | チャット連携 |
| postgres / mysql / sqlite | DB アクセス |
| filesystem | ローカルFS操作 |
| browser-use / playwright | ブラウザ自動化 |
| google-sheets / google-drive | ドキュメント連携 |
公式・コミュニティ合わせて 200を超える サーバーが公開されており、自前で書かなくても "ある" 状態が普通になりつつあります。
クラウド運用 — Streamable HTTP が推奨に
2026年は、クラウドにMCPサーバーをデプロイする際の 推奨トランスポート が Streamable HTTP に集約されつつあります。
理由：
- HTTPで素直に動く ため、ロードバランサー／CDN／WAF と相性が良い
- 長時間ストリーミング が可能で、進捗通知や分割応答に強い
- ステートレスにスケール できる設計に向かっている
stdio モードは依然としてローカル開発向けに有効ですが、本番運用は Streamable HTTP が主流になっていきます。
開発者として何を準備するか
1. MCPクライアント／サーバーのSDK選定
公式SDK（TypeScript / Python ほか）が提供されており、自前ツールをMCPサーバーとして公開する敷居は急速に下がっています。社内ツールをMCPでラップしておくと、Claude / Cursor / Zed どこからでも呼べるようになります。
2. 認可・スコープ設計
OAuth ベースのスコープ設計を、社内のIDP（Okta / Auth0 / Entra ID）と整合する形で先に決めておくと、後から楽です。
3. ロギング／監査
MCP経由のツール呼び出しを 「誰が」「何を」「いつ」呼んだか を記録する基盤を整備。EU AI Act の監査ログ要件にも繋がります。
4. テナント分離・コスト管理
外部ユーザーに開放するMCPサーバーは、テナント単位での分離・レート制限・課金 が前提に。Streamable HTTP の水平スケールが活きるのはこの領域です。
似た領域とのすみ分け
| 標準 | 主な目的 |
|---|---|
| MCP | AIモデル ↔ ツール／データの接続 |
| A2A（Agent-to-Agent） | エージェント同士の対話・協調 |
| OpenAPI / GraphQL | 一般的なAPI仕様 |
| Function Calling（各社独自） | モデル単独でのツール呼び出し |
MCP は 「LLMアプリのツール統合の入口」 という位置で、A2A はその上で エージェント同士の協調 を扱います。両者を併せて使う運用が増えていく見込みです。
まとめ
- MCP は Linux Foundation 配下、200+ サーバー、主要AIアプリがネイティブ対応
- 2026年は Working Group ベース の開発体制に移行
- ロードマップの軸は トランスポート進化／エージェント通信／認可／相互運用性
- クラウド運用の主役は Streamable HTTP に
- 開発者側は SDK選定／認可設計／監査ログ／テナント分離 を整えておくのが吉
エージェント時代のインフラとしてMCPはすでに「当たり前に存在する」存在になりつつあります。社内ツール／業務システムのMCP化は、2026年中に進めておきたい投資です。