「ステートレスコア」は具体的に何を変え、開発者が従来対処しなければならなかった問題とどう関係しているのか？
旧仕様では、MCPは双方向・ステートフルな設計であり、サーバーは各接続の状態（その接続が現在どのステップまで進んでいるか、前回のやり取りでどのような文脈が残されたかなど）を継続的に追跡しなければならなかった。この設計は、長時間接続を維持する従来型のサーバーアーキテクチャにとっては比較的自然なものだったが、同時に、サーバーレス環境のような「使い終わったら破棄される」インフラには容易にデプロイできないことも意味していた。サーバーレスアーキテクチャのインスタンスは短命であり、長期間状態を保持することができないためである。
新仕様はプロトコルをリクエスト／レスポンスモデルに変更し、各やり取りは前回の接続状態に依存しない独立したリクエストとなる。これは、サーバーが状態を維持するためだけに継続的に稼働し続ける必要がなくなり、サーバーレスやエッジコンピューティングのインフラに直接デプロイして、トラフィックに応じて弾力的にスケールできるようになることを意味する。開発者にとっては、これによって本来自分で状態管理の仕組みを設計しなければならなかった負担が取り除かれ、MCPサーバーを構築・運用する技術的なハードルが直接下がることになる。
なぜ今回の仕様更新は「これまでで最も重要な仕様リリースの1つ」と表現されているのか、その根拠は何か？
この評価には具体的な数字の裏付けがある。MCPの月間SDKダウンロード数はすでに4億回を突破しており、今年だけで4倍に成長した規模である。これは、MCPがもはや実験的でニッチなプロトコルではなく、本番環境を支える広く採用されたインフラ標準になっていることを意味する。あるプロトコルの採用規模がこの水準に達すると、迅速な反復開発のために初期に行われた設計上の選択（ステートフルな接続など）が、規模拡大時の限界として現れ始める。これが、プロトコルがこの段階まで進化すると、漸進的な小さな修正ではなく、根本から作り直すような大きな変更が現れる理由でもある。
今回の更新で、本番環境でよく使われるOAuth 2.0／OIDCといった認証標準がプロトコル自体に組み込まれたことも、同じ文脈を反映している。プロトコルの初期設計時には、認証メカニズムが本格的な企業シナリオでの負荷検証をそれほど受けていなかった可能性があるが、数百万人のユーザーと950のサーバーという規模が現実のものとなった今、企業の既存のID管理システム（EntraやOktaなど）と接続できる能力は、「あれば嬉しい機能」から「必須条件」へと変わったのである。
MCP AppsとTasksという2つの機能が「標準化された拡張フレームワーク」に組み込まれたことは、実際には何を意味し、以前から使えていたこととどう違うのか？
MCP Apps（コネクタが会話内に直接インタラクティブなUIをレンダリングでき、ユーザーがタブを切り替える必要がなくなる機能）とTasks（長時間実行されるタスクを追跡する機能）は、今回の仕様更新以前から存在していたが、従来こうした高度な機能をプロトコルに追加する場合、正式でバージョン管理された仕様に従うことなく、コアの外側に「積み重ねる」形になっており、開発者ごとに実装方法が一致しないことがあった。
新仕様ではこの2つが「バージョン管理された拡張フレームワーク」に組み込まれ、明確に定義された仕様バージョンと正式な互換性保証を持つようになった。開発者は各自で手探りするのではなく、このフレームワークの定義に従って実装できる。この変化の実務的な意味は、こうした高度な機能が「開発者が各自試している能力」から「プロトコルのエコシステム全体で共通言語として通じる標準機能」へと変わったということである。複数のMCPサーバーを連携させ、互いの挙動の一貫性を確保したい開発者にとって、これは統合時に思わぬ落とし穴を踏むリスクを下げることになる。
もし自分の組織が社内システムをMCPコネクタ化してClaudeに組み込むことを検討している場合、この仕様更新は評価の優先順位にどう影響すべきか？
もし評価の焦点が「このプロジェクトを始めるべきかどうか」であるなら、今回の更新で提供されるステートレスコア設計は、以前よりも構築・運用コストが低くなることを意味する。特に組織が懸念していたのが接続状態管理による運用の複雑さであった場合、この新仕様はそれに対する直接的な技術的解決策を提供する。また、enterprise-managed authにより、組織は既存のIDプロバイダーを通じて一括してアクセス権を付与でき、ユーザーごとに個別設定する必要がなくなるため、社内展開の際の障壁も下がる。
もし評価の焦点が「既存のMCPサーバーを新仕様にアップグレードすべきかどうか」であるなら、より実践的なアプローチは、まず現在のサーバーの利用規模と課題を確認することである。現在の課題がまさに接続状態管理やID統合の複雑さにあるなら、アップグレードの投資対効果はより直接的なものになる。逆に、現在のサーバーの規模が小さく安定して稼働しており、スケーリングや企業ID統合の差し迫った必要性がないなら、アップグレードの優先順位を下げ、まずは他の早期採用者の実装経験を観察するという判断も合理的である。これはプロトコルのコア設計にまたがる大きな変更であり、一定の移行作業を要するためである。
Anthropicは2026年7月末、MCP（Model Context Protocol）の最新仕様である 2026-07-28 をClaudeの各種製品に導入すると発表した。これはMCPがこれまでで最も重要な仕様更新の1つであり、中核となる変更は、プロトコルを従来の双方向・ステートフルな設計から、リクエスト／レスポンスモデルによるステートレスコアへと移行させたことに加え、標準化された拡張フレームワークと、より厳格な認証メカニズムが新たに追加された点にある。
公式発表によると、MCPの月間SDKダウンロード数は現在4億回を突破しており、今年だけで4倍に成長した規模である。ClaudeのコネクタディレクトリにもすでにMCPサーバーが950以上掲載されており、毎日数百万人が利用している。この仕様更新は公式によって「これまでで最も重要な仕様リリースの1つ」と表現されており、開発者が自身のMCPサーバーをより容易に構築し、規模を拡大できるようにすることを目的としている。
ステートレスコアは、今回の更新の中で最も影響が大きい変更である。従来のMCPは双方向・ステートフルなプロトコルであり、開発者は自分で接続状態の管理を処理する必要があった。新仕様の下では、サーバーはサーバーレスやエッジコンピューティングのインフラに直接デプロイでき、セッション状態を管理する必要がなくなり、開発とスケーリングの複雑さが大幅に簡素化される。2つ目の変更は「標準化された拡張」である。MCP Apps（コネクタが会話内に直接インタラクティブなUIをレンダリングできる機能）とTasks（長時間実行されるタスクを追跡する機能）が、バージョン管理された拡張フレームワークにまとめられ、開発者はプロトコルのコアに手を加えることなく、こうした高度な機能を追加するための正式な経路を得られるようになった。3つ目は認証の強化である。認可の仕組みが本番環境でよく使われるOAuth 2.0やOIDC標準に整合するようになり、MCPサーバーはEntraやOktaといった企業の既存のID管理システムに、別途回避策を用いることなく直接接続できるようになった。
この仕様更新と同時に、いくつかのコネクタ機能もリリースされた。企業は既存のIDプロバイダーを通じて、組織全体のメンバーに対して一度にコネクタのアクセス権を付与できるようになり（enterprise-managed auth）、開発者は自身が公開したコネクタが各Claude製品のインターフェースでどのように利用されているか——採用状況、エラー率、遅延——を観測ダッシュボードで確認できるようになった。さらに、まだリサーチプレビュー段階にあるMCP tunnels機能もあり、公開エンドポイントを外部に開放することなく、コネクタが企業の内部ネットワーク内のサーバーに接続できるようにする。
単にClaudeを使ってサードパーティサービスに接続しているだけの一般ユーザー（コネクタ経由でGmailやSlackを読み取っているなど）であれば、今回の仕様更新について特に何かする必要はない。基盤となるプロトコルのアップグレードはコネクタ開発者側が対応することである。しかし、もしあなたのチームがMCPサーバーを自前で構築・運用しているなら、今回の更新は具体的な技術的方向性を示している。現在のサーバー実装が接続状態管理の複雑なロジックをまだ抱えている場合、ステートレスコア設計に移行すれば、理論上はその運用負担を直接削減でき、サーバーを弾力的にスケールするインフラ上により容易にデプロイできるようになる。社内ツールをMCPコネクタ化してClaudeのワークフローに組み込むべきかどうかを検討しているチームにとっても、新仕様の下でのエンタープライズグレードの認証機能や観測機能は、実際に本番環境へ組み込む際の技術的なハードルをさらに下げるものとなる。