先に結論
VS Code を日常で使うなら、GitHub Copilot の既定値はまた Auto でよくなりました。
今回の更新で Auto は、空いているモデルを選ぶだけではなく、作業の重さを見て振り分ける ようになっています。しかも有料プランでは premium request multiplier が 10% 軽くなる ので、固定モデルを張りっぱなしにする理由も少し減りました。
一方で、全部 Auto で済ませる話でもありません。
- 再現性が欲しい検証
- チーム手順書に同じモデル名を残したい場面
- 1x 超えの premium model を明示的に使いたい場面
このあたりでは、fixed model を残したほうがまだ扱いやすいです。
何が変わったのか
GitHub は 2026-05-20 の changelog で、VS Code の Copilot auto model selection が task-aware routing へ更新された と案内しました。
見るべき点は 3 つです。
- reasoning や bug diagnosis の重さ を見てモデルを振り分ける
- tool orchestration needs まで見て選ぶ
- 1x 以下のモデル範囲で 10% 割引 を入れながら回す
これまでの Auto は「モデルの空き具合と安定性を見てうまく回す」印象が強めでした。今回の VS Code 更新では、そこに task complexity の評価 が明確に足されています。
つまり、軽い確認と重い不具合調査を同じ扱いにしにくくなった、ということです。
Auto を既定に戻しやすくなった理由
いちばん大きいのは、固定モデルを毎回選ぶ判断コストが減る ことです。
VS Code の日常利用では、軽い質問、コードの読み解き、修正案の叩き台、少し重いデバッグが同じ画面に混ざります。ここで毎回モデルを決めるのは地味に重いです。
GitHub Docs では、Auto は real-time health と task complexity を組み合わせて最適なモデルへルーティングすると説明しています。しかも routing は natural cache boundaries に沿って行われ、無駄な cache cost を増やしにくい設計です。
要するに、日常の既定値としては 前よりかなり素直に任せやすい 形になりました。
premium request はどう変わるか
今回の更新で見逃しにくいのはここです。
GitHub の changelog と docs では、有料プランで Auto を使うと model multiplier に 10% の discount が入る と明記されています。
たとえば Auto が 1x のモデルを選ぶなら、消費は 1 ではなく 0.9 premium request です。
しかも Auto は、docs 上では premium request multiplier が 1 を超えるモデルを候補に入れません。
この仕様なら、日常の VS Code 利用を Auto に戻したときも、重いモデルへ無制限に飛ぶ前提では見なくて済みます。
固定モデルを常用していたチームほど、まず見直したいのは「どの高性能モデルを固定するか」より 普段の既定値を Auto に戻しても request 管理が荒れないか です。
Copilot 全体の request 設計は、GitHub Copilot個人プラン変更まとめ も合わせて読むとつながりやすいです。
管理者が先に見るべきこと
Business と Enterprise で重要なのは、Auto が便利になったことより ポリシーを壊さないこと です。
GitHub Docs では、Auto は次を候補から外すと明記しています。
- プランで使えないモデル
- 管理者ポリシーで除外されたモデル
- data residency や FedRAMP 制約に反するモデル
- 1x を超える premium multiplier のモデル
この条件なら、管理者としては「許可済みの枠の中で Auto を標準化する」話にしやすいです。
ただし、VS Code の task optimization を全社標準にする前に、次の 2 点は見ておいたほうが安全です。
1. 本当に VS Code 利用が中心か
GitHub Docs では、task optimization が一般提供なのは VS Code です。
JetBrains、Eclipse、Xcode でも Auto 自体は使えますが、案内されているのは reliability / availability 最適化が中心です。Visual Studio は public preview 扱いです。
そのため、社内の主要 IDE が割れているなら、「Copilot Auto が賢くなった」とひとまとめにせず、まず VS Code 利用者から既定設定を変える ほうがズレません。
2. fixed model を残す例外ルールを決める
Auto を標準にしても、fixed model をゼロにする必要はありません。
残したいのは次のような場面です。
- 再現テスト
- 研修やデモ
- 評価比較
- 特定モデル前提の社内手順書
標準ルールは「普段は Auto、例外だけ fixed」で十分です。管理者向けの許可設計は、GitHub Copilot Business / Enterprise のモデル承認ガイド も役に立ちます。
fixed model を残したほうがいい場面
今回の更新でも、fixed model の価値は消えていません。
一番分かりやすいのは、毎回同じモデル挙動を前提にしたい場面 です。
Auto は時間とともに候補モデルが変わり得ます。GitHub Docs も availability は変動すると書いています。したがって、次の用途では fixed model のほうが still 扱いやすいです。
- benchmark を取りたい
- 不具合再現の条件をそろえたい
- あるモデルの得意不得意を観察したい
- request 消費の説明を固定したい
CLI 側の使い分けは、GitHub Copilot CLI auto model selection vs fixed model 指定 で詳しく整理しています。
今すぐ見直すならどこか
今回の更新を受けて、VS Code 利用者や管理者が先に見るべきなのはこの 4 点です。
1. VS Code の既定値を fixed のままにしている理由
単に過去の癖で固定しているなら、Auto に戻す価値があります。
2. premium request の見積もり
固定モデル常用より、Auto のほうが軽くなる場面が増えます。request 枠を理由に fixed を選んでいたなら再計算したほうがいいです。
3. 管理者ポリシーで何を許可しているか
Auto は許可モデルの範囲でしか動かないので、まず policy 側が古いままではないかを見ます。
4. IDE ごとの差を説明できるか
VS Code とそれ以外で Auto の最適化段階が違う点は、ユーザー向け案内で早めに書いておくほうが混乱しません。
今の時点で言えること
今回の VS Code 更新で、GitHub Copilot Auto は 保険的な選択肢 から 日常の標準候補 にかなり近づきました。
- task の重さを見るようになった
- premium request は 10% 軽くなる
- admin policy を壊さない
- 1x 超えモデルには勝手に飛ばない
なので、VS Code 中心のチームなら、まずは Auto を既定に戻してみる価値があります。
そのうえで、再現性や説明責任が必要な場面だけ fixed model を残す。この切り分けがいま一番扱いやすいと思います。