MCP 2026-07-28仕様公開：ステートレスなトランスポートへの転換

MCP 2026-07-28の仕様が更新されました。今回の大きな変更点は、トランスポートレイヤーのステートレス化です。これにより、システム構成がよりシンプルになり、スケーラビリティの向上が期待されます。

完璧だね。実際のツール呼び出し自体がステートレスなんだから。LLMがget_my_todosを呼んで、その次にadd_todoを呼ぶとき、実際にはメモリ上に何も保持してなくて、単にテキストがコンテキストウィンドウに入り直して（get_my_todosの結果）、次のツール呼び出しが行われるだけだし。

それにサーバーサイドでステートフルにするのって、どっちみちかなり不安定だよ。クライアントからの情報をどれだけの間メモリに保持するのか、接続をどれだけの間維持するつもりなのかって話になるしね。

皆さんこんにちは！MCPのリードメンテナの一人です。今日このリリースを出せて嬉しいよ。MCPサーバーをサーバーレス環境で動かしたいと考えていた人にとってはエキサイティングな変更になるはず。もちろん、他にもいい機能が盛りだくさんだから、質問やフィードバックがあればチームがサポートするよ！

数ヶ月前にMCPからHTTP/Statelessに移行したよ。個人的にはこれが正解だと思う。信頼性は上がるし、問題は減る。必要ならTOONのサポートも自然にできるしね。

ただ一つ疑問なのは、アーキテクチャ上で「チャンネル」をどう扱うかだね。Claude Codeを見た感じだと、完全にHTTPの世界に移行すると、サーバーが落ちて復帰したときにタイムアウトの問題が発生する。そのせいで自分用の内部MCPのスタブを書く羽目になってるんだ。個人的にはそれでいいんだけど、セマンティクスを整理するなら、失敗時にクライアントにどう動いてほしいのかという設計指針が明確になるとすごく助かるな。

素晴らしい改善だね。これまでセッションを管理するためにサーバーサイドで必要だった複雑さは、インフラ面でもチームへの教育面でも大きな負担になっていたから。

これこそあるべき姿だね。なぜサーバーに負担をかける必要があるの？記憶するのはクライアントの仕事で、サーバーじゃない。サーバーはリクエストに応えるためのもので、記憶するためのものじゃない。HTTPが最初からそうやって成功してきた理由もそこにあるしね。

素晴らしい改善だね。同時に、今のところMCP 1.xを使い続けることは可能なのかな？開発コストは馬鹿にならないしね。とりあえずStatelessなコア部分から手をつけて、少しずつMCP 2.xへ移行していくアプローチならいけそうかな？

正直に言うと、自分はこの機能を完全にスルーしてたし、職場の同僚の95%も全く触れてなかったよ。うちの会社はAIにどっぷりってわけじゃないからね。でも、この仕様ならようやく成熟してきた感じがして、サーバー開発をやってみてもいいかなって気分になった。まだ公開されているもの以外の具体的なユースケースは見つけられてないけど。

ついに来たか。

うちはMCPサーバーのゲートウェイ/レジストリ（Glamaって知ってる人もいるかもね）を運営してるんだけど、サーバーの状態を保持しなきゃいけないって理由だけでどれだけのバグや問題が発生してたか、言葉じゃ言い表せないくらいだよ。

この変更のおかげで、オープンソースのMCPサーバーを使ってもらうためのハードルがぐっと下がるはず。

今ちょうど、自分のMCPツールを全部HTTPに移行する作業をしてるんだ。call_httpというツールを一つ作って、APIを直接叩くようにする。そうすれば、何十年も前からあるステートレス性みたいな実績のあるパターンをそのまま活かせるからね。

現在MCPが使われているケースの大半で、MCPを使う必要性を感じないんだよね。

それよりも、スキルの詳細を書いたSKILL.mdと、curlコマンドを書いたリンク先の.mdファイルを用意するだけで十分いい結果が出るよ。単なるHTTP(S)だね。普段はデータ転送にステートフルなWebSocketプロトコルを好む僕が言うのもなんだけど、HTTPのステートレスなリクエスト・レスポンスモデルはLLMと相性が抜群なんだ。

HTTPはこの用途に最適だし、curlは超人気コマンドで、主要なコーディングモデルはみんな学習済みだからね。LLMってcurlを扱うのが異常に上手いんだよ。主要なOSには最初から入ってるし。もはやcurlコマンドがプロトコルになったと言ってもいい。

それに、ツールを正しく使うためには結局ドキュメントが必要だしね。多くのケースでMCPは不必要な手間を増やしてるだけな気がする。

バックエンドのコード環境には居場所があるかもしれないけど、ほとんどのユースケースはユーザーとAIの間に立つ中間層のような薄いアプリケーションだ。結局のところ、AIがフロントでツールがバックエンドという形になると思う。だからこそcurlなんだよ。

ユーザーとAIの間にプラットフォームを無理やり挟むと、余計な制約が増えて、相互運用性や統合のチャンスを減らすことになるんじゃないかな。