← 返回首页

MCP 2026-07-28 詳細解説：ステートレスサーバー、MCPアプリ、タスク、エンタープライズ認証、新エージェント基盤

モデルコンテキストプロトコルは、公開以来最大規模のアーキテクチャ改訂を迎えました。MCPは当初、AIアプリケーションがモデルと...を接続するための汎用的な方法として導入されました。

发布于 2026年7月31日•general•GEO 评分: 0•7 次阅读

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
MCP 2026-07-28 詳細解説：ステートレスサーバー、MCPアプリ、タスク、エンタープライズ認証、新エージェント基盤

MCP 2026-07-28 解析：プロトコルがステートレス化され、拡張が容易に

はじめに

モデルコンテキストプロトコル（Model Context Protocol）は、公開以来最大規模のアーキテクチャ改訂を迎えました。

MCPは当初、AIアプリケーションがモデルをツール、API、データソース、ファイル、外部システムと接続するための汎用的な方法として導入されました。2年足らずの間に、Anthropic主導の統合プロジェクトから、独自のガバナンスプロセス、SDKエコシステム、ワーキンググループ、拡張機能、そして多数のAI製品にわたる実装を備えた、より広範なオープンソースプロトコルへと発展しました。

2026-07-28改訂版は、MCPが開発者のノートパソコンを離れ、大規模な本番環境に移行する際に発生する問題に焦点を当てています。

主な変更点は次のように要約できます：

MCPはプロトコル層でステートレスに移行しています。

この変更により、新しいワイヤーフォーマットからプロトコルレベルのセッションと初期化ハンドシェイクが削除され、リモートMCPサーバーが通常のロードバランサー、サーバーレスインフラストラクチャ、エッジコンピューティングノード、水平スケーリングアーキテクチャの背後に容易にデプロイできるようになりました。

しかし、ステートレストランスポートは今回の更新の一部に過ぎません。

この改訂版はまた、拡張フレームワークを正式に確立し、長時間実行タスクを再構築し、複数往復リクエストを導入し、ルーティング可能なHTTPヘッダーとキャッシュヒントを追加し、認証メカニズムを強化し、JSON Schemaサポートを拡張し、正式な機能廃止ポリシーを策定しました。

プロトコル自体の外では、MCPエコシステムはインタラクティブアプリ、エンタープライズ向けホスティング認証、プライベートネットワークトンネル、より強力な開発者ツールを追加しています。

まさにこの点で、MCPは便利なエージェントコネクタではなく、本番グレードのインフラストラクチャのように見え始めています。

MCPの採用速度は急成長

ソースレポートはMCP使用量の成長速度を強調しています。

ソース記事が引用するClaude開発者向け発表によると：

  • MCP SDKの月間ダウンロード数は4億回を超えています。
  • 年間でSDKの月間使用量は約4倍に増加しました。
  • TypeScriptおよびPython SDKの累積ダウンロード数はともに非常に大きなマイルストーンを超えました。
  • Claudeのコネクタエコシステムを通じて、数百のMCP統合が利用可能です。

これらの7月末時点の具体的なデータは、発表における指標であり、中核仕様で公開された数値ではありません。

Anthropicの以前の公式発表は有用な参照点を提供しています：2026年1月、AnthropicはMCPが月間1億回のダウンロードに達したと述べました。

これは、7月のプロトコル再設計の前に、エコシステムがすでにかなり大規模であったことを意味します。

したがって、今回の更新の意義は、MCPが将来のある時点で有用になろうとしていることではなく、メンテナーがすでに本番規模で顕在化している問題を中心にプロトコルを再設計していることにあります。

これらの問題には以下が含まれます：

  • スティッキーセッション。
  • 共有セッションストレージ。
  • 水平スケーリング。
  • サーバーレスデプロイ。
  • ゲートウェイルーティング。
  • 認証の複雑さ。
  • 長時間実行されるエージェント操作。
  • インタラクティブインターフェース。
  • 後方互換性。
  • プロトコルの進化。

なぜ以前のステートフル設計がスケーリングの課題となったのか

初期のリモートMCPデプロイでは、プロトコルレベルのセッション状態を維持できました。

クライアントは通常、初期化を行い、

接続を確立してセッション識別子を取得しました。後続のリクエストはその後、そのセッションに関連付けられたままにする必要がありました。

簡略化した 2025-11-25 フローは以下のようになります：

POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "my-app",
      "version": "1.0"
    }
  }
}

初期化後、後続の呼び出しは以下を運ぶことができます：

Mcp-Session-Id: 1868a90c-3a3f-4f5b

この方法は多くのアプリケーションで機能しましたが、いくつかのインフラストラクチャレベルの要件をもたらしました。

本番環境のデプロイでは以下が必要になる可能性があります：

  • スティッキーロードバランサールーティング。
  • 共有セッションストレージ。
  • セッションレプリケーション。
  • セッション有効期限ロジック。
  • フェイルオーバー処理。
  • 接続を認識する可観測性。
  • サーバー再起動の特別な処理。

MCPメンテナーは、これらの要件がプロトコル自体と密接に結合しすぎていると結論付けました。

新しい改訂版はこの前提を削除しました。

MCPは現在プロトコルレベルでステートレス

2026-07-28プロトコル設計では、各リクエストがサーバーがリクエストを解析するために必要な情報を保持しています。

公式の例は以下のとおりです：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "q": "otters"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

プロトコルレベルの Mcp-Session-Id はもうありません。

リクエストを単一のサーバーインスタンスにバインドする必須の接続セッションはもうありません。

互換性のあるサーバーインスタンスならどれでもリクエストを処理できます。

画像は、MCP 2026-07-28プロトコル設計におけるリクエスト例を示しています。リクエストメソッドはPOST、ターゲットパスは/mcp、プロトコルバージョンはHTTP/1.1、MCPプロトコルバージョンは2026-07-28、Mcp-Methodはtools/call、Mcp-Nameはsearchです。リクエストボディはJSON形式で、jsonrpc、id、method、params、_metaなどのフィールドを含み、paramsのnameはsearch、argumentsにはqがottersとして含まれ、_metaにはクライアント情報が含まれています。この画像はコンテキストと密接に関連し、新しいプロトコル設計におけるリクエストの構造を視覚的に示し、MCPプロトコルがプロトコル層でステートレス化されている特性を体現しています。

これはクラウドデプロイにとって大きな改善です。

リモートMCPサーバーは現在、従来のアーキテクチャに適合できます：

クライアント
  ↓
APIゲートウェイ / ロードバランサー
  ↓
MCPサーバーインスタンスA
MCPサーバーインスタンスB
MCPサーバーインスタンスC

以前のリクエストが特定のインスタンスに届いたからといって、そのインスタンスに戻る必要はもうありません。

新しいワイヤーフォーマットから initialize ハンドシェイクが削除

ステートレス再設計はまた、2026-07-28ワイヤーフォーマットから古い initialize / initialized ライフサイクルを削除しました。

以前は初期化中に一度だけ転送されていた情報は、現在はメタデータを通じてリクエストとともに転送されます。

クライアントがサーバー機能を事前に検出したい場合は、新しいメソッド server/discover を使用できます。

これは古いクライアントがすぐに動作しなくなることを意味するわけではありません。

現在のSDKドキュメントには、初期のプロトコルバージョンに対する互換性動作の説明が含まれています。たとえば、C# SDKは新しいステートレス

パスを進めつつ、2025-11-25プロトコルを使用するクライアントとのレガシーなセッションベースの動作のネゴシエーションを継続できます。

重要な移行の違いは以下のとおりです：


2026-07-28：
ステートレスリクエストモデル、プロトコルセッションなし。

旧バージョン：
初期化ハンドシェイクとセッション認識動作は、引き続きサポートされる場合があります
バージョン交渉とSDK互換パスを通じて。

開発者はサーバーだけをアップグレードして、すべてのクライアントが新バージョンを理解できると想定するのではなく、統合の両端をテストすべきです。

ステートレスプロトコルはステートレスアプリケーションを意味しない

最も陥りやすい誤解の一つは、この変更を次のように解釈することです：

MCP アプリケーションは状態を保持できなくなる。

これは仕様の意味するところではありません。

プロトコル層はステートレスです。

アプリケーションは、状態が有用な場所で状態を維持できます。

買い物ツールがショッピングバスケットを作成したと仮定します。

サーバーは次を返すことができます：

{
  "basket_id": "basket_8472"
}

モデルは後続の呼び出しでその値を渡すことができます：

{
  "basket_id": "basket_8472",
  "item_id": "item_123"
}

これにより、アプリケーション状態がトランスポートメタデータに隠されるのではなく、通常のツールデータとして可視化されます。

同じパターンは、ブラウザセッション、レポートタスク、ショッピングカート、ワークフローID、デプロイメントID、ドキュメント編集状態、長時間実行される分析タスクにも使用できます。

明示的ハンドルがより良い場合がある理由

可視のハンドルにはいくつかの利点があります。

モデルは以下が可能です：

  • 関連するツール間で渡す。
  • どのハンドルがどのタスクに属するかを推論する。
  • ログに含める。
  • リトライ後に復元する。
  • 別のワークフローステップに引き渡す。

サーバーは以下が可能です：

  • ハンドルを検証する。
  • 期限切れにする。
  • ユーザーまたはテナントにバインドする。
  • 期限切れ状態を拒否する。
  • 実際の状態をデータベースに保存する。

したがって、ステートレスMCPは状態管理をトランスポート層から明示的なアプリケーションデザインへと移行させます。

サーバーレスと水平スケーリングがはるかに容易になる

元の記事ではサーバーレスデプロイが強調されており、これは新プロトコルの最も実用的な成果の一つです。

リクエストが自己完結型である場合、MCPサーバーは以下の環境でより容易に実行できます：

  • AWS Lambda。
  • Cloudflare Workers。
  • Vercel。
  • その他のサーバーレス関数。
  • コンテナ自動スケーリングプラットフォーム。
  • 通常のステートレスKubernetesデプロイ。
  • エッジ環境。

これは、すべてのMCPワークロードが自動的にすべてのサーバーレスプラットフォームで実行できることを意味するわけではありません。

開発者は引き続き、実行時間、ストリーミングサポート、コールドスタート、アプリケーション状態の永続化、シークレット、アウトバウンドネットワーク、長時間実行タスク、ファイルシステム要件、データベース接続を考慮する必要があります。

プロトコルがセッションアーキテクチャを強制しなくなったことで、主要な障壁が一つ取り除かれました。

ラウンドロビン負荷分散が自然なデフォルトになる

水平スケーリングするサーバーは、プロトコル層で単一クライアントを単一インスタンスにバインドする必要がなくなりました。

これは、単純なラウンドロビン負荷分散器が複数のインスタンス間でリクエストを分配できることを意味します。

これにより改善される点：

  • 自動スケーリング。
  • インスタンスの置き換え。
  • 障害復旧。
  • ローリングデプロイ。
  • マルチリージョンルーティング。
  • インフラストラクチャのシンプルさ。

これはまた、サーバー作成者が隠れたインメモリ状態を考慮する際の考え方も変えます。

あるツールが、以前のリクエストが特定のプロセス内のディクショナリにデータを入力したという理由だけで動作する場合、次のリクエストが別のインスタンスに到達したときに、その実装は失敗する可能性があります。

良い移行テストは次のとおりです：

すべてのツール呼び出しが異なるサーバープロセスに到達した場合、同じワークフローは継続できるか？

答えがノーであれば、サーバーには明示的にするか、永続的な共有ストレージに移行する必要のあるアプリケーション状態依存が含まれています。

持続的な呼び出し中接続に代わり、マルチラウンドトリップリクエストが登場

ステートレス設計でも、サーバーがクライアントに追加情報を要求する方法が必要です。

例としては、ユーザー確認、追加パラメータ、ガイド付き質問、モデル生成レスポンス、ワークスペース関連の値などがあります。

新しいメカニズムはマルチラウンドトリップリクエスト（Multi Round-Trip Requests、MRTR）です。

ツールは不完全な結果を返すことができます：

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "3つのファイルを削除しますか？",
      "schema": {
        "type": "boolean"
      }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

クライアントは必要な回答を収集します。

その後、inputResponses と返された requestState を使用して元の呼び出しを繰り返します。

状態はリクエストフロー内で運ばれるため、別のサーバーインスタンスが次のラウンドを処理できます。

これは、長期間存続するサーバーからクライアントへの接続を要求するよりも、ステートレスアーキテクチャに適合しています。

ヘッダーベースのルーティングによりMCPはゲートウェイにより親しみやすくなる

新しいStreamable HTTP形式は、操作メタデータを直接HTTPヘッダーに追加します。

重要なヘッダーには以下が含まれます：

Mcp-Method: tools/call
Mcp-Name: search

これは本番インフラストラクチャにとって重要です。

APIゲートウェイ、Webアプリケーションファイアウォール、レートリミッター、または可観測性レイヤーは、JSONボディを解析することなく操作を識別できます。

可能な用途：

  • すべての検索ツールを同じプールにルーティングする。
  • 破壊的操作に厳しい制限を適用する。
  • ツール名ごとにレイテンシを記録する。
  • メソッドごとに使用量を測定する。
  • ゲートウェイで許可されていないツールをブロックする。
  • 独立した信頼性ポリシーを作成する。

プロトコル仕様はまた、ヘッダーとJSON-RPCボディの間の一貫性を要求します。

サーバーは、両者が一致しないリクエストを拒否する必要があります。

リストと読み取り結果はキャッシュ対応をサポート

MCPクライアントは、ツールリスト、リソース、プロンプトリスト、リソース読み取りなど、比較的安定したメタデータを頻繁に要求します。

同じ情報を繰り返し取得することは、ネットワークトラフィックとサーバー容量を浪費します。

新しい改訂版では、キャッシュメタデータが導入されました。例：

ttlMs
cacheScope

これらの値により、サーバーは結果が新鮮に保たれるべき時間の長さ、および結果がユーザーやコンテキスト間で共有できるかどうかを示すことができます。

これは通常のHTTPキャッシュの原理に似ています。

ツール集約型エージェントの場合、これにより重複するメタデータの読み込みを削減できます。

分散トレーシングが標準化された

この改訂版では、W3C Trace Context の伝播も文書化されています。

次のようなキー：

  • traceparent
  • tracestate
  • baggage

これらはMCPメタデータを通じて伝播できます。

これにより、単一の分散トレースが以下のリンクチェーンにわたって作業を追跡できます：

ホストアプリケーション
→ MCP クライアント
→ MCP ゲートウェイ
→ MCP サーバー
→ ダウンストリームAPI
→ データベース

エンタープライズレベルのデプロイでは、チームがレイテンシが実際にどこで発生しているかを確認できるため、遅いツール呼び出しのデバッグが容易になります。

拡張機能がファーストクラスのプロトコル機能になる

プロトコルはまた、オプション機能の進化の仕方も変えています。

現在のフレームワークは拡張機能に以下を付与します：

  • 逆DNS識別子。
  • 機能交渉。
  • 独立したバージョン管理。
  • 専用コードリポジトリ。
  • 委任されたメンテナー。
  • SEPプロセスにおける正式な拡張トラック。

これは重要です。なぜなら、コアプロトコルがすべての新しいアイデアを吸収する必要がないからです。

機能はまず拡張機能として成長・成熟し、実証された能力がその後コアに近づくことができます。

MCP Apps：会話内のインタラクティブUI

最も目立つMCP拡張機能の一つがMCP Appsです。

MCPツールは伝統的にテキスト、構造化JSON、またはリソースを返します。

一部のタスクにはインターフェースが必要です。

例としては、ダッシュボード、チャート、マップ、フォーム、タスクボード、設定パネル、デザインキャンバス、ビデオプレーヤーなどがあります。

MCP Appsを使用すると、サーバーはUIリソースを宣言でき、ホストはサンドボックス化されたiframe内でそのリソースをレンダリングします。

![画像はMCP Appsのインタラクションフローを示しています。ユーザーがエージェントに「analyticsを見せて」と指示し、エージェントはチャット内でインタラクティブアプリをレンダリングします。アプリはツール呼び出しを通じてMCP Serverと対話し、サーバーはツールの入力/結果を返し、結果はアプリにプッシュされます。

ユーザーがアプリと対話し、アプリがツール呼び出しを要求し、Serverが新しいデータを返し、アプリが新しいデータに更新される。この図はコンテキストと密接に関連しており、MCP Appsがユーザー指示からアプリ更新までの完全な対話プロセスを直感的に示している。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)

簡略化したフローは以下のとおりです：

  1. ツールがUIリソースを宣言します。
  2. モデルがそのツールを呼び出します。
  3. ホストがサンドボックス内でUIを読み込みます。
  4. ツールデータがインターフェースに渡されます。
  5. ユーザーがアプリと対話します。
  6. アプリはホストを通じて追加のツール呼び出しを要求できます。
  7. ホストはこれらの操作に対して権限と監査の制御を維持します。

MCP Appsは、ClaudeやMCPをサポートする他の開発製品を含む、複数の互換ホストでサポートされています。

MCP Appsの基本インストール

公式拡張パッケージは以下のコマンドでインストールできます：

npm install -S @modelcontextprotocol/ext-apps

公式サンプルコードリポジトリはローカルで実行できます：

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start

これらのコマンドは公式MCP Appsドキュメントに基づいており、拡張機能の進化に伴って変更される可能性があります。

Tasks：接続をブロックしない長時間実行ワーク

エージェントツールは、通常のHTTPリクエスト中に完了できない作業を開始することが増えています。

例としては、CIパイプライン、大規模データ処理タスク、クラウドデプロイ、長時間のリサーチタスク、ビデオレンダリング、人間による承認プロセスなどがあります。

MCP Tasks拡張機能により、サーバーは操作の完了をブロックして待つ代わりに、永続的なタスクハンドルを返すことができます。

画像はMCP Tasks拡張機能のフローチャートを示しています。Client側がtools/callリクエストを送信し、ServerがCreateTaskResultを返します。Clientがtasks/getをループ呼び出しし、ServerがTask状態を返します。Serverがユーザー入力を必要とする場合、Clientがtasks/updateで入力を送信し、Serverがackを返します。再びtasks/getをループ呼び出しし、ServerがTask状態を返します。最終的に、ServerがTask完了状態と結果を返し、Clientがtasks/getをループ呼び出しします。この図は、ドキュメントで紹介されているMCP Tasks拡張機能がサーバーに永続的なタスクハンドルを返すことを許可し、操作完了をブロックせず、タスク状態の変化などの内容に対応しています。

公式拡張機能で定義されているメソッドは以下のとおりです：

tasks/get
tasks/update
tasks/cancel

タスクは以下の状態間を遷移できます：

working
input_required
completed
cancelled
failed

クライアントは tasks/get をポーリングできます。

サーバーがユーザー入力を必要とする場合、タスクは input_required 状態に入ることができます。

クライアントは tasks/update を通じて入力を送信できます。

この設計は、接続が切断された状況でも正常に機能し、長期間維持される接続を必要としません。

重要な互換性に関する注意事項

タスク機能は、2025-11-25 コア仕様では実験的機能として存在していました。

新しいTasks拡張機能は、旧APIの単なる名称変更コピーではありません。

公式SDKドキュメントは、新しいTasks拡張機能が初期の実験的実装とワイヤープロトコルにおいて互換性がないことを警告しています。

旧Tasks機能を使用しているアプリケーションは、自動的な互換性を期待せずに移行する必要があります。

エンタープライズ管理認可

エンタープライズデプロイが直面する認可の問題は、コンシューマー向け統合とは異なります。

企業には数千人の従業員と数十の承認済みMCPサーバーがある場合があります。

各従業員が各コネクタを個別に認可することは望ましくありません。

エンタープライズ管理認可拡張機能により、組織はIDプロバイダーを通じてアクセス制御を集中管理できます。

サポートされているエンタープライズIdP構成には、Microsoft Entra ID、Okta、エンタープライズSSOシステムなどの製品が含まれる場合があります。

組織は、どの従業員がどのMCPサーバーにアクセスできるか、またいつアクセスを取り消すべきかを決定できます。

従業員は企業IDを使用して認証し、MCPサーバーごとに個別のOAuth承認を完了する必要はありません。

画像はMCP（Microsoft Copilot for Business）インターフェースの「Connectors」下の設定ポップアップを示しています。ポップアップのタイトルは「Enable for organization」で、その下にAsana、Atlassian、Canva、Figma、Granolaなどの複数のアプリがリストされ、各アプリの右側には青いトグルボタンがあり、現在すべてオンになっています。画像はコンテキストと密接に関連しており、コンテキストではMCPのエンタープライズ管理認可拡張機能が組織にIDプロバイダーを通じてアクセス制御を集中管理することを許可すると紹介されており、この画像はMCPで組織内アプリコネクタを有効にする操作インターフェースを直感的に示しており、ドキュメントで紹介されている組織ID管理に関連しています。

公式MCPドキュメントは、エンタープライズ管理認可を、デフォルトで全てのクライアントで有効になる機能ではなく拡張機能として説明しています。

クライアントと組織のIDインフラストラクチャの両方がこの拡張機能をサポートする必要があります。

認可メカニズムがより広範に強化されている

コア認可作業には、さらにいくつかのセキュリティ改善が加えられています。

RFC 9207 発行者検証

認可応答には iss 発行者パラメータを含めることができます。

クライアントは認可コードを交換する前に発行者を検証します。

これにより、認可サーバー混乱攻撃を防ぐことができます。

クライアント資格情報はその発行者にバインドされたまま

登録されたクライアント資格情報は、無関係な認可サーバー間で再利用されるべきではありません。

リソースが他の発行者に移行された場合、クライアントはその発行者に対して適切に登録する必要があります。

改善されたデスクトップおよびCLI登録

この改訂版では、動的クライアント登録中に application_type の動作が明確化されています。

これにより、認可サーバーがネイティブCLIやデスクトップアプリケーションをWebクライアントと誤認し、ローカルリダイレクトURIを拒否する事態を回避できます。

CIMDは新しいクライアント登録の指針

MCP認可プロジェクトは、新しい実装においてクライアントIDメタデータドキュメント（Client ID Metadata Documents、略称CIMD）へ向かっており、必要な場所ではDCR互換性を維持しています。

実際の推奨事項は、古いMCPチュートリアルに基づいたクライアント登録ではなく、現在の認可ドキュメントに従うことです。

ツールの完全なJSON Schema 2020-12

ツールスキーマもより表現力豊かになっています。

inputSchemaとoutputSchemaは、完全なJSON Schema 2020-12機能をサポートしています。

入力スキーマでは以下を使用できます：

oneOf
anyOf
allOf
$ref
$defs
条件文

出力スキーマは、もはや単一の狭いオブジェクト形状に限定されません。

structuredContentは、スキーマがサポートする任意のJSON値を表現できます。

これにより、APIが共用型（ユニオンタイプ）、条件付きフィールド、ネストされた再利用可能な定義、複数の出力形態、配列またはスカラー結果を持つ場合に、MCPツールはより正確に記述できるようになります。

Roots、Sampling、Loggingは非推奨に

3つの旧来のコア機能が正式に非推奨となりました：

機能 推奨される移行先
Roots ツールパラメータ、リソースURI、またはサーバー設定
Sampling LLMプロバイダーとの直接統合
Logging stdioではstderrを使用。構造化オブザーバビリティにはOpenTelemetryを使用

非推奨は即時削除を意味しません。

新しいライフサイクルポリシーでは、非推奨となった機能は削除が許可されるまでに少なくとも12ヶ月の移行期間が設けられています。

現在のSDKは互換性を維持するため、これらの機能を引き続きサポートする場合があります。

正式な非推奨ポリシーがMCPのアップグレードリスクを変える

ステートレスな再設計には破壊的変更が含まれています。

メンテナーは、このレベルの中断が常態化することを望んでいません。

新しい機能ライフサイクルは以下の段階を定義しています：

アクティブ（Active）
非推奨（Deprecated）
削除済み（Removed）

非推奨となった機能は、削除前に最低限のサポート期間が与えられます。

拡張機能はコアとは別に独立して進化させることもできます。

これにより、チームはより予測可能な移行計画を立てることができます。

MCPトンネルは異なるエンタープライズ課題を解決する

プロトコル改訂により、公共のリモートMCPサーバーをより簡単にスケールさせることができます。

エンタープライズはしばしば逆の問題に直面します：そもそもサーバーを公開したくないのです。

AnthropicのMCPトンネル機能は、Claudeホスト型エージェントおよび対応するClaudeプラットフォームワークフロー向けにこのユースケースを解決します。

軽量なゲートウェイが企業ネットワーク内部で実行され、アウトバウンド接続を確立します。

Anthropicはこのパターンを次のように説明しています：

  • 公共のMCPエンドポイントなし。
  • インバウンドファイアウォールルールなし。
  • 公共IP不要。
  • エンドツーエンドの暗号化トラフィック。

内部データベース、ERPシステム、プライベートAPI、ナレッジベース、チケットシステムは企業ネットワーク境界内に保持できます。

MCPトンネルは依然としてClaudeの製品機能であり、コアMCPプロトコルの要件ではありません。

Anthropicは現在これをリサーチプレビューと位置づけています。

MCPアプリとトンネルを混同すべきではない

どちらの機能も本番環境でのMCPを改善しますが、解決する問題は異なります。

機能 解決する問題
MCPアプリ MCPホスト内でのリッチなインタラクションUI
タスク 永続化された長時間実行ツール操作
エンタープライズホスティング認可 集中管理された企業

アクセスポリシー |
| MCPトンネル | 公開せずにプライベートMCPサーバーへアクセス |
| ステートレスMCPコア | スケーラブルなプロトコルトランスポート |
| MRTR | 長期のプロトコルセッションなしでの通話中のクライアント入力 |

サーバーはこれらの機能の1つ、複数、またはすべてを使用できます。

既存のMCPサーバー開発者は何を変える必要があるか？

サーバーが既に旧バージョンのMCPクライアントで動作している場合、開発者はすぐにすべてを書き直す必要はありません。

構造化された移行を実行すべきです。

ステップ1：隠れたセッション依存関係を棚卸しする

以下に依存するコードを検索します：

  • Mcp-Session-Id
  • メモリ内のセッション別ディクショナリ
  • スティッキールーティング
  • 接続ローカルのクライアント状態
  • 初期化時のみの機能ストレージ
  • サーバーインスタンスのアフィニティ

各依存関係がプロトコル状態、アプリ状態、認証状態、一時的な実行状態のいずれであるかを判断します。

アプリ状態は明示的なハンドルまたは適切な永続ストレージに移行します。

ステップ2：ステートレスなリクエスト処理をテストする

2026-07-28改訂版をサポートするSDKバージョンを使用します。

その後、複数のサーバーインスタンスでテストします。

有用なテスト構成の1つは次のとおりです：

クライアント
  ↓
ロードバランサー（ラウンドロビン）
  ↓
サーバーA / サーバーB / サーバーC

マルチステップワークフローを送信し、連続するリクエストがタスクを中断せずに異なるインスタンスに到達できることを確認します。

ステップ3：明示的な状態ハンドルを追加する

状態を必要とするワークフローの場合、安定した識別子を返します：

{
  "job_id": "job_7f18c9"
}

後続の呼び出しでその識別子を含めることを要求します：

{
  "job_id": "job_7f18c9",
  "action": "continue"
}

サーバー側で各ハンドルを検証します。

優れたハンドルは、強いエントロピー、テナントバインディング、認可チェック、有効期限、失効メカニズム、明確なエラーハンドリングを備えている必要があります。

ステップ4：ゲートウェイルールを更新する

Streamable HTTPを使用する場合は、以下のヘッダーを活用します：

Mcp-Method
Mcp-Name

ルーティング、レート制限、メトリクス、WAFポリシー、アクセスログを追加します。

ステップ5：キャッシュサポートを追加する

適切なリストおよび読み取り応答に対して、以下に従うか生成します：

ttlMs
cacheScope

ユーザー固有データの機密キャッシュコンテンツをユーザー間で共有しないでください。

ステップ6：レガシータスクを移行する

アプリケーションが実験的な 2025-11-25 Tasks APIを使用している場合は、拡張ライフサイクルに更新します。

テスト：

tasks/get
tasks/update
tasks/cancel

および input_required 状態。

ステップ7：非推奨機能をレビューする

Roots、Sampling、MCP Loggingを検索します。

明示的なツールパラメータまたはリソースURI、直接のモデルプロバイダー呼び出し、stderrまたはOpenTelemetryへの移行を計画します。

ステップ8：認可を再テストする

発行者検証、リダイレクトURI、クライアント登録、リフレッシュトークン、スコープ処理、アイデンティティプロバイダー互換性を検証します。

エンタープライズ展開ではEMAが適用されるかどうかを評価します。

ステップ9：旧クライアントをテストする

後方互換性はサーバーだけの問題ではなく、エコシステム全体の問題です。

テストマトリックスを維持します：

クライアント プロトコル改訂版 結果
現在のクライアント 2026-07-28 期待されるステートレスパス
旧クライアント 2025-11-25 互換性パス
サポート対象外クライアント 旧バージョン/不明 明確なネゴシエーション失敗

すべてのクライアントが同時にアップグレードされることを暗黙に想定しないでください。

ステップ10：本番環境前にオブザーバビリティを追加する

少なくとも以下を測定する必要があります：

  • リクエスト数。
  • ツール名。
  • レイテンシ。
  • エラー率。
  • タスクの所要時間。
  • 入力が必要な頻度。
  • キャッシュヒット率。
  • 認証失敗回数。
  • ダウンストリームAPIレイテンシ。
  • トレースID。

ステートレスなシステムはスケールしやすくなりますが、分散システムには優れたオブザーバビリティが依然として必要です。

例：移行前後の比較

移行前

サーバーはレポートオブジェクトをメモリ内に保存します：

sessions[session_id]["report"] = report

次のツール呼び出しは同じプロセスに到達することが期待されます。

移行後

サーバーは永続化された状態を保存します：

report_id = save_report(report)
return {"report_id": report_id}

次のツールは以下を受け取ります：

{
  "report_id": "report_123"
}

任意のサーバーインスタンスがそのレポートを読み込むことができます。

重要な変更はアーキテクチャレベルで発生します：

隠れたトランスポートセッション状態
→ 明示的なアプリ状態

ステートレスMCPはコスト削減を意味するか？

可能性はありますが、自動的には実現しません。

ステートレスなデプロイはインフラストラクチャの複雑さを軽減できます：

  • 共有MCPセッションストレージが不要。
  • スティッキールーティングの必要性が減少。
  • 自動スケーリングが容易。
  • サーバーレスデプロイが容易。
  • フェイルオーバーが簡素化。

キャッシュは重複するメタデータ呼び出しも削減できます。

しかし、アプリ状態には依然としてコストがかかります。

ワークフローが永続的な状態を必要とする場合、開発者はRedis、SQLデータベース、オブジェクトストレージ、タスクキュー、またはワークフローエンジンが必要になる可能性があります。

新しい設計により、開発者はプロトコルセッションによって1つの方式が強制されるのではなく、ストレージアーキテクチャを選択できるようになりました。

MCPは「AI分野のHTTP」になりつつあるのか？

元記事ではこの類推が使われています。

この類推は有用ですが、文字通りに解釈すべきではありません。

HTTPは基盤的なWeb転送標準であり、ほぼすべてのインターネットシステムで使用されています。

MCPは、AIクライアントとエージェントをツール、リソース、プロンプト、インターフェース、外部サービスに接続するための専門化されたプロトコルです。

この類推が捉えているのは、発展の方向性です：

  • 標準インターフェース。
  • 多数の独立したサーバー。
  • 多数の互換性のあるクライアント。
  • 共有された規約。
  • リクエストを汎用的にルーティングし観測できるインフラストラクチャ。

2026-07-28 の再設計は、MCPトラフィックが従来のステートレスなHTTPインフラストラクチャにより自然に適合するようになったため、この類推を強化しています。

MCPがHTTPに類似した普及度に到達できるかどうかは、依然として未解決の問題です。

エコシステムはClaudeよりも広い

MCPはAnthropicに起源を持ちますが、現在はより広範なオープンソースプロトコルプロジェクトとして運営されています。

このエコシステムには、独立したメンテナー、ワーキンググループ、仕様拡張提案、多数の言語のSDK、MCPアプリ、タスク、エンタープライズ認可拡張、レジストリ、および複数のAI製品における実装が含まれます。

例えば、MCPアプリは、MCPコミュニティの貢献者ならびにAnthropic、OpenAI、MCP-UIの参加者と共同で開発されています。

これは、クライアントとサーバーの両方が単一ベンダーに依存せずにプロトコルを実装できる場合、プロトコルの価値が高まるため、重要です。

現在のSDK環境

公式のMCPプロジェクトは、複数の言語でのSDK実装を保守または承認しています。

主要なリポジトリには、TypeScript、Python、Go、C#、その他のエコシステム向けのSDKが含まれます。

2026年6月の

候補リリース発表では、特に4つのファーストクラスSDKのベータ版サポートが強調されました：

  • TypeScript。
  • Python。
  • Go。
  • C#。

7月下旬までに、現在のSDKドキュメントには 2026-07-28 の動作が含まれています。

SDKの採用は個別に行われるため、使用している正確な言語とバージョンのリリースノートを常に確認してください。

より安全な移行戦略

本番システムでは、「切替日」方式の移行を避けてください。

より安全なプロセスは次のとおりです：

  1. 開発環境をアップグレードする。
  2. 一貫性テストを実行する。
  3. 2026-07-28 クライアントをテストする。
  4. 旧バージョンのクライアントをテストする。
  5. プレリリース環境でステートレスデプロイを有効にする。
  6. 複数のサーバーインスタンスを追加する。
  7. リクエストのクロスインスタンス分散を強制する。
  8. 認証をテストする。
  9. 長時間実行タスクをテストする。
  10. アプリケーション状態ハンドルをテストする。
  11. レイテンシとエラーを監視する。
  12. 段階的にロールアウトする。

これは、新しいリビジョンが意図的にコアなライフサイクル動作を変更しているため、特に重要です。

前提とすべきでないこと

すべてのサーバーが自動的にサーバーレス化されるとは想定しないこと

このプロトコルはサーバーレスデプロイをより自然にサポートします。

アプリケーションによっては、データベース、永続的なタスク実行基盤、ファイルストレージ、またはより長い実行時間が引き続き必要になる場合があります。

すべての状態が消えるとは想定しないこと

新しいワイヤーフォーマットから削除されるのは、プロトコルレベルのセッション状態のみです。

アプリケーション状態は引き続きアプリケーション自身の問題です。

MCPアプリがすべてのクライアントで動作するとは想定しないこと

拡張はネゴシエーションで決定され、ホストのサポート状況はさまざまです。

タスクが後方互換性を持つとは想定しないこと

現在のTasks拡張は、初期の実験的実装とは異なります。

非推奨が無効を意味するとは想定しないこと

Roots、Sampling、Loggingは非推奨期間中も引き続き利用できます。

すべてのクライアントが 2026-07-28 をサポートしているとは想定しないこと

SDKと製品の採用状況はさまざまです。

「オープンプロトコル」が「セキュリティ作業が不要」を意味するとは想定しないこと

MCPは強力なツールを実行できます。

認可、ユーザー同意、サンドボックス化、ツール設計、機密情報管理、監査は依然として極めて重要です。

よくある質問

MCP 2026-07-28とは何ですか？

MCP 2026-07-28 は、ローンチ以来のモデルコンテキストプロトコル最大のアーキテクチャ改訂です。主な変更点には、ステートレスなプロトコルコア、新しいワイヤーフォーマットでのセッションハンドシェイクの削除、ファーストクラス拡張、MCPアプリ、再設計されたTasks、MRTR、強化された認可、キャッシュメタデータ、正式な非推奨ポリシーが含まれます。

MCPは現在完全にステートレスですか？

2026-07-28 のプロトコル層はステートレスになるよう設計されています。アプリケーションは、明示的なハンドル、データベース、ワークフローシステム、その他の永続ストレージを通じて状態を維持できます。

Mcp-Session-Id はどうなりましたか？

2026-07-28 ワイヤーフォーマットは、プロトコルレベルの Mcp-Session-Id メカニズムを削除しました。現在のSDKは、後方互換性のために旧プロトコルリビジョンをネゴシエーションする際に、セッションベースの動作を引き続きサポートする場合があります。

AWS LambdaやCloudflare WorkersでMCPサーバーをデプロイできますか？

ステートレスプロトコルにより、リクエストがプロトコルレベルのセッションアフィニティを必要としなくなったため、サーバーレスおよびエッジデプロイが容易になりました。サーバーは引き続き、実行時間、ネットワーク、ストレージ、実行期間の制限を満たす必要があります。

MCPアプリとは何ですか？

MCPアプリは公式拡張であり、

互換性のあるMCPホスト内で、ダッシュボード、フォーム、チャート、その他のHTMLエクスペリエンスなどのインタラクティブなインターフェースをツールが返すことを可能にします。このインターフェースはサンドボックス化されたiframe内で実行され、MCPホストを介して通信します。

MCPタスクとは何ですか？

タスク機能により、サーバーは長時間実行される作業に対して永続的な非同期タスクハンドルを返すことができます。クライアントは tasks/get で状態をポーリングし、tasks/update で必要な入力を提供し、tasks/cancel で操作をキャンセルできます。

エンタープライズホステッド認可とは何ですか？

エンタープライズホステッド認可は、組織のアイデンティティプロバイダーを通じて集中化されたアクセス制御を実現するMCPの拡張です。IT管理者は、ユーザーごとに各サーバーを個別に認可することなく、エンタープライズアイデンティティポリシーに基づいてMCPサーバーへのアクセスを管理できます。

すぐに旧版MCPから移行する必要がありますか？

必ずしもそうとは限りません。SDKはバージョンネゴシエーションを通じて旧プロトコルリビジョンをサポートでき、非推奨機能には明確なサポート期間が設けられます。本番チームは、ステートレス設計がセッション、長時間実行操作、インフラストラクチャに関する前提を変えるため、テストを開始すべきです。

関連ツール

  • Model Context Protocol：MCP仕様、アーキテクチャ、SDK、拡張、開発者ガイドの公式ドキュメント。
  • MCP TypeScript SDK：MCPクライアントおよびサーバー向けの公式TypeScript実装。
  • MCP Python SDK：MCP開発のための公式Python SDKとサンプル。
  • MCP Go SDK：公式Go実装。現在ステートレスプロトコルパスをサポート。
  • MCP C# SDK：ステートレスパターン、タスク、互換性に関する詳細なドキュメントを含む公式.NET SDK。
  • MCP Apps：MCPホスト内のインタラクティブインターフェースのための公式拡張ドキュメントとSDK。
  • MCP Tasks：長時間実行される非同期MCP操作のための公式ドキュメント。
  • [MCP Registry](https://registry.modelcontextprotocol.

io/)：公開済みMCPサーバーを発見するための公式レジストリ基盤です。

関連リンク

概要

MCP 2026-07-28 改訂版は、プロトコルを大規模Webシステムで広く採用されているインフラストラクチャパターンへと押し上げます。リクエストは自己完結型になり、プロトコルレベルのセッションは新しいワイヤーフォーマットから消え、ゲートウェイルーティングが容易になり、通常の水平スケーリングにスティッキーなMCPセッションが不要になります。

同時に、エコシステムも発展しています。MCPアプリはインタラクティブなUIを追加し、タスクは永続的な非同期ワークをサポートし、エンタープライズ管理認証は企業アクセス権限を集中化し、MCPトンネルはClaudeプラットフォームユーザーに内部プライベートサーバーへの経路を提供します。

移行は単に「セッションIDを削除する」だけではありません。チームは隠れた状態依存を特定し、アプリケーション状態を明示的なハンドルまたは永続ストレージに移行し、MRTRとタスクをテストし、認証を更新し、旧クライアントとの互換性を維持し、適切な可観測性を追加する必要があります。

最も重要な変化はアーキテクチャレベルにあります：MCPは接続指向のエージェント統合パターンから、現代のクラウドインフラストラクチャにより自然に適合するステートレスで拡張可能なプロトコルへと移行しています。

MCP 2026-07-28 详解：无状态服务器、MCP 应用、任务、企业认证与新代理基础设施