先に結論
GitHub Copilot の targeted model rules preview は、新モデルを全社一括で開けるか、止めるか の二択を崩した更新です。
enterprise owner は、組織ごとに使わせるモデルを分けられるようになりました。Copilot Business / Enterprise を複数組織で運用しているなら、かなり実務的な更新です。
一番分かりやすい使い方は次の3段階です。
- 全社で既定にするモデルを決める
- org ごとに任せたいモデルは Optional に寄せる
- 先に試したい組織だけ targeted model rules で追加モデルを開ける
これなら、全社ルールを保ったまま pilot rollout を始められます。
何が変わったのか
2026年5月26日の GitHub Changelog で、enterprise owner が 組織ごとに許可モデルを分けられる targeted model rules を public preview として使えるようになりました。
同時に、enterprise 側の default model availability 画面も整理されています。GitHub の enterprise 向け docs では、各モデルを Enabled または Optional として管理できる形が明示されています。
要するに、変更点は2つです。
- enterprise 全体の既定モデルを前より見やすく管理できる
- 組織単位で例外ルールを足せる
この2つが揃ったことで、管理者は「標準は何か」と「どこまで例外を認めるか」を分けて考えやすくなりました。
誰に関係あるか
この更新の対象は、GitHub が changelog で案内している通り Copilot Business と Copilot Enterprise です。
特に関係が深いのは、次のような組織です。
- 複数 organization で GitHub を運用している
- AI 導入の温度差が部署ごとに違う
- 新モデルを一部の開発組織だけ先に試したい
- 情シスや platform team が標準ポリシーを持っている
逆に、個人利用の model picker を想像して読むと少しズレます。今回の主役は enterprise の管理運用 です。
Enabled と Optional はどう使い分けるべきか
今回いちばん大事なのは、targeted model rules そのものより Enabled と Optional の線引き です。
enterprise docs では、各モデルを次のどちらかで扱えます。
- Enabled: enterprise 配下の全組織で自動有効
- Optional: 組織ごとに有効化するかを選べる
さらに organization 向け docs では、enterprise owner が Optional にしたモデルだけ、org 管理者が Enabled / Disabled / Unconfigured を切り替えられると説明されています。
つまり、設計の順番はこうです。
1. 全社標準として必ず開けるモデルを決める
ここは Enabled です。全組織に共通で使ってよいモデルを置きます。
2. まだ判断を各 org に残したいモデルを Optional にする
ここは rollout の余地です。全社で禁止するほどではないが、自動で配り切るには早いモデルを置きます。
3. それでも足りない対象だけ targeted model rules を使う
特定組織だけ先に追加モデルを開けたいときに使います。preview の価値はここにあります。
targeted model rules が効く場面
targeted model rules は、全社一律のポリシーを捨てる機能ではありません。標準ポリシーの上に、限定的な例外を重ねる機能 と見たほうが分かりやすいです。
たとえば、次のような場面で効きます。
開発部門だけ新モデルを先に試したい
全 organization へ一気に広げず、開発生産性チームや platform team がいる組織だけ先に開ける使い方です。社内説明もしやすく、失敗しても巻き戻しやすいです。
規制や顧客監査が重い組織を後ろに回したい
同じ enterprise の中でも、まずは通常の開発組織から始め、 regulated な組織は後で見直す運用ができます。
責任分界を残したまま pilot したい
enterprise owner が全体方針を持ちつつ、実際に使うかどうかは特定 org 管理者へ委ねる形を取りやすくなります。
今すぐ見直したい rollout パターン
今回の更新を見て最初にやるべきなのは、モデルを増やすことではありません。今の標準モデル設計を棚卸しすること です。
おすすめは次の順です。
パターン1. 標準モデルを先に固定する
まず、全 organization に自動で開けるモデルを決めます。これが曖昧なまま targeted rule を増やすと、例外のほうが本体になります。
パターン2. Optional 枠を少数に絞る
org 側で判断を任せるモデルを増やしすぎると、結局どこで何が開いているか追いにくくなります。Optional は本当に判断を残したいモデルだけに絞るほうが安全です。
パターン3. targeted rule は pilot 用から始める
preview の段階では、まず一部 organization に限定して使うのが無難です。成果が見えたあとで広げるほうが、社内説明も楽です。
Copilot のモデル承認を土台から整理したいなら、GitHub Copilot Business / Enterprise のモデル承認ガイド も先に見ておくと判断しやすくなります。
管理者向けチェックリスト
設定を開く前に、次の4点だけ確認しておくと迷いにくいです。
- 全社標準で自動有効にするモデルは何か
- 組織判断に残す Optional モデルはどれか
- targeted rule を最初に当てる pilot 組織はどこか
- 例外ルールをいつ見直すか
この4点が決まっていれば、preview 機能に振り回されにくくなります。
いま読む価値がある理由
今回の更新は、派手な新モデル追加ではありません。それでも価値が高いのは、Copilot の enterprise 導入でいつも詰まりやすい「広げ方」の問題に直接効く からです。
モデル比較だけでは、全社 rollout は進みません。どこに先に開けるか、どこはまだ開けないか、その中間を作れる管理機能のほうが、むしろ購買や継続利用に効きます。
Copilot の rollout 設計をもう少し広く見たい場合は、GitHub Copilot Cloud Agent rollout guide や GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ も合わせてどうぞ。