GitHub では、Copilot の自動モデル選択に 3 つの構成可能な階層が追加され、コーディング アシスタントがプロンプトごとにコスト、品質、応答時間をトレードオフする方法に影響を与える新しい方法が組織に提供されました。

2026 年 9 月 14 日に発表されたこの変更では、Copilot の自動モデル ピッカーの効率、バランス、インテリジェンス設定が導入されています。 3 つの層はすべて、利用可能なモデルの同じプールを使用しますが、どのモデルがリクエストを処理するかを決定する際に、Copilot が競合する優先順位を比較検討する方法が変わります。この機能は、Visual Studio Code、Copilot CLI、および GitHub Copilot アプリに展開されています。

エンタープライズ エンジニアリング チームにとって重要な点は、Copilot がモデルを自動的に選択できるというだけではありません。それは、選択肢が管理者向けのポリシー面を持つようになったということです。特定のコーディング タスクに対して、どのモデルがより安く、より速く、より強力であるかをすべての開発者に理解させる代わりに、チームは、運用の優先順位によりよく適合するデフォルトの姿勢を設定できます。

Copilot の自動モデル選択の変更点

Copilot の自動モデル選択では、すでにプロンプ​​トが評価され、GitHub のサポートされているセットからのモデルにルーティングされています。新しい階層では、ルーティング動作に対するより高いレベルの制御が追加されます。

効率階層は、低コストで高速な応答を優先することを目的としています。バランス層はコストと品質の間に位置します。インテリジェンス層は、Copilot がどのモデルが応答すべきかを評価する際に、より強力なモデルのパフォーマンスをより重視します。 GitHub は、利用可能なモデル セットが階層全体で同じであることを示しているため、この設定は安価なモデルまたはプレミアム モデルの単純な許可リストではありません。これは、選択プロセスに影響を与えるポリシー シグナルです。

使用料金は、自動で実際に選択されたモデルに基づいて請求されます。有料加入者は、自動モデル選択パスを通じて請求される使用量に対して、引き続き 10% の割引を受けられます。つまり、階層設定は支出に間接的に影響を与える可能性がありますが、どのモデルがどのくらいの頻度で使用されているかを検査する必要性がなくなるわけではありません。

ロールアウトは、複数の開発者向けのサーフェスに同時に影響するため、ロールアウトも重要です。 Visual Studio Code は、主流の IDE ワークフローをカバーします。コパイロット CLI は、端末ベースの開発に動作を組み込みます。 GitHub Copilot アプリは、エージェントのようなチャット スタイルの作業がエディターの外で行われる別のインターフェイスに拡張します。

これがエンジニアリング チームや財務チームにとって重要な理由

AI コーディング ツールを導入しているほとんどの組織は、開発者がそれを使用するかどうかという問題を超えています。さらに難しい問題は、複数のモデル、請求料金、タスク タイプ、開発者のワークフローが 1 つの製品エクスペリエンスに混在している場合に、使用状況をどのように管理するかということです。

手動でモデルを選択すると、専門家ユーザーが制御できるようになりますが、大規模なエンジニアリング組織全体に適切に拡張することはできません。多くの開発者は、利用可能なモデル間の限界コストや機能の違いを知りません。また、日常的なコーディング作業中に調達グレードの決定を下す必要はありません。自動選択によりその負担は軽減されますが、管理者がルーティング ロジックを確認または形成できない場合、コストが不透明になる可能性もあります。

新しい層は中間層です。これらは完全なモデル選択アルゴリズムを公開するものではなく、特定のプロンプトが特定のモデルに送信されることを保証するものでもありません。しかし、これらは、すべての開発者に手動で安価なモデルを選択するように指示するよりも、より実践的な管理をリーダーに提供します。

Copilot は生のモデル API ではなく開発者ツールとしてパッケージ化されているにもかかわらず、これは AI API コスト管理 と密接に関連しています。根底にあるガバナンスの問題は同じです。組織は、より高価なモデルが正当化されるのはいつか、より安価なモデルで十分な場合は、そしてそれらの選択肢が予算にどのように反映されるかを決定する必要があります。

誰が影響を受けるか

最も直接的な対象者は、GitHub Copilot Business または Enterprise を使用し、使用量ベースの請求を行うエンジニアリング組織です。すでに Copilot の使用状況を確認し、予算を設定し、利用可能なモデルを制限しているチームは、新しい設定が既存のポリシーにどのように適合するかを評価する必要があります。

プラットフォーム エンジニアリング チームも、内部ガイダンスを更新する必要がある場合があります。開発者がコードレビュー、リファクタリング、テスト、またはエージェント作業のために特定のモデルを選択するように指示されている場合、新しい自動層によって推奨されるデフォルトが変更される可能性があります。組織は、ほと​​んどの開発者がバランスを使用する必要がある、大規模チームが効率性を重視して開始する必要がある、または複雑な移行に取り組む特定のグループがインテリジェンスを使用する必要があると決定する場合があります。

請求書は依然として選択したモデルに依存するため、財務チームと調達チームは影響を受けます。効率性という名前の政策を、厳しい支出の上限として扱うべきではありません。それはルーティング設定です。組織は今後も、支出をチーム、ユーザー、ワークフロー、選択したモデルに結びつけるレポートを必要とします。

セキュリティ チームとガバナンス チームは、より狭い範囲ではありますが、実際の関心を持っています。モデル ポリシーがプロバイダー、地域、データ処理条件、または内部承認ステータスによって異なる場合、自動モデル選択はそれらの制約内で機能する必要があります。 GitHub の発表によると、利用可能な同じモデル セットが階層間で使用されるため、管理者はモデル有効化ポリシーが組織が実際に使用したいと考えているものを反映していることを確認する必要があります。

開発者にとっての実際的な結果

個々の開発者にとって、最良の結果は中断が少なくなることです。開発者は Copilot に支援を求めることができ、システムは組織が好むコストと機能のバランスに合わせたモデルを選択できます。これは、定期的なオートコンプリート、簡単な説明、テストの提案、および毎回最強のモデルに料金を支払う必要がないコマンドライン支援に特に役立ちます。

その代償として、モデル レベルでの動作の予測が難しくなる可能性があります。ユーザーにとっては似ている 2 つのプロンプトが異なる方法でルーティングされる可能性があり、GitHub が使用可能なモデル セットまたは選択ロジックを更新するため、同じワークフローでも異なるコストとレイテンシの特性が生成される可能性があります。決定論的なテスト、ベンチマークの比較、または厳密なモデルの文書化を必要とするチームでも、一部のワークフローでは明示的なモデルの選択を好む場合があります。

管理者は、ロールアウトを受動的製品の更新ではなく、ポリシーのレビューとして扱う必要があります。有用な最初のステップには、どの Copilot サーフェスが有効になっているかを確認すること、デフォルトのモデル ポリシーを確認すること、使用量ベースの課金がどのように構成されているかを確認すること、異なるチームに異なるガイダンスが必要かどうかを判断することが含まれます。成熟した AI 使用状況分析を備えたチームは、新しい段階で費用がプレミアム通話の減少、総使用量の増加、またはチームごとの異なる行動にシフトするかどうかに注目する必要があります。

最大の不確実性は透明性です。 GitHub は、Copilot が各プロンプトをどのように評価するか、または階層設定によってあるモデルが選択される確率が別のモデルよりもどのように変化するかについて、完全な詳細を公開していません。そのため、企業が自社の環境で機能を試す前に、コストや品質の変化を正確に予測できるかどうかが制限されます。

それでも、方向性は明確です。コーディング アシスタントは、単一モデルのサブスクリプションではなく、ポリシー制御を備えたマルチモデル システムになりつつあります。 AI 開発ツールを標準化する企業にとって、運用上の問題は「どのモデルが最適か?」から変わりつつあります。 「この作業、このチーム、この予算にはどのルーティング ポリシーが適切ですか?」