MCPが新ロードマップを発表、エージェント時代の5つの優先領域を提示
The New MCP Roadmap
Model Context Protocol（MCP）の公式ブログが、次期仕様リリース以降を見据えた更新版ロードマップを公開しました。ロードマップは5つの優先領域で構成され、エージェント向けメッセージングプリミティブ、HTTPネイティブトランスポートの統合と堅牢化、エージェントIDとエンタープライズ向けセキュリティ、プリミティブの改善、SDKの開発者体験向上に焦点を当てています。特に、サーバー起点のイベント、タスク拡張の仕様化、DPoPやWorkload Identity Federationによるエージェント認証の標準化などが注目されます。優先領域内のSEP（仕様拡張提案）は迅速にレビューされ、コミュニティの参加が呼びかけられています。
サーバーに100個のツールを接続すると、ユーザーが質問する前にモデルはその全表面に対してコストを支払うことになり、ツール選択はリストが長くなるにつれて悪化する傾向があります。
HNでの議論
26- rco8786
2026-07-28のリリースで、リモートMCPサーバーは他のHTTPワークロードと何ら変わりなくなりました。
良かった。専用の新しいプロトコルを導入したのは、MCPが初期リリースでやった中でも特に愚かなことの一つだった。
- izend
MCPサーバーのうち、実際にこれをすべて実装するものがどれだけあるのか、とても気になります。
「今日のMCPの認可は、人がブラウザでアクセスを承認することを中心に構築されています。これはインタラクティブなクライアントにはうまく機能しますが、呼び出し元の多くは、クラウドワークロードとして実行され、独自のIDを持ち、ユーザーに代わって行動する（その場にいないユーザーの）エージェント、またはサブエージェントに狭い権限を委任するエージェントになりつつあります。私たちは、MCPサーバーがそれらのエージェントIDを認識して信頼する標準化された方法を持てるようにしたいと考えています。それは、貼り付けられたAPIキーや長期トークンではなく、既存の標準に基づいて構築されるべきです。
この作業には、Proof of Possession（DPoP）の実証を確定してその採用を推進すること、Workload Identity Federation、Enterprise-Managed Authorizationの背後にあるID-JAGグラント、標準トークン交換を通じて、エージェントIDと委任のための意見のあるパスを定義することが含まれます。また、IETF OAuthやWIMSEワーキンググループを含むOAuth標準化団体との関与を引き続き拡大し、エージェントIDが必要とする構成要素で基盤となる標準が進化するのを支援します。」
- cube00
エージェントがRESTエンドポイントとskills.mdファイルを使うのと比べて、MCPエンドポイントの方が扱いやすいとは、依然として思えません。
- mmaunder
私の夢は、MCPが当社のような（サイバーセキュリティの）サービスに、認証付きの自己文書化エンドポイントを提供できるようにし、ユーザーにURLを渡すだけで、それがそのまま動くというものでした。その代わり、初日から、彼らが方向転換するにつれて複数の標準ができ、コンテキストを大量に消費する機能になり、場当たり的な修正のように感じられます。それが私にとってMCPというアイデアを台無しにし、ローカルツールとAPIでこれほど成功してきたので、戻るにはかなりの努力が必要です。
- mikeegg1
「MCP」と聞くと、今でも「マスターコントロールプログラム」と訳してしまいます。
- rglover
このアイデアが過度に複雑化されている度合いは困惑させられます。これはHTTPとWebSockets（必要ならSSEも）を中心にした比較的単純なパターンで解決できたはずです。
- vatsachak
モデルにプロンプトを与えるだけではどうでしょう？
LLMのあらゆる進歩は、計算効率の向上、アーキテクチャ、またはハーネスによるものです...
残りは飾りに過ぎないように思えます。
- skinfaxi
「サーバーが小さなエントリポイントを提供し、会話が絞り込まれるにつれてカタログの詳細を明らかにできるように、段階的なディスカバリの取り組みを開始しています。」
かなり遅れて来ましたね。私はすでにいくつかのハーネスでMCPの遅延読み込みを実装しなければなりませんでしたが、現在はすべてをコードモードとして実装する方向に移行しています。