FlowTune Media

GitHub Copilotが1タスクに複数モデルを使い分け始めた — HydraFusionはコストを67%下げるのか

「どのモデルを選ぶか」という悩みを、そもそも人間から取り上げる。GitHubがCopilotに投入した実験機能HydraFusionは、そういう方向の話だ。9月4〜5日に研究プレビューとして公開され、今週のAIコーディング界隈で一番ざわついていた。

1つのタスクに、1つのモデルとは限らない

これまでのCopilotは「Claude Opus 5で行くか、GPT-5.6 Solにするか」をユーザーが選ぶ設計だった。HydraFusionはそこを実行時に自動で組み立てる。タスクを受け取ると、その場でワークフローを設計し、下書き・批評・より強いモデルへの引き上げ(cascade)を組み合わせて答えを出す。

現時点で用意されているパターンは3つ。1モデルで片が付くなら素早く終わらせる「Single」、まず軽量モデルに試させて品質ゲートを通らなければ上位モデルに引き継ぐ「Cascade」、別系統のモデルに独立した視点でレビューさせる「Critique」だ。要は、簡単なタスクに高い推論を丸投げする無駄を減らしつつ、難所では複数モデルの合議に持ち込む、という発想である。

使い方はシンプルで、Copilot CLIの /experimental から有効にできる。全プランのユーザーが対象だ。

67%削減という数字の読み方

目を引くのはコストの数字だ。GitHubは自社ベンチマークで、TerminalBench 2.1においてClaude Opus 5と比べて品質を4.9ポイント上げつつ、推定コストを67%下げたと主張している。単一モデルより安くて、しかも少し賢い——うまくいけば理想的な話だ。

ただ、ここは冷静に見たい。同じ評価でもDeepSWEでは削減率が36%にとどまり、品質はむしろ1.5ポイント下がっている。社内ベンチのCheckpointBenchでは65%削減・品質ほぼ横ばい。ベンチマークによって結果がかなり振れているわけで、「常に67%安くなる」と読むのは早い。しかも評価は固定ポリシーで行われたとされ、実際の対話で毎回最適な編成に化けるかは別問題だろう。数字の出方から見て、恩恵の大きさはタスクの性質にかなり依存すると推測する。

正直、この振れ幅こそが面白いところだと思う。オーケストレーションは「安くて賢い」を約束する魔法ではなく、タスクを見極めてモデルを配る精度がすべて、ということを結果が正直に示している。

考察 — 「モデル選び」がコストの設計項目になる

この仕組みが定着すると、開発者にとって何が変わるか。一つは、モデル選択が「好み」から「コスト設計」へ移ることだ。軽いリファクタは安いモデル、設計を伴う実装だけ上位モデルにcascade——という配分が自動で効けば、月のトークン請求の形が変わる。個人開発でOpus級を回し続けて財布が痛かった層には効きうる。

もう一つは品質のルーティングだ。Critiqueのように別系統のモデルへレビューさせる発想は、1つのモデルの癖や弱点を別のモデルで打ち消す狙いがある。将来ここに「このリポジトリではこの編成が通りやすい」という学習が乗れば、プロジェクトごとに最適化された編成が育つ可能性もある。まだ研究プレビューで、そこまでの賢さは見えていないが、方向としては筋がいい。

CopilotがマルチモデルのハブになるというのはZedやCursorも進めてきた流れだが、HydraFusionは「選ばせる」のではなく「勝手に配る」側に踏み込んだ。うまく育てば、モデル選びに悩む時間そのものが消える。まずは /experimental で自分のタスクにどれだけ効くか試してみるのが正解だと思う。


関連記事:

関連記事