MCP（Model Context Protocol）は、AIエージェントが外部のツールやファイル、サービスにアクセスするための共通ルールだ。ざっくり言うと、「AIに何をどう頼むか」を標準化するための通信規格である。
今回の元記事が面白いのは、単なる機能追加の話ではなく、MCPの骨格そのものが変わったと指摘しているところだ。いちばん大きいのは、これまで前提だった「セッションを持ち続ける」方式をやめたこと。これでMCPは、かなりHTTPらしい、軽くて扱いやすい形に寄ってきた。
元記事の中心はここだ。以前のMCPは、クライアントがまず initialize して、そのあと同じ session を保ちながらやり取りする仕組みだった。サーバー側は Mcp-Session-Id のような情報を頼りに、「この通信はあの会話の続きだ」と覚えていなければならない。
これが何を面倒にするかというと、サーバーを複数台並べたときだ。普通のHTTPなら、ロードバランサーが適当に振り分けてくれてもそれなりに動く。でもセッションを持つ設計だと、「前回と同じユーザーの通信は、必ず同じサーバーに送ってね」という sticky routing が必要になる。あるいは Redis のような共有ストアにセッションを置いて、どのサーバーでも拾えるようにしないといけない。
正直、このへんは運用する側からするとかなりしんどい。機能そのものより、それを支えるための裏方の面倒が大きいからだ。元記事が「実運用している人ほどここが重要」と強く言っているのは、かなり納得感がある。
今回の仕様変更では、その前提を捨てた。各リクエストが、必要な情報を自分で全部持ってくる。言い換えると、「この1回のリクエストだけで意味が通る」形になったわけだ。これが stateless、つまり状態を持たない設計である。
この変化は地味に見えて、実際にはかなり大きい。サーバーは長生きし続ける必要がなくなり、1回のリクエストを受けて返すだけの関数のようにも動かせる。サーバーレスやエッジ環境に向く、というのはまさにその通りだと思う。MCPがようやく「現代のインフラに乗る」感じになった。
「でも、途中で追加情報を聞きたいときはどうするの？」という疑問は自然だ。ここもちゃんと置き換えられている。
新しい仕様では Multi Round-Trip Requests という考え方が入った。これは、サーバーが途中で「input_required」という結果を返し、何が足りないかを示す。クライアントはその内容を見て、元の呼び出しをもう一度、必要な入力を添えて投げ直す。
つまり、昔のように1本の接続をずっと握り続けるのではなく、独立したリクエストを何回か往復させる形に変わった。人間の会話にたとえると、電話を切らずに話し続けるのではなく、メッセージを送り合って会話を進める感じだ。
これ、設計としてかなりきれいだと思う。通信を長く持ち続けないので、インフラが単純になる。しかも「対話的な処理」はちゃんと残る。古い仕組みを壊しただけではなく、必要な体験を別のやり方で残しているのがうまい。
個人的に「お、これは実用的だ」と思ったのがここだ。tool list、prompt list、resource list などに ttlMs と cacheScope が付けられるようになった。要するに、「この一覧は何ミリ秒まで再利用していい」「どの範囲でキャッシュしていい」とサーバーが明示できる。
今までこの手の情報は、クライアント側がかなり曖昧に扱いがちだった。毎回取りに行けば安全だけど無駄が多い。ずっと保存しておけば速いけど、サーバー側が変化したときに古い情報を使ってしまう。どっちも気持ち悪い。
そこへ TTL が入ると、話はずっとシンプルになる。サーバーが「このくらいの時間なら古くならない」と言い、クライアントはそれに従う。HTTPキャッシュが長年やってきたあの基本を、MCPもようやく持った、という感じだ。
地味だが、こういう変更は効く。特にエージェントのように同じサーバーに何度もアクセスする場面では、無駄な往復が減るだけで体感がかなり違うはずだ。
セキュリティ面の変更も見逃せない。元記事では、OAuth / OIDC の扱いがかなり強化されたと説明している。
まず、認可サーバーは RFC 9207 で定められた iss パラメータを返す必要があり、クライアントはそれを検証しなければならない。これはざっくり言うと、「本当にその認可サーバーから来た許可なのか」を確認する仕組みだ。こうしないと、別の認可サーバーとの取り違えを悪用する mix-up attack の余地が残る。
さらに、client credentials は発行元の認可サーバーに結びつけられる。つまり、あるサーバーでもらった資格情報を、別のサーバーで使い回すことができない。これは当然といえば当然だが、プロトコルとして明文化されるのは大事だ。
ローカル開発でよくある localhost redirect も、ちゃんと扱いやすくなった。デスクトップアプリやCLIアプリが application_type を宣言して、ローカルのコールバックを許容できるようになったのだ。現場目線だと、こういう細かいところの整備がいちばんありがたい。理想論より、実際に開発者が詰まる場所を分かっている感じがある。
今回の仕様では、いくつかの機能が正式に整理されたり、逆に段階的に古くなったりしている。
たとえば Dynamic Client Registration (DCR) は、現在は使えるものの、将来的には Client ID Metadata Documents に置き換えていく方針だ。これは、クライアントが動的に自分を登録する代わりに、静的なメタデータ文書を公開する形。仕組みとしては少し落ち着いた方向だと思う。
ただし、いきなり切り替えるわけではない。DCR は移行期間中は残るし、HTTP+SSE の旧トランスポートや、Roots / Sampling / Logging も最低12か月の猶予付きで deprecated になっている。ここはかなり現実的だ。MCPはすでに本番利用が多いので、全員に「明日から新方式ね」は無理がある。仕様策定者がそこを分かっているのは好感が持てる。
Tasks は experimental から抜けて、io.modelcontextprotocol/tasks という正式な versioned extension になった。長時間かかる処理を tasks/get でポーリングしたり、tasks/update で更新したりできる。AIの世界は短い応答だけでは回らないので、こういう“長い仕事”の扱いがちゃんとしたのは意味がある。
さらに MCP Apps や Enterprise Managed Authorization も extension として入った。ここで重要なのは、今後の拡張が「コア仕様を毎回いじる」のではなく、extension framework に乗る道筋ができたことだと思う。プロトコルは大きくなるほど、コアを太らせすぎない設計が大事になる。
元記事がやたら強調しているのは、MCPの規模だ。SDK全体のダウンロード数は月間で約5億近く、年初から4倍になったという。TypeScript と Python の SDK はそれぞれ累計10億超え。しかも TypeScript、Python、Go、C# はすでに新仕様対応済みで、Rust も beta だ。
この数字、なかなかすごい。MCPはもう「一部の人が試している新技術」ではない。Claude Code のような実際のツール連携の裏側で、かなり太いインフラとして使われている。だからこそ、今回の stateless 化は単なる設計上の改善ではなく、運用コストや導入ハードルを下げる大きな転換点になる。
個人的には、ここがいちばん面白い。プロトコルって、流行っているうちは機能追加の話ばかり注目されがちだ。でも本当に成熟してくると、「どうやって壊さずに運用しやすくするか」が主役になる。MCPは今、その段階に入ったのだと思う。
今回の変更を一言でいうなら、MCPが「理想の実験」から「本気で使うための道具」に寄ってきた、ということだろう。
stateful な設計は、最初は分かりやすい。会話の連続性も表現しやすい。でも運用が重い。load balancer、shared session store、sticky routing、そういう裏方がどんどん必要になる。今回の仕様は、そのつらさをかなり大胆に切り捨てた。
その代わりに、リクエストは自己完結し、キャッシュは明示され、セキュリティは締められ、拡張は extension に逃がす。設計としてはかなり筋がいい。派手さはないけれど、実際に使う人にはこっちのほうがずっと効く。そういう変更だと思う。
参考: MCP Goes Stateless: What the 2026-07-28 Spec Actually Changes
