GitHub の「Enterprises can default to auto model selection」は、企業管理者が GitHub Copilot の新しい会話で「Auto model selection」を既定値にできる更新です。結論から言うと、開発者に特定モデルの選択を毎回任せるのではなく、Copilot 側にタスク内容や利用可能性を踏まえたモデル選択を任せやすくするための管理機能です。ただし、これはモデル選択を完全に固定する機能ではありません。ユーザーは会話ごとに別のモデルへ切り替えられます。(The GitHub Blog)
この変更は、GitHub Copilot を組織・エンタープライズ単位で管理している企業にとって重要です。特に、Copilot Business や Copilot Enterprise を導入している環境では、モデル選択のばらつきを減らしつつ、開発者の使い勝手を落とさない運用設計がしやすくなります。この記事では、2026年7月1日に公開された GitHub 公式情報をもとに、管理者・開発者・一般ユーザーが確認すべきポイントを実務目線で整理します。(The GitHub Blog)
GitHub の新機能・変更点：「Enterprises can default to auto model selection」で何が変わるのか
今回の更新では、Enterprise 管理者が managed-settings.json の permissions.model に "auto" を指定することで、GitHub Copilot の新しい会話を Auto model selection で開始できるようになりました。対象になるのは、企業アカウントを通じて Copilot Business または Copilot Enterprise のライセンスを受けているユーザーです。(The GitHub Blog)
Auto model selection は、ユーザーが手動でモデルを選ぶ代わりに、Copilot がタスクの内容、モデルの状態、利用可能性などを踏まえて適切なモデルを選ぶ仕組みです。GitHub の説明では、タスクの複雑さやリアルタイムのシステム状態を考慮し、より効率よくモデルをルーティングする仕組みとして位置付けられています。(GitHub Docs)
| 観点 | これまで | 今回の更新後 |
|---|---|---|
| 新しい Copilot 会話のモデル | ユーザーやクライアント側の設定に依存しやすい | Enterprise 管理者が Auto model selection を既定値にできる |
| 管理者の制御範囲 | ポリシーやモデル利用可否の管理が中心 | managed-settings.json で既定モデルの方針も配布できる |
| 開発者の操作 | モデル選択に迷う場面がある | 新規会話は Auto で始まり、必要に応じて手動変更できる |
| 強制力 | モデルの利用可否は管理ポリシーで制御 | 今回の設定は既定値の変更であり、会話ごとの切り替えは可能 |
実務上のポイントは、「Auto に固定する」のではなく「Auto から始める」設定だという点です。高性能な推論モデルを明示的に使いたい場面や、検証目的で別モデルを比較したい場面では、開発者が会話単位でモデルを切り替えられます。(The GitHub Blog)
Auto model selection とは何か
Auto model selection は、GitHub Copilot がタスクに応じてモデルを自動選択する機能です。GitHub 公式ドキュメントでは、単なるモデルピッカーではなく、品質、信頼性、判断負荷の軽減を目的にした仕組みとして説明されています。(GitHub Docs)
具体的には、次のような狙いがあります。
| 目的 | 実務での意味 |
|---|---|
| タスクに合うモデルを選ぶ | 簡単な質問には高速・低コスト寄りのモデル、複雑な問題にはより適したモデルが選ばれやすくなる |
| モデルの状態を考慮する | 一部モデルの負荷や利用状況に左右されにくくなる |
| 開発者の判断負荷を減らす | 「この作業にはどのモデルがよいか」を毎回考えなくてよい |
| コスト効率を高める | 必要以上に高コストなモデルを使い続ける状況を避けやすい |
GitHub は、Auto model selection が利用できるモデルは契約プランや管理者ポリシーの影響を受けると説明しています。つまり、管理者が利用不可にしているモデルや、プラン上使えないモデル、データレジデンシーや FedRAMP 関連の制約で除外されるモデルは、自動選択の候補にも含まれません。(GitHub Docs)
この点は企業利用で特に重要です。Auto にしたからといって、組織のポリシーを無視して任意のモデルが使われるわけではありません。既存のモデル利用ポリシーやサブスクリプション条件の範囲内で、自動選択されると理解しておくのが安全です。
管理者が設定する場所：managed-settings.json の基本
今回の設定は、Enterprise の .github-private リポジトリに配置する managed-settings.json で管理します。GitHub 公式ドキュメントでは、現在の標準パスとして .github-private リポジトリ内の copilot/managed-settings.json が示されており、従来の .github/copilot/settings.json も後方互換としてサポートされています。(The GitHub Blog)
最小構成は次のようになります。
{
"permissions": {
"model": "auto"
}
}managed-settings.json は、Copilot CLI や VS Code などの Copilot クライアントに対して、Enterprise 管理者が共通設定を配布するための仕組みです。GitHub の説明では、サポートされるキーについては、ユーザーがクライアント側で設定したファイルベースの構成よりも managed-settings.json が優先されます。(The GitHub Blog)
設定前に確認すべき前提条件
管理者は、いきなり JSON を追加するのではなく、次の条件を先に確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Enterprise の Copilot 契約 | 対象ユーザーが Copilot Business または Copilot Enterprise のライセンスを Enterprise 経由で受けているか |
.github-private リポジトリ | Enterprise の AI 設定ソースとして使う組織に .github-private リポジトリがあるか |
| 設定ファイルのパス | 標準パスは copilot/managed-settings.json。旧パスを使っている場合は移行計画も検討する |
| 対象クライアント | 公式情報では VS Code と Copilot CLI が主な対象。全クライアントで同じ挙動になるとは限らない |
| VS Code のバージョン | model permission は VS Code 1.126 以降で利用可能とされている |
| 既存ポリシー | 利用可能モデル、データレジデンシー、評価モデル、FedRAMP 関連ポリシーとの関係を確認する |
GitHub の Changelog では、model permission は VS Code 1.126 以降で利用可能とされています。また、Enterprise managed settings は VS Code と Copilot CLI で適用され、追加クライアントへの対応は今後拡張予定と説明されています。(The GitHub Blog)
管理者向け：導入手順
Enterprise 管理者が実際に導入する場合は、次の順序で進めると安全です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | Enterprise の AI Controls で設定ソースの組織を確認する | すでに custom agents 用の source organization を設定済みなら、同じ .github-private リポジトリを使う |
| 2 | .github-private リポジトリに copilot/managed-settings.json を作成する | 旧パスとの混在を避け、標準パスに寄せる |
| 3 | permissions.model に "auto" を追加する | JSON の構文ミスに注意する |
| 4 | デフォルトブランチにコミットする | レビュー付き PR にすると変更履歴を追いやすい |
| 5 | VS Code と Copilot CLI で反映を確認する | 反映は認証タイミングや定期取得の影響を受ける |
| 6 | 開発者向けに挙動を周知する | 「モデルが固定された」と誤解されないよう説明する |
公式ドキュメントでは、設定がコミットされると、ユーザーがサポート対象クライアントで次に認証したタイミングで指定設定が見えるようになり、クライアントは最新構成を1時間ごとに取得すると説明されています。(GitHub Docs)
既存の managed-settings.json に追加する例
すでにプラグイン標準や権限制御を managed-settings.json で管理している場合は、既存の permissions に model を追加します。
{
"permissions": {
"disableBypassPermissionsMode": "disable",
"model": "auto"
}
}この例では、Auto model selection を既定化しつつ、Copilot CLI や VS Code での bypass mode、いわゆる YOLO mode の無効化も同時に管理しています。GitHub のドキュメントでは、disableBypassPermissionsMode を "disable" にすると、ユーザーが bypass mode を有効化できないようにできると説明されています。(GitHub Docs)
開発者向け：日々の使い方はどう変わるか
開発者にとっての変化はシンプルです。管理者が設定を有効にすると、新しい Copilot の会話が Auto model selection で始まります。VS Code では新しい会話を開始したときのモデルピッカーが Auto になり、Copilot CLI ではユーザーが別モデルを指定しない限り Auto が使われます。(GitHub Docs)
ただし、次のような場面では手動でモデルを切り替える判断も残ります。
| 場面 | おすすめの判断 |
|---|---|
| 複雑な設計相談や難しいバグ解析 | Auto で試し、結果が浅い場合は推論に強いモデルへ切り替える |
| 生成速度を優先したい軽作業 | Auto のまま進める。必要に応じて軽量モデルを選ぶ |
| モデルごとの出力差を検証したい | 同じプロンプトで複数モデルを比較する |
| チームで再現性を重視するレビュー | 使用モデルをメモしておく |
| 管理者ポリシーで使えないモデルがある | Auto の候補にも含まれないため、選択肢に出ない場合は管理者に確認する |
Auto model selection では、Copilot Chat、Copilot CLI、Copilot cloud agent で、どのモデルが使われたかを確認できると説明されています。たとえば Copilot Chat では応答にホバーし、Copilot CLI ではターミナル上で使用モデルを確認できます。(GitHub Docs)
一般ユーザー向け：便利になる点と注意点
一般ユーザーにとっては、「モデルを選ぶ前に作業を始められる」ことが最大のメリットです。GitHub Copilot には複数のモデルがあり、どれを選べばよいか分からない場面があります。Auto model selection を既定値にしておけば、最初の判断を Copilot に任せられます。
一方で、Auto は万能ではありません。タスクの目的が曖昧なままだと、どのモデルを使っても期待した回答になりにくくなります。モデル選択よりも先に、依頼内容を具体化することが重要です。
悪い例：
このコードを直して良い例：
この React コンポーネントで、初回レンダリング時に API が2回呼ばれる原因を調べてください。
副作用の発生箇所、修正案、テスト観点を分けて説明してください。Auto model selection を使う場合でも、プロンプトの品質は結果に大きく影響します。特に、目的、制約、対象ファイル、期待する出力形式を明示すると、モデル選択の恩恵を受けやすくなります。
実務でのメリット
今回の更新は、小さな設定変更に見えますが、企業で Copilot を広く使う場合には運用上の意味があります。
モデル選択のばらつきを減らせる
チーム内で「どのモデルを使うべきか」が属人的になると、回答品質やコスト感のばらつきが出やすくなります。Auto を既定にすれば、少なくとも新しい会話の開始地点をそろえられます。
開発者教育がしやすくなる
新入社員や Copilot に不慣れなユーザーに対して、「まず Auto で始める。必要なら切り替える」というシンプルなルールを示せます。モデルごとの細かい違いを最初から覚えさせるより、導入時の心理的負担を下げやすくなります。
管理ポリシーと併用できる
Auto model selection は、管理者ポリシーや契約プランの範囲内で動きます。使わせたくないモデル、データレジデンシー要件に合わないモデル、組織方針に合わない評価モデルを除外したうえで Auto を使える点は、企業利用では重要です。(GitHub Docs)
コスト管理の一助になる
GitHub 公式ドキュメントでは、有料 Copilot プランで Auto model selection を使う場合、Copilot Chat、Copilot CLI、Copilot cloud agent のモデルコストに10%割引が適用されると説明されています。コスト最適化を目的に導入する場合は、実際の AI credits 使用状況やチーム別利用量とあわせて確認するとよいでしょう。(GitHub Docs)
導入時に失敗しやすいポイント
「Auto にすれば常に最良」と説明してしまう
Auto model selection は、タスクや利用状況に応じて適切なモデルを選ぶ仕組みですが、すべてのケースで人間の意図どおりになるとは限りません。高度な設計判断、セキュリティレビュー、パフォーマンス解析などでは、出力を検証し、必要に応じてモデル変更やプロンプト改善を行う運用が必要です。
モデル利用ポリシーを確認しない
Auto が選べるモデルは、契約プランや管理者ポリシーに制約されます。特定モデルを無効化している場合、Auto の候補にも含まれません。導入後に「期待していたモデルが使われない」とならないよう、Enterprise または Organization のモデル可用性設定を事前に確認してください。(GitHub Docs)
反映タイミングを誤解する
managed-settings.json をコミットしても、全ユーザーの画面が即時に変わるとは限りません。GitHub のドキュメントでは、ユーザーが次に認証したタイミングで設定が見えるようになり、クライアントは1時間ごとに最新構成を取得すると説明されています。(GitHub Docs)
対象クライアントを広く見積もりすぎる
Enterprise managed settings は、公式情報上では VS Code と Copilot CLI での適用が中心です。JetBrains、Visual Studio、Xcode、GitHub Web などの Auto model selection 対応状況とは別に、「Enterprise managed settings による既定値配布」がどのクライアントで効くのかを分けて確認する必要があります。(The GitHub Blog)
ユーザーへの周知を省略する
ユーザーから見ると、ある日から新しい会話のモデルが Auto になったように見えます。周知せずに変更すると、「管理者にモデルを固定された」「使いたいモデルが使えなくなった」と誤解される可能性があります。リリース時には、次の3点を伝えると混乱を減らせます。
| 伝える内容 | 説明例 |
|---|---|
| 変更内容 | 新しい Copilot 会話は Auto model selection で始まります |
| できること | 必要に応じて会話ごとに別モデルへ切り替えられます |
| 相談先 | 利用できないモデルや挙動の違いがあれば管理者に連絡してください |
トラブルシューティング：設定が反映されない場合
設定後に Auto model selection が既定値にならない場合は、次の順に確認すると原因を切り分けやすくなります。
| 症状 | 確認すること | 対処 |
|---|---|---|
| VS Code で Auto が既定にならない | VS Code のバージョン | model permission は VS Code 1.126 以降が対象。古い場合は更新する |
| 一部ユーザーだけ反映されない | Copilot ライセンスの付与元 | Enterprise またはその Organization 経由のライセンスか確認する |
| 複数契約のユーザーで挙動が違う | 個人設定の「Usage billed to」 | GitHub の個人 Copilot 設定で請求先 Enterprise が選ばれているか確認する |
| すぐに反映されない | 認証タイミングと取得間隔 | 再認証、クライアント再起動、時間経過を確認する |
| JSON を変更したのに効かない | ファイルパスと構文 | copilot/managed-settings.json の配置、JSON 構文、デフォルトブランチへのコミットを確認する |
| 期待したモデルが選ばれない | モデル可用性ポリシー | 管理者ポリシーや契約プランで除外されていないか確認する |
GitHub 公式ドキュメントでは、ユーザーが複数の請求主体からライセンスを受けている場合、個人の Copilot 設定にある「Usage billed to」で対象 Enterprise を選んでいるか確認するよう案内されています。(GitHub Docs)
導入すべき企業・まだ様子を見る企業
今回の設定は、多くの企業にとって導入しやすい変更です。ただし、すぐ全社適用するより、チーム単位で検証した方がよいケースもあります。
| 判断 | 向いているケース |
|---|---|
| すぐ導入を検討 | Copilot 利用者が多く、モデル選択の問い合わせが多い |
| まず一部で検証 | モデルごとの使い分けを厳密に運用している |
| 慎重に確認 | データレジデンシー、FedRAMP、評価モデルの利用制限が厳しい |
| 併用設定を検討 | bypass mode 制御やプラグイン標準化も同時に進めたい |
特に、Copilot を「個人の便利ツール」から「企業標準の開発支援基盤」として扱う段階では、既定値の統一が効いてきます。モデル選択を完全に管理者が奪うのではなく、Auto を出発点にして、必要に応じて開発者が切り替える運用が現実的です。
まず確認すべきこと
GitHub の「Enterprises can default to auto model selection」は、Enterprise 管理者が Copilot の新しい会話を Auto model selection で開始できるようにする更新です。設定は managed-settings.json の permissions.model に "auto" を指定するだけですが、実務ではライセンス、対象クライアント、モデル可用性ポリシー、反映タイミングの確認が欠かせません。
まずは、次の順で進めるのがおすすめです。
| 優先度 | やること |
|---|---|
| 高 | Enterprise の Copilot ライセンス付与状況を確認する |
| 高 | .github-private リポジトリと copilot/managed-settings.json の運用ルールを決める |
| 高 | VS Code と Copilot CLI の対象バージョンを確認する |
| 中 | Auto model selection の対象モデルと管理ポリシーの関係を確認する |
| 中 | 一部チームで検証し、回答品質・コスト・問い合わせ件数を確認する |
| 中 | 開発者向けに「Auto で始め、必要なら切り替える」運用ルールを周知する |
この更新は、Copilot のモデル選択を細かく管理するというより、企業として扱いやすい既定値を整えるための機能です。管理者は統制と利便性のバランスを取り、開発者は Auto を出発点にしながら、必要な場面ではモデルを切り替える。この前提で導入すれば、GitHub Copilot の利用体験を大きく崩さずに、運用の標準化を進められます。
コメント