■ 1. MCPロードマップの更新
- 新ロードマップの公開:
- Model Context Protocol の次期仕様リリース以降を対象とする更新版ロードマップを公開する
- 今後数か月のプロトコル作業の方向性を定めるものである
- 策定主体:
- Core Maintainers がメンテナのコミュニティおよび Working Group と共同で策定した
■ 2. 前ロードマップの成果
- 前回の4つの重点領域:
- 3月公開のロードマップはトランスポートの進化とスケーラビリティ、エージェント間通信を掲げた
- 加えてガバナンスの成熟、エンタープライズ対応を重点領域とした
- 過去5か月でこれら全てに大きな進展があった
- 変更の反映先:
- 大半の変更は 2026-07-28 の仕様リリースに含まれ、SDK とドキュメントにも反映済みである
- 内容は小規模な修正から大規模なプロトコル改修まで及ぶ
- セッションと初期化ハンドシェイクの廃止:
- プロトコルレベルのセッションと初期化ハンドシェイクを削除した(SEP-2575、SEP-2567)
- サーバは状態を保持せずに水平スケールできる
- 接続前ディスカバリの導入:
- クライアントは server/discover を呼び、何をするより先にサーバの対応バージョンと機能を把握できる
- リスト結果はキャッシュ可能になった(SEP-2549)
- Tasks の公式拡張化:
- アーリーアダプタのフィードバックに基づき Tasks を再設計し、公式拡張へ移した(SEP-2663)
- Multi Round-Trip Requests の新設:
- サーバ起点リクエストを置き換える新しいパターンである(SEP-2322)
- ステートレスなサーバでもエリシテーション等のフローが機能する
- Server Card の整備:
- Server Card Working Group が MCP サーバ向けの .well-known メタデータ規約の策定を継続している
- 接続することなくサーバを発見し評価できる状態を目指す
- ガバナンスの成熟:
- Contributor Ladder を正式に採用した
- Working Group が自領域の SEP をトリアージする体制へ移行した
- 仕様に機能ライフサイクルと非推奨ポリシーを定め、2026-07-28 の非推奨化が初の適用事例となった
- 認可まわりのセキュリティ強化:
- エンタープライズ対応は前サイクルでセキュリティに重点を置いた
- 想定どおり大半の成果は認可の改善として実現した
- issuer 検証、issuer に紐付くクライアントクレデンシャルを導入した
- Client ID Metadata Documents (CIMD) をクライアント登録の推奨経路とした
- Enterprise-Managed Authorization は拡張として提供し、こちらも安定版となった
- 進捗の総括:
- 極めて短期間での大きな前進であり、更新版ロードマップはここから引き継ぐ
■ 3. 5つの優先領域
- 領域構成:
- 新ロードマップは5つの優先領域で構成される
- エージェント的メッセージングのプリミティブ、HTTPネイティブなトランスポートの統一と堅牢化
- エージェントIDとエンタープライズ対応セキュリティ、プリミティブの改善、SDK 開発者体験の改善
- 前ロードマップからの格上げ:
- サーバ起点イベント、結果型の改善、エージェントIDは以前は将来課題として挙げていた
- 十分に成熟したため独立した優先領域へ格上げした
- 責任体制:
- 各領域に担当の Core Maintainers と1つ以上の Working Group を置く
■ 4. エージェント的メッセージングのプリミティブ
- 従来型パターンの限界:
- 現代のエージェント的ワークロードは標準的なリクエスト・レスポンス型に収まらない
- ループは長時間化し、サーバは結果をストリームで送出できる
- 実行中の作業を途中で操舵する明確な必要性がある
- これまでの拡充:
- Tasks、subscriptions/listen、進捗通知を導入してきた
- 適切なプリミティブを揃えるだけでなく、それらが相互にうまく組み合わさることを重視する
- 今後の作業:
- サーバ起点イベントとして webhook とチャネルを整備し、クライアントの結果ポーリングを不要にする
- Agents、Transports、Triggers & Events の各 Working Group を横断して合成のあり方をレビューする
- Tasks 拡張(SEP-2663)を成熟させ仕様本体へ取り込む
■ 5. HTTPネイティブなトランスポートの統一と堅牢化
- 通常のHTTPワークロード化:
- 2026-07-28 のリリースにより、リモート MCP サーバは他の HTTP ワークロードと変わらなくなった
- 開発者や組織が既に API やサービスで使うインフラ上で容易にホストし運用できる
- 適用範囲の拡大:
- この方式はスケールすることが実証済みであり、他のデプロイ形態にも広げる
- stdio 上で Streamable HTTP を話すローカルサーバも対象に含める
- 単一トランスポートへの統一:
- トランスポートを一本化することで MCP のサーバ開発とクライアント開発をさらに簡素化する
■ 6. エージェントIDとエンタープライズ対応セキュリティ
- 現行認可の前提:
- 現在の MCP 認可はブラウザ上で人がアクセスを承認する形を前提に組まれている
- 対話型クライアントには適するが、呼び出し元の実態は変化している
- 新たな呼び出し元:
- 自身のIDを持つクラウドワークロードとして動作するエージェントが増えている
- 不在のユーザに代わって行動する形態がある
- サブエージェントへより狭い権限を委譲する形態がある
- 目指す姿:
- MCP サーバがエージェントIDを認識し信頼する標準的な手段を持つべきである
- 貼り付けたAPIキーや長期有効トークンではなく既存標準の上に構築する
- 具体的な取り組み:
- Demonstrating Proof of Possession (DPoP) を確定させ、その普及を推進する
- Workload Identity Federation、Enterprise-Managed Authorization を支える ID-JAG グラント、標準的なトークン交換を用いる
- エージェントIDと権限委譲について明確な方針を持つ道筋を定義する
- 標準化団体との連携:
- IETF の OAuth および WIMSE ワーキンググループを含む OAuth 標準化団体との関与を拡大し続ける
- エージェントIDに必要な構成要素を基盤標準側の進化に反映させる
■ 7. プリミティブの改善
- ツール呼び出しの現状:
- ツール呼び出しは開発者が最初に触れる部分であり、プロトコルの歴史を通じて十分に機能してきた
- 結果処理の課題:
- tools/call のレスポンスは同一の出力を複数の形式で運べる
- どの形式がクライアントによってモデルに提示されるかをサーバ開発者は知る術がない
- 単一の明確な契約に標準化してこれを容易にする
- プリミティブの規模拡大:
- 100個のツールを持つサーバに接続すると、ユーザが何も尋ねないうちにモデルがその表面積すべてのコストを払う
- 一覧が長くなるほどツール選択の精度は低下する傾向にある
- プログレッシブディスカバリ:
- サーバが小さな入口を提示し、会話が絞り込まれるにつれてカタログを段階的に開示する
- この取り組みを新たに開始する
■ 8. SDK開発者体験の改善
- SDKの位置づけ:
- SDK は開発者が MCP を体験する場そのものである
- 使い勝手と仕様への適合性に投資する
- 対応する全プラットフォーム・全言語で直感的かつ十分に文書化された状態を目指す
- エージェント経由の開発:
- 多くの開発者はエージェントにライブラリを参照させて MCP クライアントやサーバを構築する
- 明快なAPIと正確なドキュメントが、摩擦なく動くコードになるか否かを決める
■ 9. 提案の優先順位付け
- 優先領域内のSEP:
- 優先領域に該当する Specification Enhancement Proposal は迅速なレビューを受ける
- 受理される可能性が最も高い
- 優先領域外のSEP:
- 自動的に却下されるわけではない
- メンテナのレビュー時間は希少であり、優先領域へ先に配分される
- 提案の進め方:
- 自分の SEP が属する優先領域を特定する
- 該当する Working Group に提起し、メンバーと協働して提案を練り上げる
- ロードマップの各領域は担当 Core Maintainers を明示しており、Discord で連絡できる
■ 10. 参加方法
- 参加の余地:
- すべての優先領域に Working Group が存在するか結成されつつある
- いずれも追加の貢献者を受け入れる余地がある
- Working Group への参加:
- Working and Interest Groups ページとコミュニティチャンネルを参照する
- SEP への関与:
- SEP ガイドラインを読んだ上で提案を作成するか、既存の提案に意見を寄せる
- 実験的拡張の開始:
- SEP-2133 により、任意の WG や IG は正式な SEP の前に experimental-ext- リポジトリで実験できる
- 直接的な貢献:
- contributing guide が仕様、SDK、ツール群への貢献方法を扱う