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のステートレス化移行記事も参照してほしい。
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の使い分けも設計の前提として押さえておくと良い。
再接続・切断時の設計で注意すべきことは
サーバー主導の正常終了は
resultType: "complete"応答を伴うが、stdioは再接続時にサブスクリプション状態を保持しない。
サーバーがシャットダウンなどで自発的にストリームを終える場合、元のsubscriptions/listenリクエストに対してresultType: "complete"を含む結果を返してから閉じるべき（SHOULD）とされている。この応答がなく通信が切れた場合、クライアントは異常切断と判断して再接続を試みてよい。注意すべきは、stdioでは再接続してもサーバー側にサブスクリプション状態が残らない点だ。クライアントは再接続後に全subscriptions/listenを再送する再確立ロジックを持つ必要がある。これを欠くと、障害復旧後にリソース変更監視が静かに失われ、キャッシュが陳腐化したまま気づかないインシデントにつながる。監査ログ基盤と合わせてサブスクリプション再確立イベントを記録しておくと、こうした静かな欠落を検知しやすい。MCPゲートウェイの運用設計はエンタープライズ向けAgent開発支援（RDE）で個別に相談できる。
参考
まとめ
MCP 2026-07-28仕様のsubscriptions/listenは、リソース・ツール・プロンプトの変更通知を単一の長命ストリームに統合した設計だ。subscriptionIdによる多重化と、stdioでの再接続時の再確立ロジックを押さえておけば、旧resources/subscribeからの移行は機械的に進められる。自社のMCPゲートウェイやクライアントSDKへの影響範囲の洗い出しに不安があれば、Kuuのエージェント開発支援（RDE）にご相談ください。