自動モデル選択の優先度を選べるようになりました
GitHub は 2026 年 9 月 14 日、Copilot の自動モデル選択に Efficiency・Balance・Intelligence の 3 ティアを追加したと発表しました。コスト、品質、応答時間のどれを重視してモデルを選ぶかを指定する機能です。公式の変更履歴 に概要が掲載されています。
チームで使うなら、ティア名だけで判断せず、利用するクライアントと請求の基準も確認したいところです。特に、Auto がある IDE でもティアを選べるとは限りません。本記事では 2026 年 9 月 19 日に確認した公式資料を基に対応範囲を整理し、チームの既定を決めるための運用案を示します。
3 ティアは何を優先するのか
候補モデルは全ティアで共通です。ティアを変えると、各プロンプトに対してモデルを選ぶ際の優先度が変わります。
| ティア | 優先するもの | 公式が想定する用途 |
|---|---|---|
| Efficiency | コストを低く抑えること | 素早く処理したい単純な作業 |
| Balance | コスト・品質・応答時間のバランス | 日常的な作業 |
| Intelligence | 品質 | 複雑な作業 |
Auto はティアを選んだ後も、プロンプトごとに依頼内容を評価します。たとえば既存の関数に docstring を加える程度なら、Intelligence でも小型モデルが使われる場合があります。表の定義とこの例の出典は、公式の発表 です。
FIXITIntelligence にしておけば、毎回いちばん大きいモデルを使うの？
Tsumikiまず触ってみるのが早いです。公式の例でも、単純な作業には小型モデルが選ばれています。
Auto は 2 系統あり、ティアの対応範囲も異なる
英語版の公式ドキュメント は、Auto をタスク最適化と信頼性・可用性の最適化に分けています。タスク最適化側は依頼の複雑さも考慮し、信頼性・可用性側はモデルの稼働状況などを基に選択する仕組みです。
| クライアント・製品 | Auto の系統 | ティア |
|---|---|---|
| VS Code・Copilot CLI・GitHub Copilot app | タスク最適化 | 対応 |
| GitHub 上の Copilot Chat・Copilot cloud agent | タスク最適化 | 対象外 |
| JetBrains IDEs・Visual Studio・Eclipse・Xcode | 信頼性・可用性の最適化 | 対象外 |
同じ Copilot Chat でも、VS Code 上ならティアを選べ、GitHub 上では選べません。
JetBrains で Auto が表示されてもティアが無いのは、この系統の違いで説明できます。また、タスク最適化側の製品すべてがティア対応というわけでもありません。対応表は同ドキュメントの製品一覧と IDE 別の記載に基づいています。
Auto 自体は全 Copilot プランで利用可能とされていますが、ティア固有のプラン条件は今回確認した資料に明記されていません。「全プランでティアが表示される」とまでは断定しないでください。
ティアの設定箇所についても、発表と公式ドキュメントには UI 上の位置や操作手順の記載がありません。9 月 14 日の発表時点では順次展開中とされており、完了時期も示されていませんでした。社内手順書を作る際は、対象クライアントで設定の表示を実際に確認してから操作を記録してください。
請求はティア名ではなく、選ばれたモデルから読む
課金の基準は、ティアに関係なく Auto が実際に選んだモデルです。有料プランでは Auto 経由の利用に 10% 割引が継続します。公式発表 で確認できます。
割引対象の製品は Copilot Chat・Copilot CLI・GitHub Copilot app・Copilot cloud agent です。公式ドキュメント に対象が列挙されています。ティア対応の範囲と割引対象は一致しない点に注意してください。
請求を読むための整理としては、「ティアごとの単価」ではなく「どのモデルがどれだけ選ばれたか」と考えると分かりやすくなります。選ばれるモデルの分布が変わりうる設定なので、ティア名だけから月の費用を計算することはできません。
Efficiency の削減率や Intelligence の増加率は公式に示されておらず、FIXIT でも実測していません。10% 割引とティア変更の効果を足し合わせて、削減目標を設定するのは避けてください。
月次で費用を比べる際は、利用量や担当した仕事が変わっていないかも一緒に見てください。難しい改修が集中した月と、文書修正が中心だった月を、そのままティアの優劣として比較するのは避けたいところです。請求制度全体の変更点は、GitHub Copilot の課金改定 にまとめています。
管理者は対象モデルの制約を先に確認する
Auto が選べるモデルは契約プランと管理者ポリシーの範囲内です。プラン外のモデル、管理者が除外したモデル、データ所在地や FedRAMP 対応に関するポリシーで除外したモデル、評価モデルの制限で除外したモデルは候補に入りません。個人プランでは評価モデルが使われる場合があり、利用者が無効化できます。公式のポリシー説明 で条件を確認してください。
導入担当者は、契約プラン・許可モデル・利用クライアントを先に整理しておくと、メンバー間の差を調べやすくなります。同じティア名でも、許可されている候補が異なれば比較条件が揃いません。
特に、データ所在地の条件がある組織では、ティアを上げることと利用可能なモデルを増やすことを分けて扱ってください。品質優先を選ぶだけで管理者の制限が解除される、と説明するのは誤りです。
チームの既定は Balance を出発点に検証する
確認した公式資料には、チームが既定にすべきティアの推奨はありません。ここからは本記事の運用提案です。「既定」はチーム内で合意する通常時の選択を意味し、管理画面での一括強制機能を指していません。
まず Balance で日常業務の状態を記録し、困っている点に応じて対象作業のティアを変える方法を提案します。コストだけで先に統一すると、やり直しが増えた理由を把握しづらくなるためです。
| 観測した状況 | 次に試す選択 | 継続するかを判断する材料 |
|---|---|---|
| まだ費用と品質の記録が無い | Balance を出発点にする | 同種の作業での費用、修正回数、待ち時間 |
| 定型的な作業が多く、費用を抑えたい | その作業で Efficiency を試す | レビュー指摘や再依頼が増えていないか |
| 複雑な改修で回答の修正が多い | 対象の改修で Intelligence を試す | 追加費用に対して手戻りが減ったか |
| モデルの違いが不具合調査を難しくしている | 利用可能なモデルを手動で指定して比較する | 同じ入力と評価基準で原因を絞れるか |
文書の整形や狭い範囲の変更から試し、受け入れ条件を満たしたかを人が確認してください。難しい改修で Intelligence を試しても、テストやレビューは引き続き必要です。品質優先という名前は、成果物の正しさを保証するものではありません。
チームで揃えるのは、最初のティア、切り替える理由、記録する項目です。個々の作業での変更は担当者に任せ、理由を短く残す運用なら、モデルを選ぶたびに承認を求めずに比較材料を集められます。
FIXIT安くなったら、その設定をみんなに勧めていい？
Tsumiki僕なら修正回数も見ます。請求が減っても、人が直す時間が増えたら選び直したいですね。
ツールを横断して費用と利用状況を整理する考え方は、Cursor のコスト管理 でも扱っています。自作アプリの API 費用を調べたい場合は、LLM アプリのコスト最適化 を参照してください。Copilot のティアとは対象が異なりますが、仕事の種類と費用を対応付ける観点は共通です。
選択後は使用モデルと作業結果を記録する
実際に使われたモデルの確認方法は、公式ドキュメント に記載されています。
| 製品 | 使用モデルの確認方法 |
|---|---|
| Copilot Chat | 応答にポインターを重ねる |
| Copilot CLI | ターミナル内の応答ごとのモデル表示を見る |
| GitHub Copilot app | モデルピッカーの Auto 横を見る |
| Copilot cloud agent | 応答の末尾を見る |
cloud agent はティア対象外ですが、Auto の利用モデルを確認する手段はあります。社内で複数製品を使う場合にも、ティアを選べるかどうかとモデルを確認できるかどうかを分けて案内してください。
試行記録には、作業の種類・クライアント・ティア・表示されたモデル・再依頼の回数・人が修正した内容を残すと比較しやすくなります。費用を作業単位で取得できない場合は、確認できる利用状況の集計範囲を添えておきましょう。モデル表示だけで請求額まで確認できた扱いにはしません。
試行期間は、たとえば 1 か月と先に決め、代表的な作業が十分に集まったかを見て判断します。期間中に許可モデルやクライアントを変えたら、その日も記録してください。候補モデルの変更がある際は、Copilot のモデル提供終了と移行先 も確認し、過去と同じ条件で比較できるかを点検してください。
HydraFusion は別の取り組みとして読む
本記事の Auto は一般提供されているモデル選択機能で、今回のティアは優先度を調整する製品機能です。一方、Project HydraFusion は実行時のモデル選択や複数モデルの組み合わせを扱うリサーチプレビューとして紹介されています。
両者は別の取り組みです。HydraFusion の実行パターンやベンチマークの削減率を、そのまま Auto のティアの説明に流用しないでください。ティアの運用判断には、利用するクライアントで観測した費用と作業結果を使いましょう。
最初のティアと見直す条件をセットで決める
チームで始めるなら、まずティア対応のクライアントと許可モデルを確認し、Balance で試す仕事を選んでください。試行期間が終わったら、費用だけでなく手戻りや待ち時間も見て、Efficiency・Intelligence を使う場面を決めていきます。
AI 駆動開発のクリエイティブスタジオである FIXIT の AI 開発ツール導入支援 では、ツールの選定からチームの運用ルール作りまで相談できます。既定の選び方や評価する仕事を整理したい方は、お問い合わせ から現在の利用環境をお聞かせください。