GitHubは2026年10月28日、複数のAIモデルを使い分けてコーディング作業を支援する「GitHub Copilot Fusion」の一般提供を発表した。タスクの内容に応じて適切なモデルを自動的に選び、必要に応じて別のモデルによる判定やレビューを組み合わせる仕組みだ。従来のモデル自動選択機能と、複数モデルの連携を研究してきた「Project HydraFusion」の技術を統合したもので、VS Code、GitHub Copilotアプリ、Copilot CLI、JetBrains IDEから利用できる。
独立評価機関Artificial Analysisのベンチマークでは、Copilot CLIでCopilot FusionをMax設定で実行した場合、総合スコア60点、平均タスク費用5.59ドルを記録した。比較対象となるClaude CodeのOpus 5.5 Maxは総合62点、平均11.42ドルであり、Fusionは総合スコアで2点差に迫りながら、平均タスク費用を約半分に抑えたことになる。ただし、この結果はあらゆる開発作業で同等の品質や費用削減が得られることを意味しない。Copilot Fusionの特徴は単なるモデルの切り替えではなく、タスクに応じて判定やレビューを追加するかどうかまで自動的に決める点にある。
独立評価で総合60点、平均タスク費用は約51%低減
Artificial Analysisが10月28日に公開した評価は、AIモデル単体ではなく、コーディングエージェントの実行環境を含めた性能と費用を比較したものだ。「Coding Agent Index v2.0」では、3種類のベンチマークを等しい重みで組み合わせて総合スコアを算出している。Copilot Fusion Maxの総合スコアは60点で、Claude CodeのOpus 5.5 MaxとDevin Fusionはいずれも62点だった。なお、この総合スコアは複数の評価結果を合成した指標であり、60点をタスクの正解率60%と解釈することはできない。
費用面では、Copilot Fusionの平均タスク費用が5.59ドルだったのに対し、Claude CodeのOpus 5.5 Maxは11.42ドル、Devin Fusionは8.00ドルだった。Claude Codeを基準にすると、Copilot Fusionの平均タスク費用は約51.1%低い計算になる。ただし、これはベンチマークにおけるAPI費用ベースの平均値であり、実際のCopilot利用者が支払う料金や、成功したタスク1件当たりの費用を表すものではない。製品の月額料金や人間によるコードレビューの費用も含まれていないため、そのまま開発コスト全体の削減率に置き換えることはできない。
個別の評価を見ると、Copilot FusionはTerminal-Bench 4.0で71点、FrontierCodeで51点、SWE-Atlas-QnA-AAで57点を記録した。Terminal-Bench 4.0では比較対象の中で首位に立った一方、FrontierCodeではClaude CodeのOpus 5.5 Maxが56点、Devin Fusionが54点と、Copilot Fusionを上回っている。総合スコアが接近していても、ベンチマークごとの優劣は異なる。実際の導入では、自分が担当する開発作業に近い課題で性能を確認する必要がある。
トークン消費量にも大きな違いがあった。Artificial Analysisによると、Copilot Fusionは1タスク当たり平均720万トークンを使用し、Claude CodeのOpus 5.5と比べて約半分に抑えられていた。ただし、この比較だけでは、モデルの自動選択やキャッシュの活用、複数モデルの連携といった個々の仕組みが、費用削減にどの程度寄与したのかは分からない。今回の数値は、モデル単体の性能や単価ではなく、エージェント全体の実行方式を含めた評価結果として捉えるべきだ。
1つのモデルで処理するか、別のモデルに判定・レビューさせるかを自動選択
Copilot Fusionの基盤となったProject HydraFusionは、2026年9月4日に研究プレビューとして発表された。これは、単一モデルにすべての処理を任せるのではなく、最初の回答案の作成、品質判定、レビュー、修正、より高性能なモデルへの引き継ぎを、タスクに応じて組み合わせる仕組みだ。今回の一般提供では、こうした複数モデルの連携機能が、従来のモデル自動選択と統合され、通常のCopilot利用環境から使えるようになった。
GitHubの公式ドキュメントによると、Copilot Fusionは「Single」「Cascade」「Critique」という3つの実行パターンを使い分ける。Singleは1つのモデルで処理を完了する方式で、Cascadeは最初のモデルが作成した回答案を判定し、必要な場合により高性能なモデルへ引き継ぐ。Critiqueでは、別の複数モデルが回答案を独立して並列レビューし、その結果を集約して最初のモデルが修正する。各方式の違いを整理すると、次のようになる。
| 実行パターン | 処理の仕組み | 呼び出し回数・待ち時間への影響 |
|---|---|---|
| Single | 1つのモデルがタスクを処理する | 追加のレビュー工程は発生しない |
| Cascade | 最初の回答案を判定し、必要なら高性能なモデルへ引き継ぐ | 判定などの追加呼び出しが発生する |
| Critique | 複数モデルが並列レビューし、元のモデルが回答を修正する | レビューと修正の処理が加わる |
Singleでは追加のレビューを省くことで処理を簡潔にする一方、CascadeとCritiqueでは品質向上が見込める場合にだけ追加のモデル呼び出しを行う。これにより、簡単なタスクでは不要な計算や待ち時間を抑え、複雑なタスクには必要な処理を追加する設計となっている。ただし、追加の判定やレビューには費用と時間がかかるため、すべてのタスクで複数モデルを利用した方が効率的になるわけではない。
利用者が選択する「処理レベル」と、これらの実行パターンは別の概念だ。Copilot Fusionには「Standard」「High」「Max」という3つの主要な処理レベルがあり、Standardは日常的な作業で品質、費用、待ち時間のバランスを重視し、タスクごとに1つのモデルを選ぶ。Highは複雑だが作業範囲が明確な開発タスクを想定し、Maxは最も高度な推論や分析を優先する設定となる。HighやMaxが特定の実行パターンに固定されるわけではなく、同じセッションでも依頼内容によって異なる方式が選ばれる。
Copilot Fusion自体はすべてのCopilotプランで利用できるが、選択可能な処理レベルはプランによって異なる。Standardは全プランで利用できる一方、HighとMaxは対応するプランに限られる。また、利用可能なAIモデルも契約プランや組織のポリシーによって制限されるため、すべての利用者が同じモデル構成で処理を実行できるわけではない。
Artificial Analysisの10月28日の評価では、Copilot Fusionの候補モデルにAnthropicのClaude Opus 5.5とClaude Sonnet 5.5、OpenAIのGPT-6 AstraとGPT-6 Solが含まれていた。Copilot Fusionは、こうしたモデルの中からタスクの性質に合うものを選び、必要に応じて複数のモデルを連携させる。ただし、候補モデルの構成は固定ではなく、新しいモデルの追加やGitHubによる評価結果に応じて変更される。
複数のモデルを使い分ける場合、トークン消費量だけでなく、会話履歴の共有やキャッシュの再利用も費用に影響する。GitHubによると、Copilot Fusionは主となる会話で可能な限り同じモデルを使い続け、キャッシュされたトークンを再利用できるようにしている。一方、レビューなどを担当する補助モデルには必要な文脈だけを渡し、無駄な入力を抑える設計だ。モデルを切り替える際には、キャッシュの区切りや会話の複雑さの変化も考慮し、品質向上につながらない追加費用を避けるという。
こうした工夫は、複数モデルを利用しながら費用を抑えるための重要な仕組みだ。ただし、独立評価で確認された平均タスク費用の約51.1%という差について、キャッシュ効率やモデル選択、レビュー工程のそれぞれがどれだけ貢献したのかは明らかになっていない。ベンチマークで費用が安かったという結果と、実際の業務でどの程度の費用削減が得られるかは区別する必要がある。
平均タスク費用の51.1%減と、期間限定の30%割引は別
Copilot Fusionの利用そのものに追加料金は発生しない。ただし、内部で使用した各AIモデルには、それぞれの標準料金が適用される。特にHighやMaxでは、1つのタスクに複数のモデルを使用する場合があるため、Standardよりも多くのAIクレジットを消費する可能性がある。レビューや品質判定のために追加されたモデル呼び出しには、処理時間だけでなく費用も伴う。
GitHubは有料Copilotプランの利用者を対象に、2026年11月30日まで、Copilot Fusionで使用するモデルの費用を30%割り引くキャンペーンを実施している。ただし、この30%割引と、Artificial Analysisのベンチマークで示された平均タスク費用の約51.1%減は、まったく異なる条件で得られた数字だ。両者を単純に足したり掛け合わせたりして、実際の利用料金の削減率を算出することはできない。費用対効果を判断するには、各処理レベルで実際に消費するAIクレジットと、自分の開発作業に必要な処理量を確認する必要がある。
モデル選択は自動でも、ファイルの変更確認は不可欠
Copilot Fusionが利用できるモデルは、契約プランと組織の管理ポリシーによって決まる。GitHubの発表によると、企業や組織の管理者は、Copilot Fusionが利用できるモデルを制限できるほか、Fusionに限って特定のモデルを無効にすることも可能だ。つまり、モデル選択を自動化しても、組織が許可していないモデルが勝手に利用される仕組みではない。導入時には、どのモデルが選択候補となっているのかを確認する必要がある。
コンテキスト長にも制約がある。Copilot Fusionには独自のコンテキストウィンドウが存在するわけではなく、各処理は実際に使用されるモデルのコンテキスト上限内で動作する。また、Fusionの複数モデル連携はサブエージェントとは別の仕組みであり、Fusion自体がサブエージェントを起動することはない。複数モデルによるレビューと、独立したサブエージェントによる作業を混同しないことが重要だ。
さらに注意したいのが、生成されたコードやファイル変更の扱いだ。GitHubの公式ドキュメントでは、Copilot Fusionが途中で作成した回答案を破棄した場合でも、その案がすでにワークスペースに加えたファイル編集などは自動的に取り消されないと明記されている。つまり、最終回答に採用されなかった処理の変更が、作業ディレクトリに残る可能性がある。複数モデルによる判定やレビューが行われていても、最終的なファイルの状態まで自動的に保証されるわけではないため、コミット前の差分確認は欠かせない。
Copilot Fusionは、AIモデルの選択だけでなく、レビューや高性能モデルへの引き継ぎまで自動化することで、コーディングエージェントの品質と費用の両立を目指す仕組みだ。独立評価では、競合製品に近い総合スコアを維持しながら平均タスク費用を約半分に抑えたものの、その優位性がすべての開発作業に当てはまるわけではない。実際の導入では、必要な品質が得られるかに加え、処理レベルごとのクレジット消費量と待ち時間、そして生成されたファイル変更を適切に確認できるかが判断のポイントとなる。
