MCP 2026ロードマップ｜次期仕様SEPの進捗と実装判断
MCP公式ロードマップの5つの優先領域と、Skills・Server Cards・非同期承認・Task操作・監査・引用などのSEP段階を2026-09-25時点で整理。2026-07-28正式仕様やfinal extensionとproposalを分け、今実装するものと待つものを判断できます。
公開 2026.09.25 / 更新 2026.09.25
この記事のポイント
- MCPの現行基準は2026-07-28正式仕様。8月22日公開のroadmapは次期仕様以降の6〜12か月を見据えた方向性で、確定日程や採択保証ではない
- 優先領域はagentic messaging、HTTP-native transport、agent identity、protocol primitives、SDK developer experienceの5つ
- SEP-2663 Tasksはfinal、SEP-2640 Skillsは公式trackerでfinal。どちらもクライアントが自動対応済みという意味ではなく、extensionと実装の対応を個別に確認する
- Server CardsはSEP-2127がin-review。2026-07-28仕様のserver/discoverとは目的と接続タイミングが異なる
- 非同期承認、structured authorization denials、task操作、監査記録、引用などはproposalまたはdraft段階。production dependencyにせず、追跡・検証用に扱う
結論：本番の基準は2026-07-28正式仕様。次期roadmapは確定仕様ではない
MCPの2026-08-22 roadmapは、次の仕様更新とその先に向けた優先領域を示します。公式ページは対象を今後6〜12か月の見通しとし、内容は確定した約束ではなく、優先や提供方法が変わる可能性を明記しています。ロードマップに載った技術名を、今すぐ実装すべきAPIやリリース日として扱うのは避けます。
productionで現在の仕様として扱うのは、正式公開済みの2026-07-28版です。TasksやSkillsのように独立したExtensionとしてfinalになったものは、core仕様へ一律に組み込まれた機能とは分け、サーバー・クライアント・SDKの対応状況とcapability negotiationを確認します。
公式roadmapの5領域と、開発者が今できること
| 優先領域 | 公式roadmapが示す方向 | 今の実装判断 |
|---|---|---|
| Agentic messaging primitives | Tasks、server-initiated events、channelsやsubscriptions、webhookなどを組み合わせ、長時間処理の完了通知や途中操作を整える | finalのTasks Extensionを使う場合も、対応version・cancel・再接続を検証する。新しいevent APIは確定前提にしない |
| HTTP-native transport | Streamable HTTPをstdio上でも扱う方向、ETagなどのcache、共通のerror handlingを検討する | 現行のstdioとStreamable HTTPを運用環境で使い分ける。roadmapだけを根拠にtransportを置き換えない |
| Agent identity / enterprise security | DPoP、Workload Identity Federation、ID-JAG、token exchangeを使ったagent identityとdelegationを進める | 利用可能な現行認証仕様を使う。EMAはstableなExtensionとして、次のagent identity構想と切り分ける |
| Improved primitives | tools/callの結果形式を分かりやすくし、大きなtool catalog向けにprogressive discoveryを進める | 現行のrequest・result contractとserver/discoverを使い、未確定の新result shapeへ依存しない |
| SDK developer experience | 仕様・conformance testを基準にSDKやquickstartを生成・再検証する実験と、Extension contractを整える | SDK tier、対応spec version、conformance結果を選定時に確認する。生成実験を各SDKで利用できる機能とはみなさない |
SEPの段階を確認する：finalでもcore仕様とは限らない
公式trackerのproposal、draft、in-review、finalは、提案・審査の状態を読むための表示です。target releaseやconformance testの欄も合わせて確認します。finalになったExtensionは独立した拡張として確定した状態であり、すべてのMCP hostがその場で対応したことを示しません。
| 機能・SEP | 2026-09-25時点の状態 | 本番での扱い |
|---|---|---|
| 2026-07-28 core仕様 | 正式公開済み。stateless core、server/discover、MRTR、cache hint、認証強化、Extensions frameworkなどを含む | 現行の基準仕様。移行前に対象SDK・client・serverの対応範囲を確認する |
| Tasks Extension / SEP-2663 | final。長時間処理のtask handleや状態取得などを独立Extensionとして定義 | 利用前に双方のExtension対応を確認する。Tasksがfinalでも、次のsteer・pause・resumeまで確定したわけではない |
| Skills Extension / SEP-2640 | 公式SEP trackerではfinal | 利用するhost・server・SDKの対応を確認する。Skillsの内容を読めることと、記載されたscriptやcommandの実行許可は別に設計する |
| Server Cards / SEP-2127 | in-review。接続前のHTTP server discoveryを扱う | server/discoverとは別の機能。正式仕様・相互運用テストが出るまでは依存先にしない |
| Structured Authorization Denials / SEP-2643 | 公式trackerではproposal | 独自のerror fieldを本番共通契約として先取りしない |
| Asynchronous Approval / SEP-2848 | open PRの状態説明はdraft。Tasksとstructured denialを前提にし、SDKのreference implementationとconformanceが未完了 | 承認待ちの本番動作をこの提案だけに依存させない。既存のhost側承認とサーバー認可で境界を作る |
| Task Interaction Methods / SEP-2669 | proposal。steer、pause、resumeを追加する案 | 現行Tasksにメソッドがあると仮定せず、使うclientとserverの正式仕様を確認する |
| Task Streaming Partial Results / SEP-2679 | 元のPRは2026-06-13にclose。TasksがExtension trackへ移るため別に追跡すると記録されている | closeを採択や実装完了と解釈しない。部分結果を必要とする場合は、現行ExtensionやSDKが実際に公開する機能を確認する |
| Tamper-Evident Audit Record / SEP-3004 | 公式trackerではproposal | protocol共通の監査記録契約があるとはみなさず、現状はserver・gateway側で必要な監査を設計する |
| Granular Citations / SEP-3094 | PR本文ではdraft。公式trackerではproposalとして表示 | 引用形式がMCP共通仕様になった前提で保存形式を決めない |
Server Cardsとserver/discoverは、発見するタイミングが違う
2026-07-28仕様のserver/discoverは、MCP接続後にserverの能力情報を取得するための仕組みです。Server CardsのSEP-2127は、HTTP endpointへ接続する前にserverの識別情報や接続情報を発見する提案です。どちらも「discovery」と呼ばれますが、実行時のcapability確認と事前のendpoint discoveryを同じAPIとして扱うと、接続設計や信頼境界を誤ります。
今実装するもの・検証だけにするもの・待つもの
| 扱い | 判断の目安 |
|---|---|
| 本番で使う | 2026-07-28正式仕様と、必要性があるfinal Extension。clientとserver双方のversion、capability negotiation、fallback、conformanceを確認してから段階導入する |
| 検証環境で試す | in-reviewやdraftに関心がある場合は、feature flagのあるPoCに留める。提案versionを固定し、失敗時に現行機能へ戻せるようにする |
| 採用を待つ | proposalやdraftのerror shape、Task操作、非同期承認、監査記録、引用にprotocol依存を作らない。final、対象リリース、SDK実装、conformance testを確認してから再判断する |
| Enterprise authorization | 現行のstable EMA Extensionと、roadmapのDPoP・WIF・delegationを分ける。実際に利用するIdP、resource server、clientの対応仕様で設計する |
- 公式spec versionと、対象のSEP番号・stage・target releaseを記録する
- Extension identifier、version、clientとserverの対応状況を照合する
- proposalを試す場合、productionから切り離し、fallbackとrollback経路を残す
- PRがcloseされた場合は、理由と後続のExtension・SEPがあるかを確認する
- 次の正式リリース後に、SDK tierとconformance testを再確認して移行計画を更新する
MCP次期仕様の予定日は、roadmapだけでは確定できない
2026-08-22のroadmapページは方向性と優先deliverableを示しますが、固定した次回release日や、掲載された全項目の採択を約束していません。スケジュールを決めるときは、draft仕様やSEP trackerのtargetだけを見て実装期限を確定せず、Core Maintainersによる正式なrelease告知と対象SDKの公開を待ちます。
よくある質問
MCPの次の正式仕様はいつ公開されますか？
2026-08-22の公式roadmapは次回リリースの確定日を示していません。正式なrelease告知と仕様versionが公開されるまでは、日付を前提にした本番計画を立てないでください。
SEPがfinalなら、どのMCP clientでも使えますか？
いいえ。Extensionの仕様段階と、個別のhost・client・server・SDKの実装状況は別です。Extension identifier、version、capability negotiation、公式またはcommunity support matrixを確認します。
server/discoverがあればServer Cardsも使えますか？
別の機能です。server/discoverは接続後の能力情報取得、Server CardsはSEP-2127が扱う接続前のHTTP server discoveryです。後者は2026-09-25時点でin-reviewとして扱います。
長時間処理のために非同期承認SEP-2848を使えますか？
SEP-2848は2026-09-25時点でdraftです。final仕様と相互運用実装が確認できるまでは、productionの承認フローに直接依存させず、現行のTasks Extensionやhost側承認で構成します。