GitHub Copilot Autoに3段階のルーティング設定が追加、コスト重視モードでも複雑なプロンプトには大規模モデルを選択する可能性

GitHubは9月14日、Copilotの自動モデル選択機能に「Efficiency」「Balance」「Intelligence」という3つの設定を追加し、まずVS Code、Copilot CLI、GitHub Copilot appへの展開を開始した。これは3つのモデルリストを別々に設けるものではなく、同じ利用可能なモデルプール上で、ルーターがコスト、品質、応答時間に与える重みを変更する仕組みだ。Intelligenceを選択していても、docstringの追加などの単純なプロンプトは、より小規模なモデルに送られる可能性がある。

Autoは、プロンプトが求めるタスクの複雑さ、リアルタイムのモデル稼働状況、可用性を組み合わせて判断する。また、プラン、データレジデンシー、FedRAMP、企業管理者によるモデル除外などの制約にも従う。GitHubによると、ルーティングは自然なキャッシュ境界で行われ、セッション途中でモデルを切り替えることによるキャッシュ無効化を防ぐ。ユーザーは、応答またはターミナル出力で、実際にリクエストを処理したモデルを確認できる。これにより、チームはリクエストごとにモデルを選ぶ代わりに、より高い抽象度で意図を設定できる。一方で、パフォーマンスの再現性の一部は、供給状況に応じて変化するルーティング戦略に委ねられることになる。

特に料金ルールは切り分けて理解する必要がある。3つの設定はいずれも、実際に選択されたモデルの入力、出力、キャッシュtokenに基づいて課金され、有料プランでAutoを使用すると10％の割引が適用される。Intelligenceが単一の高価格モデルに固定されるわけでも、Efficiencyに厳格な予算上限が設けられるわけでもない。モデルによって出力単価や長いコンテキストの料金には数十倍の差が生じ得るため、CI、バッチエージェント、長期的なリファクタリングでは、各ターンのモデル、token数、コストを引き続き記録すべきだ。

現時点で、公式には3段階それぞれの候補モデルに対する重み、品質基準、ルーティングの安定性、コスト分布は公表されておらず、組織単位の厳格な上限も提供されていない。エンジニアリングチームは次のステップとして、同じテストセットについて、時間帯ごとのモデル選択、キャッシュヒット率、テールコストを観察する必要がある。監査や決定論的な再現性が求められるワークフローでは、Autoに依存するよりもモデルを明示的に固定する方が、依然として追跡しやすい。