GitHub Copilotは、Model Context Protocol（MCP）に対応したことで、GitHubリポジトリの操作だけでなく、Playwrightによるブラウザ自動化やファイルシステム操作、社内システムとの連携など、さまざまな外部ツールをエージェントから呼び出せるようになりました。開発者にとっては非常に便利な拡張手段ですが、組織の管理者から見ると「誰が、どのMCPサーバーを、どんな権限で使っているか」が把握しづらくなるという新しい課題も生まれます。
MCPサーバーの利用拡大とガバナンスの課題
Microsoftが提供するCopilot Studioでも同様に外部ツールとの接続が広がっており、企業導入が進むにつれてガバナンス面の要件が強まっている点は共通しています。Copilot StudioとGitHub Copilotの役割の違いについては、以前の記事「GitHub Copilot・Copilot Studio・Microsoft 365 Copilotは何が違う？目的で選ぶ生成AIツール活用ガイド」でも整理していますので、あわせてご覧ください。
こうした背景を受けて、GitHub Copilotには2026年8月6日、エンタープライズ管理者がMCPサーバーの利用を一元的に制御できる新機能が一般提供（GA）されました。本記事では、この「MCP allowlist」機能の仕組みと設定方法を、実際の設定例とともに解説します。
GitHub CopilotのMCP allowlistとは（2026年8月6日 一般提供）
今回追加されたのは、allowedMcpServers と deniedMcpServers という2つのキーです。これらはGitHub Copilotの「enterprise managed settings（エンタープライズ管理設定）」に追加する形で使用し、組織内のCopilotクライアントが実行できるMCPサーバーを許可リスト・拒否リストで一元管理できます。
これにより、開発者が業務に必要とするMCPサーバーは承認しつつ、信頼できない、あるいは社内のコンプライアンス基準を満たさないMCPサーバーは組織全体でブロックする、という運用が可能になりました。対応クライアントは、GitHub Copilotアプリ、Copilot CLI、VS Codeの3つです（2026年8月時点）。
設定方法：managed-settings.jsonの書き方
3つのマッチング方法（serverUrl / serverCommand / serverName）
MCPサーバーの識別には、以下の3種類のマッチャーを使用します。
- serverUrl：リモート（HTTP/SSE）サーバーを対象とします。
*によるワイルドカードに対応しており、URLを正規化した上で照合するため、末尾のスラッシュ有無などによる回避を防ぎます。 - serverCommand：ローカル（stdio）サーバーを対象とし、コマンドと引数を完全一致で照合します。
- serverName：ユーザーが付けたサーバーのラベル名で照合します。ただし、ユーザー側で自由に名前を変更できてしまうため、公式ドキュメントでも「あくまで利便性のためのものであり、セキュリティ上の制御ではない」と明記されています。名前だけに頼った制御は避けるのが安全です。
サンプル設定（コード例）
設定は copilot/managed-settings.json というファイルに記述します。以下は公式ドキュメントで示されている設定例です。
{
"allowedMcpServers": [
{ "serverUrl": "https://api.githubcopilot.com/*" },
{ "serverCommand": ["npx", "@playwright/mcp@latest"] },
{ "serverCommand": ["cmd", "/c", "uvx", "markitdown-mcp"] }
],
"deniedMcpServers": [
{
"serverCommand": [
"npx",
"-y",
"@modelcontextprotocol/server-filesystem",
"/"
]
}
]
}この例では、allowedMcpServers に列挙した3つのいずれかに一致するサーバーが許可されます。一方で、ファイルシステムのルート（/）にアクセスするよう設定されたfilesystemサーバーは、たとえ許可リストの条件に一致していても deniedMcpServers によって常にブロックされます。拒否ルールが許可ルールより優先される、という点がポイントです。
配置場所とデプロイ方法
設定ファイルは、多くの場合、組織のソースとなる .github-private リポジトリ内に配置し、デフォルトブランチにコミットすることで反映されます。モバイルデバイス管理（MDM）を使ってユーザーの端末に直接配布する方法も用意されています。
評価ルールを理解する
評価順序（4ステップ）
Copilotクライアントは、MCPサーバーの実行可否を次の順序で判定します。
- GitHub MCP Serverなど、組み込みのデフォルトサーバーは常に許可します。
deniedMcpServersのいずれかに一致する場合はブロックします。allowedMcpServersが設定されている場合、その中のどの条件にも一致しないサーバーはブロックします。- サーバーのURLやコマンドに
${VARIABLE}のような未解決の変数が含まれる場合、クライアント側で検証できないためブロックします。
フェイルクローズ設計の意味
この機能は「フェイルクローズ（fail closed）」という設計思想を採用しています。つまり、設定ファイルのJSONが壊れている、あるいは内容を検証できない場合には、「とりあえず全部許可する」のではなく、「組み込みのデフォルトサーバー以外はすべてブロックする」という安全側の挙動になります。設定ミスがそのまま抜け穴になりにくい設計です。
複数レイヤーの設定がある場合の挙動
managed-settings.json は複数のデプロイ方法（リポジトリ経由・MDM経由など）から同時に配信される場合があります。この場合、いずれかのレイヤーで拒否ルールに一致すればブロックされ、許可リストが定義されているすべてのレイヤーで一致して初めて許可される、という積み上げ方式になっています。ネットワークエラーなどでポリシーを取得できない場合は、直前に有効だったポリシーが維持され、より制限が緩む方向には変化しません。
対応クライアントと導入時の注意点
現時点でのサポート範囲
2026年8月時点で、MCP allowlistが実際に効力を持つのは、GitHub Copilotアプリ、Copilot CLI、VS Codeの3クライアントです。他のIDE統合については今後の対応拡大が見込まれます。導入を検討する際は、自組織で使用しているクライアントが対応範囲に含まれているかを事前に確認しておくとよいでしょう。
既存のカスタムレジストリ制限との競合に注意
すでに社内でMCPサーバーのカスタムレジストリなど別の制限手段を運用している組織では、allowlistの導入によって二重の制御がかかる可能性があります。「レジストリ経由のサーバーだけを許可する」といった既存ポリシーとの整合性を事前に確認しておかないと、「設定したのにMCPサーバーが起動しない」「原因が特定しにくい」といったトラブルにつながりやすい点は注意が必要です。
overridable設定でチームに裁量を持たせる
サーバー管理型のデプロイでは、allowedMcpServers と deniedMcpServers の両方に overridable を指定できます。これにより、全社的なベースラインを維持しつつ、各チームがその上に独自の許可・拒否リストを追加できるようになります。全社統制とチームごとの柔軟性を両立させたい場合に活用できる仕組みです。
まとめ：MCP活用と統制のバランス
GitHub CopilotへのMCP allowlist導入は、エージェントが呼び出せる外部ツールの範囲が急速に広がる中で、企業が「便利さ」と「統制」のバランスを取るための重要な一歩といえます。設定自体はJSONファイル1つで完結するシンプルなものですが、フェイルクローズ設計や複数レイヤーの評価ルールを理解した上で導入しないと、意図しないブロックや「動かない」トラブルの原因になりかねません。
すでに社内でGitHub CopilotやMCPサーバーの利用が広がっている組織では、まず現状使われているMCPサーバーを棚卸しした上で、allowedMcpServers から段階的に導入していくのが現実的なアプローチです。
