MCP 新ロードマップ公開 — エージェント時代の5本柱とprogressive tool discoveryが変えるもの

はじめに

2026年8月22日、Model Context Protocol の公式ブログに新しいロードマップが公開された。Core Maintainers と各 Working Group が合意した「次期仕様で優先的に取り組む5領域」の提示である。

MCP はこの1年で、ローカルのツール接続規格から、本番のエージェント基盤を支えるプロトコルへと重心を移してきた。直近の 2026-07-28 仕様でプロトコルコアがステートレス化され、リモート MCP サーバーは「ごく普通の HTTP ワークロード」として扱えるようになっている。今回のロードマップは、その延長線上で何を積み増すかを宣言したものだ。

本記事では5本柱それぞれの中身を押さえたうえで、MCP サーバー／クライアントを実装している側から見てどのコードが書き換わるのかを整理する。とくに progressive tool discovery は、多くの実装が今まさに抱えているコンテキスト膨張問題への公式回答になっている。

ロードマップの5本柱

ロードマップが挙げる優先領域は以下の5つである。

1. Agentic Messaging Primitives

ロードマップはまず前提を明言している。「現代のエージェント的ワークロードは、標準的な request-and-response のパターンにもはや収まらない」。ループは長時間走り、サーバーは結果をストリームで push し、実行中の作業を途中で操舵する必要がある、という認識だ。

具体策は3つ。サーバー起点のイベント（webhook と channel）を導入してクライアントが結果をポーリングし続ける状態をなくすこと、**Tasks 拡張（SEP-2663）**を成熟させて仕様本体に取り込むこと、そして subscriptions/listen や progress notification と整合させることである。Agents / Transports / Triggers & Events という複数の Working Group をまたいで、これらが一貫して噛み合うことを目標に置いている。

2. HTTP-Native Transport Unification and Hardening

2026-07-28 でリモートサーバーは標準的な HTTP ワークロードになった。次はこれを他のデプロイ形態にも広げる。ロードマップの表現では「ローカルサーバーが stdio 上で Streamable HTTP を話す」形まで含めて統一する。

3. Agent Identity and Enterprise-Ready Security

現行の MCP 認可は、ブラウザ経由で人間が承認することを前提にしている。ここに agent-to-agent のシナリオを載せるため、DPoP（Demonstrating Proof of Possession）、Workload Identity Federation、標準的な token exchange による Enterprise-Managed Authorization を導入する。IETF の OAuth WG および WIMSE WG と連携して、土台となる標準側も進めるとしている。

4. Improved Primitives

tool result の扱いを単一のレスポンス契約に標準化すること、そして progressive tool discovery。「サーバーは小さなエントリポイントだけを提示し、会話が絞り込まれるにつれてカタログの続きを開示できる」形にする。

5. Improved SDK Developer Experience

SDK のエルゴノミクス、仕様適合テスト、ドキュメントの明瞭さへの投資。

技術的背景 — なぜ今この5本なのか

この5本は互いに独立した願望リストではなく、ステートレス化した 2026-07-28 コアの上で何が足りないかという一本の筋で並んでいる。

2026-07-28 仕様は、プロトコルレベルのセッションと Mcp-Session-Id ヘッダーを取り払い、同じリクエストを背後のどのサーバーインスタンスが処理してもよい形にした。ロードバランサーもキャッシュも、特別扱いなしに MCP トラフィックを扱える。スケールの観点では大きな前進だ。

だがステートレス化は「長時間走る仕事」と相性が悪い。セッションを持たないなら、5分かかるツール呼び出しの途中経過をどう返すのか。そこを埋めるのが柱1の Tasks と server-initiated events である。Tasks は 2026-07-28 で拡張として先行導入されており、「呼んでおいて後から取りに行く」パターンを表現する。ロードマップはこれを実験的拡張から仕様本体へ引き上げると言っている。webhook と channel が入れば、クライアント側の「完了したか問い合わせるループ」というアンチパターンそのものが不要になる。

柱3も同じ筋にある。ブラウザで人間が同意ボタンを押す認可は、人間がループの中にいる前提の設計だ。エージェントが別のエージェントのサーバーを叩く構図では成立しない。かといって API キーの直書きに戻れば、鍵の持ち出しがそのまま権限の持ち出しになる。DPoP（RFC 9449）はトークンをクライアントの鍵に束縛し、トークン単体を盗んでも使えないようにする仕組みで、bearer token の構造的弱点をここで塞ぐ意図だ。Workload Identity Federation は、ワークロード自身の身元を信頼の起点にして、静的な資格情報の配布そのものをなくす方向である。

柱2の「stdio 上で Streamable HTTP」も一貫している。現状、ローカルサーバーは stdio の JSON-RPC、リモートは Streamable HTTP と、実装が事実上二系統に割れている。認可・再接続・ストリーミングの扱いがそれぞれ別物になり、SDK もサーバー実装もその差を吸収するコードを抱える。トランスポートを揃えれば、この分岐がまるごと消える。

エンジニアへの影響 — 何が書き換わるか

progressive tool discovery が最も広く効く。 現在の MCP は接続時に全ツール定義をモデルへ渡す。ツールが数十個を超えたあたりから、実際に使うのは1〜2個なのに、毎リクエストのコンテキストにカタログ全体が乗り続ける。トークンコストが増えるだけでなく、選択肢が増えるほどモデルのツール選択精度自体が落ちる。

この問題は現場ではすでに独自回避されている。ツールを検索する「メタツール」を1個だけ公開し、必要になった時点で実スキーマを読み込ませる、というパターンだ。Claude Code が deferred tool を ToolSearch 経由で取りに行く構造も同じ発想である。ロードマップはこの実務パターンをプロトコル側に降ろすと言っている。独自に実装している discovery 層は、標準が固まった時点で捨てられる可能性が高い。 今から作り込むなら、置き換え前提の薄い層にしておくのが妥当だ。

tool result の単一契約化は、地味だが破壊的になりうる。 現在は結果の返し方が複数形あり、クライアントごとに解釈が揺れている。標準化は正しい方向だが、既存サーバーのレスポンス組み立て部分に手が入る。

ローカル stdio 前提のサーバーは、トランスポート層を抽象化しておくと安全だ。 統一が来たときに、フレーミングと認可の前提が変わる。逆に言えば、この統一が済めばローカル／リモートで同一の実装を出荷できる。

エンタープライズ導入を検討している側には、柱3が実質的な解禁条件になる。 「MCP サーバーを社内に置きたいが、認可が人間の同意ボタン前提なので監査に通らない」という詰まり方は珍しくない。標準ベースの agent identity が入ることで、既存の IdP・トークン基盤に載せられるようになる。

なお、ロードマップは実装スケジュールではない。SEP（Spec Enhancement Proposal）が優先領域に該当する場合に審査を優先する、という運用方針の表明であり、各項目がどの仕様バージョンで入るかは確定していない。今日のコードを書き換える指示ではなく、設計判断の重心をどこに置くかの情報として読むのが正しい。

まとめ

MCP 公式が次期仕様の優先5領域を公開した（2026年8月22日）
中身は 2026-07-28 のステートレス化コアを前提に、長時間実行・エージェント間認可・カタログ肥大という3つの穴を埋める構成になっている
実務インパクトが最も大きいのは progressive tool discovery。独自の discovery 回避策は標準に置き換わる前提で薄く作るべき
DPoP / Workload Identity Federation は、エンタープライズ導入のブロッカーを外す変更
ローカル stdio 前提のサーバーは、トランスポート抽象化の余地を残しておくと移行が軽い

MCP は「LLM にツールを繋ぐ規格」から「エージェントを本番で運用するためのインフラ規格」へ移行しつつある。ロードマップは確定スケジュールではないため、SEP-2663 をはじめとする個別提案の進行を追うのが、次に具体的な変更を知る最短経路になる。

今日のその他のニュース

React 19.3 の browser() API — ブラウザ API を必要とし SSR できないコンポーネントを宣言的にマークする API。use() と併用すると、サーバー側では直近の Suspense fallback を出し、ブラウザ側で正常に描画される。従来 hydration mismatch を招いていた pathless SSR での <Outlet /> 解決などが、mismatch なしに書ける。「SSR できないもの」を実行時バグから設計時の宣言へ移せる点が本質だ。

Codex の 505 セッション分析で「避けられた再実行」370回 — 再実行の 63.2% が Git メタデータのサンドボックス制限・GitHub API 拒否・NuGet ネットワーク遮断の3パターンに集中し、81.6% はコード変更ではなく実行条件（権限・ネットワーク・環境変数）の修正で解決したという実ログ集計。しかも一度解決した環境問題が40日以上にわたり再発していた。エージェント運用のコストは、モデルの賢さより環境知見の永続化で決まる場面が多いことを示す数字である。

Firebase Studio は 2027年3月22日にサンセット — 新規ワークスペース作成とサインアップは 2026年6月22日で停止済み。移行先は Google AI Studio / Google Antigravity。デプロイ済みアプリと Firebase 本体プロダクトは影響を受けない。