MENU

GitHub Enterprise managed-settings.json一般提供の変更点と管理者が確認すべき注意点

Microsoft

GitHub の「Enterprise managed-settings.json is generally available」は、GitHub Copilot を企業利用している管理者がまず確認すべき更新です。結論から言うと、GitHub Enterprise Cloud で Copilot を利用する企業は、managed-settings.json を使って VS Code や Copilot CLI の一部設定をエンタープライズ単位で集中管理できるようになりました。特に、Copilot のプラグイン利用、許可済みマーケットプレイス、バイパスモードの無効化、Auto model の既定化を統制したい組織では、早めに設定方針を決めておく価値があります。(The GitHub Blog)

目次

GitHub の「Enterprise managed-settings.json is generally available」とは

「Enterprise managed-settings.json is generally available」は、GitHub が 2026年7月1日に公開した GitHub Enterprise Cloud 向けの更新です。GitHub Enterprise Cloud の顧客は、選択した Organization の .github-private リポジトリ内に managed-settings.json を置くことで、Copilot クライアントの設定を企業側から配布・管理できます。(The GitHub Blog)

これまで開発者個人の VS Code や Copilot CLI 側で設定していた内容の一部を、エンタープライズ管理者が共通ルールとして上書きできる点が重要です。つまり、単なる設定ファイルの追加ではなく、GitHub Copilot の利用ルールを「個人任せ」から「組織統制」に寄せるための仕組みと考えると分かりやすいでしょう。

対象になるのは、現時点では主に次のような利用シーンです。

対象影響
GitHub Enterprise Cloud 管理者Copilot のクライアント設定を企業標準として集中管理できる
GitHub Copilot Business / Enterprise 利用者VS Code や Copilot CLI の一部ローカル設定が企業設定に従う
開発チームのリードプラグイン、モデル選択、コマンド承認のルールをチーム横断でそろえやすくなる
セキュリティ・ガバナンス担当AI エージェントの権限や拡張機能利用を制御しやすくなる

何が変わったのか

今回の更新で確認すべき中心は、managed-settings.json が一般提供されたことです。GitHub の公式情報では、設定は Copilot Business または Copilot Enterprise ライセンスを持つユーザーに対して、VS Code と Copilot CLI で適用されると説明されています。今後、Copilot SDK を通じて他の Copilot クライアントにも対応を広げる方針が示されています。(The GitHub Blog)

実務上の変更点を整理すると、次のようになります。

変更点実務での意味
managed-settings.json が GAプレビュー前提ではなく、本番運用の設計対象にしやすくなった
.github-private リポジトリで管理企業標準設定を GitHub 上のファイルとして管理できる
VS Code / Copilot CLI に適用開発者が日常的に使う主要クライアントで統制しやすい
ユーザー側のファイル設定より優先個人設定によるルール逸脱を抑えやすい
設定は認証時と定期更新で反映反映タイミングを考慮した展開計画が必要

特に注意したいのは、managed-settings.json がサポート対象のキーについて、ユーザーがクライアント側で設定したファイルベースの設定より優先されることです。開発者から見ると「自分の VS Code では以前と同じ設定にしているのに、Copilot の挙動が変わった」と感じる可能性があります。(The GitHub Blog)

managed-settings.json で管理できる主な設定

GitHub の公式ドキュメントでは、managed-settings.json で扱える主なプロパティとして、プラグインマーケットプレイス、既定で有効化するプラグイン、権限設定などが示されています。代表的な設定は次のとおりです。(GitHub Docs)

設定役割使いどころ
extraKnownMarketplaces追加のプラグインマーケットプレイスを定義する社内で承認したプラグイン配布元を追加したい場合
strictKnownMarketplaces利用できるマーケットプレイスを明示的に制限する未承認の拡張や外部配布元を避けたい場合
enabledPlugins特定のプラグインを全ユーザー向けに有効化する標準ツールや社内推奨プラグインを自動展開したい場合
permissions.model新しい会話で Auto model を既定にするモデル選択を開発者任せにしすぎず、既定値をそろえたい場合
permissions.disableBypassPermissionsModeバイパスモードを無効化するエージェントによるコマンド実行やファイル操作の承認を必須にしたい場合

なお、GitHub の Changelog では model や disableBypassPermissionsMode がサポートキーとして挙げられていますが、ドキュメント上の JSON 例では permissions 配下に記述されています。実装時は公式ドキュメントのスキーマに合わせて確認するのが安全です。(The GitHub Blog)

管理者が確認すべきポイント

.github-private リポジトリの運用権限を整理する

managed-settings.json は、選択した Organization の .github-private リポジトリで管理します。設定ファイルの変更が企業全体の Copilot クライアント設定に影響するため、通常のアプリケーションコードよりも慎重な権限設計が必要です。(The GitHub Blog)

少なくとも、次の点は事前に決めておくと運用が安定します。

確認項目推奨される考え方
誰が編集できるかEnterprise owner や AI 管理担当など、少人数に限定する
変更レビューPull Request ベースでレビュー必須にする
変更履歴なぜその設定にしたかを PR や Issue に残す
反映確認VS Code と Copilot CLI の両方で検証する
ロールバック直前の設定に戻せるよう、変更単位を小さくする

特に、disableBypassPermissionsMode のような権限系の設定は、開発者の作業手順に直接影響します。セキュリティ部門だけで決めるのではなく、実際に Copilot CLI や VS Code を使う開発チームの代表者をレビューに入れると、導入後の混乱を減らせます。

既存の AI Controls 設定との関係を把握する

managed-settings.json は、Enterprise settings の AI Controls タブにあるポリシーを置き換えるものではなく、追加で使う設定です。GitHub の Changelog でも、AI Controls タブで利用できるポリシーに加えて managed-settings.json を使う形だと説明されています。(The GitHub Blog)

そのため、管理者は次のように役割を分けて考えると整理しやすくなります。

管理対象主に使う場所
Copilot の利用可否、組織単位の基本ポリシーEnterprise settings の AI Controls
VS Code / Copilot CLI に配布するクライアント設定managed-settings.json
カスタムエージェントやプラグイン標準.github-private リポジトリと関連設定

実務では、「AI Controls で大枠の利用ポリシーを決め、managed-settings.json でクライアント側の細かい標準設定を配布する」と捉えると運用しやすくなります。

設定反映のタイミングを周知する

managed-settings.json の設定は、ユーザーが対応クライアントで次回認証したときに取得され、クライアントは最新設定を 1時間ごとに取得すると説明されています。(The GitHub Blog)

つまり、設定ファイルをコミットした直後に全員の環境へ即時反映されるとは限りません。検証や社内告知では、次のように伝えると誤解を防げます。

状況伝え方
設定をコミットした直後反映には認証タイミングや定期更新が関係する
一部ユーザーだけ反映されないCopilot ライセンスの発行元や請求先設定を確認する
検証担当者が確認する場合VS Code と Copilot CLI を再認証してから確認する
緊急で戻したい場合設定を戻しても、反映タイミングに差が出る可能性を考慮する

GitHub のドキュメントでは、設定が見えない場合に、ユーザーが Enterprise またはその Organization から Copilot アクセスを受けているか、複数の請求元がある場合は個人の Copilot 設定で対象 Enterprise が選ばれているかを確認するよう説明されています。(GitHub Docs)

開発者・一般ユーザーが確認すべきポイント

自分のローカル設定が優先されない場合がある

開発者にとって最も分かりやすい影響は、VS Code や Copilot CLI 側で個別に設定していた内容が、企業の managed-settings.json によって上書きされる可能性があることです。これは不具合ではなく、GitHub が明示している設計です。(The GitHub Blog)

例えば、次のような変化が起こり得ます。

以前の状態更新後に起こり得ること
個人設定で特定のプラグインを使っていた企業が許可したマーケットプレイス以外は使えなくなる
Copilot CLI で承認を省略する運用をしていたバイパスモードが無効化され、承認が必要になる
会話ごとにモデルを選んでいた新しい会話の既定が Auto model になる
チームごとに設定がばらばらだった企業標準の設定に統一される

特に Copilot CLI を使って自動化に近い作業をしている場合、バイパスモードの制御は作業手順に影響します。コマンド実行やファイル操作の前に承認が求められる前提で、手順書や開発フローを見直しておきましょう。

バイパスモード無効化はセキュリティ上の意味が大きい

GitHub のドキュメントでは、バイパスモードはエージェントが承認なしでコマンド実行、ファイルアクセス、URL 取得を行えるモードとして説明されています。disableBypassPermissionsMode を "disable" にすると、Copilot CLI の --yolo や --allow-all 系オプション、VS Code のグローバル自動承認設定などが制限されます。(GitHub Docs)

これは開発速度を落とすための設定ではなく、AI エージェントに広い権限を渡しすぎないための安全策です。特に、顧客情報、認証情報、社内ネットワーク、デプロイ権限に触れる可能性がある環境では、承認なしの操作を許可するかどうかを慎重に判断する必要があります。

導入手順の基本

managed-settings.json を使い始める流れは、公式情報をもとに整理すると次のようになります。GitHub では、Enterprise settings の AI Controls タブ、または API から設定元の Organization を選び、対象 Organization の .github-private リポジトリに copilot/managed-settings.json を作成すると説明されています。(The GitHub Blog)

手順作業内容注意点
1設定元にする Organization を決める既存のカスタムエージェント設定がある場合は同じ .github-private リポジトリが使われる
2.github-private リポジトリを確認する権限が広すぎないか、レビュー運用があるかを確認する
3copilot/managed-settings.json を作成する旧パス .github/copilot/settings.json には後方互換性があるが、新規運用は公式推奨パスを使う
4必要なキーだけを設定するすべての設定を一度に入れず、影響の小さい範囲から始める
5デフォルトブランチへコミットする反映対象になるため、PR レビューを通す
6VS Code / Copilot CLI で検証する再認証と時間差を考慮して確認する

最初から全社一律で強い制限をかけるよりも、まずは検証用の少人数で挙動を確認し、開発者向けの案内文を用意してから展開するのが現実的です。

設定ファイルの例

以下は、公式ドキュメントで示されている構造をもとにした例です。実際に利用する場合は、OWNER/REPO や PLUGIN-NAME@MARKETPLACE-NAME を自社の運用に合わせて置き換えます。(GitHub Docs)

{
  "extraKnownMarketplaces": {
    "agent-skills": {
      "source": {
        "source": "github",
        "repo": "OWNER/REPO"
      }
    }
  },
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "OWNER/REPO"
    }
  ],
  "enabledPlugins": {
    "PLUGIN-NAME@MARKETPLACE-NAME": true
  },
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "model": "auto"
  }
}

この例では、許可するプラグインマーケットプレイスを定義し、特定プラグインを有効化し、バイパスモードを無効化し、新しい会話の既定モデルを Auto model にしています。

ただし、実務ではこの設定をそのまま丸ごと入れるより、次のように段階的に分ける方が安全です。

フェーズ設定例狙い
第1段階model: "auto"影響が比較的小さい既定値から統一する
第2段階enabledPlugins標準プラグインの利用をそろえる
第3段階strictKnownMarketplaces未承認マーケットプレイスを制限する
第4段階disableBypassPermissionsModeセキュリティ影響の大きい権限制御を導入する

既存運用から移行するときの注意点

旧パスとの後方互換性を理解する

GitHub の公式情報では、AI standards source のサポート対象パスは copilot/managed-settings.json であり、従来の .github/copilot/settings.json には後方互換性があると説明されています。(The GitHub Blog)

既に旧パスで設定している場合、すぐに壊れるとは限りません。しかし、新しい設定を設計するなら、今後の運用を分かりやすくするために copilot/managed-settings.json へ寄せるのが無難です。

移行時は、次の失敗に注意してください。

失敗しやすいポイント対策
旧パスと新パスの両方に似た設定が残るどちらを正とするかを決め、不要な設定を整理する
JSON の構造を誤る変更前に JSON の構文チェックを行う
影響範囲を確認せずに制限を有効化する検証ユーザーで VS Code と Copilot CLI の挙動を確認する
開発者への周知が遅れる反映前に「何が変わるか」を簡潔に案内する
緊急時の戻し方が決まっていない直前のコミットへ戻せる運用にしておく

カスタムエージェント設定との関係を確認する

GitHub の Changelog では、既にカスタムエージェント用のソース Organization を設定している場合、この設定は同じ .github-private リポジトリを使うと説明されています。また、Enterprise settings の AI controls 配下にある Agents ページで設定が有効か確認できるとされています。(The GitHub Blog)

既に Copilot のカスタムエージェントやプラグイン標準を使っている企業では、managed-settings.json の導入が既存のエージェント運用と交差します。GitHub 管理者だけでなく、AI エージェントを整備しているチーム、セキュリティ担当、開発基盤チームで確認してから変更するのが安全です。

実務でおすすめの導入判断基準

managed-settings.json は便利ですが、すべての企業が同じ強度で使うべきものではありません。重要なのは、自社の Copilot 利用成熟度に合わせて導入範囲を決めることです。

組織の状態おすすめの対応
Copilot を試験導入中まずは model: "auto" など影響が小さい設定から検証する
複数チームで Copilot 利用が広がっているプラグイン標準とマーケットプレイス制御を検討する
セキュリティ要件が厳しいバイパスモード無効化を優先して検討する
開発者の自由度を重視している強制設定は最小限にし、理由を明文化する
既に独自の AI エージェントを運用している.github-private リポジトリの既存設定との整合性を確認する

特に日本企業では、AI ツールの利用可否だけを決めて、クライアント側の細かい設定は現場任せになりがちです。managed-settings.json は、その中間にある「現場の生産性を残しながら、最低限のガードレールをそろえる」ための選択肢になります。

よくある疑問

すべての GitHub ユーザーに関係する更新ですか？

いいえ。今回の主な対象は GitHub Enterprise Cloud の顧客で、Copilot Business または Copilot Enterprise ライセンスを企業または Organization から付与されているユーザーです。現時点で設定が強制されるクライアントは VS Code と Copilot CLI とされています。(The GitHub Blog)

GitHub.com の通常ユーザーや個人利用にも影響しますか？

個人で GitHub Copilot を使っているだけで、Enterprise からライセンスや設定を受けていない場合、この Enterprise managed settings の影響は通常ありません。影響を受けるのは、企業側が対象 Organization と .github-private リポジトリを設定し、サポート対象クライアントで利用しているケースです。

ユーザーが設定を上書きできますか？

サポート対象のキーについては、managed-settings.json がユーザー側のファイルベース設定より優先されます。たとえば企業がバイパスモードを無効化した場合、ユーザーがローカル側で自動承認を有効にしようとしても制限される可能性があります。(The GitHub Blog)

反映されない場合はどこを見るべきですか？

まず、設定ファイルが copilot/managed-settings.json に作成され、デフォルトブランチへコミットされているか確認します。次に、ユーザーが対象 Enterprise またはその Organization から Copilot アクセスを受けているか確認します。複数の請求元があるユーザーでは、個人の Copilot 設定で正しい Enterprise が選ばれているかも確認が必要です。(GitHub Docs)

まとめ：GitHub 管理者は「AI 利用ルールのコード化」として確認する

GitHub の「Enterprise managed-settings.json is generally available」は、GitHub Copilot の企業利用において、管理者が AI クライアント設定をファイルで標準化できるようにする更新です。ポイントは、VS Code と Copilot CLI の一部設定を Enterprise 側で制御でき、サポート対象キーではユーザー個別のファイル設定より優先されることです。

管理者はまず、.github-private リポジトリの権限、copilot/managed-settings.json のレビュー運用、既存の AI Controls やカスタムエージェント設定との関係を確認しましょう。開発者向けには、ローカル設定が上書きされる可能性、バイパスモード無効化の影響、反映タイミングを事前に共有しておくことが重要です。

次に取るべき行動は、いきなり全社展開することではありません。まず検証用の Organization または少人数の対象者で、model: "auto" やプラグイン標準など影響の小さい設定から試し、VS Code と Copilot CLI の実際の挙動を確認することです。そのうえで、セキュリティ要件に応じて disableBypassPermissionsMode や strictKnownMarketplaces の導入を検討すると、現場の生産性とガバナンスのバランスを取りやすくなります。

Microsoft
GitHub GitHub Copilot AIガバナンス Enterprise managed settings

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次