2026年7月9日時点のGitHub公式更新では、Changelog上の2026年7月8日付で「Deploy managed Copilot settings via MDM in VS Code and CLI」が発表されました。企業管理者は、GitHubアカウント経由のサーバー管理だけでなく、Microsoft IntuneやJamfなどのMDM、OSのポリシー、端末上の設定ファイルを使って、GitHub Copilotの管理設定を配布できるようになりました。対象はVisual Studio CodeとGitHub Copilot CLIで、端末単位の配布機能は一般提供と案内されています。(The GitHub Blog)
結論からいえば、既存のserver-managed設定を直ちに移行する必要はありません。一方で、個人アカウントへの切り替え後も制限を維持したい、端末グループごとに設定を変えたい、オフライン時にもCopilotのガードレールを適用したい組織は、MDMまたはファイルベース配布を検討すべきです。
特に注意したいのは、複数の配布経路がキー単位でマージされない点です。原則として「Native MDM、server-managed、file-based」の順で1つのチャネルが選ばれ、選択されたチャネルに含まれていない設定を下位チャネルから補完することはありません。部分的なMDM設定を配布すると、既存の重要な制限が意図せず無効になる可能性があります。(The GitHub Blog)
Visual Studio CodeのCopilot管理設定で何が変わったのか
従来、企業向けのCopilot管理設定は、主にGitHubの.github-privateリポジトリから取得するserver-managed方式で配布されていました。今回の更新では、同じ管理設定を端末側から配布する2つの経路が追加されています。
| 観点 | 従来の中心だった方式 | 更新後 |
|---|---|---|
| 配布経路 | GitHubアカウント経由のserver-managed | Native MDM、server-managed、file-basedの3方式 |
| 管理単位 | ユーザーやGitHubアカウント | 端末、端末グループ、ユーザーアカウント |
| 主な管理ツール | .github-privateリポジトリ | Intune、Jamf、Group Policy、Chef、Puppet、Ansibleなど |
| 対象クライアント | 対応するCopilotクライアント | VS CodeとCopilot CLIで同じ定義を利用 |
| アカウント切り替え時 | アカウント側の設定に依存 | 端末側の設定はアカウントにかかわらず維持可能 |
| オフライン時 | 最新情報の取得には通信が必要 | 端末に読み込まれた制限はローカルで適用可能 |
MDMとファイルベースの設定は端末から読み込まれるため、サインイン前やネットワーク接続前にもガードレールを適用できます。GitHubアカウントを切り替えても、端末側ポリシーは維持されます。(The GitHub Blog)
既存のVS Codeポリシーとは別の仕組み
今回追加されたCopilot managed settingsは、従来のVS Code enterprise policiesを単純に拡張したものではありません。
Windowsで一般的なVS Codeポリシーは、次の場所に保存されます。
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\VSCode一方、Copilot managed settingsは次の専用キーを使用します。
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\GitHubCopilotmacOSでも、VS Codeの一般的な構成プロファイルとは別に、Copilot専用の次のPreference Domainを使用します。
com.github.copilotすでにVS CodeのADMXテンプレートや構成プロファイルを配布している組織でも、Copilot管理設定が自動的に有効になるわけではありません。Copilot専用の配布設定を追加する必要があります。Copilot managed settingsはVS Code側のポリシーへマッピングされますが、設定形式と配布チャネルはCopilot専用であり、同じ定義をCopilot CLIにも適用できる点が大きな違いです。(Visual Studio Code)
対応が必要かを判断する基準
すべての組織がMDM配布へ切り替える必要はありません。次の基準で判断すると、過剰な移行を避けられます。
| 現在の状況・要件 | 推奨する対応 | 理由 |
|---|---|---|
| server-managedで問題なく運用できている | 現状維持でもよい | 既存方式は引き続き利用できる |
| 設定変更をGitでレビュー・監査したい | server-managedを継続 | 変更履歴や承認フローを管理しやすい |
| 部署や端末グループごとに設定を変えたい | Native MDMを検討 | IntuneやJamfの割り当て機能を利用できる |
| 個人アカウントへの切り替え後も制限したい | Native MDMまたはfile-based | 端末単位で設定が維持される |
| Linux端末を管理したい | file-based | LinuxではNative MDMチャネルを利用できない |
| Dev ContainerやCodespacesにも配布したい | file-basedを検討 | ファイル配布が利用しやすい |
| VS Codeの通常ポリシーだけを配布している | Copilot専用設定を追加 | 保存先と設定形式が異なる |
| VS Code 1.127以前が残っている | 先に更新計画を立てる | 3チャネル間の優先順位は1.128以降で明示的に適用される |
GitHubは、一般的な企業ではserver-managedを標準的な選択肢とし、端末グループへの割り当てが必要な場合はMDM、MDMを利用できない環境やコンテナではfile-basedを選ぶ方針を示しています。(GitHub Docs)
3つの配布チャネルと適用タイミング
Native MDM
WindowsとmacOSでは、OSレベルの管理領域からCopilot設定を読み取れます。
| OS | 保存先 |
|---|---|
| Windows | HKEY_LOCAL_MACHINE\SOFTWARE\Policies\GitHubCopilot |
| macOS | Managed Preferencesのcom.github.copilotドメイン |
Microsoft Intune、Jamf、Group Policyなど、既存の端末管理基盤を利用できます。クライアントは更新されたポリシーを定期的に確認し、GitHubの導入手順では再起動は不要、確認間隔はおおむね1時間とされています。VS Codeでは、コマンドパレットからDeveloper: Sync Account Policyを実行すると、テスト時に同期を促せます。(The GitHub Blog)
Server-managed
server-managedでは、GitHubにサインインしているユーザーのアカウントを基に設定が解決されます。
現在の導入手順では、.github-privateリポジトリ内の次のファイルを使用します。
copilot/managed-settings.json従来の次のパスも後方互換性のためサポートされています。
.github/copilot/settings.json設定は通常1時間程度で反映され、クライアントの再起動や再サインインによって早く取得できる場合があります。変更履歴をPull Requestでレビューしたい組織や、端末管理基盤を持たない組織に向いています。(GitHub Docs)
File-based
file-basedでは、OSごとに決められた場所へmanaged-settings.jsonを配置します。
| OS | ファイルパス |
|---|---|
| Windows | %ProgramFiles%\GitHubCopilot\managed-settings.json |
| macOS | /Library/Application Support/GitHubCopilot/managed-settings.json |
| Linux | /etc/github-copilot/managed-settings.json |
Chef、Puppet、Ansibleなどで配布できるため、Linux端末やコンテナ環境にも適用しやすい方式です。MDMとは異なり、ファイルベースの更新はクライアント起動時に読み込まれるため、変更後はVS CodeとCopilot CLIを再起動して確認します。(Visual Studio Code)
macOSやLinuxなどのPOSIX環境では、Copilot CLIは次の条件に該当する設定ファイルを拒否します。
- シンボリックリンクになっている
rootが所有していない- 全ユーザーが書き込み可能になっている
管理者以外が内容を書き換えられる状態では、セキュリティポリシーとして信頼できないためです。(GitHub Docs)
最重要仕様は「チャネル単位で勝者が決まる」こと
最新のGitHub ChangelogとVS Code公式ドキュメントでは、配布チャネルの優先順位は次の順です。
- Native MDM
- Server-managed
- File-based
重要なのは、同じキーだけが上書きされるのではなく、最高優先度のチャネルが設定全体の取得元になることです。Native MDMに1つでもCopilot managed settingが存在すると、server-managedとfile-basedの設定全体が無視されます。(The GitHub Blog)
たとえば、server-managedでプラグインを制限しているとします。
{
"enabledPlugins": {
"PLUGIN-NAME@MARKETPLACE-NAME": true
},
"strictKnownMarketplaces": [
{
"source": "github",
"repo": "OWNER/REPO"
}
]
}その後、MDMで次の権限制限だけを配布したとします。
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}この場合、MDM側が選択され、server-managed側のenabledPluginsとstrictKnownMarketplacesは補完されません。結果として、意図していたプラグイン制限が適用されなくなる可能性があります。
注意: MDM移行時は、変更したいキーだけではなく、最終的に適用したい管理設定一式をMDMペイロードへ含めてください。
安全に移行するには、現在のserver-managed設定、ファイル設定、VS Codeポリシーを棚卸しし、最高優先度のチャネルに完全な構成をまとめる必要があります。
配布できるCopilot管理設定
2026年7月の公式情報では、主に次の管理設定が案内されています。
| 管理キー | 制御内容 | 実務上の確認ポイント |
|---|---|---|
permissions.disableBypassPermissionsMode | 承認を省略するBypass／YOLOモードを無効化 | VS CodeとCLIの両方で無効になるか |
model | 新しい会話やセッションの既定モデル | 既存・再開セッションには反映されない場合がある |
enabledPlugins | 利用するプラグインIDと有効・無効状態 | キー形式とJSON文字列化を確認 |
extraKnownMarketplaces | 追加のプラグインマーケットプレイス | リポジトリ名や参照先を確認 |
strictKnownMarketplaces | 管理対象外マーケットプレイスを信頼しない | ユーザー追加のマーケットプレイスが制限されるか |
telemetry.* | OpenTelemetryの送信先、方式、取得内容など | コンテンツ取得と認証情報の扱いを確認 |
対応キーは今後追加される予定です。クライアントが認識しないキーを先行配布するのではなく、対象バージョンの公式スキーマと実機の診断結果を確認してから追加してください。(The GitHub Blog)
Bypassモードの無効化
次の設定は、エージェントが承認なしでコマンド実行、ファイル操作、URL取得などを行うモードを無効にします。
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}Copilot CLIでは、--yolo、--allow-all、--allow-all-tools、--allow-all-paths、--allow-all-urlsなどが利用できなくなります。VS Codeではchat.tools.global.autoApproveが無効化され、Bypass ApprovalsやAutopilotに相当する選択肢が非表示になります。(GitHub Docs)
セキュリティ基準がまだ固まっていない組織では、最初に導入するガードレールとして検討しやすい設定です。ただし、個別ツールの承認ルールやサンドボックス設定まで同時に制御するものではありません。
既定モデルの設定
新しい会話をAutoモデルで開始する最小構成は、公式の導入手順では次のように示されています。
{
"model": "auto"
}この設定はモデルを完全に固定するポリシーではありません。VS Codeではユーザーが会話中に別のモデルへ切り替えられ、Copilot CLIでも明示的なモデル指定や再開したセッションのモデルが優先されます。既定モデルを設定しただけで、利用可能モデルの許可リストが構成されたと誤解しないようにしてください。(GitHub Docs)
OpenTelemetry設定
telemetryブロックを使うと、VS CodeのCopilot Chat拡張機能とCopilot CLIを動かすagent hostに対して、次の項目を企業側から指定できます。
- OTLPエンドポイント
otlp-httpまたはotlp-grpc- サービス名とResource Attributes
- Collectorへ送る認証ヘッダー
- プロンプト、応答、ツール内容を取得するか
- ユーザーによる取得内容の変更を許可するか
管理対象の値は、ユーザー設定やOTEL_*環境変数より優先されます。また、管理対象の認証ヘッダーはツールの子プロセスへ環境変数として渡されない設計です。(The GitHub Blog)
プロンプトや応答内容を取得する場合は、ソースコード、個人情報、シークレットがテレメトリに含まれる可能性を考慮し、Collector側のアクセス制御、保存期間、マスキング方針も同時に決める必要があります。
MDMではスカラー値と構造化データの形式が異なる
Native MDMでは、単純な値とJSONオブジェクトで指定方法が異なります。
スカラー設定は、ドット区切りのキー名をそのまま使います。
| キー名 | 値の例 |
|---|---|
permissions.disableBypassPermissionsMode | disable |
一方、enabledPluginsなどの構造化設定は、JSONを文字列として登録します。
{"PLUGIN-NAME@MARKETPLACE-NAME":true}Windows RegistryやmacOS Managed Preferencesへ入れ子のオブジェクトをそのまま登録すると、クライアントが読み取れない可能性があります。MDM製品の管理画面でJSONの引用符がエスケープされていないか、配布後の実値まで確認してください。(The GitHub Blog)
導入前に確認すべき条件
VS Codeは1.128以降を基準にする
VS Code 1.128は2026年7月8日にリリースされました。公式ドキュメントでは、3つのチャネル間の優先順位はVS Code 1.128から適用されると明記されています。MDM配布の検証対象は、原則として1.128以降へそろえるのが安全です。(Visual Studio Code)
一方、modelのserver-managed設定自体はVS Code 1.126以降で利用可能と案内されています。つまり、1.126や1.127でも一部のキーを認識する可能性はありますが、最新のチャネル優先順位と同じ結果になるとは限りません。混在バージョンのまま一斉配布せず、バージョンごとに対象グループを分けてください。(The GitHub Blog)
Copilot CLIは最新のサポート版で検証する
今回の発表では、Copilot CLIについて具体的な最小バージョン番号は示されていません。古いCLIでの動作を推測せず、テスト前に更新し、検証したバージョン番号を記録しておく必要があります。
また、設定がVS Codeで適用されたからといって、Copilot CLIの確認を省略してはいけません。特にBypassモード、プラグイン、既定モデル、OpenTelemetryは両方のクライアントで挙動を確認します。
必要な権限を分担する
導入には、主に次の管理権限が関係します。
| 担当 | 必要な作業 |
|---|---|
| GitHub Enterprise管理者 | 管理対象キー、Copilotポリシー、既存server-managed設定の確認 |
| Intune・Jamf管理者 | MDMペイロードの作成、グループ割り当て、ロールバック |
| Windows管理者 | RegistryやGroup Policyの確認 |
| macOS管理者 | Managed Preferencesと構成プロファイルの確認 |
| Linux・基盤管理者 | ファイル配布、所有者、パーミッションの管理 |
| セキュリティ担当 | Bypassモード、プラグイン、テレメトリ取得範囲の承認 |
GitHubの管理設定はEnterprise owner向けの機能として案内されており、利用者側には対応するCopilot利用資格とサポート対象クライアントが必要です。(GitHub Docs)
安全に導入する手順
- 現在の設定元を棚卸しする
.github-private、VS Code enterprise policies、Copilot CLIのユーザー設定、端末上の設定ファイルを確認します。特にpermissions、プラグイン、モデル、テレメトリを一覧化します。 - 最終的な管理元を1つ決める
MDMを最優先にするのか、server-managedを継続するのかを決めます。複数チャネルへ異なる設定を分散させないことが重要です。 - 正規となるJSONを1つ作る
社内リポジトリに完全なmanaged-settings.jsonを保存し、そのJSONからWindows、macOS、file-based向けの配布物を生成すると、OS間の設定漏れを減らせます。 - 対象OS向けの形式へ変換する
WindowsとmacOSのMDMでは、スカラー値をドット区切りキー、構造化値をJSON文字列として配布します。Linuxでは/etc/github-copilot/managed-settings.jsonへ配置します。 - 少数の端末グループへ配布する
GitHubも全社展開前のパイロットを推奨しています。Windows、macOS、Linux、VS Code、Copilot CLIを代表する端末を含めます。(GitHub Docs) - VS Codeの診断と実際の操作で確認する
Developer: Policy Diagnosticsで有効なチャネルと値を確認したうえで、CLIの起動オプションやVS Codeの設定画面でも制限を確認します。 - ロールバック手順を試してから全社展開する
MDMポリシーを削除した場合にserver-managedへ戻るか、ファイル削除後に再起動が必要かを検証します。配布だけでなく解除まで確認しておくことが重要です。
テストで確認すべき項目
| テスト項目 | 正常な状態 | 失敗しやすいポイント |
|---|---|---|
| 有効なチャネル | 想定したMDM、server、fileのいずれかが表示される | 下位チャネルとのマージを期待している |
| MDM更新 | 同期後または定期確認後に反映される | すぐに反映されないため設定ミスと判断する |
| File-based更新 | クライアント再起動後に反映される | ファイルだけ更新して再起動しない |
| アカウント切り替え | 端末側制限が維持される | server-managedの挙動だけを確認する |
| Bypassモード | VS CodeとCLIの両方で利用できない | VS Codeだけを確認する |
| 既定モデル | 新しい会話で指定モデルになる | 既存・再開セッションで確認する |
| 構造化設定 | プラグインやマーケットプレイスが正しく反映される | JSON文字列のエスケープに失敗する |
| POSIXファイル | root所有で安全なパーミッションになっている | シンボリックリンクやworld-writableにする |
| ロールバック | 上位チャネル削除後に想定の設定へ戻る | キャッシュ、同期、再起動を考慮しない |
VS CodeのDeveloper: Policy Diagnosticsでは、適用中と未適用のポリシー、設定値、ポリシーの取得元、VS Codeのバージョンなどを確認できます。スペルミスや読み込まれていない設定も発見しやすくなります。(Visual Studio Code)
ただし、診断レポートにはアカウント識別情報、認証セッション、拡張機能へのアクセス情報などが含まれる可能性があります。チケットやチャットへそのまま貼り付けず、内容を確認してから共有してください。(Visual Studio Code)
よくある導入失敗
既存のVS Code Registry配下へ設定してしまう
Copilot managed settingsをSoftware\Policies\Microsoft\VSCodeへ登録しても、Copilot専用チャネルとしては読み取られません。WindowsではSoftware\Policies\GitHubCopilotを使用します。
MDMへ変更分だけを登録する
今回の仕様で最も危険な失敗です。MDMへ1つの設定だけを追加すると、server-managedに残した別の設定が無視されます。移行前に、最高優先度チャネルへ完全な設定を統合してください。
modelをモデル固定機能だと考える
modelは新規会話の既定値を決める設定です。ユーザーによる会話単位の変更まで禁止するものではありません。モデルの利用可否を制御したい場合は、GitHub側のモデルポリシーと組み合わせて設計する必要があります。
VS Codeだけでテストを終える
今回の目的は、同じ設定をVS CodeとCopilot CLIへ適用することです。特にCLIの--yoloなどが拒否されるか、プラグイン設定が一致するか、モデルの初期値が期待どおりかを確認してください。
ファイルの存在だけで成功と判断する
ファイルパス、JSON構文、所有者、パーミッション、シンボリックリンク、クライアント再起動のいずれかに問題があると、設定は適用されません。VS Codeの診断結果と実際の機能制限を組み合わせて判断します。
更新直後の公式ドキュメント差にも注意する
2026年7月11日時点では、公式ページ間に過渡的な記述差が見られます。
最新のGitHub ChangelogはVS CodeとCopilot CLIでのMDM・ファイル配布を一般提供と案内していますが、GitHubのEnterprise managed settings referenceにはPublic Previewの注記が残っています。さらに同ページの優先順位一覧ではserver-managedが先に記載されている一方、直後の文章ではMDMが優先すると書かれています。最新のChangelogとVS Codeドキュメントは、いずれも「Native MDM、server-managed、file-based」の順で一致しています。(The GitHub Blog)
modelの形式にも記述差があります。現在の導入手順と2026年7月1日のChangelogでは"model": "auto"が使われていますが、別のスキーマ参照ではmodel.defaultを持つオブジェクト形式が掲載されています。設定例を無条件にコピーせず、対象クライアントでのパイロット、Developer: Policy Diagnostics、公式テンプレートの更新確認を行ってください。(GitHub Docs)
まず実施すべき対応
既存のserver-managed運用に問題がなければ、慌ててMDMへ移行する必要はありません。端末単位の強制、アカウント切り替え対策、オフライン時の適用、端末グループ別の割り当てが必要な場合に、MDMまたはfile-basedを追加します。
導入する場合は、最初にVS Codeを1.128以降へそろえ、現在の管理設定をすべて棚卸ししてください。そのうえで、最高優先度チャネルに完全な設定をまとめ、少数端末へ配布します。最後にVS CodeのDeveloper: Policy DiagnosticsとCopilot CLIの実動作を確認してから、全社展開へ進むのが安全です。
コメント