HydraFusionは、GitHub Copilotがタスクごとに使うモデルと実行パターンを選び、複数のモデルを1つのターンの中で連携させる仕組みです。モデルピッカーに並びますが、それ自体はモデルではありません。2026年9月4日にCopilot CLIの研究プレビューとして公開され、9月30日にはVS Code 1.140とGitHub Copilotアプリでも選べるようになりました。この記事では、Single・Cascade・Critiqueの3パターンの動き、VS CodeとCLIで有効にするコマンドと設定、AI Creditsの課金、破棄された下書きなどの制限、Autoとの使い分けまでを実装者向けに整理します。
まとめ：HydraFusionを試す前に押さえるAutoとの違いと課金の要点
HydraFusionが向くのは、複数ファイルにまたがるバグ修正のように範囲がはっきりした大きめのコーディング作業です。公式ドキュメントは、日常の作業にはリクエストごとに1モデルを選ぶAutoを、大きく範囲の明確な作業にはHydraFusionを勧めています。定型作業に常用すると、レビュー段階のぶんだけ遅くなり、クレジットも多く減ります。
課金は、裏で動いた各モデルの標準レートの合算です。HydraFusion自体の追加料金はありませんが、Autoの割引は効きません。有効化はVS Codeなら1.140以降で chat.copilot.hydraFusion.enabled をオン、CLIなら実験的機能をオンにして /model から選びます。Business・Enterpriseでは管理者のプレビュー機能許可が先に要ります。
注意すべき制限は1つです。採用されなかった下書きが加えたファイル変更は自動で戻りません。試すときは作業用ブランチを切り、コミット前に差分を必ず見てください。
HydraFusion：Single・Cascade・Critiqueの実行の仕組み
まず、HydraFusionが裏で何を選んでいるのかを押さえます。ここを理解しておくと、遅い・高いと感じたときに原因を切り分けられます。
モデルではなく実行パターンとモデルを選ぶランタイムのオーケストレーター
GitHubの公式ドキュメント「Using HydraFusion」は、HydraFusionを「実行時に複数モデルを組み合わせるモデルオーケストレーター」と位置づけています。プロンプトを受け取るたびに、推論・コード生成・デバッグ・ツール利用といった能力の情報をもとに、品質基準を満たす中で最も効率のよい実行パターンを決めます。
パターンの選択はほとんど時間を使わず、応答の中身も生成しません。プロンプトごとに選び直すため、同じセッションの中でも1回目はSingle、2回目はCritiqueということが起こります。使うモデルは固定の一覧ではなく、新しいモデルの登場やGitHub側の評価で入れ替わります。利用者がモデルを指名することはできません。
3パターンの処理の流れとレビュー段階の有無、実行所要時間の比較
2026年10月時点で用意されているパターンは3つです。違いはレビュー段階を挟むかどうかにあります。
| パターン | 処理の流れ | レビュー段階 | 時間・消費の傾向 |
|---|---|---|---|
| Single | 選ばれた1モデルがそのまま解く | なし | 1モデルへの依頼に近い |
| Cascade | 下書き→品質判定→採用か上位モデルへ引き継ぎ | 品質ゲート | 引き継ぎが起きると増える |
| Critique | 下書き→別系統がレビュー→下書き側が1回修正 | 別系統のレビュー | 3パスぶん長くなる |
Cascadeでは、効率のよいモデルが下書きを作り、品質ゲートがそのまま採用するか、上位モデルへ引き継ぐかを判定します。Critiqueでは、1モデルが作った下書きを別のモデル系統が読み取り専用でレビューし、下書きを作ったモデルが1回だけ修正する流れです。
Critiqueのレビュー役は、Copilot CLIのラバーダックエージェントと同じ考え方で、内容を書き換えずに指摘だけを返します。途中の下書きは修正や破棄の対象になるため、画面に出るのは最終の応答だけです。
Autoとの違いはリクエスト単位の1モデル選択か1ターン内の複数モデル連携か
Autoはリクエストごとにモデルを1つ選ぶ機能で、有料プランではモデル費用に割引が付きます。HydraFusionは1回のターンの中で、ワークフローそのものを選んで複数のモデルを動かす仕組みです。どちらも「モデルを自分で決めない」点は同じですが、Autoは振り分け、HydraFusionは組み立てと捉えると判断しやすくなります。
VS Codeのモデルピッカーでも、HydraFusionはAutoのすぐ下に表示されます。迷ったらAutoを既定にしておき、大きな修正だけHydraFusionへ切り替える運用が扱いやすい形です。
VS Code 1.140でHydraFusionを有効にしてモデルピッカーから選ぶ手順
VS Code 1.140のリリースノート（2026年9月30日公開）には、HydraFusionによるモデル調整が研究プレビューとして載っています。ここでは個人環境での有効化から、表示されないときの確認までを順に追います。
設定エディタとsettings.jsonによるHydraFusionの有効化手順
利用する環境はVS Code 1.140以降かVS Code Insidersです。設定エディタ（Windowsは Ctrl+,、macOSは Command+,）で chat.copilot.hydraFusion.enabled を探し、チェックを入れます。チームで設定をそろえたい場合は、ユーザー設定のsettings.jsonに次の1行を足す方法でも同じ状態になります。
{
// HydraFusion（研究プレビュー）をモデルピッカーに出す
"chat.copilot.hydraFusion.enabled": true
}設定後にCopilot Chatのモデル選択ドロップダウンを開き、Autoの下にあるHydraFusionを選びます。応答が終わったら、応答のフッターにカーソルを合わせると、実際に使われたモデルが確認できます。
モデルピッカーにHydraFusionが出ないときに確認する4つの順番
表示されない原因は、公式ドキュメントのトラブルシューティングにまとまっています。上から順に潰すと、無駄な再インストールを避けられます。
- VS Codeのバージョンが1.140以降か（ヘルプのバージョン情報で確認）
chat.copilot.hydraFusion.enabledがオンになっているか- 組織・エンタープライズ経由の契約なら、管理者がプレビュー機能を許可しているか
- プランとモデルポリシーで使えるモデルが1つ以上残っているか
4番目は見落としやすい項目です。HydraFusionは、利用者のプランで使え、かつ組織のモデルポリシーで許可されたモデルしか呼びません。使えるモデルが1つも無いと、ピッカーそのものから消えます。
Business・Enterpriseでは管理者のプレビュー機能許可が前提条件
2026年9月30日のGitHub Changelogは、対象をCopilot Pro・Pro+・Business・Enterpriseの利用者とし、BusinessとEnterpriseでは管理者がプレビュー機能を有効にする必要があると書いています。一方、9月4日の研究記事は全プランで使えると説明しており、公式ドキュメントにはプランの一覧がありません。Freeプランで使えるかは、自分の環境のピッカーで確かめるのが確実です。
組織で入れる場合、HydraFusionは許可済みモデルの範囲で複数の提供元のモデルへコードを渡します。どのモデル系統までを許可するかは、モデルポリシー側で先に決めておく論点です。
Copilot CLIでHydraFusionを試すコマンドと単発実行のスクリプト例
HydraFusionが最初に提供されたのはCopilot CLIです。進行状況の表示やデバッグログの取得はCLIのほうが細かく、挙動を確かめるならCLIから入ると原因を追いやすくなります。
Copilot CLIの実験的機能の有効化とHydraFusionの選択手順
公式ドキュメントの手順は次の3段です。セッション中なら /experimental on を入力してからCLIを再起動しても同じです。
# 1. CLIを最新版にする
copilot update
# 2. 実験的機能をオンにして起動する
copilot --experimental
# 3. セッション内でモデル一覧を開き、
# 「HydraFusion (Research Preview)」を選ぶ
/model実行中は、使われているパターン、各パスの状態（完了・実行中・保留）、現在の処理、経過時間が表示されます。Escで中断でき、完了後の会話に残るのはパターンと各ステップの要約です。それでも一覧に出ない場合は、早期評価用で不安定になり得る /update prerelease を試す選択肢も案内されています。
-pで単発実行して作業ブランチに隔離するシェルスクリプトの例
スクリプトから1回だけ実行するときは copilot --experimental --model hydrafusion -p "プロンプト" の形を使います。CLIを非対話で動かす公式ガイドは、許可するツールを --allow-tool で必要最小限に絞るよう勧めています。この2つを組み合わせ、作業ブランチを切ってから実行し、終わったら差分だけを表示する例が次の通りです。
#!/usr/bin/env bash
set -euo pipefail
# 作業用ブランチに隔離してから実行する
git switch -c "try/hydrafusion-$(date +%Y%m%d%H%M)"
copilot --experimental --model hydrafusion \
--allow-tool='write, shell(git:*)' \
-p "src/billing 配下の端数処理の不具合を修正し、関連テストを更新してください"
# 下書きの採否に関係なく、変更されたファイルを必ず確認する
git status --short
git diff --statファイル書き込みとgitコマンドだけを許可し、パッケージのインストールなどは通さない設定にしています。サンドボックス以外では --allow-all のような広い許可を避けるよう、同じガイドに注意書きがあります。
Copilot CLIでのクレジット消費と実行パターンの記録方法
CLIで /usage を入力すると、そのセッションで各モデルが使ったAI Creditsの内訳が出ます。どのパターンが選ばれ、各ステップでどのモデルが動いたかを残したいときは /collect-debug-logs で、セッションのデバッグログをアーカイブにまとめられます。
チームで試すなら、同じ課題をAutoとHydraFusionで1回ずつ流し、/usage の値と所要時間、テストの通過を並べて記録しておくと、採用の判断材料がそろいます。
HydraFusionの課金とAI Creditsの消費、ベンチマーク数値の読み方
費用と効果の数字は、出どころと前提を分けて読む必要があります。課金の仕組みは公式ドキュメント、性能の数字は研究記事が出典です。
使用モデルごとの標準レート課金とAutoの割引が適用されない条件
HydraFusionの利用料は、裏で動いた各モデルの標準レートで計算されます。HydraFusionという機能への別料金はありません。ただしAutoに付くモデル費用の割引は適用されず、複数のモデルを動かすぶん、1モデルで済ませるより多くのAI Creditsを使うことがあります。
消費を抑える工夫として、会話はできるだけ同じモデルに保ってキャッシュされたトークンを使い回し、レビュー役などの補助モデルには必要な文脈だけを渡す設計になっています。プランごとの月間クレジットや超過時の扱いは、AI Credits移行後のGitHub Copilotの料金とプラン比較で整理しています。
TerminalBench 2.1など3種のベンチマークでのOpus 5比の数値
2026年9月4日の研究記事「Project HydraFusion」は、Claude Opus 5を基準に次の結果を示しています。
| ベンチマーク | 対象タスク | コスト（Opus 5比） | 品質（Opus 5比） |
|---|---|---|---|
| TerminalBench 2.1 | 端末環境での複数ステップの作業 | 67%減 | +4.9ポイント |
| DeepSWE | 大規模リポジトリのファイル横断の修正 | 36%減 | -1.5ポイント |
| CheckpointBench | Copilotの実セッション由来の社内評価 | 65%減 | -0.1ポイント |
品質の向上が出たのはTerminalBench 2.1だけで、残る2つは品質をほぼ保ったまま費用を下げた結果です。「Opus 5より賢い」ではなく、「Opus 5に近い品質を3〜6割ほど安く出せた」と読むのが表の実態に合っています。
コストと品質の数字を自社の採用判断に使う前に確認したい評価条件
研究記事は、数字が評価に使ったベンチマークの版、ワークフロー設定、モデルの組み合わせ、価格の前提に限ったオフライン評価だと断っています。全モデルで推論の強さをmediumにそろえた条件でもあり、待ち時間の数字は示されていません。
自社のリポジトリで同じ傾向が出るとは限りません。評価の枠組みを自前で持つなら、タスク達成率とツール呼び出しの両方を測るAIエージェント評価の指標と実装の進め方が下敷きになります。
破棄された下書きの変更・コンテキスト上限などHydraFusionの制限事項
研究プレビューのため、公式ドキュメントには制限がはっきり書かれています。運用で事故になりやすい順に見ていきます。
採用されなかった下書きのファイル編集が自動で元に戻らない制限
CascadeやCritiqueでは、途中の下書きが捨てられることがあります。問題は、その下書きがすでにファイルを書き換えていた場合です。公式ドキュメントは、破棄された下書きの変更は自動では元に戻らないと明記し、コミット前に変更を確認するよう求めています。
先ほどのスクリプトのように作業ブランチを切るか、未コミットの変更が無い状態から始めれば、git diff で余計な変更を見つけて戻せます。差分を見ずにそのままコミットする使い方は避けてください。
コンテキストウィンドウは使用モデルの中で最小の上限に合わせた値
HydraFusionのコンテキストウィンドウは、使う可能性のあるモデルの中で最も小さい上限を基準にした控えめな値です。各ステップ自体は実行するモデルの上限内で動きます。長く続いた会話の途中でHydraFusionへ切り替えると、会話が上限を超えていて先に圧縮（compaction）が必要になることがあります。
研究記事も、現時点では単発プロンプトの最初のターンで渡すコーディング作業に向くとし、複数ターンの長いセッションへの対応は今後の課題としています。大きな作業ほど、新しいセッションで1回の指示にまとめて渡すほうが結果が安定します。
サブエージェントを起動しない点とAutopilotなど他機能との併用範囲
HydraFusionはサブエージェントとは別の仕組みで動き、サブエージェントを起動しません。調査用のエージェントを並列に走らせて結果を集めるような使い方は、HydraFusionの外で組む必要があります。
CLIで人の承認なしに作業を進める機能としては、Copilot CLIのAutopilotの使い方と止まる条件があります。Autopilotは「どこまで任せるか」、HydraFusionは「どのモデルで解くか」を決める機能で、役割が異なります。
HydraFusionを使う場面と見送る場面：受託開発チームでの判断基準
ここまでの事実を踏まえ、開発チームとしての判断を言い切ります。2026年10月時点の研究プレビューを前提にした線引きです。
採用する条件は範囲の明確な複数ファイル修正を1回の指示で渡せる作業
採用するのは、次の3条件がそろう作業です。修正範囲がディレクトリやモジュール単位で言えること、テストで正否を判定できること、1回の指示で要件を渡し切れることです。決済の端数処理の修正や、型定義の変更に伴う複数ファイルの追従などが当てはまります。
この種の作業は、Critiqueの別系統レビューが効きやすい領域です。テストが通るかどうかで採否を機械的に決められるため、下書きの破棄が起きても差分の確認で吸収できます。
採用を見送る条件：定型作業・長い対話・送信先モデルを固定すべき案件
見送るのは3つの場面です。1つ目は、命名の修正や小さな関数の追加といった定型作業です。レビュー段階の時間とクレジットに見合う効果が出ません。2つ目は、仕様を対話で詰めながら進める長いセッションです。コンテキストの制約と切り替え時の圧縮が足かせになります。
3つ目は、契約でコードの送信先やモデルの提供元を固定している案件です。HydraFusionはモデルを利用者が指名できないため、提供元を限定したいなら、GitHub CopilotでClaudeなど特定モデルに切り替える方法で明示的に固定するほうが説明責任を果たせます。社内でAIコーディング支援をどこまで許可するか、プレビュー機能やモデルポリシーの線引きから決めたい場合は、一創の生成AI導入支援で利用ルールの整備から相談を受けています。
よくある質問
HydraFusionを試す前によく出る疑問を、2026年10月時点の公開情報にもとづいて整理します。
HydraFusionは無料で使えますか？
HydraFusionという機能自体に追加料金はありません。ただし裏で動いた各モデルの標準レートでAI Creditsを消費し、Autoの割引も効かないため、1モデルで済ませるより消費が増えることがあります。対象プランはChangelogではPro・Pro+・Business・Enterpriseと書かれています。Freeで使えるかは、自分の環境のモデルピッカーで確認してください。
HydraFusionが使ったモデルを確認できますか？
使用モデルは応答の完了後に確認可能です。VS CodeとGitHub Copilotアプリでは、完了した応答のフッターにカーソルを合わせると使用モデルが表示されます。Copilot CLIでは /usage でモデルごとのクレジット消費を、/collect-debug-logs で実行パターンと各ステップのモデルを含むログを取得できます。モデルを事前に指名することはできません。
VS CodeでHydraFusionが表示されないのはなぜですか？
多い原因は、VS Codeが1.140より古い、chat.copilot.hydraFusion.enabled がオフ、組織契約で管理者がプレビュー機能を許可していない、の3つです。加えて、プランとモデルポリシーで使えるモデルが1つも無い場合もピッカーに出ません。上から順に確認すると早く切り分けられます。
Copilot CLIのRubber DuckとHydraFusionのCritiqueは何が違いますか？
考え方は同じで、別系統のモデルが読み取り専用で下書きをレビューし、指摘だけを返します。違いは、Critiqueでは下書きを作ったモデルが指摘を受けて1回だけ修正する流れまでがHydraFusionの中で自動的に組まれる点です。どのタスクでCritiqueを使うかもHydraFusionが判断します。
研究プレビューのHydraFusionを業務のコードに使っても問題ありませんか？
公式ドキュメントはSLAが無く本番ワークロード向けではないと明記しており、パターンやモデルは予告なく変わり得ます。使うなら、作業ブランチに隔離し、テストと差分レビューを通した変更だけを取り込む運用が前提です。顧客との契約でモデルの提供元を限定している案件では使わない判断になります。
関連記事
- GitHub Copilot CLIのAutopilotとは｜使い方・止まる条件・料金と導入手順：CLIで承認なしに作業を進める機能で、HydraFusionと組み合わせる範囲を確認できます。
- GitHub Copilotの料金（pricing）｜AI Credits移行後のプラン比較とBilling APIでの使用量集計：HydraFusionが消費するAI Creditsのプラン別の上限と集計方法を扱っています。
- GitHub CopilotでClaudeを使う方法｜モデル切替・エージェント・料金：モデルを自分で固定したい場合の切り替え手順です。
- CodexとClaude Codeの違い｜料金・使用量・設定と併用の判断：Copilot以外のAIコーディング支援と比べる際の材料になります。
- AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方：ベンチマークの数字を自社の評価に置き換えるときの前提を整理しています。
