結論：変数名・origin・状態で切り分ける

Claude Code 2.1.234では、MCPのscope競合警告がsecretの解決済み実値ではなく設定上の${VAR}形式を表示し、接続失敗詳細はserver originだけを表示するよう改善されました。診断時はtoken本文をticketやchatへ貼らず、変数名、設定scope、transport、origin、HTTP状態、request IDで原因を切り分けます。

読者の困りごとは、MCP接続障害を早く直そうとしてdebug出力を共有し、API key、token、内部URLまで漏らしてしまうことです。この記事を読むと、調査に必要な証跡と共有してはいけない値を分け、漏えい時の停止・失効判断ができます。

次の行動：現在のMCP設定でsecretが直書きか${VAR}参照かを確認し、ticketへ貼れる診断項目を事前にtemplate化してください。

公式仕様と改善範囲を確認する

公式changelog 2.1.234は、MCP diagnosticsがresolved secretを出力していた問題を修正し、scope-conflict warningではconfigured ${VAR} form、connection-failure detailsではserver originだけを示すと説明しています。これは重要な防御ですが、すべての周辺log、MCP server自身のstderr、shell history、screen captureまで自動で無害化する保証ではありません。

公式MCP文書では、設定scopeとしてlocal、project、user、managedを使い分け、HTTPまたはstdio等のserverを構成します。複数scopeに同名serverがあると、意図しない設定が優先されたように見えるため、競合警告には変数名とscopeが必要です。project設定をcommitする場合、secret実値ではなく環境変数参照を置き、実値は組織のsecret managerや実行環境へ分離します。

公式security文書はMCP serverを第三者code・外部systemへの接続点として扱い、信頼できる提供元、tool権限、prompt injection、data accessを確認するよう求めています。接続が成功しても安全とは限りません。診断の目的は「接続させること」だけでなく、正しいserver、正しい利用者、正しいscope、必要最小限のtoolへ接続したと証明することです。

共有可否を6軸で比較する

  1. 共有可能：Claude Code version、OS、transport、設定scope、server名、変数名、発生時刻です。
  2. 条件付き：server origin、port、request ID、repository名は内部構成や顧客名を含まないか確認します。
  3. 共有禁止：token、API key、cookie、authorization header、private key、refresh tokenの実値です。
  4. 置換必要：home path、user email、organization ID、customer endpointは仮名化します。
  5. 別保管：完全なdebug logは公開ticketへ置かず、期限付きのrestricted storageへ置きます。
  6. 即時対応：実値が一度でも表示・送信されたら、削除だけで終えず失効と再発行を判断します。

originはscheme、host、portまででも機密になり得ます。社内hostnameが組織名、project名、地域、環境名を含む場合は、外部vendorへ共有する前に置換します。一方で全部を「接続先A」にすると原因を追えません。public cloudかself-hostedか、HTTPSか、default portかという診断に必要な性質を残します。

変数名もCUSTOMER_A_PROD_TOKENのように情報を含むことがあります。共有用にはMCP_TOKENへ置換し、元のmappingは社内だけに保持します。redactionは星印を増やす作業ではなく、相手が原因を再現できる最小情報を設計する作業です。

安全に診断する7手順

  1. Claude CodeとMCP serverのversion、発生時刻、再現手順をsecretなしで記録します。
  2. local、project、user、managedの各scopeで同名serverがないか確認します。
  3. 設定内のcredentialを直書きから${VAR}参照へ移し、project fileへ実値を置きません。
  4. 環境変数が存在するかだけを確認し、値をecho、screenshot、promptへ出しません。
  5. transport、origin、certificate、HTTP状態、request IDを段階的に確認します。
  6. 共有前にlogを読み、token形式、email、path、内部host、顧客名をredactionします。
  7. 漏えいの疑いがあれば接続を止め、credentialを失効し、影響期間と利用logを確認します。

stdio serverでは起動commandとstderr、HTTP serverではDNS、TLS、proxy、OAuthを分けて確認します。認証失敗をnetwork障害として扱うと、必要以上にlogを増やしがちです。まずserver processが起動したか、originへ到達したか、認証challengeが返ったか、tool一覧を取得したかの四段階に分けます。

チェックリストとHOLD条件

  • 対応versionを確認した
  • 設定scopeを列挙した
  • 同名server競合を確認した
  • secretは環境変数参照
  • project fileに実値がない
  • 値をechoしていない
  • shell historyを確認した
  • server stderrを確認した
  • originの機密性を判定した
  • request IDの共有範囲を確認した
  • 顧客名を置換した
  • 共有先を制限した
  • 保持期限を決めた
  • 失効手順がある

HOLDするのは、secretの所在が不明、debug logを公開channelへ送る必要がある、第三者MCP serverの運営主体やdata利用条件を確認できない、広すぎるtoken scopeしか使えない場合です。接続復旧を急いでも、credential実値を共有する理由にはなりません。

よくある質問と次の行動

${VAR}が表示されれば値は安全ですか？

Claude Codeの該当診断表示では改善されていますが、server側logや別commandが値を出す可能性があります。共有物全体を確認します。

screen captureを送ってよいですか？

terminal周辺、statusline、window title、path、通知にも情報があります。必要範囲だけをrestricted channelで共有します。

漏えい後にmessageを削除すれば十分ですか？

十分ではありません。閲覧、転送、cacheを前提にcredentialを失効・再発行し、利用logと影響範囲を確認します。

修正内容は公式Claude Code changelog、設定scopeは公式MCP文書、安全要件は公式security文書で公開直前に確認してください。

server導入はMCP設定ガイド、権限設計はMCP securityガイド、接続切り分けはMCP troubleshootingへつなげます。Miraigentの無料診断では、secret保管、scope、共有log、失効ownerを整理します。