GitHub Copilotの使い方：Fusionの設定とモデル選択を実務で試す

本記事は、2026年10月29日時点のGitHubの公開ドキュメントと発表内容を確認して執筆しています。ドキュメントに基づく評価であり、実機で測定したベンチマークではありません。

GitHub Copilot Fusionで何が変わるのか

GitHub Copilot Fusionは、モデルの選択と、必要に応じたモデル間の連携を引き受けます。 技術リードが変更内容を見て、すぐに実装すればよいのか、レビュアーを入れるべきか、より高度な対応に回すべきかを判断する、と考えるとわかりやすいでしょう。何を実行するかを定義し、生成されたコードを採用できるか判断するのは、引き続き利用者の役割です。

GitHubは2026年10月28日にFusionの一般提供を開始し、Project HydraFusionのオーケストレーションとAutoのモデル選択を統合しました。従来のAuto、HydraFusion、HydraFusion Maxは、それぞれ対応するFusionの推論レベルへ移行します。つまり、10月の研究プレビューはFusionの前身であり、Fusionと併用する別製品ではありません。GitHubによるFusionの発表。

実行パターンとは、処理をどのように分担して進めるかを指します。

• Single： 1つのモデルがタスクを直接処理します。
• Cascade： ドラフトを判定役に渡し、そのまま採用するか、より高度な処理に回すかを判断します。
• Critique： 別の視点からドラフトを批評し、その指摘を受けて作成元のモデルが修正します。

これらのパターンは、GitHubのHydraFusion研究で示されたものです。現在のFusionのドキュメントでは、複数の批評役が並列にレビューし、そのフィードバックを統合する仕組みが説明されています。ただし、すべてのプロンプトで全パターンが実行されるわけではありません。Fusionの動作。

たとえば、ラベルの修正と競合状態の調査に、常に同じ処理を割り当てる必要はありません。Fusionはセッション内でその振り分けを行います。背景にある「作業に合った能力を選び、その選択が役に立ったかを測る」という考え方は、モデルルーターの解説で詳しく扱っています。

Fusionはどこで使える？有効化の手順

FusionはCopilotアプリ、Visual Studio Code、Copilot CLI、JetBrains IDEで利用できます。 GitHubは、これらの対応環境とCopilotの各プランでの提供について案内しています。ただし、すべてのアカウントで同じ推論レベルを使えるとは限りません。利用できるモデルには、プランとポリシーによる制約があります。現在の提供状況。

以下の手順を試す前に、クライアントを更新してください。以前のHydraFusionプレビュー用スイッチは、現在のFusionを設定する手順とは異なります。

GitHub Copilotアプリでの設定

プロンプト入力欄の下にあるモデル名をクリックし、Copilot Fusionをオンにして、表示される推論レベルを選びます。特定のモデルを指定する使い方に戻すには、スイッチをオフにして、そのモデルを選択します。選んだ設定は、以後のセッションでも保持されます。アプリでのモデル選択。

Visual Studio Codeでの設定

設定でchat.copilot.dynamicAutoTiers.enabledが有効になっていることを確認します。モデルとエージェントのツールを接続する実行基盤であるCopilot harnessを使い、新しいチャットを開始してください。モデル選択メニューでCopilot Fusionを選び、利用可能なレベルを指定します。この設定を有効にするだけで利用権限が付与されるわけではありません。利用できるFusionのレベルがない場合は、メニューにAutoが表示され続けることがあります。VS Codeでの設定手順。

GitHub Copilot CLIでの設定

対話セッションで/modelと入力し、Fusionと推論レベルを選んで確定します。範囲を絞って最初に試す方法として、GitHubは次のコマンド形式を案内しています。この例では、ファイルを編集せずに分析するよう指示しています。

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

これが現在のFusion用オプションです。以前のHydraFusionの実験用フラグは使いません。CLIでのモデル選択。

Fusionが利用できるモデルは何か

ここで挙げるClaude/GPTのモデル群は、ある時点の構成であり、今後も同じ振り分け先が保証されるわけではありません。 GitHubは2026年10月14日のHydraFusion更新で、次のモデルを明示しています。

• AnthropicのClaude Opus 5.5。
• OpenAIのGPT-6 Astra。
• OpenAIのGPT-6.1 Sol。
• OpenAIのGPT-6 Luna。

この更新では、HydraFusion Maxに加え、ドラフト作成とレビューでより深く推論する仕組みも導入されました。上記は、プレビューの発表で確認できるモデル名です。10月のモデル構成更新。

現在のFusionの概要ページには、固定されたクラウドモデルの完全な一覧は掲載されていません。モデル群は変更されると説明されており、回答の下にある推論レベルのラベルにカーソルを合わせると、実際に使われたモデルを確認できます。Copilotのモデルカタログに載っているモデルすべてに、Fusionが振り分けると考えないでください。現在のモデル群の扱い。

開発リードにとって実務上重要なのは、自分たちのアカウントで許可されているモデル群です。Enterpriseのオーナーは、AI controls → Copilot → Models → Configure Copilot Fusion modelsから設定を開けます。ここで選んだモデルにも、ユーザーに適用される他のモデルポリシーの制約が及びます。Enterpriseのモデル管理。

ローカルモデルへの振り分けには、別のプレビューがあります。StandardでMAI Code 1.1 FlashまたはQwen3.8 Flash Nextを使う、特定の構成に対応しています。任意のローカルモデルを追加しても、Fusionの選択対象になるわけではありません。また、推論をローカルで実行しても、振り分けはクラウドで行われるため、Fusionがオフラインで動くようにはなりません。ローカルモデル利用の制約。

まずStandardを選び、必要に応じて推論レベルを上げる

最初はStandardを選び、追加レビューで何を確かめたいのかが明確になってからHighやMaxを使いましょう。 GitHubは、Standardを日常的なコーディング向け、Highを難しいタスクや深い推論向け、Maxを最も高度な作業向けと位置づけています。推論レベルの定義。

以下のタスク例は編集部としての提案であり、実測した性能を示すものではありません。

「アプリケーション全体を改善してほしい」といった曖昧な依頼は、Maxの評価には向きません。成功の条件を決めていなければ、追加の推論が役立ったか判断できないからです。たとえば「リトライの挙動を保ちながら、重複したリクエスト経路をなくす」のように、結果を確認できる問題に絞りましょう。

Fusion Maxは推論レベルの選択肢であり、加入が必要なサブスクリプションの名称ではありません。 Fusion Fastもありますが、ユーザーが選択することはできず、VS Codeのインラインチャットに限定されています。推論レベルの選択肢。

FusionのAIクレジットはどう消費されるのか

課金は、選ばれたモデルが実行した処理に応じて発生します。 入力・出力・キャッシュ済みトークンにはモデルごとの料金が適用され、該当する場合はキャッシュ書き込み料金も加わり、その額がAIクレジットに換算されます。Fusionのタスクごとに固定で消費するクレジット数は公表されていません。GitHubの課金の仕組み。

Fusionには、オーケストレーション専用の追加料金はありません。有料Copilotプランでは、現在、2026年11月30日までFusionのモデル利用料金が30%割引になります。Fusionの課金。プランの違いや利用枠については、GitHub Copilotの料金ガイドで説明しています。

ドラフト作成、批評、修正は、それぞれ使用量に加算されます。推論の深さ、コンテキストの大きさ、ツールの実行、キャッシュも消費量に影響します。そのため、振り分けが設計どおりに動いていても、複数の処理段階を経る実行は、単一モデルへのリクエストより多くのクレジットを使う場合があります。VS CodeによるAIクレジット消費の説明。

試用時は、失敗した試行と修正用のプロンプトも数えてください。安く生成できても修正を繰り返すドラフトは、費用が高くても採用できる変更を出す実行に、結果として負けることがあります。逆に、単純な名前変更への批評にお金をかけても、得るものがないかもしれません。回答1回の安さではなく、作業が完了するまでを比較しましょう。

GitHubのベンチマークからわかること、わからないこと

GitHubの報告は有望ですが、自分たちのリポジトリでどれだけ節約できるかを示すものではありません。 GitHubはUniverseでの発表で、次のように述べています。

評価に使われたのはArtificial Analysis Coding Agent Indexです。これはGitHubが報告したベンチマーク上の主張であり、本記事のために独立したテストを実施した結果ではありません。GitHub Universeでの発表。

詳細な変更履歴では、比較対象はOpus 5.5 Maxを使ったClaude Code、コストの指標はタスクあたりの平均APIコストとされています。「FusionならCopilotの請求額が半分になる」という話よりも、対象が限定されています。GitHubのベンチマークの前提。

ここから読み取れるのは、常に高性能で負荷の大きい構成を選ぶよりも、オーケストレーションによって優れた結果を効率よく得られる可能性です。すべてのバグ修正が速く、安くなるとまで言う根拠はありません。自分たちにも同じ効果があるかは、タスクの構成、採用基準、修正作業によって決まります。また、期間限定の料金割引とベンチマークの比較は別の話です。両者を組み合わせて、節約額が保証されるかのように考えないでください。

開発者・開発リード・導入担当者が見るべきポイント

開発者にとっては、モデル選びの手間を減らす選択肢です。 次のタスクをどのモデルに任せるか考えるために、何度も作業を中断しているなら、範囲を絞ってFusionを試す価値があります。課題の説明、期待する挙動、レビュー基準は明確に保ちましょう。選択を任せる目的は、気を取られる要因を減らすことです。タスクの指示まで曖昧にしてよいわけではありません。

開発リードには、推論レベルの運用ルールと、変更を採用した記録が必要です。 日常業務にはStandard、レビューが必要な範囲の明確な変更にはHigh、Maxは理由をもって選ぶ、というルールから始めるとよいでしょう。レベルを上げたことが、なぜ役立ったのかも記録します。そうしなければ、出荷する成果が改善した証拠もないまま、最上位のレベルを選ぶことが習慣になりかねません。

CopilotをClaude CodeやCursorと比較する導入担当者は、実際に採用するワークフローを検証すべきです。 ベンチマークは候補を評価するきっかけにはなりますが、組織全体を移行させる根拠にはなりません。クレジットだけでなく、レビューの負担、リポジトリとの相性、完了した成果も評価してください。より広い観点で選ぶ際は、Claude CodeとGitHub Copilotの比較が参考になります。Fusionが変えるのは、その判断の一部です。

過大評価しないために：Fusionを使わない方がよい場合

関与するモデルが増えても、差分を確認する責任はなくなりません。 GitHubが明記する制約の中でも、特に影響が大きいのは、破棄されたドラフトのファイル編集が残る可能性です。また、Fusionには複数モデルをまとめた独自のコンテキストウィンドウはなく、サブエージェントも起動しません。Fusionの制約。

条件を揃えた比較、再現性を重視する調査、明示的に承認されたワークフローのために特定のモデルが必要なら、Fusionはオフにしておきましょう。モデルを固定し、振り分けが新たな変動要因にならないようにします。それで言語モデルの出力が決定的になるわけではありませんが、変動要因を1つ減らせます。

使い慣れた特定モデルの構成で、範囲の明確なタスクをほとんど修正せずに処理できているなら、試用で実益が確認できるまでは、今の使い方を変える必要はありません。切り替えは義務ではありません。

オフラインで動くワークフローが必要な場合や、採用できる変更の条件を定義してレビューできない場合も、導入を待つべきです。ごく小さな定型の依頼なら、Standardは使い続けつつ、モデル間の連携が多い推論レベルを使わない方が適切かもしれません。「Maxを使わない」と「Fusionを使わない」は、別の判断です。

GitHub Copilotの使い方を試す：今週は1つのリポジトリから

すべての結果を確認できる規模で試しましょう。 よく知っているリポジトリを選び、Fusionと普段使っているモデル構成を比較します。

今週やることは、そのリポジトリの開発担当者とレビュアーを決め、採用のためのチェック項目を合意し、実際の変更を見てから標準の構成を決めることです。最速の回答を撮ったスクリーンショットよりも、判断の理由を読み取れる記録の方が役に立ちます。

AI開発ツールの選び方と運用に役立つ実践ガイドを受け取るには、ニュースレターに登録してください。