GitHub HydraFusion、Copilotの実行時に複数モデルをオーケストレーションし、カスケードとクロスモデルレビューでコストを制御

GitHubは9月4日、Project HydraFusionを発表した。これにより、モデル選択はプロンプト送信前の一度きりの判断から、実行時の複合ワークフローへと変わる。ユーザーはCopilot CLIでこれを1つのモデルとして選択するが、システムは推論、コード生成、デバッグ、ツール使用能力に関するシグナルに基づき、3つの経路のいずれかを選ぶ。`Single`は単一モデルに直接処理を委ねる。`Cascade`はまずリソース消費の少ないモデルに解決策を生成させ、品質ゲートを通過しなかった場合にのみ上位モデルへエスカレーションする。`Critique`では、別のモデルファミリーが読み取り専用かつツールを使用できない環境でドラフトをレビューし、その後、元のモデルが一度だけ修正する。

この分離方式は注目に値する。問題を解くモデルはワークスペースを共有し、Copilotの権限制御を引き継ぐ一方、レビューモデルはリポジトリを変更できない。処理がキャンセルされた場合や検証に失敗した場合、システムはいかなるpatchも適用しない。実行基盤は各段階の役割、結果、レイテンシ、診断情報、コストを記録する。課金には、ドラフト作成、レビュー、再試行、エスカレーション、フォールバックで消費されたすべてのtokenも含まれる。そのため、モデルの呼び出し回数を増やせば必ず安くなるわけではなく、コスト削減の成否は、十分な数のタスクを低コスト経路で完了させられるかどうかにかかっている。

GitHubは固定ポリシーを用いて、TerminalBench 2.1、DeepSWE、社内のCheckpointBenchでテストした。Claude Opus 5と比較すると、最適に調整された構成では、TerminalBench 2.1の検証品質が4.9パーセントポイント高く、推定コストは67%低かった。DeepSWEでは36%安かった一方、品質は1.5パーセントポイント低かった。CheckpointBenchではコストが65%低く、品質は0.1パーセントポイント低かった。これらはいずれもGitHubが管理したオフライン環境での結果であり、最良の構成を採用している。ルーティングモデル、品質ゲート、タスク別の分布、エンドツーエンドのレイテンシは公開されておらず、社内ベンチマークも独立した再現ができない。

プレビュー版はすでにすべてのCopilotプランで利用できるが、GitHubはまず、範囲が明確な初回の単一プロンプトタスクで使用することを推奨している。複数ターンにわたる長時間のセッションは、引き続き開発中だ。今後、エンジニアリングチームは実際のリポジトリにおけるテールレイテンシ、障害時のフォールバック、コストの予測可能性に加え、監査に十分なルーティングログをエクスポートできるかどうかを確認すべきだ。こうした制御が可視化されなければ、モデルオーケストレーション層が新たなベンダー依存やデバッグ上の死角になる可能性もある。