MCP新ロードマップを解説｜2026年後半の5つの重点領域・エージェントID・エンタープライズ認可【2026年8月最新】

MCP（Model Context Protocol）は2026年8月22日、公式ロードマップを更新し、今後6〜12か月の重点領域を5つ提示しました。示された方向性は、「人がブラウザの前で毎回承認しながらAIに道具を使わせる規格」から、「企業の本番環境で、人が張り付いていなくてもAIエージェントが安全に長時間動くための基盤規格」への軸足の移動です。

この記事では、公式ロードマップと公式ブログ、そして土台となる2026-07-28版仕様を一次情報として、次の内容を整理します。

• 5つの重点領域それぞれの課題・担当ワーキンググループ・この期間の成果物
• エージェントID／エンタープライズ認可（DPoP・ID-JAG・Workload Identity Federation）が具体的に何を変えるのか
• 2026年3月版ロードマップ（4領域）との差分
• 非推奨になった機能と、既存MCPサーバー運用者が今日から動ける移行の考え方
• 「決まっていること」と「まだ検討段階のこと」の確度レベル

想定読者は、すでにMCPサーバー／クライアントを開発・運用している方、社内でのMCP導入を検討している情シス・セキュリティ担当の方です。MCPそのものの仕組みから知りたい方は、先にMCPとは？仕組み・できること・対応ツール・セキュリティ総合解説をご覧ください。

出典: Model Context Protocol 公式サイト

新ロードマップの要点3つ

1. 重点は「非同期」「HTTP一本化」「エージェントID」に集約された

5領域は Agentic Messaging Primitives（非同期メッセージングの整合）／HTTP-Native Transport Unification and Hardening（HTTPトランスポートの統一と堅牢化）／Agent Identity and Enterprise-Ready Security（エージェントIDと企業向けセキュリティ）／Improved Primitives（プリミティブの改善）／Improved SDK Developer Experience（SDK開発者体験の改善）。いずれも「エージェントが人の監視なしで、長時間、企業のポリシー下で動く」ことに紐づいています。

2. これは予定表ではなく、SEPの審査優先度を決めるフィルタ

公式は「Maintainer review time is scarce. We spend it here first.（メンテナーの審査時間は希少なので、まずここに使う）」と明記しています。5領域に該当する仕様提案（SEP）は優先審査（expedited review）を受けられ、領域外は却下されないものの待ち行列が長くなります。MCPに機能追加を提案したい企業にとっては、自社の課題をこの5領域にマッピングできるかどうかが通りやすさを左右します。

3. 公式は「確約ではない」と明言している

ロードマップ冒頭には「This roadmap reflects current thinking rather than firm commitments.（確約ではなく現時点の考えである）」という注意書きがあります。優先度は変わりうる、別の形で実装されうる、延期されうる、そしてロードマップに載っていない作業がリリースに含まれることもある、と書かれています。実装スケジュールとして受け取るべきではありません。

今回のロードマップは何なのか｜「予定表」ではなくSEPの優先審査フィルタ

出典: Model Context Protocol 公式ブログ

このロードマップの正体は、仕様拡張提案（SEP：Specification Enhancement Proposal）の審査優先度を決める仕組みです。ここを理解しないと、各領域の記述が「やりたいことリスト」に見えてしまいます。

公式が示しているルールは次の通りです。

• 5つの重点領域に該当するSEPは優先審査され、採択される可能性が最も高い
• 領域外のSEPは自動却下ではないが、待ち行列が長くなり、正当化のハードルが上がる
• SEPを書くなら、まず該当領域を特定し、対応するワーキンググループ（WG）に持ち込み、WGの支持を付けて提案するのが最速ルート
• 各領域には担当Core Maintainerが実名で明記され、Discordで誰でも接触できる

つまり、MCPに何かを足したい開発者や企業にとって、このページは「読み物」ではなく申請の通し方を示した手引きです。

用語の整理

MCPの議論は略語が多いため、主要な用語を整理しておきます。

前提｜2026-07-28仕様でMCPは「普通のHTTPワークロード」になった

新ロードマップは2026-07-28リリースの上に立っています。この仕様変更を知らないと、5領域が何を解こうとしているのかが見えません。特に大きい変更は次の通りです。

ここで起きたのは、「MCPは独自のセッション概念を持つプロトコル」から「HTTPのお作法に乗る普通のワークロード」への転換です。ロードマップの領域①②④は、この転換で生じたひずみ（非同期の答えが複数ある／stdioとHTTPで設計が二重化した／tools/call の戻り値が曖昧）を直す作業だと理解すると筋が通ります。

重点領域① Agentic Messaging Primitives｜「まだ終わってない」の答えを1つにする

課題は、「サーバーはまだ処理が終わっていない」を表す方法が3通り存在し、それぞれライフサイクル・キャンセルモデル・エラー面を共有していないことです。担当Core Maintainerは Caitie McCaffrey / Clare Liguori / Peter Alexander。

現在MCPには Tasks拡張、subscriptions/listen、進捗通知（progress notifications）という3つの概念があり、複数のWGにまたがってバラバラに育ってきました。公式はこれらを「compose できる（きれいに組み合わせられる）ようにしたい」と書いています。

この期間の成果物

これに加えて、Tasks（SEP-2663）の作業を継続し、将来的に拡張をコア仕様へ取り込む方向が示されています。

Tasks拡張の中身

長時間処理の扱いは実務への影響が大きい部分です。公式ドキュメントによれば、Tasks拡張は次のように動きます。

• 長時間処理では最終結果の代わりに永続的なタスクID（durable handle）を返し、クライアントは tasks/get でポーリングする
• ステータスは working / input_required / completed / failed / cancelled（後ろ3つは終端）
• 途中で入力が必要になると input_required になり、クライアントは tasks/update で応答する
• tasks/cancel は協調的キャンセルで、サーバーは停止義務を負わない
• 通知は notifications/tasks でプッシュできるが、既定はポーリング

ブロッキングより優れている理由として公式が挙げているのは、接続を長時間占有しないこと、クライアントがクラッシュ・再起動しても同じIDで再開できること、進捗が見えることの3点です。

Triggers & Events WGの実態

このWGは Clare Liguori（AWS）と Peter Alexander（Anthropic）がリードし、全トランスポートで成立する順序保証（ordering guarantees）付きの標準コールバック機構の策定をミッションにしています。週次30分の作業セッションを持ち、インキュベーション用リポジトリは experimental-ext-triggers-events。スコープ外はトランスポートのワイヤーフォーマットとセッションモデルの変更（Transports WG所管）、およびMCPに必要な範囲を超えた汎用pub/subです。

成功条件として、SEPの採択に加え、Tier-1 SDK 2つ以上でのリファレンス実装と適合テストのカバレッジが明示されています。「仕様だけ通って誰も実装しない」を避ける設計です。

重点領域② HTTP-Native Transport Unification and Hardening｜stdioの上でHTTPを話す

狙いは、トランスポートモデルを1本にし、その上に標準的なHTTPの作法を載せることです。担当Core Maintainerは Kurtis Van Gent / Nick Cooper。

出典: Model Context Protocol 公式サイト

2026-07-28リリースでリモートMCPサーバーが普通のHTTPワークロードになった結果、ヘッダーやステータスコードといったHTTP固有の仕組みにトランスポート情報を載せる度合いが増えました。公式が挙げているひずみは3つです。

• HTTPネイティブ機能を作るたびに、stdio専用の第2設計が必要になる（でないとローカルで動かない）
• SDKが2本のトランスポートパイプラインを維持することになる
• プロトコルメタデータがHTTPヘッダーとメッセージフィールドに二重化し、サーバーが相互検証を強いられる

この期間の成果物

これ以外の「その先」として、全サーフェスにわたる標準化されたエラーハンドリング、SEP-2575（ステートレス化）後のツールリストのcapability scoping、サーバーに設定オプションを安全に渡す方法が挙げられています。

なお、HTTP over stdio について公式の表現は "We believe we can use HTTP/2 over stdio"（できると考えている）であり、決定事項ではありません。ローカルでstdio接続のMCPサーバーを運用している方は、当面の設定変更は不要ですが、将来的にSDKのトランスポート実装が入れ替わる可能性は念頭に置いておくとよいでしょう。stdioでのローカル運用の具体例はClaude Code自体をMCPサーバーとして動かす方法で整理しています。

重点領域③ Agent Identity and Enterprise-Ready Security｜APIキー貼り付け運用からの脱却

出典: modelcontextprotocol GitHub SEP-1933

この領域が、企業導入を検討している読者にとって最も影響が大きい部分です。 担当Core Maintainerは Paul Carleton / Den Delimarsky（Microsoft）。

公式が認めている現状の欠陥

ロードマップには、次の趣旨がはっきり書かれています。

MCPの認可は、同意の時点でブラウザの前に人間がいることを前提にしている。しかし呼び出し側は次第にエージェントになっている——自分自身のアイデンティティを持つクラウドワークロードであったり、その場にいないユーザーの代理であったり、親より狭い権限を与えるべきサブエージェントを生成したりする。既存のMCPサーバーは、貼り付けたAPIキーと長命なリフレッシュトークンに頼っている。

「MCPサーバーの設定ファイルにAPIキーを直書きしている」という運用に心当たりがある方は多いはずです。公式がそれを現行仕様の構造的な欠陥として認めたのがこの領域の出発点です。

この期間の成果物

委譲で焦点となる技術として、公式は次の3つを名指ししています。

1. Workload Identity Federation（SEP-1933、現時点ではPR段階）
2. ID-JAG（Identity Assertion JWT Authorization Grant） — Enterprise-Managed Authorization拡張で使われているもの
3. RFC 8693 トークン交換（Token Exchange）

いずれも IETF の OAuth WG および WIMSE WG と協調して進めるとされています。MCP独自の認可仕様を作るのではなく、既存の業界標準に寄せる方針である点は、企業のセキュリティ評価上プラスに働きます。

さらに、WG組成に伴ってスコープに入りうる論点として、human-presence attestation（人間存在の証明）——対話型クライアントとヘッドレスエージェントを見分ける仕組み——が挙がっています。

DPoPとは何か

DPoP（RFC 9449）は、OAuthのアクセストークンを「鍵の持ち主」に縛りつける仕組みです。

従来のBearerトークンは「持っていれば使える」ため、ログやプロキシ、メモリダンプから漏れた時点で攻撃者がそのまま使えてしまいます。DPoPでは、クライアントが公開鍵／秘密鍵ペアを持ち、HTTPリクエストごとに秘密鍵で署名した DPoPヘッダー（JWT） を付けます。認可サーバーは発行するトークンをその公開鍵にバインドするため、トークンだけ盗んでも鍵がない攻撃者には使えません。

エージェントは長時間動き、多数のサーバーにトークンを提示するため、トークン漏洩の面積が人間の利用より広くなります。DPoPが重点項目に入っているのは、この面積を潰しにいくためです。

ただし注意点があります。MCP向けのDPoPプロファイル（SEP-1932）は2025年12月5日にオープンされましたが、2026年8月上旬時点の第三者確認では未マージです。ロードマップの表現も「仕様をfinalizeして採用を進める」段階であり、具体的なリリース時期は公式に示されていません。

AWSのように、既存のIAM／監査基盤とMCPを接続するアプローチを先行して提供しているベンダーもあります。企業導入の実装例としてはAWS MCP Server 一般提供開始まとめ｜IAM認証・CloudTrail監査が参考になります。

エンタープライズ認可はどう変わるか｜ID-JAGによる集中管理

すでに公式拡張として存在する Enterprise-Managed Authorization が、領域③の到達点のプロトタイプです。 識別子は io.modelcontextprotocol/enterprise-managed-authorization で、stable仕様が公開されています。

出典: Model Context Protocol 公式サイト

解決しようとしている企業側の痛み

• 従業員が使うMCPサーバー1つ1つの認可仕様を、情シスが個別に理解する必要がある
• 各ユーザーが個別に認可するため、セキュリティチームが一貫したアクセスポリシーを強制できない
• 入社時、数十のサービスを手動で認可させる必要がある
• 退職時、サービスごとに個別の失効処理が必要になる

ID-JAGフローの流れ

① ユーザーがブラウザ経由で企業IdP（Okta / Microsoft Entra ID など）にログイン
      ↓  MCPクライアントがID Tokenを保存
② MCPクライアントが ID Token を ID-JAG に交換
      ↓  このときIdPがアクセスポリシーを評価する
③ ID-JAG を MCP Authorization Server に提示してアクセストークンを取得
      ↓
④ 以降、アクセストークンで MCP Resource Server を呼び出す

重要なのは②です。アクセス可否の判断が、MCPサーバー側ではなく企業IdP側で行われます。 権限のない従業員には、そもそもトークンが発行されません。

企業にとっての4つの効果

実装側に求められること

注意点として、MCPの拡張は常にデフォルト無効で、開発者の明示的なオプトインが必要です。対応状況はクライアントごとに異なるため、導入検討時は公式のクライアント対応表で確認する必要があります。

重点領域④ Improved Primitives｜tools/callの再設計と漸進的ディスカバリ

プロトコルの基礎部分である tools/call に手を入れる決断がなされた領域です。 担当Core Maintainerは Kurtis Van Gent / Peter Alexander / Den Delimarsky。

課題は2つ挙げられています。1つは tools/call が content と structuredContent を同時に返せてしまうため、サーバー実装者・クライアント実装者双方を混乱させ、実装が分岐してしまったこと。もう1つは、「大量のツール・リソースをクライアントに提示する際のガイド手段が足りない」という声がコミュニティから繰り返し出ていることです。

この期間の成果物

progressive discovery は、「MCPサーバーを増やすとコンテキストウィンドウがツール定義で埋まる」問題への公式の回答です。 現状は接続時に全ツールのスキーマを読み込むため、10個のMCPサーバーをつなぐと数万トークンがツール定義で消えるという事態が起きます。必要になったときだけ学習する方式に変われば、多数のサーバーを常時つないだままにする運用が現実的になります。実際に複数のMCPサーバーを併用する構成はClaude Code MCP連携ガイド｜GitHub・Slack・Notion・freee統合で扱っています。

また、File Uploads WG がスコープ付きファイル操作とファイルシステム的なリソースセマンティクス（レンジ読み取り、階層リスト）の作業を継続します。

重点領域⑤ Improved SDK Developer Experience｜仕様からSDKを生成する実験

出典: modelcontextprotocol/python-sdk (GitHub)

手作業でのSDKメンテナンスが限界に来たことを受けて、新規に追加された領域です。 担当Core Maintainerは Den Delimarsky / David Soria Parra。

出典: modelcontextprotocol GitHub Organization

公式の問題意識は明快です。SDK・リファレンスサーバー・クイックスタートがすべて手作業でメンテされており、リリースのたびに「壊れてから直す」状態になっている。これを、仕様と人間がレビューした適合テストスイートを source of truth（真実の源）とし、そこから成果物を導出して「毎リリースで再生成・再検証される」状態にしたい、というものです。

この期間の成果物

背景となるSDK Tier制度

領域⑤を理解するには、MCPが2026年2月に公開したSDKのTier制度を知っておく必要があります。

降格ルールも定められており、最新安定版で適合テストが4週間連続で失敗すると降格対象になります（Tier1→2は1つでも失敗、Tier2→3は20%超の失敗）。Issue放置が2か月続いた場合も降格対象です。適合テストは2026年1月23日に提供開始、公式SDK Tier表は2026年2月23日に公開されました。

この厳しさが手作業では維持できないため、生成に切り替えたいという流れです。なお、Tasks や MCP Apps などの実験的機能・拡張は、どのTierでも実装が必須ではありません。

2026年3月版ロードマップとの差分｜4領域から5領域へ

前版（2026年3月9日公開）と並べると、MCPが何を「終わった」と判断し、何を新たに問題視したのかが見えます。

読み取れる4つの変化

1. 「Governance Maturation（ガバナンス成熟）」が独立領域から外れた

2026-07-28リリースで Contributor Ladder と機能ライフサイクル方針が形式化され、一段落したためと考えられます。ガバナンスが「作るもの」から「回すもの」に移ったということです。

2. 「Enterprise Readiness」が「Agent Identity and Enterprise-Ready Security」に進化した

前版は「監査証跡」「SSO統合」という一般論でしたが、新版は DPoP／Workload Identity Federation／ID-JAG／RFC 8693 という具体的な標準の名指しに変わりました。抽象的な目標から、実装可能な仕様の選定フェーズに入ったことを意味します。

3. 「Improved SDK Developer Experience」が新規追加された

エコシステムが巨大化し、手作業メンテが限界に来たことの表れです。TypeScript / Python SDKの月間ダウンロードは2026年3月25日時点で9,700万を超えたという集計もあります（MCP Dev Summit 2026関連レポート）。数字は出典によって幅がありますが、規模の桁が変わったことは確かです。

4. 「Improved Primitives」が新規追加された

プロトコルの基礎部分（tools/call）に手を入れる決断がなされ、ツール数の爆発への対処（progressive discovery）が公式アジェンダに乗りました。現場の運用課題が仕様レベルの議題に昇格した形です。

非推奨になった機能と移行の考え方

既存のMCPサーバー運用者が今日から動ける、唯一の確定した実務項目がここです。 2026-07-28リリースで非推奨（Deprecated）になった機能を整理します。

期限の考え方

MCPは2026-07-28リリースで機能ライフサイクルと非推奨化ポリシーを採用しました（SEP-2596）。Active / Deprecated / Removed の3状態を定義し、最低12か月の非推奨化期間を保証しています。非推奨機能レジストリも用意されました。

したがって、非推奨化された機能は当面完全に動作します。慌てて全面改修する必要はありません。 ただし、次の2点は今から実行できます。

• 新規実装では非推奨機能を採用しない（Roots / Sampling / Logging に依存した設計を新たに書かない）
• 既存実装の依存を棚卸ししておく（どのサーバー・クライアントがHTTP+SSEやRootsに依存しているかのリストを作る）

そのほか、2026-07-28リリースの細かい変更として、クライアント資格情報は発行した認可サーバーに紐づき、別の認可サーバーで再利用禁止・変更時は再登録必須になりました（SEP-2352）。認可サーバーはRFC 9207に従い認可レスポンスに iss を含めるべきとされ、クライアントは記録済みissuerとの照合が必須です（SEP-2468）。認可周りを自前実装している場合は確認が必要です。

どこまで決まっているのか｜確度レベル早見表

ロードマップの内容は、確定度がバラバラです。ここを混同すると社内説明で誤った期待を生むため、レベル別に整理します。

特に誤解されやすい点を補足します。

出典: The Linux Foundation プレスリリース

ガバナンスについて補足すると、MCPは2024年11月にAnthropicが公開し、2025年12月にLinux Foundation傘下の Agentic AI Foundation（AAIF）へ寄贈されました。goose（Block）、AGENTS.md（OpenAI）と並ぶAAIFのアンカープロジェクトで、OpenAIも共同設立者として参加しています。一社の都合で仕様が変わる規格ではなくなったという点は、企業の技術選定において重要な前提です。標準化の広がりについてはAgent Plugins 1.0.0とは｜MCPとAgent Skillsを束ねる新標準でも触れています。

立場別に見た影響と今やるべきこと

同じロードマップでも、立場によって取るべき行動は大きく違います。

MCPサーバー運用者が最優先で確認すべき3点

1. HTTP+SSEを使っていないか — 2025年3月から非推奨で、今回Deprecatedに再分類されました。Streamable HTTPへの移行が明確な推奨です
2. Dynamic Client Registration（RFC 7591）に依存していないか — Client ID Metadata Documents への移行が推奨されています
3. APIキーを設定ファイルに直書きしていないか — 領域③が問題視している運用そのものです。標準仕様の確定を待つ間も、シークレット管理ツールへの移行は今から可能です

GitHub連携など具体的なMCPサーバーの運用についてはgithub-mcp-server（GitHub公式）の使い方も参考になります。

こんな人におすすめ／おすすめしない人

今回のロードマップを読み込む価値が高い人

• MCPサーバーを自社サービスとして提供している開発者 — トランスポート統一と tools/call 再設計は、将来の実装変更に直結します
• 社内でMCPを全社展開しようとしている情シス・セキュリティ担当 — エージェントIDとエンタープライズ認可は、稟議で必ず問われる論点への回答材料になります
• MCPに機能追加を提案したいベンダー・OSS開発者 — 5領域は提案の通りやすさを直接左右します
• AIエージェント基盤の技術選定をしている方 — MCPがどの水準の本番運用を想定しているかの目安になります

今すぐ読み込む必要が薄い人

• MCPをまだ使ったことがない方 — 先にMCPの基本を押さえたほうが効率的です。MCPとは？仕組み・できること・対応ツール・セキュリティ総合解説から始めてください
• Claude DesktopやCursorでMCPを個人利用しているだけの方 — 今回の内容は仕様・実装レイヤーの話が中心で、クライアント側が対応するまで利用体験は変わりません
• 数か月以内の導入判断を迫られている企業 — ロードマップは確約ではないため、判断材料は現行の2026-07-28仕様と既存の公式拡張（Enterprise-Managed Authorization など）で組み立てるべきです
• 具体的な実装スケジュールが必要な方 — 次期仕様リリース日は公式に示されていません

よくある質問

Q. 次のMCP仕様リリースはいつですか。

公式ロードマップに具体的な日付の記載はありません。MCPは2026年3月版ロードマップの時点で「リリースマイルストーン中心の計画をやめ、WG主導のタイムラインに移行する」と明言しています。オープン標準は予測しづらいという理由からで、日付を約束しない運用に切り替わっていると理解するのが正確です。

Q. DPoPは2026年中に使えるようになりますか。

現時点では未確定です。ロードマップは「仕様をfinalizeして広範な採用を目指す」段階と位置づけており、MCP向けDPoPプロファイル（SEP-1932）は2025年12月5日にオープンされたものの、2026年8月上旬時点の第三者確認では未マージです。最新状況は公式リポジトリで確認してください。

Q. Roots / Sampling を使っているサーバーは作り直しが必要ですか。

すぐに必要ではありません。MCPの機能ライフサイクル方針では最低12か月の非推奨化期間が定められており、その間は完全に機能します。ただし新規実装での採用は避けるべきで、RootsはツールパラメータやリソースURI、SamplingはLLMプロバイダAPIとの直接統合への置き換えが公式の移行案です。

Q. Enterprise-Managed Authorizationは今すぐ使えますか。

拡張自体はstable仕様として公開済みですが、MCPの拡張は常にデフォルト無効で明示的オプトインが必要であり、対応状況はクライアントごとに異なります。導入検討時は、利用するMCPクライアントと企業IdPの双方が対応しているかを公式のクライアント対応表で確認する必要があります。

Q. progressive discoveryが入れば、MCPサーバーを何個つないでも大丈夫になりますか。

方向性としてはその課題への対処ですが、現時点では「実験的なサーバー側ディスカバリ機構がどうあるべきかを定義する」段階です。Core Primitives WG自体がこの期間に組成される予定であり、仕様として確定していません。現状のコンテキスト圧迫は、接続するサーバーを絞る運用で対処するのが現実的です。

Q. このロードマップはAnthropicが決めているのですか。

いいえ。MCPは2025年12月にLinux Foundation傘下のAgentic AI Foundation（AAIF）へ寄贈されており、Core MaintainerにはAWS、Microsoftなど他社の技術者も含まれます。各重点領域の担当者も複数社にまたがっています。

Q. MCPの本番導入はどの程度進んでいますか。

公開MCPサーバーは10,000を超えたとLinux Foundationが発表しており、SDKのダウンロード数も急増しています。一方で、ソフトウェア業界の技術リーダーのうち「限定的にでも本番利用している」と答えたのは41%程度という調査結果もあり、セキュリティが企業導入の最大のブロッカーとされています。これらの第三者集計は出典によって数値に幅があるため、参考値として扱ってください。今回のロードマップが領域③にリソースを割いているのは、まさにこのブロッカーを外すためです。

まとめ

2026年8月22日に更新されたMCP公式ロードマップは、「エージェントが人の監視なしで、長時間、企業のポリシー下で動く」ための基盤整備に5領域を集中させるという宣言でした。

• ①非同期メッセージングの整合、②HTTPトランスポートの一本化、③エージェントIDと企業セキュリティ、④プリミティブの改善、⑤SDK開発者体験の改善
• このページはSEPの優先審査フィルタとして機能し、領域外の提案は待ち行列が長くなる
• 前版（4領域）からの最大の変化は、Enterprise ReadinessがDPoP・Workload Identity Federation・ID-JAG・RFC 8693という具体的な標準の名指しに進化したこと
• 公式は「確約ではない」と明記しており、実装スケジュールとして読むべきではない
• 一方で、非推奨機能（HTTP+SSE / Roots / Sampling / Logging / Dynamic Client Registration）の棚卸しと移行計画は、今日から着手できる確定した作業

MCPを今日から業務で使い始めたい方はClaude Code MCP連携ガイド｜GitHub・Slack・Notion・freee統合、MCPの全体像を確認したい方はMCPとは？仕組み・できること・対応ツール・セキュリティ総合解説をあわせてご覧ください。

参考（一次情報）

• MCP公式ロードマップ（2026-08-22更新）
• The New MCP Roadmap（公式ブログ）
• 仕様 2026-07-28 Changelog
• Enterprise-Managed Authorization 拡張
• Tasks 拡張 Overview
• SDK Tiering System
• RFC 9449（OAuth 2.0 DPoP）
• Linux Foundation: Agentic AI Foundation設立発表