# MCP新設計：subscriptions/listenの要点 > MCP 2026-07-28仕様はresources/subscribeを廃止し、subscriptions/listenに統合した。1接続で複数ストリームを多重化する新設計を解説する。 - Canonical: https://kuucorp.com/blog/mcp-subscriptions-listen-notification-redesign/ - Date: 2026-10-04 - Last modified: 2026-10-04 - Publisher: Kuu株式会社 (https://kuucorp.com) --- MCPサーバーを本番運用していると、リソース更新通知の実装がクライアントごとにばらつき、再接続時の挙動が読めないという相談が増えている。原因はMCP 2026-07-28仕様での仕様変更そのものにある。旧来の`resources/subscribe`リクエストと`notifications/resources/updated`の素朴な組み合わせは廃止され、`subscriptions/listen`という長命ストリームの仕組みに統合された。設計を正しく理解しないまま移行すると、多重サブスクリプションの取り違えや再接続漏れが起きる。 ## MCPのリソース通知はなぜ再設計されたのか > MCP 2026-07-28はセッション廃止と合わせ、個別の`subscribe`系RPCを汎用ストリームAPIに統合再設計した。 旧仕様では、リソース変更を監視したいクライアントは`resources/subscribe`リクエストを送り、サーバーは以後そのリソースについてだけ`notifications/resources/updated`を流していた。この方式はリソースの変更通知専用で、ツールリストやプロンプトリストの変更通知とは別経路だった。2026-07-28仕様はこれらを`subscriptions/listen`という単一の汎用リクエストに統合し、`notifications`フィルタで`toolsListChanged`・`promptsListChanged`・`resourcesListChanged`・`resourceSubscriptions`（監視対象URI配列）を同時に指定できるようにした。ステートレス化の一環として、サーバーはこのリクエストに応じて長命のストリームを開く。関連する全体像は[MCP 2026-07-28のステートレス化移行記事](/blog/mcp-2026-stateless-spec-migration-guide/)も参照してほしい。 ## subscriptions/listenはどう動くのか > サーバーは必ず`notifications/subscriptions/acknowledged`を最初に返し、`_meta`の`subscriptionId`でストリームを識別させる。 クライアントが`subscriptions/listen`を送ると、サーバーは実際に対応できる通知種別だけを反映した`notifications/subscriptions/acknowledged`を先に送らなければならない（MUST）。この確認応答より前に通知を送ることは仕様違反になる。確認応答と以後のすべての通知は、`_meta`内の`io.modelcontextprotocol/subscriptionId`に元のリクエストのJSON-RPC `id`をそのまま載せて運ばれる。クライアント側はこのIDを突き合わせることで、どの`listen`呼び出しに対する通知かを判定する。 ## 複数サブスクリプションをどう多重化するか > stdioは全メッセージが単一チャネルを共有するため、`subscriptionId`なしでは複数ストリームを区別できない。 1クライアントが複数の`subscriptions/listen`を同時に開く——たとえば「ツールリスト変更監視」と「特定リソースの更新監視」を別々に——ケースは仕様上想定されている。HTTPのStreamable Transportではストリームごとに論理的な分離があるが、stdioでは全通知が1本のパイプを共有するため、`subscriptionId`による多重化識別がなければどの監視対象の更新かを判別できない。エンタープライズでMCPゲートウェイを自社実装する場合、`subscriptionId`をルーティングキーとして扱うミドルウェア層の設計が必須になる。あわせて[Resources・Prompts・Toolsの使い分け](/blog/mcp-resources-prompts-tools-design/)も設計の前提として押さえておくと良い。 ## 再接続・切断時の設計で注意すべきことは > サーバー主導の正常終了は`resultType: "complete"`応答を伴うが、stdioは再接続時にサブスクリプション状態を保持しない。 サーバーがシャットダウンなどで自発的にストリームを終える場合、元の`subscriptions/listen`リクエストに対して`resultType: "complete"`を含む結果を返してから閉じるべき（SHOULD）とされている。この応答がなく通信が切れた場合、クライアントは異常切断と判断して再接続を試みてよい。注意すべきは、stdioでは再接続してもサーバー側にサブスクリプション状態が残らない点だ。クライアントは再接続後に全`subscriptions/listen`を再送する再確立ロジックを持つ必要がある。これを欠くと、障害復旧後にリソース変更監視が静かに失われ、キャッシュが陳腐化したまま気づかないインシデントにつながる。監査ログ基盤と合わせてサブスクリプション再確立イベントを記録しておくと、こうした静かな欠落を検知しやすい。MCPゲートウェイの運用設計は[エンタープライズ向けAgent開発支援（RDE）](https://kuucorp.com/services/rde/)で個別に相談できる。 ## 参考 - [MCP Specification 2026-07-28 — Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions) - [MCP Specification 2026-07-28 — Resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources) ## まとめ MCP 2026-07-28仕様の`subscriptions/listen`は、リソース・ツール・プロンプトの変更通知を単一の長命ストリームに統合した設計だ。`subscriptionId`による多重化と、stdioでの再接続時の再確立ロジックを押さえておけば、旧`resources/subscribe`からの移行は機械的に進められる。自社のMCPゲートウェイやクライアントSDKへの影響範囲の洗い出しに不安があれば、Kuuの[エージェント開発支援（RDE）](https://kuucorp.com/services/rde/)にご相談ください。