はじめに
GitHub Copilot のモデルピッカーで「Auto」を選択した際のモデルが、いつの間にか更新されていることに気づきました。
2026年9月14日に公開された記事で言及があったようです。
この記事の中では、Auto に efficiency / balance / intelligence の3段階が追加され、あわせて「利用できるモデルの選択肢も更新された」とアナウンスがありました。
今回は、最新のGithub CopilotでモデルをAutoにした場合の使い方がどう変わってきたかを簡単に説明していきます。
Auto を選ぶとどうなるの？
Autoを選ぶと、Copilot は依頼の内容に応じて利用可能なモデルから適したモデルを選択して利用します。また、Autoで選択したモデルは10%のディスカウントで利用することができるので、何かと問題になる価格面でも有利です。
ただ、少し前まではAutoで選択されるモデルは世代の古いモデルが多く、安くなると入っても普通にGPT-5.6 Lunaを選択したほうが安く、高性能なモデルが利用できるというねじれ現象が起きていました。
何が変わったか
すでにGitHub上のドキュメントが変更されているため確認はできませんが、インターネットアーカイブを確認すると、以前Autoで利用できるモデルは次のモデルが対象になっていたようです。
- GPT-5.3-Codex / GPT-5.4 / GPT-5.4 nano
- Opus 4.5 / Opus 4.6 / Opus 4.7 / Sonnet 4.5 / Sonnet 4.6
今回の変更後、Autoで利用できるモデルは次のページで確認できます。
選択するモデルが大幅に増えたのでここで列挙はしませんが、GPT-5.3 Codexなどの古いモデルは退役し、GPT-5.6 / GPT-6 / Claude 5 / Claude 5.5 の最新モデルや、これまでAutoでは選択されなかった Gemini Flash系のモデルが追加されていることがわかります。
Auto のモデル選択
Auto のモデル選択方針に3つの段階を選択で選択できるようになりました。
- Efficiency: コスト重視。速くて単純なタスク向け
- Balance: コスト・品質・レイテンシのバランス型。普段使い向け
- Intelligence: 品質重視。複雑なタスク向け
3段階とも使えるモデルの一覧は変わらないとのことですが、ディスカウントを効かせながら効率的にモデルが利用できるようになった...ということでしょうか。
VS Code の Agent Debug Log で確認する
「結局、今のリクエストでは何が使われたのか」は、VS Code の Agent Debug Log で追えます。
コマンドパレットで Open Agent Debug Logs を選択しましょう。
起動後にGitHub Copilotのチャットウインドウからタスクを実行すると、セッションの一覧が表示されます。
設計タスクをBalanceとIntelligenceで比べる。
次のプロンプトで実装計画まで作成した場合の動きを、BalanceとIntelligenceで比べました。
プロンプト
# 依頼
C# 向け TypeSafe AI（Jev）HTTP API ラッパーライブラリ「JevLight」を新規開発する
**仕様書** と **実装タスクリスト** を作成してください。
このタスクは一度の実行で完結させます。**途中で私に質問や確認をしないでください。
** 判断が必要な点は、あなたが最も妥当だと考える案を採用し、その理由と検討した代替案を「前提と判断の記録」に書いてください。
# 入力（これ以外は参照しない）
- 調査資料: `<docs/research/jev-research.md>`
- TypeSafe AI 公式 API ドキュメント
リポジトリ内の他の仕様書・計画書（`docs/plans/`、`SPECIFICATION.md` など）は**読まないでください**。
# 確定済みの前提（変更しない）
- 対象 TFM は `net10.0`。コアパッケージの外部 NuGet 依存はゼロ
- Native AOT とトリミングに対応する
- 初版のパッケージ: `JevLight`（コア）、`JevLight.Extensions.Logging`、`JevLight.Extensions.DependencyInjection`、`JevLight.Extensions.Resilience`、`JevLight.Extensions.Caching`
- 任意の後続: `JevLight.Extensions.AI`、`JevLight.Generators`（初版をブロックしない）
- 重視する品質: 型安全、自動復旧、性能（GC 負荷とアロケーション）、可観測性、API 変更への追従しやすさ
- 主な利用シーン: (a) Web API のリクエスト処理内での呼び出し、(b) バッチ処理での大量呼び出し
- ライセンスは MIT。ホストと CI は GitHub / GitHub Actions
- 上記にないこと（テストフレームワーク、層構成、リトライの位置、キャッシュキーなど）は、あなたが決めてください
# 成果物
コードは書かず、次の 2 ファイルだけを作成してください。
1. `docs/eval/<tier名>/SPEC.md` — 仕様書
2. `docs/eval/<tier名>/PLAN.md` — 実装タスクリスト
## SPEC.md の構成（見出しを固定）
1. 目的とスコープ（やること / やらないこと）
2. 前提と判断の記録（判断、理由、却下した代替案を表で）
3. アーキテクチャ（層構成と依存方向。図を 1 つ入れる）
4. 公開 API（主要な型とメソッドのシグネチャ）
5. エラーモデルと復旧（例外の階層、一時的エラーの判定、Retry-After、重複送信のリスク）
6. 性能設計と数値目標（計測シナリオ付き）
7. 可観測性（トレース・メトリクス・ログ、記録しない情報）
8. 各サテライトの仕様
9. セキュリティ（資格情報、ログやキャッシュへの漏えい防止）
10. 未解決のリスクと検証方法
## PLAN.md の構成（見出しを固定）
- タスクごとに: ID / 目的 / 作業内容 / 依存タスク / **検証可能な完了条件**
- タスク間の依存関係と、並行して進められる部分
- リリース（パッケージ公開）までの手順
- 後続タスク（任意）
# 最後に
提出前に自分で見直し、「SPEC と PLAN の間の矛盾」「完了条件が検証できないタスク」「確定済みの前提との矛盾」がないか確認してください。見直した結果を PLAN.md の末尾に 3〜5 行で書いてください。
今回の確認ではIntelligenceはClaude 5.5、BalanceでGPT-6 Lunaと異なるモデルを選択して作業を進めたようです。作成された成果物はコストでは圧倒的にBalanceが勝っていましたが、仕様書の内容としてはIntelligenceのほうが高い評価を得ました。
プロンプトキャッシュを効率的に利用するためだと思うのですが、どちらも設計が完了するまでは同じモデルを使い続けました。
Intelligenceの実行結果
Opus 5.5とgpt-4o-miniが利用されました。gpt-4o-miniはBackgroundTodoAgentの呼び出しに使われた1回限りで、残り8回の仕様書作成にかかわる呼び出しはすべてOpus 5.5が利用されました。
Balanceの実行結果
GPT-6 Lunaとgpt-4o-miniが利用されました。Intelligenceと同様gpt-4o-miniはBackgroundTodoAgentの呼び出しに使われた3回で、残り33回の仕様書作成にかかわる呼び出しはすべてGPT-6 Lunaが利用されました。
結果と評価
それぞれキャッシュを利用しないようVSCodeを起動しなおして3回試しましたが、メインのタスクをこなすモデルとしてIntelligenceでは常にClaude 5.5が、BalanceではGPT-6 Lunaが選択されました。
Opus 5.5に比べモデルの呼び出し回数や入力トークン数はGPT-6 Lunaを選択したBalanceのほうが圧倒的に多かったのですが、もともとのLunaの経済効果もありIntelligence:223.64AICに対し、5.26AICという驚異的なコストに収まっています（プロンプトキャッシュの影響もあるかもしれません）。
最後にGrok4.7に評価させた結果です。
今回はワンショットで仕様を作成させたので、実際の利用と必ずしも一致しませんがある程度想定した結果が得られました（利用したモデルの特徴がそのまま結果に出たという感じもありますが）。
両仕様は同じ調査メモを入力に必須条件をいずれも満たしている。差は具体性にある。balanceは層の責務がぶれず、キャッシュは明示的な有効化に留まり、方針の承認文書として読みやすい。ただしChoiceがenumのみ、再試行とキャッシュの順序が未定など、実装時に解釈が割れやすい。inteligenceは判断の追跡、検証規則、パイプラインまで落ちており、実装の正本に向く。
balanceは74点、inteligenceは86点
| 評価軸 | 見方 | balance(GPT-6 Luna) | inteligence(Opus 5.5) |
|---|---|---|---|
| 必須条件への適合 | 調査メモの決定を満たすか | 満たす。決定の範囲をほぼ超えない | 満たしたうえで、番号付きで具体化している |
| 実装可能性 | 推測せず実装できるか | 骨格まで。配線と検証規則が不足 | ほぼ実装できる。正本向き |
| 公開APIの網羅 | 公式の質問型と前方互換を表現できるか | Choiceがenumのみ。未知の質問型がない | 文字列キー、enum、未知型の抜け道がある |
| 既定値の安全性 | 再試行とキャッシュの初期設定が安全側か | 再試行は未登録なら0。キャッシュはopt-in | 再試行の分離は明確。キャッシュ既定ONは危険側 |
| 判断の一貫性 | 本文、表、例外モデルが矛盾しないか | 矛盾は少ない | 層の設計は一貫。判断表とSpanの記述に欠陥がある |
おわりに
これまでAutoは少し古いモデルを安く使うという使い方でしたが、最新モデルがサポートされ、ティアの指定ができるようになったことで、日常的な利用にはBalanceを、仕様書などの手戻りが大きく後続作業に響く内容についてはIntelligenceをといった使い方ができるようになりました。
今回の比較はタスクの種類も、試行回数も限られており、採点も LLM によるものですが、同じ Auto でも、ティアによって選ばれるモデルやコストが大きく変わることは確認できました。自分のタスクで Agent Debug Log を見ながら、最適なティアを見極めてみてください。