MCP7/28アップデート4つの変更点と既存サーバー移行の手順

この記事のまとめ

MCP（Model Context Protocol）の2026-07-28アップデートは、標準の歴史上で最大規模の改訂です。ステートレス化、スケーラビリティ向上、認証強化、拡張フレームワークの正式化という4つの柱で構成され、既存サーバーには12か月の非推奨期間を踏まえた段階移行が求められます。要点は次の通りです。

initializeハンドシェイクを廃止し、_metaとserver/discoverで自己完結型のやり取りに切り替わります。
subscriptions/listenへの統合とttlMs・cacheScopeにより、通知と一覧取得の負荷を減らせます。
OAuthの整理とEnterprise-Managed Authorization、ID-JAGで企業のID基盤に統合できます。
Tasks拡張が正式化され、Roots・Sampling・Loggingは非推奨となります。

MCP2026-07-28アップデートの全体像

MCPの基本と2026-07-28の位置づけ

MCPは、AIクライアントと外部のツールやデータをつなぐための共通ルールです。今回の2026-07-28は、そのルールの骨組みにあたる部分を大きく作り直した節目です。生成AIを実務で使い続けていると、ツール連携の仕組みがどれだけ重要かを実感します。MCPはまさにその「つなぎ目」を担う仕様であり、今回の改訂はその前提条件そのものを変えるものです。

2026年5月21日にリリース候補が確定し、7月28日付で正式仕様となりました。プロジェクトのメンテナーはこの改訂を、標準の歴史上で最大規模と位置づけています。実運用の広がりも大きく、公開されているMCPサーバーは1万を超え、SDKの月間ダウンロード数は9,700万を超えたとされています（参照*1）。私がAI導入支援をしている現場でも、MCPを使ったツール連携の問い合わせは明らかに増えています。普及期に入ったプロトコルが大規模改訂を迎えるというのは、関係者にとっては「対応しないと取り残される」というプレッシャーになります。

つまり、すでに本番運用が広がった状態で骨組みが刷新された、というのが今回の位置づけです。既存のサーバーやクライアントを持つ開発者にとっては、単なる機能追加ではなく、通信の前提そのものを見直す更新になります。生成AI導入プロジェクトで痛感しているのですが、こういった「前提の変更」は、個別の機能改善よりも影響範囲の見積もりが難しい。どこが変わったかより、何が変わっていないかを確認する作業から始めるべきです。

最大規模の改訂となった背景

改訂の背景には、これまでのMCPが抱えていた運用上の課題があります。とくにスケール時のふるまいと、複数インスタンスでの水平展開が焦点でした。これは生成AIを企業に導入する際に直面する典型的な壁と重なります。小規模で動くものが、本番スケールで崩れる。その原因の多くがステート管理の設計にあることは、AIシステムに限った話ではありません。

現行のMCPは既定でステートレスではなく、リクエストごとに独立して解釈できる作りにはなっていませんでした。負荷分散の観点では、状態を持つMCPを分散させる難しさが、スケーラビリティの最大の阻害要因として指摘されていました（参照*2）。ロードマップでも、Streamable HTTPは本番向けの土台になったものの、水平スケール、ステートレス運用、ミドルウェア対応で不足が見えてきたと整理されています（参照*3）。

こうした課題の積み重なりが、今回の大きな作り直しにつながっています。1つの機能改善ではなく、通信の前提から見直したのはそのためです。「便利だが本番では使いにくい」という状態をそのままにしておくと、普及が進んだときに技術的負債が一気に噴き出す。今回の改訂は、そのリスクに正面から向き合ったと見ています。

12か月の非推奨期間と移行スケジュール

非推奨となる機能には、猶予期間が設定されています。既存のサーバーがすぐに動かなくなるわけではなく、段階的に切り替えられる作りです。この12か月という設計判断は現実的だと思います。一気に切り替えを迫るより、現場が動ける余白を残す。ただし、猶予があると後回しにしがちなのも現実です。

Roots、Sampling、Loggingの非推奨は、このSEPを含む仕様バージョンから始まります。該当バージョンのリリースから1年以内にリリースされる仕様バージョンでは、これらの機能はそのまま動き続けます（参照*4）。

この12か月の窓が、実務では移行計画の基準になります。既存のクライアントやサーバーの棚卸しを進め、廃止対象の呼び出しを新しい方式に置き換える順番を決める材料として使えます。急な切り替えを避けつつ、期限までに移し終える計画を組みやすくなります。企業への導入支援でも同様ですが、猶予期間の初期に影響範囲を洗い出し、後半で実装する、という2段階の計画が現実的です。期限直前の対応は、品質検証の時間を圧迫します。

変更点1 ステートレス化とセッション廃止

initializeハンドシェイクの撤廃

最初の大きな変化は、接続開始時のやり取りが消えたことです。従来のような下準備の往復がなくなり、各リクエストが単独で成立します。接続のたびにハンドシェイクが走る設計は、小規模では問題になりにくいものの、同時接続が増えるとオーバーヘッドとして顕在化します。この変更はその根本を断つものです。

2026-07-28では、initializeとnotifications/initializedのハンドシェイクが取り除かれました。各リクエストは_meta.io.modelcontextprotocol配下にprotocolVersion、clientInfo、clientCapabilitiesを持ち、サーバーは状態を持たずに相手を検証できます。新設されたserver/discover RPCで、対応バージョンと能力を先に把握でき、discoverが失敗した場合、SDKは従来のinitializeにフォールバックします（参照*5）。

この変更で、リクエストは自己完結の形になります。接続ごとの初期状態を覚えずに済むため、ロードバランサーの背後に複数のサーバーインスタンスを並べる構成が組みやすくなります。私が見てきた生成AI活用プロジェクトでも、スケールアウトの設計は後回しにされやすい論点です。今回のステートレス化は、その設計を「最初から考える」ことを促す変更とも言えます。

_metaによる自己完結型リクエスト

_metaは、リクエストの素性をその場で伝えるための入れ物です。プロトコルの土台をステートレスに保つための鍵になっています。

真にステートレスなプロトコルでは、すべてのリクエストが単独で理解でき、それがシンプルさ、スケーラビリティ、信頼性につながると整理されています（参照*2）。またMCPにはプロトコルレベルのセッションが存在しないため、サーバーは接続ごとの暗黙の状態に頼って、あるツール呼び出しと次の呼び出しを結びつけることはできません。買い物カゴやブラウザーコンテキスト、DBトランザクションのように呼び出しをまたぐ状態が必要な場合、生成用ツールから明示的なハンドルを返し、以降の呼び出しではそのハンドルを引数として受け取る作りが推奨されます（参照*6）。

実務では、状態を持たせたい処理はハンドルを介した明示的な受け渡しに書き直す必要があります。暗黙のセッションに依存していた箇所を洗い出す作業が、移行の入り口になります。「どこで状態を持っているか」を言語化できていないと、移行作業の見積もりもできません。まずコードベースのセッション依存箇所を列挙するところから始めるのが現実的です。

server/discoverによる能力探索

server/discoverは、接続の最初にサーバーの素性を確かめるための呼び出しです。バージョン交渉と能力把握を1回で済ませられます。

仕様のスキーマでは、DiscoverResultにsupportedVersionsとcapabilities、cacheScopeが並びます。ClientCapabilities側では、experimental、sampling（contextとtools）、elicitation（formとurl）といった項目が定義されています（参照*7）。

クライアントは、この結果を見て接続先の対応範囲を判断できます。サポート外のバージョンや能力に依存した呼び出しを、事前に避ける設計に置き換えていく流れになります。

変更点2 スケーラビリティ向上の仕組み

subscriptions/listenへの統合

通知の受け取り方も整理されました。バラバラだった変更通知が、1本のストリームにまとまります。通知チャンネルが複数に分散していると、取りこぼしや順序の保証が難しくなります。1本に集約する設計は、運用負荷の観点でも合理的です。

従来のtools/list_changed、prompts/list_changed、resources/list_changed、resources/updatedといった通知は、単一の長寿命なsubscriptions/listenリクエストに置き換わりました。そのレスポンスストリームが、クライアントが購読を選んだすべての変更通知を多重化して流し、それぞれにio.modelcontextprotocol/subscriptionIdのタグが付きます（参照*5）。

購読の管理箇所が1つに集約されるため、通知の取りこぼしや重複への対処もひとまとめに考えられます。移行時は、購読の開始・停止と、サブスクリプションIDの割り当てを軸に書き換えます。

MRTRとキャッシュ可能な一覧結果

一覧の取り直しをどれだけ減らせるかは、大規模運用の鍵です。今回の改訂では、鮮度のヒントが仕様に組み込まれました。ポーリング削減は地味に見えますが、スケール時の効果は大きい。私がメディア運営で感じるのと同様、「無駄なリクエストをなくす」という発想は、システムのどこでも有効です。

tools/list、prompts/list、resources/list、resources/templates/list、resources/read、そしてserver/discoverの結果に、ttlMsとcacheScopeが追加されました。クライアントは鮮度の目安として尊重し、ポーリングを減らせます。共有の中継はcacheScopeを見て、応答をキャッシュしてよいかを判断します（参照*5）。

クライアントとプロキシで扱いを揃えれば、同じ一覧を何度も取り直す無駄が減ります。キャッシュの共有範囲は、cacheScopeがpublicかprivateかで切り分ける前提で設計します。

HTTPヘッダー標準化と中継最適化

中継サーバーやプロキシに配慮した設計も盛り込まれました。ヘッダー側に情報を出すことで、本文を開かずに扱えます。

Streamable HTTPトランスポートでは、本文の一部フィールドがHTTPヘッダー（Mcp-Method、Mcp-Name、Mcp-Protocol-Version、Mcp-Param-*）にも写されます。これにより、中継が本文を解析せずにルーティングや検査を行えるようになりました。本文が真の情報源であり、不一致はHeaderMismatchとして扱われます。

変更点3 認証強化と企業運用対応

OAuth認可の硬化ポイント

認可まわりも整理が進みました。実装のばらつきを減らし、扱いを統一する方向です。企業への生成AI導入を支援していると、認証・認可の設計が一番揉める箇所のひとつだと感じます。仕様レベルで統一の方向性が示されることは、現場の判断を楽にします。

OAuthでは、認可の開始処理がAuthorizationRequestに集約されました。メタデータの探索はresolve_metadataに改名され、由来（provenance）を返すようになりました。カスタムのOAuth HTTPエラーは、ボックス化されたソースエラーとして扱われます（参照*8）。

入口の関数と戻り値の形が固まったことで、SDKごとのばらつきを吸収しやすくなります。エラー処理も、原因のたどり方が一貫します。複数のSDKを使い分ける環境では、この統一がデバッグ効率に直結します。

Enterprise-Managed AuthorizationとID-JAG

企業運用では、社員一人ひとりが個別にサーバーを認可するやり方が限界になっていました。今回の拡張は、その入口を一本化するものです。生成AI導入を進める企業から相談を受けるとき、「誰がどのツールを使えるか」の管理が整備されていないケースは多い。個別認可の積み重ねは、あとから統制しようとしても手がつけられない状態になります。

Enterprise-Managed Authorization拡張（io.modelcontextprotocol/enterprise-managed-authorization）は、組織が既存のID基盤（IdP）を通じて、MCPサーバーへのアクセスを中央から統制できるようにします。従業員がサーバーごとに個別認可する代わりに、ITやセキュリティチームがアクセスポリシーを1か所で管理します。フローとしては、MCPクライアントがIdPから、Identity Assertion JWT Authorization Grant（ID-JAG）と呼ばれる特別なトークンを受け取り、それをMCPサーバーの認可サーバーでアクセストークンに交換します（参照*9）。米国のNSAとCISAは2026年6月2日、MCP向けのセキュリティ設計ガイダンスを共同で公開しました。MCPサーバーへの呼び出し元は毎回認証し、接続を丸ごと信頼するのではなく、個々のツール呼び出し単位で認可することを求めています（参照*1）。

変更点4 拡張フレームワークの正式化

Tasks拡張による長時間処理対応

すべてのツール呼び出しがすぐ返るわけではありません。長い処理を扱う仕組みが正式化されました。AIを使った業務自動化を実際に試すと、「処理が終わるまで待つ」という設計の限界にすぐぶつかります。非同期で動かし、後から結果を取りに行く仕組みは、実務上の必須要件です。

CIパイプライン、バッチ処理、人の承認のように、秒・分・それ以上かかる処理があります。MCP Tasksは、サーバーがブロッキングせずに耐久性のあるハンドルを返す仕組みで、クライアントは進捗をポーリングし、必要なら入力を渡し、再接続後に最終結果を取り出せます（参照*10）。

長時間処理の扱いが標準的な形にそろうため、独自実装で回避してきた部分を仕様に寄せられます。再接続をまたいだ結果の取り出しも、統一された手順で書けます。独自実装は短期的には速いですが、仕様が変わるたびに追従コストがかかります。標準に寄せる判断は、長期的な保守コストを下げます。

Roots・Sampling・Loggingの非推奨化

中核機能の一部が非推奨となりました。将来的な削除を見据えた作り替えが必要です。「まだ動く」と「推奨される」は別の話です。非推奨機能に依存したまま放置すると、次の改訂で急に動かなくなるリスクを抱えることになります。

このSEPで非推奨となるのは、Roots（roots/list、notifications/roots/list_changed）、Sampling（sampling/createMessage、ClientCapabilities.tasks.requests.sampling）、Logging（logging/setLevel、notifications/message）です（参照*4）。elicitation、sampling、rootsに関するサーバーからクライアントへの要求は、新しいJSON-RPCリクエストとして発行されなくなります。代わりに、tool・prompt・resourceのハンドラーがInputRequiredResultを返し、そのinputRequestsフィールドで要求を伝えます。クライアントは各要求を満たし、inputResponsesを埋めて元の呼び出しを再試行します（参照*5）。

既存MCPサーバー移行の手順と注意点

SDK別の移行ステップ

移行の入り口は、利用中のSDKごとに用意されています。まずは公式のガイドを起点にします。移行作業を始める前に、現状把握と影響範囲の洗い出しを先にやる。これは生成AI導入プロジェクトでも同じで、いきなり実装に入ると手戻りが大きくなります。

Rust側では、RMCP 3.0がMCP 2026-07-28に対応しました。2.xからアップグレードする前に、プロトコルの主要変更とRMCP 3.0の移行ガイドを確認するよう案内されています。セッションレスなStreamable HTTPでは、Mcp-Session-Id、独立したGETストリーム、DELETEによるセッション終了、Last-Event-IDによる再開といったセッション由来の要素が取り除かれます（参照*8）。TypeScript側では、SDK v2の最初のベータが2026-07-28仕様のサポートとともに公開されました。v1からのアップグレードはdocs/migration/upgrade-to-v2.md、2026-07-28の採用はdocs/migration/support-2026-07-28.mdの移行ガイドが案内されています（参照*11）。

まずは移行ガイドで差分を確認し、影響範囲の広い箇所から手を付ける進め方になります。優先順位をつけずに全部同時にやろうとすると、どこも中途半端になります。非推奨機能の利用箇所を一覧化してから、依存度の高い順に着手する進め方が現実的です。

レガシー互換とデュアル対応

いきなり全面切り替えは難しい場面が多いため、旧仕様との併存が現実的です。クライアント側から対応可否を見て使い分ける形にできます。これは生成AI導入の現場でも同じ発想で、「使えるところから使う」という段階的展開が定着への近道です。一斉移行を前提にした計画は、例外処理で崩れやすい。

Cloudflareが公開したAgents SDK v0.20.0は、MCP 2026-07-28のリリース候補に対して、クライアントとサーバーの両側で対応を追加しました。MCPクライアントマネージャーは@modelcontextprotocol/clientを使い、接続ごとにserver/discoverで2026-07-28への対応を確かめます。サーバーがステートレスプロトコルに対応していない場合、クライアントは同じ接続のまま従来のinitializeハンドシェイクで通信を続けます（参照*12）。

このやり方なら、サーバー群を一斉に更新しなくても、対応済みの箇所から順に恩恵を受けられます。移行の順番と、切り戻しの余地を残せます。切り戻しを設計しておくことは、移行そのものより重要な場面があります。うまくいかなかったときに戻せる状態を保ちながら進むのが、本番環境での原則です。

移行時のセキュリティ確認

移行のタイミングは、セキュリティを見直す好機でもあります。公開サーバーの脆弱性は、無視できない水準で報告されています。新しい仕様への移行作業は、コードを触る必然性が生まれる機会でもあります。セキュリティの棚卸しをそこに組み込まない手はありません。

Practical DevSecOpsは、2026年半ば時点で、SDKの月間ダウンロードが9,700万超、稼働している公開MCPサーバーが1万超という数字を公表しました。独立系のスキャンでは、悪用可能な欠陥を持つ公開サーバーの比率が、対象や条件により30%から82%まで分布したとしています。米国のNSAとCISAが共同で示した設計ガイダンスは、MCPサーバーの呼び出し元を毎回認証し、接続をまるごと信頼せず、個々のツール呼び出し単位で認可することを求めています（参照*1）。

おわりに

MCPの2026-07-28アップデートは、通信の前提そのものを作り直した節目です。ステートレス化、subscriptions/listenへの統合、認証の中央管理、Tasks拡張の正式化という4つの柱が、これからの本番運用の土台になります。生成AIのツール連携が広がるほど、その「つなぎ目」の設計が重要になります。今回の改訂は、その土台を本番スケールに耐えるものに作り直した、と見ています。

移行には12か月の窓が用意されています。SDKごとの移行ガイドを起点に、_metaとserver/discoverへの置き換え、購読の統合、OAuthとID-JAGへの寄せ替え、非推奨機能の棚卸しを、順を追って進めていく形になります。猶予があるうちに着手する。これは言葉にすると当たり前ですが、実行できる組織とできない組織の差が、こういった局面で出ます。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））