AI アシスタントに外部ツールやデータベースを繋ぐための標準規格、MCP（Model Context Protocol）のサーバーを構築したエンジニアに向けた内容です。Claude Code や Cursor 向けに GitHub 連携や社内 DB 接続用の MCP サーバーを自前で運用している方の参考になれば幸いです。
MCP は 2024 年末に Anthropic が公開したオープン規格です。AI アプリ（ホスト）とツール（サーバー）を繋ぐ通信の作法を定義しています。仕様の更新により、これまで「正しい実装」とされていた部分の一部が legacy（保守はされるが推奨されない古い実装）扱いになります。派手に壊れるわけではありませんが、移行の猶予期間は有限です。
何が起きるか: セッション管理の仕組みが丸ごと不要になる
影響の中心は接続確立の手順、いわゆる handshake（クライアントとサーバーが最初に行う挨拶的な通信）です。
これまでの MCP では、クライアントとサーバーが initialize というメソッドでやり取りを開始し、サーバー側が Mcp-Session-Id というヘッダーを発行していました。以降のリクエストは全てこのセッション ID を使い、同じサーバーインスタンスに紐付けられていました。
更新後は、この initialize と Mcp-Session-Id によるセッション管理が廃止されます。リクエストは Mcp-Method というヘッダーを見てルーティングされ、ロードバランサー配下のどのインスタンスにも着地できるようになります。特定のサーバーに接続が固定される sticky routing（同じ接続を同じサーバーに固定する仕組み）が不要になるということです。
これにより、MCP サーバーはステートレスな一般的な Web サービスと同じ扱いで運用できるようになります。セッション状態を共有するためのデータストアや、ゲートウェイでのパケット検査といった、これまで「税金」のように払っていたインフラコストが消えます。
もう一つの明確な破壊的変更は Tasks API です。これは Tasks extension に置き換えられ、タスク呼び出しは tasks/get、tasks/update、tasks/cancel という新しいメソッド体系に移行します。実験的な機能だった分、ここは唯一の hard break（互換性のない破壊的変更）として扱われています。
なぜ起きるか: 状態管理は技術的負債という判断
なぜここまで踏み込んでセッションを削るのでしょうか。背景には「State is debt（状態は負債である）」という設計思想があります。
セッションによる状態管理は、一見便利に見えても運用側には確実にコストを課します。同じ接続を同じインスタンスに固定する必要があるため、水平スケールの自由度が落ちます。共有データストアも必要になり、障害点が増えます。
興味深いのは、状態の一部が消えるのではなく「押し戻される」点です。呼び出しの履歴（チェーン）を、サーバー側ではなくモデル側が保持するようになります。AI モデルが処理の主導権を持っている以上、モデル側に状態を持たせる方が合理的という考え方です。
これは LLM（大規模言語モデル）を使ったプロンプト設計、いわゆる context engineering（モデルに渡す文脈を設計する手法）とも通じる話です。冗長なトークンが資産ではなく負債として扱われるのと同じ発想が、プロトコルの状態管理にも適用されたと理解すると腑に落ちます。
あわせて、クライアント側の機能である Roots（対象ディレクトリの指定）、Sampling（クライアント経由での LLM 補完呼び出し）、Logging（ログ出力の仕組み）も非推奨になります。ただしこちらは 12 か月の移行猶予があり、即座に壊れるわけではありません。認証面では OAuth 2.1 が必須化され、緩い認証実装は許容されなくなります。
自分のプロジェクトが該当するか確認する方法
まず確認すべきは、手元の MCP サーバー実装がセッションの仕組みに依存しているかどうかです。
# initialize ハンドラとセッション依存のコードを洗い出す
grep -rn "initialize" ./src
grep -rn "Mcp-Session-Id" ./src
grep -rn "session" ./src --include="*.py" --include="*.ts"次に SDK のバージョンです。Python SDK では FastMCP というクラス名が MCPServer に変更されます。TypeScript SDK は ESM 専用（CommonJS 形式のビルドを廃止）になる点も要チェックです。Go と C# の SDK はプレビュー版として新規に登場しています。
# 使用中の SDK バージョンを確認する例（Python の場合）
pip show mcp
# package.json 内の MCP 関連依存を確認する例（Node.js の場合）
cat package.json | grep -i mcpTasks API を使っているかどうかも重要な分岐点です。tasks/create のような旧メソッド呼び出しがコード内にあれば、唯一の hard break に直撃します。Roots・Sampling・Logging を使っている箇所も、非推奨とはいえ 12 か月以内に対応が必要なので棚卸ししておく必要があります。
対策の手順
該当箇所が見つかったら、以下の順番で移行を進めるのが現実的です。
- Tasks API の呼び出しを
tasks/gettasks/updatetasks/cancelへ書き換える（唯一の即時対応必須項目） - Roots の利用箇所をツールのパラメータや設定ファイルでの指定に置き換える
- Sampling を使っている箇所は、MCP 経由ではなくモデルの API に直接アクセスする実装に変更する
- Logging は標準エラー出力（stderr）か OpenTelemetry（分散トレーシングの標準規格）への出力に切り替える
- OAuth 2.1 に対応していない認証実装があれば優先度を上げて対応する
- クリティカルな環境では SDK バージョンをピン留めし、意図しない自動アップデートで v2 系に切り替わらないようにする
移行作業を効率化する手段として、リポジトリを走査して更新に関わる問題箇所を検出し、移行チェックリストを生成するツールも公開されています。CLI から実行する方法と、Claude Code の skill（Claude が呼び出せる拡張機能）として組み込む方法があり、後者は検出結果を Claude 自身が読み取って修正提案まで行える点で対応が早く済みます。手元で grep を使った棚卸しが済んでいれば、こうしたツールの出力と突き合わせて漏れがないか検証する使い方もできます。
確認と対応の優先順位まとめ
MCP のサーバーを運用している場合、まず initialize と Mcp-Session-Id への依存を grep で洗い出すところから始めるのが安全です。
Tasks API を使っている場合は唯一の hard break なので、他の対応より先に着手する必要があります。Roots・Sampling・Logging は 12 か月の猶予があるとはいえ、放置すると期限直前にまとめて対応する羽目になります。
SDK のバージョン確認と OAuth 2.1 対応も忘れずに棚卸ししておくと、後からの手戻りを防げます。プロトコルが状態を手放してシンプルになる分、実装側の棚卸しは今のうちに済ませておくのが安心です。