GitHub HydraFusion、Copilotの実行時に複数モデルをオーケストレーション――コストは低下も品質向上は限定的

GitHubはProject HydraFusionを研究プレビューとしてCopilot CLIに導入し、「どのモデルを選ぶか」をワークフロー全体にわたる実行時の意思決定へと引き上げた。ユーザーがHydraFusionを選択するだけで、システムは推論、コード生成、デバッグ、ツール使用などの能力シグナルに基づき、3つのモードへルーティングする。`Single`では1つのモデルが直接タスクを完了する。`Cascade`では、まず低コストのモデルが草案を作成し、品質ゲートが上位モデルへエスカレーションするかを判断する。`Critique`では、別のモデルファミリーに属する読み取り専用モデルがレビューを行い、その後、元のモデルが一度だけ修正する。

この設計におけるエンジニアリング上の要点は、ルーターだけではない。GitHubは、草案作成、レビュー、再試行、エスカレーション、フォールバックに伴う使用量をすべて合算し、各段階にタイムアウトとキャンセルのルールを設定する。レビューモデルはツールを使用できない隔離環境で実行され、解決を担当するモデルだけが権限制御された共有ワークスペースへアクセスできる。検証に失敗した場合や処理がキャンセルされた場合、システムはいかなるパッチも適用せず、各ステップの役割、コスト、レイテンシー、診断データを記録する。

Claude Opus 5と比較すると、最適にチューニングされた構成では、TerminalBench 2.1の検証済みタスク品質が4.9パーセントポイント向上し、推定コストは67％低下した。一方、DeepSWEではコストが36％低下したものの、品質も1.5ポイント低下した。社内ベンチマークのCheckpointBenchではコストを65％削減した一方、品質は0.1ポイント低かった。これは、複数モデルを使えば必ず精度が上がるというより、調整可能な品質とコストのトレードオフに近いことを示している。

エンジニアリングチームは引き続き、実環境でのレイテンシー、ルーティングのオブザーバビリティ、モデル更新後の戦略ドリフトに注意を払う必要がある。テスト結果は固定されたモデルプールとオフライン評価に基づいており、CheckpointBenchも公開されていない。現時点でGitHubは、まずスコープが明確な単一ターンのタスクで利用することを推奨しており、長時間にわたる複数ターンの開発ワークフローについては、なお検証が必要である。