MCPセキュリティガイド — サーバーごとに許可する範囲をどう決めるか

MCPサーバーは、外部のツールやデータベースにClaude Codeから直接アクセスさせる接続口です。便利さと引き換えに、接続したサーバーの数だけ攻撃対象が広がります。許可判断は「接続前に何を確認するか」「権限ルールでどこまで絞るか」「組織としてどう一元管理するか」の3層で決まり、どれか1つだけを固めても抜け道が残ります。以下ではこの3層それぞれで、実際に設定できる項目に絞って基準を示します。サンドボックスや権限モード全体、データの学習利用を含むClaude Code全体のセキュリティ設計はClaude Codeセキュリティ・権限ガイドにまとめています。

MCPサーバーへの接続はどこにリスクがあるか

外部コンテンツを取得するMCPサーバーは、プロンプトインジェクションのリスクを持ち込みます。公式ドキュメントも「サーバーを信頼できるか、接続前に必ず確認する」ことを明記し、Webページやissueの本文を読み込むサーバーがその代表例として挙げられています。接続先のサーバーが返す出力は、ユーザーの指示と同じ文脈でClaudeに渡るため、悪意のあるテキストが紛れ込めばツール呼び出しを誘導される恐れがあります。

もう1つのリスクは提供元の不透明さです。Anthropic Directoryに掲載されたコネクタは審査を経ていますが、claude mcp addや.mcp.jsonへの直書きはそうした審査を経由しません。誰でも任意のURLやコマンドをサーバーとして登録できる以上、「公式が配布しているように見えるか」ではなく「自分がコードまたは提供元を検証できたか」を基準にする必要があります。この検証可能性は、MCPサーバーを自作して配布する側にも同じ基準で跳ね返ります。

プロジェクトスコープの.mcp.jsonは、この不透明さへの防波堤として承認フローを持ちます。リポジトリに同梱された.mcp.jsonのサーバーは、Claude Codeを対話的に起動してワークスペースの信頼ダイアログを受け入れるまで接続されません。クローンしただけのリポジトリは自分自身のMCPサーバーを承認できない設計です。

権限ルールでMCPツールをどこまで許可するか

MCPツールの権限ルールは、mcp__<サーバー名>__<ツール名>という名前空間で管理します。粒度は3段階です。

denyルールはグロブパターンを使えます。"mcp__*"と書けば、サーバーをまたいで全MCPツールを一括拒否できます。一方allowルールはmcp__<サーバー名>__という接頭辞が必須で、サーバー名部分にグロブは使えません。"*"や"mcp__*"のような接頭辞なしのallowグロブは警告付きでスキップされ、何も自動承認しません。許可は狭く書け、拒否は広く書けるという非対称な設計です。

権限モードとの組み合わせにも注意が必要です。dontAskモードは事前承認済みのツール以外を自動拒否します。ただしMCPサーバー側が_metaでanthropic/requiresUserInteractionをtrueに設定したツールは別扱いです。allowルールで許可していても常にプロンプトを出すか、dontAskモードでは拒否に倒れます。bypassPermissionsモードでも、このツールだけはプロンプトが残ります。同意そのものが目的のツール(アクセス許可の付与など)を自動承認すると、誰も同意していないのに処理が進む状態になるためです。

組織でMCPサーバーを一元管理するには

チーム・企業でMCP利用を統制する仕組みは、管理設定(managed settings)に集約されています。

• managed-mcp.json(排他制御): OSごとに決まったパス(macOSは/Library/Application Support/ClaudeCode/managed-mcp.json、Linux/WSLは/etc/claude-code/managed-mcp.json、WindowsはC:\Program Files\ClaudeCode\managed-mcp.json)に配置すると、そこに定義したサーバーだけがロードされます。ユーザーはプラグイン提供分を含め他のサーバーを一切追加・変更・利用できません。mcpServersを空にすればMCPを完全に無効化できます。この方式はclaude.aiコネクタも既定で抑制し、管理設定側でallowAllClaudeAiMcpsをtrueにした場合だけ元どおり読み込まれます(Claude Code v2.1.149以降)
• allowedMcpServers / deniedMcpServers: 管理設定でサーバーを許可・拒否リストに登録します。allowManagedMcpServersOnlyをtrueにすると、ユーザーやプロジェクトが追加したサーバーは無視され、管理設定の許可リストだけが有効になります。ただしdeniedMcpServersはどのスコープからでもマージされるため、拒否は常に効きます
• disableSideloadFlags: --plugin-dir --plugin-url --agents --mcp-configといったCLIフラグを起動時に拒否します。これらのフラグは、単発の実行に限って組織のマーケットプレイス制限を迂回できてしまうため、無効化すると抜け道を塞げます
• strictPluginOnlyCustomization: skills / agents / hooks / MCPサーバーを、プラグインまたは管理設定由来のものだけに限定します。trueで4種すべてを、["skills", "hooks"]のような配列で特定の種類だけをロックできます
• claude.aiコネクタの個別制御: 組織はコネクタの各ツールにask(毎回確認を強制。autoやbypassPermissionsでも例外なくプロンプトが出る)またはblocked(Claudeの目に触れる前にツール一覧から除外)を設定できます

認証方式ごとにどこまで信用してよいか

MCPサーバーの認証方式は、資格情報の置き場所と漏えい経路が異なります。

• OAuth 2.0: トークンはシステムキーチェーンなど安全な場所に保存されます。oauth.scopesを設定すれば、上流の認可サーバーがより広いスコープを提示していても、要求するスコープをその部分集合に固定できます。セキュリティチームが承認した範囲だけに絞る、公式サポート済みの手段です
• 静的ヘッダー(headers): .mcp.jsonに直書きすると、プロジェクトスコープではリポジトリにトークンがそのまま残ります。共有が前提のプロジェクトスコープに生トークンを書かず、環境変数展開(${VAR}・${VAR:-default})で参照する運用が安全です
• headersHelper: 短命トークンや社内SSOなど、OAuth以外の認証をカバーする代わりに任意コマンド実行という広い権限を伴います

スコープ自体もリスクの層になります。ローカルスコープ(既定)は~/.claude.jsonに自分専用で保存され、チームには共有されません。プロジェクトスコープは.mcp.jsonをバージョン管理に載せるため全員に届きますが、その分「見えない人が中身を確認できる」設計にもなっています。同じサーバー定義が複数スコープに存在する場合、Claude Codeはローカル → プロジェクト → ユーザー → プラグイン提供 → claude.aiコネクタの順で最初に見つかった定義だけを使います。フィールドはマージしません。サーバーの追加方法とスコープ指定の構文はClaude Code MCP設定ガイドに実装例とあわせてまとめています。

どの要因の組み合わせが最もリスクを上げるか

接続するMCPサーバーを判断するとき、確認すべき要因は次の4つです。

4つの中でも、外部コンテンツを取得するサーバーへの書き込み系ツール許可が最も影響が大きい組み合わせです。読み取り専用のツールと、ファイル書き込みやコマンド実行を伴うツールを同じ扱いにしないことが、許可設計の起点になります。

権限ルールの粒度は「到達範囲」で線を引く運用

MCPの許可設計は、機能名でなく到達範囲で区切ると破綻しにくくなります。mcp__<サーバー>__*で丸ごと許可するのは、そのサーバーの全ツールが同じ信頼度を持つときだけに限ります。読み取り系と書き込み系が混在するサーバーでは、個別ツール名まで指定したallowルールを積み上げるほうが安全です。

管理設定側でも同じ発想が効きます。allowManagedMcpServersOnlyで許可リストを一元化すれば、ユーザーが個人的に追加したサーバーは載りません。組織の統制と個人の生産性はここで衝突します。それでもdeniedMcpServersはどのスコープからでもマージされる設計です。「危険と分かっているサーバーを個人が有効化してしまう」事故だけは、許可リストの運用方針にかかわらず防げます。Coworkのデータ共有はこの管理設定とは別の権限モデルで制御されます(Coworkセキュリティ)。

よくある質問

MCPサーバーは追加しただけで自動的に有効になりますか

ローカル・ユーザースコープはコマンド実行時点で接続されます。プロジェクトスコープの.mcp.jsonだけは、ワークスペースの信頼ダイアログを受け入れるまで⏸ Pending approvalのまま止まります。

プロジェクトスコープの承認をリセットするには

claude mcp reset-project-choicesで、そのプロジェクトの承認選択をすべてリセットできます。誤って承認したサーバーを見直したいときに使います。

claude mcp reset-project-choices

headersHelperを使う設定は安全ですか

headersHelper自体は任意のシェルコマンドを実行する仕組みなので、コマンドの中身を信頼できる場合に限って使ってください。プロジェクト・ローカルスコープならワークスペース信頼ダイアログが1段防波堤になりますが、ユーザースコープにはその確認がありません。

claude mcp serveでClaude Codeを公開したときの責任範囲は

Claude Code自身をMCPサーバーとして公開すると、ファイル編集などのツールがそのまま外部のMCPクライアントに露出します。個々のツール呼び出しをユーザーに確認させる実装は、接続先のクライアント側の責任になります。

組織全体で特定のclaude.aiコネクタを禁止するには

deniedMcpServersに名前かURLパターンで登録します。全コネクタを止めたい場合はdisableClaudeAiConnectorsをtrueにするか、シェルセッション単位ならENABLE_CLAUDEAI_MCP_SERVERS=falseを使います。

OAuthのスコープを絞って接続するには

サーバー設定のoauth.scopesにスペース区切りの文字列でスコープを指定します。上流の認可サーバーが対応スコープをすべて提示していても、Claude Codeが要求するスコープはこの指定範囲に固定されます。

まとめ

MCPの許可判断は、接続前の信頼確認・mcp__名前空間の権限ルール・組織の管理設定という3層で成立します。押さえるべき点は3つです。

• 読み取り専用のツールと書き込み・実行系のツールを同じ扱いにしない
• headersHelperのようなコマンド実行を伴う認証方式は、中身を確認してから使う
• プロジェクトスコープの.mcp.jsonは信頼ダイアログの承認フローを前提に運用する

この3点を押さえれば、MCPサーバーを増やすたびに個別のセキュリティ判断をゼロから積み直す必要はなくなります。