allowAllClaudeAiMcpsでclaude.aiコネクタを排他制御と共存させる
managed-mcp.jsonの排他制御はclaude.aiコネクタも抑制します。allowAllClaudeAiMcpsで両立させる設定手順とセッション種別ごとの違いをまとめました。
allowAllClaudeAiMcpsは何を解決するか
managed-mcp.jsonを配置すると、Claude Codeはそのファイルが定義したサーバーだけをロードする排他制御に入ります。このとき抑制されるのはユーザーが自分で追加したサーバーだけではありません。管理者がclaude.ai管理コンソールで組織向けに設定したコネクタも含め、Claude Code自身が取得するclaude.aiコネクタが丸ごと止まります。
allowAllClaudeAiMcpsは、この抑制だけを解除する設定キーです。trueにすると、Claude Codeはmanaged-mcp.jsonが無いときと同じclaude.aiコネクタをロードしたうえで、managed-mcp.jsonのサーバーも引き続き使えます。既定値はfalseで、何も設定しなければ排他制御はclaude.aiコネクタを止めたままです。
なぜ排他制御はコネクタまで止めるのか
managed-mcp.jsonは「これだけを配る」という固定配布の仕組みで、対象は~/.claude.jsonや.mcp.json経由でユーザーが追加するサーバーに限られません。Claude Code自身が起動時に取得するclaude.aiコネクタも、ユーザーが追加したサーバーと同じ扱いで抑制対象に含まれます。組織のセキュリティ管理者からすれば、承認していないサーバーが紛れ込む経路を1つ残さず塞ぐ設計です。
ただしこの設計は、個々のユーザーがclaude.aiで許可を得て使っているコネクタ(Slack連携やGoogle Workspaceコネクタなど)まで一律に止めてしまいます。Google Workspaceコネクタの使い方のように組織管理者が個別に許可設定を行ったコネクタでも例外にはなりません。許可リスト・拒否リストを含むManaged MCP全体の設計はManaged MCPで許可リスト・拒否リストを組織管理するにまとめてあります。ここではmanaged-mcp.jsonとclaude.aiコネクタを共存させるallowAllClaudeAiMcpsだけを扱います。
設定手順 — 管理ソースのどこかに1行書く
設定はブール値で、3つの管理ソースのどれかに書けば反映されます。サーバー管理設定(claude.ai管理コンソール経由)、MDM配布のプロファイルやレジストリ、システムパスのmanaged-settings.jsonファイルです。
{
"allowAllClaudeAiMcps": true
}書く場所によって配布の速さが変わります。サーバー管理設定はClaude for TeamsとClaude for Enterpriseの管理コンソールから即座に配布でき、組織のOAuthログインか設定済みのAPIキーで認証しているユーザーに届きます。MDMプロファイルやレジストリキーはフリート管理ツールの反映サイクルに従うため、設定した直後に全端末へ届くとは限りません。managed-settings.jsonを直接配置する方法は、システムパスに書き込める管理者権限のあるプロセスが必要です。
設定後もallowedMcpServersとdeniedMcpServersは効く
allowAllClaudeAiMcpsを有効にしても、コネクタが無条件で通るわけではありません。allowedMcpServersとdeniedMcpServersはこのキーが読み込んだコネクタにも引き続き適用されます。特定のコネクタだけを止めたいなら、deniedMcpServersに表示名かURLパターンで登録します。
{
"deniedMcpServers": [
{ "serverName": "claude.ai Slack" }
]
}効果が及ぶ範囲も限定的です。このキーが対象にするのは、Claude Code自身が取得するclaude.aiコネクタだけです。プラグインが提供するMCPサーバーはmanaged-mcp.jsonの排他制御下では引き続き抑制されたままで、allowAllClaudeAiMcpsでは復活しません。
コネクタを許可リストに登録するときは、書き方に制約があります。allowedMcpServersのserverNameは英数字・ハイフン・アンダースコアに限られますが、claude.aiコネクタの表示名はclaude.ai Slackのように空白や記号を含みます。この形式はserverNameのパターンに一致しないため、コネクタを許可リストに載せるならserverUrlを使う必要があります。拒否リストのserverNameは任意の文字列を受け付けるので、ブロックだけなら表示名でも登録できます。
有効化後もツール単位の制御は独立して効く
allowAllClaudeAiMcpsはコネクタの接続そのものを解禁する設定で、コネクタが持つ個々のツールの可否とは別レイヤーです。組織はclaude.aiコネクタのツールごとにblocked(呼び出し前に除外)とask(呼び出しのたびに承認を求める)を設定でき、Claude Codeはこの設定を起動時に読み込んで自分で判定します。askの確認はacceptEditsやbypassPermissionsのような権限モードでもスキップされません。
デスクトップアプリのローカル・SSHセッションだけは扱いが違います。blockedはアプリ側がコネクタを渡す前に取り除きますが、askはClaude Codeに伝わらず、そのセッションの通常の権限ルールに従って処理されます。allowAllClaudeAiMcpsを設定してコネクタが使えるようになったあとも、どのツールが実際に呼び出せるかはこの組織設定次第です。
セッションの種類でコネクタの届き方が変わる
allowAllClaudeAiMcpsが効くかどうかは、セッションがどこで動いているかに左右されます。claude.aiコネクタが届く経路自体がセッションの種類ごとに違うためです。
| セッションの種類 | コネクタの届き方 | allowAllClaudeAiMcpsの効果 |
|---|---|---|
| ターミナル / VS Code / JetBrains / Agent SDK | コネクタの届き方Claude Code自身が取得 | allowAllClaudeAiMcpsの効果対象。管理ソースで設定した内容が反映される |
| クラウドセッション | コネクタの届き方リモートホストが渡す | allowAllClaudeAiMcpsの効果対象外。ホストにmanaged-mcp.jsonがあれば設定に関わらず抑制される |
| デスクトップアプリのローカル / SSHセッション | コネクタの届き方アプリがin-processで直接組み込む | allowAllClaudeAiMcpsの効果対象外。managed-mcp.jsonもこのキーも届かない |
セルフホストランナーのようなホストでmanaged-mcp.jsonを配置している場合、そのホスト上で動くクラウドセッションのコネクタはallowAllClaudeAiMcpsを設定していても抑制されたままです。クラウドセッションが受け取るコネクタは、ホストのmanaged-mcp.jsonではなく、そのセッションに届くallowedMcpServers/deniedMcpServers(サーバー管理設定経由など)でしか絞り込めません。デスクトップアプリのローカル・SSHセッションはさらに独立していて、アプリがコネクタをin-processのサーバーとして直接組み込むため、managed-mcp.jsonもこのキーもそもそも経路に関与しません。
クラウドセッションでserverUrlパターンを使うときも注意点があります。セッションのプロキシがコネクタのURLを書き換えるため、コネクタ自身のURLに合わせて書いたserverUrlは一致しなくなります。セルフホスト環境で配布済みのコネクタをURL許可リストと共存させたいときは、プロキシ経由後のURLに合わせた専用のエントリを追加する必要があります。
よくあるつまずき
管理者が最初に踏みやすい誤解を並べます。
- ユーザー側の設定ファイルに書いてしまう:
~/.claude/settings.jsonや.claude/settings.jsonにallowAllClaudeAiMcps: trueを書いても無視されます。ユーザー自身が排他制御を解除できない設計だからです - クラウドセッションも直るはずと思い込む: セルフホストランナー上の
managed-mcp.jsonがクラウドセッションのコネクタも抑制している場合、allowAllClaudeAiMcpsをどこに設定してもそのセッションには効きません - プラグイン提供のサーバーまで戻ると思い込む: このキーが対象にするのはclaude.ai由来のコネクタだけで、プラグインMCPサーバーは別扱いのまま抑制が続きます
- v2.1.259より前のクライアントで許可リストとの相性を確認せずに配布する:
managed-mcp.jsonのサーバーに${VAR}展開を使っていると、v2.1.259以降はallowedMcpServersとの評価順序が変わります。コネクタとサーバーの許可設定を同時に見直すタイミングでは、対象クライアントのバージョンも合わせて確認します
設定を確認する手順
配布後は管理対象のマシンで反映を確認します。/mcpを実行し、claude.ai由来のコネクタが一覧に表示されていれば設定が効いています。表示名の横にclaude.ai由来であることを示す表記が付きます。
/mcpコマンドラインからはmanaged-mcp.jsonによる排他制御の状態を確認できます。表示されるのはmanaged-mcp.jsonが定義したサーバーとmanagedMcpServersで配布したサーバーだけで、ユーザーが自分で追加したサーバーがまだ並んでいれば、ファイルが読み込まれていないサインです。claude.aiコネクタはこの一覧の対象ではないため、コネクタが届いているかどうかは前段の/mcpで確認します。
claude mcp listコネクタが一覧に出ない場合は、まず/statusで有効な認証方式を確認します。ANTHROPIC_API_KEYやapiKeyHelper、サードパーティプロバイダーが有効なセッションでは、claude.aiアカウントでログインしていてもコネクタ自体が取得されません。設定の反映漏れとコネクタ未取得の原因は切り分けて確認する必要があります。
/mcpの一覧で組織が認証を管理しているコネクタにはmanagedという表記が付きます。これは認証を組織側で管理していることを示すだけで、接続方法やツール単位のblocked/ask設定の適用範囲は変わりません。managed表記の有無で挙動を推測せず、実際にツールが呼べるかどうかは組織のコネクタ設定側で確認します。
組織が数多くのコネクタを配布している場合、ユーザーが一度もサインインしていないコネクタは一覧の末尾で折りたたまれ、Show unused connectorsの行を選ぶまで表示されません。allowAllClaudeAiMcpsを有効にしても一覧が短く見えるときは、抑制されているのではなくこの折りたたみに隠れているだけの場合があります。
まとめ
allowAllClaudeAiMcpsは、managed-mcp.jsonの排他制御とclaude.aiコネクタを共存させるための、管理ソース専用の1つのブール値です。組織が固定配布するMCPサーバーのセキュリティ境界を保ったまま、ユーザーが個別に許可を得ているコネクタも使わせたい場合に設定します。効果が及ぶのはClaude Code自身が取得するコネクタに限られ、クラウドセッションとデスクトップアプリのローカル・SSHセッションは別経路のため対象外です。設定後もallowedMcpServers/deniedMcpServersは引き続き効くので、コネクタ単位の細かい制御はそちらで行います。
MCP以外の組織向け機能でも、既定で止まっている外部連携を管理ソース側の1つの設定で解禁する構造はよく出てきます。Claude Code Channels組織管理の有効化もその一例で、対象の設定が読み込まれる場所を先に確認してから配布する進め方は共通しています。