GitHubは2026年7月31日、Copilotのモデル公開範囲をenterprise team単位で調整できるpublic previewを発表しました。これまではorganization単位での制御が中心でしたが、今後は職種や検証段階ごとに許可モデルを出し分けやすくなります。特に2026年8月26日に既定モデルの自動有効化が始まる前に、どのチームへ何を開けるかを決めたい企業には影響が大きい変更です。
結論：全社一律から、職種別の段階導入へ切り替えやすくなった
今回のpreviewで一番大きい変化は、enterprise全体の基準モデルを決めたうえで、追加モデルだけを特定チームへ配れることです。たとえば全社では安定運用向けの標準モデルだけを開放し、R&DやAI推進室だけに新しい推論モデルや高コストモデルを追加する、といった設計がしやすくなります。これはPoC段階での先行検証と、本番部門でのコスト統制を両立しやすい設計です。
同日にGitHubはGemini 2.5 ProとGemini 3 Flashのdeprecatedも案内しており、代替モデルの有効化確認を管理者へ求めています。つまり、モデルの入れ替わりに合わせて『誰がどの代替モデルを使えるか』を即座に見直す運用が必要になってきました。新機能は単なるUI変更ではなく、モデル追加と廃止が速い時代のガバナンス基盤と捉えるべきです。
Copilotのモデル統制を部門別に設計し直したい場合は、利用ルールと承認フローを先に固めると後戻りが減ります。 AI・Claude研修や運用設計の相談はこちら
何が変わったのか：organization単位からenterprise team単位へ
従来はorganizationごとにモデル公開範囲を決める色が強く、同じorganization内でも開発基盤チームと業務アプリチームで要求が違う場合に細かい出し分けがしづらい状態でした。新previewではenterprise teams modeを有効化すると、モデルの可否判断はenterprise側とenterprise team側で行い、organizationレベルのモデル設定は適用されなくなります。GitHubはこの方式を、役割や訓練レベル、機能ごとの実態に近い制御だと説明しています。
ロールアウトは段階的で、多くのenterprise customerは2026年8月3日からpreview opt-inにアクセスできる予定です。今すぐ全社切り替えが始まるわけではありませんが、切り替え前にenterprise teamを作成し、Optionalモデルの割り当て準備だけ先に進められる点が実務上は重要です。
3つの状態をどう使い分けるか：Enabled・Disabled・Optional
GitHubが示した状態は3つです。Enabledはenterprise全員に開放、Disabledはenterprise全員で利用不可、Optionalはenterprise teamへ割り当て可能という意味です。運用イメージとしては、標準モデルをEnabled、高コストや検証中のモデルをOptional、契約や保持要件に合わないモデルをDisabledに置くと整理しやすいです。
注意点は、enterprise teams modeではleast-restrictive strategyが採用されることです。あるユーザーがどこか1つのenterprise teamからモデル利用権を受けると、そのユーザーはCopilotを使う場所全体でそのモデルへアクセスできます。つまり『特定リポジトリだけ』『特定organizationだけ』の閉じ方ではなく、『特定ユーザーに対する権限付与』として設計する必要があります。
8月26日のDefault availability policyとどうつながるか
GitHub Docsによると、2026年8月26日からは未設定のGAモデルがDefault availability for released models policyに従って自動的にenabledまたはdisabledへ寄ります。organization運用ではenterpriseがOptionalにしたモデルをorganization ownerが未設定のままにすると、この既定値の影響を受けます。一方、Docsは『enterprise teams model access previewにopt inしている場合はこの挙動が当てはまらない』と明記しています。
ここが既存記事との差分で、前日の『inherits default』整理だけでは不十分です。8月26日までに考えるべきことは、未設定モデルをどう扱うかだけではなく、previewへ移行した後に誰へどのOptionalモデルを割り当てるかです。新モデルを自動で広げたい企業と、先行チームだけで試したい企業では最適解が変わります。
導入前のチェックリスト：まず決めるべき4項目
1つ目は、全社共通で必ず使わせたい基準モデルです。2つ目は、Optionalで開ける先行検証モデルの候補です。3つ目は、コスト・データ保持・法務観点でDisabledにするモデルです。4つ目は、どのenterprise teamへ誰を入れるか、異動時の更新責任を誰が持つかです。少なくともこの4点を決めずにtoggleだけ有効化すると、権限の意図が追えず監査で苦労します。
実務では、開発生産性チーム・AI推進室・規制部門向け開発チームの3階層で切ると整理しやすいです。標準チームはEnabledのみ、推進室はOptionalモデルを複数試験、規制部門はdata residencyや保持条件に合うモデルだけを残す、という分け方です。GitHub Docsも、モデル利用可否はplan、client、enterpriseやorganizationの制限設定で決まると案内しているため、IDEごとの差も含めて配布ガイドを作ると混乱が減ります。
FAQ：管理者が詰まりやすいポイント
Q. enterprise teams modeを有効化するとorganization設定は残るのか。A. GitHub changelogでは、mode有効化後はorganization-level model settings no longer applyとされています。つまり、切り替え後の運用責任はenterprise側へ寄ります。
Q. 複数teamに所属するユーザーは最も厳しい制限に縛られるのか。A. 今回のpreviewではleast-restrictive strategyです。1つでもteamから権限を受ければ使えるため、兼務者を広い検証teamへ入れすぎないことが重要です。Q. 他enterpriseからもライセンスを受けている人はどうなるか。A. changelogでは、自社enterpriseのライセンスを使う場合は自社のmodel policiesだけが適用され、他enterpriseの制限は適用されないと説明されています。
まとめ：8月3日までに『モデル表』と『チーム表』を先に作る
今回のpreviewは、Copilotのモデル管理を技術設定から人の運用へ近づける変更です。発表日である2026年7月31日時点で分かっているのは、8月3日から多くのenterprise customerがopt-in可能になること、設定状態はEnabled・Disabled・Optionalの3つであること、organization単位の設定はmode有効化後に効かなくなること、そしてleast-restrictiveで権限が広がることです。8月26日の既定値変更も控えているため、今のうちにモデル一覧とenterprise team一覧を棚卸ししておく価値があります。
CopilotやClaude、ChatGPTを部門横断で安全に展開したい企業は、モデル選定と権限設計、研修を一体で設計したほうが失敗が少なくなります。 導入ルール整備やAI研修のご相談はこちら
