managed-settings.jsonをCopilotアプリとクラウドエージェントへ反映する方法

managed-settings.jsonをGitHub CopilotアプリとCopilotクラウドエージェントへ反映するには、Enterpriseの構成ソースとして選択したOrganizationに.github-privateリポジトリを作成し、デフォルトブランチのcopilot/managed-settings.jsonへ設定を保存します。

すでにCopilot CLIやVisual Studio Code向けにサーバー管理型設定を運用している場合、原則として新しい設定ファイルは不要です。GitHub Copilotアプリは再起動または再サインイン時、Copilotクラウドエージェントは次のタスク割り当て時に既存設定を読み込みます。

ただし、すべての設定が両方に適用されるわけではありません。プラグインとマーケットプレイスの制御はクラウドエージェントにも適用されますが、承認プロンプトの回避を禁止する設定は、Copilotアプリ、Copilot CLI、VS Codeなどの対話型クライアントだけが対象です。(The GitHub Blog)

GitHub Copilotの企業管理設定がアプリとクラウドエージェントにも拡大

GitHub Copilot Enterpriseのmanaged-settings.jsonは、企業がCopilotクライアントの動作を一元管理するための設定ファイルです。

従来のCopilot CLIやVS Codeに加え、2026年7月27日からは次の環境も企業管理設定の対象になりました。

対象	主な適用内容	承認回避の禁止	設定を確認するタイミング
GitHub Copilotアプリ	プラグイン、マーケットプレイス、Allow allの禁止など	対応	アプリ再起動、再サインイン、または定期更新
Copilotクラウドエージェント	承認済みプラグイン、マーケットプレイス	非対応	次のタスク割り当て
Copilot CLI	プラグイン、マーケットプレイス、YOLO・allow-allの禁止など	対応	再起動、再サインイン、または定期更新
VS Code	プラグイン、マーケットプレイス、グローバル自動承認の禁止など	対応	再起動、再サインイン、または定期更新

重要なのは、クラウドエージェントまで管理したい場合は、.github-privateを利用するサーバー管理型設定が必要という点です。

MDM管理型とファイル配布型はローカルクライアント向けであり、Copilotクラウドエージェントには適用されません。サーバー管理型は、Copilot CLI、VS Code、GitHub Copilotアプリ、Copilotクラウドエージェントを一つの設定で管理できます。(GitHub Docs)

managed-settings.jsonを反映する前に確認すること

設定はEnterprise全体に適用される

サーバー管理型のmanaged-settings.jsonは、対象EnterpriseのCopilotプランを利用するユーザーへ適用されます。

Organization単位で設定を上書きする仕組みはありません。そのため、あるOrganizationだけ先にstrictKnownMarketplacesを有効化するといった段階展開はできません。

本番Enterpriseで設定を変更する場合は、次の影響を事前に確認してください。

現在利用されているプラグイン
開発者が参照しているマーケットプレイス
Copilot CLIの--yoloや--allow-allを利用した自動化
VS Codeのツール自動承認設定
GitHub CopilotアプリのTool Permissions
非公開リポジトリから配布しているプラグインのアクセス権

Enterprise managed settingsはEnterprise全体へ適用され、Organizationレベルの上書きはありません。(GitHub Docs)

設定ソースには優先順位がある

同じキーが複数の方法で配布されている場合、優先順位は次のとおりです。

MDM管理型設定
サーバー管理型設定
ファイル配布型設定
ユーザー設定

たとえば、.github-privateでサーバー管理型設定を変更しても、端末へMDMから同じキーが配布されていればMDM側が優先されます。

「リポジトリの内容は正しいのにCopilotアプリへ反映されない」という場合は、IntuneやJamfなどから別の設定が配布されていないか確認してください。(GitHub Docs)

管理操作にはEnterprise owner権限が必要

Enterpriseの構成ソースを設定する操作は、Enterprise ownerが行います。

専用のCopilot Business Enterpriseを使用している場合、サーバー管理型設定にはOrganizationと.github-privateリポジトリが必要です。これらを作成するために、少なくとも1ユーザー分のGitHub Enterpriseライセンスが必要になる場合があります。(GitHub Docs)

.github-privateへmanaged-settings.jsonを配置する手順

.github-privateリポジトリを作成する

Enterpriseに所属するOrganizationを一つ選び、次の名前でリポジトリを作成します。

.github-private

リポジトリ名は正確に.github-privateとしてください。.githubやgithub-privateでは認識されません。

リポジトリの可視性は、運用方法に応じて選択します。

可視性	適した運用
Internal	Enterpriseメンバーから設定変更の提案やPull Requestを受け付けたい場合
Private	設定ファイルを限られた管理者だけで管理したい場合

.github-privateの閲覧権限がないユーザーにも企業管理設定は適用されます。リポジトリをPrivateにしても、設定の適用対象がリポジトリ閲覧者だけに限定されるわけではありません。(GitHub Docs)

Enterpriseの構成ソースを選択する

リポジトリを作っただけでは設定は配布されません。Enterprise側で、どのOrganizationの.github-privateを参照するか指定します。

GitHubの管理画面で、次の順に開きます。

対象Enterpriseを開く
AI controlsを開く
Agentsタブを選択する
Configuration sourceを確認する
Select organizationを開く
.github-privateを作成したOrganizationを選択する

選択後は、同じ画面にあるConfiguration summaryを確認します。ここにリポジトリから読み込まれた設定が表示されれば、構成ソースの指定は成功しています。(GitHub Docs)

copilot/managed-settings.jsonを作成する

.github-privateリポジトリ内に、次のパスでファイルを作成します。

.github-private/
└── copilot/
    └── managed-settings.json

実際に作成するリポジトリ内のパスは次のとおりです。

copilot/managed-settings.json

.github-private/managed-settings.jsonや.github/copilot/managed-settings.jsonではありません。

設定はデフォルトブランチにコミットします。作業ブランチにファイルを作成しただけでは、Enterpriseの構成として反映されません。(GitHub Docs)

プラグインとマーケットプレイスを制御する設定例

次の例では、企業管理下のマーケットプレイスだけを許可し、指定したプラグインを有効化しています。あわせて、対話型クライアントで承認回避モードを使用できないようにしています。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "enabledPlugins": {
    "security-review@company-marketplace": true,
    "unapproved-helper@company-marketplace": false
  },
  "extraKnownMarketplaces": {
    "company-marketplace": {
      "source": {
        "source": "github",
        "repo": "YOUR-ORG/copilot-marketplace",
        "ref": "v1"
      }
    }
  },
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "YOUR-ORG/copilot-marketplace",
      "ref": "v1"
    }
  ]
}

YOUR-ORG/copilot-marketplaceは、実際にプラグインを配布するリポジトリへ置き換えてください。

enabledPluginsでプラグインを有効化・禁止する

enabledPluginsは、特定のプラグインを企業ポリシーとして有効または無効にします。

キーは次の形式です。

PLUGIN-NAME@MARKETPLACE-NAME

値の意味は次のとおりです。

値	動作
`true`	プラグインを有効化し、対応クライアントで自動的に利用可能にする
`false`	プラグインを無効化する

例として、次の設定はcompany-marketplaceにあるsecurity-reviewプラグインを有効にします。

{
  "enabledPlugins": {
    "security-review@company-marketplace": true
  }
}

プラグイン名とマーケットプレイス名が実際の定義と一致していない場合は、有効化されません。

extraKnownMarketplacesはマーケットプレイスを追加する設定

extraKnownMarketplacesは、ユーザーが利用できる追加のマーケットプレイスを定義します。

ただし、このキーだけでは他のマーケットプレイスを禁止できません。

企業用マーケットプレイスを追加しつつ、既存のマーケットプレイス利用を継続させたい場合に使用します。

GitHubリポジトリを配布元にする場合は、次のように指定します。

{
  "extraKnownMarketplaces": {
    "company-marketplace": {
      "source": {
        "source": "github",
        "repo": "YOUR-ORG/copilot-marketplace"
      }
    }
  }
}

refにはブランチ、タグ、コミットSHAを指定できます。厳格な変更管理が必要な環境では、変更され続けるブランチ名よりも、タグやコミットSHAへ固定する方法が適しています。

strictKnownMarketplacesで許可リスト方式にする

strictKnownMarketplacesを設定すると、明示的に指定したマーケットプレイス以外からのプラグイン導入を制限できます。

{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "YOUR-ORG/copilot-marketplace"
    }
  ]
}

extraKnownMarketplacesは「追加」、strictKnownMarketplacesは「制限」という違いがあります。

企業用マーケットプレイスだけを許可する場合は、両方の設定で同じリポジトリ、ref、pathを使用すると設定ミスを減らせます。

なお、次の設定は完全なロックダウンを意味します。

{
  "strictKnownMarketplaces": []
}

空配列を誤ってコミットすると、利用可能なマーケットプレイスがなくなります。既存業務への影響を確認せず、本番環境へ適用しないでください。

enabledPlugins、extraKnownMarketplaces、strictKnownMarketplacesの書式と動作は、GitHubが公開しているEnterprise managed settingsのスキーマで定義されています。(GitHub Docs)

非公開プラグインでは配布元リポジトリの権限も必要

ユーザーは、設定を取得するために.github-privateリポジトリを閲覧できる必要はありません。

一方、enabledPluginsで有効化したプラグイン本体が非公開リポジトリにある場合は、その配布元リポジトリへのアクセス権が必要です。

つまり、次の二つは別々に考える必要があります。

.github-privateへの閲覧権限
プラグイン配布元リポジトリへの閲覧権限

enabledPluginsにtrueを設定しても、プラグイン配布元の権限までは自動付与されません。

一部のユーザーだけプラグインがインストールされない場合は、JSONではなく、配布元リポジトリのOrganization所属、SSO認証、ライセンス、リポジトリアクセスを確認してください。(GitHub Docs)

承認回避設定が適用される範囲

承認プロンプトの回避を禁止する設定は、次のように記述します。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

値はBoolean型のtrueではなく、文字列の"disable"です。

この設定を適用すると、対話型クライアントでは次の動作になります。

GitHub Copilotアプリ

セッション設定にあるTool PermissionsのAllow allを利用できなくなります。

これにより、コマンド実行、ファイルアクセス、URL取得などを、すべて一括承認するモードをユーザーが有効化できなくなります。

Copilot CLI

次のような承認回避オプションが抑止されます。

--yolo
--allow-all
--allow-all-tools
--allow-all-paths
--allow-all-urls

/yoloや/allow-allなどのスラッシュコマンドもブロックされます。

VS Code

グローバルなツール自動承認設定であるchat.tools.global.autoApproveが無効化され、ユーザーが再度有効にできなくなります。

Copilotクラウドエージェント

permissions.disableBypassPermissionsModeは、Copilotクラウドエージェントには適用されません。

これは、クラウドエージェントが企業管理設定の対象外という意味ではありません。クラウドエージェントには、enabledPlugins、extraKnownMarketplaces、strictKnownMarketplacesなど、適用可能なプラグイン・マーケットプレイス設定が反映されます。

クラウドエージェントの統制を設計するときは、承認回避設定だけに依存せず、利用を許可するプラグインとマーケットプレイスを明示的に管理することが重要です。(The GitHub Blog)

managed-settings.jsonのJSONを検証する

managed-settings.jsonは通常のJSONファイルです。コメントや末尾の余分なカンマは記述できません。

コミット前に構文を検証しておくと、単純な入力ミスを防げます。

jqで検証する

jq empty copilot/managed-settings.json

構文が正しければ、通常は何も出力されません。

PowerShellで検証する

Get-Content .\copilot\managed-settings.json -Raw |
    ConvertFrom-Json |
    Out-Null

Write-Host "JSONの構文は正常です。"

エラーを分かりやすく表示する場合は、次のように実行します。

try {
    Get-Content .\copilot\managed-settings.json -Raw |
        ConvertFrom-Json |
        Out-Null

    Write-Host "JSONの構文は正常です。"
}
catch {
    Write-Error "managed-settings.jsonの構文に問題があります。"
    Write-Error $_
    exit 1
}

GitHub Actionsでこの検証を実行し、構文エラーがあるPull Requestをマージできないようにする方法も有効です。

設定が反映されるタイミング

デフォルトブランチへ設定をコミットすると、対応クライアントは定期的にサーバー上の設定を確認します。

対象	通常の反映	すぐに確認する方法
GitHub Copilotアプリ	おおむね1時間以内	アプリを再起動するか、サインアウト後に再サインインする
Copilot CLI	おおむね1時間以内	CLIを再起動するか、再認証する
VS Code	おおむね1時間以内	VS Codeを再起動するか、再サインインする
Copilotクラウドエージェント	次のタスク割り当て	新しいタスクを割り当てて確認する

すでに実行中のクラウドエージェントタスクではなく、設定変更後に新しく割り当てたタスクで確認するのが確実です。

Copilot CLIやVS Code向けにすでに.github-privateを運用している場合、Copilotアプリやクラウドエージェント向けに別ファイルを作る必要はありません。Copilotアプリは既存設定を再起動または再サインイン時に取得し、クラウドエージェントは次回のタスク割り当て時に適用可能な設定を参照します。(The GitHub Blog)

設定が反映されたか確認する方法

Enterprise管理画面を確認する

最初に、Enterpriseの次の画面を確認します。

Enterprise
└── AI controls
    └── Agents
        └── Configuration source

確認する項目は次のとおりです。

正しいOrganizationが選択されている
.github-privateリポジトリが存在する
Configuration summaryに設定内容が表示されている
対象ファイルがデフォルトブランチにある
ファイルパスがcopilot/managed-settings.jsonになっている

GitHub Copilotアプリで確認する

disableBypassPermissionsModeを設定した場合は、Copilotアプリを再起動してからセッション設定を開きます。

Tool PermissionsにあるAllow allを有効化できなければ、承認回避設定が反映されています。

プラグイン設定も行った場合は、次の点を確認します。

trueにしたプラグインが利用可能になっている
falseにしたプラグインが利用できない
許可していないマーケットプレイスからインストールできない

Copilotクラウドエージェントで確認する

設定変更後に新しいタスクを割り当て、次の動作を確認します。

承認済みプラグインを利用できる
禁止したプラグインを利用できない
許可リスト外のマーケットプレイスを参照しない

クラウドエージェントではAllow allの表示有無を確認しても、disableBypassPermissionsModeの検証にはなりません。クラウドエージェントで確認すべきなのは、プラグインとマーケットプレイスの制御です。

managed-settings.jsonが反映されないときの確認項目

症状	主な原因	対処
Configuration summaryが空	構成ソース未選択	`AI controls`の`Agents`でOrganizationを選択する
すべてのクライアントに反映されない	ファイルパスが違う	`copilot/managed-settings.json`へ修正する
変更内容が反映されない	デフォルトブランチへ未マージ	Pull Requestをマージしてデフォルトブランチへ反映する
Copilotアプリだけ変わらない	更新待ち、古いクライアント	アプリを更新し、再起動または再サインインする
クラウドエージェントだけ変わらない	MDM・ファイル配布を使用している	`.github-private`によるサーバー管理型へ切り替える
クラウドエージェントの既存タスクで変わらない	タスク割り当て前の設定を参照している	設定変更後に新しいタスクを割り当てる
プラグインがインストールされない	配布元リポジトリの権限不足	ユーザーのリポジトリアクセスとSSO認証を確認する
許可したマーケットプレイスもブロックされる	`repo`、`ref`、`path`が不一致	`extraKnownMarketplaces`と`strictKnownMarketplaces`を比較する
サーバー設定より別の値が適用される	MDM設定が優先されている	IntuneやJamfの配布内容を確認する
一部ユーザーだけ反映されない	Copilotの請求元が別Enterprise	個人設定の`Usage billed to`を確認する

複数の企業や請求元からCopilotライセンスを付与されているユーザーは、個人のCopilot設定で対象EnterpriseがUsage billed toに選択されているか確認する必要があります。(GitHub Docs)

本番環境で安全に展開する進め方

いきなりstrictKnownMarketplacesでマーケットプレイスを制限すると、開発者が利用していたプラグインを突然使えなくする可能性があります。

次の順序で展開すると、業務影響を抑えやすくなります。

現在の利用状況を調査する

開発チームごとに、利用中のプラグインと配布元を確認します。

名称だけではなく、次の情報まで記録します。

プラグイン名
マーケットプレイス名
配布元リポジトリ
ブランチ、タグ、コミットSHA
プラグインを必要とする業務
配布元リポジトリのアクセス対象者

許可するマーケットプレイスを追加する

最初はextraKnownMarketplacesで企業用マーケットプレイスを追加し、正常に参照できることを確認します。

この段階ではstrictKnownMarketplacesを設定せず、既存利用を直ちに遮断しない方法もあります。

標準プラグインを有効化する

全社で利用するプラグインをenabledPluginsでtrueにします。

一部ユーザーだけ導入に失敗する場合は、設定ファイルではなく配布元リポジトリの権限を確認します。

マーケットプレイスを許可リスト化する

必要なプラグインがすべて企業管理下のマーケットプレイスから利用できることを確認した後、strictKnownMarketplacesを追加します。

承認回避を禁止する

Copilotアプリ、Copilot CLI、VS Codeの利用状況を確認し、disableBypassPermissionsModeを適用します。

自動化処理で--allow-allなどを使用している場合は、設定変更前に個別承認方式へ修正してください。

.github-privateをポリシーコードとして管理する

managed-settings.jsonは単なるアプリ設定ではなく、Enterprise全体のCopilot利用ルールです。

通常のソースコードと同じように、次の管理を行うことが重要です。

デフォルトブランチへの直接Pushを禁止する
Pull Requestによる変更を必須にする
CODEOWNERSでセキュリティ担当者のレビューを必須にする
JSON構文チェックをGitHub Actionsで実行する
リポジトリRulesetで対象ファイルを保護する
変更理由と影響範囲をPull Requestへ記録する
緊急時に戻せるよう、変更単位を小さくする

.github-privateはGitリポジトリであるため、設定変更を履歴として残し、Pull RequestやRulesetによってレビュー可能なガバナンス運用を構築できます。(GitHub Docs)

サーバー管理型設定はOrganization単位で分けられないため、本番Enterpriseでのテストには注意が必要です。ローカルクライアントだけを先行検証するなら、MDMのデバイスグループ配布を利用できます。ただし、MDM設定はCopilotクラウドエージェントには届きません。

クラウドエージェントまで含めて完全に事前検証する場合は、テスト用Enterpriseや検証用のガバナンス環境を用意するのが安全です。

managed-settings.jsonを反映するときの要点

managed-settings.jsonをGitHub CopilotアプリとCopilotクラウドエージェントへ反映する基本手順は、次のとおりです。

Enterprise内のOrganizationに.github-privateを作成する
EnterpriseのAI controlsで構成ソースとなるOrganizationを選択する
copilot/managed-settings.jsonをデフォルトブランチへ配置する
プラグイン、マーケットプレイス、承認回避設定を記述する
Copilotアプリを再起動または再サインインして確認する
クラウドエージェントへ新しいタスクを割り当てて確認する

プラグインとマーケットプレイスの制御は、Copilotアプリとクラウドエージェントの両方へ適用できます。一方、disableBypassPermissionsModeによる承認回避の禁止は、Copilotアプリ、Copilot CLI、VS Codeだけが対象です。

最初にConfiguration summaryで構成ソースを確認し、許可するマーケットプレイスの追加、標準プラグインの有効化、許可リスト方式への移行という順序で進めると、既存業務への影響を抑えながらCopilotの企業ガバナンスを強化できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。