← AIバイブコーディングTips 一覧へ Protocol / Claude Blog 公式

MCPがステートレスになった

2026年7月28日、MCP(Model Context Protocol)の仕様が更新された。双方向のステートフルなプロトコルから、1回のHTTPリクエストで完結するリクエスト/レスポンス型へ。従来は「セッション初期化→セッションID取得→ツール呼び出し」の2段階が必須だったが、それが1回で終わる。自作MCPサーバーを持つ・持とうとしている人向けに、何が変わったのかを読む。

この記事で手に入るもの

従来の2段階セッションフローと新しい1リクエストフローの違い、月間4億SDKダウンロード(前年比4倍)950以上のMCPサーバーという採用規模の実数、そして自作MCPサーバーの実装をどう点検すればいいかのチェックリスト。

01 — 何が変わったか

「2リクエスト必須」だった手続きが、1回で終わるようになった

これまでのMCPは双方向のステートフルなプロトコルだった。クライアントがサーバーに接続するとき、まず初期化リクエストを送ってMcp-Session-Idを受け取り、それを使って初めてツール呼び出しができる——という2段階の手続きが必須だった。セッションIDが発行された時点で、サーバー側は「このクライアントとの会話状態」をどこかに保持し続けなければならない。

2026-07-28仕様では、この手続きが単一のHTTPリクエストで完結する「リクエスト/レスポンスモデル」に置き換わった。Claude公式ブログはこれを「Servers can now deploy on serverless and edge infrastructure」と説明している。セッションという状態を持たなくてよくなったことで、MCPサーバーは普通のステートレスHTTPワークロードとして動かせるようになる。


02 — 変化点を分解する

具体的に何が消え、何が強化されたか

公式ブログが挙げている変更点を、実装に効く順に3つに絞って読む。

01

セッション管理コードがまるごと不要になる

セッションIDの発行・保持・タイムアウト処理・再接続時の引き継ぎ——ステートフル設計を選んだ瞬間に降ってくるこれらの実装が、仕組みごと要らなくなる。サーバー側の複雑さの多くは、突き詰めれば「誰の会話がどこまで進んでいるか」を覚えておく仕組みそのものだった。

02

認可がOAuth 2.0/OIDCの本番運用にそのまま乗る

公式は「Authorization now aligns with production OAuth 2.0 and OIDC deployments, so MCP servers connect to enterprise identity systems like Entra or Okta without workarounds」と述べている。EntraやOktaのようなエンタープライズID基盤に、独自の回避策なしでつながる設計に強化された。

03

サーバーレス・エッジへのデプロイが現実的になる

状態を持たないなら、リクエストごとに別のインスタンスが処理しても問題ない。これはサーバーレス関数やエッジワーカーの動作モデルそのものであり、常時起動のプロセスを維持する必要がなくなる。個人開発でMCPサーバーを運用コスト込みで検討していた人には、選択肢が広がる変更にあたる。


03 — 採用規模

すでに月間4億ダウンロード、950以上のサーバーが動いている

MCPは2024年後半の登場からすでに一定の規模で使われているエコシステムだ。公式ブログによれば、MCP関連SDKの月間ダウンロード数は4億件(400M)で、前年比4倍に伸びている。Claudeのディレクトリには950以上のMCPサーバーが並ぶ。

ここが核心。これだけの規模で動いているプロトコルが仕様の根本部分(接続モデル)を変える、という点は軽く見ない方がいい。今から新しくMCPサーバーを書くなら、ステートフル前提の実装例をそのまま真似ない方が安全になる。


04 — 実践者の反応

Simon Willisonはすでに手を動かしている

Simon Willisonは新仕様を「クライアント・サーバー双方の観点から実装がはるかにクリーンになる」と評価し、公開直後に2つのツールを作っている。1つはMCPサーバーを対話的に調査できるPython製CLImcp-explorer。もう1つはDatasetteインスタンス向けのMCPプラグインdatasette-mcpで、list_databases()get_database_schema()execute_sql()という3つのツールを提供する。

実例として、Claudeとの会話の中でシステムが質問に答えるために7つの個別SQLクエリを自律的に実行した、という具体例も紹介されている。ステートレス化によってサーバー側の実装がシンプルになったことが、こうした「ツールを素早く試作して動かす」スピード感に直結している様子がうかがえる。


05 — 実務への翻訳

自作MCPサーバーがあるなら、何を点検すればいいか

「対応必須」と身構える前に、まず自分の実装がどちら側かを確かめる。

セッションIDに依存したコードがないか探す初期化リクエストで受け取ったMcp-Session-Idを、以降のリクエストの識別・状態の紐付けに使っている箇所を洗い出す。
サーバー側でグローバルな状態を保持していないか確認する接続中クライアントの一覧やインメモリのセッション辞書のような「プロセスが生きている前提」の実装は、リクエスト単位で完結する設計へ書き換える対象になる。
常時起動プロセスを前提にホスティングを組んでいないか見直すステートレス化できるなら、サーバーレス関数やエッジワーカーへの移行でホスティングコストを下げられる余地がある。
使っているMCP SDK・フレームワークのバージョンを確認する新仕様への対応状況はSDKごとに異なるため、自分が依存しているライブラリの変更履歴を先に確認する。

06 — 留保すること

断定できない部分は、断定しない

今回参照した公式ブログとSimon Willisonの記事には、旧仕様(ステートフル)のサーバー・クライアントが新仕様下でどう扱われるか——後方互換性の詳細についての明示的な記述は見当たらなかった。既存のMCPサーバーを運用している場合、移行のタイミングや猶予期間は各SDK・実装のドキュメントを個別に確認する必要がある。

出典: Claude Blog — Bringing MCP 2026-07-28 to ClaudeSimon Willison's Weblog — Stateless MCP