GitHubは2026年9月24日、Copilot BusinessとCopilot Enterprise向けに、一般提供済みのCopilot機能と対応クライアント機能へ適用される「Default policy for new features」を案内しました。ポイントは、管理者が明示的に設定していない対象機能が、2026年10月22日以降にグローバル既定値へ従うことです。既定値をEnabledのままにすると、未設定の対象機能は有効化される前提で扱われます。
この記事では、GitHub公式ChangelogとGitHub Docsの内容をもとに、企業管理者が28日以内に確認すべき設定、影響範囲、例外、組織別の判断軸を整理します。Copilotの新機能を早く使わせたい企業と、監査・データ保護を優先したい企業では、選ぶべき既定値が変わります。
概要：10月22日から未設定機能が既定ポリシーに従う
今回の変更は、Copilotのすべてを強制的に上書きするものではありません。対象は、企業または組織のCopilot設定で「Unconfigured」のまま残っている一般提供済み機能です。GitHubは、9月24日の発表時点から次の28日間は設定できるが、まだユーザーの機能アクセスには影響しない猶予期間と説明しています。
2026年10月22日以降、対象機能が未設定なら、選択したグローバル既定値に従います。すでにEnabledまたはDisabledを明示している機能は維持されます。Preview機能は引き続きオプトインで、Preview時代に選んだ設定がある場合、GAになってもその選択が尊重されます。
仕様表：3つの選択肢と対象範囲
管理者が選べる設定は3つです。Enabledは、現在と将来の対象機能をユーザーが利用できる状態にします。Disabledは、現在の対象機能を利用不可にし、将来の対象機能も管理者承認が必要な状態にします。Let organizations decideは、組織管理者へ判断を委任します。
対象になるのは、enterpriseの「Features & clients」ページで管理される機能に加えて、AgentsページのCopilot Code Reviewポリシー、Copilot policy内のMCP serversです。GitHub Docsでは、既存GA機能、新しいGA機能、PreviewからGAへ移行する機能が対象と説明されています。
一方で例外もあります。Preview機能はこの機能ポリシーの対象外です。また、GHE.comのデータレジデンシーやFedRAMP向けの制限モデルポリシー、Copilot CLIとVS CodeのローカルセッションをCloudへ保存する設定は、Docs上で例外として示されています。
管理の見方を表にすると、開発生産性を優先する部門はEnabled、規制業務や顧客データを扱う部門はDisabled、部門ごとにリスク許容度が違う企業はLet organizations decideが候補になります。全社一律ではなく、enterpriseとorganizationの責任分界を先に決めることが重要です。
Copilotの設定棚卸しやAI活用ルール整備を短期間で進めたい場合は、HelloCraftAIのAI研修・導入支援でも相談できます。
設定方法：AI Controlsでまず未設定数を確認する
最初に確認すべき場所は、enterpriseのAI Controlsです。AI Controlsを開き、Copilotのサブページへ移動し、「Default policy for new features」を確認します。GitHubの発表では、Features & clientsページ、AgentsページのCode Review、MCP関連ポリシーが関係すると説明されています。
次に、画面上のバナーや一覧でUnconfiguredの対象数を確認します。ここで見るべき数字は、単なる機能数ではなく、10月22日に自動的に既定値の影響を受ける可能性がある未判断項目です。数が多い場合は、全社Enabledにする前にリスクが高い機能だけ個別にDisabledへ落とす運用が現実的です。
3つ目に、organization単位の例外を決めます。たとえば研究開発組織は新機能の試用を早め、金融・法務・顧客データを扱う組織はDisabledを初期値にする、といった分け方です。Let organizations decideを使う場合も、組織管理者が未設定のまま放置しないよう、期限とレビュー担当を決める必要があります。
28日チェックリスト：公開前に見る8項目
1. enterpriseのDefault policy for new featuresがEnabled、Disabled、Let organizations decideのどれかを確認する。2. Features & clientsページでUnconfiguredの機能数を確認する。3. Code ReviewとMCP serversが今回の確認対象に含まれることを管理者間で共有する。4. Preview機能は対象外だが、GA移行時の設定引き継ぎを確認する。
5. 明示的にEnabledまたはDisabledにした設定は上書きされないため、重要機能から個別設定を固定する。6. 規制部門や顧客データを扱うorganizationに例外ルールを作る。7. 10月22日までに棚卸しレビューを1回、適用後にログ確認を1回入れる。8. 新機能のChangelog監視担当を決め、月1回のCopilot設定レビューへ組み込む。
この8項目の狙いは、Copilotの新機能を止めることではありません。意図しない有効化を防ぎつつ、開発チームが必要な機能を遅れず使える状態を作ることです。特にMCP serversやCode Reviewは、開発体験だけでなく、外部ツール連携、レビュー品質、データ取り扱いにも関わるため、情シスと開発部門の合同レビューが向いています。
判断軸：Enabledにする組織、Disabledにする組織
Enabledが向いているのは、Copilotの新機能を積極的に検証し、開発者の利用ログや効果測定を毎月見られる組織です。新機能がGAになったタイミングで試用が遅れにくく、現場からのフィードバックも集めやすくなります。条件は、Changelog確認、影響範囲レビュー、問題時の無効化手順があることです。
Disabledが向いているのは、顧客データ、機密コード、規制要件、委託先との分掌が厳しい組織です。新機能の利用前に、データ送信範囲、保存期間、外部連携、監査ログ、利用対象者を確認できます。速度は落ちますが、承認フローを残せるため、内部監査で説明しやすくなります。
Let organizations decideは、全社で同じ判断が難しい企業に向きます。ただし、委任しただけでは統制になりません。organizationごとの責任者、判断期限、例外申請、月次レビューの4点をセットにして、未設定のまま10月22日を迎えない運用にする必要があります。
FAQ：管理者が迷いやすい質問
Q. 何もしないとどうなりますか。A. GitHub Docsでは、この機能ポリシーはデフォルトでEnabledと説明されています。未設定の対象機能は、2026年10月22日以降に有効化される前提で確認したほうが安全です。
Q. すでにDisabledにした機能も変わりますか。A. GitHubの発表では、明示的な判断は維持されると説明されています。重要な機能はUnconfiguredのままにせず、EnabledまたはDisabledを明示しておくのが実務上の対策です。
Q. Preview機能も自動で有効になりますか。A. Preview機能は引き続きオプトインです。ただし、PreviewからGAへ移行する時点で既存の選択が維持されるため、試験導入中の機能も棚卸し対象に入れておくと安心です。
Q. モデルの既定可用性とは同じですか。A. GitHub Docsでは、機能の既定可用性とモデルの既定可用性は別ポリシーとして説明されています。モデル側はすでに有効で、新しい未設定GAモデルに影響します。機能側は10月22日から適用されます。
まとめ：28日以内に未設定を判断済みに変える
今回の変更で重要なのは、Copilotの新機能そのものよりも、未設定を放置した場合の扱いが明確になる点です。10月22日までに、Default policy for new features、Unconfiguredの対象数、Code Review、MCP servers、組織別の例外を確認しておけば、意図しない有効化を避けながら新機能の展開速度も保てます。
HelloCraftAIでは、Copilot Business/Enterpriseの設定棚卸し、AI開発ルール、社内研修、PoC設計までまとめて支援しています。自社のCopilot設定を28日以内に整理したい方は、導入状況を添えてご相談ください。
