最強を選ばず、手順を組む——GitHub HydraFusion を個人開発の視点で読む

2026年9月上旬、GitHub は Project HydraFusion を発表した。新しい巨大モデルではない。Copilot の研究プレビューとして、リクエストごとに「どのモデルをどう組み合わせて解くか」を実行時に決めるオーケストレーション層だ。ユーザーは HydraFusion をモデル一覧から選ぶだけで、裏で Single／Cascade／Critique のどれかが走る。本稿は機能カタログではなく、同じ週の NVIDIA PAIR（家の推論振り分け）の対になる「クラウド側の振り分け」を、個人開発の視点で読むメモである。

何が発表されたか

公式によれば、HydraFusion はタスクの能力シグナル（推論・コード生成・デバッグ・ツール利用など）を見て、品質バーを満たしそうないちばん単純な実行パターンを選ぶ。いま公開されている型は三つだ。Single は選ばれた1モデルが直接解く。Cascade は効率寄りのモデルが下書きし、品質ゲートで足りなければ強いモデルへ上げる。Critique は別系統のモデルが読み取り専用でレビューし、下書き側が一度直す（Rubber Duck と同じレビュー型、と公式は書く）。レビューはツール無しの隔離文脈、ソルバ側は共有ワークスペースと通常の権限付きエージェントループ、失敗やキャンセル時は不完全なパッチをリポジトリに載せない、といった運用原則も併記されている。

オフライン評価では、TerminalBench 2.1 で Claude Opus 5 比おおよそ コスト67%減・検証品質 +4.9pt、DeepSWE／CheckpointBench では品質はほぼ同等〜わずかに下がりつつコスト大幅減、という数字が出た。比較は固定価格仮定・同一 reasoning 水準などの条件下だ。研究プレビューは Copilot CLI の experimental 経由で全プランから触れられ、課金は実際に呼んだ各モデルの通常レート合算。現状のすすめは、まず一発目の単発コーディングタスクから、とある。

感想①：Auto と HydraFusion は層が違う

GitHub にはすでに Auto model selection がある。「このタスクにいちばん合いそうな1モデル」を選ぶ層だ。HydraFusion はその上（または横）で、「1モデルで足りるか、下書き＋昇格か、下書き＋独立レビューか」まで含めた手順を組む。報道でも、Auto は selection、HydraFusion は orchestration、将来の収束も検討、と整理されている。名前は派手だが、やっていることは開発者が手作業でやってきたこと——安いモデルで試す、ダメなら強いモデル、別モデルにレビューさせる——の自動化である。魔法ではなく、台本の固定化だ。

個人開発で重要なのは、「常に最強」をやめた設計が製品に載ったことだ。最強固定は品質の上限を上げやすいが、待ちと請求も上げる。HydraFusion の売り文句の核は、フロンティア級の体感を、全部をフロンティアに投げずに近づける、という最適化問題である。ベンチの数字は更新され得る。残るのは「品質バーを満たす最小手順」という発想そのものだ。

感想②：三パターンは、全部を常時オンにしないための地図だ

Single／Cascade／Critique は機能名というより、コスト配分の地図だ。簡単な修正に Critique を常時かければ、呼び出しが増えて遅くなる。難しいリポジトリ修正に Single だけを固執すれば、安いが外しやすい。Cascade は「まず効率側、ダメなら昇格」なので、ゲートの感度が本体になる。公式が「追加のモデル呼び出しは、改善しそうなときだけ」と書くのは当然で、個人が自前ルータを書くときも同じ原則が要る。並列にモデルを増やすことと、手順を賢くすることは別だ。増やすだけなら請求も増える。

もう一つ。Critique のレビューが読み取り専用・ツール無し、という点は実務の匂いがする。レビュアに編集権限を渡すと、レビューが再実装になりやすい。読む役と書く役を分ける。失敗時にパッチを載せない。この二つは、HydraFusion を使わなくても、手元のエージェント運用にそのまま移植できる。便利なプレビューの裏にあるのは、境界設計の教科書である。

感想③：PAIR と並べると、家とクラウドの同じ問いになる

今朝メモした NVIDIA PAIR は、LAN 内の遊休マシンへ独立リクエストを横に逃がす。HydraFusion は、クラウド側で1リクエストの中に複数モデルの手順を縦に組む。向きは違うが、問いは近い。どこに強い推論を使うか。どこで十分か。誰がゲートを持つか。家ではノードとモデルタグが制約になり、クラウドではトークン単価とレイテンシが制約になる。どちらも「全部を最強に載せない」ための薄い層だ。

ぼくの。のような小さなサイト運用では、HydraFusion を毎日の必須ボタンにする必要はない。持ち帰れるのは短い手順書だ。(1) 下書きは軽い側。(2) 境界をまたぐ変更だけ強い側。(3) 可能なら別系統で一度だけ読む。(4) 適用は人間または差分レビューの後ろ。(5) 一発目の単発タスクで効きを見て、長くて込み入った対話は固定モデルに戻す。プレビュー段階ではマルチターンが弱い、と公式も次の焦点だと書いている。新しい道具の初期は、効く範囲を狭く取る方が安全だ。

おわりに

HydraFusion は「次の神モデル」の発表ではない。「神モデルをいつ呼ぶか」を実行時に決める発表だ。Astra 週の能力競争の隣に、GitHub はオーケストレーションを置いた。個人開発者が明日から experimental を常時オンにする話ではない。代わりに残るのは、選定と手順は別レイヤだということ、レビュー役に書き込みを渡さないこと、コストは呼び出し回数の物語だということだ。派手な見出しは週末で薄れ、残るのはゲートとレビューの平日である——その結論は、今週の他のメモとも同じ向きを向いている。

一次情報は GitHub の公式ブログである。モデルプール・課金・提供範囲は更新され得る。導入直前には一次情報を当て直してほしい。