GitHub Copilot の HydraFusion を使うと依頼内容に応じて実行パターンが自動で切り替わる
製造ビジネステクノロジー部の小林です。
これまで Copilot CLI だけで試せた HydraFusion のリサーチプレビューが、Visual Studio Code と GitHub Copilot アプリでも使えるようになりました。
HydraFusion がそもそも何をしてくれるものなのかを整理し、VS Code と Copilot アプリでの有効化と、実際に選んで使うところまで試してみました！
HydraFusion とは
HydraFusion はモデルピッカーに並びますが、それ自体は 1 つのモデルではありません。実行時に複数のモデルを連携させるしくみで、タスクごとに「どのモデルを、どんな流れで動かすと品質基準を満たしつつ一番効率がよいか」を選んでくれます。
推論・コード生成・デバッグ・ツール使用あたりの能力情報をもとに、実行パターンを最適化問題として選ぶ、というのが中身です。
選ばれる実行パターンは、いまのところ次の 3 つです。
- Single: 選ばれた 1 つのモデルがそのままタスクを解きます。シンプルなタスクでは、ほぼ 1 モデルに投げたときと同じ動きです。
- Cascade: まず効率のよいモデルが案を作り、品質ゲートがそれを採用するか、より高性能なモデルへ引き継ぐかを判断します。
- Critique: 1 つのモデルが案を作り、別のモデルファミリーのモデルが独立してレビューします。レビュー役は Copilot CLI の Rubber Duck と同じく、中身を書き換えずに指摘だけ返し、その指摘をもとに案を作ったモデルが 1 回だけ修正します。
Critique のレビュー役が参考にしている Rubber Duck の考え方はこちらにまとまっています。
図にすると、こういう分岐のイメージです。
HydraFusion を使うと何が嬉しいのか
HydraFusion を選んでおけば、「このタスクにはどのモデルを使うか」「別のモデルにも確認させるか」を自分で考えなくてよくなります。
モデルを選ばなくていい
モデルピッカーにはたくさんのモデルが並んでいて、タスクごとにどれを使うか迷いがちです。HydraFusion なら、お願いのたびに使うモデルと進め方を自動で決めてくれます。Copilot に新しく追加されたモデルも選択肢に入るので、新モデルが出るたびに選び直す必要もありません。
タスクに合わせて手数を変えてくれる
簡単な質問なら 1 つのモデルでそのまま答え、手間のかかるタスクには何段階かの工程を組みます。どのタスクにも最初から一番高性能なモデルを使い続けるより、ムダが少なくなります。
別のモデルのチェックが自動で入る
AI の回答が不安なとき、別のモデルに「この回答は合っている？」と聞き直すことがあると思います。HydraFusion はこれを 1 回のお願いの中でやってくれます。回答を作るモデルとは別系統のモデルがレビューし、必要ならその指摘をもとに修正します。手元に返ってくるのは最終的な回答 1 つだけなので、チャットの間で回答をコピペする必要もありません。
GitHub の研究ブログで公開されている TerminalBench 2.1 の結果によると、Claude Opus 5 と比べて品質が 4.9 ポイント向上し、推定コストは 67% 低くなったそうです。
VS Code で有効にする
VS Code はバージョン 1.140 以降、または VS Code Insiders が対象です。Copilot Chat のモデルピッカーから HydraFusion を選ぶだけです。
もしピッカーに出てこない場合は、設定 chat.copilot.hydraFusion.enabled を有効にします。settings.json なら次の 1 行です。
{
// リサーチプレビューの HydraFusion をモデルピッカーに出すためのフラグ
"chat.copilot.hydraFusion.enabled": true
}
Organization や Enterprise 経由で Copilot を使っている場合は、管理者が Organization / Enterprise 側でプレビュー機能を許可しておく必要があることがあります。ピッカーにも設定にも出てこないときは、まず管理者側の許可を確認するのがよさそうです。
GitHub Copilot アプリで有効にする
Copilot アプリ側は、設定からの有効化が一手間入ります。
- アプリを最新バージョンに更新する
- Settings（設定）を開き、「HydraFusion」で検索して有効にする
- モデルピッカーで HydraFusion を選ぶ
使ってみる
有効化できたら、あとは普段どおり Copilot Chat にお願いするだけです。ピッカーで HydraFusion を選んだ状態でタスクを投げると、「どの実行パターンを選んだか」「いまどのモデルが動いているか」が順に表示されていきます。
まず「HydraFusion について教えて」と聞いてみたところ、Critique が選ばれました。
「Using Critique: a solver will draft a result, a critic will review it, and the original solver will revise it if needed.」という宣言のあと、下書きを Claude Opus 5.5 が担当し（Draft pass）、別系統の GPT-6 Luna がレビュー役（Critique pass）に回っているのが、そのまま画面に流れてきます。
次に「簡単なタスクをこのモデルで実行して、挙動を比べてみる」とお願いしたところ、今度は Single が選ばれました（Using Single: one solver will work on your request.）。
お題は「src/config/env.ts の環境変数を必須／任意に分けて一覧にする」という読み取り専用タスクです。これを hydrafusion と標準モデルのサブエージェントで並行実行し、結果を比べました。
変数は 13 個、必須は 4 個（NEXT_PUBLIC_BASE_URL / NEXT_PUBLIC_GOOGLE_TAG_ID / NEXT_PUBLIC_HUBSPOT_PORTAL_ID / NODE_ENV）で、どちらも正解でした。
答えが 1 つに決まる簡単なタスクなので、差が出たのは説明の粒度と速さだけです。このくらいのタスクでは、HydraFusion は余計な手数をかけずに Single で済ませます。
ただ、hydrafusion の回答には「必須の文字列項目が z.string() だけで定義されているので、空文字列でも検証を通ってしまう」という指摘が含まれていました。これを次のお題にします。
送ったプロンプトはこちらです。
`src/config/env.ts` で、必須の環境変数が空文字列でも検証を通ってしまう問題を修正して。あわせてテストを追加して、`pnpm test` で通ることも確認して。
今回は Cascade が選ばれ、Main pass を GPT-6.1 Sol が担当しました
まずテストを追加して問題を再現し、そのうえで、空文字列を通してしまう必須項目 3 つの z.string() に .min(1) を付け修正は先にテストで問題を再現してから行われ、最後は全テストと型チェックが通ることまで確認されていました。
ここまでの 3 つのお願いで、Critique、Single、Cascade のすべてが使われました。説明を聞くときはレビューを入れ、簡単な調査は 1 モデルで済ませ、コードを変更するときはレビューの工程が付いた流れにする、といった判断を HydraFusion に任せられるのは便利ですね。
まとめ
HydraFusion が VS Code と Copilot アプリでも使えるようになり、いつものモデルピッカーから選ぶだけで、複数のモデルを組み合わせて使えるようになりました。
今回試した範囲では、説明を聞くときは Critique、簡単な調査は Single、コードの修正は Cascade と、お願いする内容によって実行パターンが切り替わりました。モデル選びやレビューの段取りを自分で考えずに済むので便利ですね。
一方で、簡単なタスクでは単体モデルとの差がほとんど出ず、応答が少し遅くなる場面もありました。複数ファイルにまたがる修正や原因の分からないバグ調査など、手数をかける価値のあるタスクで使うと、良さが出やすいと思います。
この記事がどなたかの参考になれば幸いです。
