MCPの新ロードマップ: その上で作る人に何が変わるのか

8月22日、Model Context Protocolのメンテナーは、今後6か月から12か月のプロトコル開発を示す更新版ロードマップを公開しました。5つの優先領域、それぞれを担当するコアメンテナー、そしてどの提案を先にレビューするかという静かですが重要なルールが書かれています。前回の3月ロードマップは4つのことを約束し、その大半を7月の仕様公開で実現しました。だから今回は真面目に読む価値があります。私の見方では、MCPは意図的に「普通のWeb基盤」になろうとしています。作る側にとって役に立つ問いは、その変化が自分のスタックのどこへ最初に効くかです。

要点 - ロードマップは5つを優先します。エージェント型メッセージング、HTTPネイティブな単一トランスポート、エージェントIDと企業向けセキュリティ、より整理されたツールプリミティブ、仕様から生成するSDKです。 - これらの領域に入る仕様提案（SEP）は優先的にレビューされます。外側にある提案は、より長い待ち時間と高い採用基準を見込んだほうがいいでしょう。 - 3月ロードマップの約束は、2026-07-28仕様でかなり実現しました。ステートレスなコア、キャッシュ可能な一覧結果、複数往復リクエストなどです。 - コードへ最も早く影響しそうなのは、エージェントID（DPoPとワークロードID連携）と、大規模なツールカタログ向けの段階的ツール発見です。 - ロードマップは方向であって確約ではありません。メンテナー自身がそう書いています。これを待つために開発を止める必要はありません。

MCPメンテナーは実際に何を発表したのか

まず事実からです。2026年8月22日付の更新版MCPロードマップは、次の仕様サイクルを5つの優先領域に整理しています。それぞれにコアメンテナーが明記され、背後には一つ以上の作業部会があります。

1. エージェント型メッセージングのプリミティブ: チャンネル、サブスクリプション、Webhookなど、サーバー起点のイベントを導入し、クライアントがポーリングを続けなくてよいようにします。さらにTasks、トリガー、進捗通知が一つのライフサイクルを共有できるよう、構成全体も見直します。

2. HTTPネイティブなトランスポートの統一と強化: Streamable HTTPを単一のバインディングとし、最終的にはローカルサーバーでもstdio上で同じ方式を話します。キャッシュもETagまで拡張します。

3. エージェントIDと企業利用に耐えるセキュリティ: DPoP（所有証明の提示）を完成させ、既存IETF標準の上に、エージェントIDと権限委譲の明確な標準経路を定義します。

4. プリミティブの改善: tools/callの結果形式を設計し直し、クライアントが必要になった範囲からサーバーのカタログを知る、段階的発見の新しい取り組みを進めます。

5. SDK開発体験の改善: 拡張契約を定義し、仕様からTier 1 SDKとクイックスタートを直接生成する実験を行います。

5つの領域とは別に、今後をかなり左右するルールがあります。優先領域に入るSEPは迅速にレビューされ、作業部会の後ろ盾がある提案ほど先へ進みます。メンテナー自身の言葉では「メンテナーのレビュー時間は限られている。まずここに使う」です。ロードマップは確約ではなく現時点の考えを示すものだとも明記されているため、個々の項目は遅れたり、別の形で出たりする可能性があります。

2026年8月22日に公開されたMCPロードマップは、今後6か月から12か月の5つの優先領域として、エージェント型メッセージング、HTTPネイティブなトランスポート、エージェントID、改善されたツールプリミティブ、仕様から生成するSDKを挙げています。これらの内側にある提案は優先レビューされ、外側の提案はより長く待つことになります。

なぜこのロードマップは重要なのか

前回のロードマップが実際に実現したからです。若いオープンソースプロジェクトのロードマップは、ときどき希望を書いただけの文書になり、そのまま静かに古びます。今回は実績があります。2026年3月のロードマップは4つを優先し、その大半が5か月後の2026-07-28仕様公開で出荷されました。

採用規模がロードマップに重みを与えています。2026年7月までにTier 1 SDKは月間5億回近くダウンロードされ、TypeScriptとPythonのSDKはそれぞれ累計10億ダウンロードを超えていました。その規模のプロトコルが進む方向を示すなら、地図を読む価値があります。

出典: MCPロードマップ（2026年3月、8月）および2026-07-28仕様の発表。

2026年3月のMCPロードマップは、トランスポートの進化、エージェント間通信、ガバナンスの成熟、企業利用への対応を約束しました。5か月後、2026-07-28仕様はステートレスなプロトコルコア、Tasks拡張、複数往復リクエスト、最短12か月の猶予を持つ正式な非推奨ポリシーを公開しました。

MCPの上で作っているなら何を意味するのか

作る側への直近の影響は均等ではありません。5領域のうち2つは1年以内にコードを変える可能性が高い。残り3つは、プロトコルの周囲でガバナンスや保守のされ方を変えます。順に実務へ訳します。

エージェント型メッセージング: ポーリングの終わり

本物のエージェント仕事は、単純なリクエストとレスポンスに収まりません。ジョブは何分も走り、クライアントが見ていない間にサーバー側で終わります。今のクライアントはポーリングするしかなく、費用もかかり、見た目もきれいではありません。ロードマップはチャンネル、サブスクリプション、Webhookといったサーバー起点イベントを優先します。作業が終わったとき、サーバーからクライアントへ知らせられるようにするためです。構成全体の見直しも同じくらい重要です。今のままだとTasks、subscriptions/listen、進捗通知が「サーバーの仕事がまだ終わっていない」に対する別々の3回答になりかねません。メンテナーは、ライフサイクル、キャンセルモデル、エラー面を共通化したいと考えています。長時間動くツールを作っているなら、Discordでこの領域を追う価値があります。

どこでも同じ一つのトランスポート

2026-07-28公開で、リモートMCPサーバーは普通のHTTPワークロードになりました。次のロードマップはリモートとローカルの分断を消そうとしています。Streamable HTTPを単一のバインディングとし、ローカルサーバーではstdinとstdout上で同じものを話し、HTTP/2で多重化しながら、サブプロセスのセキュリティとライフサイクル保証は残します。今はHTTPネイティブな機能を追加するたびにstdio専用設計も必要になり、そうしなければローカルでは動きません。SDKも2つのトランスポート経路を保守しています。一つのモデルにできれば、その重複が減ります。キャッシュも拡張されます。7月に入ったttlMsとcacheScopeのヒントにETagを加え、ツール呼び出し結果を毎回取り直す代わりに版管理できるようにします。

エージェントID: いちばん早く困るところ

MCPの認可は、同意するときにブラウザーの前に人がいることを前提にしています。しかし呼び出し元は急速にエージェントへ変わっています。自分のIDを持つクラウドワークロードが不在のユーザーに代わって動いたり、親より狭い権限を持つべきサブエージェントを生成したりします。7月の公開発表で引用されたHoneycombでは、月間インタラクティブクエリの約20%をすでにエージェントが占めています。一方、多くの本番MCPサーバーはまだ貼り付けたAPIキーや長寿命のリフレッシュトークンに頼っています。まさに今回の取り組みが終わらせたい慣習です。計画はDPoPを完成させて採用し、ワークロードID連携（SEP-1933）、企業管理型認可の背後にあるID-JAGグラント、RFC 8693トークン交換を使った標準委譲経路を作ることです。IETF OAuthとWIMSE作業部会とも連携します。

MCPの認可モデルは、人がブラウザーでアクセスを承認する前提で作られました。しかし呼び出し元はエージェントへ変わりつつあります。ロードマップはDPoPと、ワークロードID連携およびRFC 8693トークン交換に基づく標準委譲経路を優先します。貼り付けたAPIキーや長寿命トークンなしで、サーバーがエージェントIDを認識できるようにする狙いです。

ツール結果と段階的発見

ここでは2つの混乱を直します。1つ目はtools/callがcontentとstructuredContentの両方を同時に返すことです。サーバー作者はクライアントがどちらをモデルへ見せるか分からず、実装がばらついています。この契約を設計し直します。2つ目は規模です。100個のツールを持つサーバーへ接続すると、ユーザーが一つも質問していないうちからモデルは表面全体のコストを払い、一覧が長くなるほどツール選択も悪くなります。トークン料金は机上の話ではありません。Cloudflareが2026年2月に行ったテストでは、2,500エンドポイントのAPIをMCPツール定義として公開すると約117万トークンを消費し、コード呼び出しなら約1,000トークンでした。提案されている答えが段階的発見です。小さな入口だけを最初に見せ、会話の焦点が絞られるにつれてカタログを追加で見せます。上のキャッシュ作業とも連携します。私はどんなときに普通のAPIのほうが良いかを書きましたが、段階的発見はMCP側からその差を縮める試みです。

仕様からSDKを生成する

いちばん静かな項目が、いちばん示唆的かもしれません。今はSDK、参照サーバー、クイックスタートを人が手作業で保守しています。ロードマップでは実験として、仕様からTier 1 SDK候補と付属クイックスタートを生成し、両方を適合性テスト一式で検証し、どの層を決定論的コード生成にすべきか、どこをモデル支援にすべきかまで含めて結果を公開します。うまくいけば、仕様の曖昧さは生成失敗として露出し、SDKが実装すべき文書からずれていくことも減ります。

今、何をすべきか

緊急度の高い順に4つです。

1. 今週: 非推奨になった面の上で新規開発を始めない。 Roots、Sampling、Logging、旧HTTP+SSEトランスポートは2026-07-28仕様で非推奨になり、最短12か月の猶予があります。まだ動きます。ただ、新しい実装が採用する理由はありません。

2. 今月: サーバーをキャッシュしやすくする。 一覧結果にはすでにttlMsとcacheScopeがあり、ETagも来ます。今から適切なキャッシュヒントを出すサーバーは、移行を一つ先取りできます。

3. 今四半期: エージェントの認証方法を監査する。 運用中のMCPサーバーが、無人で動く呼び出し元に貼り付けAPIキーや長寿命リフレッシュトークンを信頼しているなら、それこそエージェントID作業部会が置き換えようとしている形です。独自の委譲方式を作るより、そのグループを追ってください。ガバナンス面はAIエージェントの統制で扱った話とつながります。

4. プロトコルを形作りたいなら: SEPを優先領域の中で書く。 先に関係する作業部会へ持ち込み、その支持を得てください。ロードマップに沿う提案は優先レビューされ、外側の提案は待ちます。

やらないほうがいいことも2つあります。次の仕様を待って開発を止めないこと。現在の仕様が安定した土台で、非推奨ポリシーにより破壊的変更には今後最短12か月の予告があります。そしてロードマップを約束として扱わないこと。冒頭から、優先順位は変わり得て、一覧にない作業も出荷され得ると書かれています。もっと初期段階なら、私の最初のMCPサーバーを作る実践ガイドとつなぐ価値のあるサーバー一覧が実用的な出発点です。

2026-07-28 MCP仕様はRoots、Sampling、Logging、旧HTTP+SSEトランスポートを、最短12か月の猶予付きで非推奨にしました。公開発表には、その期間中は引き続き動くと明記されています。ただし新しい実装が採用するべき面ではありません。

もっと大きな流れ

少し引いて見ると、これはプロトコルが公開の場で大人になっていく過程です。MCPは2025年12月、OpenAIとBlockを共同創設者として、Linux Foundation傘下のベンダー中立なAgentic AI Foundationへ寄贈されました。それ以降、コントリビューター階梯、機能ライフサイクル、非推奨ポリシーが加わり、今度はメンテナーがどこへ注意を使うかも公開されました。拡張フレームワークも地味ですが実際に効いています。SEP-2133により、どの作業部会も正式提案の前にexperimental-ext-リポジトリで実験でき、コアを不安定にせずアイデアを試せます。

次の2四半期で私が見るのは、stdio上のHTTPが実現するかです。ローカルとリモートのサーバーが本当に一つのトランスポートへ収束すれば、「MCPサーバー」は特殊な種類のソフトウェアではなく、標準の顔を持つWebサービスになります。プロトコルが配管の中へ消える地点です。良い基盤は、最終的にそうなるべきです。

よくある質問

MCPは今、構築に使えるほど安定していますか

はい。ただし移行を前提にした運用は必要です。2026-07-28仕様で最短12か月の猶予を持つ正式な非推奨ポリシーが入り、SDKも破壊的変更には移行ノートを付けます。プロトコルは今後も動きますが、依存しているものが消えるときは1年前から分かるようになりました。

MCPのセッションはどうなりましたか

2026-07-28仕様で廃止されました。initializeハンドシェイクとMcp-Session-Idヘッダーはなくなりました（SEP-2575、SEP-2567）。現在は各リクエストが自己記述的で、プロトコルバージョンとクライアント能力を_metaに載せます。能力を最初に知りたいクライアント向けには、任意のserver/discover呼び出しがハンドシェイクを置き換えます。ラウンドロビンのロードバランサー背後では、どのリクエストもどのインスタンスへ届いて構いません。

次の仕様を待ってから作るべきですか

いいえ。ロードマップは今後6か月から12か月の方向を示すもので、確約された機能一覧ではありません。メンテナーも明記しています。現在の仕様は安定し、キャッシュ可能で、ステートレスです。その上で作り、非推奨面を避け、自分に最も影響する2つの作業部会を追ってください。