GitHub Copilot Fusion、モデル選びをやめて品質目標を選ぶ仕組みに

GitHub Copilotのモデルピッカーを開くと、Claude、GPT、Geminiと名前の違うモデルが並んでいる。簡単な修正に強いモデルを使えば待ち時間とクレジットの無駄になるし、難しいタスクに軽いモデルを選べば書き直しになる。そのたびにどれを選ぶか迷う人は多いはずだ。

GitHubは2026年10月28日、この選択自体をやめる機能「GitHub Copilot Fusion」を一般提供(GA)にした。選ぶのはモデル名ではなく、どこまでの品質が欲しいかという目標だけになる。モデルを何にするか、1つで済ますか複数を組み合わせるかは、タスクごとにCopilotが判断する(GitHub Changelog)。選ばない代わりに何をしていて、品質やコストはどう変わるのかを、公式ドキュメントで確かめた。

Fusionを選ぶと何が起きるのか

GitHubの公式ドキュメントは、Copilot Fusionを「タスクごとにモデルと実行パターンを選ぶランタイムのモデルルーター兼オーケストレーター」と説明する。モデルピッカーで選ぶのは特定のモデルではなく、このシステム自体になる(GitHub Docs「About GitHub Copilot Fusion」)。

リクエストが来るたびに、Fusionは次の3つを決める。

• どの実行パターンで動かすか
• 推論にどこまで力を割くか
• どのモデルに実行させるか

タスクの難易度やコード生成・デバッグの能力シグナルに加えて、その時点のモデルの稼働状況も考慮するという。ここまでを読んで、自分は最初、賢いおすすめモデル選択の延長だろうと思っていた。だが実行パターンの中身を見ていくと、Fusionが選んでいるのは1つのモデルとは限らないと分かった。

モデルを選ばず何を組み合わせるか

Fusionには3つの実行パターンがある。どれが使われるかはプロンプトごとに決まり、同じセッション内でも変わる(GitHub Docs)。

たとえば複数ファイルにまたがる複雑なバグ修正を1回頼んだとする。Single以外のパターンが選ばれれば、まず効率の良いモデルが下書きの修正案を作る。それを別のモデル(判定役)がチェックし、採用してよいレベルならそのまま返し、力不足と判断すればより能力の高いモデルに作業を投げ直す。Critiqueなら、複数のモデルが並行して下書きを読み、指摘を1つにまとめたうえで最初のモデルが書き直す。

つまり「モデルを選ばない」という説明は、手を抜いているのではなかった。人がふだん1人のモデルに頼むところを、必要なら複数モデルの下書き・判定・査読に置き換えている、ということだ。レビュー用の呼び出しが要らなければSingleのまま進むので、常に重い処理になるわけでもない。

この連携のしかたを決めたら、次はどこまで力を入れるかが残る。それを選ぶのが、ユーザーに見えるもう1つの軸になる。

effort levelは品質の目標

モデルピッカーでFusionを選んだあと、ユーザーが選べるのは「effort level」と呼ばれる品質目標で、4段階ある(GitHub Docs)。

ここで引っかかりやすいのが、effort levelは「使うモデルの強さ」を直接選んでいるわけではない、という点だ。High や Max を選んでも、必ず1つの強いモデルに固定されるのではない。実行パターンの選択は別に行われるので、effort levelを上げることは、むしろSingleで済ませず判定やレビューを挟む場面が増えることに近い。品質目標の高さと、モデルを何台連携させるかは別の軸で決まる。

Free・Student・Proの各プランで使えるのはFusion StandardとFastだけだ。HighとMaxは、Pro+以上の有料プランに限られる。自分のプランで何が使えるかは、この表で先に確認しておくとよい。品質目標とモデル連携の仕組みが分かったところで、次に気になるのは実際どれだけ得をするのかだろう。

品質とコスト・速度はどう変わるのか

実行パターンとeffort levelを整理すると、気になるのは「複数モデルを連携させる分、遅く・高くなるのではないか」という点だろう。GitHubが発表した数値は、その予想とは逆方向を向いている。

GitHubによれば、最上位設定のFusion Maxは独立したベンチマーク「Artificial Analysis Coding Agent Index」で60点を獲得した。最上位モデルの1つであるClaude Code(Opus 5.5 Max)との差は2点以内だったという。その一方で、タスクあたりの平均APIコストは約半分、使用トークン数も約半分、所要時間は約40%短かったという(TNW)。

ほぼ同じ品質を、コストと時間を抑えて出せる、というのがGitHubの主張になる。ただし、これはGitHub自身が示した数値であり、第三者が独立に再現した検証結果ではない。「2点以内」「約半分」「約40%」という表現はGitHubの言葉どおりで、得点の算出根拠やドル単位の実額は公開されていない。Microsoft CEOのSatya Nadella氏はLinkedInで「フロンティア級の品質を40%速く、最大77%低いコストで」とも述べている。ただしこちらは比較の基準が異なり、GitHubの数値とは単純に足し合わせられない(TNW)。

数字の出どころを一言で言えば、発表元が自社のベンチマークで測った結果だ。独立検証ではない、という留保を踏まえたうえでも、複数モデルを連携させる設計が速度とコストの両方で不利にならない、という方向性は読み取れる。あとは、自分が使っているエディタやプランで今すぐ試せるかどうかが残る。

自分の環境で今すぐ使えるのか

Fusionは2026年10月28日時点で、4つのクライアントに一般提供されている。対象はVisual Studio Code、GitHub Copilot CLI、GitHub Copilot app、JetBrains IDEだ。他のクライアントは「近日対応予定」とされ、まだ含まれていない(GitHub Changelog)。

Copilot appでの有効化は次の手順になる(GitHub Docs「Choosing a model」)。

1. モデル表示部分をクリックする
2. Copilot Fusionのスイッチをオンにする
3. effort levelを選ぶ

料金で押さえておく点は3つある。

• Fusion自体に追加料金はなく、実際に使われた各モデルの標準料金が課金される
• 有料プランは2026年11月30日まで、期間限定でモデル料金が30%割引になる
• HighやMaxは複数モデルを使う分、Standardより多くのAIクレジットを消費する場合がある

もう1つ、パブリックプレビューの段階にある機能がある。Fusion Standardは、手元のPCで動かしているローカルモデルを、適切な場面で選ぶ場合がある。対象はWindows向けのMAI Code 1.1 Flashと、Ollamaなどで導入したQwen3.8 Flash Nextだ。これを使うには実験的機能を有効にする必要がある。Copilot appなら設定の「Local model auto routing」を、Copilot CLIなら --experimental 起動か /experimental on をオンにする(GitHub Docs)。

Fusionは、Project HydraFusionという名前でテストされていたマルチモデル連携と、従来の自動モデル選択機能を組み合わせて作られた。以前のリサーチプレビューでauto・HydraFusion・HydraFusion Maxを有効にしていたユーザーの設定は、対応するeffort levelへ自動で移行される(GitHub Changelog)。

まとめ

GitHub Copilot Fusionは、モデルピッカーでモデル名を選ぶ操作を、品質目標(effort level)を選ぶ操作に置き換える機能だ。実際にどのモデルを使うか、1モデルで完結させるか複数モデルに下書き・判定・査読を分担させるか(実行パターン)は、リクエストごとにCopilotが判断する。

GitHubの発表では、最上位設定でも品質をほぼ保ったままコストと時間を抑えられるとされているが、これは発表元自身のベンチマークにもとづく。対応はVS Code・Copilot CLI・Copilot app・JetBrains IDEで、effort levelのHighとMaxはPro+以上のプランに限られる。モデルピッカーで毎回迷っていた人は、まずFusion Standardを試し、複雑な修正を任せる機会が増えたらHigh・Maxを検討する、という順番が試しやすい。