GitHub Copilotの「HydraFusion」がVS Codeとアプリへ - モデルではなく実行パターンを選ぶ仕組み
GitHubが2026年9月30日、複数モデルを組み合わせるHydraFusionの研究プレビューをVS CodeとCopilotアプリに広げた。課金は使ったモデルすべての標準レートで、自動モデル選択の割引は適用されない。仕組みと使い分けを整理する。
GitHubは2026年9月30日、HydraFusion の研究プレビューを Visual Studio Code と GitHub Copilot アプリで使えるようにしたとChangelogで告知した。これまで Copilot CLI だけだったものが、その外へ広がった形である1。同社は、より多くの利用面へ広げることが初期フィードバックで最も多かった要望だったとしている。
HydraFusion はモデルピッカーに並ぶが、モデルではない。公式ドキュメントは「モデルピッカーで HydraFusion を選ぶが、これはモデルではない。ランタイムでモデルをオーケストレーションするシステムだ」と書いている2。モデルを1つ選ぶ場合と比べて、選んだあとの挙動と請求の仕方が変わる。
Auto が選ぶのはモデル、HydraFusion が選ぶのは手順
Copilot には以前から自動モデル選択（Auto）がある。9月14日には efficiency / balance / intelligence の3段階が追加されたが、いずれもリクエストごとにモデルを1つ選ぶ仕組みである。
今回のChangelogは両者の違いをこう説明している。Auto はリクエストごとにモデルを選ぶ。HydraFusion は「1ターンの中でワークフローを選び、複数のモデルを調整する」ことを Copilot がどうできるかを探るものだ1。ドキュメントの言い方はもう少し端的で、自動モデル選択がリクエストごとに最適なモデルを選ぶのに対し、HydraFusion はタスクに対して最適な実行パターンを選ぶ、となっている。
実行パターンは現在3つある2。
| 実行パターン | 何が起きるか |
|---|---|
| Single | 1つのモデルがタスクを完了する |
| Cascade | 効率のよいモデルが解を下書きし、品質ゲートが受け入れるか、より強いモデルへエスカレートするかを決める |
| Critique | 1つのモデルが応答を下書きし、別のモデルファミリーのモデルがその下書きにフィードバックを与え、最初のモデルが1回だけ修正する |
どのパターンを使うかはプロンプトごとに選ばれる。最初のプロンプトが Single でも、続くプロンプトが Critique になることがあるとドキュメントは書いている。選ぶ工程自体は軽く、時間はほとんど増えず、応答のどの部分も生成しないという。Critique は Copilot CLI の rubber duck エージェントに似た形だとされている。
ワークフローの選択は最適化問題として扱われており、推論・コード生成・デバッグ・ツール利用のケイパビリティ信号を使って、品質の基準を満たす最も効率的な実行パターンを選ぶ1。使うモデルは速いモデルと推論の強いモデルの混成で、新しいモデルが入ったり同社が評価を更新したりするのに応じて構成は変わるため、固定のモデル一覧はない。利用者の側でどのモデルを使うかは選べない2。
請求は「使ったモデルの合計」になる
ここが選ぶ前に把握しておきたい点である。ドキュメントによれば、HydraFusion を使うと、使われた各モデルについてそのモデルの標準レートで課金される。HydraFusion 自体への別料金はないが、自動モデル選択の割引は適用されない。1つのタスクに複数のモデルを使いうるため、単一モデルの場合より多くの AI クレジットを消費することがある2。
キャッシュについては、主たる会話を可能なかぎり同じモデルに留めることでキャッシュされたトークンの恩恵を維持し、レビュアーなど補助するモデルには必要な文脈だけを渡すと書かれている。
コンテキストの扱いも独特だ。HydraFusion 自身のコンテキストウィンドウは存在せず、各ステップはそれを走らせるモデルの上限の中で動く。ピッカーに表示される値は、使うモデルのうち最小の上限に基づく保守的な数字で、現在の会話がそれより大きい場合は切り替える前にコンパクションを求められる2。
同社が挙げている使い分けはこうだ。Auto は日常業務向けで、リクエストごとに1つのモデルを選び、有料プランはモデルコストの割引を受ける。HydraFusion は、複雑なバグの修正や複数ファイルにまたがる変更のような、追加のモデルパスに時間と AI クレジットを払う価値があるかもしれない、まとまった範囲の明確なコーディングタスク向けである。素早い・定型のタスクには Auto を選ぶよう案内されている。Cascade と Critique はレビューのパスを含むため時間が長くなり、Single は1つのモデルへのリクエストとほぼ同じ挙動になるという。
破棄された下書きのファイル編集は戻らない
制約として明記されているもののうち、コミット前の手順に直接関わるのがこれである。HydraFusion が下書きを破棄した場合、その下書きがすでにワークスペースに加えた変更（ファイル編集など）は自動的には取り消されない。コミット前に変更を確認するようドキュメントは求めている2。
作業中は各ステップの進捗を追えるが、中間の下書きは修正・破棄されることがあるため、表示されるのは最終応答だけである。つまり、破棄された下書きの編集が手元に残っていても、画面には出ないという組み合わせになる。Claude Code・Cursor・Google Antigravity の動かし方を比べた記事でも、どこで結果を確認するかは3ツールで設計が分かれていた。確認の場所と粒度を決めておく話が、ここでは1ターンの内側にも入ってくる。
ほかに、HydraFusion はサブエージェントとは別に動作してサブエージェントを起動しない、研究プレビュー中は実行パターンと使うモデルが変わりうる、といった点が挙がっている。研究プレビュー中はサービスレベル契約（SLA）がなく、本番のワークロードを意図したものではないとも書かれている2。
有効化には管理者の許可が要ることがある
VS Code では1.140以降または VS Code Insiders が必要で、ピッカーに出ない場合は設定 chat.copilot.hydraFusion.enabled を有効にする1。Copilot アプリでは最新版に更新し、設定で「HydraFusion」を検索してオンにしてから、ピッカーで選ぶ。
組織やエンタープライズ経由で Copilot を使っている場合は、管理者が組織またはエンタープライズの設定でプレビュー機能を許可する必要があることがある。Changelogは対象を Copilot Pro、Pro+、Business、Enterprise の利用者としており、Business と Enterprise では管理者がプレビュー機能を有効にする必要があるとしている1。なお9月4日の研究プレビュー告知では、Copilot CLI の /experimental を通じて「すべての GitHub Copilot プラン」の利用者に提供するとされていた3。9月30日のChangelogと9月4日の告知はこの点で書き方が違い、どちらも差の理由には触れていない。
ドキュメント側には対象プランの列挙がなく、自分のプランで利用できて組織・エンタープライズのモデルポリシーで許可されたモデルしか使わない、使えるモデルがどれもなければモデルピッカーに現れない、という条件が書かれている2。Copilot Business / Enterprise向けの「新機能の既定ポリシー」は、プレビュー中の機能には適用されないと明示されている。プレビュー機能の可否はそれとは別の設定で決まるため、10月22日の発効を待っていても HydraFusion が開くわけではない。
ベンチマークは3件中2件で Opus 5 をわずかに下回る
9月4日の研究プレビュー告知には、3つのエージェント型コーディングベンチマークでの測定結果が載っている。比較のベースラインは Claude Opus 5 と GPT-5.6 Sol で、掲載されているのは最もよくチューニングした HydraFusion の構成の結果だという3。
| ベンチマーク | Opus 5 比のコスト | Opus 5 比の品質 |
|---|---|---|
| TerminalBench 2.1 | 67%低い | +4.9ポイント |
| DeepSWE | 36%低い | -1.5ポイント |
| CheckpointBench | 65%低い | -0.1ポイント |
同社の測定では、コストは3件すべてで36〜67%低い一方、品質が上回ったのは TerminalBench 2.1 の1件だけである3。品質の指標は verified task quality、つまり正しく答えたと確認されたタスクの割合で、コストは下書き・批評・修正・エスカレーション・リトライ・フォールバックまで含めた推定総額とされている。TerminalBench 2.1 については、同社自身が「比較的飽和している」ため広い検証が重要だと書いており、より難しいリポジトリ規模のタスクを含む DeepSWE を3件の評価に加えたと説明している。CheckpointBench は実際の Copilot のセッションから作った社内のマルチターンのベンチマークである。
測定条件の断りも押さえておきたい。同社は、これらは統制されたオフラインの結果で、評価したベンチマークのリビジョン・ワークフロー構成・モデルプール・価格の前提に固有のものであり、すべてのモデルを同じ medium の推論レベルで評価したとしている3。研究プレビューを通じて、この結果が実際の開発者のワークロードにどう移るかを検証するという。
ベースラインの名前と日付にも注意がいる。測定は9月4日の告知に載ったもので、ベースラインは Claude Opus 5 と GPT-5.6 Sol である。その後 Claude Opus 5.5（9月22日公開）や GPT-6.1 Sol（9月29日公開）が出ており、HydraFusion が使うモデルの構成も固定ではないとされている。数字は当時のモデルプールでの測定として読む必要がある。
何を確かめてから選ぶか
単一モデルを選ぶ操作と同じ見た目で、裏側の請求と挙動が変わる。選ぶ前に手元で確かめられるのは3点になる。
ひとつは費用の見え方で、同社は使ったモデルの確認方法として、VS Code では完了した応答のフッターに、Copilot アプリでは応答にホバーするよう案内している。Copilot CLI では /usage でセッション内の各モデルの AI クレジット消費が見られる2。もうひとつは、下書きが破棄されたときにワークスペースへ残る編集の扱いを、コミット前の確認手順に組み込めるかどうか。最後に、組織で使うならプレビュー機能の許可が下りているかどうかである。
同社は HydraFusion を、最良のモデルを選ぶことから、各タスクを解く最良の方法を動的に構成することへの移行であり、その考えへの最初の賭けだと位置づけている3。9月4日の時点では、中間の下書きを出さないために「十分な可視性がないまま待つことは開発者にとって現実のトレードオフだ」と認め、次は進捗更新の改善を検討するとしていた。今回のChangelogが挙げた改善点は、各ステップで何をしているかがより明確に見えること、進捗更新の頻度が上がったこと、長いタスクでも作業中だと分かりやすくなったことの3点で、そのトレードオフに当てた更新になっている1。
Sources
- HydraFusion in VS Code and the GitHub Copilot app - GitHub Changelog（2026年9月30日）
- Using HydraFusion - GitHub Docs（確認日2026年10月1日）
- Project HydraFusion: Frontier quality via multi-model orchestration - GitHub Blog（2026年9月4日。研究プレビューの告知とベンチマーク結果）
この記事は役に立ちましたか？
ありがとうございます！
受け取りました。ありがとうございます！