GitHubは2026年8月6日、GitHub Copilotのenterprise managed settingsでMCP allowlistを一般提供しました。今回のポイントは、企業がModel Context Protocolの利用を「許可したサーバーだけ通す」管理ができるようになったことです。結論から言うと、Copilot BusinessやEnterpriseを広げる企業は、MCPを全面解放するより先に、remote URL・local command・例外ルールを managed-settings.json で明文化した方が安全です。
特に影響が大きいのは、Copilot app、Copilot CLI、VS CodeでMCPを使い始めているチームです。公式仕様では built-in の GitHub MCP server は常に許可される一方、外部サーバーは denied が優先され、allowlist を置いた瞬間に非一致サーバーは止まります。曖昧なまま広げると、停止か統制漏れが起きやすくなります。
GitHub CopilotのMCP allowlistsで何が変わったのか
Changelogでは、新しい allowedMcpServers と deniedMcpServers キーを enterprise managed settings に追加し、MCP server を remote URL、local command、server name の3種類で照合できるようになったと案内されています。しかも malformed な設定や検証不能な設定は fail closed で止まるため、「設定ミスでも通ってしまう」設計ではありません。サーバー管理型デプロイでは overridable にして、enterprise team ごとに上乗せルールを持たせることもできます。
導入前に確認したい前提条件
公式ドキュメントでは前提条件が2つあります。1つ目は、enterprise もしくは organization の Copilot policy で MCP servers を有効化していること。2つ目は、すでに custom registry 制限を使っている場合、allowlist と競合しないよう「registry経由だけ許可」の設定を見直すことです。GitHubは single source of truth を保つため、registry 制限を緩めて allowlist 側へ寄せる運用を勧めています。ここを確認せずに投入すると、「設定したのにMCPが動かない」か「二重統制で原因不明」になりがちです。
managed-settings.jsonはどう書くべきか
GitHub Docs では managed-settings.json を .github-private リポジトリの既定ブランチに置く方法を基本形として案内しています。allowlist には serverUrl か serverCommand を優先して書き、serverName はあくまで補助的に扱うのが安全です。理由は、ユーザーが server name を変更できるため、名前一致だけでは security control にならないからです。たとえば Playwright MCP を許可したいなら command 配列で固定し、社内HTTP/SSEサーバーは URL wildcard で絞り、学習用や検証用の外部URLは deny に先回りで入れる構成が実務向きです。
評価順を知らないとどこで詰まるか
評価順はかなり重要です。GitHub Docsでは、① built-in の既定サーバーを常時許可、② deniedMcpServers に一致したら遮断、③ allowedMcpServers が存在する場合は非一致を遮断、④ URL や command に未解決変数が残っていれば遮断、の順で判定すると説明しています。つまり deny は allow より強く、allowlist を空配列にすると実質 deny-all になります。さらに ${VARIABLE} や $VARIABLE を残したまま配布すると client が検証できず、意図せず止まるので注意が必要です。
企業で最初に作るべき運用ルール
最初の運用ルールは4点で十分です。1. 業務で使うMCP serverを「社内運用」「主要SaaS連携」「個人検証」に分類する。2. 社内標準として許可する URL と command だけを allowedMcpServers に入れる。3. 法務・セキュリティ上まずい接続先や学習データ持ち出し懸念のある接続先を deniedMcpServers に明示する。4. team override を許す場合は、どの部門まで overridable を使えるか決める。この4つがあるだけで、現場の試行錯誤を止めすぎず、後から監査しやすい設計になります。
最短の導入手順
最短手順は、対象チームの洗い出し、MCP policy の有効化確認、managed-settings.json の作成、テスト端末で Copilot app・CLI・VS Code の3クライアント検証、段階展開の5ステップです。特に app と CLI だけ通って VS Code で止まる、といった混乱を避けるため、サポート対象クライアントを横断で確認した方が安全です。HelloCraftAIでは、MCPの許可設計、AIエージェント導入の社内ルール化、運用フロー整備までまとめて支援しています。
よくある質問
Q. Copilot Freeでも使えますか。A. allowlist 機能の管理対象は GitHub Docs 上で Enterprise owners と Copilot Business / Enterprise とされています。個人利用のCLI設定とは別物です。Q. serverName だけで統制してよいですか。A. 推奨しません。GitHub自身が name は convenience であり security control ではないと説明しています。Q. まず何を deny すべきですか。A. 未審査の remote URL、再現不能な個人 command、社内標準外の学習用サーバーから始めるのが現実的です。
今すぐ判断したい企業向けの結論
GitHub CopilotのMCP allowlistsは、「MCPを使うか」ではなく「どのMCPだけを使わせるか」を enterprise managed settings に落とし込めるようにした更新です。2026年8月6日時点では、MCPを有効化するだけでなく、allowedMcpServers と deniedMcpServers をセットで設計し、custom registry 制限との二重管理を避け、3クライアントで検証してから広げるのが安全です。MCP利用ポリシーの設計や社内展開を急ぎたい方は HelloCraftAIへご相談ください 。要件整理からPoC運用、権限設計まで伴走できます。
