MCPのステートレス化（2026-07-28仕様）：MCPサーバー移行チェックリスト

#「ステートレス化」がもたらすアーキテクチャ上のインパクト

これまでの仕様では、リモートMCPサーバーはクライアントを「記憶」する必要がありました。initialize ハンドシェイクによってセッションを開始し、Mcp-Session-Id を使って特定のインスタンスへ接続を固定していました。これを水平分散（スケールアウト）させようとすると、セッションIDに基づくスティッキーなルーティングを設定するか、Redisなどの共有ストアを構築してすべてのインスタンスがセッション情報を同期できるようにしなければなりませんでした。これは、分散システムを運用したことのあるエンジニアなら誰もが避けたい複雑さです。

2026-07-28仕様は、まさにこの部分を根本から解決します。プロトコル層でのハンドシェイクとセッションIDを排除したことで、**「任意のインフラリクエストが任意のサーバーインスタンスに到達しても問題がない」**状態になります。サーバーは標準的なHTTPインフラの上で動作し、スティッキー設定なしで単純なラウンドロビンでスケール可能になります。

デリバリーおよびインフラの運用面から見れば、保守すべきサーバーインフラのレイヤーが1つ減ることを意味します。しかし一方で、「有効なセッションが存在する」ことを前提として記述された状態保持ロジックは、設計を書き換える必要があります。

#廃止される機能と追加される機能の対比

思考のパラダイムシフト：状態（State）そのものが消滅するわけではありません。「トランスポート層の裏側に隠されていた状態」から「会話ログの中で明確に記述される状態」へと移行するのです。サーバーがセッションとして記憶する代わりに、モデルに向けて明示的な「ハンドル」を発行し、以降のやり取りでモデル自身にそのハンドルを持たせて呼び出させます。

#MCPサーバーのステートレス移行チェックリスト

現在稼働中の既存MCPサーバーを移行する際の推奨手順です。

1. 公式SDKのアップデート： 利用している言語用のSDKが2026-07-28仕様をサポートするのを待ちます（Tier 1の主要SDKは、10週間の検証ウィンドウ内に対応予定です）。公式SDKの準備が整う前に、独自のラッパーを実装するのは避けるのが賢明です。

2. Mcp-Session-Id への依存性の排除： サーバーコード内でセッションIDを読み取って状態を検索している箇所をすべて洗い出します。これが今回の移行での最大の修正ポイントです。

3. 明示的なハンドル設計への移行： 状態を初期化するツールから明示的なハンドル（例： basket_id や browser_id）を発行・返却するように変更します。関連する後続ツールは、このハンドルを通常の引数（パラメータ）として受け取れるように設計し、状態の受け渡し責任をモデル側に持たせます。

4. 新規ルーティングヘッダーの実装： リクエストボディ全体を解析することなくロードバランサー等がパケットを振り分けられるよう、Mcp-Method および Mcp-Name ヘッダー（SEP-2243）を出力・認識できるようにします。

5. 複数ステップのインタラクションの「InputRequired」化： クライアントからのデータ入力を待つためにSSEなどの接続を開き続けるのをやめ、InputRequiredResult（inputRequests および requestState を内包）を返却して即時応答します。クライアントは入力値を含めた inputResponses と、サーバーからエコーバックされた requestState を持たせて再度リクエストします。これにより、再試行リクエストが別のインスタンスに振り分けられても破綻しません。

6. Tasksを新ライフサイクル仕様へ移行： 実験的なTasks（2025-11-25仕様の段階）を利用していた場合は、正式な標準ライフサイクルへ切り替えます。tools/call でタスクハンドルを返却し、クライアントからの tasks/get、tasks/update、tasks/cancel を通じて状態制御を行います（SEP-2663 ―― これは破壊的変更になります）。

7. 認証機能の堅牢化（Hardening）： セキュリティ関連のSEPに準拠します。RFC 9207に基づく iss パラメータの検証（SEP-2468）、動的クライアント登録（DCR）時のOIDC application_type の明示（SEP-837）、認証情報を issuer にバインドし変更時に再登録する仕組み（SEP-2352）などを実装します。

チェックリストのまとめ：**手順2〜3が移行のコア（本質）**であり（暗黙的なセッションを廃止し、明示的ハンドルにする）、その他はルーティングヘッダー、Tasks、認証の標準化対応です。もし提供しているサーバーが読み取り専用（状態非保持）であれば、移行の負担はほぼゼロです。

#拡張（Extensions）フレームワークの標準化：MCP AppsとTasksが正式採用へ

今回の仕様アップデートでは、新たに拡張（Extensions）フレームワーク（SEP-2133）が正式に規格化されます。これらは逆DNS表記の識別子を持ち、機能交渉（Negotiation）はCapabilities内の extensions マップを介して行われます。コア仕様とは独立してバージョン管理され、ext-* リポジトリで開発されます。中でも特に注目される2つの公式拡張機能は以下の通りです。

• MCP Apps（SEP-1865） ―― サーバーが動的なHTMLユーザーインターフェースをホスト側に送信し、ホストはセキュリティが確保されたサンドボックス化されたiframe内で描画（レンダリング）します。ツールは事前にUIテンプレートを宣言するため、ホストは先読み（Prefetch）やキャッシュ、事前のセキュリティスキャンを行えます。UI操作からサーバーへのコールバックは、既存のJSON-RPCチャンネルを介して送信されるため、通常のツール呼び出しと同様にセキュリティ監査のログに記録されます。これにより、MCPは「テキストやデータのみを返す」プロトコルから「インターフェース全体を直接届ける」プロトコルへと進化します。
• Tasks（SEP-2663） ―― 接続を開き続けずに、バックグラウンドでの長時間処理を管理するための標準規格です。サーバーがタスク識別用のハンドルを返却し、クライアントは必要に応じて tasks/get、tasks/update、tasks/cancel を通じて状態を確認・制御します。

#過剰な懸念は不要：非推奨化ロードマップの確立

本バージョンより、公式の非推奨化（Deprecation）ポリシー（SEP-2577）が導入されます。機能は「Active → Deprecated → Removed」の3フェーズで段階的に整理され、Deprecated（非推奨）に指定されてから実際にRemoved（削除）されるまで、最低でも12ヶ月間の猶予が保証されます。

今回の仕様策定において非推奨に指定される3つの注釈的アノテーション機能（現行バージョンでは動作します）：

MCPのアドバンスド領域において広く議論されていた機能群ですが、仕様策定チームはこれらを別の手法に整理することを決定しました。ただし、実質的に移行のための猶予期間が1年以上残されているため、7月28日に何かが突然動かなくなる心配はありません。

#おわりに

MCPは着実に進化を遂げています。接続セッションと暗黙の内部状態を前提とした旧仕様から、HTTP標準に乗るステートレスなプロトコルへ。そして、拡張フレームワークによって規律ある機能拡張が可能となりました。

ユーザー側としてMCPを利用する立場であれば、基本的にはSDKのアップデートのみで対応が完了します。一方で、MCPサーバーを提供する開発者側にとっての要点は極めてシンプルです。**「暗黙的なセッションを捨て、状態を明示的なハンドルに変換し、新しいルーティングヘッダーを出力する。そして非推奨となった機能群については、1年以内のタイムラインで順次書き換えていく」**ということです。

さらに理解を深めたい方は、MCPの基本構造（クライアント/サーバー構成、3大機能、トランスポート）を説明したModel Context Protocol、およびそのアドバンスドガイドをご参照ください。また、これらのサーバーを呼び出すエージェントを自ら開発する際は、Claude Agent SDK vs Claude API vs Claude Codeを参考にしてください。ブラウザ上で動作するWebエージェントに関してはWebMCPで解説しています。学習ロードマップ全体は [/learn/claude?lang=ja] にまとめられています。

Nguyễn Phúc Nguyên Châu
Delivery Manager
ベトナム・日本市場向けに14年のデリバリー経験（Web・システム・AI自動化）