GitHub Copilot Fusionが正式提供、処理レベルを選んでモデル選びを任せる

スナック3行まとめ

  • GitHub Copilot Fusionが正式提供され、処理レベルを選んでモデル選択を任せられるようになりました。
  • High/Maxは複数モデルを使う場合があり、StandardよりAIクレジットを多く消費することがあります。
  • 下書きが破棄されても、すでに加えられたファイル変更は自動で元に戻りません。コミット前の差分確認が必要です。

GitHubは2026年10月28日、GitHub Copilot Fusionの正式提供を発表しました。開発者が作業に応じた処理レベルを選ぶと、Fusionがタスクごとのモデルと実行方法を選び、最終的な回答を1つ返します。従来の自動モデル選択と、Project HydraFusionの複数モデル連携をまとめた仕組みです。

GitHub Copilot FusionのStandard・High・Max選択画面
Copilot Fusionの処理レベル選択画面。資料:GitHub。

スナックガールズのひとこと

AIKO: 下書きをそのまま通すか、強いモデルにつなぐか。その分岐をタスクごとに追ってみたいです。

レッド: 複雑なバグを追うときに試してみたい! コミットする前に、変更されたファイルの差分はちゃんと自分で見るよ。

Standardは1モデル、High/Maxは必要に応じて連携

選択できる処理レベルはStandard、High、Maxの3段階です。Standardは日常的なコーディング向けで、タスクごとに1つのモデルを選びます。Highは複雑なバグ修正や複数ファイルにまたがる変更など、Maxは特に深い推論や綿密な分析が必要な作業を想定しています。

実行方法にも違いがあります。「Single」は1モデルで完結し、「Cascade」は効率のよいモデルが作った下書きを判定し、そのまま採用するか、より強力なモデルに引き継ぎます。「Critique」は下書きを別のモデルがレビューし、元のモデルが指摘を踏まえて修正します。

High/Maxでも、すべてのプロンプトで複数モデルを呼び出すわけではありません。必要に応じて実行方法を選ぶため、同じセッションでもプロンプトごとに構成が変わります。なお、Fusionはサブエージェントとは別の仕組みで、サブエージェントを起動しません。

対応する4環境と、プラン・管理者設定の範囲

FusionはすべてのCopilotプランで提供され、Visual Studio Code、GitHub Copilot app、Copilot CLI、JetBrains IDEsに対応します。利用するにはクライアントを更新し、モデル選択メニューからCopilot Fusionと処理レベルを選びます。

ただし、すべてのプランで全処理レベル・全モデルを使えるわけではありません。利用できるモデルは契約プランと組織・企業のポリシーに従い、対象モデルが1つも利用できなければ、Fusionはメニューに表示されません。

管理者はFusionに使用を許可するモデルを制限できます。企業向けの管理設定では、処理レベルを含めてFusionを既定にすることも可能です。

30%割引はサブスク料金ではなくモデル利用コスト

料金はFusionが使ったモデルごとに、そのモデルの通常料金で計算されます。Fusion自体の追加料金はありません。有料Copilotプランでは、2026年11月30日までFusion利用時のモデル利用コストが30%割引になりますが、サブスクリプション料金そのものの割引ではありません。

High/Maxでモデル呼び出しが増えると、StandardよりAIクレジットを多く消費することがあります。レビューを挟むCascadeやCritiqueは、1モデルで完結するSingleより時間もかかります。

下書きを捨てても、編集済みファイルは戻らない

Fusionが途中の下書きを採用しなかった場合でも、その下書きがワークスペース内ですでに行ったファイル編集は自動では取り消されません。画面に出る最終回答だけでなく、実際に変更されたファイルにも目を通す必要があります。

複数モデルによるレビューも、コードの正しさや安全性を保証するものではありません。コミット前には差分を確認し、意図しない変更が残っていないか確かめましょう。

出典・日付: 2026-10-30

関連ハッシュタグ
#GameSunakku #AI #GitHubCopilot #CopilotFusion #AICoding #DeveloperTools #生成AI #開発ツール

コメント

1

ログイン不要。投稿したブラウザから編集・削除できます。

すべてのコメント 1

한국어 · English · 日本語
  1. 오피셜메일KR

    초안 채택 여부와 작업 공간의 파일 변경을 따로 봐야 한다는 마지막 주의사항이 가장 실무적으로 읽힙니다. 검토 모델의 피드백이 최종 답변에 반영됐더라도 diff·테스트·남은 파일을 따로 확인하는 완료 기준이 필요하겠네요. 강도별 비교를 할 때도 응답 품질뿐 아니라 한 작업을 마무리하는 데 든 전체 호출 비용을 같이 적으면 선택 이유가 더 분명해질 것 같습니다.

この記事をシェア