結論：通知後は/mcpで状態を確認し、再実行前に副作用を照合する
Claude Code 2.1.273では、session中にMCP serverが切断し、自動再接続も諦めた時に通知が出て、/mcpへ案内されます。これは「toolが失敗した理由を黙って推測する」運用を変える更新です。通知を見たら対象server、最後に成功したtool、認証期限、通信経路、相手側の処理済み状態を確認してください。書き込みや送信を盲目的に再実行せず、復旧後の一回だけを検証します。
MCPは外部ツールやデータソースへ接続する仕組みなので、切断はClaude Code本体の問題とは限りません。serverプロセス、HTTP・SSEなどのtransport、proxy、token、接続先のrate limit、managed settingsを分けて見ます。復旧を急いで新しいserverを追加すると、同じデータへの二重経路や過剰権限を作るため注意が必要です。
根拠はClaude Code公式changelogとMCP公式リファレンスです。既存のMCP接続トラブル解決は初回設定・認証・transport全般、HTTP・SSE fallbackはlegacy接続方式、MCP診断のsecret保護はログの秘密情報を扱います。本稿は2.1.273の切断通知から始める再接続失敗の診断に限定します。
切断・再接続失敗・tool失敗を比較する
| 状態 | 意味 | 最初の確認 |
|---|---|---|
| 一時切断 | 接続が途切れ再接続を試している | server状態とnetwork |
| 再接続失敗通知 | 自動復旧を諦めた | /mcp、認証、最後のevent |
| tool error | 接続後の操作が失敗した | 入力、権限、相手側の処理 |
| 副作用の未確認 | 書き込み結果が不明 | 相手側のID・監査log |
通知がないから接続が正常とは限りません。tool結果が古い、timeoutが増えた、serverから返るresourceが空になった場合も、切断に近い影響があります。逆にserverが復旧していても、切断直前のcreate、send、updateが完了済みなら、再実行によって二重登録が起きます。操作を「読む」「変更する」「外部へ送る」に分類してから復旧操作を選びます。
再接続失敗を切り分ける9手順
- 通知を保存する。時刻、session、server名、表示されたerror、最後のtoolを記録します。
- sessionを固定する。別のterminalやworktreeで同じserverを調べていないか確認します。
- /mcpを開く。接続済みserver、状態、scope、再認証の案内を確認します。
- serverを単独確認する。プロセス停止、port、health check、server側logを読みます。
- 認証を確認する。token期限、refresh、scope、secretの差し替えを確認し、本文へ貼りません。
- 通信を確認する。DNS、proxy、TLS、firewall、allowlist、timeoutを順番に切り分けます。
- 設定の優先順位を見る。local、project、user、managed settingのどれがserver定義を上書きしたか確認します。
- 読み取りで復旧を試す。低リスクのlistやstatusだけで接続と返却データを確認します。
- 副作用を照合してから再実行する。request ID、remote record、監査eventがない操作だけを、責任者の承認付きで行います。
手順3でserverが見えない場合、再登録を先に行わず、設定scopeとmanaged policyを確認します。手順5で認証を更新した場合は、更新者、対象server、失効したcredential、復旧時刻を残します。手順8の読み取りが成功しても、書き込み権限まで戻った証拠にはなりません。readとwriteを別テストにし、writeはテストresourceで実行します。
再接続失敗が繰り返される場合は、待ち時間を短くして再試行回数を増やすことが解決にならない場合があります。server側のrate limitやtoken失効を悪化させるからです。通知を受けた時点でsessionの作業を安全な停止状態へ移し、担当者がserver側のhealthと監査logを確認してから再開します。復旧後は、同じ入力を一度だけ読み取り、相手側の更新時刻やIDを照合し、未知の状態を残したまま次の自動化へ進ませないようにします。
この復旧記録は、次回の障害訓練で再利用できる形式にします。
障害の分類を「Claudeが使えない」だけで終わらせず、MCP serverだけが止まったのか、Claude Codeのsession全体が止まったのか、外部サービスへの書き込みだけが不明なのかに分けます。分類ができれば、業務をread-onlyで継続するか、対象workflowだけを止めるか、全体をエスカレーションするかを判断できます。
復旧時刻と再発防止の担当者も、同じ記録に明記します。
担当者が変わっても、同じ手順で再現できることを確認します。
確認結果は次の担当者へ引き継げるよう、時系列で残します。
定期的に訓練して、手順を更新します。
復旧判断のチェックリスト
- 通知のserver名と実際に使ったserver名が一致している
- 最後のtool callが読み取りか副作用操作か分かっている
- server側で処理済みかをrequest IDで照合した
- token、proxy、TLS、DNSのどこを直したか記録した
- /mcpでscopeと権限を確認した
- 復旧確認は低リスクのreadから始めた
- 再実行する操作の重複防止条件を決めた
- 再発時にserverを止める担当者と連絡先が分かる
企業利用では、MCP serverの可用性をClaude Codeの可用性と同じSLAだと考えないことも重要です。外部システム側の障害をClaudeの回答品質の問題へ混ぜず、接続、認証、データ、操作結果を別の記録にします。再接続を何度も繰り返すより、一定回数で人間へエスカレーションする方が、外部APIの負荷と重複操作を抑えられます。
よくある質問
通知が出たらClaude Codeを再起動すべきですか？
必ずしも再起動が最初ではありません。まず/mcp、server状態、認証、通信を確認し、sessionや未完了操作の証跡を保全します。
自動再接続が成功したかどうかは？
通知が再接続失敗を示す場合は自動復旧を前提にせず、/mcpと低リスクreadで確認します。成功しても副作用の再実行は別判断です。
MCP serverを追加し直せば直りますか？
設定の重複や権限の拡大を生む可能性があります。既存定義、managed policy、認証scopeを確認してから変更します。
公式情報
次の一歩
MCPの切断対応を担当者の経験だけに依存させず、server、認証、権限、重複防止の境界を棚卸ししてください。Miraigentの無料診断では、外部連携を含む業務の停止条件と確認責任を整理します。