メインコンテンツへスキップ
AI駆動開発・開発生産性
Claude Code
AI駆動開発
セキュリティ
AI

Claude Code で第三者の MCP サーバーを安全に使う — 信頼の判断、許可リスト、managed-mcp.json

Claude Code に第三者の MCP サーバーをつなぐ前に。ローカルのサーバーはサンドボックスの外で動き、Anthropic は MCP サーバーを監査しない。.mcp.json の承認、許可・拒否リストの正しい書き方、managed-mcp.json、審査チェックリストを公式ドキュメントで整理します。

公開日
読了時間
13分
著者
友田 陽大
シェア

結論から書きます。MCP サーバーをつなぐことは、Claude Code に新しい手足を渡すことです。Claude がそのツールを呼ぶ操作は権限ルール(allow・ask・deny)を通りますが、ローカルで起動するサーバーのプロセス自体はサンドボックスの外で利用者のフル権限で動き、プロセスの中で何をするかは権限ルールからは見えません。 だから組織で決めるべきなのは「便利なサーバーを探すこと」ではなく、どのサーバーを、どの範囲の権限で、誰が承認して使うかです。

公式の Security ページは、Anthropic はディレクトリに載せる前に掲載基準で審査するが、MCP サーバーのセキュリティ監査や管理はしていないと明記しています。採否の判断は、利用する側の仕事です。

この記事は、組織で Claude Code を使う前提の セキュリティ・ガバナンス設計(権限・managed settings・サンドボックス) のうち、MCP の部分を掘り下げたものです。設定キーと挙動は、2026年10月12日に取得した公式ドキュメントで確認しました。バージョンで変わる箇所があるので、導入時点の版で確かめてください。


1. MCP サーバーに何ができるか

ローカルの MCP サーバーは、Claude Code が起動する別のプロセスで、利用者のフル権限で動きます。 サンドボックスのドキュメントは、command hooks や LSP サーバーと並べて「ローカルの MCP サーバーはフル権限で動く」と書いています。サンドボックスが囲うのは Claude が実行するシェルコマンドであり、MCP サーバーのプロセスではありません。

組織として想定すべきリスクは4つです。

リスクどういうことか
ローカルでの実行stdio のサーバーは端末上のプログラムなので、そのコードが読めるファイル、環境変数、通信先はすべて届く範囲になる
データの送り先リモートのサーバーには、ツールの呼び出しで渡す引数(コード、Issue の本文、顧客名など)が送られる
プロンプトインジェクション外部の内容を取り込むサーバーの応答は Claude の文脈に入る。公式も、外部の内容を取ってくるサーバーはプロンプトインジェクションのリスクにさらしうると警告している
見えない追加.mcp.json 以外のスコープ、claude.ai のコネクタ、プラグインもサーバーを足せる。公式も「.mcp.json を見るだけでは、セッションが読み込むサーバーの全体は分からない」としている

チーム全員に配る前に

Claude Code を組織で安全に使うための、権限とガバナンスの設計

2. スコープ:local・project・user と優先順位

MCP サーバーの設定は3つのスコープに置けて、同じサーバーが複数にあると、最上位のものだけが丸ごと使われます。

スコープ読み込まれる範囲チームと共有保存場所
local(既定)今のプロジェクトだけしない~/.claude.json
project今のプロジェクトだけする(バージョン管理)プロジェクトのルートの .mcp.json
userすべてのプロジェクトしない~/.claude.json

優先順位は local → project → user → プラグインのサーバー → claude.ai のコネクタです。フィールド単位で結合されることはありません。3つのスコープの重複は名前で、プラグインとコネクタは接続先で判定されます。組織が managed settings の managedMcpServers で配るサーバーは、これらすべてより上位です。

紛らわしい点が1つあります。MCP の「local スコープ」はホームディレクトリの ~/.claude.json に保存され、一般の設定でいう .claude/settings.local.json とは別物です。

3. プロジェクトの .mcp.json と承認:-p と SDK の例外

対話セッションでは、プロジェクトの .mcp.json にあるサーバーを使う前に承認を求められます。しかし claude -p、Agent SDK、クラウドのセッションではそのプロンプトを出せないため、確認なしで読み込まれます。

対話セッションの側には、クローンしたリポジトリが自分で承認を済ませる抜け道を塞ぐ仕組みがあります。リポジトリの .claude/settings.json にコミットされた enableAllProjectMcpServers や enabledMcpjsonServers は、信頼していないフォルダでは無視され、サーバーは承認待ちのままです。

問題は非対話の実行です。権限のドキュメントの表では、claude -p や SDK で一度も信頼していないフォルダの .mcp.json のサーバーは「承認の有無にかかわらず、確認なしで接続される」とされています。CI で他人のリポジトリや外部からの PR に対して Claude を動かすなら、次のいずれかで閉じます。

  • disabledMcpjsonServers に名前で載せる。すべての許可モードで止まります。
  • --setting-sources や SDK の settingSources で、プロジェクトの設定を読ませない。
  • --strict-mcp-config で起動し、--mcp-config で渡したサーバーだけを使う。
  • --bare で起動し、プロジェクトの .mcp.json を含む自動検出を止める。

なお、skipDangerousModePermissionPrompt をユーザー設定か managed settings に入れて bypassPermissions で始めたセッションでも、この承認は省かれます。

4. 組織の統制パターンを選ぶ

公式ドキュメントは統制の強さに応じたパターンを示しています。 まず、どれにするかを決めます。

パターン何が起こるか設定
MCP を無効化例外を除いてどのサーバーも読み込まれない空のマップの managed-mcp.json
固定配布全員が同じサーバーを使い、他は足せないmanaged-mcp.json
組織が提供指定したリモートのサーバーを全員に配り、各自のサーバーも残るmanaged settings の managedMcpServers
承認済みカタログ承認したサーバーの中から各自が選んで追加し、それ以外は止まるallowedMcpServers + allowManagedMcpServersOnly: true
緩い許可リスト許可リストはあるが、利用者が自分の設定で広げられるallowManagedMcpServersOnly なしの allowedMcpServers
拒否リストのみ既知の危険なものだけ止めるdeniedMcpServers

多くの組織にとって現実的なのは「承認済みカタログ」です。Claude Code には利用者が閲覧してインストールできる組み込みの MCP レジストリはないので、承認したサーバーと claude mcp add のコマンドを社内 wiki などで共有するか、管理されたプラグインのマーケットプレイスで配ります。

5. allowedMcpServers / deniedMcpServers の正しい書き方

許可・拒否リストの各エントリは、serverUrl・serverCommand・serverName のどれか1つだけを持つオブジェクトです。統制に使えるのは serverUrl と serverCommand で、serverName は使えません。

  • serverUrl:リモート(HTTP・SSE)のサーバーの URL。* のワイルドカードが使えます。ホスト名を完全に書いたパターンは既定のポート(https なら 443)だけに一致し、ホスト名に * を含むパターンはすべてのポートに一致します。
  • serverCommand:stdio のサーバーを起動するコマンドと引数の配列。引数の順番まで完全一致です。["npx", "-y", "server"] は ["npx", "server"] にも、--flag を足したものにも一致しません。ただし env ブロックは比較されません。
  • serverName:利用者が付けるラベル。公式は「どちらのリストでもセキュリティの統制ではない」としています。誰でも任意のサーバーに github と名前を付けられるからです。

評価の順番は、リストの結合 → 拒否リストの確認 → 許可リストの確認です。拒否リストに一致したサーバーは、何があっても止まります。許可リストに serverUrl のエントリが1つでもあれば、リモートのサーバーは URL で一致しなければならず、名前だけで通ることはなくなります(stdio と serverCommand も同様です)。

未設定と空の配列の違いも押さえます。

設定未設定(既定)空の配列 []値あり
allowedMcpServersすべて許可利用者が足すサーバーはすべて拒否一致するものだけ許可
deniedMcpServers何も止めない何も止めない一致するものを止める

そして最も誤解されやすい点です。allowedMcpServers と deniedMcpServers は managed 専用のキーではなく、どの設定ファイルにも書けます。 allowManagedMcpServersOnly を立てないと、ユーザーの ~/.claude/settings.json を含む各スコープの許可リストが結合され、利用者が許可を広げられます。また、allowManagedPermissionRulesOnly(権限ルールの鍵)を立てても、MCP の許可リストは強制されません。別の鍵です。

6. managed-mcp.json でサーバーを固定する

managed-mcp.json を置くと、その端末で使える MCP サーバーは組織が決めたものだけになります。 利用者は他のサーバーを追加・変更・使用できず、プラグインが提供するサーバーや --mcp-config で渡すサーバーも止まります。claude mcp add は企業ポリシーのエラーで失敗します。

置き場所は managed settings と同じシステムディレクトリです。

OSパス
macOS/Library/Application Support/ClaudeCode/managed-mcp.json
Linux と WSL/etc/claude-code/managed-mcp.json
WindowsC:\Program Files\ClaudeCode\managed-mcp.json

形式はプロジェクトの .mcp.json と同じです。注意点が3つあります。

  • サーバー管理設定では配れません。 独立したファイルなので、MDM・グループポリシー・構成管理など、管理者権限でシステムパスに書ける仕組みで置きます。排他制御が不要で、claude.ai から配りたいなら managedMcpServers を使います。
  • 空のマップで MCP をほぼ無効にできます。 ただし managedMcpServers で配ったサーバーなど、併用を許したものは読み込まれます。
  • ${VAR} を使うエントリは許可リストの確認を受けます。 変数展開を使わない組織のサーバーは確認を省かれますが、展開を使うと許可リストと照合されます。

ブロックされたサーバーは、利用者には理由が示されないまま /mcp と claude mcp list から消えます。新しい制限を入れるときは、どのサーバーが止まるかを事前に知らせてください。

7. 権限ルールで MCP のツールを絞る

サーバーを許可したあとも、ツール単位で ask や deny をかけられます。 権限ルールでは、MCP のツールを次の名前で指定します。

  • mcp__puppeteer:puppeteer というサーバーのすべてのツール
  • mcp__puppeteer__*:同じく、ワイルドカードでのすべてのツール
  • mcp__puppeteer__puppeteer_navigate:そのサーバーの特定のツール

deny と ask では "mcp__*" ですべてのサーバーのすべてのツールを指定できます。一方、allow のワイルドカードは mcp__<server>__ という具体的な接頭辞のあとでしか使えず、"mcp__*" を allow に書いても警告とともに無視されます。サーバー全体を一括で自動承認させない設計です。

運用の目安としては、読み取り系のツールは allow、書き込みや外部への送信をするツールは ask、使わせないツールは deny にします。また、リモートのサーバーで OAuth を使う場合は、oauth.scopes で要求するスコープを固定できます。公式は、認可サーバーが広いスコープを提示するときに、セキュリティチームが承認した範囲に絞る方法として案内しています。

8. 第三者の MCP サーバーの審査チェックリスト

採否は「便利かどうか」ではなく、「そのサーバーに渡すものと、そのサーバーが届く範囲」で判断します。 次の項目を、導入申請のテンプレートにすると運用しやすくなります。

観点確認すること
出どころソースコードが公開されているか。誰が保守し、最近まで更新されているか。自社で書けるならそれが一番確実
動く場所ローカル(stdio)か、リモート(HTTP)か。ローカルならフル権限で動く前提で、そのコードを読めるか
必要な権限どのトークンや API キーを要求するか。読み取りだけで足りるのに書き込み権限を求めていないか
トークンの範囲専用のアカウントや最小権限のトークンを発行できるか。OAuth なら oauth.scopes で絞れるか
通信先サーバーがどこへ通信するか。外部の Web やメールなど、信頼できない内容を取り込むか(インジェクションの入口)
外に出るデータツールの引数として、コード・顧客情報・社内文書が送られるか。リモートの提供元の保持方針は社内規程に合うか
版の固定npx などで最新版を毎回取ってくる構成になっていないか。版を固定し、更新は審査を通してから
統制の書き方許可リストに serverUrl か serverCommand で書けるか。必要なツールだけを allow にできるか

ローカルのサーバーに環境変数の秘密が渡るのが心配なら、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 で、stdio の MCP サーバーを含む子プロセスの環境から認証情報を取り除けます(GitHub トークンとプロキシ設定は残ります)。

9. 許可リストの設定例

次の例は、公式ドキュメントで確認したキーだけで組んだ「承認済みカタログ」の出発点です。 URL とパッケージ名は例なので、自社で審査したものに置き換えてください。

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://mcp.example.internal/*" },
    { "serverCommand": ["npx", "-y", "@example-org/docs-mcp-server@1.4.2"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ],
  "permissions": {
    "ask": [
      "mcp__github"
    ]
  }
}

この例の意図を補足します。

  • allowManagedMcpServersOnly があるので、ユーザーやプロジェクトの設定で許可リストを広げても無視されます。拒否リストは各スコープから結合されるので、利用者が自分でさらに止めることはできます。
  • serverCommand には版を含めた引数を完全な形で書いています。引数が1つでも違えば一致しないので、利用者が別の版や別の引数で起動したサーバーは止まります。
  • 拒否リストの https://*.untrusted.example.com/* は、ホスト名に * を含むのでそのサブドメインのすべてのポートに一致します。ホスト名を完全に書いてポートを書かないパターンは既定のポートにしか一致しないので、特定のホストを止めるときはポートの書き方に注意します。
  • mcp__github を ask にしているのは、利用者が github と名付けたサーバーのツールを毎回確認させるためです。名前は利用者が付けるので、どのサーバーを動かすかの統制は上の許可リストが担い、ask は確認の手間を足す補助です。
  • managed settings として配るので、ファイル・MDM・サーバー管理設定のどれでも配れます(managed-mcp.json と違い、サーバー管理設定でも配れます)。

10. 導入後に見ること

MCP の統制は、配って終わりではありません。 OpenTelemetry を設定しているなら、OTEL_LOG_TOOL_DETAILS=1 でツールのイベントに MCP のサーバー名とツール名が入り、利用者が実際にどのサーバーにつないでいるかを集計できます(この変数は既定では無効です)。許可リストに載せたのに使われていないサーバーは外し、申請が多いサーバーは審査にかけます。


まとめ:MCP は「信頼の判断」を設定に落とす仕事

MCP サーバーは、Claude Code の能力を大きく広げる一方で、ローカルのサーバーのプロセスはサンドボックスの外で利用者のフル権限で動き、外部の内容を Claude の文脈に持ち込みます。権限ルールが統制するのは Claude によるツールの呼び出し(第7節)であって、サーバーのプロセスの振る舞いではありません。Anthropic はサーバーを監査していないので、審査し、許可リストを serverUrl と serverCommand で書き、allowManagedMcpServersOnly で組織のリストだけを有効にし、CI では .mcp.json を読ませない。この4点が組織の基本線です。

権限モードやサンドボックスなど、MCP 以外の統制は Claude Code を組織に導入するときのセキュリティ・ガバナンス設計 にまとめています。自社の MCP の審査基準や許可リストの設計を外部に相談したい場合は、Claude Code 組織導入のセキュリティ・ガバナンス設計 で受け付けています。

よくある質問

Anthropic の公式ディレクトリに載っている MCP サーバーなら安全ですか?
安全が保証されているわけではありません。公式の Security ページは、Anthropic はコネクタを掲載基準に沿って審査してからディレクトリに加えるが、MCP サーバーのセキュリティ監査や管理はしていない、と明記しています。自分で書いたサーバーか、信頼できる提供元のサーバーを使うよう勧めており、採否の判断と審査は利用する側が行います。
リポジトリの .mcp.json に書かれたサーバーは、必ず承認を求められますか?
求められない場合があります。対話セッションでは承認のプロンプトが出ますが、claude -p、Agent SDK、クラウドのセッションではプロンプトを出せないため、確認なしで読み込まれます。CI などでは disabledMcpjsonServers で個別に拒否するか、--setting-sources や --strict-mcp-config でプロジェクトの設定を読ませないようにします。
allowedMcpServers を managed settings に書けば、利用者は他のサーバーを使えなくなりますか?
それだけでは使えてしまいます。allowedMcpServers はどの設定ファイルにも書けるキーで、各スコープの許可リストは結合されるため、利用者が自分の設定で許可を広げられます。組織の許可リストだけを有効にするには、managed settings で allowManagedMcpServersOnly を true にします。拒否リストは常にすべてのスコープから結合されます。
許可リストはサーバー名(serverName)で書けば十分ですか?
十分ではありません。serverName は利用者が claude mcp add のときに付けるラベルで、どんなサーバーにも github という名前を付けられます。公式も serverName はセキュリティの統制ではないとしています。リモートのサーバーは serverUrl、ローカルのサーバーは serverCommand で、実際に動く先を指定します。
MCP サーバーを完全に固定したい場合はどうしますか?
managed-mcp.json を各端末のシステムディレクトリに配ります。置くと、利用者は他の MCP サーバーを追加・変更・使用できなくなり、空のマップを置けば MCP をほぼ無効にできます。ただし独立したファイルなので、claude.ai から配るサーバー管理設定では配れません。MDM やファイル配布の仕組みで置きます。

参考文献

友田

友田 陽大

経済産業大臣賞 受賞プロダクト開発者。TypeScript + Python + AWS で、SaaS・業界DX・実用レベルの生成AI(RAG)を、要件定義からインフラ・運用まで一人で完遂します。

チーム全員に配る前に

Claude Code を組織で安全に使うための、権限とガバナンスの設計

許可モード・allow / ask / deny ルール・管理設定(managed settings)・サンドボックス・MCP サーバーの許可リスト・hooks・CI での使い方を、チームの方針として決め、設定に落とします。公式ドキュメントにある機能だけを前提に、端末管理と組み合わせた多層の設計にします。

プロジェクト単位(請負)・技術顧問のどちらにも対応可能です。まずは30分の無料技術相談から。

最短ルート:カレンダーから直接予約

相談内容が固まっている方は、フォーム送信よりその場で日程を確定する方がスムーズです。下記から空き時間をお選びください。

  • 30分のオンライン無料相談
  • Google Meet / Zoom / Microsoft Teams
  • NDA 商談前締結可・無理な営業はいたしません
無料相談の空き枠を予約する

あわせて読みたい