MCPの最大のアップデート：多くのサーバーの基盤を除去

Model Context Protocol (MCP) は、ローンチ以来最大のアップデートを迎えようとしています。主要メンテナーは5月21日にリリース候補を凍結し、最終仕様は7月28日に確定する予定です。

一見すると、変更履歴は劇的です：セッションと初期化ハンドシェイクが削除され、3つのコア機能が非推奨になります。しかし、よく見ると、この改訂はMCPを簡素化し、馴染みのあるタスクを既存のインフラに戻すことに重点を置いています。運用担当者にとって、これは長年の不満を解決します：リモートMCPサーバーを実行するために、通常のステートレスサービスには不要な特別な仕組みを必要とすべきではないという点です。

MCPがユーザーに課していた税金

削除を理解するには、MCPの当初の設計と実際の展開との間のギャップを調べる必要があります。最も初期の最もよく知られた形態は、標準入出力を介してローカルプロセスと通信するデスクトップアプリであり、起動時のハンドシェイクは長時間の接続上で低コストでした。

より多くのサーバーがリモートの水平スケーリングされたデプロイメントに移行するにつれて、セッションが問題になりました。サーバーはMcp-Session-Idを発行し、クライアントを発行インスタンスに固定しました。スケールアウトするには、多くの場合、セッションアフィニティ、外部共有セッションストア、またはJSONボディを解析して呼び出しルーティングを決定するMCP対応ゲートウェイロジックが必要でした。MCPサーバーを出荷するチームは、プロトコルが自ら作り出した分散システム問題を解決するためにコストを支払っていました。

能力ネゴシエーションは2番目のコストを追加しました。能力は接続時に一度だけ交換されるため、リスト結果は接続ごとに異なる可能性があり、セッション間や共有仲介者でのキャッシュを困難にしました。

メンテナーが最適化したもの

6つの仕様拡張提案は、すべてのリクエストを独立させるという単一の目標に収束します。プロトコルバージョンとクライアント能力は、各呼び出しで_metaに含まれて伝達されます。クライアントはそこに自身のIDを含めることが期待され、新しいserver/discoverメソッドによりサーバー能力を個別にクエリできます。リリース記事はこれを「ペイ・アズ・ユー・ゴー・コンプレクシティ」の原則と呼びます：コアはスリムに保ち、状態は機能が本当に必要とする場合にのみ現れます。

明白な反論は、多くのサーバーが何かを覚えておく必要があることです。1つの主要な答えは明示的なハンドルです。これは20年にわたってすべてのHTTPショッピングカートが使用してきたパターンです。ツールはbasket_idを生成し、結果に返し、モデルは次の呼び出しで通常の引数として渡します。アカウント状態、リソースURI、タスクハンドル、通常のデータベース識別子はすべて、そのルートを経由すべきでないもののために引き続き利用可能です。

ハンドルが単なる回避策以上のものである理由は、それがモデルに見えることです。トランスポートメタデータに隠されたセッション状態はモデルが推論できないものでしたが、ツール結果内のハンドルはツール間で合成でき、ワークフローステップ間で受け渡せます。トレードオフは、それがプロンプト、トランスクリプト、ログにも現れるため、認証されたプリンシパルにバインドし、使用ごとに権限を確認する必要があることです。

開発者が実際に得るもの

サーバー作者にとって、リモートMCPサーバーは従来のステートレスHTTPサービスのように運用できるようになります。ラウンドロビン背後にある3つのレプリカ、アフィニティ設定不要、プロトコルセッションストアの運用や回復不要。ローリングデプロイはもはやセッションを無効化したり、クライアントを削除されたインスタンスに残したりしませんが、進行中のリクエストやサブスクリプションストリームを中断する可能性があり、再開機能がなくなったため、クライアントは新しいリクエストIDでその作業を再発行します。

プラットフォームチームにとって、必須のMcp-Methodヘッダーと、名前付きツール、リソース、プロンプト操作のためのMcp-Nameヘッダーにより、ゲートウェイはリクエストボディを調べることなく操作ごとにレート制限や認可を行えます。これはトランスポート検証ルールの下でのみ成立します。バックエンドはヘッダーとボディが一致しないリクエストを拒否し、ポリシー強制仲介者はチェックを保証しないプロトコルバージョンを拒否します。これを省略すると、無害なヘッダーが異なる呼び出しの前に立つ可能性があります。

キャッシュの変更は、これまで受けてきた以上に注目に値します。影響を受けるリストおよび読み取り結果には、HTTP Cache-Controlに基づくttlMsとcacheScopeを含める必要があり、クライアントは宣言された間隔でカタログを保持でき、再取得する必要がありません。ドラフトはttlMsを、データがまだ有効であるという約束ではなく、鮮度ヒントとして扱います。また、サーバーは決定論的な順序でツールを返すことが求められ、ドラフトはこれがプロンプトキャッシュヒット率の向上につながるとし、ボリュームがある場合、プロバイダーがプロンプトキャッシュを価格設定する場所で、レイテンシーやトークンコストの削減を意味する可能性があります。

1つの注意点は、脚注ではなくここに属します。プロトコル層でのステートレス性はルーティング可能性を買うものであり、決定論ではありません。2つのレプリカはプロトコル状態を相談せずに同じリクエストを受け入れますが、異なるバージョンを実行したり異なるダウンストリームデータを読み取ったりすると、異なる答えを返す可能性があります。

なぜ拡張機能を気にするのか

エコシステムの議論は、単一の機能よりも強力です。拡張機能は名前空間識別子を取得します：公式のものはio.modelcontextprotocol、サードパーティのものは作者が所有する逆ドメイン名に加え、独自のext-リポジトリとリリースサイクルを持ちます。Kubernetesカスタムリソース定義を書いたことがある人なら誰でも、その形状を認識するでしょう。機能がコアリリーストレインの外で出荷され成熟するのです。

Tasksはその重要性の証明です。2025-11-25に実験的なコア機能として出荷され、実際のプロダクション使用で設計問題が露呈し、拡張機能として再設計されました。コアから移動すること自体が破壊的な仕様変更ですが、次のイテレーションはそうではありません。拡張機能は機能フラグや設定レベルのバージョニングを通じて進化し、やむを得ない場合にのみ新しい識別子を使用するからです。MCP Appsはすでに拡張機能として利用可能であり、以前は存在しなかったプロセスではなく、正式に統治された交渉フレームワーク内に位置付けられています。

非推奨ポリシーがもたらすもの

機能ライフサイクルポリシーは、すべての機能にアクティブ、非推奨、削除の状態を与え、機能が最初に非推奨となるリビジョンから最低12か月のウィンドウを設けます。この最低期間は、公開された勧告または文書化された悪用を伴うアクティブなセキュリティリスクがある場合にのみ短縮でき、それでも90日がハードな最小値です。公開レジストリは何がいつまでに廃止されるかをリストし、標準トラック提案は、一致するシナリオが適合性スイートに着地するまで最終状態に到達できません。

開発者にとって、これはハウスキーピングのように読めます。しかし、プラットフォームレビュー委員会にMCP統合を正当化しなければならない人にとって、書面による非推奨保証は、このリリースのどの機能よりも価値があります。

コスト

これらはすべて無料で提供されるわけではありません。実験的なTasks APIに対して構築した人は新しいライフサイクルに移行する必要があり、クライアントに自身のリクエストを発行していたサーバーは複数ラウンドトリップリクエストパターンに移行し、サーバーはまだ必要なものを返し、クライアントは回答を持って再試行します。そのサーバーは、認可やビジネスロジックに影響を与える可能性のあるエコーされたrequestStateを認証する必要もあります。ワンタイムワークフローには、独自のリプレイトラッキングが必要です。

非推奨はドロップインの置き換えではなく移行の方向性であり、Samplingが最も顕著なケースです。クライアント仲介のSamplingを使用するサーバーはプロバイダー資格情報を必要とせず、一般的にモデル請求を負いませんでした。一方、プロバイダーAPIを直接呼び出すと、それは資格情報保持者、請求当事者、ユーザーデータの個別処理者になります。Loggingも同様の話です。stderrとOpenTelemetryは運用者の可観測性に答えますが、リモートクライアントに以前受け取っていた構造化ログストリームと同等のものを与えません。

プロトコルは状態の管理をやめましたが、それは状態がなくなることと同じではありません。ハンドル、カート、タスクレコード、冪等性キーは、どこかに存在する必要があります。プロトコルは状態の管理をやめましたが、状態がなくなるわけではありません。

今後の道筋

プロトコルの誕生から2年も経たないうちに基礎的な抽象化を削除することは計算されたリスクであり、メンテナーは10週間の検証ウィンドウとPython、TypeScript、Go、C#用のベータSDKで賢明にヘッジしました。

また、移行パスを定義しました。クライアントは最初にserver/discoverでプローブし、レガシーのみのサーバーに遭遇した場合にのみinitializeにフォールバックします。これは、ワイヤレベルでの破壊的変更ですが、交渉可能なパスが存在し、エコシステム全体の旗日ではありません。

リリース候補ウィンドウは、セッション依存関係を棚卸し、テストする適切な時期であり、プロダクション展開は承認と安定したSDKの後に行うべきです。個々のサーバー作者からプラットフォームチーム、その周りにゲートウェイやレジストリを構築するベンダーまで、その見返りは、業界がすでに運用方法を知っているインフラにはるかに自然に適合するプロトコル層です。