Model Context Protocol (MCP) ロードマップの更新

MCPは自律的なエージェント・ワークロードをサポートするために進化しています

Model Context Protocol (MCP) は、単純なリクエスト・レスポンス・パターンから、エージェント・メッセージング、統合された HTTP トランスポート、およびエンタープライズ対応のセキュリティのための包括的なフレームワークへと移行しています。この転換は、MCP を対話的なユーザー主導のセッションから、人間のユーザーが介在しなくても独立して動作できるクラウド・ワークロードとして実行される自律的なエージェントへと進化させることを目的としています。

エージェント・メッセージングのプリミティブ

MCP は、長時間実行されるループ、ストリーミング結果、およびエージェントの作業の中断・制御（mid-flight steering）をサポートするための新しいプリミティブを導入しています。目標は、クライアントが結果をポーリングする形式から、よりダイナミックなインタラクション・モデルへと移行することです。

主な開発内容は以下の通りです：

Server-initiated events: サーバーがクライアントに更新をプッシュできるようにするための webhooks と channels の実装。
Tasks Extension: Tasks extension (SEP-2663) を成熟させ、コア仕様へと移行すること。
Integration: Agents, Transports, および Triggers & Events Working Groups の間で作業を調整し、これらのプリミティブが cohesive に動作することを保証すること。

HTTP-Native Transport の統合

2026-07-28 のリリース以降、MCP サーバーは標準的な HTTP ワークロードとして扱われます。ロードマップは、クライアントとサーバーの両方の開発を簡素化するために、すべてのデプロイメント・モードを単一のトランスポート・メカニズムの下に統合することを目指しています。

この統合には、stdio を介した Streamable HTTP を使用してローカルサーバーをカバーするように HTTP-native なアプローチを拡張することが含まれます。MCP サーバーを標準的な API サービスとして扱うことで、プロトコルは、既存の組織的なインフラストラクチャ上でサーバーをホストおよび運用する際の摩擦を軽減します。

エージェントのアイデンティティとエンタープライズ・セキュリティ

エージェントがどのように識別され、認可されるかを標準化することは、主要な優先事項です。現在のブラウザベースの人間による承認モデルは、自律的なクラウド・エージェントには不十分だからです。

エンタープライズ対応のセキュリティを実現するために、MCP は以下に焦点を当てています：

Proof of Possession: Demonstrating Proof of Possession (DPoP) の最終決定と導入の推進。
Workload Identity Federation: ID-JAG grant および Enterprise-Managed Authorization を通じて、エージェントのアイデンティティと委譲のためのパスを定義すること。
Standards Engagement: IETF OAuth および WIMSE working groups と協力し、基盤となるアイデンティティ標準がエージェント特有のニーズを満たすように進化させること。

コア・プリミティブの洗練

MCP は、ツール・コーリング（tool calling）における制限と、コンテキスト・ウィンドウの肥大化を抑え、モデルの性能を向上させるために、ツール・カタログのスケールに関する問題に対処しています。

Standardized Result Handling: tools/call レスポンスのための明確な契約を確立し、サーバー開発者がクライアントがどのように出力をモデルに提示するかを正確に把握できるようにすること。
Progressive Discovery: サーバーが小さなエントリー・ポイントを提供し、会話が進むにつれてより多くのツールを公開していくシステムを実装することで、モデルが巨大なツール・カタログ（例：100個以上のツールを持つサーバー）によって圧倒されるのを防ぐこと。

SDK 開発者エクスペリエンス

SDK のエルゴノミクス（使いやすさ）と仕様への準拠に投資が向けられています。現在、多くの開発者がエージェントを使用して MCP クライアントやサーバーのコードをコードを記述しているため、ロードマップは、AI 支援開発における摩擦を軽減するために、明確な API と正確なドキュメントを重視しています。

コミュニティの視点と批判

ロードマップは洗練された将来の道筋を示していますが、Hacker News からのコミュニティのフィードバックは、プロトコルの複雑さと必要性に関して、かなりの懐疑的な見方を示しています。

複雑さとオーバーエンジニアリング

いくつかの開発者は、MCP が既存の Web 標準に不必要なver 2.0 へのアップグレードをレイヤーとして追加していると主張しています。

"The degree to which this idea has been overcomplicated is confusing. This could have been solved with some relatively simple patterns wrapped around HTTP and WebSockets..."

他の開発者は、特化されたプロトコルが、ドキュメント・ファイル（例：skills.md）と組み合わされた単純な REST エンドポイントよりも優れているのかどうかを疑問視しています。

安定性と実装

一部のユーザーは、仕様の急速な進化に不論理な不満を感じており、早期採用者が常に実装を書き直さなければならない点に注意しています。

"When specs change, you obviously have to update existing work too... Senior programmers always advised me to only use things that have been around for at least three years."

Progressive Discovery の有用性

ロードマップは progressive discovery を新しい優先事項として掲げていますが、一部の開発者は、プロトコルの現在の制限により、すでに手動でこれを実装する必要があったと述べています。

"Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now..." }],