MCPロードマップ刷新 「野良AIエージェント」の過剰権限をどう防ぐ：AIニュースピックアップ

AIモデルと外部ツールをつなぐ標準規格「MCP」のコアメンテナーが、更新版ロードマップを公開した。2026年7月の大規模改訂で土台を固めた次に、企業の本番環境での利用を見据えて取り組む5つの優先領域とは何か。

[ITmedia]

　AIモデルと外部のデータやツールを接続するオープン標準「Model Context Protocol」（MCP）のコアメンテナーは2026年8月22日（現地時間）、更新版のロードマップを公開した。次期仕様リリース以降の開発方針を示すもので、コアメンテナーがコミュニティーのメンテナーやワーキンググループと共同で策定した。

　MCPは2026年3月に、トランスポートの進化とスケーラビリティ、エージェント間通信、ガバナンスの成熟、エンタープライズ対応という4領域を掲げたロードマップを公開していた。その成果の多くは2026年7月28日公開の仕様に反映されている。プロトコルレベルのセッションと初期化のやりとりを廃止し、サーバが状態を保持せずに水平方向へ拡張できるようにしたのが最大の変更点だ。認可の面でも、発行者の検証やクライアント登録手順の見直しが加わった。

　一方で、長時間動き続けるAIエージェントをどう制御するか、人が承認画面を操作しない場面で権限をどう扱うかといった論点は残っている。新ロードマップは、これらにどう手を付けるのか。

MCPが次に狙う5領域とは

　新ロードマップが示した優先領域は、エージェント向けの通信の基本要素、トランスポートの統一、エージェントIDの標準化、ツール呼び出しの結果と規模の改善、SDKの開発者体験の向上という5つだ。各領域にはコアメンテナーと1つ以上のワーキンググループが割り当てられている。

　新ロードマップが掲げる優先領域は、以下の5つだ。

1. エージェント向けの通信の基本要素：1つの要求に1つの応答を返す従来の型では、長く回り続けるエージェントの処理に対応しきれない。サーバ起点のイベント（Webhookやチャネル）を扱えるようにし、クライアントが結果を問い合わせ続けずに済む形を目指す。非同期処理の仕組みである「Tasks」拡張を成熟させ、仕様本体へ取り込む作業も含む
2. HTTPネイティブなトランスポートの統一と堅牢化：2026年7月28日仕様によって、リモートのMCPサーバは他のHTTPワークロードと変わらない扱いになった。既存のAPI基盤にそのまま載せられる。今後はこの方式をローカル環境にも広げ、ローカルサーバが標準入出力（stdio）の上で「Streamable HTTP」を話せるようにする
3. エージェントIDとエンタープライズ向けセキュリティ：現状では、MCPの認可は、人がブラウザで承認する前提で組まれている。しかし呼び出し元は、独自のIDを持つクラウドワークロードとして動くエージェントや、その場にいない利用者の代わりに動くエージェント、限定的な権限を渡されたサブエージェントへと広がっている。APIキーの貼り付けや長期間有効なトークンに頼らず、既存の標準の上でエージェントのIDを識別して信頼できる仕組みを整える
4. 基本要素の改善：ツール呼び出しの応答が同じ出力を複数の形式で運べるため、サーバ開発者はどの形式がモデルに渡るかを判断できない。これを1つの契約に統一する。もう一つの課題は規模だ。100個のツールを持つサーバに接続すると、利用者が質問する前にモデルがその全体を読み込むコストを負う。ツールの数が増えるほど選択の精度も落ちる
5. SDKの開発者体験の向上：MCPの使い勝手はSDKで決まる。仕様への適合性と使いやすさに投資し、対応する全ての言語で文書を整える

　エージェントIDの領域では、通信相手が正規の保持者であることを示す「Demonstrating Proof of Possession」（DPoP、RFC 9449）の仕様確定と普及を進める。合わせて、ワークロードにIDを付与する「Workload Identity Federation」、企業のIDプロバイダー側でMCPサーバへのアクセスを一括管理する拡張「Enterprise-Managed Authorization」の基盤となるID-JAGグラント、標準的なトークン交換を組み合わせ、エージェントのIDと権限委譲の道筋を定める。インターネット技術の標準化団体であるIETFのOAuthワーキンググループやWIMSEワーキンググループとの連携も続ける。

　基本要素の改善では、サーバがまず小さな入り口だけを提示し、会話の焦点が絞られるにつれてツールの一覧を段階的に開示する「progressive discovery」の検討を始める。SDKについては、開発者がAIエージェントにライブラリを示してMCPクライアントやサーバを作らせる例が増えている点を挙げ、APIの明快さとドキュメントの正確さが動くコードになるかを左右すると説明している。

SEP審査は優先領域から

　MCPの仕様変更は「Specification Enhancement Proposal」（SEP）と呼ぶ提案を通じて進む。今回示した5領域に該当するSEPは審査が優先され、採択される可能性も高くなる。領域外の提案が自動的に却下されるわけではないものの、メンテナーのレビュー時間は限られており、優先領域へ先に配分される。

　MCPサーバを社内に立てる企業や、MCP対応の製品を選ぶ立場から見ると、今回のロードマップは「どの機能がいつ標準になるか」を読む材料になる。特にエージェントIDと認可の設計は、既存のIDプロバイダーやOAuth基盤との接続方針に直結する。仕様の確定を待つか、拡張として先行導入するかの判断が求められる。