AI最新情報読了 7 分

MCPプロトコル、明日ステートレス接続を正式化 GitHubサーバーも即対応

Shiritomo編集部 @shiritomoAI_jp 2026年7月27日更新

「セッションIDの管理が、明日から不要になる」。
AI開発者のあいだで、そんな地味だけど実務に直結する話が静かに広がっています。
舞台はMCP（Model Context Protocol：AIがデータベースやAPIに接続するための共通規格）。
ClaudeやChatGPTのようなAI（LLM：大規模言語モデル）が外部サービスとやり取りするための「つなぎ役」の仕様が、2026年7月28日に大きく変わります。
ふだんAIツールを業務で使っている人や、社内でMCPサーバーを運用している人にとっては、明日から接続の作り方が変わるという話です。

先に結論をまとめると：
– MCPの新版（2026-07-28）で、接続方式がステートフルからステートレスに変わります
– セッションID管理と接続時の初期化処理（ハンドシェイク）が廃止される破壊的変更です
– GitHubのMCPサーバーはすでに先行対応済みで、接続が速くスケールしやすくなっています

何が起きたのか（Xでの盛り上がり）

MCPは、Anthropicが2024年11月に公開した規格です。
AIとデータベースやAPIをつなぐたびに個別の統合コードを書く必要があった状態を、統一プロトコルで解消することを目指してきました。
今回の更新はその中核である接続方式そのものに手を入れる内容で、technology系のXユーザーの間で反応が広がっています。

Publickeyの記事タイトルをそのままシェアした投稿は、公開から半日ほどで36件のいいねと7件のリツイートを集めました。

いい話

MCP仕様が明日アップデート、7月28日版MCPからはステートレスな接続が正式仕様に。GitHub MCPサーバが早くも対応発表－ Publickey https://t.co/x7ZHO15a1F

— Yusuke Wada (@yusukebe) 2026年7月27日

「明日アップデート」というタイミングの近さと、GitHub MCPサーバーが早々に対応を発表したという事実が、拡散の火種になったようです。
ただ、いいね数だけを見ると規模は控えめで、まだ「一部の開発者が気づき始めた」段階に見えます。
実際に何が変わるのかを一次情報で確認すると、単なる仕様の微調整ではなく、接続の仕組みそのものを作り直す変更だと分かりました。

調べて分かったこと（調査・深掘り）

ステートレスとステートフル、何が違うのか？

これまでのMCPは「ステートフル」な通信でした。
クライアント（AIツール側）とサーバーが接続を開始する際に、initializeという初期化のやり取り（ハンドシェイク）を行い、Mcp-Session-Idというヘッダーでセッション（一連のやり取りのまとまり）を識別・管理していました。
つまりサーバー側は「誰が今どんな状態で接続しているか」を覚えておく必要があったわけです。

新版の2026-07-28仕様では、この仕組みが丸ごと廃止されます。
Publickeyの記事によれば、新方式では各リクエストが自己完結した情報を持つようになり、「MCPクライアントからのリクエストはどのMCPサーバに到着しても処理されるようになります」。
サーバーが接続状態を覚えておく必要がなくなるため、複数台のMCPサーバーとシンプルなロードバランサーを組み合わせて、容易にスケールできる構成が実現します。

なぜ今、この変更が必要だったのか？

セッション管理には見えないコストが伴います。
サーバー側は接続ごとにセッションIDをデータベースなどに書き込み、リクエストが来るたびにそれを読み出して状態を確認する処理が必要でした。
接続数が増えれば増えるほど、このオーバーヘッドが積み重なります。

この点を実務者視点で言語化していたのが、次の投稿です。

明日からMCPの仕様が変わる。7月28日版からステートレス接続が正式仕様。これで接続維持のオーバーヘッドが消えて、サーバー側のスケールやリトライ耐性が劇的に上がる。自分は早めにGitHub MCPサーバの対応版に乗り換えて、接続切れによるAIの迷走をゼロにする運用に切り替える。
— ARIA｜AIで仕事を自動化する人 (@aria_ai_tools) 2026年7月27日

投稿者は「接続維持のオーバーヘッドが消えて、サーバー側のスケールやリトライ耐性が劇的に上がる」と述べ、GitHub MCPサーバーの対応版への早期移行を明言しています。
この投稿自体のいいね数は1件と少ないですが、内容は今回の変更が解決しようとしている課題を的確に突いていると言えるでしょう。

GitHubサーバーは何を変えたのか？

GitHubのMCPサーバーは、正式仕様の公開に先立って7月23日に対応を発表しました。
CodeZineの報道によれば、Redisセッション（接続状態を一時的に保持する仕組み）を廃止し、初期化時のデータベース書き込みと呼び出しごとのデータベース読み出しが不要になったとのことです。
詳細なペイロード（送受信データの本体部分）を毎回検査する代わりに、必要な情報をHTTPヘッダーから直接取り出す方式に切り替えたことで、処理が軽くなったと説明されています。

主要なSDK（開発キット）は後方互換性を保っているため、既存ユーザーがすぐに対応を迫られるわけではない点も確認できました。

導入時に注意すべき点はあるか？

一方で、現場から疑問の声も出ています。

MCP がステートレスになる変更、まだ詳細読んでないけど、最近 n8n 経由のセッションに問題があって自前の MCP サーバーをマルチセッション対応したばかりなんだが、どうなるんだろう、ステートレス自体は歓迎なんだけど、"self-contained" が具体的にどういうものかがわからん
— nunulk (@nunulk) 2026年7月27日

この投稿者は、n8n（ワークフロー自動化ツール）経由のセッションで問題が起きたため、自前のMCPサーバーをマルチセッション対応にしたばかりだといい、ステートレス化そのものは歓迎する一方、新仕様が使う「self-contained（自己完結）」という言葉が具体的に何を指すのか分からない、と率直に書いています。
仕様変更の方向性には賛成でも、実装レベルの詳細がまだ追いついていない開発者が一定数いることがうかがえます。
破壊的変更（既存の実装が動かなくなる可能性のある変更）である以上、自前でMCPサーバーを運用している場合は、リリースノートの原文を確認してから移行するのが安全そうです。

Shiritomo編集部の考察：明日からやることは2つ

SNS上の反応規模はまだ小さいものの、この話題は「バズ」ではなく「実装に直結する情報」として広がっている点が特徴的です。
いいね数十件程度でも、拡散元がPublickeyという技術メディアで、拡散者に開発者が多いという構造は、後日じわじわと参照され続けるタイプの情報拡散だと考えられます。
ニュースの即時性よりも検索経由での再訪が伸びやすい話題でしょう。

明日から実務担当者がやるべきことは、大きく2つに絞れます。
ひとつは、自社でMCPサーバーを運用している場合、新仕様のリリースノートを確認し、セッション管理に依存した独自実装が残っていないかを点検すること。
もうひとつは、GitHub MCPサーバーのように外部提供のMCPサーバーを利用している場合、対応版への切り替えタイミングを見極めることです。
仕様変更のたびに現場が右往左往しないためには、公式発表と実装者の生の声を両方追う習慣が欠かせません。