AIアプリと外部ツールをつなぐオープン規格Model Context Protocol（MCP）のコアメンテナーが、2026年8月22日に新しいロードマップを公開しました。次の仕様リリースとその先で何に手を付けるかを5つの重点分野として整理した内容で、単発のツール呼び出しを超えた長時間の処理と、エージェント自身の身元確認が上位に並んでいます。
セッションを捨てた7月の大改修が出発点
今回のロードマップは、直前の作業が一段落したことを前提に組まれています。前回の版は2026年3月に出たもので、トランスポートの進化とスケーラビリティ、エージェント間通信、ガバナンスの成熟、企業導入への備えという4つを掲げていました。その大半が2026年7月28日の仕様リリースに着地しています。
なかでも影響が大きいのが、プロトコル階層のセッションと初期化ハンドシェイクの廃止です。サーバーが状態を抱えなくてよくなり、そのまま水平にスケールできるようになりました。クライアントは接続後にいきなり本題へ入る代わりに、server/discover を呼んでサーバーが対応するバージョンと機能を先に確認できます。一覧取得の結果はキャッシュ可能になりました。
エージェント間通信の側では、Tasksが早期採用者の声を受けて作り直され、公式の拡張機能という位置に移りました。サーバー側から要求を投げる従来の仕組みは、Multi Round-Trip Requestsという新しいパターンに置き換わっています。ステートレスなサーバーの上でも、ユーザーへの問い合わせのような往復を伴う処理が成立するようにするための変更です。
ガバナンスも形が整いました。貢献者の役割を段階で示すContributor Ladderが正式に採用され、ワーキンググループが自分の担当領域の仕様改善案を選り分けるようになり、機能の寿命と廃止手順を定めたポリシーも用意されました。7月の廃止項目は、そのポリシーを最初に適用した事例です。
待たせるエージェントには、待たせるための部品が要る
新ロードマップの1つ目の重点分野は、エージェント向けのメッセージング基盤です。現代のエージェントの仕事は、要求を投げて答えが返ってくるという素直な形に収まりません。ループが長く回り、サーバーが途中経過を押し出し、動いている処理に横から方向修正を入れたい場面も出てきます。
MCPはこれに合わせてTasks、subscriptions/listen、進捗通知といった部品を足してきました。ロードマップが問題にしているのは、部品が揃っているかどうかではなく、それらが互いにうまく噛み合うかどうかです。作業としてはサーバー側から発火するイベント、つまりWebhookやチャンネルの導入が挙げられています。クライアントが結果を求めて何度も問い合わせ続ける状態から抜け出すためです。あわせて、Agents、Transports、Triggers & Eventsの各ワーキンググループをまたいで、部品同士の組み合わせ方を点検する予定とされています。拡張機能にとどまっているTasksを仕様本体へ引き上げることも目標に入りました。
ローカルのサーバーもHTTPで話させたい
2つ目はトランスポートの統一です。7月の変更によって、リモートのMCPサーバーは普通のHTTPワークロードと変わらなくなりました。開発者や組織がすでにAPIやサービスの運用に使っているインフラへ、そのまま載せられるということです。この方式は規模の面で通用することが確かめられたため、ほかの動作形態にも広げようという話になっています。
具体的に名前が挙がっているのが、ローカルで動くサーバーです。標準入出力の上でStreamable HTTPを話させる方向が検討されています。ローカルとリモートで別々のトランスポートを抱えなくてよくなれば、サーバーとクライアントの実装はさらに単純になります。
人が承認ボタンを押せない場面が増えてきた
3つ目のエージェントの身元と企業向けセキュリティは、現行の認可の前提が崩れつつあるという認識から来ています。今のMCPの認可は、人がブラウザでアクセスを承認する流れを中心に設計されています。対話的なクライアントにはよく合いますが、呼び出し側がクラウド上のワークロードとして独自の身元を持ち、その場にいないユーザーの代理で動き、さらに配下のエージェントへ絞った権限を渡す、という構図が増えてきました。
メンテナーが目指しているのは、貼り付けたAPIキーや長寿命のトークンに頼らず、既存の標準の上でエージェントの身元をサーバー側が認識し信頼できるようにすることです。作業項目としては、アクセストークンを鍵に結び付けるDemonstrating Proof of Possession（DPoP）の仕上げと普及、Workload Identity Federation、企業向け認可の裏で使われているID-JAGグラント、標準的なトークン交換を組み合わせた委任の道筋の定義が挙げられています。IETFのOAuthワーキンググループやWIMSEとの関わりも続けるとしています。
100個のツールを、質問される前に全部見せない
4つ目は基本機能そのものの改善です。ツール呼び出しはMCPで最初に触る部分であり、これまで大きな破綻はありませんでした。手薄なのは結果の扱いのほうです。tools/call の応答は同じ内容を複数の形で運べるため、サーバーの開発者は、目の前のクライアントがどの形をモデルに見せるのかを知る手段を持っていません。ここは1つの明確な取り決めに寄せる方針です。
もう1つの課題は規模です。ツールを100個公開しているサーバーにつなぐと、ユーザーがまだ何も質問していない段階で、その全体分をモデルが読み込むことになります。しかも一覧が長くなるほど、どれを選ぶべきかの判断は鈍っていきます。そこで、まず小さな入り口だけを見せ、会話の焦点が絞られるにつれてカタログの残りを出していく段階的な開示の取り組みが始まります。
SDKは「エージェントが読む前提」で整える
5つ目はSDKの開発者体験です。多くの開発者にとって、SDKはMCPそのものと言える存在です。使い勝手と仕様への適合性、そして対応する各言語・各プラットフォームでのドキュメントの正確さに投資するとしています。
理由付けが今風です。MCPのクライアントやサーバーを、ライブラリをエージェントに読ませて書かせる開発者が増えており、APIが分かりやすくドキュメントが正確かどうかが、そのまま生成されたコードが動くかどうかを決めてしまう、というわけです。
仕様改善案の通りやすさが変わる
ロードマップは、どの提案が優先的に審査されるかにも直結します。5つの重点分野に入る仕様改善案（SEP）は審査が早く回り、採択される見込みも高くなります。範囲外の提案が自動的に却下されるわけではありませんが、メンテナーの時間は有限であり、まず重点分野に割かれるとはっきり書かれています。
提案を考えている人に対しては、自分の案がどの重点分野に属するかを見極め、該当するワーキンググループに持ち込み、そこのメンバーと一緒に形にしていくやり方が案内されています。各分野には責任を持つコアメンテナーの名前が明示されました。
まとめ
7月の仕様改定でMCPは状態を持たない普通のHTTPサービスに近づき、その土台の上で次に何をするかが今回のロードマップで示されました。長く動く処理をきちんと扱うための部品の整理、ローカルまで含めたトランスポートの統一、人が承認できない場面を前提にしたエージェントの身元確認、ツールが増えても選べるようにする段階的な開示、そしてSDKの品質という5本です。共通しているのは、人が横で見ている前提を少しずつ外していく方向性で、エージェントを本番に置いた運用側の関心事とよく重なっています。
出典: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/
