Azure App ServiceでMCPサーバーを運用している場合、今回まず確認すべきなのは「App Serviceのスケール設定」よりも「MCPサーバー実装がセッション前提になっていないか」です。2026年6月下旬にApps on Azure Blogで公開された「MCP Just Went Stateless — What the 2026 Spec Changes About Scaling on App Service」は、MCPの2026-07-28リリース候補でプロトコルレベルのセッションがなくなり、App Service上のMCPサーバーを水平スケールしやすくなる、という内容です。(TECHCOMMUNITY.MICROSOFT.COM)
分類はNoticeとして捉えるのが適切です。つまり、Azure App Serviceの既存環境が即座に強制変更される話ではなく、MCP仕様の変更に備えて、SDK、セッション管理、ロードバランシング、監視設定を点検するための情報です。特に、既存のMCPサーバーでinitialize、Mcp-Session-Id、ARR Affinity、Redisなどを使っている場合は、早めに棚卸ししておく必要があります。
Azure App Service上のMCPサーバーで何が変わるのか
今回の中心は、MCPがプロトコルレベルでステートレスになることです。従来のMCPでは、クライアントが最初にinitializeを呼び出し、サーバーからMcp-Session-Idを受け取り、その後のリクエストでも同じセッションIDを送る流れがありました。2026-07-28仕様では、この初期化ハンドシェイクとプロトコル上のセッションIDが削除され、各リクエストが自己完結する形になります。(TECHCOMMUNITY.MICROSOFT.COM)
Azure App Serviceの観点では、これはかなり大きな意味を持ちます。複数インスタンスにスケールアウトしたとき、どのMCPリクエストがどのインスタンスに届いても処理できる設計に近づくためです。以前は、セッションIDを発行したインスタンスに後続リクエストを寄せる必要があり、スティッキールーティングや共有セッションストアを検討する必要がありました。
| 確認ポイント | これまでの考え方 | 2026仕様での見方 |
|---|---|---|
| 初期化処理 | initializeで接続時に情報交換する | リクエストごとに_metaで必要情報を渡す |
| セッション | Mcp-Session-Idを後続リクエストで利用する | プロトコルレベルのセッションはなくなる |
| App Serviceのスケールアウト | セッション維持や共有ストアを意識する | 任意のインスタンスで処理しやすくなる |
| Redisなどの外部ストア | プロトコルセッション共有に使う場合がある | アプリ状態、キャッシュ、レート制限などに使う |
| 監視 | インスタンスごとのばらつきを見る | Application Insightsで分散状況を確認する |
影響を受けるAzure利用者
今回の影響が大きいのは、Azure App ServiceでリモートMCPサーバーをホストしているチームです。特に、AIエージェント向けにMCPエンドポイントを公開し、App Service Planで複数インスタンスにスケールアウトしている場合は、実装と運用設計の見直し対象になります。
一方、通常のWebアプリをApp Serviceで動かしているだけで、MCPサーバーを公開していない環境には直接の影響はほぼありません。また、単一インスタンスの検証環境では問題が表面化しにくいため、本番でスケールアウトしているか、今後スケールアウト予定があるかを基準に優先度を決めるとよいでしょう。
影響度の目安は次の通りです。
| 利用状況 | 優先度 | 確認すべきこと |
|---|---|---|
| App ServiceでMCPサーバーを本番運用している | 高 | SDK対応、セッション依存、ARR Affinity、監視 |
| App ServiceでMCPサーバーを検証中 | 中 | 2026仕様前提で設計し直せるか |
| API ManagementやFront Door越しにMCPを公開している | 中 | Mcp-Method、Mcp-Nameなどのヘッダー保持 |
| MCPを使っていない通常のWebアプリ | 低 | 直接対応は基本不要 |
| 既存アプリ内にMCPエンドポイントを追加予定 | 中 | 既存WebセッションとMCPの状態管理を分離 |
すぐ確認したいApp Service設定
まず確認したいのは、App ServiceのARR Affinityです。Apps on Azure Blogでは、App ServiceでMCPサーバーをスケールさせる場合、clientAffinityEnabled: falseを維持する考え方が示されています。2026仕様ではプロトコル側のセッションがなくなるため、App Serviceのロードバランサーが複数インスタンスへリクエストを分散しやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
Azure CLIで現在値を確認する場合は、次のように確認できます。
az webapp show \
--resource-group <resource-group-name> \
--name <app-name> \
--query clientAffinityEnabled \
-o tsvただし、clientAffinityEnabledを単純にfalseへ変えればよい、という話ではありません。同じApp Service上で通常のWeb画面やログインセッションも扱っている場合、MCP以外の処理がスティッキーセッションに依存している可能性があります。その場合は、MCPエンドポイントを別アプリに分ける、アプリ状態を外部ストアへ逃がす、ステージングスロットで負荷試験する、といった順序で確認するのが安全です。
MCPサーバー実装で確認すべきポイント
プロトコル変更の本丸は、アプリケーションコードとSDKです。既存実装でinitializeやMcp-Session-Idを前提にしている場合、2026-07-28仕様対応のSDKへ更新しただけでは済まない箇所が出る可能性があります。
特に確認したいのは次の点です。
| 確認項目 | 見る場所 | 対応の考え方 |
|---|---|---|
initialize処理 | MCPサーバーの接続初期化コード | 2026仕様では前提にしない |
Mcp-Session-Id | ヘッダー処理、Redisキー、ログ | セッションID依存を削除または置換 |
_meta | リクエスト処理 | プロトコルバージョン、クライアント情報を毎回読む |
server/discover | サーバー能力の取得処理 | 必要時に能力情報を取得できるようにする |
Mcp-Method / Mcp-Name | ゲートウェイ、WAF、アプリ側検証 | ヘッダーと本文の不一致を拒否する |
ttlMs / cacheScope | tools/list、リソース読み取り | キャッシュ可能なレスポンスを明示する |
MCP 2026-07-28リリース候補では、Mcp-MethodやMcp-Nameを使ってルーティングやレート制限をしやすくする変更、tools/listなどでttlMsやcacheScopeを使う変更、W3C Trace Contextを_metaで伝搬する変更も説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
「ステートレス化」してもRedisやDBが不要になるわけではない
ここで誤解しやすいのが、「MCPがステートレスになるならRedisやデータベースは不要になるのでは」という点です。不要になる可能性があるのは、プロトコルセッションを共有するためだけの仕組みです。アプリケーションとして状態を持つ必要があるなら、Redis、Cosmos DB、SQL Databaseなどの外部ストアは引き続き必要です。
たとえば、買い物かごを扱うMCPツールなら、セッションに隠して状態を持つのではなく、basket_idのような明示的なハンドルを返し、次回以降のツール呼び出しでそのIDを引数として受け取る設計にします。Microsoftのブログでも、こうした明示的ハンドルの考え方が紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次のように整理すると判断しやすくなります。
| 用途 | 外部ストアを残すべきか | 理由 |
|---|---|---|
| プロトコルセッションIDの共有 | 原則見直し | 2026仕様ではプロトコルセッションがなくなるため |
| ユーザー別の作業状態 | 必要 | 明示的ハンドルで参照する状態を保存するため |
| 高コストな検索結果のキャッシュ | 必要な場合あり | レイテンシとコスト削減に有効 |
| レート制限カウンター | 必要な場合あり | 複数インスタンスで一貫した制御が必要 |
| 会話メモリやエージェント状態 | 必要な場合あり | アプリ要件として状態を持つため |
監視ではインスタンス分散とトレースのつながりを見る
App ServiceでMCPサーバーをスケールアウトする場合、Application Insightsでインスタンスごとのリクエスト分散を確認することが重要です。ブログでは、cloud_RoleInstanceを使ってMCPリクエストが各インスタンスに分散しているかを見る例が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
requests
| where timestamp > ago(15m)
| where name contains "/mcp"
| summarize count() by cloud_RoleInstanceこの結果が特定インスタンスに偏っている場合は、ARR Affinity、フロントエンドのルーティング、クライアント側の接続再利用、ゲートウェイ設定を確認します。2026仕様ではリクエスト自体は任意のインスタンスで処理しやすくなりますが、実際の通信経路でヘッダーが落ちていたり、上流のリバースプロキシが意図せず固定ルーティングしていたりすると、期待通りに分散しません。
また、OpenTelemetryやApplication Insightsを使っている場合は、traceparent、tracestate、baggageの扱いも確認しておくとよいでしょう。2026仕様ではW3C Trace Contextの伝搬が整理されているため、ホストアプリ、MCPクライアント、MCPサーバー、下流APIまでを一つのトレースとして追いやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
破壊的変更として注意したい点
今回の2026-07-28仕様はリリース候補であり、最終仕様は2026年7月28日に公開予定とされています。また、破壊的変更を含むため、既存の本番環境でいきなり置き換えるのではなく、SDK対応状況を確認しながらステージング環境で検証するのが前提です。(TECHCOMMUNITY.MICROSOFT.COM)
特に次の点は、コード検索で早めに確認しておきたい項目です。
| 変更点 | 影響 |
|---|---|
initialize / initializedの削除 | 初期化処理に依存した実装は修正が必要 |
Mcp-Session-Idの削除 | セッションIDをキーにした状態管理は移行が必要 |
tasks/listの削除 | 実験的Tasks APIを使っている場合は見直し |
| Roots / Sampling / Loggingの非推奨化 | すぐ削除ではないが代替設計を検討 |
| リソース未検出エラーコードの変更 | -32002を直書き判定しているクライアントは注意 |
非推奨化は「即時利用不可」を意味しません。ただし、将来の削除や仕様変更に備える必要があります。特にエラーコードを文字通り比較しているクライアントや、古いSDKの挙動に依存したテストコードは、仕様変更時に壊れやすいポイントです。
Azure利用者向けの実務チェックリスト
既存環境では、次の順番で確認すると無駄が少なくなります。
| 順番 | 作業 | 判断基準 |
| -: | ————— | —————————————————– |
| 1 | MCPサーバーの有無を確認 | App Service上で/mcpなどのエンドポイントを公開しているか |
| 2 | SDKと仕様バージョンを確認 | 2025-11-25前提か、2026-07-28対応予定があるか |
| 3 | コード検索 | initialize、Mcp-Session-Id、tasks/listを検索 |
| 4 | App Service設定確認 | clientAffinityEnabledとインスタンス数を確認 |
| 5 | 状態管理の棚卸し | プロトコル状態とアプリ状態を分ける |
| 6 | ゲートウェイ確認 | Mcp-Method、Mcp-Name、MCP-Protocol-Versionが保持されるか |
| 7 | ステージング検証 | 複数インスタンスで負荷をかけ、状態と分散を確認 |
| 8 | 監視更新 | Application Insights、OpenTelemetry、アラート条件を見直す |
新規にMCPサーバーを作る場合は、最初から「セッションに隠して状態を持たない」設計にするのが安全です。既存環境では、RedisやDBを削除することを目的にせず、「何の状態を保存しているのか」を分類することから始めてください。プロトコル都合のセッション共有は減らせますが、アプリケーションに必要な状態まで消してはいけません。
まとめ：App Serviceの設定変更より先に、MCP実装の状態管理を確認する
「MCP Just Went Stateless」の重要点は、Azure App ServiceでMCPサーバーを普通のWebアプリに近い感覚で水平スケールしやすくなることです。ただし、これはAzure側の設定だけで完結する話ではありません。MCP SDK、プロトコルバージョン、セッションID依存、明示的ハンドル設計、ゲートウェイのヘッダー保持、Application Insightsでの監視まで含めて確認する必要があります。
すぐにやるべきことは、App Serviceで動いているMCPサーバーを洗い出し、initializeとMcp-Session-Idへの依存を検索し、ステージング環境で複数インスタンスの分散と状態保持を検証することです。2026-07-28仕様の最終化を待つだけではなく、今のうちに「プロトコル状態」と「アプリ状態」を分けておくと、移行時の手戻りを大きく減らせます。
コメント