MCP 2026-07-28 仕様が確定、ステートレス化とMCP AppsがClaudeへ

要約

Model Context Protocol（MCP）の新仕様 2026-07-28 が確定版として公開されました。MCP公式ブログが仕様側の変更を、Anthropic が claude.com/blog でClaude製品への反映内容を、それぞれ同日に発表しています。

最大の変更はプロトコルのステートレス化です。従来のMCPは双方向のステートフルなプロトコルで、initialize / initialized のハンドシェイクと Mcp-Session-Id ヘッダーによるセッション管理を前提にしていました。新仕様ではこれらが廃止され、各リクエストが独立して成立するリクエスト/レスポンスモデルになります。結果として、MCPサーバーをサーバーレスやエッジの実行環境にそのままデプロイできるようになります。常駐プロセスを前提としたホスティングが不要になるという意味で、運用面のインパクトが大きい変更です。

もう一つの軸が拡張フレームワークの正式化です。これまで実験的にコアへ入っていた Tasks は io.modelcontextprotocol/tasks という拡張へ切り出され、MCP Apps、Enterprise Managed Authorization（EMA）とあわせて、バージョン付きの拡張として提供されるようになりました。コアプロトコルを変更せずに機能を追加できる正式な経路が用意されたかたちです。

認可まわりも強化されました。RFC 9207 に基づく発行者検証が入り、Dynamic Client Registration（DCR）から Client ID Metadata Documents（CIMD）へ移行、認可サーバー間での認証情報の再利用も防止されます。Entra や Okta のようなエンタープライズIDシステムとの連携を前提とした設計になっています。

Claude 側では、MCP Apps によるインタラクティブUIの会話内描画、IdP経由でコネクタを組織全体にプロビジョニングできるエンタープライズ管理認証、コネクタディレクトリ掲載サーバー向けのオブザーバビリティダッシュボード、そしてプライベートネットワーク内のMCPサーバーへ公開なしで接続できるMCPトンネル（リサーチプレビュー）が提供されます。公式ブログでは、MCPのSDK月間ダウンロードが4億回を突破し年内で4倍に増えたことにも触れています。

何が変わったか

• プロトコルがステートレスコアに移行。initialize / initialized 交換と Mcp-Session-Id ヘッダーが廃止され、各リクエストが独立して成立する
• MCPサーバーをサーバーレス／エッジ基盤へデプロイ可能に
• Tasks が実験的コアから io.modelcontextprotocol/tasks 拡張へ移行。MCP Apps、Enterprise Managed Authorization とともにバージョン付き拡張フレームワークとして提供
• 認可を強化：RFC 9207 の発行者検証、DCR から CIMD への移行、認可サーバー間での認証情報再利用の防止
• Multi Round-Trip Requests（MRTR）により双方向ストリームが不要に。ヘッダーベースのルーティング、ttlMs / cacheScope によるキャッシュ可能なリスト結果にも対応
• Roots / Sampling / Logging は非推奨化。ただし少なくとも12か月間は機能継続する廃止予定期間が設定されている
• Tier 1 SDK（TypeScript / Python / Go / C#）は仕様公開時点で 2026-07-28 に対応済み
• Claude 側で MCP Apps（会話内インタラクティブUI）、エンタープライズ管理認証、コネクタ開発者向けオブザーバビリティ、MCPトンネル（リサーチプレビュー）を提供

業務インパクト（一般企業向け）

社内でMCPサーバーを自前運用している企業にとって、ステートレス化は運用モデルの選択肢を広げる変更です。セッション保持のために常駐プロセスとスティッキーな接続を維持していた構成は、Lambda や Cloudflare Workers のような従量課金の実行環境へ移せる可能性があります。一方で、セッション状態に依存した実装をしているサーバーは、リクエストごとに文脈を再構成する設計へ見直す必要があります。非推奨化された Roots / Sampling / Logging を使っている場合も、12か月の猶予があるうちに移行計画を立てておくべきです。

情シス・セキュリティ観点では、エンタープライズ管理認証の意味が大きいところです。従来はユーザーが個別にコネクタを認可する運用になりがちでしたが、管理者が一度認可すれば、ユーザーは既存のIdPグループを通じてアクセスを継承し、初回ログイン時に接続されます。「誰がどのコネクタを使えるか」をIdPのグループ管理に寄せられるため、入退社時の権限管理が既存フローに統合できます。

MCPトンネルは、社内システムをインターネットに露出させずにClaudeから使いたいケースに直接効きます。これまでリバースプロキシやVPN経由の構成を検討していた組織にとって、ファイアウォール設定やIP許可リストなしで社内ツールを繋げる選択肢が増えます。ただしリサーチプレビュー段階のため、本番前提の採用判断は慎重に行うのが妥当です。

副業・個人活用視点

個人でMCPサーバーを作って配布している場合、ステートレス化はホスティングコストを直接下げます。従来は小さなMCPサーバーでも常時起動のコンテナやVPSが必要でしたが、サーバーレスに載せられればリクエストが来たときだけ課金される構成にできます。趣味・副業レベルのコネクタを公開し続けるハードルが下がる変更です。

MCP Apps は、コネクタの差別化ポイントになり得ます。テキストの応答だけでなく会話内にUIを描画できるため、たとえばフォーム入力・選択肢の提示・結果のビジュアル表示といった体験を組み込めます。コネクタディレクトリに掲載すればオブザーバビリティダッシュボードで利用状況とエラーを追えるので、「作って終わり」ではなく改善サイクルを回せる環境が整いつつあります。MCPのSDKダウンロードが年内4倍という成長を踏まえると、コネクタ開発は今から入っても市場が広がっている領域です。