GitHubは2026年9月2日、エンタープライズ管理設定（enterprise-managed settings）を通じて、GitHub Copilotの新しい会話における既定モデルを、任意のモデルから選べるようにしたと発表しました。従来もエンタープライズ管理者が既定モデルを指定する仕組み自体は存在していましたが、これまで一定のモデルに限られていたエンタープライズ管理設定の既定モデル指定が、任意のGitHub Copilotモデルに対応しました。 組織のワークフローに最も適したモデルを、管理者側の判断で全社に行き渡らせられるようになったことになります。
背景には、2026年9月に入ってからのGitHub Copilotのモデルラインアップの急速な入れ替わりがあります。9月1日にはClaude Opus 4.5／4.6、Claude Sonnet 4.5／4.6、Gemini 3.1 Pro、Raptor Miniの6モデルが提供終了となる一方、同じ9月1日にAnthropicのClaude Fable 5.1がGA、9月3日にはGoogleのGemini 3.8 Flashが利用可能になるなど、モデルの新陳代謝がこれまで以上に激しくなっています。選択肢が増えるほど、ユーザー任せのモデル選定では組織としての一貫性やコスト管理が難しくなるため、今回の機能拡張は実務上のニーズに沿ったものといえます。
何ができるようになったのか
全社共通の既定モデルを一元設定
エンタープライズ管理者は、managed.jsonファイル内のmodelキーを書き換えるだけで、組織に所属する全ユーザーの新規会話における既定モデルを変更できます。GitHubが公開した設定例のスクリーンショットでは、既定モデルのキーを「Kimi 3」に置き換える様子が示されており、公式の設定例では、managed.json内のmodelキーの値を「Kimi 3」に置き換えるだけで、全社の既定モデルを切り替えられることが示されています。 OpenAI・Anthropic・Google系のモデルに限らず、Copilotのモデルピッカーに登場する幅広いモデルが対象になっていることがうかがえます。
チーム単位でのオーバーライドにも対応
すべての部署やチームが同じモデルを最適とは限りません。今回の更新では、組織全体の既定値とは別に、チームごとに異なる既定モデルを割り当てる仕組みも用意されました。モデルキーをoverridableに設定し、team-mappings.jsonでチーム設定ファイルを更新することで、エンタープライズチームごとに異なる既定モデルを割り当てられます。それ以外のユーザーは、組織全体の既定モデルを継承します。 たとえば、コード生成中心のエンジニアリングチームには推論力の高いモデルを、ドキュメント作成や問い合わせ対応が中心のチームには低コストなFlash系モデルを、といった使い分けが管理者側の設定だけで実現できます。
対応環境とプラン
モデルの既定設定は、GitHub CopilotアプリケーションやCopilot CLI、Visual Studio CodeにおいてCopilot BusinessおよびCopilot Enterpriseで一般提供されています。 個人向けプランは対象外で、あくまで組織単位でCopilotを管理しているBusiness・Enterprise契約が前提となる点には注意が必要です。対応クライアントは順次拡大していく可能性があるため、自社で利用している開発環境が対象に含まれているかは、導入前に公式ドキュメントで確認しておくとよいでしょう。
設定手順の実装ガイド
managed.jsonでの基本設定
エンタープライズ管理設定は、GitHub Enterprise Cloudの管理者がリポジトリ経由で配布するJSON形式の設定ファイル群で制御します。既定モデルを変更する場合は、managed.json内のmodelキーに、使用したいモデルの識別子を指定します。設定を反映させるには、通常のエンタープライズ管理設定と同様、変更をコミットして配布用リポジトリに反映させる流れになります。反映後は、対象ユーザーが新しい会話を開始した際に、指定したモデルが既定として選択された状態になります。
team-mappings.jsonでのチーム別オーバーライド
チームごとに既定モデルを分けたい場合は、まずmanaged.json側でmodelキーをoverridable（上書き可能）に設定します。そのうえで、team-mappings.jsonにチームとモデルの対応関係を記述することで、該当チームに所属するメンバーだけ異なる既定モデルが適用されるようになります。チームマッピングに含まれないユーザーは、引き続き組織全体の既定モデルを継承する仕組みなので、既存の全社設定を崩さずに一部チームだけ例外を作れるのが実務上のメリットです。
反映確認と運用上の注意点
設定変更後は、対象クライアント（Copilotアプリ、Copilot CLI、VS Code）それぞれで、実際に新規会話の既定モデルが意図した通りに切り替わっているかを確認することをおすすめします。クライアントによって設定の反映タイミングにズレが生じる場合があるため、全社展開の前に一部チームや検証用アカウントで先行確認を行うと、トラブルを未然に防ぎやすくなります。また、ユーザー自身がモデルピッカーから別のモデルを都度選び直すこと自体は引き続き可能で、あくまで「何も選ばなかったときにどのモデルが使われるか」を管理者が制御する機能である点も押さえておきたいポイントです。
なぜ今この機能が重要なのか
モデル選択肢の急増とコスト・品質のトレードオフ
前述の通り、GitHub Copilotでは9月だけでも複数のモデルが入れ替わっています。すでに当サイトでも報じたGitHub Copilotの旧モデル6種提供終了のように、モデルは定期的に非推奨化されていきます。ユーザー各自の判断に既定モデルの選定を委ねてしまうと、非推奨化のたびに個々のユーザーが対応を迫られ、組織としての利用実態やコストの把握も難しくなります。エンタープライズ管理設定で既定モデルを一元的にコントロールできれば、モデルの入れ替わりに組織として計画的に追従しやすくなります。
9月に相次ぐポリシー変更との関連
今回の機能拡張は単独の出来事ではなく、GitHubが2026年9月に予定している一連のCopilotポリシー・課金変更の流れの中に位置づけられます。当サイトで既に取り上げたGitHub Copilotの料金・ポリシー変更では、Business・Enterprise新規申込の再開とシート課金の見直し、Copilot Chatの体験統合、コードレビューの既定エフォート変更という3つの変更を解説しましたが、今回の既定モデル設定の拡充もあわせて、管理者がCopilotの挙動を細かく制御できるようにする一連の取り組みの一部と捉えると理解しやすくなります。
新モデルをどう既定に組み込むか
Claude Fable 5.1のように、既定でデータ保持が必要になるなど、これまでのモデルと運用条件が異なるモデルも登場しています。既定モデルとして設定する際には、単に性能やコストだけでなく、こうしたデータの取り扱いポリシーも含めて検討する必要があります。実際にClaude Fable 5.1を組織で利用する場合の注意点は、当サイトのGitHub CopilotでClaude Fable 5.1が利用可能にでも詳しく解説しているので、既定モデルの候補として検討する際にはあわせて確認することをおすすめします。
導入時の注意点・トラブルシューティング
設定が反映されない場合のチェックポイント
既定モデルの変更がユーザー側の環境に反映されない場合、まず確認すべきはmanaged.jsonの構文エラーや、配布用リポジトリへの反映漏れです。エンタープライズ管理設定は他の項目と同様、設定ファイルの記述ミスがあると意図しない挙動になることがあるため、変更後は必ず対象クライアントで動作確認を行いましょう。また、クライアントごとにキャッシュの更新タイミングが異なる場合があるため、反映まで時間差が生じることも想定しておく必要があります。
継承ルールの理解
team-mappings.jsonによるチーム別オーバーライドを使う場合、優先順位を正しく理解しておくことが重要です。チームマッピングで明示的に指定されたチームのメンバーには、そのチーム用の既定モデルが適用され、それ以外のユーザーには組織全体の既定モデルが適用されます。複数のチームに所属するユーザーがいる場合の優先順位など、細かな挙動については公式ドキュメントを確認しながら設計するのが安全です。
モデル非推奨化を見据えた運用
GitHub Copilotのモデルは今後も定期的に非推奨化されていくと見込まれます。既定モデルとして特定のモデルを指定した場合、そのモデルが提供終了になれば既定設定も見直しが必要になります。エンタープライズ管理者としては、既定モデルの設定を一度作って終わりにするのではなく、GitHubのChangelogを定期的に確認し、モデルのライフサイクルにあわせて設定を更新していく運用体制を組んでおくことが望まれます。
まとめ
GitHub Copilotのエンタープライズ管理設定が、任意のモデルを既定に指定できるように拡張されたことで、組織はCopilotの利用体験をこれまで以上に細かくコントロールできるようになりました。全社共通の既定モデル設定に加え、team-mappings.jsonを使ったチーム単位のオーバーライドも可能になったため、部署ごとの業務特性に応じたモデル選定が管理者側の設定だけで実現できます。9月に相次いだモデルの入れ替わりや関連するポリシー変更とあわせて、自社のCopilot運用ルールを見直す良いタイミングといえるでしょう。
参考サイト
- GitHub Changelog「Enterprise-managed settings support any default model」
- GitHub Changelog「Upcoming changes to GitHub Copilot policies and billing」
- GitHub Changelog「Selected GitHub Copilot models deprecated」
- GitHub Changelog「Claude Fable 5.1 is generally available in GitHub Copilot」
- GitHub Changelog「Gemini 3.8 Flash is now available in GitHub Copilot」
- GitHub Docs「Enterprise managed settings reference」
