Model Context Protocol、通称MCPの2026-07-28仕様が公開されました。
ひとことで言うと、「AI向けの共通接続ルール」が、よりWebらしく、より実運用向けに育った更新です。
MCPは、AIエージェントやツールが外部サービスとやり取りするための共通規格です。たとえば、ファイルを読む、検索する、社内データベースに問い合わせる、承認を取る。そういう動きを、アプリごとにバラバラに作らずに済むようにする土台ですね。今回の仕様変更は、見た目以上に大きいです。単なる機能追加ではなく、「接続の仕方そのもの」を組み替えているからです。
Mcp-Method と Mcp-Name というHTTPヘッダーでルーティングしやすくなったlist系レスポンスがキャッシュ可能になり、一覧取得のムダが減る今回の主役は、やはり stateless 化です。
従来のMCPは、双方向でつながり続けるようなイメージが強く、サーバー側も「このクライアントとの会話の続き」を覚えている前提がありました。ところが新仕様では、その考え方をかなり手放しています。
初回の initialize / initialized のやり取りは廃止され、Mcp-Session-Id もなくなりました。代わりに、1回1回のリクエストが自己完結します。プロトコルのバージョン、クライアント情報、能力情報はリクエストごとに持ち運ばれる。これ、地味に見えてかなり強いです。
なぜかというと、サーバーをスケールさせやすいからです。
今までのように「同じ利用者は同じサーバーに当たってほしい」「セッション情報を共有しないと困る」という事情が減ります。普通の round-robin ロードバランサーの後ろに、複数台のMCPサーバーを並べやすくなる。運用の現場では、こういう話が本当に効きます。華やかな機能より、こっちのほうが現実にはありがたいことも多いです。
もちろん、アプリケーションとして状態を持てないわけではありません。
仕様文でも触れられているように、必要なら明示的な handle をツールから発行して、それを次の呼び出しで渡す形にできます。セッションに“隠す”のではなく、モデルに見える形で持ち回る。これはかなり筋がいい設計だと思います。裏でこっそり覚えるより、表で見えるほうがAIには扱いやすいはずです。
新しい MRTR (Multi Round-Trip Requests) は、今回の改訂でかなり面白い部分です。
これまでのMCPには、途中でユーザー確認が必要になったときに、持ちっぱなしのストリームを前提にした仕組みがありました。たとえば「この操作、本当に実行していい？」とか、「不足しているパラメータを教えて」といった場面です。ところが、常時接続の双方向ストリームは運用負荷が高い。そこでMRTRは、その面倒を減らしています。
流れとしては、サーバーが resultType: "input_required" を返し、どんな入力が必要かを明示します。クライアントは元の呼び出しを、回答を添えて再送する。つまり、会話の往復を「接続しっぱなし」ではなく、「必要なときに何回か往復する」形にしたわけです。
これはWebの世界にかなり近い。
常時つながることにロマンはあるけれど、実際には重いし壊れやすい。そこを一段現実に寄せた感じがあります。個人的には、こういう変更のほうが長生きしやすいと思います。
Mcp-Method と Mcp-Name というHTTPヘッダーが追加されたのも、運用目線ではかなり重要です。
今までは、HTTPの中身のJSONを見て「これはどのツール呼び出しだろう」と判定する必要がありました。でもヘッダーに方法名やツール名が乗れば、gateway、rate limiter、WAF みたいな中間層が扱いやすくなります。
要するに、HTTPの入り口でルーティングや制御がしやすくなるということです。
こういう変更は、一見すると地味です。でも本番運用では地味な改善ほど効きます。
たとえば「特定のツールだけレート制限したい」「この名前の操作は特定のバックエンドへ回したい」といった話は、現場では普通に出てきますから。
tools/list、prompts/list、resources/list、resources/read のレスポンスに、ttlMs と cacheScope が入るようになりました。
これは簡単に言うと、「この一覧はしばらく使い回していいですよ」というヒントです。
一覧系のAPIって、何度も叩かれがちです。
しかも、毎回ほぼ同じ結果が返ることも多い。ならキャッシュしたほうがいいに決まっている。そこを仕様として明示したのは、とても素直な改善です。
さらに、順序が決定的になるので、クライアント側のキャッシュや、上流のprompt cacheが安定しやすくなります。こういう“安定性のための細工”は、派手ではないけれど、プロダクションでは本当に大事です。結果の順番がぶれるだけで、キャッシュヒット率や差分処理が微妙になることがありますから。
今回の仕様で、セキュリティ面はかなり磨かれています。
ここは地味に見えて、実際には一番ありがたいかもしれません。
まず、authorization server は iss パラメータを返し、クライアントはコードを使う前にそれを検証する必要があります。これは authorization-server mix-up と呼ばれる混乱を防ぐためです。簡単に言うと、「どの認可サーバーが出したトークンなのか」を取り違えにくくする仕組みですね。
それから、Dynamic Client Registration (DCR) の扱いも変わりました。
デスクトップアプリやCLIアプリが localhost にリダイレクトする時に、認可サーバーが弾いてしまう問題に対して、application_type を設定するようにしています。OAuth系のフローで「なぜか redirect_uri エラーになる」経験がある人は、ああ、こういう事情かと思うはずです。開発者のつまずきポイントを、かなり正面から潰しに来ています。
さらに、クライアント資格情報は、それを発行した issuer に紐づくようになり、別の認可サーバーで使い回せません。これも当たり前に聞こえて、実は大事です。
そしてDCR自体は、今後は CIMD (Client ID Metadata Documents) に移る方向で、正式に deprecated になりました。しばらくは動くけれど、新規実装では採用しないほうがいい、という立ち位置です。
MCPが「試してみる便利な規格」から、「企業で雑に使っても事故りにくい土台」に寄ってきた感じがします。私はこの変化、かなり本質的だと思います。AI時代って、モデルの賢さよりも、認可と運用の詰めのほうが先にボトルネックになることが多いので。
Tasks は experimental core から外れ、io.modelcontextprotocol/tasks という extension になりました。
中身としては、tasks/get と tasks/update が用意され、ポーリング型で扱います。さらに、通知の受け取り方も整理されました。
長時間走る処理や、後で結果を見に行くタイプのワークフローは、AIエージェントではよく出ます。
たとえば、重い解析、外部処理、承認待ち、非同期な自動化。こういうものをきちんと扱う仕組みが正式化されたのは、かなり意味があると思います。
しかも Tasks は、AWS が最初の公式MCP extensionのひとつとして貢献したと説明されています。MCPが「チャット的な道具」から「長く動く業務基盤」へ寄っていく流れが、ここに出ています。
非推奨になったものもあります。
Roots、Sampling、Logging は deprecated。旧HTTP+SSE transport も正式にお役御免です。
ただし、すぐ壊すわけではありません。少なくとも12か月は使えるので、いきなり全部止まる話ではない。ここは実務的です。仕様変更で一番困るのは「明日から動かない」ことなので、移行の猶予をちゃんと設けているのは好感が持てます。
とはいえ、新規実装はもう古い仕組みに乗らないほうがいいでしょう。
今回の方向性を見ると、MCPは“細い互換性を残しながら、新しい骨格へ誘導する”動きに入っています。
Tier 1 の SDK、つまり TypeScript / Python / Go / C# は、すでに 2026-07-28 に対応しています。
Rust SDK は beta 対応です。
実際に開発する人にとっては、仕様書よりSDKの対応状況のほうが大事だったりします。仕様が立派でも、手元のライブラリが追いついていなければ何も始まらないからです。その意味で、主要言語が一斉に更新されているのは心強いですね。
もちろん、破壊的変更があるぶん移行コストはあります。特に session identifier に依存していた人は、手当てが必要です。ただ、公式側もそのへんは想定していて、移行ノートを出しています。面倒ではあるけれど、無茶な変更ではない、という印象です。
私が一番面白いと思うのは、MCPが「AI専用の特殊な仕組み」から、「Webの流儀に沿った基盤」へ寄ってきたことです。
stateless、cacheable、routable、secure。
この4つにちゃんと寄せたのはかなり強い。AIの世界はどうしても“とりあえず動く”実装が先行しがちですが、そこで本気で運用性を取りにいっている。これは、MCPが実験段階を超えつつあるサインではないでしょうか。
一方で、ここまで大きく変えると、既存実装の移行は当然しんどいです。
でも、しんどさを先送りにするより、今まとめてやるほうが長期的にはマシ、という判断もわかります。とくに企業利用が増えるほど、セッション前提の複雑さや認可の曖昧さは、あとで必ずツケになりますから。
MCPは、もう「面白い新規格」ではなく、かなり本気のインフラに近づいています。
今回の仕様改訂は、その事実をかなりはっきり示したアップデートだと思います。