MCP のステートレス 2026-07-28 仕様により、エージェント ツール サーバーのオペレーティング モデルが変更されます

モデル コンテキスト プロトコルはインフラストラクチャの主要なマイルストーンに達しました。2026 年 7 月 28 日の改訂により、プロトコルはステートレス コアに移行します。エージェント システム、ツール サーバー、IDE 統合、またはマルチモデル オーケストレーション レイヤーを構築しているチームにとって、これは表面的な仕様の更新ではありません。これは、セッション、初期化、スケーリング、互換性、ガバナンスに関する前提を変更します。

MCP リリース候補では、ステートレス プロトコル コア、拡張フレームワーク、タスク、MCP アプリ、認証強化、および正式な非推奨ポリシーを追加するとして 7 月 28 日の仕様について説明しました。公式 MCP ブログでも、このリリースには重大な変更が含まれていることを警告しました。最も目立つ MCP サーバー実装の 1 つを運用している GitHub は、最終リリースに先立って、その MCP サーバーがすでに新しい仕様をサポートしており、7 月 28 日にこのプロトコルを「ステートレスになる」と説明したと発表しました。

実際の意味は単純です。MCP は、セッション負荷の高いローカル統合レイヤーというよりは、リモート ツール アクセス用のインターネット スケールのプロトコルに近い形になっています。エージェント システムはもはやデスクトップ開発ツールに限定されないため、これは重要です。これらは、クラウド サービス、CI システム、カスタマー サポート ワークフロー、問題トラッカー、エンタープライズ自動化プラットフォーム内で実行されることが増えています。

MCP

での変更点は、ステートレス プロトコル コアへの移行です。 GitHub の変更ログには、リモート MCP デプロイメントの拡張を容易にすることを目的として、新しいコアがセッションを削除して初期化することが記載されています。これは重要なアーキテクチャの変更です。ステートフル プロトコルはローカル ツールや制御された環境では適切に機能しますが、水平スケーリング、サーバーレス実行、フェイルオーバー、エッジ デプロイメント、負荷分散が複雑になります。

ステートレス コアにより、実装者は通常の Web インフラストラクチャの背後で MCP 台のサーバーをより自由に実行できるようになります。特定のバックエンドで長期間存続するセッションを保持せずに、リクエストをインスタンス間で分散できます。大規模な組織の場合、これにより運用の複雑さが軽減されます。小規模なチームの場合、カスタムの長期実行インフラストラクチャではなく、マネージド コンピューティングを使用して、ホストされた MCP サーバーのデプロイが容易になる可能性があります。

リリース候補資料によると、より広範な 2026 年 7 月 28 日のリリースでは、拡張機能フレームワークとタスクも導入されています。これらの追加は、MCP がよりモジュール化され、長時間実行される作業についてより明示的になっていることを示唆しています。 MCP アプリと認証の強化は同じ方向を向いています。つまり、プロトコルは初期のエコシステムの接着剤から、エージェントとツールの相互作用のためのより正式な層へと成熟しています。

その成熟のコストは互換性作業です。 MCP ブログでは、このリリースを破壊的な変更を伴うリリースとして特徴づけており、このリビジョンに関連して公開された TypeScript および C# SDK 資料は、移行サポートとステートレス概念に焦点を当てています。 MCP サーバーを運用しているチーム、IDE 拡張機能に MCP を埋め込んでいるチーム、または内部インフラストラクチャ経由でエージェント呼び出しをルーティングしているチームは、このリビジョンをバックグラウンドの標準更新ではなくエンジニアリング イベントとして扱う必要があります。

開発者やオペレーターにとってステートレス MCP が重要な理由

エージェント ツールには、通常の API スケーリングとは異なるスケーリングの問題があります。単一のユーザー要求により、多くのツール呼び出し、モデルの回転、再試行、ファイルの読み取り、検索クエリ、および承認ステップがトリガーされる可能性があります。ツールのプロトコルが永続的なセッションを想定している場合、運用オペレーターはそれらのインタラクション全体で状態を保存するか、プロトコルの回避策を構築する必要があります。

コアからセッションを削除することで、MCP エージェントのワークロードがバースト的、分散的、非同期である環境にさらに適合します。サーバーレス機能、エッジ ワーカー、Kubernetes デプロイメント、およびマルチリージョン システムはすべて、リクエストを個別に処理できる場合にメリットをもたらします。これによってエージェント アプリケーションから状態が削除されるわけではありません。状態をプロトコル コアに埋め込むのではなく、アプリケーション データベース、タスク キュー、ID システム、または明示的なワークフロー層に移動します。

開発者にとって、この変更により、最終的にはリモート ツール サーバーが使いやすくなるはずです。プラットフォーム チームにとっては、可観測性とキャパシティ プランニングが簡素化される可能性があります。オペレータは、不透明なセッション アフィニティの動作をデバッグする代わりに、リクエスト レベルのトレース、ツール呼び出しのレイテンシ、認可の決定、エラー パターンに集中できます。

ガバナンスの観点もあります。 MCP がコーディング アシスタントやエンタープライズ エージェントでより一般的になるにつれて、企業はエージェントが呼び出せるツール、アクセスできるデータ、それらの呼び出しを許可するユーザーやサービスに関するポリシーが必要になります。したがって、新しいリビジョンでの Authorization の強化は偶発的なものではありません。これは、ツールへのアクセスが開発者の利便性だけでなく、今やセキュリティ境界になっているという現実を反映しています。

誰が影響を受けるか

最も直接的な影響を受けるグループは、MCP 人のサーバー管理者、SDK 人のユーザー、エージェント プラットフォーム チーム、および内部ツールを AI エージェントに公開している組織です。サーバーがセッションの動作や古い初期化フローに依存している場合は、新しい仕様に照らしてテストする必要があります。アプリケーションが複数の MCP バージョンをサポートする場合、バージョン ネゴシエーション、互換性レイヤー、または段階的な移行計画が必要になる場合があります。

IDE および開発者ツールのベンダーも対象となります。 MCP は、コーディング エージェント、カスタム エージェント、モデル管理機能と並んで登場することが増えています。ステートレス プロトコル コアにより、これらの製品はリモート ツールを確実に呼び出すことが容易になりますが、これはその統合が仕様に準拠している場合に限られます。

エージェント自動化を使用する企業は、MCP 仕様を読んだことがなくても注意する必要があります。この変更は、リポジトリ、チケット発行システム、データベース、内部ナレッジ ベース、または展開ツールに接続するエージェントの信頼性に影響を与える可能性があります。移行期間中に発生する可能性のある障害モードは、明らかな機能停止だけではありません。これらには、ツールの機能が欠落している、認証動作が変更されている、またはツール サーバーが期待どおりに動作しなくなったため、エージェントが異なるパスを選択していることが含まれる場合があります。

Model Gate などの AI API ゲートウェイの場合、この接続は実用的です。統合 AI API は、モデル ルーティング、API キー管理、使用状況分析、チーム API ガバナンスの近くに配置されることが増えています。エージェント システムでは、通常のモデル呼び出しに加えて MCP 個のツール呼び出しが追加されるため、ゲートウェイ層とオブザーバビリティ層はワークフローの両方の側面、つまりどのモデルが使用されたか、どのツールが呼び出されたか、コスト、誰が承認したか、どこで障害が発生したかを考慮する必要があります。

移行の優先順位と未解決の質問

移行の最初の優先順位は互換性テストです。チームは MCP 台のクライアントとサーバーのインベントリを作成し、セッションへの依存関係を特定するか動作を初期化し、利用可能な場合は 2026-07-28 SDK または適合資料に対してテストする必要があります。本番システムは、特にエージェントがプル リクエストの作成、問題の変更、顧客データのクエリ、デプロイメント ワークフローの実行などの副作用を伴うアクションを実行する場合、アップグレードを段階的に行う必要があります。

2 番目に優先されるのはオブザーバビリティです。ステートレス インフラストラクチャは拡張が容易ですが、分散エージェント システムでは依然として相関 ID、トレース キャプチャ、リクエスト ログ、およびポリシー イベントが必要です。これらがないと、チームはセッションの複雑さと引き換えにデバッグの複雑さを得る可能性があります。使用状況分析では、特にエージェント ワークフローが課金されている場合、レート制限されている場合、またはチームによって監査されている場合には、モデル呼び出しとツール呼び出しを区別する必要があります。

3 番目の優先事項は承認レビューです。新しい仕様によって認可セマンティクスが強化された場合、実装者は古いアクセスの前提を単に新しいバージョンに移植すべきではありません。トークンのスコープ、ユーザーの委任、サービス アカウント、監査ログ、拒否動作を再確認する必要があります。特にリモート MCP デプロイメントの場合、ツールのアクセスはデフォルトで最小権限である必要があります。

組織が取り消し不能な設計上の決定を下す前に、確認する価値のある詳細がいくつか残っています。この記事で利用できる調査には、リリース候補、仕様ページ、SDK の移行資料、GitHub の実装ノートが含まれています。 2026-07-28 仕様の最終的な規範的な文言は、内部標準や顧客ドキュメントで正確なプロトコル要件を引用する前に、直接レビューする必要があります。

その警告はあったとしても、方向性は明確です。 MCP は、エージェント インフラストラクチャ向けのより実稼働指向のプロトコルになりつつあります。ステートレス コアにより、リモート デプロイメントの拡張が容易になりますが、エコシステムは以前の実装からの前提条件をクリーンアップする必要もあります。エージェントを使用して構築しているチームにとって、これは単なるブックマークではなくスプリント チケットに値する種類のプロトコル変更です。