結論：再登録の前に「設定・承認・通信・認証」を分ける
先に答えると、Claude CodeでMCPが接続できない時は、何度も削除して追加し直すのではなく、表示されている状態を固定し、設定、workspace trustと承認、transportとURL、認証、サーバープロセス、ネットワークの順に確認します。接続失敗という一つの表示でも、type不足、未承認、期限切れトークン、コマンド不在、サーバー停止では対処が異なります。
読者の困りごとは、設定例を貼ってもツールが出ず、どの層で失敗しているか分からないことです。この記事を読み終えれば、状態とエラーを九段階で切り分け、再現手順を添えて管理者や提供元へ渡せます。次の行動は、失敗中の設定を消さず、秘密値を除いた状態表示と確認時刻を記録することです。
最初に状態と変更点を記録する
ターミナルでclaude mcp listを実行し、対象サーバー名と状態を確認します。詳細はclaude mcp get サーバー名、セッション内では/mcpを使います。公式文書では、project設定が承認待ちならPending approval、拒否済みならRejected、URLが空ならnot configuredといった表示が説明されています。表示をそのまま記録し、推測で「ネットワーク障害」と決めません。
最後に接続できた時刻、直前に変えた設定、Claude Codeの更新、OSやVPNの変更、資格情報の更新を並べます。複数の変更を同時に戻すと原因が分からなくなるため、一回につき一項目だけ確認します。秘密値をログやチケットへ貼らず、サーバー名、transport、ホスト名、状態、時刻だけを共有します。
設定のtype・URL・commandを確認する
remote HTTPではtypeとURLが必要です。公式MCPリファレンスは、JSONにURLがあるのにtypeがない場合、stdioとして解釈され設定エラーになると説明しています。HTTPはhttpまたは仕様名のstreamable-httpを使います。SSEは非推奨なので、提供元がHTTPを案内しているなら古いSSE例を使い続けません。
stdioではcommandが実行可能か、引数の区切り、実行ファイルのPATH、必要な環境変数、作業ディレクトリを確認します。手動でコマンドを試す場合も秘密値を画面や履歴へ残さないようにします。設定ファイルの引用符、JSON構文、同名サーバーの重複、予約済み名称も確認してください。
workspace trustと承認状態を確認する
projectスコープの.mcp.jsonは、リポジトリへ置かれているだけでは自動的に信頼されません。初回にworkspace trustを受け入れ、サーバー設定を確認する必要があります。クローンしたリポジトリが自分自身を承認する設定は無視されるため、Pending approvalは通信障害ではありません。対話セッションで提供元と設定差分を確認して承認します。
拒否済みの場合はdisabled設定を確認し、理由が解消していないまま有効化しません。組織のmanaged settingsが優先される環境では、個人設定を変えても接続できない場合があります。その時は管理者へ対象サーバー、必要業務、必要権限を示して審査を依頼します。
MCP接続を切り分ける9手順
claude mcp listと/mcpで状態を固定します。- 直前の変更と最後の成功時刻を記録します。
- サーバー名、type、URLまたはcommandを公式手順と照合します。
- project設定ならworkspace trustと承認待ち・拒否を確認します。
- OAuthやトークンの期限、対象組織、権限を安全な画面で確認します。
- HTTPならDNS、プロキシ、VPN、TLS、提供元statusを確認します。
- stdioなら実行ファイル、PATH、依存関係、標準エラーを確認します。
- 安全なテストデータで再接続し、ツール数と読み取り結果を確認します。
- 直らなければ秘密値を除いた再現手順とログを管理者・提供元へ渡します。
公式文書ではHTTPやSSEの切断に対して指数バックオフで自動再接続する仕様が説明されています。接続中表示の直後に何度も操作せず、規定の再試行を待って状態を再確認します。一方、stdioはローカルプロセスであり同じ自動再接続ではないため、プロセス終了の原因をログから見ます。
認証エラーとネットワークエラーを分ける
401や認証画面のループは資格情報、対象アカウント、OAuth callback、期限の問題を疑います。403は認証済みでも組織やリソースへの権限がない場合があります。接続タイムアウト、名前解決失敗、TLSエラーはネットワーク、プロキシ、証明書、VPNを確認します。HTTPステータスとエラー時刻を記録すると、提供元statusとの照合ができます。
トークンを作り直す前に失効範囲と影響を確認します。広い権限へ変えて接続だけ通すのは解決ではありません。管理された端末でプロキシや許可ドメインが原因なら、個人が回避せず管理者へ必要なホスト名と用途を伝えます。
復旧後の確認チェックリスト
復旧後は、状態がconnected／想定ツール数／公開情報の読み取り成功／想定外の書き込みなし／資格情報がログにない／設定差分が承認済み／再起動後も接続／失敗原因と修正を記録、の八項目を確認します。一度つながっただけでは完了にせず、Claude Codeと端末を再起動した条件でも同じ範囲で確認します。
恒久対策として、承認済み設定例、更新担当、資格情報の期限、障害時の連絡先、停止方法を短い運用書へ残します。障害のたびに設定を全削除する運用は、原因と監査証跡を失います。最小変更とreadbackを標準にしてください。
管理者や提供元へ渡す情報
自分で直せない時は、発生時刻、Claude Codeの版、OS、サーバー名、transport、状態表示、直前の変更、再現手順、試した確認をまとめます。URLはホスト名まで、設定は秘密値を伏せ、トークンやAuthorizationヘッダーを添付しません。期待した状態と実際の状態を一文ずつ書くと、担当者が同じ地点から調査できます。
一時的に復旧しても原因が不明なら、再発監視の期限を置きます。自動再接続で見かけ上直った場合は、提供元障害、ネットワーク、認証更新のどれだったかをstatusやログで照合します。原因を断定できない時は未確認と記録し、広い権限や無期限の例外設定で回避しません。
同じ症状が再発した時に比較できるよう、正常時の状態表示も一度保存します。
公式情報と無料診断
状態表示と再接続仕様は公式MCPリファレンス、設定問題の案内は公式Troubleshootingと公式Debug your configurationで確認してください。
あわせて、Claude Codeの権限設定、企業導入の進め方、Claudeのセキュリティ確認も確認してください。
Miraigentの無料診断では、接続障害だけでなく、権限、データ、運用担当まで含めて導入経路を整理します。復旧後に同じ障害を繰り返さない管理表を作ります。