🔌 セッションと初期化ハンドシェイクを廃止したステートレス改訂 - MCP 2026-07-28

Model Context Protocol (MCP) の仕様改訂 2026-07-28 は、プロトコルレベルのセッションと初期化ハンドシェイクを廃止しました。リモート MCP サーバはスティッキールーティングと共有セッションストアから解放されます。

一方で、セッションが暗黙に引き受けていた責務（呼び出しをまたぐ状態、サーバ起点の対話、変更通知、一覧結果の鮮度管理）は、そのまま消えるわけではありません。すべてアプリケーション側の明示的な設計判断として表面化します。

本記事は前版 2025-11-25 からの差分を構造・データ・運用の順に整理し、「何が消えたか」ではなく「消えた責務をどこで引き受けるか」を軸に読み解きます。

調査日は 2026-07-27 です。この時点で仕様本文は docs/specification/draft/ 配下にあり、日付ディレクトリ 2026-07-28/ は未作成です。本文中の仕様リンクは draft を指します。

概要

この改訂の位置づけ

MCP の仕様は日付ベースのリビジョン番号で管理されています。リビジョン名は仕様が確定した日付そのものです。2026-07-28 は 2025-11-25 の次のメジャーリビジョンにあたります。

仕様は、リビジョンを 2 つの era（時代）に分類しています。

両方に対応する実装は Dual-era（両 era 対応）と呼ばれます。2026-07-28 は Modern era の最初のリビジョンです。

なぜステートレス化したのか

2025-11-25 までの Streamable HTTP は、initialize でセッションを確立し、以降のリクエストに Mcp-Session-Id ヘッダを付与する方式でした。このヘッダは、セッションを発行したサーバインスタンスにクライアントを固定します。

この固定（スティッキールーティング）には、運用上の制約がありました。

2026-07-28 はプロトコルレベルのセッションと Mcp-Session-Id ヘッダを廃止しました（SEP-2567）。あわせて initialize / notifications/initialized ハンドシェイクも廃止しました（SEP-2575）。

結果として、リクエストはそれぞれ自己完結します。各リクエストは _meta にプロトコルバージョンとクライアント能力を含みます。任意のサーバインスタンスが任意のリクエストを処理できます。従来スティッキーセッションと共有セッションストアを必要としたリモート MCP サーバが、通常のラウンドロビン型ロードバランサの背後で稼働できます。

サーバをまたぐ状態の保持自体は禁止されていません。状態が必要なサーバは、create_basket のようなツールで basket_id を発行し、以降のツール呼び出しにモデルが引数として渡す「明示ハンドル (explicit, server-minted handle)」パターンを使います。プロトコルが状態管理を肩代わりしなくなっただけであり、アプリケーションの状態管理自体は引き続き可能です。

リビジョン間の比較

2025-11-25 と 2026-07-28 の主要な違いを 7 つの観点で比較します。

削除 / 非推奨 / 拡張へ移動

用語を 3 分類で整理します。削除は仕様から取り除かれた項目です。非推奨は機能が引き続き動作する項目です。拡張へ移動はコア仕様から公式拡張へ移った項目です。

削除 (Removed)

非推奨 (Deprecated、機能は残る)

非推奨の各項目には、最低 12 ヶ月の猶予期間が設けられます。Roots・Sampling・Logging・DCR の最短削除時期は「2027-07-28 以降に公開される最初のリビジョン」です。

拡張へ移動 (Moved to extension)

Tasks の再設計では、ブロッキング方式の tasks/result を tasks/get によるポーリングへ置き換えました。クライアントから入力を送る tasks/update を新設しました。tasks/list は削除しました。サーバはリクエスト単位のオプトインなしにタスクハンドルを返せます。

RC 期間と GA

2026-07-28 の RC (Release Candidate) は 2026-05-21 にロックされました。最終仕様の GA (正式版) は 2026-07-28 です。ロックから GA まで約 10 週間の RC 期間が設けられています。

RC 期間の目的は、SDK メンテナとクライアント実装者による実運用ワークロードでの検証です。SDK tier system における Tier 1 SDK は、この RC 期間内にサポートを提供することが期待されています。

本改訂には破壊的変更が含まれます。RC 告知ブログは、これを標準的な進め方にはしない方針を明言しています。今回導入した機能ライフサイクルポリシー・拡張フレームワーク・適合性連動の SEP 承認プロセスの 3 つのガバナンス SEP により、今後のリビジョンではトランスポートやライフサイクルの実装を書き直さずに追随できることを見込んでいます。

特徴

2026-07-28 の主要な特徴を 7 点にまとめます。

• ステートレス化: プロトコルレベルのセッションと初期化ハンドシェイクを廃止しました（SEP-2567 / SEP-2575）。各リクエストが _meta でバージョンと能力を運ぶ自己完結型になりました。
• MRTR (Multi Round-Trip Requests): サーバ起点リクエストの代わりに、サーバが InputRequiredResult（resultType: "input_required"）を返し、クライアントが元のリクエストを再送する方式を導入しました（SEP-2322）。すべての結果に resultType フィールドが必須になりました。
• subscriptions/listen: HTTP GET エンドポイントと resources/subscribe / resources/unsubscribe を、単一の長寿命 POST ストリーム subscriptions/listen に統合しました（SEP-2575）。リクエストスコープの通知（notifications/progress など）は、このストリームではなく該当リクエストのレスポンスストリームに流れ続けます。
• キャッシュ制御: 結果に ttlMs と cacheScope を必須化する CacheableResult インタフェースを新設しました（SEP-2549）。tools/list の決定的な順序返却も SHOULD 化し、クライアント側キャッシュと LLM プロンプトキャッシュのヒット率向上を図りました。
• 拡張フレームワーク: ClientCapabilities / ServerCapabilities に extensions フィールドを追加しました。拡張はリバース DNS 形式の ID で識別され、独立したリポジトリで管理され、仕様本体とは別にバージョニングされます（SEP-2133）。MCP Apps と Tasks が、この枠組みでの最初の公式拡張です。
• 機能ライフサイクルポリシー: Active / Deprecated / Removed の 3 状態と、最低 12 ヶ月の非推奨期間を定めるガバナンスを採用しました（SEP-2596）。非推奨機能はレジストリで一覧管理されます。
• 認可強化: 認可サーバ側は RFC 9207 の iss パラメータを含めるべきとし、クライアント側は認可コード引換前に issuer 照合を MUST としました（SEP-2468）。動的クライアント登録時の application_type 指定を要求しました（SEP-837）。クライアント資格情報を発行元の認可サーバに束縛し、issuer 識別子でキーイングして永続化することを MUST としました（SEP-2352）。このほかリフレッシュトークン要求手順（SEP-2207）、ステップアップ時のスコープ蓄積の明確化（SEP-2350）、.well-known ディスカバリのサフィックス（SEP-2351）を含む、あわせて 6 件の認可関連 SEP が今回の改訂に含まれます。

構造

C4 model の 3 段階（システムコンテキスト / コンテナ / コンポーネント）で整理します。あわせて前版との構造差分と、代表的な 3 つのリクエストライフサイクルをシーケンス図で示します。

システムコンテキスト図

MCP クライアントと MCP サーバを対象システムとし、周囲のアクターと外部システムとの関係を示します。

コンテナ図

MCP サーバ側を分解します。ステートレス化により、ロードバランサはスティッキールーティングを不要とし、セッションストアは存在しません。

プロトコルレベルのセッションストアが存在しないため、どのインスタンスがリクエストを処理しても結果は変わりません。ロードバランサは接続状態を意識せずに分散できます。

コンポーネント図

サーバインスタンス内部を分解します。tools/call を例に、ヘッダ処理から結果返却までの内部コンポーネントを示します。

前版との構造差分図

セッションを前提とした旧構成と、ステートレスな新構成を並べます。

前版 2025-11-25

新版 2026-07-28

消えた要素は、セッションストア、スティッキールーティング、Mcp-Session-Id ヘッダ、HTTP GET 常設エンドポイント、Last-Event-ID によるストリーム再開の 5 つです。

リクエストライフサイクル

通常の tools/call

ヘッダと _meta を毎回運ぶ、最も基本的なリクエストです。

MRTR

サーバが追加入力を要求し、クライアントが元のリクエストを再送して応答します。

subscriptions/listen

クライアントがオプトインし、サーバが確認応答したうえで通知を配信し続けます。

データ

データ構造を、概念モデルと情報モデルの 2 段階で示します。両モデルは同じエンティティ集合を対象とします。

概念モデル

エンティティ間の所有関係と参照関係を示します。subgraph の入れ子は所有関係、矢印は参照または継承関係を表します。

リクエスト

結果

発見

購読

ツール・リソース・プロンプト

エラー

情報モデル

主要な属性を示します。継承は --|>、所有は多重度付きの *--、参照は多重度付きの --> で表します。

リクエスト

結果

発見

購読

ツール・リソース・プロンプト

エラー

エラーコード体系

MCP は JSON-RPC 2.0 の実装定義サーバエラー範囲（-32000 から -32099）を分割して運用します。

本改訂で導入・再採番したコードです。

-32002（2025-11-25 以前の resource not found）と -32042 は、将来のバージョンでも再利用しません。-32042（URL elicitation required）は、2025-11-25 で導入された URL モード elicitation 専用のコードです。URL モード elicitation は、サーバがブラウザで開く URL をクライアントに提示し、その完了を notifications/elicitation/complete で通知する方式でした。本改訂では完了通知と相関用の elicitationId がいずれも削除され、MRTR の再送で結果を知る方式に置き換わったため、このコードも役目を終えました。

_meta キー一覧

traceparent / tracestate / baggage は、_meta のリバース DNS プレフィックス規則の例外として、プレフィックス無しでそのまま使えます。

構築方法

対応の前提条件

既存実装を 2026-07-28 に対応させる前に、次の前提を確認します。

前版クライアント対応を捨てる場合は server/discover のみで十分です。対応する場合は initialize ハンドシェイクの並行実装が必要です。

SDK の対応状況

公式ブログ「SDK ベータ告知」（2026-06-29）によると、Tier 1 SDK 4 種（Python / TypeScript / Go / C#）すべてがベータで 2026-07-28 に対応しています。個別バージョンは各リポジトリのリリースとレジストリで確認しました（確認日 2026-07-27）。

導入判断のポイントです。

• どの SDK もベータ導入は明示的なオプトインです。無指定インストールでは安定版に留まります。
• ベータのバージョン番号は頻繁に更新されます。導入前に各レジストリで最新ベータを再確認してください。
• 2026-07-28 を実際にワイヤ上で話すかどうかは、SDK バージョンとは別の設定です。

SDK ごとのステートレス有効化

「SDK を上げること」と「ステートレスな 2026-07-28 を話すこと」は別の操作です。SDK ごとに有効化の入口が異なります。

Python は FastMCP が MCPServer に改称されました。デコレータ API は引き継がれます。

from mcp.server import MCPServer

mcp = MCPServer("Demo")


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

TypeScript は単一パッケージ @modelcontextprotocol/sdk を廃し、@modelcontextprotocol/server と @modelcontextprotocol/client に分割しました。ESM 専用で、Node.js 20 以降・Bun・Deno で動作します。ツールスキーマは Standard Schema に対応し、Zod v4・Valibot・ArkType などを選べます。

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

const server = new McpServer({ name: "greeting-server", version: "1.0.0" });

server.registerTool(
  "greet",
  {
    description: "Greet someone by name",
    inputSchema: z.object({ name: z.string() }),
  },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }],
  }),
);

TypeScript は v1 からの機械的な改名を codemod で処理できます。.tool() から registerTool への改称やエラー型の改称が対象です。

npx @modelcontextprotocol/codemod@beta v1-to-v2 .

TypeScript SDK は「v2 への移行」と「2026-07-28 の採用」を独立した 2 手順として扱います。v2 に上げてから、準備が整った時点で新リビジョンを有効化できます。

Go はモジュールパスを変えずにプレリリースタグを指定します。

go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1

各 SDK とも、ベータと安定版で公開 API が変わる可能性があるため、バージョンは正確に固定してください。

プロトコルバージョンの宣言方法

2026-07-28 にはネゴシエーションハンドシェイクがありません。バージョンは毎リクエストで宣言します。

役割分担は次のとおりです。

• HTTP では両方を送ります。ヘッダとボディの値は一致が必須です。不一致はサーバが 400 Bad Request と HeaderMismatch（-32020）で拒否します。
• STDIO にはヘッダ層がありません。_meta のみで宣言します。
• サーバが要求バージョンに対応しない場合、UnsupportedProtocolVersionError（-32022）を返します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2026-07-28", "2025-11-25"],
      "requested": "1900-01-01"
    }
  }
}

STDIO と Streamable HTTP のセットアップ差分

STDIO のセキュリティ制約として、サーバは stdout に MCP メッセージ以外を書き込んではいけません（MUST NOT）。ログは stderr に出します。

Streamable HTTP のセキュリティ制約として、サーバは Origin ヘッダを検証し、不正なら 403 Forbidden を返します（MUST）。

利用方法

必須パラメータ・ヘッダ一覧

個別の利用例に先立ち、リクエストが運ぶべきフィールドをまとめます。

server/discover の呼び出し

• サーバは MUST で実装します。
• クライアントは MAY で呼び出します。呼ばずに個別 RPC を直接呼び、UnsupportedProtocolVersionError をハンドリングする運用も可能です。
• レスポンスはキャッシュ対応（ttlMs / cacheScope）です。

リクエストです。

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

レスポンスです。

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {},
      "resources": {}
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "ExampleServer",
        "version": "1.0.0"
      }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

DiscoverResult の主要フィールドです。

通常のツール呼び出し

tools/call は毎リクエストでヘッダと _meta の両方を運びます。

JSON-RPC リクエストです。

{
  "jsonrpc": "2.0",
  "id": "call-tool-example",
  "method": "tools/call",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    },
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}

JSON-RPC レスポンスです。

{
  "jsonrpc": "2.0",
  "id": "call-tool-example",
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"
      }
    ],
    "isError": false
  }
}

HTTP の生リクエストです。ヘッダと _meta の対応関係が分かります。

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Seattle, WA"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Mcp-Name の値は params.name（resources/read では params.uri）のミラーです。両者は一致必須で、不一致はサーバが -32020（HeaderMismatch）で拒否します。

MRTR（Multi Round-Trip Requests）

前版の elicitation/create / sampling/createMessage / roots/list のような server-initiated request を置き換えるパターンです。サーバは独立した JSON-RPC リクエストを送らず、結果として InputRequiredResult を返します。

InputRequiredResult を返せるクライアントリクエストは次の 3 つに限られます。これ以外で返してはいけません（MUST NOT）。

サーバからの InputRequiredResult です。resultType の値は必ず "input_required"（スネークケース）です。

{
  "resultType": "input_required",
  "inputRequests": {
    "github_login": {
      "method": "elicitation/create",
      "params": {
        "message": "Please provide your GitHub username",
        "requestedSchema": {
          "type": "object",
          "properties": {
            "name": {
              "type": "string"
            }
          },
          "required": ["name"]
        }
      }
    },
    "capital_of_france": {
      "method": "sampling/createMessage",
      "params": {
        "messages": [
          {
            "role": "user",
            "content": {
              "type": "text",
              "text": "What is the capital of France?"
            }
          }
        ],
        "maxTokens": 100
      }
    }
  },
  "requestState": "eyJsb2NhdGlvbiI6Ik5ldyBZb3JrIn0"
}

クライアントが再送するリクエストの inputResponses です。この内容と、上記結果に含まれていた requestState の値をそのまま元のリクエストの params に追加して再送します。

{
  "github_login": {
    "action": "accept",
    "content": {
      "name": "octocat"
    }
  },
  "capital_of_france": {
    "role": "assistant",
    "content": {
      "type": "text",
      "text": "The capital of France is Paris."
    },
    "model": "claude-3-sonnet-20240307",
    "stopReason": "endTurn"
  }
}

サーバとクライアント双方の主要ルールです。

• サーバは inputRequests か requestState の少なくとも一方を MUST で含めます。
• サーバは、クライアントが能力宣言していない inputRequests（例: elicitation 未宣言なのに elicitation/create を要求）を MUST NOT で含めません。
• クライアントは requestState を MUST NOT で解釈・改変せず、そのまま echo します。
• 再送リクエストの JSON-RPC id は初回と MUST で異なる値にします（独立したリクエストのため）。
• requestState が認可・リソースアクセス・業務ロジックに影響する場合、サーバは MUST で完全性保護（HMAC・AEAD 等）を行います。改竄されても失敗するだけの場合のみ省略できます。

subscriptions/listen

前版の HTTP GET エンドポイントと resources/subscribe / resources/unsubscribe を置き換える、単一の長寿命ストリームです。

オプトインのフィールド（SubscriptionsListenRequestParams.notifications）です。

すべて任意です。指定しない種別はオプトインしなかったものとして扱われます。

リクエストです。

{
  "jsonrpc": "2.0",
  "id": "listen-1",
  "method": "subscriptions/listen",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    },
    "notifications": {
      "toolsListChanged": true,
      "resourceSubscriptions": ["file:///project/config.json"]
    }
  }
}

確認応答の通知です。サーバは MUST でこれを最初に送り、これより前に他の通知を MUST NOT で送りません。

{
  "jsonrpc": "2.0",
  "method": "notifications/subscriptions/acknowledged",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/subscriptionId": "listen-1"
    },
    "notifications": {
      "toolsListChanged": true,
      "resourceSubscriptions": ["file:///project/config.json"]
    }
  }
}

サーバがシャットダウン等で自発的に閉じる場合のレスポンスです。

{
  "resultType": "complete",
  "_meta": {
    "io.modelcontextprotocol/subscriptionId": "listen-1"
  }
}

io.modelcontextprotocol/subscriptionId の付き方です。

• 値は、その subscriptions/listen リクエストの JSON-RPC id そのものです。
• 確認応答・以降のすべての変更通知・終了時のレスポンスに、同じ subscriptionId が付きます。
• STDIO では全メッセージが単一チャネルを共有するため、クライアントは MUST でこのフィールドを使い、どの購読の通知かを判別します。
• notifications/progress と notifications/message はリクエストスコープの通知であり、subscriptions/listen のストリームには流れません。関連するリクエストのレスポンスストリーム側に流れ続けます。

明示ハンドル（explicit handle）パターン

セッション廃止後に、ショッピングカートやデータベーストランザクションのような跨ぎ状態を持つための設計パターンです。仕様本文はこれを非正規（non-normative）ガイダンスと明記しています。プロトコル自体にハンドルという概念はなく、ワイヤ上はただの文字列です。

以下は仕様本文に掲載された実装例です。

// tools/call リクエスト
{ "name": "create_basket", "arguments": {} }

// 結果
{
  "content": [{ "type": "text", "text": "Created basket bsk_a1b2c3" }],
  "structuredContent": { "basket_id": "bsk_a1b2c3" }
}

// 後続の tools/call リクエスト。ハンドルを引数として渡す
{
  "name": "add_item",
  "arguments": { "basket_id": "bsk_a1b2c3", "sku": "..." }
}

設計上の考慮点は「ベストプラクティス」の状態設計で扱います。

ログレベル指定

• ログレベルは _meta の io.modelcontextprotocol/logLevel でリクエスト単位に指定します。
• このフィールドを含まないリクエストに対して、サーバは notifications/message を MUST NOT で送出します。
• 前版の logging/setLevel RPC は削除されました。
• logLevel フィールド自体は Logging 機能の一部として Deprecated（SEP-2577）です。少なくとも 12 ヶ月は仕様に残り、機能します。新規実装では移行先（stderr または OpenTelemetry）の採用が推奨されます。

notifications/message の例です。

{
  "jsonrpc": "2.0",
  "method": "notifications/message",
  "params": {
    "level": "error",
    "logger": "database",
    "data": {
      "error": "Connection failed",
      "details": {
        "host": "localhost",
        "port": 5432
      }
    }
  }
}

後方互換の書き方

resultType の欠落時の扱いが後方互換の要です。

• サーバが 2026-07-28 を実装している場合、結果には MUST で resultType を含めます。
• クライアントが resultType を含まない結果を受け取った場合（前版のサーバから）、クライアントは MUST でそれを "complete" として扱います。

トランスポート別の後方互換プローブです。

フォールバック判定は特定のエラーコード 1 つに固定してはいけません（MUST NOT）。legacy サーバは未知の pre-initialize リクエストに対し実装依存のエラー（多くは -32601 か -32602）を返すか、無応答のことがあります。

クライアントとサーバの era 別互換性マトリクスです。

運用

水平分散とルーティング

2026-07-28 はプロトコルレベルのセッションを廃止しました（SEP-2567）。Mcp-Session-Id ヘッダは削除され、tools/list / resources/list / prompts/list は接続ごとに内容が変わりません。

• ロードバランサ・ゲートウェイは、スティッキールーティングが不要になります。
• Streamable HTTP の POST リクエストは、JSON-RPC ボディの一部を HTTP ヘッダにミラーリングする標準リクエストヘッダ（SEP-2243）を必須で運びます。

• 中間装置は JSON ボディをパースせずに、これらのヘッダだけで経路制御・レート制限ができます。
• サーバはヘッダ値とボディ値の不一致を MUST で検出し、400 Bad Request と -32020 HeaderMismatch を返します。ヘッダとボディで異なる情報源（LB はヘッダ、MCP サーバはボディ）を信頼する構成に対するセキュリティ対策でもあります。
• ツール引数由来のカスタムヘッダ拡張 x-mcp-header を使うと、Mcp-Param-{Name} という追加ヘッダを経路制御に使えます。

以下は仕様外の補完による実装例です。

# 実装例: Mcp-Method によるプール振り分け
map $http_mcp_method $backend_pool {
    "tools/call"     pool_tools;
    "resources/read" pool_resources;
    default          pool_default;
}

location /mcp {
    proxy_pass http://$backend_pool;
}

キャッシュ運用

CacheableResult インタフェース（SEP-2549）により、以下の 6 操作の結果には ttlMs と cacheScope が必須になります。

• server/discover
• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

changelog の要約文は 5 操作を列挙し server/discover を省いていますが、キャッシュ専用ページと server/discover のページはいずれも server/discover を対象に含めています。本稿は専用ページの記述を採ります。

resultType: "input_required" の中間結果はキャッシュ対象外です。

ttlMs（鮮度ヒント）の扱いです。

鮮度判定は now < t_received + ttlMs です。クライアントは TTL をポーリング間隔として使うべきではなく、必要になったタイミングで鮮度チェックし、stale なら再取得します。ポーリングを実装する場合はジッタとバックオフを MUST で付与します。

cacheScope（共有可否）の扱いです。

• 全ユーザーで同一のツール一覧・プロンプト一覧には "public" が適切です。
• 認証ユーザー依存の resources/read や、ユーザーごとにフィルタされた一覧結果には "private" が適切です。
• "public" は「認証済みエンドポイントの結果でも、異なるアクセストークンの呼び出し元同士で共有されうる」ことを意味します。サーバ実装者は cacheScope を認可制御の代わりに使ってはならず（MUST NOT）、primitive 単位のアクセス制御を別途適用する必要があります。

listChanged 通知との補完関係です。

• ttlMs のみを提供し listChanged: true を広告しない構成も可能です（TTL だけに依存）。
• 両方提供する構成では、TTL が不要な再取得を減らし、通知が即時無効化のシグナルとして働きます。fresh な期間中に関連通知を受信した場合、キャッシュは直ちに stale 扱いになります。

ページネーションとの関係です。

• ページごとに独立してキャッシュ可能で、ttlMs もページごとに異なってよいです。
• 同一リクエストの全ページで cacheScope は統一します（MUST）。
• カーソルが無効化された場合、クライアントは全キャッシュページを破棄し先頭から再取得すべきです（SHOULD）。

tools/list の決定的順序について、サーバは決定的な順序で返すことが SHOULD です。これはクライアント側キャッシュのヒット率だけでなく、ツール一覧がシステムプロンプトへ埋め込まれる用途で効きます。順序が安定するとプロンプトの先頭部分が変化せず、LLM 推論基盤側のプレフィックスキャッシュのヒット率向上にも寄与します。

可観測性

• OpenTelemetry トレースコンテキストの伝播規約（SEP-414）が _meta の予約キーとして文書化されました。traceparent / tracestate / baggage の 3 つです。
• これらのキーは _meta のリバース DNS プレフィックス規則の例外として、プレフィックス無しでそのまま使えます。値は W3C Trace Context / W3C Baggage の形式に従う必要があります。

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": {
      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"
    }
  }
}

• OpenTelemetry の gen-ai/mcp セマンティック規約との互換維持が目的として明記されています。
• セッションが廃止されたことで、複数ホップ（クライアントからゲートウェイを経てサーバ）にまたがるリクエストの相関手段は、接続やセッション ID ではなく traceparent によるトレースコンテキスト伝播に一本化されます。
• Logging 機能自体が非推奨化（SEP-2577）されたため、ログの運用は移行が必要です。

ログレベル運用

• logging/setLevel RPC は削除されました。ログレベルは _meta の io.modelcontextprotocol/logLevel によりリクエスト単位で指定します。
• このフィールドを含まないリクエストに対して、サーバは notifications/message を送信してはなりません（MUST NOT）。

運用上の影響は次のとおりです。

• 以前のようにセッション全体へ一度だけ verbosity を設定する運用はできません。デバッグしたい呼び出しごとに logLevel を明示します。
• notifications/message は当該リクエストのレスポンスストリーム上でのみ配信され、subscriptions/listen の長寿命ストリームには流れません。ログビューアはリクエスト単位でアタッチする設計が必要です。
• サーバが notifications/message を送出する場合、logging capability の宣言は引き続き必要です。
• io.modelcontextprotocol/logLevel が認識できない値の場合、サーバは -32602（Invalid params）で拒否します（SHOULD）。

ストリームの扱い

• SEP-2575 により、SSE ストリームの再開可能性とメッセージ再送（Last-Event-ID ヘッダおよび SSE イベント ID）が Streamable HTTP から削除されました。
• レスポンスストリームが切れると、その in-flight リクエストは失われます。クライアントは MUST で新しいリクエスト ID を付けて同一操作を再送します。
• Streamable HTTP の仕様上、SSE レスポンスストリームを閉じることはサーバにとって当該リクエストのキャンセルとして扱われます（MUST）。プロキシやロードバランサのタイムアウトで長時間ストリームが切断されると、サーバ側の処理はキャンセル扱いになり、再送は独立した新規リクエストとして処理されます。冪等でない操作は再送時の重複実行リスクを設計側で吸収する必要があります。
• 長時間処理は、単一ストリームの生死に結果を依存させない Tasks 拡張（io.modelcontextprotocol/tasks）へ寄せる判断が妥当です。
• 長寿命の subscriptions/listen ストリームでは、アイドル時間中の接続断を避けるため、サーバが定期的に SSE コメント行（: で始まる keep-alive）を送ることが推奨されます。また X-Accel-Buffering: no ヘッダの付与が SHOULD で推奨されており、nginx 等のリバースプロキシでのバッファリングによる遅延を避けられます。

バージョン移行運用

2025-11-25 以前（legacy）と 2026-07-28 以降（modern）が混在する期間の運用です。

• サーバは server/discover の実装が MUST です。クライアントはこれを事前呼び出しして対応バージョンを確認できます（MAY）。
• HTTP 上でのフォールバック判定では、クライアントはまず modern なリクエストを送り、400 Bad Request を受けたらボディを確認します。
  • ボディが UnsupportedProtocolVersionError など認識可能な modern な JSON-RPC エラーであれば、相手は modern サーバです。supported 一覧から相互サポート可能なバージョンを選んで再送します（フォールバックしません）。
  • ボディが空、または認識できない内容であれば、legacy の initialize にフォールバックします。
• stdio 上ではリクエストごとの HTTP ステータスコードが存在しないため、server/discover を先に送るプローブ運用が推奨されます（SHOULD）。
• era 判定はサーバプロセス（stdio）またはオリジン（HTTP）単位の性質です。クライアントはその結果をプロセス・オリジンの生存期間中キャッシュしてよく（SHOULD）、キャッシュした前提が後で失敗すれば再プローブします。
• modern のみをサポートするサーバは、initialize に対して返すエラーに対応バージョン一覧を含めることが推奨されます（SHOULD）。legacy クライアントには他に診断手段がないためです。

組み合わせごとの結果は「利用方法」の互換性マトリクスを参照してください。

段階的なロールアウトでは、次の順序が安全です。

1. サーバを dual-era 化する。前版クライアントを切らずに 2026-07-28 を受けられる状態を先に作ります。Python の v2 サーバと TypeScript の createMcpHandler は、同一エンドポイントで両リビジョンを処理します。Go は StreamableHTTPOptions.Stateless = true を設定した時点で 2026-07-28 を受け付けます。
2. ロードバランサのスティッキー設定を残したまま dual-era サーバを展開する。この段階ではまだ前版クライアントがセッションを使うため、スティッキー設定を先に外すと前版クライアントが壊れます。
3. クライアントを modern へ更新する。
4. 前版トラフィックが消えたことを確認してからスティッキー設定を外す。MCP-Protocol-Version ヘッダはボディを解析せずに観測できるため、リビジョン別のトラフィック比率をロードバランサのアクセスログで集計できます。

スティッキー設定の解除を最後に置くのが要点です。ステートレス化はサーバ側の対応だけでは完結せず、前版クライアントが残っている限りセッションの固定が必要になります。

ベストプラクティス

状態設計

セッション廃止に伴い、呼び出しをまたぐ状態は、サーバが発行する明示ハンドル（server-minted handle）をツールの通常引数として受け渡す設計に置き換えます。

以下は仕様が定める型名ではなく設計パターンの実装例です。

{
  "resultType": "complete",
  "content": [{ "type": "text", "text": "started" }],
  "structuredContent": {
    "transactionHandle": "eyJhbGciOiJIUzI1NiJ9.opaque-token"
  }
}

{
  "name": "commit_transaction",
  "arguments": {
    "transactionHandle": "eyJhbGciOiJIUzI1NiJ9.opaque-token"
  }
}

ハンドル設計時の考慮点です。

状態がツール引数として LLM に可視化されるため、モデル自身が「このハンドルをいつ使い、いつ手放すか」を推論できます。セッションという不可視の裏状態に依存しません。

設計原則は MRTR の requestState に対する規範と同一です。クライアントを経由するハンドルは、攻撃者が改ざん可能な入力として扱う必要があります。リプレイ対策として、認証済みプリンシパル・短い有効期限・元リクエストの識別子を完全性保護の対象に含めて検証することが推奨されます（SHOULD）。

認可設計

セッション単位で一度だけ確立していた認可判断は、リクエスト単位・ハンドル単位で毎回検証する設計に置き換わります。永続セッションが存在しないため、認可コンテキストをリクエストごとに独立して評価する前提が必要です。

発行者（issuer）検証（SEP-2468）

認可サーバは認可レスポンス（エラーレスポンスを含む）に RFC 9207 の iss パラメータを含めることが SHOULD です。authorization_response_iss_parameter_supported: true を広告する認可サーバは iss を含めることが実質必須になります。

クライアントは認可コードをトークンエンドポイントに渡す前に、この検証を MUST で適用します。これはミックスアップ攻撃を、リダイレクト前に記録した issuer とレスポンスを突き合わせることで緩和します。PKCE 単体では防げません。code_verifier 自体が攻撃者のトークンエンドポイントに渡ってしまうためです。

資格情報の発行者束縛（SEP-2352）

• クライアント資格情報（事前登録済み、または DCR で取得したもの）は、発行した認可サーバの issuer 識別子でキーイングして永続化します（MUST）。
• 異なる認可サーバでの再利用は MUST NOT です。
• Protected Resource Metadata の更新により認可サーバの変更を検知した場合、MUST で再登録します。
• CIMD ベースの client_id（自己ホストする HTTPS URL）は認可サーバをまたいで可搬なため、この再登録は不要です。

DCR の application_type（SEP-837）

OIDC 対応の認可サーバで動的クライアント登録を行う場合、application_type を明示することが MUST です。省略すると OIDC 上のデフォルトである "web" になり、native スタイルのリダイレクト URI と衝突する可能性があります。

DCR（RFC 7591）の非推奨化と CIMD 移行（PR #2858）

• RFC 7591 に基づく動的クライアント登録は非推奨化され、Client ID Metadata Documents（CIMD）が推奨経路になりました。
• CIMD は HTTPS URL をそのまま client_id として使い、その URL がホストする JSON メタデータ文書（client_id / client_name / redirect_uris を最低限含む）を認可サーバが取得・検証する方式です。事前関係のないクライアントとサーバの間の登録を実現します。
• クライアントの登録手段の優先順位（SHOULD）は次のとおりです。
  1. 既存の事前登録済みクライアント情報があればそれを使う
  2. 認可サーバが client_id_metadata_document_supported: true を広告していれば CIMD を使う
  3. 認可サーバが registration_endpoint を持てば DCR にフォールバック
  4. どちらも無ければユーザーにクライアント情報の入力を求める
• RFC 7591 は CIMD 非対応の認可サーバとの後方互換のために引き続き利用可能です。削除ではなく非推奨であり、最短削除時期は 2027-07-28 以降の最初のリビジョンです。

リフレッシュトークン運用（SEP-2207）

セッションが無くなったことで、認可コンテキストの継続はトークンの寿命管理だけに依存します。仕様はリフレッシュトークンの扱いを次のように定めます。

• クライアントは、リフレッシュトークンを転送時・保存時ともに秘匿します（MUST）。
• クライアントは grant_types クライアントメタデータに refresh_token を含めるべきです（SHOULD）。
• 認可サーバのメタデータの scopes_supported に offline_access が含まれる場合、クライアントは認可リクエストとトークンリクエストの scope に offline_access を追加できます（MAY）。
• クライアントは、リフレッシュトークンが必ず発行されると仮定してはいけません（MUST NOT）。発行の可否は認可サーバの裁量です。
• MCP サーバ（保護リソース）は、WWW-Authenticate のスコープや Protected Resource Metadata の scopes_supported に offline_access を含めるべきではありません（SHOULD NOT）。リフレッシュトークンはリソース側の要件ではないためです。

スコープ蓄積と discovery（SEP-2350 / SEP-2351）

• SEP-2350 は、ステップアップ認可においてクライアント側でスコープが蓄積される挙動を明確化しました。
• SEP-2351 は、MCP における RFC 8414 の .well-known URI サフィックスを明示的に規定しました。

これら 3 件は個別の OAuth 改善に見えますが、いずれもセッション廃止と同じ方向を向いています。認可の状態をサーバ側の接続に預けられなくなったため、トークンの寿命・スコープ・発行元といった認可コンテキストの構成要素を、クライアントが自分で正確に保持し、リクエストごとに提示する必要が生じました。

ハンドル受け取り側の認可チェック

明示ハンドルを受け取る側は、そのハンドルが呼び出し元自身の認可コンテキストで発行されたものであることを毎回検証する必要があります。これは、MCP サーバがアクセストークンについて「自分宛てに発行されたものだけを受理し、他のリソース向けトークンは拒否・転送しない」という既存の必須要件と同じ構造を、ハンドルという別種の秘匿トークンにも適用する考え方です。テナント A の認可コンテキストで発行したハンドルをテナント B のトークンで使用しようとした場合、サーバは拒否する必要があります。

非推奨機能の移行計画

2026-07-28 で新たに非推奨化された機能は、機能ライフサイクルと非推奨ポリシー（SEP-2596）に従い、最低 12 ヶ月の非推奨期間を経てから削除対象になります。削除そのものはコアメンテナの別途判断です。

非推奨機能は猶予期間中も完全に機能します。新規実装はこれらを採用すべきではなく（SHOULD NOT）、既存実装は猶予期間中に移行することが推奨されます（SHOULD）。最新の対象一覧は非推奨機能レジストリが正本です。

拡張の使い分け

• ClientCapabilities / ServerCapabilities に追加された extensions フィールドは、拡張識別子（io.modelcontextprotocol/tasks のような、必須プレフィックス付きの _meta キー命名規則に従う文字列）から設定オブジェクトへのマップです。空オブジェクトは「追加設定なしでサポート」を意味します。
• 一方が拡張をサポートし、他方がサポートしない場合、サポートする側はコアプロトコルの挙動へ戻るか、適切なエラーで拒否する MUST があります。拡張はフォールバック挙動を文書化することが推奨されます（SHOULD）。
• Tasks 拡張（io.modelcontextprotocol/tasks、SEP-2663）は、experimental だったタスク機能がコアから公式拡張へ移動したものです。
  • ブロッキングの tasks/result を廃止し、tasks/get によるポーリングに置換しました。
  • クライアントからサーバへの入力用に tasks/update を新設しました。
  • tasks/list は削除しました。
  • サーバはリクエスト単位のオプトインなしにタスクハンドルを返せます。
  • 使いどころは、単一の HTTP ストリームの生死に結果を依存させたくない長時間処理です。

契約テスト

適合性テストは公式リポジトリ modelcontextprotocol/conformance（"Conformance Tests for MCP"）で公開されています。SEP-2484 は、Standards Track の SEP が Final 状態に到達する条件として、対応するシナリオが適合性スイートに追加されていることを要求します。SDK Tiering System も、Tier 判定の根拠としてこのスイートを参照します。

自社実装の受け入れテストには、このスイートに加えて、以下の仕様が定義する規範的な合図を土台として使えます。

• 互換性マトリクス（前掲の 7 通りの組み合わせ）を、クライアント・サーバ実装が満たすべき受け入れテストの母集合として使う。
• UnsupportedProtocolVersionError（-32022）・MissingRequiredClientCapabilityError（-32021）・HeaderMismatchError（-32020）のボディ形状（data.supported / data.requested / data.requiredCapabilities など）を、プロトコルバージョン別テストのアサーション対象にする。
• server/discover が返す supportedVersions と実際に処理可能なバージョンの整合性を検証する。

以下は仕様外の補完による実装例です。

# 実装例: プロトコルバージョン別契約テストの観点
- 未知バージョンで UnsupportedProtocolVersionError が正しい data 形状で返るか
- ヘッダとボディを意図的に不一致にして HeaderMismatch (-32020) になるか
- legacy スタブサーバ相手に initialize フォールバックが正しく発火するか
- server/discover の supportedVersions が実装と一致しているか

トラブルシューティング

エラーコード起因の症状

廃止された機能に起因する症状

ステートレス化に起因する症状

まとめ

MCP 2026-07-28 は、プロトコルレベルのセッションと initialize ハンドシェイクを廃止し、各リクエストが _meta でバージョンと能力を自己申告する構造へ移行しました。これによりリモート MCP サーバはスティッキールーティングと共有セッションストアから解放される一方、呼び出しをまたぐ状態は明示ハンドル、サーバ起点の対話は MRTR、変更通知は subscriptions/listen、鮮度管理は CacheableResult と、これまでプロトコルが暗黙に肩代わりしていた責務がアプリケーション側の設計判断として顕在化します。移行では、サーバの dual-era 化を先に済ませ、ロードバランサのスティッキー設定の解除を最後に置く順序が要点です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNS でのシェアをいただけると励みになります！

参考リンク

仕様本文へのリンクは main ブランチを指します。main は更新され続けるため、本稿の記述は コミット 7634684（2026-07-27 時点） の内容に基づきます。当時の内容を再現する場合は、URL の main をこのコミット SHA に置き換えてください。

仕様本体

• Key Changes（changelog）
• changelog.mdx（raw）
• Architecture
• Base Protocol（エラーコード割当ポリシーと _meta 一般規定）
• Versioning and Compatibility
• Deprecated Features（非推奨機能レジストリ）

構造・トランスポート

• Streamable HTTP transport
• stdio transport
• Transports 概要
• Multi Round-Trip Requests (MRTR)
• Subscriptions
• server/discover

データ・スキーマ

• schema.ts（draft）
• schema.json（draft）
• スキーマ JSON 実例集（schema/draft/examples/）
• Tools（Stateful Tools セクション）

運用・キャッシュ・可観測性

• Caching（ttlMs / cacheScope）
• Logging
• OpenTelemetry gen-ai/mcp セマンティック規約

認可

• Authorization
• Client Registration（CIMD / DCR 非推奨）
• Authorization Server Discovery
• Security Considerations
• RFC 9207: OAuth 2.0 Authorization Server Issuer Identification
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol

SEP（変更提案）

• SEP-2567: セッションと Mcp-Session-Id の削除
• SEP-2575: ステートレス化・server/discover・subscriptions/listen
• SEP-2322: Multi Round-Trip Requests と resultType
• SEP-2243: 標準リクエストヘッダ
• SEP-2549: CacheableResult（ttlMs / cacheScope）
• SEP-2663: Tasks の公式拡張への移動
• SEP-2577: Roots / Sampling / Logging の非推奨化
• SEP-2596: 機能ライフサイクルと非推奨ポリシー
• SEP-2468: iss パラメータ検証
• SEP-2352: 資格情報の発行者束縛
• SEP-837: DCR の application_type
• SEP-2106: JSON Schema 2020-12 対応
• SEP-414: OpenTelemetry トレースコンテキスト伝播
• SEP-2164: resource not found エラーコードの標準化（-32602）
• SEP-2207: OpenID Connect 向けリフレッシュトークンガイダンス
• SEP-2350: ステップアップ認可でのクライアント側スコープ蓄積の明確化
• SEP-2351: MCP における RFC 8414 well-known URI サフィックスの明示
• SEP-2484: Standards Track SEP の Final 到達に適合性テストを要求
• PR #2858: Client ID Metadata Documents への移行

告知・SDK

• The 2026-07-28 MCP Specification Release Candidate（RC 告知ブログ）
• SDK ベータ告知（2026-06-29）
• SDK Tiering System
• modelcontextprotocol/conformance（適合性テスト）
• Python SDK v1 から v2 への移行ガイド
• TypeScript SDK: Upgrading from v1 to v2
• TypeScript SDK: Adopting the 2026-07-28 revision
• Go SDK v1.7.0-pre.1
• C# SDK v2.0.0-preview.1
• Python mcp パッケージ（PyPI）

起点記事（二次情報）

• MCPが7月28日にステートレス化。初期化のハンドシェイク廃止でシンプルに（Publickey）