新しいMCPロードマップ

2026年8月22日原文(blog.modelcontextprotocol.io)

概要

Model Context Protocol（MCP）の最新ロードマップ公開
5つの優先分野に沿った今後の開発方針
エージェントメッセージング、HTTPトランスポート統一、セキュリティ強化などを重点
開発者向けSDK体験向上も注力
コミュニティ参加・提案方法も案内

Model Context Protocol (MCP) 最新ロードマップの発表

Model Context Protocol（MCP） の新しいロードマップ発表
今後数ヶ月の 開発方針 と 重点分野 の明確化
コアメンテナーとコミュニティ、各Working Groupの協力による策定

優先分野

ロードマップは 5つの優先分野 で構成
- サーバー主導イベント
- 結果型の改善
- エージェントアイデンティティ
- ツール呼び出しの改善
- SDK開発体験の向上

エージェントメッセージングの進化

従来型リクエスト＆レスポンス の枠を超えたエージェントワークロード対応
Tasks、サブスクリプション、進捗通知 などの新プリミティブ導入
Agents、Transports、Triggers & Events Working Groupとの連携強化
サーバー主導イベント（WebhookやChannel）でクライアントのポーリング回避
Tasks拡張（SEP-2663）の仕様成熟化

HTTPネイティブトランスポートの統一と強化

2026-07-28リリース でMCPサーバーが標準HTTPワークロードと同等に
既存のAPI/サービスインフラでの運用容易化
Streamable HTTP over stdioによるローカルサーバー対応も視野
トランスポート統一による開発・運用の簡素化

エージェントアイデンティティとエンタープライズセキュリティ

現状： 人間の承認 を前提とした認可モデル
今後： クラウドエージェント や サブエージェント の標準的なアイデンティティ認証
標準規格に基づく認証（APIキーや長期トークンの廃止）
DPoP（Demonstrating Proof of Possession）の最終化と普及推進
Workload Identity FederationやID-JAG、標準トークン交換による認可強化
OAuth、IETF OAuth、WIMSE WGとの連携を継続

プリミティブの改善

MCPで最も利用される ツール呼び出し のレスポンス標準化
結果の形式統一による 開発者の負担軽減
ツール数増加によるスケール課題への対応（プログレッシブディスカバリーの導入）
サーバーが段階的にカタログを公開する仕組み

SDK開発者体験の向上

SDKの 使いやすさ と 仕様準拠 への投資拡大
すべてのプラットフォーム・言語で直感的かつ文書化されたAPI提供
エージェントによるライブラリ活用時の API明確化 と ドキュメント充実

提案（SEP）の優先順位付け

優先分野に該当する Specification Enhancement Proposal（SEP） は審査が迅速
該当外の提案も拒否はされないが、レビュー時間は優先分野が優先
SEP提出時は該当分野を特定し、関連Working Groupと協力して提案作成

コミュニティ参加方法

各優先分野ごとに Working Group が存在
参加方法：
- Working GroupまたはInterest Groupへの参加（コミュニティチャンネル参照）
- SEPの提案またはコメント（SEPガイドラインを参照）
- 実験的拡張の開始（SEP-2133利用）
- 仕様・SDK・ツールへの直接貢献（コントリビューティングガイド参照）
MCPのさらなる成長と進化に向けたコミュニティ参加を歓迎

Hackerたちの意見

プログレッシブディスカバリーの取り組みを始めてるんだ。サーバーが小さな入り口を提供して、会話が狭まるにつれてカタログのもっと多くを見せる感じ。ちょっと遅れて参加した気分。今までいくつかのハーネスでMCPのレイジーローディングを実装してきたけど、これからは全部コードモードで実装するつもり。

└

「コードモード」ってどういう意味？

└

コードモードに+1。ランタイムパフォーマンスや、複雑なロジックでたくさんのツールコールを調整する柔軟性、その他のいろんな利点がある。今、個人的なものをcloudflare-osの自己ホスト版に切り替えてるところなんだ。cloudflareの「ローカルファイルなし」のパラダイムに合わせるために、いろいろと再設計が必要だけど、今のところ、彼らが操作できるコンテナのゲートキーパーを持っていて、リポジトリをチェックアウトできるようにしてる。

どれだけのMCPサーバーがこれを実装するのか、めっちゃ気になる。「今日のMCP認証は、ブラウザでアクセスを承認する人に基づいて構築されている。インタラクティブなクライアントにはうまくいくけど、呼び出し元のエージェントは、自分のアイデンティティを持ってクラウドワークロードとして動いていることが増えてきてる。ユーザーが不在の状態で、サブエージェントに狭い権限を委譲することもある。MCPサーバーには、既存の標準に基づいて、これらのエージェントのアイデンティティを認識し、信頼するための標準化された方法が必要だ。APIキーや長期トークンを貼り付けるのではなくね。ここでの作業は、所有権の証明（DPoP）の最終化とその採用を進めること、エージェントアイデンティティと委譲のための意見を持った道筋を定義することを含む。これは、エンタープライズ管理認証の背後にあるID-JAG助成金や標準トークン交換を通じて行われる。OAuthの標準団体、IETF OAuthやWIMSE作業部会との関わりも続けていくつもりだ。エージェントアイデンティティに必要なビルディングブロックで、基盤となる標準が進化できるようにね。」

└

今でも、MCPサーバー自体がすべてのセキュリティオプションを実装する必要はないよ。agentgatewayみたいなもので、MCPサーバーの認証プロキシとして機能させることができる。

└

まさに過剰設計の例だね。なんでOAuthを使わないの？

└

方向性としては、みんなそうだよ。彼らが言ってることは明らかに正しい。ブラウザで手動でクリックするのはボトルネックだし、真剣なユーザーにはますます受け入れられなくなるだろうね。そして、その移行に伴う個別の作業はエージェントがやることになる。

└

同意。どうやら2つの流れがあって、それが分岐したり合流したりする可能性があるみたい？1つ目は、ワークロードが既存の認証情報を使ってRFC 7523とOIDCディスカバリーをサポートすること。「すでに確立された信頼（認証情報）を信じる」って感じ。基本的には現在の主要なNHIパラダイムを拡張するってこと。2つ目は、DPoPが各リクエストに対して署名された証明を義務付けること。だから、認証情報をクライアントが持つキーや特定のリクエストの詳細やコンテキストに結びつけるってこと。#1でスケールできるのか、それとも分岐するのか（例えば、#1の方法のほとんどがDPoP用に設計されてないからとか）？

└

できればたくさんあればいいな。完全に機能するエージェントのアイデアが大好きで、人間が介入する瞬間を減らせるのがいいよね。例えば、https://projects.dev/みたいなもの。たくさんのセキュリティ問題や他の課題があるけど、これが未来の方向性だと思ってる。

└

サブエンティティのための認可が必要だね。エージェントが自分の代わりに何ができるかを定義するのは面倒だし、特化したエージェントが増えると特にそう。パターンベースだとAIが簡単に攻略できちゃうけど、役割に基づいて権限を制限するサービス独立の方法が必要だと思う。私はジャックの右耳 - すごい、いろんなことが聞けるね。私はジャックの右手 - いいね、いろいろ入力できるね。

└

正直、仕様がややこしすぎると思う。長期間使える認証トークンを追加して、それをMCPの設定にヘッダーとして入れて送信すればいいだけなのに、特別なルールが増えるのは避けられる。「ああ、長生きするトークンはダメだ」って言うけど、1Password CLIみたいなシークレットマネージャーに入れれば、エージェントを始められるのに…。

└

そのすべてを約束するプロトコルに取り組んでるんだ。現在、来週のNOSTR/Buzzデモを概念実証として目指しているところ。

Hacker Newsで議論の続きを見る

ハクソク