はじめに
GitHub Copilot でモデルを使うとき、これまでは「Auto にモデル選択を任せる」か、「HydraFusion に複数モデルの実行を任せる」かを考える場面がありました。
2026 年 10 月 28 日、GitHub は Copilot Fusion の一般提供（GA）を発表しました。Copilot Fusion は、Auto のモデル選択と Project HydraFusion の複数モデル・オーケストレーションを組み合わせた機能です。
以前の記事では、Auto は「どのモデルを使うか」、HydraFusion は「モデルをどう組み合わせるか」という違いを整理しました。今回は、その二つが Copilot Fusion でどのように一つの体験になったのかを、公式発表をもとに見ていきます。
本記事のゴール
- Copilot Fusion が Auto と HydraFusion をどう組み合わせるのかを理解する
- effort level と実行パターンの違いを把握する
- 利用できるクライアント、料金、管理者向け設定を確認する
Auto と HydraFusion の違い
これまでの二つは、どちらもモデル選択に関係しますが、主に担う役割が異なっていました。
| 仕組み | 主な役割 | 利用者が意識すること |
|---|---|---|
| 🎛️ Auto | タスクに応じて使うモデルを選ぶ | モデル選択を自動化する |
| 🧠 HydraFusion | モデルと実行パターンを選び、必要に応じて複数モデルを使う | モデルの組み合わせ方を任せる |
Auto は、プロンプトごとに使うモデルを選ぶ仕組みです。一方、HydraFusion は単にモデルを選ぶだけではなく、複数モデルを使う実行パターンも選びます。詳しくは以前の記事「HydraFusionと動的ワークフロー：作成時のモデル選択は品質にどう効くのか」でも整理しました。
Copilot Fusion は、この二つの利点をまとめ、利用者が個々のモデルを選び分けなくても、タスクに応じてモデルの選択や連携を行う体験として提供されます。公式発表では、Copilot Fusion 自体を選び、必要な effort level を指定する流れが案内されています。
effort level を選ぶ
Copilot Fusion では、モデルそのものではなく、どの程度の能力を優先するかを選びます。
| effort level | 優先すること | 想定されるタスク |
|---|---|---|
| ⚖️ Fusion Standard | コスト、品質、応答時間のバランス | 日常的な作業。タスクごとに一つのモデルを選択 |
| 🔍 Fusion High | 複数モデルの連携とトークン削減のバランス | 複数ファイルにまたがる修正や複雑なバグ対応 |
| 🚀 Fusion Max | トークン効率も考慮しながら、最も高い能力を優先 | 最も深い推論や丁寧な分析が必要なタスク |
| ⚡ Fusion Fast | 高速なモデルを使うシナリオ向け | VS Code の Inline Chat でのみ利用。利用者が選択する項目ではない |
選択するのは、個別のモデル名ではなく effort level です。どのモデルを使うか、またモデルをどう連携させるかは、Copilot Fusion がプロンプトごとに判断します。タスクの途中でモデルを切り替えたり、各工程に合うモデルを都度選んだりする必要を減らす考え方です。なお、Fusion Fast は現在、VS Code の Inline Chat に限られた利用者が選択できない effort level です。
必要に応じてモデルを連携する
GitHub の発表では、Copilot Fusion の実行パターンとして次の三つが紹介されています。
| パターン | 処理の流れ |
|---|---|
| 🧩 Single | 一つのモデルがそのままタスクを解く |
| 🔁 Cascade | 効率的なモデルが案を作り、別のモデルが受け入れるか、より強いモデルへのエスカレーションが必要かを判断する |
| 📝 Critique | 一つのモデルが案を作り、複数のモデルが並行してレビューする。レビュー結果をまとめ、最初のモデルが修正する |
毎回複数のモデルを使うのではなく、タスクに合わせて一つのモデルで処理したり、確認や追加の推論を挟んだりするのがポイントです。利用者がプロンプトごとに実行方法を設計するのではなく、Copilot Fusion に選択を任せられます。
同じセッションでも、プロンプトごとに異なる実行パターンが選ばれることがあります。Copilot Fusion の進行中は各ステップと使用モデルを確認でき、応答後には effort level の表示から使用モデルの一覧を確認できます。
Copilot Fusion はモデルの健全性や利用可能性も考慮してモデルを選びます。単純なタスクには不要なレビュー工程を追加しないため、必ず複数モデルを使うわけではありません。一方、詳細なルーティング条件や品質チェックの判定基準までは公開情報から断定できません。
管理者が制御できる範囲
Copilot Fusion が使うモデルは、企業や組織で有効になっているモデルポリシーに従います。管理者は、Copilot Fusion が選択できるモデルを確認し、Fusion 向けに個別のモデルを無効化できます。これは、そのモデルを組織全体で使えなくする設定とは分けて管理できます。
また、Enterprise managed settings を利用する環境では、管理者が任意の effort level の Copilot Fusion を既定モデルに設定できます。個人が選ぶだけでなく、組織として利用モデルや既定値を管理できる点も、今回の発表に含まれています。
料金と提供状況
Copilot Fusion の利用料金は、Fusion が使用した各モデルについて、それぞれの標準料金で請求されます。GitHub は期間限定で、有料 Copilot プランのユーザーを対象に、Copilot Fusion のモデル利用料を 30% 割引すると発表しています。割引の適用条件や期間は変わる可能性があるため、利用前に公式情報を確認してください。
発表時点では、Copilot Fusion はすべての Copilot プランで利用可能で、次のクライアントが対象です。
- Visual Studio Code
- GitHub Copilot app
- GitHub Copilot CLI
- JetBrains IDE
利用するにはクライアントを更新し、モデルピッカーで Copilot Fusion を選択して effort level を指定します。発表記事では、その他のクライアントへの対応は今後提供予定とされています。
研究プレビューに参加し、Auto、HydraFusion、HydraFusion Max を有効にしていた場合は、それぞれ対応する Copilot Fusion の effort level に自動移行すると案内されています。
ベンチマークの数字をどう見るか
GitHub は、Artificial Analysis Coding Agent Index において Copilot Fusion Max が 60 点を獲得し、Claude Code with Opus 5.5 Max のスコアから 2 点以内だったと説明しています。また、タスクあたりの平均 API コストとトークン数はおよそ半分、所要時間は約 40% 短かったとしています。
これは GitHub が発表したベンチマーク結果です。特定の評価環境での比較であり、あらゆるリポジトリやタスクで同じコスト・時間・品質になることを示すものではありません。実際の利用では、タスクの種類や選択されたモデル、組織のモデルポリシーによって結果が変わり得ます。数字を参考にしつつ、自分の作業での品質や費用も確認するのがよさそうです。
おわりに
Copilot Fusion は、Auto の「モデルを選ぶ」役割と、HydraFusion の「モデルを組み合わせて処理する」役割を、一つの選択肢にまとめたものです。利用者はモデル名を選ぶ代わりに effort level を指定し、プロンプトごとのモデル選択や実行パターンの判断を Copilot Fusion に任せます。
モデルを細かく選ぶ手間が減る一方で、利用者が指定するのはモデルそのものではなく、能力や推論の強さの方向性です。モデルごとに挙動を固定して比較したい場合と、タスクに応じた自動選択を活用したい場合は、目的に応じて使い分けることになりそうです。
まずはモデルピッカーから Copilot Fusion を選び、普段のタスクで Standard、High、Max の違いを試してみると、どの作業を任せやすいか見えてきそうです🧭