GitHub Copilot Fusionとは|3つの型と料金
「GitHub Copilotのモデル選択にCopilot Fusionという項目が増えた。選んでいいのか、料金はどうなるのか」——モデルを毎回自分で選んできた人ほど、任せてよいのか迷うところです。
結論から言うと、Copilot Fusionはモデルではなく、複数のモデルを依頼ごとに振り分けて組み合わせる仕組みです。2026年10月28日に一般提供が始まり、全プランで使えます。Fusionそのものの料金はなく、実際に使われたモデルの通常単価でAIクレジットが減ります。日常の作業はStandard、難しいバグや複数ファイルの変更だけHighかMaxを選ぶのが基本です。
株式会社Fyveは、AIに記事を書かせ、別のAIに監査させてから公開する無人の仕組みを、2026年7月から毎日回しています。Fusionの「Cascade」「Critique」は、私たちが手で組んできた形とほぼ同じです。この記事では公式の仕様を整理したうえで、自前で同じ形を運用してわかった落とし穴と、Fusionを選ぶときの判断の目安をお伝えします。
GitHub Copilot Fusionとは
Copilot Fusionは、GitHub Copilotのモデル選択画面で「特定のモデル」の代わりに選ぶ項目です。公式ドキュメントでは「実行時にモデルを振り分け、組み合わせる仕組み(runtime model router and orchestrator)」と説明されています。
利用者が選ぶのは強さの段階(Standard/High/Max)だけです。どのモデルを使うか、モデル同士をどう組み合わせるか、どこまで深く推論させるかは、Fusionがプロンプトごとに決めます。最後に返ってくる回答は1つです。
発表の日付と経緯
- 2026年10月28日:GitHubの変更履歴(Changelog)で一般提供を発表
- 土台は、研究段階で公開されていた「Project HydraFusion」(複数モデルの組み合わせ)と、既存の「自動モデル選択(auto model selection)」の2つ
- 研究プレビューでauto・HydraFusion・HydraFusion Maxを有効にしていた人は、対応するFusionの段階へ自動で移行
同じ日に、PCの中で動くローカルモデルにも振り分けられる機能が試験提供(experimental preview)として出ています。こちらは後の節で扱います。
使える場所
一般提供の対象は次の4つです(2026年11月1日時点)。
- Visual Studio Code
- GitHub Copilot CLI
- GitHub Copilotアプリ
- JetBrains IDE
ほかのクライアントは「近日対応」とされています。使うには、クライアントを最新版に更新し、モデル選択画面で「Copilot Fusion」を選び、続けて段階を選びます。
Copilot Fusionの3つの実行パターン
Fusionが内部で使う実行パターンは3つです。名前は公式のまま書きます。

パターン | 動き方 | 向く作業 |
|---|---|---|
Single | 1つのモデルがそのまま解く | 日常の小さな修正・質問 |
Cascade | 効率型のモデルが下書きし、判定役が点検して「そのまま通す」か「強いモデルに上げる」かを決める | 多くは軽く済むが、ときどき難しい依頼が混ざる作業 |
Critique | 1つのモデルが下書きし、複数のモデルが並行して指摘し、指摘をまとめて元のモデルが直す | 難しいバグ・複数ファイルにまたがる変更 |
パターンはプロンプトごとに変わる
どのパターンを使うかは、依頼に推論・コード生成・デバッグ・ツール操作のどの力が要るかと、選んだ段階から決まります。同じ会話の途中でも切り替わります。
公式ドキュメントによると、パターンを選ぶ処理で増える待ち時間はわずかで、レビュー役の呼び出しは「その作業に必要なときだけ」足されます。逆に言えば、CascadeやCritiqueが選ばれた回は、そのぶん応答に時間がかかります。
使われたモデルは後から確認できる
回答の下に出る段階名にカーソルを合わせると、その回答で使われたモデルが表示されます。作業中も、どの手順をどのモデルが担当しているかを追えます。画面に出る最終回答は1つだけです。
強さの段階(Standard・High・Max)と使えるプラン
段階は3つ、加えて利用者が選べない「Fast」が1つあります。
段階 | 優先すること | 想定する作業 |
|---|---|---|
Fusion Standard | 費用・品質・速さの釣り合い | 日常の作業。基本は1つのモデルで処理 |
Fusion High | 組み合わせを使いつつ、トークンもある程度節約 | 範囲がはっきりした重めの作業(難しいバグ、複数ファイルの変更) |
Fusion Max | 最上位の能力。トークン効率も考慮 | 最も深い推論と徹底した分析が要る作業 |
Fusion Fast | 速さ | VS Codeのインラインチャットでのみ使用(選択不可) |

StandardはFree・Student・Proを含む全プランで使えます。HighとMaxはPro+・Max・Business・Enterpriseだけです。無料プランやProでFusionを選んでも、使えるのはStandardまでということになります。
Copilot Fusionの料金:Fusion自体はタダ、モデル代は普通にかかる
料金の考え方は単純です。
- Fusionという機能に別料金はない
- Fusionが使ったモデルごとに、そのモデルの通常単価で課金される
- HighとMaxは1つの依頼で複数のモデルを呼ぶことがあるため、Standardより多くのAIクレジットが減ることがある
GitHub Copilotは2026年6月1日から、従来のプレミアムリクエストに代えて、入力・出力・キャッシュのトークン量に応じて「GitHub AI Credits」を消費する課金に移っています。各プランには料金と同額分のクレジットが毎月含まれています(例:Proは月額10ドルで10ドル分、Businessは1ユーザーあたり月額19ドルで19ドル分。2026年11月1日時点の公式発表による。最新の金額は公式の料金ページでご確認ください)。Fusionはこのクレジットを、使ったモデルの分だけ減らします。
有料プランの割引
有料プランの利用者は、Fusion経由のモデル費用が30%引きになります。変更履歴では「期間限定」、公式ドキュメントでは「2026年11月30日まで」と案内されています(2026年11月1日時点)。割引は条件が変わることがあるので、判断の根拠には通常単価を使うことをおすすめします。
GitHubが示した性能と費用の数字
GitHubは変更履歴で、外部評価「Artificial Analysis Coding Agent Index」でFusion Maxが60点を取り、Claude CodeとOpus 5.5 Maxの組み合わせとの差は2点以内だったと発表しています。そのうえで、1タスクあたりの平均API費用とトークン量はおよそ半分、所要時間はおよそ40%短かったとしています。
ただし、これはGitHub自身が発表した数字です。同じ点数でも、自社のリポジトリ・自社の作業で同じ結果になるとは限りません。私たちが自前の仕組みで学んだのは、「平均で安い」と「自分の作業で安い」は別物だということです。次の節で詳しく書きます。
Fyveの実運用から:Cascade・Critiqueと同じ形を自前で組んでわかったこと
私たちは2026年7月から、AIに記事を書かせる無人の仕組みを1日3回動かしています。そこで使っている形は、Fusionの3パターンとほぼ重なります。
Fusionのパターン | 私たちの運用で対応するもの | 始めた時期 |
|---|---|---|
Single | 決まった作業(集計・転記など)は1つの軽いモデルで最後まで処理 | 2026年7月 |
Cascade に近い | 作業の種類で使うモデルを分ける。機械的な作業は軽いモデル、実名で公開する文章は上位モデル | 2026年7月9日 |
Critique に近い | 書いたモデルとは別のプロセスで監査役のAIを起動し、通った記事だけを公開。落ちたら1回だけ直して再監査し、それでも落ちたら下書きに退避 | 2026年7月14日 |
違いは、私たちは作業の種類ごとに人がモデルを決めているのに対し、Fusionは依頼ごとに自動で決める点です。自前で回してみて、Fusionにも同じように当てはまると考える落とし穴が3つありました。
落とし穴1:レビュー役が知らないことは、レビューでも直らない
監査役のAIに「内容が正しいか」を判断させていた時期、新しく出たばかりの製品について、正しい記述を誤りとして落とし、本当の誤りを見逃すことが起きました。監査役のモデルも学習した時点までの知識しか持っておらず、新しい事実ほど両方向に外したのです。
2026年8月21日から、監査役には「内容の真偽」を判断させるのをやめ、「発表日が書かれているか」「出典がついているか」といった手続きの確認だけを任せる形に変えました。事実の確認は、書く段階で公式の情報を2つ以上当てることで担保しています。
FusionのCritiqueも、複数のモデルが指摘を出す仕組みです。指摘役が複数でも、全員が知らない新しいライブラリや社内だけの約束事は拾えません。Critiqueはテストやリンターの代わりにならないと考えて、手元の検査は残すべきです。
落とし穴2:どのモデルが動いたかを残さないと、品質の変化を追えない
私たちは一度、書き手を新しいモデルに上げたのに、監査役のモデルを別の場所で古い世代のまま指定していたことがありました。書き手は新しく、監査は一世代前という食い違いです。品質が揺れても原因の切り分けが難しく、モデルの指定を1か所にまとめて直しました。
Fusionでは、モデルの選択そのものが依頼ごとに変わります。しかも、選ばれるモデルの組み合わせは「時間とともに変わりうる」と公式に書かれています。結果がおかしいときは、段階名にカーソルを合わせてどのモデルが使われたかをまず確認する習慣をつけておくと、原因を追いやすくなります。
落とし穴3:レビューの仕組み自体が止まっても気づけない
2026年8月、監査役を起動するための認証が期限切れになり、25回続けて監査が「判定不能」になりました。判定できないときは公開しない設計にしていたので、誤った記事は出ませんでした。その代わり、書いた記事がすべて下書きに積み上がり、しばらく誰も気づきませんでした。
Fusionの場合、レビュー役が呼ばれたかどうかは利用者から見えにくくなっています。公式ドキュメントでも、レビューは「必要なときだけ」足すとされています。重要な変更ほど、Fusionが勝手に見てくれたはずと考えず、自分のレビュー手順を残すのが安全です。
Copilot Fusionを使うときの注意点
公式ドキュメントの「制限」と注意書きから、実務で効くものを抜き出します。
捨てられた下書きの変更は、自動では戻らない
Cascadeで下書きが不採用になり強いモデルに上がった場合でも、下書きの段階ですでにファイルを書き換えていたら、その変更は自動で取り消されません。公式ドキュメントにも「コミット前に変更を確認する」よう明記されています。
私たちの無人の仕組みでは、AIが書いてよいフォルダを決め、その外への変更はコミット前に機械的に捨てています。Fusionを使う場合も、git diffで差分を確かめてからコミットする、作業ブランチを切ってから任せる、といった基本をそのまま守るのが確実です。
コンテキストの長さは、組み合わせの中で一番短いモデルが基準
Fusionには独自のコンテキストウィンドウ(一度に読める量の上限)がありません。各手順は担当するモデルの上限の中で動きます。画面に出る上限は、候補のモデルの中で一番小さい値をもとにした控えめな数字です。大きなリポジトリ全体を読ませたい作業では、上限の大きいモデルを直接選んだほうがよい場面があります。
なお、Fusionは会話の主な部分をなるべく同じモデルに残し、キャッシュ済みのトークンを無駄にしないよう振り分けます。レビュー役のモデルには、必要な部分の文脈だけが渡されます。
サブエージェントとは別物
Fusionはサブエージェント(作業を分けて別のエージェントに任せる仕組み)を起動しません。「複数のモデルが協力する」という点は似ていますが、Fusionは1つの依頼の中でのモデルの組み合わせです。作業そのものを分割したいなら、サブエージェントやカスタムエージェントを使います。
使えるモデルは、プランと管理者の設定の範囲だけ
Fusionが選ぶのは、自分のプランと組織の設定で許可されたモデルだけです。次のモデルは候補から外れます。
- プランで使えないモデル
- 管理者が無効にしたモデル
- データの保存場所の指定(データレジデンシー)やFedRAMP準拠を求める設定で除外されたモデル
- 評価用(Evaluation)モデルを制限する設定で除外されたモデル
候補になるモデルが1つもない場合、Fusionはモデル選択画面に表示されません。「Fusionが出てこない」ときは、まず組織のモデル設定を確認してください。公式のコミュニティ掲示板でも、Businessプランの管理者から「管理画面にもVS Codeにも出てこない」という投稿があり、2026年11月1日時点で回答はついていません。
管理者向け:Copilot Fusionの設定
BusinessやEnterpriseで導入する場合、管理者ができることは変更履歴によると次の3つです。
- Fusionが選ぶモデルの一覧を確認する:どのモデルが候補になっているかを企業の設定画面で見られる
- モデルごとに、Fusionでの利用だけを止める:そのモデルを全員に禁止せず、Fusionの候補からだけ外せる
- Fusionを既定のモデルにする:Enterpriseの管理設定(managed settings)で、どの段階のFusionでも既定にできる
社内のデータの扱いで「このモデルは使わせたくない」という線がある会社は、Fusionを有効にする前に候補の一覧を確認しておくのが先です。Fusionは許可されたモデルの中からしか選ばないので、入口の設定がそのまま安全の線になります。
GitHubの発表では、通信会社のAT&Tが、開発者が「簡単なモデルに戻すのを忘れる」手間がなくなりトークン効率が上がった、とコメントしています。会社全体で既定をFusion Standardにする使い方は、この「戻し忘れ」を防ぐ意味があります。
ローカルモデルへの振り分け(試験提供)
2026年10月28日の別の変更履歴で、FusionがPCの中で動くローカルモデルとクラウドのモデルを振り分ける機能が、明示的に有効化する試験提供として公開されました。
項目 | 内容(2026年11月1日時点) |
|---|---|
対象モデル | MAI Code 1.1 Flash(Windows・対応機種)/Qwen3.8 Flash Next(Windows・macOS・Linux、Ollamaなどで用意) |
使える段階 | Fusion Standardのみ |
有効化(CLI) |
|
有効化(アプリ) | 設定の「Experimental」で「Local model auto routing」をオン |
有効化(VS Code) |
|
注意点は2つあります。1つ目は、ローカルで推論してもオフラインにはならないことです。どのモデルに振り分けるかの判断はクラウドで行われます。2つ目は、ローカルモデルの安全対策がクラウドのモデルと同じとは限らないことです。また、自分で追加したモデル(BYOK)は、追加しただけではFusionの振り分け対象になりません。
Copilot Fusionを選ぶか、モデルを自分で選ぶかの判断
ここまでの仕様と私たちの運用経験から、判断の目安をまとめます。
状況 | おすすめ | 理由 |
|---|---|---|
日常の小さな修正・質問が中心 | Fusion Standard | 軽いモデルで済む作業は安く済み、モデルを戻し忘れる心配もない |
難しいバグ・複数ファイルの変更 | Fusion High(足りなければMax) | CritiqueやCascadeが使われ、1つのモデルの見落としを減らせる |
結果を毎回同じ条件で比べたい(検証・ベンチマーク・定期処理) | モデルを直接指定 | Fusionはモデルの組み合わせが依頼ごと・時期ごとに変わる |
リポジトリ全体を一度に読ませたい | 上限の大きいモデルを直接指定 | Fusionの上限は候補の中で一番小さいモデルが基準 |
月のクレジットをきっちり管理したい | Standard中心+HighとMaxは必要なときだけ | High・Maxは複数のモデルを呼ぶ分、減り方が読みにくい |
私たち自身は、無人で毎日動かす処理ではモデルを直接指定する方針を続けます。設定し忘れたときに機械の既定値に任せないこと、結果が変わったときに原因を切り分けられることを優先しているからです。一方、人が画面の前にいて結果をその場で確認できる対話の作業なら、Fusion Standardを既定にしても困る場面は少ないと考えています。
関連記事
GitHub CopilotとMicrosoft 365 Copilotは名前が似ていますが、対象も料金も別の製品です。違いを整理した記事はこちらです。
開発用のAIとしてCodexと比べたい場合は、こちらで業務での選び方を比べています。
CodexとGitHub Copilot徹底比較|業務での選び方
上位モデルと中位モデルをどう使い分けるかを、Claudeのモデルで実測した記事もあります。Fusionの段階選びを考えるときの参考になります。
Claude Sonnet 5.5とOpus 5.5の使い分け|半額でどこまで足りるか
AIのレビューが的外れな指摘を返してきたときの対処は、こちらにまとめています。
まとめ
- Copilot Fusionは、モデルの代わりに選ぶ「振り分けと組み合わせの仕組み」。2026年10月28日に一般提供
- 実行パターンはSingle・Cascade・Critiqueの3つ。どれを使うかはプロンプトごとにFusionが決める
- StandardはFreeを含む全プラン、HighとMaxはPro+・Max・Business・Enterpriseのみ
- Fusion自体の料金はなく、使われたモデルの通常単価でAIクレジットが減る。High・Maxは減り方が大きくなりうる
- 捨てられた下書きの変更は自動で戻らない。コミット前に差分を確認する
- Critiqueはテストの代わりにならない。指摘役のモデルが知らないことは、指摘役が何体いても拾えない
株式会社Fyveでは、AIに書かせてAIに確かめさせる仕組みを自社で毎日動かしています。Fusionのような自動の振り分けと、自分で決めるモデルの指定をどう組み合わせるかは、作業ごとに答えが変わります。仕様は今後も変わりうるので、導入前にはGitHubの公式ドキュメントで最新の内容を確認してください。
御社の業務に合わせたCopilot導入・定着支援
「ライセンスを配ったのに使われない」を終わらせる。
業務の棚卸しから、効く業務の切り分け、社内への定着まで一貫して支援します。