
GitHub Copilot Fusion入門 - モデル選びを任せる仕組みとeffortレベル、料金の考え方
当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。
GitHub Copilot Fusionは、モデルピッカーで選ぶ「モデル」ではなく、タスクごとに使うモデルと進め方を自動で決める仕組みです。2026年10月28日に一般提供(GA)になりました。利用者が選ぶのは、Standard、High、Maxの3つのeffortレベルだけです。
料金は、Fusionが実際に使ったモデルごとの通常料金をAI Creditsで払う形で、Fusion自体の追加料金はありません。有料プランでは、2026年11月30日までモデルの料金が30%割引になります。
この記事では、GitHubのChangelogと公式ドキュメント(2026年11月2日時点)をもとに、仕組み、effortレベル、料金、管理者の設定、使う前に知っておきたい制限を整理します。
Copilot Fusionとは
| 項目 | 内容 |
|---|---|
| 何か | 実行時にモデルを選び、組み合わせて動かすモデルルーター兼オーケストレーター |
| 一般提供 | 2026年10月28日 |
| 前身 | Project HydraFusion(2026年9月4日に研究プレビュー)と、Auto model selection |
| 選べるもの | effortレベル(Standard、High、Max) |
| 対応クライアント | Visual Studio Code、GitHub Copilot CLI、GitHub Copilotアプリ、JetBrains IDE |
| 対応プラン | すべてのCopilotプラン(使えるeffortレベルはプランで違う) |
| 料金 | 使ったモデルごとの通常料金。Fusion自体の料金はなし |
公式ドキュメントは、Fusionを「実行時のモデルルーター兼オーケストレーター」と説明しています。モデルピッカーでCopilot Fusionを選んでも、特定のモデルを選んだことにはなりません。プロンプトごとに、どのモデルをどの順番で使うか、どれくらい推論させるかをFusionが決め、最後に1つの回答を返します。
GitHubは、9月に研究プレビューとして出したProject HydraFusion(複数のモデルを組み合わせる仕組み)と、以前からあるAuto model selection(タスクに合うモデルを1つ選ぶ仕組み)を合わせたものだと説明しています。研究プレビューでAuto、HydraFusion、HydraFusion Maxを選んでいた人の設定は、対応するFusionのeffortレベルへ自動で移ります。
3つの実行パターン
Fusionは、プロンプトの内容とeffortレベルを見て、次の3つの進め方から1つを選びます。
| パターン | 動き |
|---|---|
| Single | 1つのモデルがそのまま解く。普通に1つのモデルへ頼むのと同じ |
| Cascade | 効率のよいモデルが下書きを作り、判定役のモデルがそれを採用するか、より強いモデルへ回すかを決める |
| Critique | 1つのモデルが下書きを作り、複数のモデルが並行して批評する。批評をまとめて、最初のモデルが直す |
パターンはプロンプトごとに選ばれるので、同じセッションの中でも、最初のプロンプトはSingle、次はCritiqueということがあります。パターンを選ぶ処理は軽く、待ち時間はほとんど増えないとされています。
モデルの呼び出しを増やすのは必要なときだけです。簡単なタスクで、要らない批評のために待たされたり、AI Creditsを使ったりすることはありません。逆に言えば、CascadeとCritiqueは確認のための呼び出しが入るぶん、Singleより時間がかかります。
使っている間は、いまどのステップをどのモデルで動かしているかが見えます。途中の下書きは直されたり捨てられたりするので、画面に出るのは最後の回答だけです。回答の下にあるeffortレベルの名前にカーソルを合わせると、使ったモデルの一覧が出ます。
effortレベル
| レベル | 何を優先するか | 向いている作業 |
|---|---|---|
| Fusion Standard | 料金、品質、速さのバランス | ふだんの作業。タスクごとに1つのモデルを選ぶ |
| Fusion High | 複数のモデルを組み合わせつつ、トークンをほどほどに節約 | 込み入ったバグの修正や、複数のファイルにまたがる変更など、範囲がはっきりした大きめの作業 |
| Fusion Max | トークンの効率も見つつ、最も高い能力 | とことん深い推論や、徹底した分析が要る作業 |
| Fusion Fast | 速いモデルだけを使う | 利用者は選べない。VS Codeのインラインチャットでだけ使われる |
High以上は、1つのタスクに複数のモデルを使うことがあるため、Standardより多くAI Creditsを使う可能性があります。
プランごとに使えるレベル
| レベル | Free | Student | Pro | Pro+ | Max | Business | Enterprise |
|---|---|---|---|---|---|---|---|
| Fusion Standard | 使える | 使える | 使える | 使える | 使える | 使える | 使える |
| Fusion High | 使えない | 使えない | 使えない | 使える | 使える | 使える | 使える |
| Fusion Max | 使えない | 使えない | 使えない | 使える | 使える | 使える | 使える |
| Fusion Fast | 使える | 使える | 使える | 使える | 使える | 使える | 使える |
個人のProではStandardまでで、HighとMaxを使うにはPro+以上が必要です。
Autoとの違い
Fusionが使えるクライアントでは、モデルピッカーに「Auto」ではなく「Copilot Fusion」が出ます。Autoは、Fusionに対応していない場所で引き続き使われます。
| 項目 | Copilot Fusion | Auto model selection |
|---|---|---|
| すること | モデルを選び、必要なら複数のモデルを組み合わせる | タスクに合うモデルを1つ選ぶ |
| 利用者が選ぶもの | Standard、High、Max | Efficiency、Balance、Intelligence |
| 主な提供先 | VS Code、Copilot CLI、Copilotアプリ、JetBrains IDE | GitHub.comのCopilot Chat、Copilot cloud agent、GitHub Mobile、Visual Studio、Xcode、Eclipseなど |
| 有料プランの割引 | 2026年11月30日まで30% | 10% |
どちらも、システムの稼働状況を見てモデルを選びます。また、キャッシュが切れる区切りや、会話の難しさが大きく変わったところでモデルを切り替えます。品質が上がらないのにキャッシュが無駄になるのを避けるためです。
料金
2026年6月から、Copilotの料金はAI Creditsによる従量課金に変わりました。1 AI Creditは0.01ドルで、モデルごとのトークン単価で計算されます。
Fusionを使ったときは、Fusionが使ったモデルそれぞれについて、そのモデルの通常の単価で課金されます。Fusionという仕組みへの別料金はありません。
- 有料プランでは、2026年11月30日まで、Fusionで使ったモデルの料金が30%割引になります。12月以降の扱いは、11月2日時点で公式ドキュメントに書かれていません(未確認)。
- HighとMaxは1つのタスクで複数のモデルを使うことがあるので、Standardより多くクレジットを使う場合があります。
- 会話の本筋は、できるだけ同じモデルで続けます。キャッシュされたトークンを使い続けられるようにするためです。批評役などの補助のモデルには、必要な文脈だけを渡します。
プランに含まれるクレジットを超えたくない場合は、AI Creditsの予算を0ドルにして「上限に達したら止める」を有効にする方法が、公式ドキュメントで案内されています。予算の考え方は、従量課金の記事にまとめています。
GitHubが示した性能の数字
Changelogには、Artificial AnalysisのCoding Agent Indexで、Fusion Maxが60点だったと書かれています。Claude CodeとOpus 5.5 Maxの組み合わせとの差は2点以内で、1タスクあたりの平均API料金は約半分、トークンは約半分、時間は約40%少なかったとしています。
これはGitHub自身の発表です。同じ条件での第三者の検証は、この記事の時点では確認できていません(未確認)。また、点数はタスクの種類によって変わるはずなので、自分のリポジトリで試して判断するのが確実です。Opus 5.5そのものについては、Claude Opus 5.5の記事で紹介しています。
ローカルモデルを使う(パブリックプレビュー)
Fusion Standardでは、手元のマシンで動かしているモデルを使わせることもできます。この機能はパブリックプレビューで、変わる可能性があります。
- Windowsで条件を満たすマシンなら、Copilot CLI、Copilotアプリ、VS CodeからMAI Code 1.1 Flashをダウンロードして入れられます。
- Copilot CLIでは、Ollamaなどで動かしているQwen3.8 Flash Nextを、Copilotが
qwen3.8-flash-next-localとして認識すれば、Fusion Standardが使えるようになります。こちらはWindows、macOS、Linuxで使えます。 - 使うには実験的な機能を有効にします。Copilotアプリでは設定の「Experimental」にある「Local model auto routing」、Copilot CLIでは
--experimentalを付けて起動するか、セッション中に/experimental onを実行します。
ローカルモデルを使うのはStandardだけで、HighとMaxでは使われません。特定のローカルモデルに確実に処理させたい場合は、Fusionではなく、そのモデルを指定したカスタムエージェントを作る方法も案内されています。
管理者が設定できること
Fusionは、企業や組織のモデルのポリシーで許可されたモデルだけを使います。次のモデルは、Fusionの選択肢に入りません。
- プランで使えないモデル
- 管理者のポリシーで外されたモデル
- データの保存場所(データレジデンシー)やFedRAMPに対応したモデルだけに絞るポリシーで、対象外になるモデル
- 評価用のモデル(Evaluation models)を禁じるポリシーで、対象外になるモデル
使えるモデルが1つもない場合は、モデルピッカーにCopilot Fusionが出ません。
Fusionに使わせるモデルを選ぶ
Enterpriseの管理者は、「AI controls」から「Copilot」を開き、「Models」の「Configure Copilot Fusion models」で、モデルごとにFusionで使うかどうかを決められます。ここで外しても、そのモデルを全員に対して禁止したことにはなりません。手で選べば使える状態のまま、Fusionの選択肢からだけ外せます。
Fusionを既定にする
Enterprise managed settingsで、新しい会話の既定のモデルをFusionにし、effortレベルも決められます。
{
"model": "fusion",
"fusionTier": { "overridable": "standard" }
}modelを"fusion"にすると、新しい会話の既定がFusionになります。利用者は会話ごとに別のモデルを選べます。fusionTierに"standard"、"high"、"max"のどれかを文字列で書くと、そのレベルに固定され、利用者やリポジトリの設定では変えられなくなります。"unmanaged"にすると管理しません。{ "overridable": "standard" }の形で書くと、企業の既定はStandardにしつつ、エンタープライズチームの設定ファイルで"high"などに上書きできます。fusionTierはeffortレベルを決めるだけで、モデルは選びません。modelと組み合わせて使います。- 対応バージョンは、Copilot CLIが1.0.104-3以降、VS Codeが1.144.0以降、Copilotアプリが1.1.33-4以降です。
エンタープライズでのCopilotの統制全般は、企業のAIコーディングツール導入の記事でも扱っています。
使う前に知っておきたい制限
公式ドキュメントに書かれている制限と注意点です。
- Fusionはサブエージェントとは別に動き、サブエージェントを起動しません。
- Fusionが下書きを捨てても、その下書きがワークスペースに加えた変更(ファイルの編集など)は自動では元に戻りません。コミットの前に変更を確認する必要があります。
- Fusion自体にはコンテキストウィンドウがありません。各ステップは、それを動かすモデルの上限の中で動きます。Fusionに表示されるコンテキストウィンドウは、使うモデルの中で一番小さい上限に合わせた控えめな値です。
- 使う実行パターンとモデルの顔ぶれは、これから変わる可能性があります。新しいモデルが出たり、GitHubがどのモデルの成績がよいかを評価し直したりするためです。
2つ目は特に大事です。エージェントとしてファイルを書き換える作業でCascadeやCritiqueが選ばれると、最終的に採用されなかった下書きの編集がワークスペースに残る可能性があります。git diffで差分を見てからコミットする習慣は、Fusionでも欠かせません。
データの扱いについて、Fusion独自の説明は、確認した範囲の公式ドキュメントにはありませんでした(未確認)。Fusionが使うのはポリシーで許可されたモデルだけなので、データレジデンシーなどの条件は、ふだんのモデルのポリシーで決まると考えられます(推測)。
同じ日の発表: GitHub EnterpriseにCopilotが含まれるように
同じ10月28日に、GitHub EnterpriseのライセンスにCopilotが含まれる形の提供も始まりました。
- GitHubまたはMicrosoftの営業担当と契約しているGitHub Enterprise Cloudの企業が対象です。自分で契約している企業向けには、段階的に提供するとしています。
- ライセンスを持つ全員がCopilotを使えます。機能とモデルはCopilot Enterpriseと同じですが、席ごとの毎月のAI Creditsは含まれません。
- AIの利用は最初のリクエストから企業の予算に対して従量で数えられます。コード補完と次の編集の提案は予算がなくても使えますが、Copilot Chat、Copilotのコードレビュー、Copilot in the cloudには予算が必要です。
- GitHub Enterpriseのライセンスを持たない利用者は、Copilot Standaloneとして1人月10ドルで同じ使い方ができます。
- Copilot BusinessとCopilot Enterpriseは、引き続き購入できます。
席数ではなく予算で管理する形になると、組織全体の既定をどのeffortレベルにするかが、そのまま支出に響きます。前の節のfusionTierは、この点で使いどころがある設定です。
どのレベルを選ぶか
ここからは筆者の考えです。
- まずはStandardを既定にします。タスクごとに1つのモデルを選ぶので、料金の見通しが立てやすく、強いモデルを選んだまま簡単な作業を続けてしまう無駄も減ります。
- 範囲のはっきりした大きめの修正で、Standardの結果が物足りないときだけHighに上げます。
- Maxは、設計の検討や原因の分からない不具合の調査など、時間とクレジットをかけてもよい場面に絞ります。
- 割引が11月30日までなので、その間に自分のリポジトリでStandardとHighを比べ、クレジットの使い方を見ておくと、12月以降の判断がしやすくなります。
GitHubのクラウドで動くエージェントについては、Copilot coding agentの記事も参考にしてください。
まとめ
- Copilot Fusionは、タスクごとにモデルと進め方(Single、Cascade、Critique)を自動で選ぶ仕組みで、2026年10月28日に一般提供になりました。
- 利用者が選ぶのはeffortレベルだけです。Standardは全プラン、HighとMaxはPro+、Max、Business、Enterpriseで使えます。
- 料金は使ったモデルごとの通常料金で、Fusion自体の料金はありません。有料プランでは11月30日まで30%割引です。
- 管理者は、Fusionに使わせるモデルを選んだり、managed settingsの
modelとfusionTierで既定を決めたりできます。 - 捨てられた下書きの編集は自動では戻らないので、差分の確認は欠かせません。
参考リンク
- Route and orchestrate models with GitHub Copilot Fusion(GitHub Changelog、2026-10-28)
- About GitHub Copilot Fusion(GitHub Docs)
- About GitHub Copilot auto model selection(GitHub Docs)
- Models and pricing for GitHub Copilot(GitHub Docs)
- Enterprise managed settings(GitHub Docs)
- Managing availability of models in your enterprise(GitHub Docs)
- Project HydraFusion: Frontier quality via multi-model orchestration(GitHub Blog、2026-09-04)
- GitHub Enterprise now includes access to GitHub Copilot(GitHub Changelog、2026-10-28)


