Claude CodeのMCP接続をHTTPとSSEで切り分ける

結論：transportを明示し、2.1.266以降のfallbackを前提に診断する

一次情報はClaude Code公式changelogと公式MCPリファレンスです。changelogはlegacy HTTP+SSEへSSE fallbackする2.1.266の修正、MCP文書はremote HTTP serverの推奨構成、type、認証ヘッダー、信頼できるserverの確認を示します。

HTTP・streamable-http・legacy SSEの違い

設定・経路	向く場面	確認ポイント
HTTP	現在のremote MCP server	URL、認証、proxy、endpoint
streamable-http	MCP仕様の別名として記載された構成	Claude Codeのversionとserver文書
legacy HTTP+SSE	旧transportしか提供しないserver	2.1.266以降、SSE接続、再接続
stdio	ローカルprocess	command、環境変数、process終了

公式MCP文書では、remote HTTP serverにはHTTP transportが推奨され、urlがある設定でtypeを省略すると設定エラーになります。また、streamable-httpはHTTPのaliasです。serverのREADMEに古いSSE例が残る場合、まず現行形式へ移行できるか確認し、移行できない時だけfallbackを検証します。

8手順：MCP接続を安全に再現する

1. claude --versionとMCP serverのversionを記録し、2.1.266のfallback修正が対象か確認します。
2. project、user、managedのどこからserver定義が読み込まれるか分けます。
3. server名、URL、type、header名、scopeだけを台帳へ記録し、tokenやCookieの実値は残しません。
4. まず現行推奨のHTTPまたはstreamable-httpを指定し、JSON構文とURLを検証します。
5. legacy serverなら、SSE endpoint、proxyの長時間接続、server側の認証を確認します。
6. MCP一覧とdebug出力を読み、登録、transport選択、initialize、tool一覧のどこで止まったかを分けます。
7. 同じserverへ別clientを同時に当てず、ダミーのread-only操作でtool応答を確認します。
8. 移行するならstagingで試し、rollback条件、server管理者、許可toolを決めてから配布します。

接続できた後も、serverが外部コンテンツを取得するならprompt injectionのリスクがあります。公式MCP文書も、接続前にserverを信頼できるか確認するよう警告しています。接続成功を安全性の証明とせず、toolごとの読み書き、外部通信、データ持ち出しをレビューしてください。既存のMCPセキュリティ、MCP診断の秘密情報保護、managedMcpServersの運用が関連します。

接続失敗を4分類する

第一は設定エラーです。URLがあるのにtypeがない、JSONが壊れている、別scopeの設定が優先されている場合です。第二はtransportエラーで、HTTPは返るがSSEのstreamが開かない、proxyが接続を閉じる場合です。第三は認証エラーで、Authorizationの形式、期限、server側scopeが一致しません。第四はtool実行エラーで、initializeは成功してもtoolが拒否します。分類を飛ばしてtokenを入れ替えると原因が隠れます。

legacy SSEを継続する判断にも期限を置きます。server提供者のHTTP移行予定、TLS終端の担当、長時間接続の監視、切り戻し設定を確認し、古い経路を無期限に本番へ残しません。社内serverで移行に時間がかかる場合は、fallbackを使う対象versionとrepositoryを限定して台帳化します。

切り分けの順番は、client側のversionと設定、network、server、tool権限です。serverを再起動する前に、同じ時刻のclient debugとserver access logを突き合わせます。これにより、SSE streamが作られていないのか、proxyで閉じたのか、initialize後のtoolだけが拒否されたのかを説明できます。

本番のMCP定義を直接編集せず、検証用の複製でtransportだけを変えます。差分をreviewし、認証headerの名前、timeout、serverの公開範囲を確認してから戻します。接続が戻った後も、使えるtoolが増えていないかを一覧で確認してください。

チェックリスト：MCPを再接続する前に

□ versionを記録した　□serverの所有者を確認した　□URLとtypeを明示した　□HTTPとSSEを区別した　□認証情報をマスクした　□proxy timeoutを確認した　□initializeとtool実行を分けた　□read-onlyで試した　□外部通信を確認した　□stagingと本番を分けた　□rollbackを用意した

よくある質問

2.1.266なら古いSSE serverを必ず使えますか？

fallbackの対象になり得ますが、endpoint、認証、proxy、MCP仕様への適合までは保証しません。実serverでread-only検証を行ってください。

HTTP設定のtypeをstreamable-httpにすべきですか？

公式文書ではaliasとして扱われますが、serverの説明とversionを確認します。名称変更だけで接続保証にはなりません。

debugログをそのまま共有できますか？

共有せず、server名、transport、status、時刻、エラー要約だけを使います。URLのquery、Authorization、Cookie、tool引数を確認してください。

公式情報と無料診断

transport仕様は公式changelogと公式MCP文書を公開直前にreadbackしています。Miraigentの無料診断では、MCP serverの接続経路、権限、secret、監視、移行計画を業務フローへ整理できます。