HydraFusionとは。仕組み・料金・使い方を解説

モデルではなく編成役

通常のモデル選択では、利用者がGPTやClaudeなどを1つ選び、そのモデルへ作業を任せます。HydraFusionで選ぶのはモデル名に見えて、実際には実行計画です。GitHubによると、HydraFusionは推論、コード生成、デバッグ、ツール利用に関する能力の信号を見て、必要な複雑さの経路を選びます。

選択肢	何を選ぶか	1つの依頼で起こること
固定モデル	利用者が指定した1モデル	原則として同じモデルが処理する
Auto	タスクに合う1モデル	タスクの複雑さや稼働状況からモデルを選ぶ
HydraFusion	モデルを含む実行経路	1モデルで終えるか、段階的に強化・レビューする

重要なのは、毎回たくさんのモデルを呼ぶ仕組みではない点です。単独で解ける依頼へレビューや再実行を足すと、時間も料金も増えます。HydraFusionは、品質基準を満たすと見込める最小の経路を選び、追加推論が役立つ場面にだけ複数モデルを使う設計です。

モデル選択の負担は減りますが、結果の責任まで自動で移るわけではありません。どのファイルを変えてよいか、どのテストを通すか、何を完了条件にするかは、依頼する側が明確にする必要があります。これは、AIコードレビューを導入するときの確認項目と同じです。モデルが増えても、検証可能な条件は省けません。

• HydraFusionは新しい基盤モデルではない
• 依頼ごとにモデルと処理順を組み立てる
• 必要なときだけ複数モデルを使う
• 最終的な受け入れ条件は利用者側で決める

3つの実行経路

HydraFusionが現在選ぶ経路は、Single、Cascade、Critiqueの3種類です。同じプロンプトでも、作業の難しさやレビューの有効性によって処理の流れが変わります。

経路	流れ	向く仕事	注意点
Single	1つのモデルが直接解く	明確で小さな修正、説明	追加レビューはない
Cascade	効率的なモデルが下書きし、品質ゲートを通らなければ強いモデルへ上げる	難しさを事前に読み切れない実装	エスカレーション時は呼び出しが増える
Critique	1モデルが下書きし、別系統のモデルが読み取り専用で批評し、元のモデルが1回修正する	設計やテストの盲点を探したい作業	待ち時間とレビュー分の消費が加わる

Critiqueのレビュー担当は、下書き担当と異なるモデル系統から選ばれます。GitHubは、同じモデルが持つ偏りや見落としを共有しにくくする狙いを説明しています。レビュー担当は隔離されたツールなしの環境で動き、リポジトリを変更しません。変更を実行できるのは、通常の権限管理下にある解決側です。

これは「モデルを3つ並列に走らせ、多数決で決める」方式ではありません。Cascadeは条件付きの引き上げ、Critiqueは下書きと別視点の批評、Singleは単独処理です。どの経路を通ったかで、消費量、待ち時間、得られる検証の厚みが変わります。

GitHubは中間の下書きを利用者へそのまま見せず、1つのまとまった結果を返します。途中案は破棄や修正の対象になるためです。一方で、処理中に何が起きているか見えにくい時間が生まれます。GitHub自身も、進捗の見せ方を研究プレビューの課題として挙げています。

Autoとの違い

HydraFusionとAutoは、どちらも「利用者が毎回モデルを決めなくてよい」機能です。ただし、Autoが主に1モデルを選ぶのに対し、HydraFusionは依頼を終えるまでの経路を選びます。

比較点	Auto	HydraFusion
判断対象	どのモデルへ送るか	どのモデルを、どの順序で使うか
主な信号	タスクの複雑さ、稼働状況、利用可能性	推論、生成、デバッグ、ツール利用などの能力信号
途中のモデル追加	自然なキャッシュ境界で選択	CascadeやCritiqueなら追加モデルを呼ぶ
提供状態	一般提供	Research Preview
料金上の扱い	有料プランはモデル費用を10%割引	各経路で使ったモデルのトークンを標準単価で計上

Autoは、単一モデル選択の手間やレート制限を減らしたいときの既定値に向きます。GitHubは、キャッシュ費用を増やさないよう、セッション開始や圧縮後など自然な境界でモデルを選ぶと説明しています。

HydraFusionは、1モデルを選んだ後の「解き方」まで任せたいときの候補です。たとえば、安価なモデルで下書きできるかを試し、基準に届かないときだけ強いモデルへ移す選択ができます。あるいは、実装モデルとは別の系統へ設計の穴を探させられます。

どちらが常に優れるわけではありません。短いやり取りを重ねる相談、利用モデルを固定したい監査対象の仕事、料金を事前に読みたい定型処理ではAutoや固定モデルのほうが扱いやすい場合があります。対して、完了条件が明確な大きめの単発作業はHydraFusionを試しやすい領域です。

料金は合算される

HydraFusionに「1回いくら」という固定料金はありません。GitHubは、HydraFusionが呼び出したモデルごとに、実際に消費したトークンを各モデルの標準レートで計算すると説明しています。下書き、批評、修正、上位モデルへの引き上げ、再試行、フォールバックも、使われれば費用計算の対象です。

GitHub Copilotでは、モデル料金をGitHub AI Creditsへ換算します。公式料金表では1 AI Creditが0.01米ドルで、各プランの利用枠を超えた分は追加利用として扱われます。HydraFusionの実際の費用は、次の要素で変わります。

1. Single、Cascade、Critiqueのどれが選ばれたか
2. 各工程でどのモデルが使われたか
3. 入力、出力、キャッシュの各トークン量
4. 品質ゲート後の引き上げや再試行が発生したか

そのため、GitHubが示す「最大67%低い推定費用」を、どの依頼にも使える値引率として受け取るのは危険です。これは特定のベンチマーク、モデル構成、価格前提で測った相対値です。個々のセッションでは、Critiqueが入れば単一モデルより呼び出しが増える場合もあります。

料金を確かめるなら、同じリポジトリの同程度の課題を数件用意し、固定モデル、Auto、HydraFusionで比較します。Copilot CLIの/usageでは、セッション中のAI Credits、経過時間、編集行数、モデル別トークンを確認できます。GPT-6 Astraの料金と利用条件のように、基盤モデルの単価だけを見るのではなく、仕事1件を完了する総額で比べるのが要点です。

評価結果の読み方

GitHubは、TerminalBench 2.1、DeepSWE、社内のCheckpointBenchでHydraFusionを評価しました。比較対象はClaude Opus 5で、同じタスク入力、ツール、実行制限、価格前提、採点条件を使い、全モデルをmedium相当の推論レベルにそろえたとしています。

ベンチマーク	Opus 5比の推定費用	Opus 5比の検証済み品質
TerminalBench 2.1	67%低い	4.9ポイント高い
DeepSWE	36%低い	1.5ポイント低い
CheckpointBench	65%低い	0.1ポイント低い

3行を並べると、HydraFusionがすべての評価で品質も費用も勝ったわけではないとわかります。TerminalBench 2.1では両方が改善しましたが、DeepSWEとCheckpointBenchでは品質がわずかに下がりました。読み取れるのは「必ず賢くなる」ではなく、「品質を大きく落とさず、費用を抑えられる可能性がある」です。

さらに、CheckpointBenchは実際のCopilotセッションをもとにGitHubが作った社内評価です。公表値はGitHub自身の管理下で得られたオフライン結果であり、第三者が実運用で再現した証拠ではありません。独立した解説も、3評価のうち2つでは品質がわずかに下がった点を注意点として挙げています。

比較するときは、成功率だけでなく、費用、所要時間、余計な変更、レビューで見つかった不具合を記録します。CursorとCopilotの利用動向が示すように、モデルや機能の選択は単一のベンチマークだけでは決まりません。自分のコードベースで、同じ種類の仕事を完了できたかを見る必要があります。

試す手順と条件

HydraFusionは、現時点でGitHub Copilot CLIの実験機能から利用します。GitHubの案内する手順は3段階です。

1. Copilot CLIで/updateを実行し、最新版へ更新する
2. /experimental onで実験機能を有効にする
3. /modelを開き、HydraFusion (Research Preview)を選ぶ

Copilot CLI自体は全Copilotプランで利用できます。組織からライセンスを受けている場合は、管理者がCLIポリシーを有効にしている必要があります。また、HydraFusionは研究プレビューです。名称、構成モデル、実行経路、提供範囲、料金上の動作は変わる可能性があります。

GitHubが最初の検証対象として勧めるのは、初回ターンで渡せる、十分に範囲を絞った大きめのコーディング課題です。長いやり取りを前提にしたマルチターン性能は、今後の重点項目とされています。

試験用の依頼には、次の5項目を入れると比較しやすくなります。

• 変更対象のファイルや機能
• 変えてはいけない挙動
• 実行するテストと合格条件
• 料金または時間の上限
• 完了時に報告してほしい差分と未解決点

本番へ直接変更を流すのではなく、隔離したブランチやworktreeで試し、人間が差分とテスト結果を確認します。HydraFusionには、失敗や検証不合格ならパッチを適用しない設計があります。それでも、品質ゲートの定義が自分の製品要件と同じとは限りません。

導入判断の基準

HydraFusionを試す価値があるのは、強いモデルを毎回固定すると費用が重く、安価なモデルだけでは失敗時の手戻りが多い仕事です。モデルを手動で切り替え、別モデルへレビューを頼む運用をすでにしているチームなら、その手順を1つの実行経路へまとめる意味があります。

一方、出力の再現性が厳密に必要な処理や、どのモデルへコードを渡したかを事前に固定する必要がある仕事では、研究プレビューを既定値にするのは早いでしょう。HydraFusionは複数提供元のモデルを選べる設計です。組織のモデルポリシー、データ取り扱い、追加利用枠も先に確認する必要があります。

向いている条件	慎重にする条件
単発で範囲が明確な実装	長い対話を前提にした設計相談
成功・失敗をテストで判定できる	正解を機械判定しにくい企画判断
固定の高性能モデル費用を下げたい	モデルと費用を事前に固定したい
別モデルの批評が役立つ	複数提供元への送信を認められない

導入時は、最初から全員の既定モデルにしないほうが比較しやすくなります。代表的な課題を5〜10件選び、固定モデルとHydraFusionで同じ受け入れテストを通します。費用だけでなく、完了率、再修正回数、余計な差分、待ち時間を記録すれば、ベンチマークではなく自社の仕事に合うかを判断できます。

まとめ

• HydraFusionは新モデルではなく、Single、Cascade、Critiqueから依頼ごとの実行経路を選ぶ編成層です。モデル選びだけでなく、引き上げや別モデルレビューまで自動化する点がAutoとの違いです。
• 料金は固定額ではなく、使われた全モデルのトークン消費を標準単価で合算します。67%という数字は特定評価の推定値であり、実務では仕事1件を完了する総額と待ち時間を測る必要があります。
• 現在はCopilot CLIの研究プレビューで、初回ターンに渡せる明確な単発課題が主な検証対象です。隔離環境、受け入れテスト、モデルポリシーをそろえてから小さく比較するのが現実的です。

出典・参考

• GitHub「Project HydraFusion」公式発表
• GitHub Docs「Using GitHub Copilot CLI」
• GitHub Docs「Models and pricing for GitHub Copilot」
• GitHub Docs「About Copilot auto model selection」
• GitHub Docs「About the rubber duck agent」
• Pimp My IDE「HydraFusion Pit Wall」