MCPの2026年ロードマップ — 次の半年で優先される5領域
MCP公式ロードマップ(2026-08-22更新)が定める次期仕様の優先領域5つと、SEP審査への影響、既に動き始めている変更点をまとめます。
MCPロードマップとは何か
MCPロードマップは、Core Maintainers(仕様の中核メンテナー)が今後6〜12か月で優先する開発領域をまとめた公式ページです。2026-08-22更新の版では、優先領域を5つに絞っています。確定したコミットメントではなく、Specification Enhancement Proposals(SEP、仕様変更提案)の審査優先度を決めるための指針という位置づけです。
ページ自身も「現時点の考え」と断っています。優先順位は変わりうるうえ、書かれた項目が別の形で届いたり先送りされたりします。逆に、載っていない作業が次のリリースに入ることもあります。
領域の内側のSEPは審査が早く、採択の見込みも高くなります。外側のSEPが自動で却下されるわけではありませんが、順番待ちが長くなり、提案を正当化するハードルも上がります。各領域には担当のCore Maintainersが明記されていて、Discordから連絡できます。領域ごとに挙げられた項目が今期の成果物で、残りはWorking Group(作業部会、WG)が埋めていく余白です。
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自動生成の実験 |
前回の仕様改訂(2026-07-28)は、セッションID・初期化ハンドシェイク・ping・SSEの再送機能を取り除く改訂でした。5領域のうち、メッセージングとトランスポートの2つは、その改訂で入れた仕組みの続きにあたります。認可とSDKは別の軸から始まる作業です。
エージェント間メッセージング
出発点は、サーバーがまだ終わっていないことを表す3つの仕組みが、別々のWGから生まれたことです。2026-07-28の仕様では、次のように分かれています。
subscriptions/listen: クライアントが選んだ変更通知(ツール一覧の変更など)を、1本の長いPOSTレスポンスのストリームで受け取る- 進捗通知:
notifications/progressは、関係するリクエストのレスポンスストリームに乗る - Tasks拡張: 完了の確認は
tasks/getのポーリングで行い、クライアントからの追加入力はtasks/updateで渡す
ライフサイクルもキャンセルの扱いもエラーの出し方も揃っていません。この半年は個別の仕様を足すより、3つを組み合わせても破綻しないかを見る構成レビューが優先されます。レビューを担うのはAgents・Transports・Triggers & Eventsの3つのWGです。
もう1本の柱が、Triggers & Events WGの「サーバー主導イベント」です。同WGのチャーターは、現状のクライアントがポーリングかSSE接続の保持で更新を知っていると書き、Webhookのようなコールバックの標準化を使命に掲げています。成功基準は、採択されたSEPに加え、Tier 1 SDK 2つ以上での参照実装と適合性テストです。Tasksの完了通知もこのWGの持ち分で、ロードマップは「高コストなクライアント側ポーリングだけに頼らずに済む」拡張を求めています。
Agents WGの側は、Tasksをコアに取り込む安定化に加え、エージェントを裏側に持つMCPサーバーの使い方を見直します。チャーターでは、Tasksを発展させる・Agents Extensionを新設する・既存のプリミティブの使い方を文書化する、の3通りが並んでいます。どれを選ぶかは設計作業の結論待ちです。
HTTP-Nativeトランスポートの統合
2026-07-28のリビジョンで、リモートMCPサーバーは普通のHTTPワークロードになりました。POSTリクエストには Mcp-Method と Mcp-Name のヘッダーが必須になり、メッセージ本体にも同じ情報が入ります。サーバーは両者を突き合わせる必要があり、食い違いを示す HeaderMismatch のエラーも定義されています。ロードマップが「プロトコルメタデータの重複」と呼んでいるのはこの状態です。
トランスポートの現状と目指す形
いまの構成
リモートはHTTP、ローカルはstdioで、HTTP頼みの機能にはstdio用の別設計が要ります。SDKは2本のトランスポート処理を抱え、ヘッダーと本体の二重情報を検証します。
目指す構成
Streamable HTTPを唯一のバインディングにし、ローカルサーバーにはstdin/stdout上でそれを話させます。ロードマップは、サブプロセスの安全性とライフサイクルを保ったままHTTP/2で多重化できる、という見通しを示しています。
キャッシュは、2026-07-28で ttlMs(鮮度の目安、ミリ秒)と cacheScope(public か private)が一覧結果と resources/read の必須フィールドになりました。次の段階がETag対応で、ツール呼び出しを含むプリミティブの結果にバージョンを持たせる狙いです。同じリビジョンでは、tools/list を決まった順序で返すことも推奨されました。クライアント側のキャッシュと、LLMのプロンプトキャッシュの命中率のためです。
統合の先には、全面的なエラー処理の標準化、SEP-2575(ステートレス化)後のツール一覧の能力スコープ、サーバー設定を安全に渡す仕組みが控えています。同じリビジョンでHTTP+SSEは正式に非推奨へ移され、その経緯はMCPのHTTP+SSEが正式に非推奨ににまとめています。
エージェントIDとエンタープライズ認証
MCPの認可は、同意の場面にブラウザを持つ人間がいる前提で作られています。実際の呼び出し元は、本人が不在のまま動くクラウドのワークロードや、親より狭い権限で動くサブエージェントに広がりました。既存のMCPサーバーはAPIキーの貼り付けや長寿命のリフレッシュトークンに頼りがちです。
今期の項目は2つです。
- DPoP(Demonstrating Proof of Possession、鍵の所持を証明する仕組み): 仕様の確定と普及。Agent Identity WGが担当します
- エージェントの身元と委任: Workload Identity Federation(SEP-1933)、Identity Assertion JWT Authorization Grant(ID-JAG)、RFC 8693のトークン交換を使い、IETFのOAuth・WIMSEの両ワーキンググループと歩調を合わせます
ID-JAGは、すでに拡張として存在するEnterprise-Managed Authorizationが使っている仕組みです。クライアントが企業のIdP(Okta、Azure ADなど)からID-JAGを受け取り、それをMCPサーバー側の認可サーバーでアクセストークンに交換します。従業員が1サーバーずつ許可する手間をなくし、アクセス可否をIdPの側で決める流れです。仕組みの詳細はMCPのEnterprise Authorization拡張にあります。
WGの発足に伴って範囲に加わりうる話題として、対話中のクライアントとヘッドレスなエージェントを見分ける「人間の在席証明(human-presence attestation)」も挙がっています。
Claude CodeなどからリモートMCPサーバーへつなぐ際の現行の認可は、リモートMCPのOAuth認証の仕組みにまとめています。2026-07-28のリビジョンでも、認可応答の iss パラメーターの検証(RFC 9207)、Dynamic Client Registrationでの application_type の指定、クライアント認証情報の発行元への紐づけが加わりました。Dynamic Client Registration自体は、Client ID Metadata Documentsへの置き換えを前提に非推奨になっています。
プリミティブの改善
tools/call が content と structuredContent を同時に返せる仕様は、サーバーとクライアントの実装者を混乱させ、解釈の割れた実装を生みました。Core Primitives WG(新設中)がこのインターフェースを再設計し、構造化出力と非構造化出力の扱いを揃えます。
あわせて、大量のツールやリソースを最初に全部読み込ませず、必要になった時点で学ばせる段階的発見(progressive discovery)の実験が始まります。キャッシュの仕組みとどう噛み合わせるかも、成果物の一部として定義される予定です。
もう1つの項目が、コンテンツの対象読者と優先度を示す「プリミティブ注釈」です。ツール結果やリソースへ適用すれば、SEP-2200が挙げた可視性の混乱を解けるかもしれません。ただ、実装者の多くは注釈を採用しておらず、目的も十分に知られていない可能性があります。役に立たなければ廃止も検討する、と明記されています。
領域の外では、File Uploads WGが範囲指定の読み取りや階層的な一覧といった、ファイルシステム風のリソース操作を進めています。
SDK開発体験の改善
公式SDK・リファレンスサーバー・クイックスタートは手作業で保守されています。ロードマップが目指すのは、仕様と人手でレビューした適合性テストスイート(Conformance Test Suite)を正本にして、これらの成果物を派生させることです。リリースのたびに生成し直して再検証する形にして、後から手直しする運用を変えます。
今期の項目は2つあります。
- 拡張の契約: 拡張がホスト・クライアント・サーバー・エージェントのどの役割に結びつくか、能力を宣言したときに各役割が何をするか、SDKが標準で持つべき範囲、拡張のパッケージ方法を決める
- 自動生成の実験: 仕様からTier 1 SDKの候補とクイックスタートを生成して適合性テストで検証し、次のサイクルへの提言を公開する。どの層を決定的なコード生成に任せ、どの層をモデル支援に任せるかも成果に含める
Tier 1 SDKは、適合性テストの100%合格、新しいプロトコル機能のリリース前の対応、Issueへの2営業日以内の一次対応などを満たすSDKです。TasksやMCP Appsのような拡張は、どの階層でも必須ではありません。生成で失敗した箇所を仕様の不明瞭さの表れとして、文書のバグ扱いにする方針も書かれています。仕様の改訂が確定するまでの手順はMCP仕様の改訂ライフサイクルで扱っています。
すでに入った変更と、これから決まる変更の境界
ロードマップは「これから」の話ですが、土台の一部は2026-07-28の改訂で入っています。読み分けの目安は次のとおりです。
どこまでが確定済みか
2026-07-28で入った
ステートレス化(SEP-2575)とセッションIDの廃止(SEP-2567)、
subscriptions/listen、ttlMsとcacheScope(SEP-2549)、Tasksの拡張機能化(SEP-2663)、複数往復リクエスト(MRTR)。今期の検討事項
tools/callの結果形式、段階的発見、プリミティブ注釈の存廃、ETag対応、stdio上のHTTP/2、DPoPの確定、拡張の契約。発足待ちのWG
Agent Identity WGとCore Primitives WGは、ロードマップ期間中に発足する予定のWGです。担当項目(DPoPの確定、
tools/callの結果形式の再設計など)はこれから進みます。
Tasksがコア仕様ではなく拡張として先行した経緯はMCP Tasksが拡張機能に移った理由に、ステートレス化の影響はMCPのセッションID廃止の理由にあります。
SEP審査の優先枠に乗るまでの道筋
SEPは仕様の追加・破壊的変更・運営ルールの変更・論争になりそうな話題のためのもので、バグ修正・誤字・例の追加・挙動を変えない軽微なスキーマ修正は通常のPull Requestで足ります。SEP全体の流れはMCPのSEPプロセスの全体像で扱っています。ここでは、ロードマップの優先枠を狙う場合の順序だけを並べます。
優先領域の中でSEPを通す流れ
- 1
領域を決める
提案が5領域のどれに当たるかを先に特定します。当たらなければ、審査の列は長くなります。
- 2
WGで議論する
該当するWGやInterest GroupとDiscordで話し、その議論へのリンク(スレッド・会議メモ・GitHub Discussions)を用意します。リンクのないSEPは受理されません。
- 3
Pull Requestを出す
seps/ディレクトリにSEPのファイルを追加し、PR番号でファイル名を付け替えます。 - 4
スポンサーを見つける
関係するCore MaintainerかMaintainerを1〜2人タグします。2週間反応がなければ
#generalで聞きます。6か月見つからないとdormant(休眠)になりますが、却下ではなく、後から復活できます。 - 5
Core Maintainersが審査する
スポンサーが
in-reviewにすると、隔週のCore Maintainers会議で採択・却下・差し戻しが決まります。 - 6
参照実装まで終えて確定する
採択後に参照実装と適合性テストを仕上げ、
finalになります。SDKでの実装はfinalの条件ではありません。
WGの後ろ盾があり、ロードマップとの接点が明確なSEPほど早く進む、とロードマップは書いています。正式なSEPの前に試したい場合は、SEP-2133の experimental-ext- リポジトリで拡張を実験する道もあります。
自作MCPサーバーに関係する領域の見分け方
ロードマップの5領域は、運用中のサーバーの状況ごとに関係の濃さが違います。
| サーバーの状況 | 関係する領域 | 関連する動き |
|---|---|---|
| stdioとHTTPの両方を実装している | 関係する領域HTTP-Nativeトランスポート | 関連する動き一本化の方向。SDKが2系統を持つ状態の解消が狙い |
| APIキーや長寿命トークンで認可している | 関係する領域エージェントID | 関連する動きDPoPとID-JAGが検討の中心 |
| 数百のツールを一括で返している | 関係する領域プリミティブ | 関連する動き段階的発見の実験と ttlMs の活用 |
| 長時間処理をTasksで返している | 関係する領域メッセージング | 関連する動きWebhook型の完了通知がTriggers & Events WGで検討中 |
| Roots・Sampling・Loggingを使っている | 関係する領域ロードマップの外 | 関連する動き2026-07-28で非推奨に |
最後の行は、ロードマップの項目ではなく決定済みの話です。Roots・Sampling・Loggingは新規実装を勧めない状態に入り、移行先は、ディレクトリをツール引数やリソースURIで渡す、LLMプロバイダーのAPIを直接使う、stderrかOpenTelemetryにログを出す、です。非推奨の期間は最低12か月と定められています。詳しくはMCP Samplingが非推奨にとMCPの非推奨機能一覧にあります。
拡張を使う設計では、MCP拡張機能のサポートマトリクスのように、クライアント側の対応状況の把握が先に必要です。ロードマップの「拡張の契約」は、この対応の揃え方そのものを扱う項目です。
まとめ
優先5領域はいずれも「SEPの列に並ぶ順番」を決める指針で、仕様の約束ではありません。自作サーバーを持つ人は、トランスポートと認可の2領域の進み方を、SEPを書く人は、提案がどの領域とWGに結びつくかを先に見ておくと動きやすくなります。