GitHubは2026年8月3日に、GitHub Copilotのenterprise managed settingsを企業チーム単位で出し分けられる『enterprise team specialization for managed settings』を公開しました。全社の安全基準は維持したまま、先行導入チームだけモデル選択やプラグイン追加を広げやすくなったのが今回の変化です。
これまでの悩みは『全社固定か全社解禁か』に寄りがちだったことです。今回の更新で、managed-settings.json を企業の基準線にしつつ、team-mappings.json と copilot/teams/ 配下の差分ファイルで職種別の運用がしやすくなりました。
GitHub Copilotのenterprise team specializationで何が変わったのか
公式発表では、.github-private リポジトリを internal に置き、利用部門がPull Requestで設定変更案を出し、中央管理側がレビューする流れまで案内されています。つまり、設定の責任は中央に残しつつ、変更提案は現場から上げやすくする設計です。
ただし、チーム側が何でも上書きできるわけではありません。Docsでは、managed-settings.json 側で { "overridable": 値 } と宣言したキーだけがチーム設定ファイルで変更可能と明記されています。自由化ではなく、許可した範囲だけ差分運用できる機能だと理解した方が安全です。
まず押さえるべき対象と制約
managed settings自体はCopilot CLI、VS Code、GitHub Copilot app、Copilot cloud agentをまたいで使えます。ただし、team specializationの中心になる overridable keys は現時点で permissions.model と permissions.disableBypassPermissionsMode です。対応表ではこの2つはCLI・VS Code・Copilot appで使えますが、cloud agentでは未対応です。
一方で enabledPlugins と extraKnownMarketplaces は加算方式で cloud agent まで届きます。つまり、モデル選択は主にローカル系クライアント向け、プラグインやマーケットプレイスの広げ方は cloud agent を含む横断設計向け、という切り分けです。
チーム別に差分を作る手順
実務での流れは4段階です。① copilot/managed-settings.json に企業共通ルールを書く。② 変更を許すキーだけ overridable にする。③ copilot/team-mappings.json で settings file と enterprise team slug を結びつける。④ copilot/teams/ に devs.json や frontier.json のような差分ファイルを置く。この順にすると、全社統制を崩さずに先行チームだけ段階的に緩和できます。
GitHubの例でも、企業側は model と disableBypassPermissionsMode を overridable として宣言し、特定チームだけ unmanaged に切り替える構成が示されています。『まずAI推進チームだけ広める』『研修済み部門だけ追加許可する』といった運用に向いています。
プラグイン運用で見落としやすい点
enabledPlugins と extraKnownMarketplaces は減算ではなく加算です。企業のbaselineをteam fileで弱めるのではなく、必要なチームへ追加で広げる挙動なので、最低限の統制を保ちやすい設計です。
ただし、プラグインのホスト先がprivate repositoryなら注意が必要です。Docsでは、managed settingsで有効化しても、利用者にそのリポジトリへのアクセス権がなければ自動インストールで詰まると案内されています。権限設計とライセンス設計を別途そろえる必要があります。
Copilotの権限制御や段階展開を急ぎたい場合は、 HelloCraftAIへ相談する 形で先に設計を固めると、導入後の差し戻しを減らせます。
複数チーム所属時の扱い
利用者が複数のenterprise teamに所属している場合、GitHubは team file をキーごとに least restrictive value で結合し、その下に enterprise settings を適用すると説明しています。チーム差分同士では緩い方が採られますが、企業側が overridable にしていない重要設定は最後まで固定できます。
設定ソース全体の優先順位は MDM-managed、server-managed、file-based、user-level settings の順です。cloud agent まで含めてレビュー履歴を残したいなら server-managed、端末グループ単位の強制配布を優先するなら MDM-managed が判断軸になります。
管理者向けチェックリスト
導入前に確認したいのは5点です。1. 固定したいキーを先に決める。2. overridable は必要最小限に絞る。3. team-mappings.json を運用単位で切る。4. pluginのホスト先権限を確認する。5. server-managedは通常約1時間で反映される前提で告知手順を作る。この5点だけでも初期混乱をかなり減らせます。
よくある質問
Q. Copilot cloud agentでも model のチーム別上書きは効きますか。A. 2026年8月4日時点のGitHub Docsでは未対応です。cloud agentまで含めて差分運用したい場合は、まず plugins や marketplaces の加算設計を中心に考えるのが現実的です。
Q. まず server-managed と MDM-managed のどちらを選ぶべきですか。A. cloud agent を含めた一元統制と監査履歴を優先するなら server-managed、端末単位の強制配布を優先するなら MDM-managed が向いています。多くの企業は server-managed を基準にする形が分かりやすいです。
今すぐ判断したい企業向けの結論
GitHub Copilotのenterprise team specialization for managed settingsは、『全社統制を崩さず、先行チームだけ速く動かす』ための更新です。最初の一歩は、固定する基準を先に決め、緩めるチームを限定し、plugin権限まで一緒に設計することです。
GitHub Copilotのmanaged settings設計や社内展開を整理したい方は、 こちらからお問い合わせください 。要件整理から運用ルール作成まで支援します。
