Model Context Protocol（MCP）の新しいロードマップが公開され、AIエージェント対応やトランスポートの統一、エージェントIDの標準化といった方向性が示されました。ただし、この内容の受け取り方には注意が必要です。ロードマップはあくまで将来の方針を示すものであり、すでに確定した仕様とは切り分けて理解しなければなりません。本記事では、確定済みの内容と提案段階の内容を明確に区別しながら、実運用チームが今から備えるべき技術的なインパクトを整理していきます。

MCP新ロードマップが登場した背景とAAIFによる統治体制

今回のロードマップを理解するうえで、まず押さえておきたいのが発表主体と統治構造です。MCPの新ロードマップを示したのは、Linux Foundation配下に設けられたAgentic AI Foundation（AAIF）です。MCPはかつて単一ベンダー主導で開発されていましたが、現在はマルチステークホルダーによる統治体制へ移行済みであり、これは確定した事実として扱えます。

AAIFのPlatinum会員には、AWS、Anthropic、Google、Microsoft、OpenAIといった主要企業が名を連ねています。プレスリリースの記載値によれば、公開されているMCPサーバーはすでに1万を超える規模に達しています。単一企業の製品ではなく、業界横断の共通基盤としてMCPが位置づけられていることが分かります。

統治プロセスの面でも大きな変化があります。仕様変更はこれまでのリリース単位の計画から、Working Group駆動とSEP（Specification Enhancement Proposal）審査を軸としたプロセスへと移行しました。この文脈で言うロードマップとは、次期の仕様リリースに向けて優先的に審査されるSEP領域を示すものにあたります。

ここで最も重要な前提を確認しておきます。公式ロードマップ（最終更新は2026年8月22日）は、自らを「確定した約束ではなく現時点での考え方（current thinking rather than firm commitments）」であると明言しています。つまり、本記事で後述する5本柱の各施策は、原則としてすべて提案・計画段階のものです。実装済みの確定仕様と混同しないよう読み進めてください。

確定済みの2026-07-28仕様がもたらした変化

ロードマップの前提として、すでに導入された確定仕様を先に整理します。直近で確定した仕様リリースは2026年7月28日のものであり、ここに含まれる変更は「導入済み」として扱ってよい内容です。

最も影響が大きいのがステートレス・コア化（SEP-2575）です。従来のセッションとinitializeハンドシェイクが撤去され、各リクエストが自己記述的になりました。これにより、共有ストレージを持たなくても、ロードバランサ背後の任意のインスタンスへリクエストを振り分けられるようになります。スケールアウト設計にとって有利な変更です。

トランスポートについては、legacy HTTP+SSEトランスポートが正式に非推奨化されました。ただし最低12か月のサポート窓（off-ramp）が確保されています。ここで強調しておきたいのは、非推奨化されたのはあくまでlegacyなHTTP+SSEであって、これはSSEの段階的な扱いの見直しであり、stdioの廃止ではないという点です。

あわせて、Streamable HTTPにはMcp-MethodとMcp-Nameのヘッダを用いたヘッダベースルーティングが導入されました。ゲートウェイやWAFがJSONボディを解析せずにルーティングできるようになります。List結果については、ttlMsとcacheScope（SEP-2549）によるキャッシュ可能化も加わりました。

認可の面では、Enterprise-Managed Authorization（EMA）がstable化しています。認可サーバのissuer検証を定めたRFC 9207が採用され、クライアントは値を利用する前にissuerを検証します。さらに、Dynamic Client Registration（DCR）が非推奨化され、CIMD（Client ID Metadata Document）への移行方針が確定しました。これらはいずれも導入済みの確定事項です。

新ロードマップ5つの方針とその技術的背景

ここからが提案段階の話になります。新ロードマップは5本の柱を掲げていますが、繰り返し強調するとおり、以下はすべて現時点での方針であり確定仕様ではありません。

柱1のAgentic Messaging Primitivesは、エージェント作業がリクエスト・レスポンスの枠を超えている現状に対応する構想です。数分単位で走るタスクやサーバからのプッシュに応えるため、server-initiated eventsやTasks拡張（SEP-2663）を通じて、コストの高いクライアント側ポーリングへの依存から脱却しようとしています。

柱2のHTTP-Native Transport Unificationは、Streamable HTTPを唯一のバインディングとする方針です。ローカルサーバーでは、stdin/stdout上でHTTPを話す「HTTP over stdio」へ統一する構想が示されています。これはstdioを廃止するという話ではなく、あくまでトランスポートモデルを一つにまとめる統一の取り組みだと理解してください。

柱3のAgent Identity and Enterprise-Ready Securityは、エージェント自身のIDを標準ベースで扱う構想です。DPoP、Workload Identity Federation（SEP-1933）、ID-JAG、RFC 8693のtoken exchangeを軸に、貼り付けAPIキーや長寿命トークンへの依存から脱却することを目指しています。

柱4のImproved Primitivesは、tool結果の形状を再設計し、progressive discoveryによって大量のツールやリソースを順次案内できるようにする構想です。柱5のSDK Developer Experienceは、仕様と適合テストスイートをsource of truthとして、SDKやサンプルを再生成・再検証する実験的な取り組みです。いずれも提案段階にとどまります。

現行実装からの移行で開発者が注意すべき点

現行実装から移行するにあたり、開発者が誤解しやすい点を確定側と提案側の両面から整理します。

第一に、HTTP over stdioはstdioの廃止ではなくモデルの統一である点です。ローカル実行手段としてのstdioは存続し、その上でStreamable HTTPを話す形になります。「stdioが消える」という誤読は避けてください。実際に非推奨化されたのはlegacy HTTP+SSEであり、既存のSSE実装は12か月以上の窓の間にStreamable HTTPへの移行計画を立てる必要があります。これは確定事項です。

第二に、セッション前提やinitializeハンドシェイク前提の実装は、ステートレスモデルへの見直しが必要になります。あわせて、Mcp-MethodやMcp-Nameのヘッダを途中で落としてしまう中間装置は不具合の要因になり得るため、経路上での保持を確認しておくべきです。

第三に、エージェントID関連の仕組み、すなわちDPoPやWIF、ID-JAG、token exchangeはまだ提案段階です。確定と誤認して先行実装しないことが重要です。同様に、tools/callのcontentとstructuredContentを同時に返却する挙動にも依存しない実装が無難です。

実運用チームが今から準備し検証すべきアクション

最後に、実運用チームが着手すべきことを、確定対応と提案段階のウォッチに分けて示します。混同を避けることが、無駄な先行投資を防ぐ鍵になります。

今すぐ着手すべき確定対応としては、まずHTTP+SSE(legacy)を利用している箇所を棚卸しし、Streamable HTTPへの移行計画を起票することが挙げられます。あわせて、クライアントやゲートウェイがMcp-MethodとMcp-Nameのヘッダを保持・ルーティングできるかを検証してください。認可基盤については、RFC 9207のissuer検証の実装状況を確認し、DCR利用箇所を洗い出してCIMD移行を評価します。ステートレス動作、つまりセッション不要でロードバランサ背後の任意インスタンスへ振り分けられるかの検証も、確定対応にあたります。

一方、提案段階のウォッチにとどめるべき領域もあります。Agent Identity Working Groupの動向は追跡しつつも、本番実装は保留し、当面のエンタープライズ認可はstableなEMAで賄えるかを評価するのが堅実です。非同期処理については、当面はポーリング（Tasks）を前提に設計し、server-initiated eventsの仕様確定を待ちます。加えて、自社要件に効くSEPを該当するWorking Groupでウォッチし、必要に応じてコメントを寄せていくことも有効です。

MCPは提案段階と確定仕様が同時に動いている過渡期にあります。確定対応は今すぐ、提案段階は要件整理とPoCまで、という線引きを守ることが、変化に振り回されずに価値を積み上げる近道になります。