GitHub Copilot appを全社導入し始めた企業にとって、2026年7月27日の更新は見逃しにくい変更です。これまでCopilot appの利用可否はCopilot CLIポリシーと強く結び付いていましたが、今回からCopilot app専用のポリシーでアクセスを切り分けられるようになりました。さらにenterprise managed settingsがCopilot appとCopilot cloud agentにも適用され、プラグイン許可、マーケットプレイス制限、承認バイパス抑止、既定モデル設定まで一元管理できます。
結論から言うと、今回の更新で情シスや開発基盤チームが最初に確認すべきポイントは3つです。1つ目は、Copilot appをCLIとは別に有効化・無効化できるようになったこと。2つ目は、managed-settings.jsonのガードレールがCopilot appとcloud agentにも広がり、承認フローやプラグイン配布の統制漏れを減らせること。3つ目は、設定反映タイミングが即時ではなく、再サインイン・再起動・次回タスク割り当て・約1時間以内の反映など面ごとに差があることです。
GitHub Copilot app専用ポリシーで何が変わったのか
GitHub公式の2026年7月27日付 changelog では、Copilot appに専用ポリシーが追加されたと明記されています。これまではCopilot appへのアクセスがCopilot CLIポリシーの有効化に依存していましたが、今後は両者を独立して制御できます。つまり、CLIはまだ許可したくないがCopilot appは試したい、逆にappは止めたいがCLIは残したい、といった運用判断がしやすくなりました。
設定場所はenterpriseまたはorganizationのAI Controls内にある「Copilot Clients」セクションです。選べる状態は「Enabled everywhere」「Disabled everywhere」「Let organizations decide」の3択で、初期値はEnabled everywhereです。既定で有効なため、管理者が何もしないと利用が始まる点は、厳格な審査運用をしている企業ほど先に確認しておきたいポイントです。
enterprise managed settingsがappとcloud agentに広がる意味
同日の別changelogでは、enterprise managed settingsがGitHub Copilot appとCopilot cloud agentに適用されたことが案内されています。managed-settings.jsonで一度決めた設定が、既存のCopilot CLI・VS Codeだけでなくappやcloud agentにも反映されるため、表面ごとに別ルールを持つ必要が減ります。GitHub Docsでも、ガバナンスは最も統制の弱いsurfaceに引っ張られると説明されており、appだけ別管理の状態は監査上の穴になりやすいと整理できます。
今回appで統一できる代表項目は、enabledPlugins、extraKnownMarketplaces、strictKnownMarketplaces、permissions.disableBypassPermissionsMode、permissions.modelです。要するに、どのプラグインを許可するか、どのマーケットプレイスからだけ入れられるか、承認を飛ばすような挙動を禁じるか、自動モデル選択を既定にするかを横断的に揃えられます。cloud agent側も承認バイパス設定以外の多くを引き継ぐため、タスクを裏側で動かすときだけ統制が抜ける、という事故を抑えやすくなります。
GitHub Copilot appや各種agentを部署横断で広げる前に、どこまで自律実行を許すか、どのプラグインだけを残すかを先に決めておくと後戻りが減ります。社内統制の設計から一緒に整理したい場合は HelloCraftAIへ相談してください 。
管理者が先に見るべき設定項目と判断順
実務では、まず利用可否、その次にプラグインと承認、その後にモデルと反映時間の順で確認すると整理しやすいです。第1に、Copilot appを全社有効にするか、特定organizationだけに委ねるかを決めます。第2に、managed-settings.jsonでapproved pluginの一覧とstrictKnownMarketplacesの有無を確認します。第3に、disableBypassPermissionsModeを有効にして、現場が都度承認を飛ばせない状態を保てるかを確認します。第4に、permissions.modelで既定モデルをautoにするか固定するかを決め、AI creditsや品質差の影響を見ます。
この順番が有効なのは、appを開放した後にプラグイン統制や承認統制を詰め始めると、すでに一部チームで運用が走ってしまうからです。特にPoC段階では「まず便利に使ってもらう」方向に流れやすい一方、enterprise managed settingsはMDM管理、server-managed、file-based、user-levelの順で優先されます。現場のローカル設定より上位設定が勝つ設計なので、早めにenterprise側で基準を決める方が修正コストが小さくなります。
導入時に起きやすい3つの見落とし
1つ目は「CLIを止めればappも止まる」という旧認識のまま運用してしまうことです。現在は専用ポリシーがあるため、CLIを無効にしてもappが有効なまま残る可能性があります。2つ目は、interactive client向けの承認バイパス制御とcloud agent向けの設定差を理解しないまま同一運用だと考えることです。GitHubはbypass-prompt controlsはapp、CLI、VS Codeなどinteractive clientsに適用されると説明しており、cloud agentではプラグインやマーケットプレイス統制が主軸になります。3つ目は、設定変更が即時全面反映されると思い込むことです。appは再サインインや再起動、cloud agentは次回タスク割り当て、supported clients全体では概ね1時間以内など、反映契機に差があります。
とくに承認設計を曖昧にしたままAutopilotやcloud sandboxを試すと、現場には「全部自動で流してよい」という誤解が広がりやすくなります。GitHub Docs上でもCopilot appはparallel workspaces、PR作成、複数モデル選択、スケジュール実行まで一つのアプリで扱えるとされており、便利さが高いぶん、利用境界を先に決める価値が大きいといえます。
導入チェックリスト: 7月27日更新をどう実務に落とすか
最短で確認するなら、次の5点を会議30分で埋めるのがおすすめです。1. enterpriseでCopilot appポリシーをEnabled everywhereのままにするか。2. organizationに委譲する場合、どの部門に最初の判断権を渡すか。3. managed-settings.jsonで許可するプラグインと厳格なmarketplace制限をどう置くか。4. disableBypassPermissionsModeを有効にし、承認を飛ばせない設定を標準にするか。5. 設定変更後、誰が再起動・再サインイン・検証タスク実行を担当するか。
もし既にCopilot CLIとVS Codeでmanaged-settings.jsonを配っている企業なら、新規の大規模設計は不要です。既存設定をappとcloud agentに広げたとき、どこまで同じルールでよいかを再確認すれば足ります。一方で、これから初めてenterprise managed settingsを入れる企業は、.github-private リポジトリ作成、copilot/managed-settings.json配置、キー定義、反映確認までを1セットで進める必要があります。
FAQ: よくある疑問
Q. Copilot CLIを無効にすればCopilot appも止まりますか。A. いいえ。GitHub DocsではappとCLIは別の独立したclient policyで管理されると明記されています。Q. appはどのプランで使えますか。A. GitHub DocsではCopilot appはall Copilot plans availableと案内されていますが、BusinessとEnterpriseではapp policyが有効である必要があります。Q. 既存のmanaged-settings.jsonをそのまま使えますか。A. 既にCLIやVS Code向けに配布していれば、新しいappは再起動または再サインイン後、cloud agentは次回タスク割り当て時に反映される想定です。
GitHub Copilot appを広げる論点は、単なる新機能紹介ではなく「どのsurfaceまで同じ統制で覆えるか」です。7月27日更新を機に、app、CLI、VS Code、cloud agentを別々に見るのではなく、全体のガードレールとして見直すと導入事故を減らせます。社内ガバナンス、PoC設計、利用ルール策定まで含めて整理したい場合は こちらからお問い合わせください 。
