0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

MCP次期仕様入門 — ステートレス化・server/discover・認可刷新の中身

0
Posted at

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傘下でオープンソース開発が進んでいます1。仕様本体のリポジトリ modelcontextprotocol/modelcontextprotocol は8.5kスターを集めており2、多数のクライアント・サーバーSDKがこの上に構築されています。

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

対象読者

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

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

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

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

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

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

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

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

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

変更点3: MCP AppsとTasks拡張

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

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

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

変更 内容
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ヶ月の移行猶予期間 が設けられています1。

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

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

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

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

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

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

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も同様にシンプルです3。

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はベータ版と安定版の間で変わる可能性がある」と明記しており、ベータ利用時はバージョンを固定することが推奨されています3。

著者視点の発見ポイント

公式ブログを読み解いて筆者が最も注目したのは、ステートレス化が単なる「セッション廃止」ではなく、ロードバランサー・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で先行して変更内容を確認できる

参考リンク

  1. The 2026-07-28 MCP Specification Release Candidate（Model Context Protocol Blog） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  2. modelcontextprotocol/modelcontextprotocol（GitHub、2026年7月時点でスター数8.5k） ↩

  3. Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here（Model Context Protocol Blog） ↩ ↩2 ↩3 ↩4

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?