MCPが「ステートレス」になった話 — 2026年7月改訂版を追う
MCPとは（おさらい）
MCP（Model Context Protocol）は、AIエージェントが外部のツールやデータソースにアクセスするための標準プロトコルです。REST APIにおけるHTTPのような立ち位置で、モデルやフレームワークが違っても同じ形式でツールを呼び出せるようにする仕組みとして、この数年で急速に普及しました。
そのMCPの仕様が、2026年7月28日に大きく改訂されました。これは公開以来最大級の変更で、実際に触ってみると設計思想がかなり変わっていることが分かります。この記事では、何がどう変わったのかを整理します。
最大の変更点：セッションが消えた
これまでのMCPは、クライアントとサーバーの間で initialize ハンドシェイクを行い、Mcp-Session-Id というセッションIDを発行して、そのセッションに紐づく形で通信していました。ロードバランサーの背後に複数のサーバーインスタンスを置く場合、同じセッションのリクエストは同じインスタンスに届くよう「セッションアフィニティ」を維持する必要がありました。
新しい仕様では、このハンドシェイクとセッションIDがプロトコルのコアから完全に削除されました。どのMCPリクエストも、どのサーバーインスタンスに届いても処理できるようになっています。具体的には：
- クライアントはプロトコルバージョンや対応機能を
_metaフィールド経由で伝える - サーバーは
server/discoverエンドポイントを実装する - リクエストには
Mcp-MethodとMcp-Nameヘッダーが付き、ロードバランサーはボディを見なくてもルーティングできる
これにより、MCPサーバーを水平スケールする際にセッションアフィニティを考える必要がなくなります。素朴に複数インスタンスを並べてラウンドロビンするだけで動く、という設計です。
一つ注意点として、「プロトコルがステートレスになった」ことと「アプリケーションがステートレスであるべき」ことは別の話です。もしサーバー側で呼び出しをまたいで状態を持ちたい場合は、明示的なハンドル（ID）を発行し、それをモデルが通常の引数として次の呼び出しに渡す、という形で自分で管理する必要があります。プロトコルはもう面倒を見てくれません。
認証まわりの強化（6つのSEP）
今回の改訂では、認可（authorization）まわりも大きく手が入りました。OAuth 2.0 / OpenID Connectの実際の運用実態に合わせて仕様を整合させる、6つのSEP（Spec Enhancement Proposal）が取り込まれています。
代表的なものとして、クライアントが iss パラメータを RFC 9207 に従って検証するようになりました。これは、MCPの「1クライアント・複数サーバー」という構成特有の、いわゆる mix-up attack（どのサーバーからのレスポンスか混同してしまう攻撃）を防ぐためのものです。
ただ、実際に触っていて気づいたのですが、この6つのSEPはすべて**ログイン時（ハンドシェイク時）**の話です。どのトークンを誰に発行するか、という部分は厳格になった一方で、「個々のツール呼び出しごとに、このロールはこの操作をしてよいか」をサーバー側でチェックする仕組みは、仕様としては定義されていません。ステップアップ同意（追加の同意確認）はログイン時に何を承認するかを決めるものであって、1時間後の500回目のツール呼び出しで何が起きているかは関知しない、というのが現状です。
このギャップについては、実際に手を動かしてMCPサーバーを作ってみた話を次回以降の記事で書く予定です。
キャッシュもプロトコルレベルに
もう一つの変更点として、list や read 系のレスポンスに ttlMs（有効期限）と cacheScope（キャッシュの共有範囲）が付与されるようになりました。HTTPのCache-Controlに近い発想で、クライアント側は「このレスポンスはあと何ミリ秒使い回してよいか」「他のユーザーと共有してよいキャッシュか」を明示的に判断できます。
これまでキャッシュ戦略は各実装が独自に考える必要がありましたが、プロトコルレベルでヒントが提供されるようになったのは実用上ありがたい変更です。
現状使ってみて
Python SDKはすでにv2のベータ（mcp==2.0.0b1、pip install --pre が必要）が公開されており、安定版は7月27日にリリース予定とされていました（記事執筆時点では既にリリース済みのはずです）。ただしベータ版だけあって、ドキュメントはまだかなり薄く、実際に動かしながら help() や dir() でAPIを確認する場面が多々ありました。
クライアント側の対応も一様ではありません。手元で使っている範囲では、Pydantic AIなどいくつかのフレームワークはまだ旧バージョン（mcp 1.x）に依存していて、新仕様への追従はこれからという状況でした。実装をまたいで移行期にあるプロトコルを触るのは、ドキュメントを読むより手を動かして確認する場面が多く、なかなか骨が折れますが、その分学びも多いです。
まとめ
- セッション/ハンドシェイクがプロトコルのコアから削除され、真にステートレスなサーバーが組めるようになった
- 認可はログイン時のハードニングが中心で、呼び出し単位の認可は仕様のスコープ外
- キャッシュのヒント（
ttlMs/cacheScope）がプロトコルレベルで提供されるようになった - SDKはまだベータで、ドキュメントより実装を読む場面が多い
次回は、この新しい仕様の上に「呼び出しごとのガードレール」を自作でどう組んだか、実際に作ったプロジェクトの話を書きます。
参考リンク（公式）
- 仕様変更点（Changelog）: https://modelcontextprotocol.io/specification/2026-07-28/changelog
- リリース公式アナウンス: https://blog.modelcontextprotocol.io/posts/2026-07-28/
- Release Candidate解説（6つのSEPの背景）: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- GitHubリポジトリ: https://github.com/modelcontextprotocol/modelcontextprotocol