MCP公式ロードマップ2026-08-22更新、5つの優先領域を解説

Model Context Protocol（MCP）の公式ロードマップが2026年8月22日に更新された。公開元は modelcontextprotocol.io で、内容はCore Maintainersが見込む今後6〜12ヶ月の5つの優先領域と、そこに紐づく主要な仕様強化提案（SEP: Specification Enhancement Proposal）の一覧である。ロードマップ自体が明記している通り、これは「確約（firm commitments）」ではなく「現時点での考え方（current thinking）」を示したものにすぎない。とはいえ、優先領域に該当するSEPは審査で優先され採択されやすくなる一方、領域外のSEPは自動却下こそされないものの待ち行列が長くなり正当化のハードルが上がる、という運用ルールが明言されている。MCPサーバー・クライアントを実装している開発者や、AIエージェント基盤の技術選定を進めているチームにとっては、今後どの機能が仕様に入りやすく、どこに設計上の変更が来る可能性があるかを見積もる材料になる。本稿では5つの優先領域を順に整理する。

MCPの仕様変更はSEP（Specification Enhancement Proposal）という提案の形で進む。ロードマップは「今期どの領域のSEPが優先的にレビューされるか」を示すものであり、個々のWorking Group（作業部会）やInterest Group（関心グループ）がその領域を実際に担当する。Working Groupの支持を得たSEPが最も速く前進するとされており、優先領域に含まれていても個別のSEPが必ず採択されるとは限らない。逆に優先領域外のSEPが提案できないわけでもない。以下で扱う5領域は、あくまで「Core Maintainersが今期リソースを重点的に割く方向性」として読むのが正確だ。

エージェント的なワークロードは、単純なリクエスト/レスポンスでは表現しきれない。数分かかる処理、サーバー側からのプッシュ通知、ストリーミングで返ってくる結果、処理の途中でクライアントが方向づけ（操舵）を行うパターンなどが必要になる。現状のMCPには、こうした「サーバーがまだ終わっていない」という状態への答えがTasks・subscriptions/listen・progress notificationsという3つの概念に分かれて存在しており、それぞれが複数のWorking Groupにまたがっている。ライフサイクルの管理方法、キャンセルの扱い、エラーの表現方法が統一されていない点がリスクとして挙げられている。今期はTriggers & Events Working Groupによるserver-initiated events（webhookを含むプッシュ配信のためのチャネルとサブスクリプション。クライアント側の高コストなポーリングを減らす狙い）と、Agents・Transports・Triggers & Eventsの各Working Groupが合同で行うcomposition review（Tasksなど作りかけのprimitive同士が具体的なユースケースにおいてきれいに合成できるかの確認）が中心になる。SEP-2663として進んでいるTasksの作業も継続し、最終的にはコアプロトコルへの統合を目指す方向性が示されている。

2026年7月28日リリースの仕様変更で、リモートMCPサーバーは実質的に通常のHTTPワークロードとして扱われるようになった。その結果、ヘッダーやステータスコードでトランスポート関連の情報を運ぶ度合いが増え、HTTPネイティブな機能を追加するたびにstdio専用の設計を別途用意する必要が生じている。SDK側も2本のトランスポートパイプラインを保守しなければならず、プロトコルのメタデータがHTTPヘッダーとメッセージフィールドの双方に二重化してしまい、サーバー実装者はクロス検証を強いられる状況だという。今期の柱は、Transports Working Groupが進めるHTTP over stdioである。Streamable HTTPを唯一のバインディングとし、ローカルサーバーではそれをstdin/stdout上で話す構成にする案で、HTTP/2 over stdioを使えばサブプロセスのセキュリティ・ライフサイクル保証を保ったまま多重化されたHTTPトランスポートを得られると見込んでいる。これが実現すると、stdioとHTTPで別々に設計してきた機能を1つのモデルに統一できる。もう一つの柱はCachingで、直近のリビジョン（SEP-2549）でlist結果とresource readにttlMsとcacheScopeが追加された経緯を踏まえ、これをETagへ拡張し、tool callを含むprimitiveの結果をバージョニングできるようにする方向で検討されている。加えて、全サーフェスにまたがる標準化されたエラーハンドリング、SEP-2575（stateless MCP）後を見据えたtool listに対するcapability scoping、サーバーへの安全な設定オプション提供も議題に挙がっている。MCP 2026-07-28版仕様とステートレス移行で扱ったステートレス化の流れの延長線上にある領域といえる。

MCPの認可モデルは、これまで「同意の瞬間にブラウザの前に人間がいる」ことを前提に設計されてきた。しかし実際の呼び出し元は次第にエージェントへと移っている。独自のIDを持つクラウドワークロード、その場にいないユーザーの代理として動くエージェント、親エージェントより狭い権限で起動されるべきサブエージェント——こうしたケースに既存のモデルはうまく対応できない。既存のMCPサーバーの多くは、貼り付け式のAPIキーや長命のリフレッシュトークンに依存しているのが実情だ。今期発足予定のAgent Identity Working Groupが取り組むのは、まずDPoP（Demonstrating Proof of Possession、トークンの所持を暗号学的に証明する仕組みで、盗まれたトークンの使い回しを防ぐことを狙う）の仕様確定と普及である。もう一つはagent identityとdelegation（委任）で、エージェント自身のIDまたはユーザーが委任したIDでMCPサーバーに到達する方法を定める。具体的にはWorkload Identity Federation（SEP-1933）、Enterprise-Managed Authorizationで使われるIdentity Assertion JWT Authorization Grant（ID-JAG）、RFC 8693のトークン交換に軸足を置き、IETFのOAuth WGおよびWIMSE WGと協調して進める方針が示されている。対話型クライアントとヘッドレスエージェントを区別するhuman-presence attestation（人間がその場にいることの証明）なども議論の俎上にあるが、まだ確定した仕様ではない。

tools/callは現状、contentとstructuredContentを同時に返せてしまう仕様になっており、これがサーバー実装者・クライアント実装者の双方を混乱させ、実装の分岐を生んできたとロードマップは指摘する。また「大量のツールやリソースをクライアントにどう案内するかの手段が足りない」という声も繰り返し届いているという。今期発足予定のCore Primitives Working Groupは、まずtool result shapeとしてtools/callインターフェースを再設計し、戻り値型の忠実度の差を解消して構造化・非構造化出力の扱いを整理する。次にprogressive discoveryとして、クライアントがサーバーのツール・リソースを最初に全カタログとして読み込むのではなく、必要に応じて段階的に学習できる仕組みを検討する。これは前述のCaching作業と相互作用する見込みだ。さらにprimitive annotationsとして、content annotations（コンテンツの想定利用者と優先度を宣言する仕組み）をtool結果やresourceにも適用することでSEP-2200が指摘する可視性の混乱を解消できないか検討する。ただしこの仕組みは多くの実装者に採用されておらず、目的も十分に知られていないため、有用性が確認できなければ廃止も選択肢に入っているとロードマップは明記している。このほかFile Uploads Working Groupが、範囲読み込み（range reads）や階層リストといったスコープ付きファイル操作とファイルシステム的なリソースセマンティクスの検討を継続する。

SDK・リファレンスサーバー・クイックスタートは現状、手作業で保守されている。ロードマップは、仕様と人間がレビューするコンフォーマンステストスイートを信頼できる情報源とし、これらの成果物をリリースのたびに再生成・再検証する（リリース後に不具合を直すのではなく）方向を目指すとしている。今期はSDK Working GroupとCore Maintainersがthe extension contract（拡張の契約）に取り組む。拡張がhost・client・server・agentのどのロールに紐づくのか、capability宣言時に各ロールが何をするのか、SDKがネイティブに対応すべき範囲、拡張のパッケージング方法、capability追加を拡張のバージョン付き変更として扱うこと、認可（auth）を独立した領域として扱うこと——といった論点を整理する。もう一つがthe generated-artifacts experimentで、仕様からTier 1 SDK候補と付随するクイックスタート例を生成し、コンフォーマンステストスイートで検証したうえで、どの層を決定的なコード生成に任せ、どの層をモデル支援にするかの推奨を次サイクルへ向けて公開するという実験的な取り組みだ。あわせて、リファレンスサーバーやクイックスタートリポジトリの所有と鮮度の期待値を見直し、生成に失敗した箇所が明らかにした仕様の不明瞭さをドキュメントのバグとして扱う方針も示されている。Claude Code の MCP 連携ガイドのようなクイックスタート系ドキュメントの精度にも関わってくる領域だ。

- ロードマップは確約ではなく見通しであることを前提に、今から大規模な作り直しに着手しない
- 長時間かかる処理やサーバー起点の通知を自前で無理に実装している場合は、Server-initiated eventsやTasksの動向を継続的に確認する
- stdioとHTTPのトランスポートを別々に保守しているSDK・実装があれば、HTTP over stdioの仕様確定後に統合できるよう設計を疎結合に保つ
- APIキーの貼り付けや長命リフレッシュトークンに依存した認可実装は、DPoPやagent identity/delegationの仕様化を見据えて棚卸ししておく
- tools/callでcontentとstructuredContentを両方返している実装は、tool result shapeの再設計対象になりうる点を把握しておく
- SEPの起票・コメントやWorking Group参加、SEP-2133に基づくexperimental-ext-リポジトリでの実験的拡張など、公式の参加経路を確認しておく

詳細な議論の経緯やSEPごとの進捗は公式ロードマップ（https://modelcontextprotocol.io/development/roadmap ）で随時更新される見込みだ。エージェント基盤の権限設計を検討している場合はAgent Plugins 1.0 標準もあわせて参照するとよい。