GitHub Copilot Business/Enterpriseの新しいデフォルトポリシーとは？10月22日までに管理者が確認したい設定【2026年9月】

GitHubは2026年9月24日、GitHub Copilot BusinessとCopilot Enterprise向けに、一般提供済み（GA）の機能をどう有効化するかを決める新しい「Default policy for new features」を発表しました。

今回の変更で注意したいのは、新機能が追加されたこと自体ではありません。2026年10月22日から、明示的に設定していない対象機能は、企業や組織で設定したデフォルトポリシーに従って有効・無効が決まるようになります。

GitHubの公式ドキュメントでは、この新しい機能向けデフォルトポリシーは初期状態で有効になっており、何も変更しなかった場合、対象となる「Unconfigured」のGA機能が10月22日から有効になると説明されています。

GitHub Copilotを個人向けプランで使っているだけなら、今回の企業・組織向けポリシー変更の直接の対象ではありません。一方、Copilot BusinessまたはCopilot Enterpriseを利用している企業で、GitHub EnterpriseやOrganizationの管理を担当しているSE、情報システム担当者、開発責任者は、10月22日までに現在の設定を確認しておきたい変更です。

特に重要なのは、「新しいGA機能を自動的に使えるようにしたいのか」「管理者が確認してから有効化したいのか」「Organizationごとに判断を委ねたいのか」を意図的に決めることです。

先に結論：10月22日までに「Unconfigured」を確認する
GitHub Copilotのデフォルトポリシーは何が変わる？
「Enabled」のままでよい会社と、確認した方がよい会社
10月22日から何が自動的に変わるのか
Preview機能まで自動で有効になるわけではない
Copilot Code ReviewとMCP servers in Copilotも確認対象
「機能」のデフォルトと「モデル」のデフォルトは別物
EnterpriseとOrganizationの役割分担にも注意
Enabled・Disabled・Organization判断のどれを選ぶべきか
10月22日までに管理者が確認したい手順
SE実務では「新機能を使えるか」だけで判断しない
フリーランスSEでも顧客環境では確認しておきたい
まとめ：10月22日前に「何も設定していない項目」を見る
参考情報

先に結論：10月22日までに「Unconfigured」を確認する

今回の変更への対応は、複雑な移行作業ではありません。まず確認したいのは、Copilotの各機能が現在どの状態になっているかです。

GitHubは新しいデフォルトポリシーについて、2026年9月24日から28日間は設定できるものの、ユーザーの機能アクセスにはまだ影響しない準備期間としています。そして10月22日から、対象となるGA機能にデフォルトポリシーが適用されます。

特に確認すべきなのは「Unconfigured」と表示されている項目です。「Unconfigured」は単純に「無効」という意味ではありません。10月22日以降は、明示的な設定がない対象機能に対して、企業または組織で決めたデフォルトポリシーが適用されます。

そのため、「設定していないから今後も無効のままだろう」と考えるのは危険です。GitHub Docsでは、新しい機能向けデフォルトポリシーは初期状態で有効とされており、管理者が何もしなければ対象となる未設定のGA機能が有効になると説明されています。

Copilotを会社で利用しているなら、まず「現在Unconfiguredになっている機能が何件あるか」を確認するところから始めると整理しやすくなります。

GitHub Copilotのデフォルトポリシーは何が変わる？

今回追加されたのは、Copilotの機能を個別に一つずつ設定するだけでなく、未設定の機能に対する基本方針をあらかじめ決めておく仕組みです。管理画面では「Default policy for new features」として設定します。

設定	動作
Enabled	現在および今後の対象GA機能を原則利用可能にする
Disabled	現在の対象未設定機能を利用不可とし、今後の対象機能も管理者の承認が必要になる
Let organizations decide	Enterprise側では決めず、Organization管理者に判断を委ねる

ここで重要なのは、「新しい機能だけ」に適用されるわけではないことです。GitHub Docsによると、対象には新しくGAになった機能だけでなく、現在すでにGAでありながら「Unconfigured」になっている機能も含まれます。また、PreviewからGAへ移行した機能も対象です。

つまり10月22日は、新機能が突然追加される日というより、現在放置されている未設定項目に、組織としてのデフォルト方針が適用され始める日と考えた方が分かりやすいです。

「Enabled」のままでよい会社と、確認した方がよい会社

新しいGA機能を積極的に試す開発組織であれば、Enabledを選ぶことで管理の手間を減らせます。Copilotへ新しい対象機能が追加されるたびに管理者が個別承認しなくても、対象機能を利用できるためです。

小規模な開発チームや、Copilotの新機能を比較的自由に試せる環境では合理的な運用になる可能性があります。

一方、金融、医療、受託開発、大企業の社内システムなど、利用可能なAI機能を事前審査している組織では注意が必要です。新しい機能には、外部サービスとの接続、エージェントによる処理、リポジトリへのアクセスなど、従来のコード補完とは異なる性質を持つものがあります。

ただし、今回のデフォルトポリシーを有効にしたからといって、すべてのCopilot機能や外部システムへのアクセスが無条件で許可されるわけではありません。適用対象には条件や例外があり、個別に明示した設定も維持されます。

そのため、「Enabledは危険」「Disabledなら安全」と単純に判断するのではなく、自社でどこまで新機能の自動利用を許可するのかを決める必要があります。

10月22日から何が自動的に変わるのか

GitHubの公式発表では、10月22日に新しいデフォルトポリシーが有効になると、対象となるGA機能のうち「Unconfigured」の項目がデフォルト設定に従うようになります。

一方、すでに明示的にEnabledまたはDisabledとして設定している機能については、その判断が維持されます。例えば、企業のデフォルトをEnabledにしたとしても、ある特定の機能を事前にDisabledとして設定していれば、その機能まで強制的に有効になるわけではありません。

この仕様は実務上かなり重要です。「基本的には新しいCopilot機能を使わせたいが、一部だけは禁止したい」という企業なら、デフォルトをEnabledとしながら、制限したい機能だけ個別にDisabledへ変更できます。

反対に、「原則禁止し、評価が終わった機能だけ利用可能にしたい」のであれば、デフォルトをDisabledにして、承認済み機能だけ個別にEnabledへ変更する運用が考えられます。

Preview機能まで自動で有効になるわけではない

今回の変更について、「Copilotの新機能がすべて自動的に有効になる」と理解しないよう注意が必要です。GitHubはPreview機能について、新しいデフォルトポリシーの対象外としています。Preview機能は引き続きオプトインです。

また、Preview段階で明示的に利用を選択した機能が後からGAへ移行した場合も、それまでの明示的な選択は保持されます。

企業のAIガバナンスを考えるときは、「GAになった新機能をどう扱うか」と「Preview機能を誰に試させるか」を分けて考えた方が管理しやすくなります。検証チームだけPreviewを許可し、一般利用者にはGA機能だけ提供するといった運用も考えられます。

Copilot Code ReviewとMCP servers in Copilotも確認対象

今回のデフォルトポリシーで見逃しやすいのが、Copilot Code ReviewとMCPです。GitHubによると、新しいデフォルトポリシーは「Features & clients」ページで管理される対象機能だけでなく、AgentsページにあるCopilot Code Reviewのポリシーと、MCPページの「MCP servers in Copilot」ポリシーにも適用されます。

Copilot Code Reviewは、単純にコードを生成する機能とは役割が異なり、Pull Requestに対する指摘や再レビューなど開発フローそのものへ入る機能です。すでにCopilotをコード補完だけで利用している会社でも、コードレビュー機能については別途運用を決めている場合があります。

コードレビュー機能そのものの改善については、既存記事「GitHub Copilotのコードレビュー改善とは？指摘の対応状況・再レビュー・コミット作成をSE実務で整理【2026年9月】」で詳しく扱っています。今回の記事は機能改善ではなく、企業管理者が新しいデフォルトポリシーをどう確認するかが中心です。

MCPはModel Context Protocolの略で、AIエージェントと外部ツールやデータソースを接続するための仕組みです。GitHub Docsでは「MCP servers in Copilot」ポリシーが、CopilotでMCPサーバー機能を利用できる場所を管理すると説明されています。

ただし、このポリシーはCursor、Windsurf、Claudeなど第三者のホストアプリケーションからGitHub MCP Serverへアクセスするときの権限まで制御するものではありません。企業利用では、Copilot側のポリシーと、接続先・ホストアプリ側の権限管理を分けて考える必要があります。

「機能」のデフォルトと「モデル」のデフォルトは別物

今回の変更で特に混乱しやすいのが、Copilotモデルの自動有効化です。GitHub Copilotには複数のAIモデルがあり、企業管理者は利用可能なモデルを管理できます。

しかし今回10月22日から適用される「Default policy for new features」は、モデル向けのデフォルト設定とは別です。GitHub Docsでは、Copilot BusinessとCopilot Enterpriseについて、「機能のデフォルトポリシー」と「モデルのデフォルトポリシー」の2種類が存在すると説明しています。

モデル側の「Default availability for released models」はすでに有効です。一方、今回発表された機能側のデフォルトポリシーは10月22日から適用されます。

また、モデル側にも例外があります。Pre-GAモデル、Open weightモデルの一部、GitHubのデータ保持契約の対象外となる一部モデルなどは、デフォルトポリシーにかかわらず無効になるとGitHub Docsに記載されています。データレジデンシーやFedRAMP準拠モデルに制限している企業では、その制約を満たさないモデルも対象外です。

管理者としては、「どのCopilot機能を使えるか」と「どのAIモデルを使えるか」を別の設定として確認する必要があります。

EnterpriseとOrganizationの役割分担にも注意

GitHub Enterprise配下に複数のOrganizationを持っている場合は、誰が設定を決めるのかも整理しておきたいところです。

Enterprise ownerは、企業全体へ一つのポリシーを適用することも、個々のOrganization ownerへ判断を委ねることもできます。Enterprise側で「Let organizations decide」を選択すれば、Organization側で対象機能の利用可否を決められます。

一方、Enterprise ownerが特定のポリシーを明示的に有効化または無効化した場合、Organization側からその設定を上書きできないケースがあります。

複数部門を持つ企業では、この仕組みを使って、AI機能を積極的に検証する開発部門と、より厳格な管理が必要な部門で設定を分けることもできます。ただしOrganizationごとに判断を任せるほど設定差も増えます。「どのOrganizationが何を許可しているのか」を棚卸しできる運用も必要です。

Enabled・Disabled・Organization判断のどれを選ぶべきか

どの設定が適切かは、企業の運用方針によって変わります。

Enabledは、新しいGA機能を早く利用でき、管理者の承認作業も減らしやすい設定です。一方、新機能が追加されるたびに事前評価したい企業には向きません。

Disabledは、管理者が確認した機能だけを許可する運用を作りやすくなります。ただし、新しい機能を使うたびに管理者側の設定変更が必要になり、開発者が利用開始できるまで時間がかかる可能性があります。

Let organizations decideは、部署やプロジェクト単位で異なる方針を持つ企業に使いやすい選択肢です。一方で、Organizationごとに設定が分散するため、企業全体の統制や棚卸し方法を決めておく必要があります。

重要なのは、一律にどれかが優れているわけではなく、「新機能を速く使いたいのか」「管理者による事前確認を優先するのか」「Organizationへ権限委譲したいのか」を決めてから選択することです。

10月22日までに管理者が確認したい手順

実務では、次の順序で確認すると整理しやすくなります。

Enterprise ownerはGitHubの「AI controls」からCopilot設定を開く
「Default policy for new features」の現在値を確認する
画面に表示される未設定ポリシー数を確認し、Unconfiguredの対象を洗い出す
企業全体をEnabled、Disabled、Let organizations decideのどれで運用するか決める
Copilot Code ReviewとMCPの設定も確認する
例外として個別に明示したい機能は10月22日より前に設定する
機能とは別に、モデル側のDefault availabilityも確認する
Organizationへ判断を委ねる場合は、担当者と運用ルールを決める

設定変更そのものより、この「現状の棚卸し」の方が重要です。既存設定が明示的にEnabledまたはDisabledになっていれば、その判断は維持されます。問題になりやすいのは、これまで特に判断せずUnconfiguredのまま残していた項目です。

SE実務では「新機能を使えるか」だけで判断しない

開発者側から見ると、新しいCopilot機能が自動で利用可能になることは便利です。しかし企業導入では、機能が使えることと、業務で利用してよいことは同じではありません。

例えばAIエージェントを追加する場合でも、どのリポジトリへアクセスするのか、外部サービスと通信するのか、生成したコードを誰がレビューするのか、エージェントが実行できる操作は何か、ログをどこまで保存するのか、といった運用ルールが必要になります。

今回のポリシー変更は、こうした個別機能の安全性や利用条件を自動的に判断してくれる仕組みではありません。あくまで「明示的に設定していない対象機能を、デフォルトでどう扱うか」を管理する仕組みです。

そのため企業では、ポリシー設定と業務利用ルールを分けて考える必要があります。

フリーランスSEでも顧客環境では確認しておきたい

個人向けのGitHub Copilot契約では今回の企業・組織向けポリシー変更は直接の対象ではありません。ただし、フリーランスSEが顧客のGitHub EnterpriseやOrganizationへ参加して開発している場合は事情が異なります。

自分のCopilot環境では利用できる機能が、顧客Organizationでは無効になっていることがあります。反対に、企業側で新しいGA機能が有効になったとしても、その機能を案件で利用してよいとは限りません。

特にAIエージェント、外部連携、MCPなどを利用する場合は、技術的に使えるかどうかだけでなく、顧客の利用規約や情報管理ルールも確認した方が安全です。「GitHubでボタンが押せるから利用可能」と判断せず、案件のAI利用ルールと合わせて確認する必要があります。

まとめ：10月22日前に「何も設定していない項目」を見る

GitHub Copilot Business / Enterpriseの今回の変更で重要なのは、新しい設定項目そのものよりも、これまで「Unconfigured」のままになっていた機能の扱いが変わることです。

2026年10月22日から、対象となる未設定のGA機能は「Default policy for new features」に従うようになります。現在の公式ドキュメントでは、このデフォルトポリシーは初期状態で有効であり、何もしなければ対象となる未設定機能が有効になると説明されています。

一方、すでに明示的に設定したポリシーは維持され、Preview機能も自動的に有効になるわけではありません。

SEやGitHub管理者が今やるべきことは、新機能を一つずつ調べ始めることより、まず現在の設定を開いて「Unconfigured」がどれだけ残っているかを確認することです。そのうえで、新しいGA機能を原則利用可能にするのか、事前承認制にするのか、Organizationごとに判断させるのかを決めます。

Copilotはコード補完から、コードレビュー、AIエージェント、MCPなどへ利用範囲が広がっています。機能が増えるほど、追加されたものを一つずつ追いかけるだけでは管理が難しくなります。今回のデフォルトポリシーは、その管理方法を企業側で先に決めておくための仕組みと考えると理解しやすいでしょう。