2026 MCP subscriptions/listen：単一プロセスか複数インスタンスか？

接続は成立しているのに、別のWorkerで発生したtools変更が通知されません。

単一プロセスならまずメモリ通知を使い、発行者と購読ストリームが別プロセスになる時点で通知バスへ移行してください。切断後はイベントの再送を期待せず、再購読と一覧・状態の再取得で復旧します。

この解説は、動的なtools、resources、prompts一覧を実装するServer開発者、複数インスタンスで長時間の通知ストリームを提供するプラットフォーム担当者、Clientの再接続やキャッシュ無効化を設計するAgentチーム向けです。

2026 MCP subscriptions/listenで最初に分けるべき三つの役割

MCP 2026-07-28では、subscriptions/listenは変更を知らせる通知ストリームとして扱われます。公式の変更履歴を確認すると、これは「現在の一覧や状態そのもの」を保存する仕組みではなく、変更を検知するための経路として設計する必要があります。実装の基準は2026-07-28仕様の変更履歴です。

設計上は、次の三つを混同しないことが重要です。

• 変化シグナル：toolsやresourcesなどが変わったことを知らせる通知
• 事実データの読み取り：通知を受けた後に一覧や状態を取得する処理
• 永続イベントログ：後から接続したClientにも過去のイベントを再生する保存層

subscriptions/listenを永続イベントログとして扱うと、切断中の変更をすべて補填できるという誤解が生まれます。実際には、通知を受け取ったClientが最新データを再読み込みし、現在の状態へ追いつく設計にする方が安全です。

Python SDKのClient文書でも、購読と通知を受けた後の読み取りは別の処理として説明されています。一方で、SDKごとに補助APIやServer側の対応範囲は異なるため、Pythonの実装をそのまま全言語の共通動作とは見なさないでください。確認にはPython SDKのClient購読文書とServer側購読文書を使います。

単一プロセスの開発では内蔵通知を優先する

発行処理と通知ストリームの保持処理が同じプロセス内にあるなら、メモリ上の購読者一覧とイベント発行で十分な場合が多いです。ここで外部のメッセージシステムを先に追加しても、通知の順序、接続終了、再読み込みの不具合が見えにくくなるだけです。

最初に確認するのは、次の五つです。

1. Clientが購読を開始した後、Server側で購読状態を確認できること。
2. tools、resources、promptsの対象を分け、関係のない変更を送らないこと。
3. Clientの切断時に、購読者とストリームが確実に解放されること。
4. 通知を受けたClientが一覧または状態を再取得すること。
5. 再接続時に購読を作り直し、古いキャッシュを有効な状態として扱わないこと。

単一プロセスでも通知バスは必須ですか。

必須ではありません。発行者とストリーム保持者が同じ実行環境にあり、プロセス再起動時に状態を再構築できるなら、メモリ通知を選ぶ方が検証範囲を小さくできます。ただし、将来Workerを増やす計画があるなら、通知インターフェースだけは外部化しやすい形にしておくと移行時の変更を抑えられます。

複数Workerでは「届かない場所」を先に特定する

Web Worker、プロセスプール、リクエストごとに処理が終了する実行環境では、イベントを発行したプロセスとSSEストリームを保持するプロセスが一致しないことがあります。Streamable HTTPを使っていても、HTTP接続の入口とイベント発行元が同じWorkerになる保証はありません。

subscriptions/listenを複数インスタンスで利用して通知を受け取れない場合は、次の順序で切り分けます。

• 発行元にインスタンス識別子とイベント識別子を記録する。
• ストリーム保持側で購読開始と受信待機の記録を残す。
• 通知バスに入る直前と、購読側が取り出す直後を記録する。
• 負荷分散装置を経由した場合と、単一の実行先へ固定した場合を比較する。
• Clientが通知を受けた後に、一覧の再取得を実行したか確認する。

この記録で、欠落箇所をアプリケーション内、通知バス、プロキシ、Clientのどこかに絞れます。ログに「発行した」という事実だけを残しても、別プロセスの購読者へ到達した証拠にはなりません。

MCPの通知ストリームに必ずメッセージキューが必要ですか。

必要なのは「プロセス境界を越えて通知を届ける経路」であり、特定の製品やメッセージキューそのものではありません。共有できる通知バス、軽量なPub/Sub、内部イベント配信層など、運用環境で再送範囲と障害時の挙動を説明できる仕組みを選びます。ただし、それを永続ログと呼べるかは別問題です。

複数インスタンスでは共有通知経路を追加する

負荷分散下では、インスタンスAがtools変更を受け取り、インスタンスBがClientの通知ストリームを保持する構成が起こります。この場合、Aのメモリ内イベントをBが読めないため、Clientが正常に接続していても通知は届きません。

共有通知経路の責任範囲は、インスタンス間へ変化シグナルを配ることです。接続が切れていた時間帯の全イベントを保存し、Clientへ完全に再生する機能まで、プロトコルや通知バスに自動的に付属するわけではありません。必要な整合性は、通知後の一覧再取得、状態読み取り、またはアプリケーション側の世代番号などで補います。

Serverを無状態に近づける場合でも、通知ストリーム自体は接続を保持するため、実行環境の終了、ローリング更新、アイドルタイムアウトの影響を受けます。認証情報や購読対象の扱いも、各インスタンスで同じ規則になるように確認してください。

Clientと運用担当者が受け持つ復旧範囲

subscriptions/listenは切断後に過去のイベントを自動で補いますか。

一律に補われるとは考えないでください。接続が失われたClientは、ストリームを再作成し、subscriptions/listenを再登録したうえで、tools一覧やresource状態などの依存データを読み直します。これにより、切断中に何件の通知が発生したかを数えなくても、現在の状態へ復帰できます。

旧版MCP Clientへ一覧変更を届ける場合は、Clientが対象の購読機能と通知形式を実装しているかを確認します。未対応なら、通知だけに依存せず、一定条件で一覧を再取得する互換経路を用意します。SDK更新では補助APIや移行点が変わる可能性があるため、Python SDKの変更点を確認し、利用言語の公式SDKでも同じ操作を検証してください。

プロキシや実行環境の検証では、次の項目を実際に再現します。

• SSEレスポンスが途中でバッファリングされず、イベントが逐次転送されるか。
• 接続を無通信のまま維持したとき、アイドルタイムアウトで切断されないか。
• プロセスの優雅な終了時にClientが再接続できるか。
• ローリング更新中に発行された変更を、再接続後の再読み込みで回収できるか。
• 通知と一覧取得の順序が逆転しても、Clientのキャッシュが古い状態へ戻らないか。

MDNのSSE転送説明はイベントストリームの基本動作を確認する資料になります。Uvicornを使う構成では、公式設定文書でWorkerや終了処理の設定を確認し、Streamable HTTPの実装差はRuby SDKの転送実装など、各SDKの文書とコードで照合してください。

配置形態別の選択マトリクス

評価は導入の簡単さ、通知到達の説明しやすさ、切断後の復旧設計を合わせた判断です。複数ノードであっても、永続ログを追加すれば自動的に正しくなるわけではありません。通知経路、最新データの取得、Clientの復旧処理を別々に受け入れ検査してください。

単一プロセスで始めるなら、過剰な共有基盤を避けて購読確認と再読み込みを先に固めます。複数Workerへ移す時点で到達テストを追加し、複数ノードへ広げる時点でプロキシの長時間接続とローリング更新を検証する、という順序が最も切り戻しやすいです。

macOS上の一時的な検証環境が必要なら、SSHMacのMacレンタルプランで実行場所を分け、SSHMacのヘルプセンターで接続条件を確認しながら、単一プロセスと複数Workerの差を検証できます。

現在の構成が単一プロセスなら、外部通知基盤を先に導入する方法には、運用対象の増加、障害箇所の分散、ローカル再現の難しさという欠点があります。反対に、複数ノードをメモリ通知だけで運用すると、発行元とストリーム保持先が分かれた瞬間に通知が欠落し、切断復旧の責任も曖昧になります。短期の検証や一時的な実行場所を用意する目的なら、SSHMacのMac環境を使って構成を分けて確認する方が、自前設備を固定的に増やすより判断しやすい場合があります。長期の安定運用や物理インターフェースが必要な処理には自前環境が適しますが、通知経路の検証、互換確認、短期間のAgent試験ではレンタル環境が現実的です。