GitHubは2026年9月9日、Copilotエージェント操作の企業管理権限を発表しました。開発作業を委任するチームにとって、個人設定に左右されていた操作を中央で管理できることが実務上の変化です。
発表と設定リファレンスは9月10日に確認しました。本記事は導入検証の提案であり、企業テナントへの適用結果ではありません。
対象と変更点は？
GitHubの発表はBusinessとEnterpriseを対象とし、Copilotアプリ、CLI、Agent Hostを使うVS Codeセッションを挙げています。シェルコマンド、ファイルアクセス、ネットワークドメインを管理できます。
チームが使う正確なクライアントを確認してください。「Copilotを使っている」だけでは導入範囲が曖昧です。一つの対応クライアントで動く設定が、すべてのエディタやリモートエージェント、自動化経路を保護するとは限りません。
deny・ask・allowはどう作用する？
管理設定リファレンスは、次の優先順位を定義しています。
| ルール | 記載された効果 |
|---|---|
| deny | 別のルールが許可しても、一致する操作を禁止 |
| ask | 一致する操作のたびに新しい承認を要求 |
| allow | より強い制約がなければ、確認なしで許可 |
適用される管理許可リストは積集合になります。管理されたaskは、バイパス、自動承認、過去に保存された許可では満たせません。複数の設定元が同じ利用者に作用する場合に重要な条件です。
展開前に、実効設定を構成するポリシーの出所を記録しましょう。そうしないと、意図した承認要求をクライアントの不具合と誤認しやすくなります。
ポリシーをどう検証する？
使い捨ての作業領域で、害のない操作を使います。以下は実施済みの結果ではなく、提案する受け入れ確認です。
- 許可する予定の対応操作が進むことを確認する。
- 承認が必要な操作を二度行い、毎回尋ねられることを確認する。
- 禁止操作がローカルの承認設定でも解除されないことを確認する。
- 競合するルールに一致する操作で実効設定を確認する。
- 対象の全クライアントとチーム設定で繰り返す。
ポリシーの版、クライアントの版、操作、実際の判断を一緒に記録します。設定画面の画像だけより、再現可能な操作と期待する結果の方が強い証拠になります。
別途必要な保護は？
承認ルールは完全なサンドボックスではありません。許可されたコマンドがスクリプトや依存ライブラリを呼び、追加の作用を生むこともあります。ネットワーク、ファイルシステムの隔離、認証情報、ローカルMCPは実行環境で別途確認してください。
ファイル編集を許可しても、その編集が正しいとは限りません。通常のレビューと受け入れ確認を維持します。エージェントのガバナンスガイドは担当とエスカレーションの整理に役立ちます。
チームの運用をどう更新する？
管理設定の保守担当、実行環境の担当、コード変更の受け入れ担当を明確にします。予期しないブロックの報告経路と、適用範囲を広げる前の設定変更テストも決めます。
同時にモデルを導入する場合は、失敗を説明できるよう変更を分けてください。モデルの利用条件はGPT-6 AstraのCopilotガイド、自社実行環境への移行はCursorのデータ経路分析を参照できます。
よくある質問
保存済みの承認でCopilotの管理されたaskルールを通過できますか？
できません。GitHubは管理されたaskについて、毎回新しい一回限りの承認を求めると説明しています。バイパス、自動承認、以前保存された許可は使えません。
管理権限のルールはすべてのCopilotクライアントに適用されますか？
一律の対応を仮定しないでください。9月9日の発表はCopilotアプリ、CLI、Agent Hostを使うVS Codeセッションを挙げています。導入前に最新の対応表を確認してください。
エージェントの権限管理でサンドボックスやコードレビューを代替できますか？
できません。権限は対応する操作を進めてよいか判断し、サンドボックスは実行環境がアクセスできる資源を制限し、レビューは変更の正しさを確認します。それぞれ検証が必要です。