メインコンテンツへスキップ
Dev Tools 17分で読める

MCPからセッションが消える──2026-07-28仕様RCで何が壊れ、何が良くなるか

#MCP#Model Context Protocol#Claude Code#AIエージェント#Anthropic#ステートレス#API設計

「スティッキーセッションをロードバランサーの裏で動かすのは、言葉通りそれだけ苦痛だ。普通のWebサービスと同じように動くというのは退屈に聞こえる。だがそれが要点だ」（Hacker Newsでのエンジニアのコメント、出典: HN item #47380270）。

2026年5月21日、MCPのリード・メンテナーであるDavid Soria ParraとDen Delimarskyは「2026-07-28 リリース候補（RC）」を公開した。その冒頭の一文はこうだ。「ローンチ以来、最大のプロトコル改訂だ」（出典: MCP Blog）。

最終仕様の公開は2026年7月28日。今日（6月26日）から32日後だ。現行の安定版（2025-11-25）からRCへの移行は破壊的変更を含む。MCPサーバーを本番運用しているチームは、今動く必要がある。

この記事はこんな人におすすめ
  • MCPサーバーを開発・運用しているエンジニア
  • Claude CodeやCursorなどAIツールのMCP連携を設計しているPM・アーキテクト
  • 2026年7月28日の仕様変更前に移行コストを見積もりたいチームリード

なぜMCPはセッションを捨てたのか

MCP（Model Context Protocol）は2024年11月にAnthropicが公開したAIエージェントとツールを接続する標準プロトコルだ。2026年6月時点で月間9,700万ダウンロード、公開サーバー数は9,000以上、Fortune 500の28%が本番環境で採用しているとされる（出典: MCP Adoption Statistics 2026、二次情報）。

ただし急成長には裏がある。現行仕様（2025-11-25）はステートフル設計だ。クライアントとサーバーはinitialize/initializedハンドシェイクで接続を確立し、Mcp-Session-Idヘッダーで特定のサーバーインスタンスに固定される。これを「スティッキーセッション」という。

問題はスケールアウト時に顕著になる。複数のサーバーインスタンスをロードバランサーで水平展開しようとすると、セッションをどのインスタンスが持っているかを追跡するための「セッションストア」と「スティッキールーティング」が必要になる。普通のHTTP APIでは不要なインフラ層だ。

この感覚はMCPを本番運用してきた開発者に広く共有されており、Hacker Newsでは今回の変更を「長年求めていたもの」と歓迎する声が多い（出典: HN #47380270）。

これを解決するのが「ステートレス化」だ。セッションをプロトコルレベルから廃止し、あらゆるリクエストを任意のサーバーインスタンスが処理できるようにする。ただし「ステートレス化」はアプリケーションが状態を持てなくなることを意味しない。代わりにサーバーがツール呼び出しの結果として「ハンドル」（例: basket_id）を返し、クライアント（AIモデル）がそのハンドルを次の呼び出しの引数として渡す。HTTPが数十年使ってきたのと同じパターンだ。

2026-07-28 RCで具体的に何が変わるか

公式ブログが「ローンチ以来最大の改訂」と表現したRCは、5本の主要変更で構成される（出典: MCP Blog RC発表）。

1. initializeハンドシェイクの廃止（SEP-2575：Specification Enhancement Proposal）

initialize/initializedの2ステップ接続確立は完全に削除される。代わりにクライアントが毎リクエストの_metaフィールドにプロトコルバージョン・クライアント情報・対応機能を埋め込む。サーバーはserver/discover RPCでいつでも機能一覧を返せる。

2. Mcp-Session-Idヘッダーの削除（SEP-2567）

セッションIDヘッダーが消える。水平スケールアウト時に必要だったスティッキールーティングとセッションストアが不要になる。公式ブログは「普通のラウンドロビンロードバランサーで動く」と明記している。

3. 新必須HTTPヘッダー: Mcp-MethodとMcp-Name（SEP-2243）

Streamable HTTPトランスポートでは、毎リクエストにMcp-Method（例: tools/call）とMcp-Name（ツール名）の2ヘッダーが必須になる。これによりロードバランサーやゲートウェイがリクエストボディを解析せずにルーティングできる。

4. Tasksエラーコード変更

リソース未検出時のエラーコードが独自値-32002から標準JSON-RPCの-32602（Invalid Params）に変わる。リテラル値でエラーを識別しているクライアントコードは修正が必要だ。

5. tasks/listの削除

実験的Tasksのリスト取得エンドポイントが削除される。セッションなしではスコープを安全に定義できないためだ。TasksはTasksエクステンションとして再設計される（詳細は次節）。

MicrosoftのAzure App Serviceチームは独自のブログ記事でこの変更を歓迎している。「以前はスティッキーセッション、共有セッションストア、ゲートウェイでのボディ解析が必要だったMCPサーバーが、普通のWebアプリのようにスケールアウトできるようになる」（出典: Microsoft Tech Community）。

新機能：MCP AppsとTasksエクステンション

RCは廃止と同時に、2つの大型エクステンションを正式化した。

MCP Apps（SEP-1865）：AIチャットにUIが生える

2026年1月26日に正式ローンチしたMCP Appsは、MCPサーバーがサンドボックスiframe内でインタラクティブなHTMLインターフェースをホスト側に返せる機能だ（出典: MCP Blog MCP Apps）。

仕組みはシンプルだ。ツールが_meta.ui.resourceUriフィールドでui://スキームのリソースURIを返し、ホストがそのHTMLをiframe内でレンダリングする。UIとホスト間の通信はJSON-RPC 2.0のpostMessageで双方向に行われる。セキュリティはCSPと厳格なiframeサンドボックスで保証される。

Block（旧Square）のAndrew Harvardはこう語る。「MCP Appsはユーザーインターフェースをエージェント体験の中に組み込むことで、さらに前進する」（出典: MCP Apps Blog）。

Claude（Web・デスクトップ）、ChatGPT、VS Code、Goose、JetBrainsなどの主要クライアントがすでに対応している。ダッシュボード、フォーム、データ可視化、マルチステップワークフローをAIチャット内で実現できる。

Tasksエクステンション（SEP-2663）：長時間タスクの標準化

2025-11-25仕様に実験的に含まれていたTasksはステートレス化に対応する形で再設計され、コアではなくエクステンションとして正式化された（出典: Tasks Extension Docs）。

流れはこうだ。tools/callがタスクハンドルを返す → クライアントがtasks/getでステータスをポーリング → 完了後に結果を取得。サーバーが即座に答えられないCI/CDパイプライン・バッチ処理・ヒューマンインザループ承認などのユースケースに対応する。

注意点が1つある。tasks/listは削除された。セッションなしでは安全にスコープを定義できないからだ。旧Tasks APIのコードは移行が必要になる。

3つの廃止機能：Roots・Sampling・Logging

SEP-2577（2026年5月15日マージ）は3機能を同時に廃止予定とした。廃止はアノテーションのみで、メソッドとタイプは現行通り機能する。最終仕様（7月28日）から最低12ヶ月は削除されない。

機能廃止理由移行先
Rootsセマンティクスが曖昧、採用率低、セキュリティ境界が機能しないツールパラメータ・リソースURIで明示的に渡す
Sampling最大のセキュリティリスク（プロンプトインジェクション、データ漏洩）、複雑な実装、低採用LLMプロバイダーAPIを直接呼び出す
Loggingstderr・OpenTelemetryと重複、ステートレス化と非互換stdioにはstderr、HTTPにはOpenTelemetry

Samplingの廃止に対しては、コミュニティの一部から批判の声もある。Nullpointer Blogは「Samplingの廃止は残念だ。モデル非依存でクライアントのLLMを借りるパターンは、セキュリティコストを上回る価値があった」と主張している（出典: Nullpointer Blog）。MCPチームはこの懸念を認めつつも、セキュリティリスクと採用率の低さを根拠に廃止を決定した。

光と影は明確だ。廃止によってプロトコルは大幅に簡素化される。一方で、Samplingを使っているサーバーは移行コストを負担する。

7月28日まで32日：今すぐ動くべき理由

現行安定版（2025-11-25）は引き続き動作する。だが7月28日の最終仕様リリース以降、クライアントがRCベースに移行すると互換性の問題が生じる。特にMcp-Session-Idを使うサーバーや、initializeハンドシェイクに依存するコードは早めの対応が必要だ。

Dev.toの開発者@akaranjkar08はこう書いている。「5月28日、MCPチームはハードな7月28日カットオーバー日を設定して最大の仕様改訂を公開した。破壊的変更、2つの新しいHTTPヘッダー、エラーコード変更、キャッシュセマンティクス、3つの廃止機能——今すぐ移行計画を始める必要がある」（出典: DEV Community）。

MCP 2026-07-28移行チェックリスト（破壊的変更のみ）

以下は最終仕様リリース（7月28日）までに対応が必要な項目だ。廃止機能（Roots・Sampling・Logging）は最低12ヶ月の猶予があるため優先度は低い。

  1. Mcp-Session-Idを廃止: セッションIDの読み書きを削除。状態はハンドルをツール引数で渡す方式に移行
  2. initializeハンドシェイクを削除: 接続確立ロジックを撤廃。server/discoverに置き換え
  3. HTTPヘッダー追加: Streamable HTTP全リクエストにMcp-MethodとMcp-Nameを追加
  4. エラーコード修正: -32002を-32602に変更（リソース未検出）
  5. tasks/list削除対応: Tasks使用コードのエラーハンドリングを見直す
  6. SDK更新: Python SDKはmcp>=1.27,<2で固定後、v2アルファを評価。TypeScriptはsessionIdGenerator: undefined設定を確認

関連ガイドを読む

MCPとA2Aの使い分けはMCP vs A2A完全比較2026も参照。Claude Code上でのネストされたサブエージェント活用例はこちらのガイドで紹介している。

MCPの実践入門ガイドを読む

関連記事

本記事に記載の技術仕様はMCP公式ブログ「The 2026-07-28 MCP Specification Release Candidate」（2026年5月21日公開、blog.modelcontextprotocol.io）およびGitHubの各SEPマージ内容に基づく。最終仕様は2026年7月28日に公開予定であり、RCから変更が加わる可能性がある。本記事は特定のツール・サービスの採用を保証・推奨するものではない。

Share