MCPの2026年ロードマップ — 次の半年で優先される5領域
MCP公式ロードマップ(2026-08-22更新)が定める次期仕様の優先領域5つと、SEP審査への影響、既に動き始めている変更点をまとめます。
MCPロードマップとは何か
MCPロードマップは、Core Maintainers(仕様の中核メンテナー)が今後6〜12か月で優先する開発領域をまとめた公式ページです。2026-08-22時点の最新版では、優先領域を5つに絞り込んでいます。確定したコミットメントではなく、Specification Enhancement Proposals(SEP、仕様変更提案)の審査優先度を決めるための指針という位置づけです。
ページ自体もそう明記しています。ロードマップに載らない提案が却下されるわけではありませんが、審査の順番は後回しになります。SEPを書く前にこのロードマップの5領域のどれに当たるかを確認し、担当のWorking Group(作業部会)に相談してから提出するのが公式の推奨フローです。
5つの優先領域で何が変わろうとしているか
| 優先領域 | 担当WG | 中心テーマ |
|---|---|---|
| エージェント間メッセージング | 担当WGTriggers & Events / Agents | 中心テーマサーバー主導イベント・Tasksとの整合 |
| HTTP-Nativeトランスポートの統合 | 担当WGTransports | 中心テーマstdio上のHTTP/2化・キャッシュのETag対応 |
| エージェントIDとエンタープライズ認証 | 担当WGAgent Identity(新設中) | 中心テーマDPoP・Workload Identity Federation |
| プリミティブの改善 | 担当WGCore Primitives(新設中) | 中心テーマtools/callの結果形式・段階的発見 |
| SDK開発体験の改善 | 担当WGSDK | 中心テーマ仕様からのSDK自動生成の実験 |
エージェント間メッセージングは、Tasks・subscriptions/listen・進捗通知という「サーバーがまだ終わっていない」を表す3つの仕組みが別々のWGから生まれたことへの反省が出発点です。ライフサイクルもキャンセルの扱いもエラーの出し方も揃っていないため、この半年は個別の仕様を足すのではなく、3つを組み合わせたときに破綻しないかの構成レビューが優先されます。あわせて、Triggers & Events WGが「サーバー主導イベント」を担当し、Webhookを含むチャネル・購読の仕組みを整備します。非同期のワークロードをTasksや他のイベントで扱うようになるほど、サーバーがクライアントへ完了を通知する手段がクライアント側の高コストなポーリングに頼らずに済むようにする、という狙いです。
プリミティブの改善領域では、tools/callがcontentとstructuredContentを同時に返せる仕様がサーバー・クライアントの実装者を混乱させ、実装ごとに解釈が割れてきた点への反省があります。この半年はCore Primitives WG(新設中)がtools/callのインターフェースを再設計し、構造化・非構造化出力の扱いを整理する計画です。加えて、大量のツール・リソースを一括で読み込ませず必要になった時点で発見させる「段階的発見(progressive discovery)」の実験的な仕組みの検討も始まります。コンテンツの対象読者・優先度を示す「プリミティブ注釈」については、実装者の採用が進んでいない現状を踏まえ、有用でなければ廃止も選択肢に入れると明記されている点も見逃せません。
HTTP-Nativeトランスポートの統合は、2026-07-28のリビジョンでリモートMCPサーバーが普通のHTTPワークロードになったことの延長線です。ローカル用のstdioとリモート用のHTTPで別々の設計をSDKごとに二重メンテナンスしている状態を解消するため、stdio上でもHTTP/2を話せるようにする案が検討されています。プロトコルメタデータがHTTPヘッダーとメッセージ本体の両方に重複している問題も、この統合で解消を狙う対象です。すでに非推奨化が進んでいるHTTP+SSEトランスポートの経緯はMCPのHTTP+SSEが正式に非推奨ににまとめています。
エージェントID・DPoPが優先領域に入った背景
MCPの認可設計はもともと「ブラウザを持つ人間が同意する」前提で作られています。しかし呼び出し元が人間ではなくエージェントになる場面が増え、既存のMCPサーバーはAPIキーの貼り付けや長寿命のリフレッシュトークンに頼りがちです。この半年は、DPoP(Demonstrating Proof of Possession、鍵の所持を証明する仕組み)の仕様確定と普及、およびRFC 8693のトークン交換を使ったエージェント委任の仕組み作りが中心テーマです。IETFのOAuth・WIMSE(Workload Identity in Multi System Environments)ワーキンググループとも歩調を合わせて進みます。
Claude CodeでリモートMCPサーバーに接続する際のOAuth周りの実装は、この認可設計の変化を追いかける形で今後も更新が続く見込みです。現行の仕組みはリモートMCPのOAuth認証の仕組みにまとめています。
SEP審査で何が優先され、何が後回しになるか
SEPは誰でも提出できますが、レビュー時間はCore Maintainersにとって希少資源です。ロードマップの5領域内であれば審査が早く進み、採択される可能性も高くなります。領域外のSEPが自動的に却下されるわけではないものの、キューは長くなり、正当化のハードルも上がります。
公式が推奨する進め方は次の順です。
- 提案がどの優先領域に属するかを特定する
- 該当するWorking Groupに提案を持ち込み、支持を得る
- WGの支持と本ロードマップへの明確な接続を示してSEPを提出する
WGの後ろ盾があり、ロードマップとの結びつきが明確なSEPほど審査が速い、と公式ページは明言しています。個人開発者が単独でSEPを書くより、既存のWGディスカッション(Discordで参加可能)に先に加わるほうが現実的な入り口です。
既にリリース済みの部分と、まだ検討中の部分の境界
ロードマップは「これから」の話ですが、一部はすでに前回の仕様改訂(2026-07-28)で土台が入っています。どこまでが確定済みかは混同しやすい部分です。
- すでに入った変更: セッションレスなステートレス化(SEP-2575)、リスト結果への
ttlMs/cacheScope(SEP-2549、キャッシュ機能の一部)、Tasksの拡張機能化(SEP-2663、コア統合はまだ) - これから検討される変更:
tools/callのcontent/structuredContent併存問題の整理、サーバーの全ツールを一括取得しない段階的発見(progressive discovery)、プリミティブへのアノテーション適用の是非 - 形成中のWG: Agent Identity WGとCore Primitives WGはこのロードマップ期間中に正式発足する予定で、現時点ではまだ確定した仕様がない
Tasksがコア仕様ではなく拡張機能として先行実装された経緯はMCP Tasksが拡張機能に移った理由で扱っています。ステートレス化がクライアント・サーバーの実装に与える影響はMCPのセッションID廃止の理由が詳しいので、ロードマップの背景を掴むにはあわせて読むと理解が早まります。
SDKの自動生成実験は何を狙っているか
SDK開発体験の改善領域でひときわ具体的なのが、「仕様からSDKとサンプルを自動生成する」実験です。現状、公式SDK・リファレンスサーバー・クイックスタートは手作業でメンテナンスされており、仕様が変わるたびに手直しが発生します。ロードマップ期間中に、Tier 1 SDK(公式最優先サポート対象)の候補版を仕様から生成し、Conformance Test Suite(適合性テストスイート)で検証したうえで、次のサイクルへの提言を公開する計画です。仕様そのものの改訂がどんな手順を踏んで確定していくかはMCP仕様の改訂ライフサイクルで扱っています。
どの層を決定的なコード生成に任せ、どの層をモデル支援に任せるかという線引き自体が実験の成果物になる、という書き方をしている点は目を引きます。SDKの品質を人力レビューに依存させない体制づくりへ、Core Maintainers自身が舵を切ろうとしていると見てよいでしょう。
MCPサーバー開発者は今何を見ておくべきか
自作サーバーを運用している開発者にとって実務上の影響が大きいのは、HTTP-Nativeトランスポート統合とエージェントID対応の2つです。stdioとHTTPを両方サポートしているサーバーは、今後トランスポート層の実装が一本化される方向に向かうため、独自の二重実装を抱え込むより公式SDKの更新を待つほうが手戻りが少なくなります。認可まわりも、長寿命トークンに依存した設計は今後DPoP対応への移行コストが発生する前提で設計しておくのが安全です。
MCP Registryへのサーバー公開を計画している場合、バージョニングやパッケージ種別の仕様は今回のロードマップの直接の対象ではありませんが、HTTP-Native統合が進めば公開時の要件が変わる可能性があります。公開前の最新要件確認は継続して必要です。
プリミティブ改善で議論されている段階的発見が実装されると、数百・数千のツールを抱える大規模なMCPホストの起動時間やコンテキスト消費が変わってくる可能性があります。現時点ではまだ実験段階の位置づけなので、今すぐ設計を変える必要はありませんが、大量のツールを一括登録する構成を取っているサーバー運用者は、この項目の進捗を優先的に追っておく価値があります。
まとめ
2026-08-22更新のMCPロードマップは、エージェント間メッセージング・HTTP-Nativeトランスポート・エージェントID/認可・プリミティブ改善・SDK開発体験の5領域を次の6〜12か月の優先事項に据えています。SEPを書く予定がある開発者はこの5領域のどれに当たるかを先に確認し、担当WGとの接続を作ってから提出すると審査が早く進みます。自作MCPサーバーの運用者は、トランスポートの一本化と認可方式の変化という2点を継続的に追う価値があります。ロードマップは公式ページ側でも「確定ではなく現時点の方針」と明記されているため、今後の仕様改訂タイミングで内容が更新されていないかを定期的に確認してください。