GitHub Copilotモデルを部門や職種ごとに使い分けたい場合、Enterprise全体やOrganization単位の設定だけでは、必要なユーザーへ細かく割り当てるのが難しいことがあります。
この課題に対応するため、GitHubは2026年7月31日、GitHub Copilot Business／Enterpriseを対象に、Enterprise Teamsを使ってモデル利用可否をユーザー単位で制御する機能をパブリックプレビューとして発表しました。段階的に展開され、多くのEnterprise顧客には同年8月3日にオプトインを提供する予定と案内されています。(The GitHub Blog)
設定の要点は、全員向けのモデルを「Enabled」、全員禁止のモデルを「Disabled」、一部ユーザーだけに許可するモデルを「Optional」にすることです。ただし、複数チームに所属するユーザーには、各チームから与えられた権限が加算されます。どこか1つのチームがモデルを許可すれば、そのユーザーは利用可能になるため、従来のOrganization単位の考え方をそのまま移行すると、意図しない許可や利用停止が起こる可能性があります。
GitHub CopilotのEnterprise Teamsモデルポリシーとは
Enterprise Teamsモデルポリシーは、GitHub Enterprise CloudのEnterpriseアカウント内に作成したチームを使い、特定のユーザーグループへGitHub Copilotモデルを割り当てる仕組みです。
従来は、Enterprise全体の設定に加えて、Organizationごとにモデルの利用可否を判断するのが基本でした。Enterprise Teams modeを有効にすると、詳細なモデル制御の単位がOrganizationからEnterprise teamへ切り替わります。
対象となる主な条件は次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象環境 | GitHub Enterprise Cloud |
| 対象プラン | GitHub Copilot Business、GitHub Copilot Enterprise |
| 設定できるユーザー | Enterprise owner |
| 提供状況 | オプトイン方式のパブリックプレビュー |
| 制御単位 | Enterprise全体およびEnterprise team |
| 主な用途 | 職種、研修受講状況、検証チーム、業務要件に応じたモデル割り当て |
ここでいうEnterprise teamは、個別のOrganization内に作成する通常のTeamとは異なり、Enterpriseアカウント全体でユーザーをまとめるためのチームです。Enterprise teamには、Copilotモデルのほか、ライセンスやEnterpriseロールなども割り当てられます。(GitHub Docs)
なお、モデルポリシーでモデルを許可しても、それだけでCopilotライセンスが付与されるわけではありません。利用者には、対象Enterpriseから有効なGitHub Copilot BusinessまたはCopilot Enterpriseライセンスが割り当てられている必要があります。
Enabled・Disabled・Optionalの違い
Enterpriseレベルでは、各GitHub Copilotモデルに対して次の3状態を設定します。
| 状態 | 利用できるユーザー | 適した使い方 |
|---|---|---|
| Enabled | Enterprise内の全対象ユーザー | 全社標準として認めたモデル |
| Disabled | Enterprise内の全ユーザーが利用不可 | コンプライアンスや社内基準で禁止するモデル |
| Optional | 指定したEnterprise teamのメンバー | 検証中、高機能、研修修了者向けなどの限定モデル |
Enterprise全体で共通利用するモデルはEnabled、誰にも使わせないモデルはDisabled、一部のユーザーだけに使わせるモデルはOptionalにします。Optionalにしたモデルは、Enterprise teamの「Default models」設定から対象チームへ追加します。(The GitHub Blog)
EnterpriseのDisabledはチームから上書きできない
Enterprise teamのモデル設定は、Enterprise全体の設定に対する「追加許可」として働きます。
そのため、次のルールが適用されます。
| Enterpriseの設定 | チームの設定 | 最終結果 |
|---|---|---|
| Enabled | 未設定またはOptional | 利用可能 |
| Disabled | Enabledにしようとしても不可 | 利用不可 |
| Optional | チームでEnabled | 利用可能 |
| Optional | チームでOptional | 利用不可 |
EnterpriseでDisabledにしたモデルを、特定のチームだけEnabledにすることはできません。反対に、EnterpriseでEnabledにしたモデルを、特定チームだけ利用禁止にすることもできません。
つまり、Enterpriseレベルの設定が基本となり、Enterprise teamはOptionalモデルを追加するために使います。(GitHub Docs)
チームには明示的なDisabledがない
Enterprise team側のモデル設定には、モデルを明示的に拒否するためのDisabledがありません。
チーム側では、実質的に次の2状態を使います。
| チーム側の状態 | 意味 |
|---|---|
| Enabled | そのチームのメンバーへモデルを追加許可する |
| Optional | そのチームからはモデルを許可しない |
チーム側のOptionalは、「Enterprise teamへ割り当て可能」というEnterprise側のOptionalとは意味が少し異なります。チームの設定画面では、Optionalはそのチームに現在付与していない状態を表します。(GitHub Docs)
「最も制限の少ない評価方式」の意味
Enterprise Teamsモデルポリシーで特に注意したいのが、GitHubが「least-restrictive strategy」と説明している評価方式です。
これは複数のEnterprise teamに所属するユーザーについて、各チームが持つ許可の和集合を適用するという意味です。
たとえば、次のユーザーを考えます。
- 開発部チームでは「モデルA」がOptional
- AI検証チームでは「モデルA」がEnabled
- ユーザーは両方のチームに所属
この場合、AI検証チームからモデルAが付与されるため、ユーザーはモデルAを利用できます。開発部チーム側で許可されていなくても、利用権限は取り消されません。
| 所属チーム | モデルAの設定 |
|---|---|
| 開発部 | Optional |
| AI検証チーム | Enabled |
| ユーザーの最終状態 | 利用可能 |
ここで重要なのは、「最も制限の少ない評価方式」は最小権限の原則とは異なることです。
権限を絞るチームを作るのではなく、必要な権限を追加するチームを作る仕組みです。あるチームで許可されたモデルを、別のチームから拒否することはできません。(The GitHub Blog)
モデル利用はチームに対応するリポジトリだけに限定されない
Enterprise teamからモデルを付与されたユーザーは、そのモデルをユーザー単位で利用できるようになります。
モデル利用可否は、特定のOrganizationやリポジトリだけに閉じた権限ではありません。いずれかのEnterprise teamからモデルを付与されると、そのEnterpriseのCopilotライセンスを使用する範囲全体でモデルへアクセスできます。(The GitHub Blog)
そのため、「特定プロジェクトだけでモデルを使わせる」といったリポジトリ単位の制御を、Enterprise Teamsモデルポリシーだけで実現することはできません。
Enterprise Teams modeを有効にすると何が変わるか
Enterprise Teams modeを有効にすると、Organizationレベルのモデル設定は無効化されます。
| 項目 | 有効化前 | 有効化後 |
|---|---|---|
| 詳細なモデル制御単位 | Organization | Enterprise team |
| Organization ownerによるモデル管理 | 可能 | 不可 |
| Organizationレベルのモデル設定 | 適用される | 適用されない |
| EnterpriseレベルのEnabled／Disabled | 適用される | 引き続き適用される |
| Optionalモデルの追加許可 | Organizationまたは対象ルール | Enterprise team |
Enterprise Teams modeを有効にした後は、Organization ownerがモデルポリシーを変更できなくなります。既存のOrganization設定やOrganizationを対象とするモデルルールも、モデル利用可否の判断には使われません。(GitHub Docs)
Optionalや未設定のモデルが突然使えなくなる可能性がある
移行時に最も起こりやすい問題は、これまでOrganization側で許可されていたモデルが利用できなくなることです。
EnterpriseでOptionalまたは未設定になっているモデルは、Enterprise Teams modeへ切り替えた後、対象のEnterprise teamでEnabledにしない限り利用できません。(GitHub Docs)
たとえば、移行前に次の構成だったとします。
- EnterpriseではモデルAがOptional
- Organization XではモデルAがEnabled
- 開発者はOrganization Xに所属
Enterprise Teams modeを有効にすると、Organization XのEnabled設定は適用されなくなります。モデルAを許可したEnterprise teamへ開発者を追加していなければ、モデルAは利用できなくなります。
そのため、先にEnterprise Teams modeを有効にし、後からチームを作る進め方は避けるべきです。
Enterprise Teamsモデルポリシーへの移行手順
現在のモデル設定を記録する
最初に、Enterpriseと各Organizationで現在使われているモデル設定を整理します。
最低限、次の情報を表やスクリーンショットで記録してください。
- Enterpriseレベルの各モデルの状態
- Organizationごとのモデル設定
- Organizationを対象にしたモデルルール
- 各モデルを実際に利用している部門やユーザー
- モデル利用に社内承認や研修が必要か
- 複数のEnterpriseに所属するユーザー
- Copilotライセンスの付与元
この記録は、移行後の比較だけでなく、ロールバック時にも必要になります。
モデルを3種類に分類する
各モデルを、次の判断基準で分類します。
| 分類 | Enterprise設定 | 判断例 |
|---|---|---|
| 全員に許可 | Enabled | 社内検証済みで、全従業員が利用してよい |
| 全員禁止 | Disabled | 契約、データ処理、社内基準などの理由で禁止 |
| 条件付き許可 | Optional | 検証担当者、特定職種、研修修了者だけに許可 |
Enterprise Teams modeでは、EnterpriseのEnabledとDisabledが強い基準になります。
後からチーム単位で絞り込むことはできないため、迷うモデルを安易にEnabledへ設定しないことが重要です。一部ユーザーだけに利用させる可能性がある場合はOptionalにします。
権限追加型のEnterprise teamを作る
Enterprise teamは、組織図をそのまま再現するより、付与するモデル権限を基準に設計したほうが管理しやすくなります。
たとえば、次のようなチームです。
- 先行モデル検証メンバー
- 高度モデル利用承認者
- AI研修修了者
- 特定業務向けモデル利用者
反対に、次のような拒否目的のチームは機能しません。
- モデル利用禁止者
- 高度モデル除外ユーザー
- 開発部モデル制限チーム
別のチームからモデルを付与されれば利用できるため、「禁止するチーム」ではなく「許可するチーム」を作ります。
各チームには、説明欄などを使って次の情報を残しておくと運用しやすくなります。
- チームの目的
- 付与するモデル
- メンバー追加の承認条件
- 所管部門
- 定期見直しの時期
Enterprise teamへユーザーを追加する
Enterprise teamの作成場所は、Enterprise画面の「People」から「Enterprise teams」です。
ユーザーは手動で追加できるほか、REST APIによる管理にも対応しています。Enterprise Managed Usersを使用している環境では、IdPグループとEnterprise teamを同期し、SCIM経由でメンバー変更を反映できます。(GitHub Docs)
人数が多い環境では、手動登録よりもIdPグループやAPIで管理したほうが、退職・異動・職務変更時の削除漏れを防ぎやすくなります。
Enterprise側で対象モデルをOptionalにする
Enterpriseのモデル設定は、公式ドキュメントでは次の手順で開きます。
- 対象のEnterpriseを開く
- 「AI controls」を選択する
- サイドバーから「Copilot」を選択する
- 「Configure models」を開く
- 必要なモデルを追加する
- 各モデルをEnabled、Disabled、Optionalのいずれかに設定する
特定のEnterprise teamだけに付与するモデルは、Enterprise側でOptionalにしておく必要があります。(GitHub Docs)
チームのDefault modelsでモデルを有効にする
次に、作成したEnterprise teamの設定を開きます。
- 対象のEnterprise teamを開く
- 「Default models」タブを選択する
- 追加許可するモデルをEnabledにする
- 付与しないモデルはOptionalのままにする
Enterprise Teams modeを有効にする前でも、チームの作成やモデル割り当ての準備は可能です。ただし、この段階ではチームのモデル設定はまだユーザーへ適用されません。(The GitHub Blog)
移行前に割り当て表を確認する
切り替え前に、少なくとも次のパターンを確認します。
| テスト対象 | 確認内容 |
|---|---|
| EnterpriseのEnabledモデルだけ使うユーザー | 標準モデルを引き続き利用できるか |
| Optionalモデル付与チームのユーザー | 対象モデルを利用できるか |
| 複数チーム所属ユーザー | 各チームのモデルがすべて加算されても問題ないか |
| どの付与チームにも属さないユーザー | Optionalモデルが利用不可でよいか |
| 複数Enterprise所属ユーザー | Copilotライセンスの付与元が正しいか |
特に、複数チーム所属者の確認が重要です。本人の所属部門だけを見るのではなく、プロジェクトチーム、検証チーム、兼務先などを含めて確認します。
Enterprise Teams modeを有効にする
準備が完了したら、次の場所からオプトインします。
- Enterpriseの「AI controls」を開く
- 「Copilot」を選択する
- 「Enterprise teams mode」のトグルを有効にする
有効化した時点から、Organizationレベルのモデル設定が適用されなくなり、EnterpriseとEnterprise teamを使ったモデル制御へ切り替わります。(The GitHub Blog)
切り替え後は、想定したユーザーでGitHub Copilotのモデル選択画面を確認します。許可対象者だけでなく、本来許可されないユーザーでも確認し、過剰付与がないかを検証してください。
移行前に確認したいチェックリスト
| 確認項目 | 完了 |
|---|---|
| 現在のEnterpriseモデル設定を記録した | □ |
| Organizationごとのモデル設定を記録した | □ |
| 各モデルをEnabled、Disabled、Optionalに分類した | □ |
| Optionalモデルごとの付与チームを作成した | □ |
| 現在の利用者を適切なチームへ追加した | □ |
| 複数チーム所属による権限の加算を確認した | □ |
| Optionalのまま割り当て先がないモデルを確認した | □ |
| 複数Enterprise所属者のライセンス付与元を確認した | □ |
| 切り替え前の設定状態を保存した | □ |
| ロールバックの判断基準を決めた | □ |
パブリックプレビュー中のロールバックに注意する
Enterprise Teams modeは、パブリックプレビュー中であればロールバックできます。
ロールバックすると、オプトイン前に使っていたOrganizationベースのポリシー状態へ戻ります。ただし、Enterprise Teams modeへ切り替えた後に変更したEnterpriseレベルのモデルポリシーは、ロールバック後に保持されません。(GitHub Docs)
たとえば、切り替え後にモデルAをOptionalからDisabledへ変更しても、ロールバックすると、切り替え前の状態へ戻る可能性があります。
安全に運用するため、次の対策を取ります。
- オプトイン直前の設定を保存する
- 切り替え後の変更履歴を別途記録する
- ロールバック後に再設定が必要な項目を整理する
- ロールバック条件と判断者を決める
- 本番切り替え直後に大規模なモデル変更を重ねない
ロールバックは、変更内容を自動的に統合してくれる機能ではありません。あくまで切り替え前のポリシーへ戻すための安全策として考える必要があります。
複数Enterprise所属ユーザーに適用されるポリシー
Enterprise Managed Usersを使用していない環境では、1人のGitHubユーザーが複数のEnterpriseに所属し、それぞれからCopilotライセンスを付与されるケースがあります。
Enterprise Teams modeでは、ユーザーが現在利用しているCopilotライセンスを付与したEnterpriseのモデルポリシーだけが適用されます。他のEnterpriseが設定した制限は合算されません。(The GitHub Blog)
たとえば、次の構成を考えます。
| 項目 | Enterprise A | Enterprise B |
|---|---|---|
| モデルX | Enabled | Disabled |
| ユーザーの所属 | 所属 | 所属 |
| 使用中のCopilotライセンス | Enterprise Aから付与 | 使用していない |
この場合、モデルXにはEnterprise Aのポリシーが適用され、ユーザーは利用可能です。Enterprise BのDisabled設定は適用されません。
複数Enterpriseに所属するユーザーのアクセス結果が想定と異なるときは、所属先だけでなく、どのEnterpriseが現在のCopilotライセンスを付与しているかを確認してください。
Enterprise Teamsモデルポリシーで起こりやすい設定ミス
Optionalにすれば自動的に一部ユーザーが使えると思っている
Optionalは、自動的に一部ユーザーへモデルを公開する設定ではありません。
Enterprise Teams modeでは、Enterprise側でOptionalにしたうえで、対象Enterprise team側をEnabledにする必要があります。付与先チームがなければ、そのモデルは利用できません。
Organization設定を残しておけば併用できると思っている
Enterprise Teams modeを有効にすると、Organizationレベルのモデル設定は適用されません。
移行後もOrganization設定画面の内容を前提に運用すると、管理者の認識と実際のアクセス結果がずれる可能性があります。
制限用のチームを作っている
チーム側には明示的なDisabledがなく、他のチームから付与されたモデルを拒否できません。
モデルを使わせたくないユーザーについては、許可チームから外す必要があります。Enterprise全体で禁止する場合は、Enterprise側をDisabledにします。
兼務チームを確認していない
複数チームのモデル権限は加算されます。
所属部門のチームでは許可していなくても、検証プロジェクトや兼務先のチームからモデルが付与されていれば利用可能です。アクセスレビューでは、ユーザーが所属するすべてのEnterprise teamを確認します。
ロールバックすれば切り替え後の変更も残ると思っている
ロールバックでは、オプトイン後に変更したEnterpriseモデルポリシーが保持されません。
切り替え後に行った変更を再現できるよう、変更日時、対象モデル、変更前後の状態、変更理由を記録してください。
Enterprise Teamsモデルポリシーを安全に運用するポイント
GitHub CopilotモデルをEnterprise Teams単位で制御する場合は、Enterprise teamを単なる部署名簿として扱うのではなく、モデル利用権限を付与するグループとして設計することが重要です。
まず、全員向けのモデルをEnabled、全員禁止のモデルをDisabled、一部ユーザー向けをOptionalに分類します。次に、Optionalモデルを許可するEnterprise teamを作り、対象ユーザーを割り当てます。
その際は、複数チームの許可が加算されること、Enterprise Teams mode有効化後はOrganization設定が適用されないこと、ロールバック時に切り替え後のEnterprise設定変更が保持されないことを必ず確認してください。
最初に行うべき作業は、現在のOrganization別モデル設定と利用者の一覧化です。そのうえでEnterprise teamへの割り当てを完成させ、テストユーザーで権限の過不足を確認してからEnterprise Teams modeを有効にするのが、安全な移行手順です。
コメント