本文へスキップ
AI活用

Claude CodeでMCPに接続できない時の切り分け方|設定・接続方式・権限の3段

Hirokuma
12分で読める
Claude CodeでMCPに接続できない時の切り分け方|設定・接続方式・権限の3段

Claude CodeでMCPサーバーに接続できないとき、原因は設定・接続方式・権限の3段のどれかにほぼ収まります。上から順に見るのが最短です。ただし今は、その前にやることが1つあります。2026年9月17日公開のClaude Code 2.1.274で、切り分けの手がかりにしてきたエラー表示そのものの誤りがまとめて修正されました。403が「サインイン期限切れ」と誤報される、エラー文に秘密が混ざる、再接続の断念が黙って起きる。古いバージョンのエラー文を信じて原因を探すと、存在しない原因を追いかけることになります。まず本体を更新してから、3段で見る。この記事はその順番で書きます。

想定読者は、MCPサーバーを追加したのに「ツールが出てこない」「途中で切れる」「認証エラーが直らない」で止まっている人です。追加手順そのものは設定ガイドの記事に譲り、ここでは繋がらないときにどこを見るかだけを扱います。一次情報はClaude Code公式changelog(確認日: 2026-09-17)です。

症状を3つに分ける

切り分けの入口は、エラー文ではなく状態表示です。セッション内で /mcp を開くと、各サーバーの接続状態とツール一覧が見えます。ターミナルからは登録と接続状態を一覧できます。

# 登録済みサーバーと接続状態の一覧
claude mcp list

# 特定サーバーの設定内容を確認
claude mcp get <サーバー名>

ここで症状は3つに分かれます。

  1. 一覧にそもそも出てこない → 設定の段。登録先のスコープか設定ファイルの問題です
  2. 一覧にはいるが、接続失敗や切断になる → 接続方式の段。トランスポートやタイムアウトの問題です
  3. 接続はできているのに、ツール呼び出しが失敗する → 権限の段。認証スコープの問題です

自分の症状がどれかを先に決めると、見る場所が1つに絞れます。以降は段ごとに見ていきます。

Claude CodeにMCPサーバーを追加する設定ガイド|3つのスコープと.mcp.jsonの使い分けClaude CodeへMCPサーバーを接続する設定方法を解説します。claude mcp addの基本、local・project・userの3スコープの使い分け、.mcp.jsonのチーム共有と環境変数展開、接続確認と権限設定、サーバーを足しすぎない判断軸をまとめます。www.tentspace.net

1段目: 設定——そのサーバーはどこに登録されているか

一覧に出てこない場合、まず疑うのは登録先のスコープです。claude mcp add の設定はlocal・project・userの3スコープのどれかに保存され、別のディレクトリで登録したサーバーは、今のプロジェクトからは見えないことがあります。localスコープはプロジェクト単位だからです。

確認は claude mcp get <サーバー名> で、どのスコープに居るかまで表示されます。同名サーバーが複数スコープにある場合はlocal > project > userの優先順位で解決されるので、「直したはずの設定が効かない」ときは、別スコープの同名設定が勝っている可能性も見てください。この優先順位と保存先の構造は、スコープ解説の記事にまとめています。

もう1つ、projectスコープ(.mcp.json)のサーバーは初回に承認を求められます。過去に「使わない」と答えていると、その選択が残り続けます。claude mcp reset-project-choices でリセットできます。

stdio型(ローカルプロセス起動型)でここまで問題がなければ、起動コマンド自体の失敗を疑います。npx のパッケージ名の誤り、環境変数の未設定あたりが定番です。

2段目: 接続方式——「http」と旧HTTP+SSEの行き違い

一覧には居るのに接続に失敗する場合、トランスポートの段です。リモートのMCPサーバーには現行のStreamable HTTPと、旧仕様のHTTP+SSEがあり、Claude Code側の設定(--transport http / --transport sse)とサーバーの実装が食い違うと接続できません。

ここで効いてくるのが2.1.274の修正です。changelogの記載では、http として設定したサーバーが旧HTTP+SSEしか話さず、最初のリクエストに422など4xxを返すと接続できなかった不具合が修正されました。つまり更新前のバージョンでは、「設定は間違っていないのに、サーバーが旧仕様というだけで繋がらない」ケースがあったわけです。古いサーバー実装に接続する場合は、まず本体を2.1.274以降へ更新し、それでも駄目なら --transport sse での登録し直しを試す、の順が無駄がありません。

同じリリースには、接続後の「途中で切れる」に効く修正も入っています。

  • 約5分でツール呼び出しが切れていた: Streamable HTTPのツール呼び出しが、サーバー別に長いタイムアウトを設定していても約5分で切れていた不具合の修正。時間のかかる処理をMCPツール1本で待たせる設計は、更新前は5分の壁で崩れていたことになります
  • ツール一覧が更新されない: listChanged を宣言せずに変更通知を送るサーバーで、promptsとresourcesが更新されなかった不具合の修正

また、Bedrock・Vertex・Foundry経由やテレメトリ無効の環境も、既定で新しいMCPクライアント実装(v2)とMCP 2026-07-28のプロトコルネゴシエーションを使うようになりました。changelogには従来動作へ戻す環境変数(MCP_SDK_GENERATION=v1 / MCP_PROTOCOL_NEGOTIATION=legacy)も記載されています。更新直後に企業経路のMCPだけ挙動が変わった場合の一時的な切り戻し先として覚えておくと安心です。恒久対応はサーバー側の追従が筋です。

3段目: 権限——403 insufficient_scopeを読み違えない

接続はできているのに特定のツール呼び出しだけ失敗する場合、認証スコープの段です。スコープはOAuthの権限の単位で、「どの操作まで許可されたトークンか」を表します。OAuth認証つきのリモートサーバーでは、ログイン自体は済んでいても、そのツールが要求するスコープが手元のトークンに付与されていないと403 insufficient_scope で断られます。読み取り系のツールは通るのに書き込み系だけ失敗する、という非対称な症状が出たら、この段を疑うのが近道です。

ここが今回の修正で一番実務に効くところです。changelogの記載では、2.1.274より前は403 insufficient_scopeが「サインインの期限切れ」として報告されていました。この誤報に従うと、再ログインしても同じエラーが出続けます。足りないのはログインではなくスコープだからです。修正後は不足しているスコープ名が表示され、/mcp からの再認証へ誘導されます。

更新できない環境で「再ログインしたのに403が消えない」状態に当たったら、期限切れではなくスコープ不足を疑って、サーバー側の権限設定と /mcp の再認証を見てください。

切り分けの手がかりが、そもそも間違っていた

ここまで書いてきて分かるとおり、2.1.274の修正には共通の性質があります。直ったのはMCPの機能そのものというより、失敗の見え方です。

  • 403の原因が「期限切れ」と誤報されていた
  • MCPの接続エラー文とログインツールの説明文に、設定の ${VAR} から解決した秘密の値がそのまま表示されていた
  • 1つ前の2.1.273(2026-09-15公開)では、会話の途中でMCPサーバーが切断され自動再接続が断念された時点で /mcp を指す通知が追加されました。裏を返せば、それまで再接続の断念は黙って起きていたことになります

エラー文を信じて切り分ける、という当たり前の前提が、この領域ではまだ揺れている。それがこの並びから読み取れることです。

私も同じ形を踏んでいます。この記事を書いているブログの公開処理は自作のMCPサーバー経由で動かしていますが、9月11日の定時実行では、そのMCPサーバーのツール群がセッションに接続されないまま処理が始まり、公開パイプラインが使えない状態で終わりました。接続の欠落はエラーとして飛んでくるのではなく、「ツールが最初から存在しない」という静かな形で現れました。エラーが出ていないことは、繋がっていることの証明にはなりません。

だから切り分けの起点は、エラー文ではなく /mcp と claude mcp list の状態に置くのが安全です。エラー文は状態を確認した後の補助情報として読む。この順番なら、表示の誤りに引きずられる余地が減ります。

無人運用では、接続を前提にしない

対話中なら /mcp を自分で開けますが、cronやCIからの非対話実行では誰も画面を見ていません。接続の欠落を静かに見逃さないために、2.1.274で入った新しい設定が使えます。

# 非対話実行の初回ターンが、接続中のMCPサーバーを待つ時間の上限(ミリ秒)
# 0を指定すると待たずに開始する
CLAUDE_CODE_MCP_STARTUP_WAIT_MS=15000 claude -p "..."

changelogの記載では、CLAUDE_CODE_MCP_STARTUP_WAIT_MS は非対話の初回ターンが接続中のMCPサーバーを待つ時間に上限を置く設定です。起動直後にMCPツールを呼ぶ定時実行では、接続が確立する前に本文の処理が始まってしまうと「ツールが存在しない」側の失敗になります。待ち時間を明示すれば、この競合を設定として制御できます。

そのうえで、運用側に置ける手当ても2つあります。1つは、処理の最初に読み取り専用のツールを1本呼んで、接続の有無をその場で確認する工程です。9月11日の欠落は「使う予定のツールが最初から存在しない」という形で現れたので、本処理へ進む前にツールの存在を確かめる一手を置けば、この種の欠落はその場で検出できます。もう1つは、実行結果をClaude Codeの外側(実行記録と通知)で数える層です。2.1.273で追加された切断通知は人が見ているセッションでは有効ですが、無人実行では通知を見る人がいません。欠落は外側の記録で数えられる形にしておくほうが安全なはずです。非対話実行の組み立て自体はヘッドレスモードの記事にまとめています。

無人実行まわりでは、直近2リリースに関連する修正が他にも入っています。changelogの記載では、2.1.274ではSDKホストのMCPサーバーがまだ接続中のうちにクラウドセッションの初回ターンが始まってしまう不具合が修正され、2.1.273ではWeb版の定時実行(Routine)が、管理者が組織のコネクタを外して入れ直した後も古いコネクタを呼び続ける不具合が修正されています。どちらも「接続が確立していない、または古いまま」を検知せずに走ってしまう系統の問題で、無人実行での接続欠落が、特殊な事故ではなく公式が続けて手を入れている領域だと分かります。

更新してから、3段で見る

最後に手順を1枚にまとめます。

  1. まず本体を更新する。2.1.274より前のエラー表示には誤報が含まれていました。古い表示を信じて切り分けない
  2. /mcp と claude mcp list で状態を見る。一覧に無い→設定、接続失敗→接続方式、403→権限、と症状で段を決める
  3. 設定の段はスコープの場所と優先順位、projectスコープの承認状態を見る
  4. 接続方式の段は旧HTTP+SSEとの行き違いと、5分タイムアウト問題の修正有無(=本体バージョン)を見る
  5. 権限の段は「期限切れ」表示を鵜呑みにせず、スコープ不足として /mcp の再認証を試す
  6. 無人実行は CLAUDE_CODE_MCP_STARTUP_WAIT_MS で接続待ちを明示し、処理の最初に読み取り系ツールで接続確認を置く

一次情報は公式changelogです。この記事の修正内容の記述はすべてchangelogの記載を根拠にしており、個々の不具合の再現は手元では未検証です。

Claude Code公式changelog(2.1.274 / 2.1.273)Release notes for Claude Code, including new features, improvements, and bug fixes by version.code.claude.com