ステートレス化、認可強化、拡張機能などMCPサーバーの最新動向を解説

• 
• シェア
• ツイートする
  一覧
• 

MCPの仕様がまた変わった——そう聞いて、本番運用への影響をまず確認したくなった方も多いのではないでしょうか。2026-07-28リリースは、Model Context Protocol（MCP）の登場以来最大級の改訂で、トランスポート、拡張機能、認可、ツールスキーマにまで一気に手が入りました（リリース発表）。

本番環境に近い形でMCPを運用しているなら、これは単なる機能追加ではなく、土台からの作り直しと言えるでしょう。この記事では何が変わったのか、そして実際の業務データに対してMCPを運用するチームにとって、それぞれの変更が何を意味するのかを解説します。

概要：MCP 2026-07-28リリースは、ステートレスなプロトコルコアを軸にMCPを再編成し、各機能はバージョン管理されたオプトイン型の拡張機能として提供されるようになりました。単一の巨大な仕様から、小さなコア＋拡張機能エコシステムへの転換です（リリース発表）。MCPサーバーを運用している場合、セッション、認可、ツールスキーマの扱いが変わります。ちょうど2026年に企業でのMCP導入が本格化しようとしているタイミングでの変更です。

MCP 2026-07-28リリースで何が変わったのか

今回の変更は、単体ではなく組み合わさって効いてきます。プロトコルコアがステートレスになったことで、サーバーからクライアントへのリクエストの形も変わりました。正式な拡張機能フレームワークが導入され、MCP AppsとTasksが最初の2つの公式拡張機能となっています。認可も強化され、ツールスキーマは完全なJSON Schema 2020-12標準に移行しました。そして従来のRoots、Sampling、Loggingといった機能は、廃止に向けた段階に入っています（リリース発表）。

仕様の詳細は公式発表と仕様書に譲り、本記事では各変更が実際の運用でどんな意味を持つのかに絞って解説します。MCPそのものが初めてという方は、まずMCPとは何か、なぜ重要なのかから読んでみてください。

今回の改訂がどれくらいの節目なのかは、これまでのバージョンの並びを見るとつかみやすくなります。MCPの仕様はおよそ4〜8か月おきに更新されてきました。

・2024-11-05：初版。Tools、Resources、Promptsといったコアアーキテクチャを定義
・2025-03-26：Streamable HTTPの導入と、OAuth 2.0による認証の整備
・2025-06-18：JSON-RPCバッチ処理の廃止と、構造化出力への対応
・2025-11-25：段階的なスコープ同意、アイコン表示、Tasksの実験的サポート
・2026-07-28：ステートレス化、拡張機能フレームワーク、認可強化、初期機能の非推奨化

並べてみると、これまでの4回が主に機能の追加と部分的な整理だったのに対して、今回だけはプロトコルの前提そのものを組み替えていることが分かります。

この「非推奨化」は少し丁寧に見ておく価値があります。「非推奨になった日」と「なくなる日」は同じではないからです。

一部の古い仕組みは、今回のリリースですでに置き換えられています。ただしRoots、Sampling、Loggingといった主要機能については、撤廃までに少なくとも12ヶ月の移行期間が設けられています（リリース発表）。実務上のポイントは、移行計画を立てる前に、自分たちが使っているSDKがまだ何をサポートしているかを確認することです。

この3機能には、それぞれ推奨される移行先があらかじめ示されています。Rootsはツールの入力パラメーター（inputSchema）やリソースURIへ、Samplingはクライアント側での制御やモデルプロバイダーAPIへの直接連携へ、Loggingは標準エラー出力やOpenTelemetryのような業界標準の観測性ツールへ、という整理です。あわせて全機能にActive → Deprecated → Removedという状態が定義されたため、今後の破壊的変更も事前に見通しやすくなりました。

ステートレス化とは？MCPの中核となる変更

これまでのMCPは、セッションをサーバー側に保持していました。クライアントが接続すると、サーバーがその接続を覚えておき、以降のリクエストは必ず同じインスタンスに戻ってくる必要があったのです。2026-07-28リリースは、この仕組みをやめます（リリース発表）。

これからは各リクエストに、サーバーが処理に必要な情報がすべて含まれます。そのため、どのインスタンスでもどのリクエストにも応答できるようになり、通常のWebサービスと同じ感覚でMCPサーバーをスケールできるようになります。これにより、以前指摘したステートフルなServer-Sent Events（SSE）の制約も解消されます。通信レベルの仕組みについては、ステートレスMCPを掘り下げた別記事を参照してください。業務向けAIにとってそれがなぜ重要かも、そちらで扱っています。

企業でMCPを運用する立場から見ると、ここが一番の恩恵です。クライアントをセッション開始時のインスタンスに固定する必要がなくなり、他のステートレスなインフラと同じようにスケールアウトやフェイルオーバーができるMCPサーバーになります。本番品質のAIエージェントをMCP上でどう設計するかについては、Production-ready なエージェント設計でリファレンスアーキテクチャとして整理しています。

ただし注意点はタイミングです。完全なステートレス化は、SDKやクライアント側の対応が完了して初めて実現します。実際に切り替わるときは破壊的変更になる可能性が高いため、ある日突然オンにするものというより、移行として計画しておくべきものでしょう。

この「まだ対応が追いついていない」状況は、手元でも確認できます。本記事の執筆時点（2026年7月29日）で、公式TypeScript SDKと、同時期に公開された新パッケージを調べた結果は次のとおりでした。

$ npm view @modelcontextprotocol/sdk version
1.30.0

$ npm view @modelcontextprotocol/sdk engines
{ node: '>=18' }

# 1.30.0 が認識するプロトコルバージョン（dist/cjs/types.js）
exports.LATEST_PROTOCOL_VERSION = '2025-11-25';
exports.SUPPORTED_PROTOCOL_VERSIONS = [
  LATEST_PROTOCOL_VERSION, '2025-06-18',
  '2025-03-26', '2024-11-05', '2024-10-07' ];

# 新しく切り出されたパッケージ
$ npm view @modelcontextprotocol/core version
2.0.0

$ npm view @modelcontextprotocol/core engines
{ node: '>=20' }

従来の@modelcontextprotocol/sdkが認識するプロトコルバージョンは、最新の1.30.0でも2025-11-25のままで、サポート一覧にも2026-07-28は含まれていません。新仕様への対応は@modelcontextprotocol/coreや@modelcontextprotocol/serverといった2.0.0系の別パッケージとして切り出されています。つまり移行はバージョンを上げるだけでは終わりません。依存パッケージの構成そのものを組み替える作業になり、Node.jsの要件も18以上から20以上へ上がっています。逆に言えば、今日動いているサーバーが明日壊れるわけでもありません。

この「仕様は出たがSDKはまだ」という時間差を、自社で埋めるか外に任せるかは判断の分かれ目です。CData Connect AIのようなマネージドのMCPレイヤーを使う場合、こうしたSDKの追従やパッケージ構成の組み替えはサービス側が吸収するため、自社チームはプロトコル改訂そのものを追いかけずに済みます。

ステートレス化にも限界はあります。一部のインタラクティブな機能は、サーバーがスケールアウトした後も正しく動作するために状態（ステート）に依存しており、その状態をどのインスタンスからも参照できる場所に置く必要が出てきます。

マルチラウンドトリップリクエストとは？

ステートレス化を実現するには、逆方向の問題も解決する必要があります。リクエストの途中で、サーバーがクライアントに何かを尋ねたい場面があるからです。不足している入力を補うためのelicitation（要求確認）プロンプトや、サンプリング呼び出しなどがこれにあたります。

従来の設計では、クライアントへ向けて長時間張ったままのServer-Sent Eventsストリームを開き、回答が届くまで状態を保持することで対応していました。ところがロードバランサー環境ではこれが破綻します。クライアントの回答が、待っているインスタンスとは別のインスタンスに届いてしまう可能性があるため、サーバー側でスティッキールーティングか共有ストレージによってギャップを埋める必要が生じるからです（SEP-2322）。

マルチラウンドトリップリクエスト（Multi Round-Trip Requests）は、このパターンを置き換えます。クライアントへの接続チャネルを開く代わりに、呼び出しの応答としてInputRequiredResult（入力が必要という結果）を返せるようになりました。ここにはサーバーからの追加質問と、サーバー自身の状態を表す不透明なトークンが含まれます。クライアントは回答し、そのトークンを添えて元の呼び出しを再送します。

サーバーが必要とする情報はすべてリクエストに載っているため、どのインスタンスでも処理を完了できます。これはサーバー起点のリクエストの動作を変える破壊的変更であり、それが許される範囲も狭くなります（リリース発表）。

企業のチームにとって、これはインタラクティブな機能を本番環境で使えるようにする変更です。SSE接続を保持できない、あるいはインスタンス間でセッション状態を共有できないリモートMCPサーバーでは、elicitationやサンプリングは事実上使えませんでした。マルチラウンドトリップリクエストにより、これらの機能を通常のステートレス・ロードバランス構成のインフラ上で動かせるようになります。代わりに、ステートレスコアへの移行と歩調を合わせて計画すべき、もう一つの破壊的変更が発生します。

拡張機能フレームワークとは？MCP AppsとTasks

コアそのものを肥大化させる代わりに、今回のリリースでは拡張機能フレームワークが追加されました。サーバーが任意に採用できる、バージョン管理されたオプション機能です。これにより、すべてのサーバーが全機能を抱え込まなくても、MCP全体としては機能を追加していけます（リリース発表）。MCP AppsとTasksが、最初の2つの公式拡張機能です。

MCP Appsを使うと、サーバーはツールの実行結果と合わせてホスト側がレンダリングする、小さなサンドボックス化されたインターフェースを提供できます（SEP-1865）。このインターフェースは事前に宣言されるため、セキュリティチームが公開前に審査できます。レンダリングされたインターフェースをユーザーに届ける前に、企業がまず必要とするのはこの審査ゲートです。業務データの多くでは、自由形式のインターフェースよりも、ソート可能なテーブルやストアドプロシージャ向けの入力フォームのほうが自然に合うでしょう。

Tasksは、時間のかかる処理を扱うための仕組みです。ジョブが終わるまで接続を張り続ける代わりに、ツールはチケットを返し、クライアントが後から状況を確認できるようにします（MCP Tasks extension）。

業務データを扱う現場では、時間のかかる処理はむしろ当たり前です。一括エクスポート、データウェアハウスのスキャン、システムをまたぐフェデレーテッドジョイン、長時間実行のストアドプロシージャは、いずれも1回のリクエストの時間予算を超えてしまいます。Tasksはこうした処理に標準的な形を与え、エージェントは長時間ジョブを開始し、後から結果を回収できるようになります。リクエストの途中でタイムアウトする心配もありません。

認可はどう強化されたのか？

「認可周りの変更」と聞くと、サーバーの作り直しを想像するかもしれません。ですが実際に強化が入るのは、サーバー側ではなくほとんどがクライアント側です。基本的な考え方自体は変わっていません。APIは自分を守っている認可サーバーがどれかを公開でき、クライアントは手動で設定される代わりに、その情報を発見して認証方法を判断します（RFC 9728）。

今回のリリースでは、この仕組みまわりのクライアント側チェックが厳格化されており、詳細はMCP authorization specにまとめられています。チームの立場からすると、これはNSAのMCPセキュリティアドバイザリーが指摘していたID・アクセス制御まわりのギャップに対する直接的な回答であり、対応が必要になるのは主にクライアント側です。

ただし、ハンドシェイクの部分は問題の半分でしかありません。より難しいのは、クライアントが認証を終えた後に何が起きるかです。アクセスが、ユーザーがデータソースのシステムで元々持っている権限をきちんと守っているか。そして、エージェントが実行するすべてのクエリを監査できるか。このガバナンスはプロトコルの外側にある話であり、本番運用するMCP環境であれば、どんな構成であってもこの基準はクリアしておくべきです。こうしたガバナンス要件を漏れなくチェックリスト化したい場合は、エンタープライズMCPガバナンス完全ガイドが参考になります。

ツールスキーマとJSON Schema 2020-12

MCPのツール定義は、以前からツールの入力をJSON Schemaで記述してきましたが、使えるのはその一部だけでした。今回のリリースでは完全なJSON Schema 2020-12標準を採用し、ツール作成者はツールが受け取る値・返す値をこれまでよりずっと精密に記述できます（リリース発表）。

標準そのものは新しくありません。新しいのは、その全体を使えるようになったことです。契約が厳密になれば、モデルがリカバリーしなければならない不正な形式のツール呼び出しは減り、本番環境での想定外の挙動も減ります。スキーマ設計の厳密さがAIの精度にどれだけ影響するかは、MCPサーバー設計の実証比較で数値とともに検証しています。

これはツール作成者にとって、「各ツールをどこまで厳密に規定するか」という実務的な問いを改めて投げかけます。制約を強めるほど不正な呼び出しを早い段階で捕捉できますが、契約自体が緩いデータソース向けにスキーマだけを過剰に厳密化しても、失敗はなくならず、むしろ下流に先送りされるだけです。つまり適切な厳密さのレベルは、全体で一律に決めるより、データソースごとに判断するほうが理にかなっています。

システムオブレコードの手前に立つツールにとって、この精密さはそのままコントロールの手段にもなります。スキーマを厳密にするほど、エージェントが本番システムに対して要求できることの範囲が狭まるからです。これは、企業がエージェントをリアルタイムデータのそばに置く前に確保しておきたいコントロールの範囲と言えるでしょう。

MCP本番採用環境において、このリリースの意味は？

全体を通して見ると、今回のリリースは本番システムがすでに必要としていたもの——ステートレスなスケーリング、オプトイン型の拡張機能、標準化された認可、そして精密なツール契約——を仕様として明文化したものです。本番サービスを運用したことがある人にとって、これらの要素自体はどれも目新しいものではありません。新しいのは、プロトコル側がそれに足並みを揃えたという点です。

このリリースの恩恵を最も受けやすいのは、すでに実際の業務データに対してMCPを運用しているチームです。仕様が明文化しているのは、まさに彼らがすでにぶつかってきた課題だからです。MCPサーバーをゼロから構築・運用する際の勘所は、MCPサーバーの構築・運用ガイドで詳しく解説しています。

Gartnerは、2027年末までにエージェント型AIプロジェクトの40%以上が中止になると予測しており、その主な理由はコスト、価値の不明確さ、そして統制の甘さです。生き残るプロジェクトは、ガバナンスの効いたデータアクセスを早い段階で「難しい部分」として扱ってきた傾向があります。今回のリリースを採用するチームは、本番環境で痛い目に遭いながら学び直す代わりに、その経験を最初から引き継げるのではないでしょうか。

業務データ向けにMCPの採用を検討しているなら、実務上の問いは「データソースごとに自分たちでMCPサーバーを構築・運用するか」、それとも「接続とガバナンスをまとめて引き受けてくれるマネージドMCPプラットフォームを採用するか」です。これは、2026年版MCPサーバーのベストプラクティスでも扱われているのと同じトレードオフです。

この判断は、すでに実務の場で分かれ始めています。国内のヘルスケア領域の専門商社では、5,100万件を超える商品マスタが300社以上のメーカー独自カテゴリで登録されており、粒度が細かすぎて傾向分析に使えない状態が続いていました。この企業が選んだのは、コミュニティ版のMCPサーバーではなく、SOC 2 Type IIなどのセキュリティ基準を満たすCData MCP Serverでした。基幹システムのREST APIをSQLとして抽象化することでLLMのハルシネーションリスクを抑え、追加開発なしにプロンプトだけで自動カテゴライズを実現しています。仕様がまだ動いている領域では、プロトコルへの追従を自社の外に出せるかどうかが、着手のしやすさをそのまま左右します。

各変更が自社チームにとって何を意味するか

CData Connect AIで本番品質のMCPを体験

業務データへの、ガバナンスの効いた安全な接続——これがMCPを本番運用する上で一番難しい部分であり、CData Connect AIはまさにそこのために作られています。1つのマネージドMCPレイヤーを通じて、AIクライアントは400種類以上のデータソースにアクセスできます。認証、データソースのシステム側の権限、クエリ監査はすべてConnect AI側で面倒を見ます。Connect AI MCPクイックスタートから始めれば、数分でデータソースをAIクライアントに接続できます。

よくある質問

MCP 2026-07-28リリースとは何ですか？
MCPというプロトコルが登場して以来、最大級の改訂です。プロトコルのコアをステートレスにし、拡張機能フレームワークを正式に導入し（MCP AppsとTasksが最初の公式拡張機能）、認可を強化し、ツールスキーマを完全なJSON Schema 2020-12標準にアップグレードし、Roots、Sampling、Loggingの廃止を開始します（リリース発表）。

MCPは企業の本番環境で使える段階にありますか？
その方向に着実に近づいており、今回のリリースはその大きな理由の一つです。ステートレスなスケーリング、標準化された認可、精密なツール契約は、いずれも本番運用チームが求めてきたものです。ただし実際の準備度合いは、ガバナンスの効いたアクセス、監査可能なクエリ、そして長時間処理への現実的な答えを備えて、きちんと運用できるかどうかにかかっています。この点こそが、マネージドMCPプラットフォームと自前で構築するサーバーの違いが表れるところです。

ステートレス化への変更は、既存のMCPサーバーやクライアントを壊しますか？
従来のサーバー側セッション保持に依存していたものは壊れます。1つのインスタンスへのスティッキールーティングや、サーバーが接続を覚えていることを前提にしたクライアントなどです。すでにステートレスに作られているサーバーは考え方自体は共通していますが、今回のリリース固有のステートレスな仕組みを採用するのは、クライアントとSDK側の対応が成熟していくのに合わせて進める移行作業になります（リリース発表）。

MCP拡張機能とは何ですか？最初の公式拡張機能は何ですか？
拡張機能とは、サーバーが任意に採用できる、バージョン管理されたオプション機能のことです。すべてのサーバーが全機能を抱え込まなくても、MCP全体としては機能を拡張していけます。MCP Apps（ツールの実行結果と合わせてホストがレンダリングするサンドボックス化されたUI）とTasks（後から確認する時間のかかる処理）が、最初の2つの公式拡張機能です（リリース発表）。

MCPツールにはJSON Schema 2020-12が今後必須になりますか？
2026-07-28リリース以降、MCPはツールの入出力スキーマを完全なJSON Schema 2020-12方言に基づいて定義するようになり、2020-12がツール作成時の標準となります（リリース発表）。2020-12が許すすべての機能を使う必要はありませんが、完全な方言が使えるようになったことで、ツール作成者は入出力をこれまでよりずっと精密に記述でき、不正な形式のツール呼び出しも減ります。

このリリースで認可はどう変わりますか？
クライアント側のチェックが厳格化されます。クライアントは、正しい認可サーバーを自動的に見つけられる既存のディスカバリーモデル（OAuth 2.0 Protected Resource Metadata、RFC 9728）に加えて、トークンが想定していた認可サーバーから発行されたものであることを確認するようになります（RFC 9207準拠）（authorization spec；RFC 9728；RFC 9207）。

参考文献

1. Model Context Protocol. The 2026-07-28 MCP Specification Release Candidate.
2. Model Context Protocol. Authorization specification.
3. RFC 9728: OAuth 2.0 Protected Resource Metadata.
4. RFC 9207: OAuth 2.0 Authorization Server Issuer Identification.
5. JSON Schema. JSON Schema 2020-12.
6. Model Context Protocol. SEP-2575: Make MCP Stateless.
7. Model Context Protocol. SEP-2322: Multi Round-Trip Requests.
8. Model Context Protocol. SEP-1865: MCP Apps.
9. Model Context Protocol. MCP Tasks extension.
10. Over 40% of agentic AI projects will be canceled by end of 2027.

この記事の編集者は以下の記事もオススメしています

• sponsored

  個人の便利さから組織展開へ――ローカルMCPが直面する「ガバナンスとセキュリティの壁」

• sponsored

  kintoneデータを最強のAIコンテキストに　MCP活用で変わるAIエージェント開発とデータアクセスレイヤーの重要性

• デジタル

  MCPサーバーとは？AIと業務データをセキュアに接続する構築・運用ガイド