GitHub Copilot Business／Enterpriseを利用している組織では、2026年8月26日から、新たに一般提供されたGAモデルが既定で利用可能になる仕組みが適用されます。現在のように、新しいモデルを管理者が一つずつ承認してから公開したい場合は、8月26日より前にDefault availability for released modelsポリシーをDisabledへ変更する必要があります。
何も設定しない場合、個別に有効・無効を指定していないモデルはinherits defaultへ移行し、既定で有効になっているポリシーに従って利用可能になります。一方、個別モデルに対してすでに明示したEnabled／Disabledの判断は変更されません。(The GitHub Blog)
8月26日前にCopilotモデルの自動有効化を止める設定
新しいCopilotモデルを引き続き管理者の承認制にしたい場合、実施すべき対応は次のとおりです。
- GitHubのEnterpriseまたはOrganization設定を開く
- Copilotのモデル設定画面へ移動する
Default availability for released modelsを確認する- ポリシーを
Disabledに変更する - 現在のモデルごとの
Enabled／Disabled設定を確認する - 2026年8月26日以降、未設定モデルが意図した状態になっているか再確認する
このポリシーは2026年7月29日から設定画面に表示されています。ただし、8月26日までは設定を変更してもモデルの利用可否には影響しません。8月26日になると、新規GAモデルだけでなく、既存の未設定GAモデルにもポリシーが適用されます。(The GitHub Blog)
Copilotのモデル管理は何が変わるのか
今回の変更の本質は、単に新しいモデルが追加されることではありません。
これまで管理者が何も設定していないモデルは、実質的に利用開始の承認待ちとして扱われていました。8月26日以降は、未設定という状態がinherits default、つまり「既定のポリシーを継承する状態」に変わります。(The GitHub Blog)
| 状態 | 8月26日以降の動作 |
|---|---|
個別にEnabled | ポリシーにかかわらず利用可能 |
個別にDisabled | ポリシーにかかわらず利用不可 |
inherits defaultかつ既定ポリシーがEnabled | 利用可能 |
inherits defaultかつ既定ポリシーがDisabled | 利用不可 |
| 対象外モデル | 既定ポリシーでは自動有効化されない |
inherits defaultは固定された設定ではありません。ポリシーを変更すると、この状態にあるモデルも直ちに新しい既定値へ追従します。たとえば、8月26日以降にポリシーをEnabledからDisabledへ変更すれば、inherits defaultのモデルはまとめて利用不可になります。(The GitHub Blog)
ただし、意図せずモデルが利用可能になる期間を作らないためには、8月26日より前に設定を完了させるのが安全です。
Enterpriseでポリシーを無効化する手順
Enterprise全体で新規GAモデルの自動有効化を止める場合は、Enterprise Ownerなど、必要な管理権限を持つアカウントで操作します。
- GitHubで対象のEnterpriseを開く
- 画面上部の「AI controls」を選択する
- サイドバーから「Copilot」を開く
- 「Configure models」を選択する
Default availability for released modelsを探す- 設定を
Disabledへ変更する - モデル一覧で、個別の
Enabled、Disabled、Optionalも確認する
GitHubのEnterprise設定では、モデルを次の3種類の状態で管理できます。
| Enterpriseでの設定 | 意味 |
|---|---|
Enabled | Enterprise内の全対象ユーザーに有効 |
Disabled | Enterprise内の全対象ユーザーに対して明示的に無効 |
Optional | OrganizationまたはEnterprise Team側で追加設定できる状態 |
EnterpriseレベルでモデルをEnabledまたはDisabledにしている場合、その明示的な設定が優先されます。Organizationごとに判断させたいモデルはOptionalにします。(GitHub Docs)
Enterprise全体で無効化すべきケース
次のような組織では、EnterpriseレベルでDefault availability for released modelsをDisabledにする運用が適しています。
- 新しいAIモデルを情報システム部門や法務部門が事前審査している
- 利用可能モデルを社内規程や承認済みリストで限定している
- モデル追加前に出力品質や利用条件を検証している
- 全Organizationで同じモデル利用基準を適用したい
- 未承認モデルが一時的にでも利用可能になることを避けたい
運用上、Disabledは「承認したモデルだけを有効にする許可リスト型」、Enabledは「問題のあるモデルだけを個別に止める除外リスト型」と考えると判断しやすくなります。
Organization単位でポリシーを無効化する手順
Enterprise全体では自動有効化を許可しつつ、機密性の高いOrganizationだけを承認制にする運用も可能です。
Organization Ownerは、次の手順でモデル設定を確認できます。
- GitHub右上のプロフィール画像を選択する
- 「Organizations」を開く
- 対象Organizationを選択する
- Organizationの「Settings」を開く
- 「Code, planning, and automation」の「Copilot」を選択する
- 「Models」を開く
Default availability for released modelsをDisabledに変更する- 個別モデルの状態を確認する
この画面では、Enterprise側でOptionalにされたモデルについて、Organization OwnerがEnabledまたはDisabledを選択できます。Organization側で何も指定しなかったモデルは、OrganizationのDefault availability for released modelsに従います。(GitHub Docs)
Organization側で変更できない場合
モデル設定が固定されていて変更できない場合は、次の可能性があります。
- Enterprise Ownerがモデルを明示的に有効または無効にしている
- Enterprise側でOrganizationへの制御委任が行われていない
- Enterprise Teamsによるモデルアクセス管理のプレビューが有効になっている
- 操作しているユーザーに必要な権限がない
Enterprise Teamsのモデルアクセス管理が有効なEnterpriseでは、Organizationレベルのモデル設定が無効になります。この場合は、Enterpriseのモデル設定とEnterprise Teamごとの割り当てを確認する必要があります。(GitHub Docs)
既存の個別モデル設定は変更されない
今回の変更で最も誤解しやすいのが、既存モデルの扱いです。
Default availability for released modelsをDisabledにしても、すでに個別にEnabledと設定したモデルが自動的に無効になるわけではありません。同様に、個別にDisabledと設定したモデルが、既定ポリシーによって有効になることもありません。(The GitHub Blog)
たとえば、次のような設定があるとします。
| モデル | 現在の個別設定 | 既定ポリシーをDisabledにした後 |
|---|---|---|
| モデルA | Enabled | 引き続き利用可能 |
| モデルB | Disabled | 引き続き利用不可 |
| モデルC | 未設定 | 利用不可 |
| 今後追加されるGAモデル | 未設定 | 利用不可 |
つまり、既定ポリシーの変更は、あくまで明示的な判断が行われていないモデルに対するルールです。
既存モデルも含めて利用可能なモデルを整理したい場合は、既定ポリシーを変更した後に、モデル一覧を一つずつ確認してください。
自動有効化の対象になるモデル
Default availability for released modelsの対象になるのは、基本的に次の条件を満たすモデルです。
- 一般提供済みのGAモデル
- EnterpriseまたはOrganizationで明示的な設定が行われていない
- GitHubが既定有効化の対象として扱うモデル
- 組織のデータ所在地やFedRAMP関連の制限に適合するモデル
Enterpriseレベルでは、モデル設定ページの一覧に追加されていないモデルが未設定として扱われます。Organizationレベルでは、Enterprise管理者がOptionalにしており、Organization Ownerが個別に有効・無効を決めていないモデルが該当します。(GitHub Docs)
自動有効化から除外されるモデル
すべての新規モデルが自動的に有効になるわけではありません。GitHubの公式ドキュメントでは、次のモデルが既定有効化の対象外とされています。(GitHub Docs)
| 除外対象 | 扱い |
|---|---|
個別にDisabledと設定したモデル | 自動有効化されない |
| GA前のモデル | 自動有効化されない |
| オープンウェイトモデル | 自動有効化されない |
| GitHubのデータ保持契約の対象外モデル | 自動有効化されない |
| データ所在地の制限に適合しないモデル | 制限対象Enterpriseでは自動有効化されない |
| FedRAMP要件に適合しないモデル | 制限対象Enterpriseでは自動有効化されない |
公式ドキュメントでは、オープンウェイトモデルの例としてDeepSeekやKimi K2.7 Code、GitHubのデータ保持契約の対象外モデルの例としてClaude Fable 5が挙げられています。(GitHub Docs)
ただし、「一部のモデルが除外されるから何もしなくても安全」とは限りません。除外条件に該当しない新規GAモデルは、既定ポリシーがEnabledであれば利用可能になります。
ポリシーをEnabledのままにするかDisabledにするか
すべての組織が自動有効化を止める必要はありません。モデル利用の承認方法に応じて判断します。
| 組織の運用方針 | 推奨設定 |
|---|---|
| 新しいモデルをすぐ利用できるようにしたい | Enabled |
| モデルごとの手動承認を維持したい | Disabled |
| 法務・セキュリティ審査後に公開したい | Disabled |
| 管理作業を減らし、問題のあるモデルだけ止めたい | Enabled |
| Organizationごとに要件が異なる | Enterpriseで委任し、厳格なOrganizationのみDisabled |
| 利用可能モデルを社内規程で限定している | Disabled |
特に、現在「新しいモデルは管理者が有効化するまで使わせない」という認識で運用している組織は注意が必要です。その認識のまま設定を変更しないと、8月26日以降は運用ルールと実際のGitHub設定が一致しなくなります。
8月26日までに実施したい確認項目
ポリシーを単にDisabledへ変更するだけでなく、次の内容も併せて確認すると移行後の混乱を防げます。
管理単位を確認する
最初に、モデル管理をEnterprise全体で行うのか、Organizationごとに行うのかを決めます。
Enterpriseで統一管理する場合は、Organization側に設定を任せすぎないようにします。反対に、部門ごとに異なるルールを使う場合は、Enterprise側で対象モデルをOptionalにし、Organization Ownerの責任範囲を明確にします。
現在の個別設定を棚卸しする
モデル一覧を確認し、少なくとも次の3種類に分類します。
- 全ユーザーに利用を認めるモデル
- 特定のOrganizationまたはTeamだけに認めるモデル
- 利用を禁止するモデル
明確に禁止したいモデルは、既定ポリシーだけに頼らず、個別にDisabledと設定しておくと意図が分かりやすくなります。
未設定モデルを確認する
今回影響を受けるのは、明示的な判断をしていないモデルです。
「現在利用されていないから問題ない」ではなく、設定画面上でUnconfigured、Optionalまたは未追加になっているモデルがないかを確認してください。
変更内容を記録する
次の情報を社内の変更記録に残しておくと、後から設定意図を確認しやすくなります。
- 変更した日時
- 変更した管理者
- EnterpriseまたはOrganizationの対象範囲
- 変更前と変更後のポリシー
- 個別に有効・無効としたモデル
- 判断の根拠
- 次回の見直し日
GitHubは、ポリシー設定のドリフトを防ぐため、設定権限を持つユーザーの定期確認や監査ログによる変更確認を案内しています。(GitHub Docs)
利用者へ周知する
ポリシーの自動有効化は、全ユーザーの使用モデルを強制的に切り替える設定ではなく、対象モデルを「利用可能にするかどうか」を決める設定です。
ただし、新しいモデルが利用可能になれば、利用者がモデル選択画面などから選べる可能性があります。社内で利用モデルを指定している場合は、利用者向けのガイドも更新しておきましょう。
よくある設定ミス
8月26日から設定項目が表示されると思っている
設定項目は2026年7月29日から表示されています。8月26日は表示開始日ではなく、ポリシーが実際のモデル可否に反映され始める日です。(The GitHub Blog)
現在のモデルだけを確認して対応を終える
個別モデルをすべて確認しても、既定ポリシーがEnabledのままでは、今後リリースされる対象GAモデルが自動的に利用可能になります。
手動承認を維持する目的なら、個別設定だけでなくDefault availability for released modelsをDisabledにすることが重要です。
ポリシーをDisabledにすれば全モデルが無効になると思っている
Disabledへ変更しても、個別にEnabledと設定済みのモデルは引き続き有効です。すべてのモデルを見直す場合は、個別設定も確認してください。(The GitHub Blog)
OptionalをDisabledと同じ意味で扱う
Enterprise設定のOptionalは利用禁止ではありません。OrganizationまたはEnterprise Teamに判断を委ねる状態です。
Organization側で個別設定が行われていない場合、そのOrganizationの既定ポリシーがEnabledなら、対象モデルが利用可能になる可能性があります。(GitHub Docs)
除外対象だけを見て対応不要と判断する
オープンウェイトモデルやデータ保持契約の対象外モデルは自動有効化から除外されます。しかし、通常のGAモデルまで除外されるわけではありません。
承認制を維持したい組織では、モデルの種類にかかわらず既定ポリシーを確認する必要があります。
8月26日以降に確認すること
設定変更後は、8月26日以降に次の項目を確認します。
Default availability for released modelsが意図した値になっている- 以前の未設定モデルが
inherits defaultとして表示されている inherits defaultのモデルが既定ポリシーに従っている- 個別に
EnabledまたはDisabledとしたモデルの状態が維持されている - EnterpriseとOrganizationの設定に矛盾がない
- テストユーザーから利用可能なモデルが想定どおりである
- 設定変更が監査記録や社内台帳に残っている
8月26日以降でもポリシーは変更できます。inherits defaultは動的な状態であるため、ポリシーの変更は該当モデルに直ちに反映されます。(The GitHub Blog)
手動承認を続けるなら8月26日前にDisabledへ変更する
GitHub Copilot Business／Enterpriseでは、2026年8月26日から、未設定のGAモデルがDefault availability for released modelsポリシーを継承するようになります。
既定値はEnabledであるため、何もしなければ、対象となる既存の未設定GAモデルと今後の新規GAモデルが利用可能になります。一方、個別に設定済みのEnabled／Disabledは変更されません。(The GitHub Blog)
新しいモデルを管理者が審査してから公開する運用を続ける場合は、次の順序で対応してください。
- 8月26日より前に既定ポリシーを
Disabledへ変更する - 既存モデルの個別設定を棚卸しする
- EnterpriseとOrganizationの管理範囲を整理する
- 8月26日以降に
inherits defaultの状態を確認する - 今後のGAモデル発表を定期的に確認し、必要なモデルだけを明示的に有効化する
今回の変更は、モデルそのものの追加よりも、「未設定をどのように扱うか」という管理方式の変更です。承認制を採用している組織は、現在のモデル一覧だけでなく、将来追加されるモデルに対する既定ポリシーまで確認しておきましょう。
コメント