MCPが「番号をもらう」から「毎回名乗る」に変わる話
普段Claude Codeを使うとき、裏側ではMCP（Model Context Protocol）という規格が働いています。AIがカレンダーやSlack、社内ツールに安全に繋がるための共通の会話のルール、くらいの理解で毎日お世話になっています。そのMCPの中身が変わる、というニュースを読みました。今回はこれを、当事者というより「普段お世話になっている道の下の水道管が変わる」くらいの距離感で読み解いてみます。
元になったのは、TechCrunchの記事「AI’s most important protocol is getting a little bit easier to use」（Russell Brandom、2026年7月20日）と、そこで紹介されているArcade社のブログ「MCP ‘26: MCP Is Going Stateless. Here’s What That Means」（Nate Barbettini、同日公開）です。Arcadeは6月に6,000万ドルを調達した、Gmail・Slack・Salesforceなどの連携を専門にするスタートアップで、この変更の当事者に近い立場から説明を書いています。
何が変わるのか：「番号をもらう」関係から「毎回名乗る」関係へ
まず、変更点そのものを整理します（この記事の執筆時点で、この仕様はリリース候補（RC）です。正式版は2026年7月28日に公開予定なので、読むタイミングによっては状況が変わっている可能性があります）。
旧方式（ステートフル）
ここでいう「旧方式」は、複数の利用者やクライアントがHTTP経由でリモートのMCPサーバーに繋ぐ場合（Streamable HTTP）の話です。自分のPC上でClaude Codeが直接起動するstdio方式のローカルサーバーは、そもそもこのセッションIDのやり取り自体をしていません。
- クライアント（Claudeなど）がサーバーに「hello、私はこういうバージョン・機能です」と挨拶する
- サーバーが「じゃああなたはセッションID: XYZね」と番号を発行する
- 以降の全リクエストで、クライアントはこの番号を提示する。サーバーは番号を見て、同じプロトコル上のセッションに属するリクエストだと扱う
問題が起きるのはスケールしたとき
企業規模でMCPサーバーを運用すると、サーバーは1台ではなく複数台になり、ロードバランサーがリクエストを振り分けます。セッションの状態を、発行したマシンのメモリだけに置く単純な作りだと、他のマシンはそれを認識できません（複数マシンから参照できる共有のセッションストアを別途用意する手もありますが、その分の運用コストがかかります）。
- マシンAが番号XYZを発行する
- 次のリクエストがロードバランサーの都合でマシンBに飛ぶ
- マシンBは「XYZ？知らない番号ですけど」となる
MCP公式ブログによれば、旧方式のリモートMCPサーバーは、こうした事態を避けるために「スティッキーセッション（同じ利用者を常に同じマシンに固定する）」「共有のセッションストア」「ゲートウェイでの深いパケット検査」といった対応が必要でした。Arcadeの創業者Barbettiniも、これを「深刻な課題」と表現しています。スティッキーセッションは負荷分散を無効にするわけではありませんが、特定の利用者を特定のマシンに固定するぶん、負荷の再配分や障害時の切り替えが難しくなります。
新方式（ステートレス）
初回の挨拶（ハンドシェイク）自体を廃止し、以前は接続時に一度だけ交換していたプロトコルバージョンやクライアントの情報を、毎回のリクエストに載せて送る方式に変わります。実際には一部がHTTPヘッダー（プロトコルバージョンなど）に、一部はJSON-RPCリクエストの_metaという欄（クライアント情報や機能情報）に入ります。これはユーザー本人の認証情報ではなく、あくまで「このクライアントはこういうプロトコル・機能で話します」という自己紹介です。どのマシンが受けても、プロトコル上のセッションの記憶なしにリクエストを解釈できます。
なくなるのは、あくまでプロトコルが暗黙に抱えていたセッション状態です。買い物かごや、途中経過のある処理のように、アプリ側で本当に状態を持ち越したい場面はなくなりません。そこは、サーバーが明示的なID（例えばbasket_id）を発行し、クライアント側がそれを次のリクエストで提示する、という形に置き換わります。
これを自分なりの言葉に置き換えると、「サーバーに番号を提供してもらい、それを預かって使う関係」から「毎回、自分から自己紹介を提示するだけの関係」への転換だと思います。関係を”覚えておく”側の負担を消して、情報を”持ち歩く”側に寄せた、と言ってもいいかもしれません。
じゃあ最初からそうしとけばよかったのでは？
読んでいて素朴に浮かんだのがこの疑問でした。1台のサーバーに負荷が偏るリスクなんて、少し考えればわかりそうなものです。エンジニアが見落としていたのでしょうか。
Arcadeの記事を読み込むと、答えは「見落とし」ではなく「元の想定スコープの外側で使われ始めた」でした。
記事にはこう書かれています。MCPの初期設計は、VSCodeやSublimeのようなエディタが使う LSP（Language Server Protocol） を参考にしています。LSPは「1つのエディタ⇔1つのローカルプロセス」が前提の規格です。自分のPCの中でエディタと言語サーバーが1対1で会話するだけなので、記事いわく「ローカルマシン上で2つのプロセスがステートフルに喋るくらい、何の問題もない」。
つまりMCPが生まれた当初の主な使われ方は、「自分のPCで動くClaude Desktopが、自分のPCで動くローカルサーバーと1対1で話す」という世界でした。MCPの公式仕様書自身も、MCPはLSPから着想を得たと明記し、「ステートフルな接続」を基本プロトコルの特徴の一つに挙げています。サーバーが複数台に分散する使われ方をまだ主に想定していなかった時期なら、これは合理的な設計だったと読めます——ここから先は資料に書かれた開発者の意図そのものではなく、僕の解釈です。
ところがMCPは想定より速く普及し、自分のPCで動かす規模から、従業員1万人規模や数百万人の利用者を想定するクラウド運用へと広がりました（この規模感はArcade自身の顧客数の実績ではなく、記事中で挙げられている一般的な例示です）。Arcadeのような事業者は、まさにこの移行を支えるサーバーやゲートウェイを提供する立場にいます。ローカル1対1では正解だった設計が、後から出てきた使われ方には合わなくなった、という順番です。
これは、たぶんMCPに限った話ではありません。サーバー側に状態を溜め込む設計から、リクエスト側に自己完結した情報を持たせる設計への移行は、Web業界の一部でも見覚えがあります（もちろん、JWTのようなトークン方式にも失効管理など別のトレードオフがあるので、単純に「これが正解」という話でもありません）。初期スコープでは正しい設計判断が、想定より速い普及でスコープそのものが変わった瞬間に負債化する——PdMとして見ていても、わりとよくある展開だと思います。
個人として、この変更をどう受け取ったか
正直に言うと、この変更自体が自分の日々の使い方に直接影響することはほぼありません。自分がMCPを使うのは、Claude Codeから自分のPC上・あるいは限られた連携先に繋ぐ、比較的小規模な使い方だからです。Arcadeが直面している、大量の利用者が同時接続するクラウド運用の悩みは、今のところ他人事です。
ただ、この記事を読んで意識が変わった点が一つあります。それは、自分が便利に使っている規格の裏側にも、「誰かが今まさに壊れかけていて、直している最中の配管」がある、という感覚です。MCPは新しい機能が足されるニュースの方が目立ちますが、今回のような「地味だけど効く」仕様変更のほうが、実は普及の本気度を測る指標になる気がします。派手な新機能ではなく、負荷分散のような泥臭い部分を直しにいくというのは、それだけ「本番運用されている」証拠だからです。
Claude Codeを使いながらMCPサーバーを自分で設定するとき、これまでは「繋がればOK」くらいの理解で済ませていました。次に何か新しいMCPサーバーを触るときは、それがステートフルな古い方式なのか、ステートレスな新しい方式なのか、少し気にしてみようと思います。
まとめ
MCPのセッションID方式は、2026年7月28日公開予定の次期仕様（執筆時点ではリリース候補）でステートレス化されます。背景にあるのは、LSP由来のローカル1対1という前提が、Arcadeのようなクラウドホスト型の多数利用者運用というスケールに追いつかなくなったこと。変更の実質は「サーバーが番号を提供する関係」から「クライアントが毎回自分の情報を提示する関係」への転換で、これによって複数マシンでの負荷分散がやりやすくなります。
ただし、この変更は単一バージョン同士で見ればワイヤー上の互換性を壊す破壊的変更でもあります（2025-11-25版と2026-07-28版は、そのままでは直接話せません）。MCPにはバージョン交渉の仕組みがあり、新旧両方に対応したクライアント・サーバーやゲートウェイを用意すれば移行期間中は両方に対応できますが、既存の実装を持つ会社にとっては、この「二重対応」自体が書き直しのコストになる話でもあります。「使いやすくなる」の裏には、必ず「作り直す誰か」がいる、というのも覚えておきたいところです。
出典：TechCrunch “AI’s most important protocol is getting a little bit easier to use”（Russell Brandom, 2026年7月20日）／Arcade Blog “MCP ‘26: MCP Is Going Stateless. Here’s What That Means”（Nate Barbettini, 2026年7月20日）／MCP公式ブログ “2026-07-28 Release Candidate”／SEP-2567 “Sessionless MCP via Explicit State Handles”。