GitHub Copilotで既定モデルを enterprise-managed settings から固定できるようになり、2026年9月2日から新しい会話の初期モデルを企業側でそろえやすくなりました。今回の変更は、単に好みのモデルを選べるという話ではありません。高コストモデルの誤利用を減らす、用途別に既定値を分ける、教育済みチームだけに別の初期値を配る、といった運用設計に直結します。
結論: 既定モデル管理は「全社標準」と「チーム差分」を同時に扱えるようになった
GitHubの2026年9月2日付 changelog では、Enterprise-managed settings で任意の既定モデルを新規会話の初期値にできると案内されました。さらに team-mappings.json と teams 配下の設定ファイルを組み合わせることで、全社の既定モデルを持ちながら、開発部門だけ別モデルを使う構成も可能です。Copilot Business と Copilot Enterprise の両方が対象で、対応クライアントは GitHub Copilot app、Copilot CLI、Visual Studio Code です。
何が変わる？ 9月2日公開の変更点
これまでもモデルの利用可否は enterprise 側で管理できましたが、今回の更新で「新しい会話を開いたときに最初からどのモデルを選んだ状態にするか」を明示的に決めやすくなりました。GitHub Docs では managed-settings.json の top-level に model キーを置くこと、必要なら overridable 構文を使って enterprise team ごとに差分を持たせることが説明されています。つまり、標準は low-cost モデル、特定チームだけ frontier モデル、という配布が現実的になります。
対象読者: こんな管理者は優先して確認したい
特に確認優先度が高いのは、1. AI Credits や利用予算を抑えたい企業、2. チームごとに許可モデルを分けたい企業、3. CLI と VS Code と app の初期体験をそろえたい企業です。既定モデルが曖昧だと、ユーザーは毎回モデルを選ぶ必要があり、高価なモデルに流れたり、研修資料と実際の画面がずれたりします。今回の変更は、運用ルールを UI と設定ファイルに落とし込める点が実務的です。
モデル統制と現場の使いやすさを両立したい場合は、 HelloCraftAIに相談する ことで、権限制御・予算管理・社内展開まで含めて設計できます。
導入判断ポイント: team別上書きは便利だが、設計を誤ると混乱する
Docsでは、managed settings の優先順位が MDM 管理、server-managed、file-based、user-level の順で適用されるとされています。加えて team 上書きを使う場合、overridable にしたキーだけを teams ファイルで変更できます。ここで重要なのは、いきなり全部のチームに差分を持たせないことです。まず全社既定モデルを1つ決め、その上で高コストモデルを必要とするチームだけ team-mappings.json で分岐させる方が、教育・監査・サポートの手戻りを減らせます。
FAQ: 先に押さえるべき3つの疑問
Q1. どこで設定するのか。サーバー管理なら .github-private リポジトリの copilot/managed-settings.json を更新します。Q2. いつ反映されるのか。GitHub Docs ではサーバー管理設定はおおむね1時間以内に反映され、クライアント再起動や再サインインで即時更新を促せると案内されています。Q3. チームごとの差分はどう作るのか。model キーを overridable として定義し、copilot/team-mappings.json でチームと設定ファイルを結び、copilot/teams/ 配下にチーム別 JSON を置く流れです。
管理者チェックリスト
1. 2026年9月2日時点で自社が Copilot Business か Copilot Enterprise かを確認する。2. 既定モデルを1つ決め、用途別に分ける必要があるか判断する。3. enterprise teams を使うなら team-mappings.json と teams 配下の責任者を決める。4. 研修資料や社内FAQの初期モデル表記を更新する。5. 高コストモデルを既定化する前に、予算ルールと承認範囲を整理する。今回の変更は小さく見えて、社内の最初の利用体験を変える設定です。運用を標準化したい企業ほど、早めに見直す価値があります。
