TL;DR

Model Context Protocol（MCP）の次期仕様 2026-07-28 リリース候補（RC）が公開され、プロトコル誕生以来最大の改訂 になった
核心は「ステートレス化」。Mcp-Session-Id と initialize/initialized ハンドシェイクが廃止され、どのサーバーインスタンスでも1リクエストを完結処理できるようになる
最終仕様は 2026年7月28日 に確定予定。検証期間は10週間（RCロックは5月21日）で、Tier 1 SDKはこの期間内の対応が求められる

はじめに

MCPは、LLMアプリケーションと外部データソース・ツールを繋ぐオープンプロトコルとして、Linux Foundation傘下でオープンソース開発が進んでいます¹。仕様本体のリポジトリ modelcontextprotocol/modelcontextprotocol は8.5kスターを集めており²、多数のクライアント・サーバーSDKがこの上に構築されています。

2026年7月、そのMCPにとって最大級の改訂となる次期仕様のリリース候補（RC）が公式ブログで発表されました¹。目玉は「ステートレス化」で、これまでサーバー側にセッション状態を持たせていた設計を根本から作り直しています。本記事では、公式ブログとSDKベータのリリースノートをもとに、変更点を実装レベルで整理します。

対象読者

MCPサーバー・クライアントを実装/運用している方
ロードバランサーやCDNの手前にMCPサーバーを置いている、または置く予定の方
2025-11-25 版の実験的Tasks機能を使っている方

なぜステートレス化が必要だったのか

従来のMCPは、クライアントが最初に initialize/initialized ハンドシェイクを行い、サーバーが発行した Mcp-Session-Id を以降の全リクエストに付与する設計でした。この方式では、同じセッションのリクエストを必ず同じサーバーインスタンスに届ける「スティッキールーティング」と、セッション状態を共有するストアが必要になります。ロードバランサーはリクエストボディを検査してMCPのメソッドを判別する必要があり、ふつうのHTTPインフラでは扱いにくい構成でした¹。

2026-07-28 仕様は、この前提を覆します。

変更点1: セッションレスなリクエスト設計

Mcp-Session-Id ヘッダーを廃止。プロトコルレベルのセッションという概念自体がなくなり、どのMCPリクエストもどのサーバーインスタンスに着地しても処理できるようになります¹。
クライアント情報・クライアント機能は、接続時に一度だけ交換するのではなく、_meta フィールドに載せて毎リクエスト送信 する方式に変わります¹。
Mcp-Method ヘッダーと Mcp-Name ヘッダー がStreamable HTTPのPOSTリクエストすべてに必須化されます。前者はリクエストが対象とするMCPメソッド、後者は操作対象のツール・リソース名を宣言し、ロードバランサーやCDNがボディを検査せずヘッダーだけでルーティング判定できるようにする狙いです¹。ヘッダーとボディの内容が食い違う場合、サーバーはリクエストを拒否します。

変更点2: server/discover メソッド

これまでの initialize ハンドシェイクに代わり、クライアントがサーバーの機能を必要なタイミングで取得できる新メソッド server/discover が追加されます¹。ステートレスかつキャッシュ可能な設計で、共有状態を必要としません。

あわせて tools/list のレスポンスには ttlMs（キャッシュ有効期限）と cacheScope（ユーザー間で共有可能かどうか） が追加されます。これはHTTPの Cache-Control ヘッダーをモデルにした設計で、クライアントはレスポンスをどれだけ長く、誰と共有してキャッシュしてよいかを正確に判断できるようになります¹。

変更点3: MCP AppsとTasks拡張

MCP Apps拡張: サーバーがインタラクティブなHTML UIテンプレートを事前宣言し、ホスト側はサンドボックス化されたiframe内でレンダリングします。ホストは実行を許可する前にUIを検査・キャッシュでき、UIとの通信も既存のJSON-RPCプロトコルに載るため、監査経路が統一されます¹。
Tasks拡張: 2025-11-25 版の実験的Tasks機能から大きく再設計されました。サーバーは tools/call に対してタスクハンドルを返せるようになり、クライアントは tasks/get・tasks/update・tasks/cancel でライフサイクルを操作します。ステートレス設計に合わせ、tasks/list は削除 されています¹。旧Tasks機能を使っている実装は新しいライフサイクルへの移行が必要です。

変更点4: 認可（OAuth/OpenID Connect）の刷新

認可まわりも複数の提案（SEP）で強化されます。公式ブログで挙げられている主な変更は以下の通りです¹。

変更	内容
`iss` パラメータ検証	RFC 9207準拠のissuer検証が必須化
`application_type` 宣言	動的クライアント登録時にOpenID Connectの `application_type` を明示
issuerバインディング	認可サーバーの `issuer` に認証情報を紐付け
リフレッシュトークン	OpenID Connect準拠サーバーからのリフレッシュトークン取得手順を文書化
スコープ蓄積	ステップアップ認証時のスコープ累積ルールを明確化

破壊的変更まとめ

項目	変更前 (`2025-11-25`)	変更後 (`2026-07-28`)
ハンドシェイク	`initialize`/`initialized`	`server/discover`（都度呼び出し可）
セッション	`Mcp-Session-Id` 必須	廃止・自己完結型リクエスト
ルーティング用ヘッダー	なし（ボディ検査が必要）	`Mcp-Method` / `Mcp-Name` 必須
リソース欠落エラー	MCPカスタム `-32002`	JSON-RPC標準 `-32602`
Tasks	実験的（`tasks/list` あり）	再設計（`tasks/list` 廃止）

さらに Roots・Sampling・Logging の3機能が非推奨 になります。Rootsはツールパラメータやリソース URI で、SamplingはLLMプロバイダーAPIとの直接統合で、Loggingはstderr出力やOpenTelemetryでの代替が案内されており、いずれも 12ヶ月の移行猶予期間 が設けられています¹。

移行スケジュールとSDK対応状況

RC（リリース候補）ロック: 2026年5月21日
最終仕様公開: 2026年7月28日
検証期間: 10週間（SDKメンテナーと実装者が実ワークロードで検証する期間）
Tier 1 SDK（公式一次サポート対象）はこの期間内での対応が求められます¹

TypeScript・PythonのSDKはすでにベータ版が公開されています³。

# TypeScript
npm install @modelcontextprotocol/server@beta
npm install @modelcontextprotocol/client@beta

# Python
uv add "mcp[cli]==2.0.0b1"

Python SDK v2の最小構成は以下の通りです³。

from mcp.server import MCPServer

mcp = MCPServer("Demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

TypeScript SDK v2も同様にシンプルです³。

import { McpServer } from "@modelcontextprotocol/server";
import * as z from "zod/v4";

const server = new McpServer({ name: "greeting-server", version: "1.0.0" });
server.registerTool("greet", {
  inputSchema: z.object({ name: z.string() }),
}, async ({ name }) => ({
  content: [{ type: "text", text: `Hello, ${name}!` }],
}));

公式ブログは「パブリックAPIはベータ版と安定版の間で変わる可能性がある」と明記しており、ベータ利用時はバージョンを固定することが推奨されています³。

著者視点の発見ポイント

公式ブログを読み解いて筆者が最も注目したのは、ステートレス化が単なる「セッション廃止」ではなく、ロードバランサー・CDNといった既存HTTPインフラをそのまま使える設計への転換 である点です。これまでMCPサーバーをスケールさせるには、スティッキールーティングや共有セッションストアといった、MCP専用の運用ノウハウが必要でした。Mcp-Method/Mcp-Name ヘッダーによるルーティングと tools/list のHTTPライクなキャッシュ制御は、既存のWebインフラの知見をほぼそのまま転用できる設計だと読めます。一方で、-32002 から -32602 へのエラーコード変更のように、クライアント側で文字列・数値リテラルの一致判定をしている実装は、10週間の検証期間中に静かに壊れる可能性があります。移行対象の実装では、まずTasks機能とエラーコードの直接比較箇所を洗い出すのが優先度が高いと考えられます。

まとめ

MCP 2026-07-28 仕様RCは、Mcp-Session-Id 廃止と server/discover メソッド追加により、プロトコルの中核をステートレス化する
Mcp-Method/Mcp-Name ヘッダーとキャッシュ制御(ttlMs/cacheScope)により、既存のHTTPロードバランサー・CDNがそのまま使えるようになる
Tasksは再設計、Roots・Sampling・Loggingは12ヶ月の猶予期間付きで非推奨に
最終仕様は2026年7月28日公開。TypeScript/Pythonのベータ版SDKで先行して変更内容を確認できる

参考リンク

The 2026-07-28 MCP Specification Release Candidate（公式ブログ） — 仕様変更の一次情報
Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here（公式ブログ） — SDKベータのインストール手順・コード例
modelcontextprotocol/modelcontextprotocol（GitHub） — 仕様本体リポジトリ

The 2026-07-28 MCP Specification Release Candidate（Model Context Protocol Blog） ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
modelcontextprotocol/modelcontextprotocol（GitHub、2026年7月時点でスター数8.5k） ↩
Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here（Model Context Protocol Blog） ↩ ↩² ↩³ ↩⁴