MCPが「ブラウザ前提の認可」から離れようとしている

Model Context Protocol のロードマップが2026年8月22日に公開された。5つの優先領域が並んでいる。

5つ

エージェント同士のメッセージング基本要素。 長時間動くループ、サーバ側から結果を押し出す形、途中での方向修正。サーバ発のイベントと Tasks 拡張の成熟が挙がっている。

HTTP ネイティブなトランスポートの統一と堅牢化。 2026-07-28 仕様で入ったステートレス化を、stdio で動くローカルサーバを含む他の配置形態にも広げる。

エージェントのIDと、企業で使える securityへの対応。 MCP サーバがエージェントのIDを認識して信頼できるようにする。DPoP や Workload Identity Federation といった標準を通じて、ブラウザ前提の認可から、クラウドのワークロード向けへ移る、と書かれている。

基本要素の改善。 ツール結果の扱いの標準化と、段階的なツール探索。ツールカタログが増えたときの規模の問題に対応する。

SDK の開発体験。 各言語・各プラットフォームでの使い勝手、仕様への適合、ドキュメントの品質。

で、SEの実務ではどう使うか

3番目が実務にいちばん効く。

現在の MCP の認可は OAuth をブラウザで回す形が基本で、人間がブラウザでログインする前提になっている。バッチやサーバ常駐のワークロードだと、この前提が合わない。サービスアカウントの資格情報を持ち回るか、トークンを事前に取って置くかになり、どちらも監査で説明しにくい。

DPoP と Workload Identity Federation が入ると、「このエージェントが、この権限で」という粒度を、既存の企業ID基盤の語彙で表現できるようになる。クラウド側の IAM と接続しやすい。

いま設計するなら、認可の実装を薄く分けておくのが安い。 ロードマップに載っているということは、現在の形が置き換わるということでもある。認可の取り回しをアプリケーションのロジックに埋め込むと、移行時に全部触ることになる。

2番目のステートレス化が stdio まで広がる点も、運用の見通しに関わる。ローカルサーバとリモートサーバで接続の作法が揃えば、開発環境と本番環境の差が減る。逆に言えば、いま stdio 固有の前提に依存した作りにしていると、そこが差分になる。

なお 2026-07-28 仕様での廃止項目は、新しく定めた機能ライフサイクルと廃止方針に従った最初の例だと書かれている。今後の変更は、この方針の枠内で予告されることになる。

内容はすべて MCP のロードマップに記載されているものである。