Copilot のモデルポリシーをチーム単位で割り当て可能に、2026-08-03 までに大半へ提供

要約

GitHub Enterprise の管理者が、AI モデルのアクセスポリシーをチーム単位で設定できるようになりました。対象は Copilot Business または Copilot Enterprise のライセンスを持つエンタープライズで、public preview での提供です。

これまでモデルの可否は組織単位でしか決められませんでした。GitHub はこの変更を「役割、習熟度、機能といった実際の働き方に沿った、よりきめ細かいユーザー単位の制御」と説明しています。全員に同じモデルを配る前提が、実態と合っていなかったということです。

エンタープライズレベルでのモデル設定は3種類になります。Enabled はエンタープライズの全メンバーが利用できる状態。Disabled は誰も利用できない状態。そして Optional が今回の要点で、特定のエンタープライズチームに割り当てられる状態です。Enabled と Disabled の二値では表現できなかった「一部にだけ許す」を、Optional で扱えるようになりました。

複数チームに所属するユーザーの扱いは least-restrictive（最も制限の緩いものを採用）方式です。いずれかのチームでモデルが割り当てられていれば、そのユーザーはどこでもそのモデルを使えます。制限を厳しくする方向ではなく緩い方を採る設計なので、「あるチームで許可したモデルが、別チームでの作業にも持ち込まれる」ことになります。ここは意図を理解したうえで運用する必要があります。

有効化は Copilot Models 設定ページの「Enterprise teams mode」をトグルします。preview 期間中は、完全に切り替える前にエンタープライズチームを作成して Optional モデルを割り当てる準備を進められます。以前の構成へのロールバックも可能です。ロールアウトは 2026-08-03 までに大半の顧客へ提供されます。

何が変わったか

• モデルのアクセスポリシーをチーム単位で割り当てられるようになった（public preview）
• エンタープライズレベルの設定は Enabled / Disabled / Optional の3種類
• Optional のモデルを特定のエンタープライズチームへ割り当てられる
• 複数チーム所属時は least-restrictive 方式（いずれかで割り当てられていれば利用可）
• Copilot Models 設定ページの「Enterprise teams mode」トグルで有効化
• preview 期間中に、切り替え前の準備（チーム作成と Optional 割り当て）ができる
• 以前の構成へのロールバックが可能
• 対象: Copilot Business / Copilot Enterprise ライセンスを持つ GitHub Enterprise
• ロールアウト: 2026-08-03 までに大半の顧客へ

業務インパクト（一般企業向け）

この機能が解く問題は明確です。モデルの可否を組織全体で決めると、判断が最も保守的な部門に引きずられます。金融系の子会社があるから全社で新モデルを止める、といった状況です。チーム単位で割り当てられるなら、リスク許容度の異なる部門に別々のモデルセットを配れます。

もう1つの使い方は段階導入です。新しいモデルをまず一部のチームで Optional として試し、問題がなければ Enabled へ広げる。これまでも運用でやろうとすればできましたが、制度として組めるようになったのが違いです。preview 期間中に準備を進められる設計、ロールバックが可能という点も、慎重に進めたい組織には配慮された作りです。

2026-07-29 に発表されたデフォルトモデル有効化ポリシー（2026-08-26 発効）と組み合わせて考えるべき機能です。あちらは「GA になったモデルを既定でオンにするかどうか」という全体の既定値の話でした。こちらは「誰に何を割り当てるか」の話です。2軸が揃ったことで、たとえば「既定は有効にしておくが、特定ベンダーのモデルは Optional にして許可制にする」といった設計が可能になります。8月26日の発効までに方針を決める必要があるので、この2つは同時に検討するのが効率的です。

least-restrictive 方式については、運用前に理解しておくべき点です。あるチームで許可したモデルが、そのユーザーの別チームでの作業にも使えます。「機密性の高いプロジェクトのチームでは特定モデルを使わせない」という統制をしたい場合、この方式では実現できません。ユーザー単位で緩い方に寄るため、チームで縛るのではなくユーザーの所属設計で制御する必要があります。ここを誤解すると、意図した統制になりません。

導入の進め方としては、preview 期間を使って現状のチーム構成がモデル配布の単位として妥当かを確認するところからです。既存の GitHub チームは、コードの権限管理のために作られていることが多く、モデル配布の単位としては粒度が合わないことがあります。エンタープライズチームを新たに設計する必要があるかもしれません。

副業・個人活用視点

エンタープライズ向けの管理機能なので、個人契約には直接関係しません。ただし、企業に業務委託で入っている場合、8月以降に「案件によって使えるモデルが違う」という状況が生まれる可能性があります。あるクライアントでは Claude が使えるが、別のクライアントでは Gemini のみ、といった具合です。案件開始時に使えるモデルを確認する習慣を持っておくと、想定と違って手戻りする事態を避けられます。

least-restrictive 方式の帰結として、複数チームに所属していると想定より多くのモデルが使えることがあります。逆に言えば、使えるからといってその案件で使ってよいとは限りません。技術的に選択できることと、契約上許されることは別問題です。特に外部委託の立場では、この区別を自分で管理する必要があります。

支援する立場での視点では、この機能は具体的な提案材料になります。「モデルの可否を全社一律で決めると最も保守的な部門に引きずられる」という問題は、多くの企業で実際に起きています。チーム単位の割り当てという解決策が公式に用意されたことで、抽象論ではなく設定手順まで含めた提案ができます。2026-07-29 のデフォルト有効化ポリシーが 2026-08-26 に発効することもあり、8月は Copilot のガバナンス設計を見直す組織が増えるタイミングです。