8月22日、Model Context Protocol公式ブログがDavid Soria Parra（リードメンテナー）とDen Delimarsky（リードメンテナー）の連名で「The New MCP Roadmap」と題した記事を公開した。MCPの次期仕様リリースに向けた5つの優先領域と今後の開発方針が詳しく示されている。
MCP（Model Context Protocol）は、AIモデルが外部のツールやデータソースに接続する際の共通インターフェースを定めたオープンプロトコルで、2024年末にAnthropicが公開した。Claude、Cursor、各種AIエージェントフレームワークが相次いで採用しており、現在はAIエージェントとツールを接続する事実上の標準として機能している。今回のロードマップはコアメンテナーとコミュニティのワーキンググループが共同で策定したもので、公式な方向性を示す一次情報として重要度が高い。
設定された5つの優先領域は以下の通りだ。重要度順に列挙されており、最初の2つがアーキテクチャ上の影響が最も大きい。
- エージェントアイデンティティとエンタープライズ対応セキュリティ
- エージェンティックメッセージングプリミティブ
- HTTPネイティブトランスポートの統一
- プリミティブ（基本構成要素）の改善（ツール呼び出しとプログレッシブディスカバリー）
- SDK開発者体験の向上
認証の根本的な再設計 — ブラウザ不在のエージェントに対応できない現状
アーキテクチャ上の影響が最も大きいのが、「エージェントアイデンティティとエンタープライズ対応セキュリティ」だ。
現在のMCP認可はブラウザ上でユーザーがアクセスを承認する仕組みを前提としている。しかし実際のユースケースはすでにその前提を超えている。クラウドワークロードとして動くエージェント、ユーザー不在で代理実行するエージェント、サブエージェントに権限を委譲するエージェント——こうした構成では、ブラウザベースの認可はそもそも機能しない。
解決策として、DPoP（Demonstrating Proof of Possession、RFC 9449）の策定・普及促進と、Workload Identity Federationを通じたエージェントアイデンティティ・委譲の標準パスの定義を進める方針だ。DPoPはトークンの盗用を防ぐためにHTTPリクエストと暗号鍵を紐付けるIETF標準で、エージェントのような非対話型クライアントに特に有効とされている。APIキーのベタ書きや長期トークンに頼らない設計を、既存の標準仕様の上に構築するアプローチである。IETFのOAuthワーキンググループやWIMSE（Workload Identity in Multi System Environments）との連携も継続し、エージェントアイデンティティに必要なビルディングブロックを標準レベルで整備していく。
エージェンティックメッセージングプリミティブ — 長時間タスクへの対応
「プリミティブ（primitive）」とはプロトコルが提供する基本操作・メッセージ単位のことで、MCPの文脈ではツール呼び出しやリソース取得などの基本構成要素を指す。
従来のリクエスト／レスポンス型では対応できない長時間ループや中断・操作のニーズに対応するため、サーバー起点イベント（webhookとチャネル）を整備し、クライアントがポーリングしなくて済む構成を目指す。バックグラウンドで数時間動き続けるエージェントが増えている現状では、接続を張り続けるSSEや定期的なポーリングでは帯域・コストの面で限界があり、イベント駆動型への移行は実用上の必須課題となっている。すでに実験的に導入されているTasks拡張（SEP-2663）を正式仕様に昇格させることも目標に含まれる。
HTTPネイティブトランスポートの統一
2026-07-28リリースでリモートMCPサーバーは通常のHTTPワークロードと同等になった。今後はこのモデルをstdioベースのローカルサーバーにもStreamable HTTPで対応させることで、トランスポートを一本化し、クライアント／サーバー実装をさらに簡素化する。stdioとHTTPの二系統が混在する現状は、実装者にとって動作確認コストが倍増する要因になっており、この統一はエコシステム全体の実装品質向上につながる。
プリミティブの改善 — ツール呼び出しとプログレッシブディスカバリー
tools/callのレスポンスは現在、同じ出力を複数の形式で返せる仕様になっているが、サーバー開発者はどの形式をクライアントがモデルに渡すかを知る手段がない。これを単一の明確なコントラクトに整理する。
また、ツールが100個あるサーバーに接続した場合、最初の質問の前にすべてのツール定義のトークンを消費してしまう問題も対処対象だ。プログレッシブディスカバリー（段階的なツール提示）の仕組みを導入し、会話の文脈が絞られるにつれてサーバーがカタログを段階的に提示できるようにする。大規模なMCPサーバーを運用するチームからは、この問題がコスト面での実運用障壁になっているという声が出ており、優先領域に含まれた背景がある。
SDK開発者体験の向上
SDKは開発者がMCPと接する主な接点であり、仕様への適合性テストの充実と、ドキュメントの改善に投資する。エージェントがライブラリを直接参照してMCPサーバーを実装するケースが増えており、APIの明確さとドキュメントの正確さが実装品質を直接左右する。
SEPへの影響
Specification Enhancement Proposals（SEPs）は仕様改善を提案する公式プロセスで、上記5つの優先領域に該当するものが優先レビューされる。領域外の提案が自動却下されるわけではないが、メンテナーのレビュー時間はロードマップが優先される。SEPを検討中の場合は、対応するワーキンググループを通じて提案を成形し、Discordでコアメンテナーにコンタクトすることが推奨されている。
詳細はThe New MCP Roadmapを参照していただきたい。
