MCPのロードマップは2026年、結局どこへ向かうと示されたのでしょうか？ 答えは「脱ポーリング（サーバー起点イベント）・HTTPトランスポートへの一本化・エージェント認証の標準化・プリミティブ改善・SDK開発者体験」の5領域で、2026年8月22日にModel Context Protocol公式ブログが正式なロードマップとして公開しています。
公開したのはMCPのリードメンテナであるDavid Soria Parra氏とDen Delimarsky氏。2026年7月28日に確定した最新仕様（ステートレスコア）を土台に、「次の仕様リリースとその先」で何に取り組むかを整理した方向性表明です。具体的な期日は書かれていませんが、どの領域も既にWorking Groupが動いており、MCPサーバーやクライアントを作っている開発者にとっては設計判断に直結する内容になっています。
この記事では、前提となる2026-07-28仕様の変更点を短くおさらいしたうえで、ロードマップの5つの優先領域を1つずつ読み解き、開発者とエンタープライズがいま何を準備できるかまで整理します。
2025年11月〜2026年7月：ステートレス化までの流れをおさらい
今回のロードマップを理解するには、直前の仕様改訂を押さえておく必要があります。MCPの仕様は「2025-11-25」リビジョンから「2026-07-28」リビジョンへの改訂で、プロトコルの根幹が大きく変わりました。公式の変更履歴（changelog）に記載されている主要な変更は次のとおりです。
| 変更点 | 内容 | ねらい |
|---|---|---|
| プロトコルレベルのセッション廃止 | Streamable HTTPからMcp-Session-Idヘッダーを削除。状態が必要なら、サーバーが発行するハンドルをツール引数として明示的に渡す |
水平スケールの容易化 |
| ステートレスコア | initializeハンドシェイクを廃止し、各リクエストの_metaにプロトコルバージョンとクライアント能力を毎回載せる |
接続の前提を減らし、ロードバランサ配下でも安全に |
server/discoverの追加 |
サーバーが対応バージョン・能力・識別情報を広告するRPC。事前のバージョン選択や互換性プローブに使う | 能力ネゴシエーションの単純化 |
| Multi Round-Trip Requests（MRTR） | サーバー起点リクエストの代わりに、resultType: "input_required"で「追加入力が必要」と返し、クライアントが再試行時に回答を添える |
双方向接続に依存しないやり取り |
| list結果のキャッシュ化 | tools/list等の結果にttlMsとcacheScopeを必須化。クライアント側キャッシュでポーリングを削減 |
大規模運用時の負荷軽減 |
| Tasksの拡張化 | 実験的だったタスク機能をコアから切り出し、公式拡張io.modelcontextprotocol/tasksへ。tasks/getによるポーリング型に再設計 |
長時間ジョブの扱いを整理 |
| Roots・Sampling・Loggingの非推奨化 | 12カ月以上の猶予期間つきで段階的廃止へ。旧HTTP+SSEトランスポートも正式にDeprecated | プロトコルの痩身化 |
ひとことで言えば、2026-07-28仕様は「MCPをWebと同じ流儀にする」改訂でした。セッションを持たず、毎回のリクエストが自己完結し、レスポンスはキャッシュできる。この形になったことで、CDNやロードバランサといったWebの既存インフラがそのまま使えるようになっています。仕様改訂そのものの詳細はMCP次期仕様解説｜ステートレスコアとTasks拡張化で先行して取り上げているので、実装レベルの変更点はそちらを参照してください。
ステートレス化後のリクエストがどんな形になるかだけ、概念例を示しておきます。ハンドシェイクなしで、1リクエストに必要な情報がすべて載る構造です。
// 2026-07-28仕様の概念例: initialize不要、_metaに毎回バージョンと能力を載せる
// 注意: フィールド名は公式changelogに基づく概念例です。実装時は必ず公式仕様を確認してください。
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search_docs",
"arguments": { "query": "roadmap" },
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientCapabilities": {},
"io.modelcontextprotocol/clientInfo": { "name": "my-client", "version": "1.0.0" }
}
}
}ポイント: レスポンス側にはresultTypeフィールドが必須になり、通常は"complete"、追加入力が必要なら"input_required"が返ります。本番環境で使用する前に、必ずテスト環境で動作確認してください。
2026年8月22日：新ロードマップが提示した5つの優先領域
この土台の上で、8月22日のロードマップは「次に解くべき課題」を5つ挙げました。原文の表現とあわせて、1つずつ見ていきましょう。
①Agentic Messaging Primitives — ポーリングをやめて、サーバーから知らせる
ロードマップが最初に挙げたのは、リクエスト・レスポンスの枠を超えるメッセージングです。原文には「現代のエージェントワークロードは、もはや標準的なリクエスト＆レスポンスのパターンに収まらない。ループはより長く走り、サーバーはストリーミングで結果を送り、進行中の作業に途中で介入したいという明確なニーズがある」とあります。
現状のMCPでは、長時間タスクの進捗を知るにはクライアントがtasks/getで聞きに行く（ポーリングする）しかありません。ロードマップはここに、Webhookやチャネルといったサーバー起点イベントを導入し、ポーリングを解消する方針を示しました。あわせて、2026-07-28仕様で公式拡張になったTasksを、本仕様への昇格に向けて成熟させることも明記されています。
実際にMCPサーバーで長時間処理を組んでみると、ポーリング間隔の設計は悩みどころです。短くすればサーバー負荷が上がり、長くすれば応答が遅く感じられる。サーバー側から「終わったよ」と通知できるようになれば、この設計問題ごと消えることになります。エージェントが数分〜数時間単位のジョブを回す使い方が増えている以上、優先度が最上位に置かれたのは順当と言えるでしょう。
②HTTP-Native Transport Unification — ローカルサーバーもHTTPの流儀に
2つ目はトランスポートの一本化です。MCPには歴史的に、ローカルプロセス向けのstdioトランスポートと、リモート向けのStreamable HTTPが並存してきました。ロードマップは原文で「ローカルサーバーがstdio越しにStreamable HTTPを話すことを含め、他のデプロイモードもカバーするようにHTTPアプローチを引き伸ばしたい」と述べています。
つまり、通信路がプロセスのパイプであってもネットワークであっても、その上を流れるプロトコルはHTTPの意味論で統一するという方向です。これが実現すると、サーバー実装者は2種類のトランスポートを別々にテストする必要がなくなり、クライアント側も接続処理を1系統に集約できます。Streamable HTTPの実装パターンはMCP Streamable HTTP完全実装ガイドで詳しく解説していますが、今後はこの知識がローカルサーバー開発にもそのまま効いてくることになります。
③Agent Identity and Enterprise-Ready Security — 「人がいない場面」の認証を標準で
3つ目はエンタープライズ導入の本丸、認証・認可です。ロードマップは現状認識として「呼び出し元の多くが、独自のアイデンティティを持ってクラウドワークロードとして動くエージェントになりつつある。その場にいないユーザーの代理として動いたり、より狭い権限をサブエージェントに委譲したりする」と書いています。ブラウザでログイン画面を開ける「人間がいる前提」のOAuthフローだけでは足りない、という問題意識です。
具体的に挙げられているのは次の3つで、いずれも独自方式ではなく既存のオープン標準の採用です。
- DPoP（Demonstrating Proof of Possession / RFC 9449）: アクセストークンをクライアントの鍵ペアに暗号学的に紐づける仕組み。トークンが漏洩しても、対応する秘密鍵がなければ使えなくなる
- Workload Identity Federation: クラウド上のワークロードが、長期のAPIキーを持たずに自身の実行環境由来のアイデンティティで認証する方式。IETFのWIMSE（Workload Identity in Multi System Environments）Working Groupが標準化を進めている領域
- トークン交換（Token Exchange / RFC 8693）: ユーザーから委譲された権限を、より狭いスコープのトークンに交換してサブエージェントへ渡すための標準
ロードマップには、IETFのOAuth関連Working GroupやWIMSEと連携して進めることも明記されています。MCPが認証を自前発明せず標準化団体と歩調を合わせるのは、企業のセキュリティ部門にとって審査しやすい方向です。現行仕様のOAuthベース認可をこれから設計する場合は、MCP OAuth認可ガイドが前提知識として役立ちます。
④Improved Primitives — ツール結果の扱いと「段階的な発見」
4つ目は地味ながら実務インパクトの大きい領域です。課題は2つ挙げられています。1つはツール結果のハンドリングが実装ごとにバラバラで、契約として標準化されていないこと。もう1つはスケールの問題で、原文の表現がわかりやすいので引用します。「100個のツールを持つサーバーに接続すると、ユーザーが1つも質問しないうちから、モデルはその全表面積のコストを払うことになる。しかもツールの選択精度は、リストが伸びるほど悪化する傾向がある」。
解決策として示されたのがプログレッシブディスカバリー（段階的なツール発見）です。サーバーは最初に小さな入口だけを見せ、文脈に応じてカタログの残りを開示していく。ツール定義を全部プロンプトに詰め込む現在のやり方に比べて、トークンコストとツール選択精度の両方を改善する狙いがあります。ツール数が多いMCPサーバーを自作している場合、この動きは設計の前提を変える可能性があります。
⑤Improved SDK Developer Experience — AIがコードを書く時代のSDK品質
最後はSDKです。原文は「SDKは開発者がMCPを体験する場そのものだ。明確なAPIと正確なドキュメントが、最小の摩擦でコードが動くかどうかを決める」と位置づけたうえで、仕様準拠（コンフォーマンス）テストの整備とドキュメントの明確化を優先課題に挙げています。
興味深いのは、SDKの主要な「利用者」としてAIコーディングエージェントを想定している点です。人間だけでなくAIが読んで正しくコードを生成できるドキュメントとAPI設計が、そのままプロトコルの普及速度を左右するという認識です。PythonでのMCPサーバー開発ではFastMCPによるサーバー自作ガイドのようなフレームワーク層が既にありますが、公式SDK自体の準拠性が上がれば、こうしたエコシステム全体の品質底上げにつながります。
5領域を1枚で俯瞰する
ここまでの内容を整理すると、5つの優先領域はそれぞれ異なる立場の開発者に効いてきます。自分がどこに関係するかを確認しておきましょう。
| 優先領域 | 現状の課題 | ロードマップの答え | 主に影響を受ける人 |
|---|---|---|---|
| ①Agentic Messaging | 長時間タスクの進捗をポーリングで確認するしかない | Webhook・チャネルによるサーバー起点イベント、Tasks拡張の本仕様化 | 長時間ジョブを扱うサーバー実装者 |
| ②HTTPトランスポート統一 | stdioとStreamable HTTPの2系統を別々に実装・テストする負担 | ローカルサーバーも含めHTTPの意味論に一本化 | サーバー・クライアント両方の実装者 |
| ③Agent Identity | 人間不在のワークロード認証や権限委譲の標準がない | DPoP・Workload Identity Federation・トークン交換の採用 | エンタープライズの導入・セキュリティ担当 |
| ④Improved Primitives | ツール結果の扱いが実装依存、ツール数増でコストと精度が悪化 | 結果ハンドリングの標準化、段階的なツール発見 | ツール数の多いサーバーの設計者 |
| ⑤SDK Developer Experience | SDKごとの仕様準拠のばらつき、ドキュメントの曖昧さ | コンフォーマンステストとドキュメント整備 | SDK利用者全員（AIコーディングエージェント含む） |
注目したいのは、5つのうち3つ（①②④）が「スケールしたときの痛み」への対処だという点です。MCPが実験フェーズを越えて、数百ツール・数千接続の規模で運用され始めている実態が、優先順位の付け方から透けて見えます。
開発者がいま準備できる4つのこと
ロードマップは方向性表明であって、確定した日付やリリーススケジュールは書かれていません。それでも、いま打てる手はあります。
- 新規サーバーはステートレス前提で設計する: セッションに依存した状態管理を今から組み込むのは逆行です。状態が必要なら、サーバー発行のハンドルをツール引数で受け渡す2026-07-28仕様の流儀に合わせておきましょう
- Roots・Sampling・Loggingへの新規依存をやめる: この3機能は既に非推奨です。ディレクトリはツール引数やリソースURIで渡す、ログはstderrやOpenTelemetryに出す、といった公式の移行先に沿った設計にしておくと、将来の改修コストが減ります
- ポーリング処理は「置き換わる前提」で疎結合に:
tasks/getによるポーリングは当面必要ですが、通知受信に差し替えられるよう、ポーリングロジックをアプリケーション本体から分離しておく価値があります - 認証設計でカスタム方式を避ける: 独自のAPIキー配布やトークン運用を作り込むほど、DPoPやWorkload Identity Federationへの移行が痛くなります。現行のOAuthベース認可に素直に乗っておくのが、結果的に最短経路です
エンタープライズ導入への影響 — 「様子見」の理由が減っていく
企業のセキュリティ審査でMCP導入が止まる典型的な理由は、「エージェントの認証が標準化されていない」「トークンの委譲範囲を制御できない」「監査の枠組みがない」の3点でした。今回のロードマップは、このうち認証と委譲に対してRFCベースの回答を用意しに行く宣言です。
DPoPによるトークンの鍵バインディングが入れば、トークン漏洩時の被害範囲が構造的に狭まります。トークン交換が標準化されれば、「エージェントには読み取り権限だけ、サブエージェントには特定リソースだけ」といった最小権限の委譲を、監査可能な形で構成できます。セキュリティ部門との対話では、「MCPはIETFのOAuth・WIMSEと連携して標準ベースで進めている」という事実自体が説得材料になるでしょう。
一方で、正直に言えば未確定要素も残ります。ロードマップの各項目にはリリース時期の記載がなく、Tasks拡張の本仕様昇格やサーバー起点イベントの具体的なプロトコル設計はこれからです。本番システムの調達計画にこれらを「確定機能」として織り込むのは時期尚早で、現時点では2026-07-28仕様の範囲で設計し、ロードマップ項目は拡張ポイントとして余地を残しておく、という二段構えが現実的です。
よくある質問
ロードマップの内容はいつ仕様に入りますか？
公式ロードマップに具体的な日付や期限の記載はありません。「次の仕様リリースとその先」に向けた優先領域の表明であり、各項目はWorking Groupでの議論とSEP（仕様拡張提案）のプロセスを経て仕様化されます。進捗はGitHubのmodelcontextprotocolリポジトリで公開されています。
既存のMCPサーバーは書き直しが必要ですか？
直ちに書き直す必要はありません。2026-07-28仕様には後方互換の配慮があり、非推奨機能にも12カ月以上の猶予期間が設定されています。ただし、Roots・Sampling・Logging・旧HTTP+SSEトランスポートに依存した新規開発は避けるべきです。
DPoPやWorkload Identity Federationは今すぐ使えますか？
DPoP自体はRFC 9449として2023年に標準化済みで、対応する認可サーバーであれば技術的には利用可能です。ただしMCPプロトコルとしての組み込み方はロードマップ上の取り組み中であり、MCP標準の作法として確定するのはこれからです。
結論と次の一歩
2026年8月22日のMCPロードマップが示したのは、「ステートレス化を終えたMCPが、次はエージェント時代の通信と認証を標準で解きに行く」という明確な方針です。脱ポーリングのメッセージング、HTTPへのトランスポート統一、DPoP・Workload Identity Federationによるエージェント認証、ツール結果と段階的発見の標準化、そしてAIエージェントを利用者に見据えたSDK品質。5領域はどれも、MCPを実験段階から企業インフラへ引き上げるための布石になっています。
次の一歩としては、まずロードマップ原文に目を通し、自分のサーバー実装に2026-07-28仕様への移行残タスク（セッション依存・非推奨機能の使用）がないかを棚卸ししてみてください。そのうえで、ポーリング部分と認証部分を差し替え可能な形に整理しておけば、ロードマップの各項目が仕様に降りてきたときに最小の改修で追従できます。
参考・出典
- MCP Roadmap — Model Context Protocol公式ブログ（2026-08-22公開、参照日: 2026-08-29）
- MCP Specification 2026-07-28 Key Changes — Model Context Protocol公式仕様（参照日: 2026-08-29）
- RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — IETF（参照日: 2026-08-29）
- RFC 8693: OAuth 2.0 Token Exchange — IETF（参照日: 2026-08-29）
- WIMSE (Workload Identity in Multi System Environments) Working Group — IETF Datatracker（参照日: 2026-08-29）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
この記事はAIgent Lab編集部がお届けしました。
