9月5日、RuntimeWireが「GitHub launches HydraFusion to make several AI models do one coding job」と題した記事を公開した。GitHubが複数のAIモデルを協調させて1つのコーディングタスクをこなす新しいオーケストレーション機構「HydraFusion」を発表したことを詳しく伝えている。
「どのモデルを使うか」ではなく「どう組み合わせるか」
GitHub Copilotは9月4日、Project HydraFusionをリリースした。研究プレビュー段階の機能で、GitHub Copilot CLIの実験的メニューから全プランのユーザーが利用できる。使い方はシンプルで、モデルピッカーからHydraFusionを選ぶだけ。内部では複数のAIモデルを組み合わせたワークフローが自動で組まれる。
これまでのCopilotは「自動モデル選択」によってタスクの複雑さやシステムの空き状況に応じて1つのモデルを選んでいた。HydraFusionはそこから一歩踏み込み、複数モデルに役割を割り当てる実行計画を構築する。たとえば「モデルAが初稿を書き、モデルBがレビューし、モデルAが修正する」という流れを1回のプロンプトで実行できる。
HydraFusionが採用するアーキテクチャは、LLM研究におけるMixture of Agents（MoA）の流れに位置づけられる。MoAは複数の言語モデルを階層的に組み合わせ、各モデルの出力を次のモデルへの入力として活用することで、単一モデルを超える品質を目指す手法だ。HydraFusionはこの考え方をCopilotの開発者ワークフローに実用的な形で組み込んだものといえる。また、モデルが自身の出力を採点・選別する「LLM-as-judge」のアプローチとも共通点を持つ。
※編集部の考察：マルチモデルオーケストレーションはAnthropicのMixture of Agentsに関する実験やOpenAIのマルチエージェント研究など、主要プロバイダー各社が注目している領域でもある。HydraFusionはその知見をプロダクト側で実装しようとする試みとして注目に値する。
3つのルーティングパターン
HydraFusionが選択するワークフローは現在3種類ある。
- Single（シングル）: タスクを1つのモデルに直接送る。従来と同じ動作。
- Cascade（カスケード）: まず軽量・低コストなモデルで処理し、品質チェックを通過しなければより強力なモデルにエスカレーションする。
- Critique（クリティーク）: 初稿を別モデルファミリーの「読み取り専用レビュアー」に送り、フィードバックを受けた上で元のモデルが1回修正する。
特にCritiqueパターンは、Copilot CLIにすでにある「rubber duckエージェント」（計画や実装を別モデルに検査させる仕組み）を発展させたもの。レビュー担当のモデルはツールを持たず、リポジトリを直接変更できない設計になっている。ソルバーモデルだけが作業領域とCopilotのエージェントループにアクセスする。
Cascadeパターンは特に、コストの大半を占めるフロンティアモデルの呼び出し回数を自動的に絞り込む点で実用的だ。タスクが簡単であれば軽量モデルで完結し、フロンティアモデルは本当に必要な場面にだけ使われる。この「エスカレーション型」の設計は、開発者が都度モデルを選ぶ手間を省きながらコストと品質のバランスを自動最適化するものといえる。
ベンチマーク：コスト削減と品質のトレードオフ
GitHubはClaude Opus 5およびGPT-5.6 Solを比較対象に、Terminal-Bench 2.1・DeepSWE・CheckpointBenchで評価を実施した。
| ベンチマーク | HydraFusion vs Opus 5 | 推定コスト削減 |
|---|---|---|
| Terminal-Bench 2.1 | +4.9ポイント（上回る） | 最大67%削減 |
| DeepSWE | −1.5ポイント（下回る） | 36%削減 |
| CheckpointBench | −0.1ポイント（ほぼ同等） | 65%削減 |
Terminal-Bench 2.1は89のコンテナベースタスクで構成され、Terminal-Bench 2.0の依存関係やタイムアウト問題を修正したバージョン。DeepSWEは113の長時間リポジトリタスクを測定する。CheckpointBenchはGitHub内部のベンチマークでCopilotのコーディングセッションから生成されている。
ただし、これらはすべてGitHubが管理するオフライン評価での数値であることに注意が必要だ。タスク入力・ツール・実行制限・価格前提・採点条件・推論レベルを固定した条件での結果であり、最良にチューニングされたルーティング設定を使用している。実際のリポジトリ、長い会話、ネットワーク遅延、途中での要件変更といった現実的な条件での検証はこれからだ。
コストの仕組みと注意点
HydraFusionを使っても無料にはならない。ワークフロー内の全モデルが消費したトークンがそれぞれの標準Copilotレートで課金される。CritiqueやCascadeでは1回のプロンプトに対して複数のモデル呼び出しが発生するため、ルーティングで節約できる推論コストがそのオーバーヘッドを上回る場合にのみ実質的なコスト削減になる。
また、現時点では中間ドラフトが開発者に見えない。後続のクリティークやエスカレーションによって破棄される可能性があるためで、最終的な応答は整理されているが、長い処理中の可視性は低い。マルチターンセッションへの対応も現在も開発中とされている。
GitHubにとっての意味
HydraFusionが実用上うまく機能すれば、GitHubはコストが高いフロンティアモデルを本当に必要なプロンプトにだけ充て、ルーティン作業は安価なモデルにシフトできる。新しいモデルプロバイダーが増えても、開発者のワークフローを変えずに内部で組み込める。モデルピッカーは引き続き目に見えるが、実質的な選択はエンターを押した後にオーケストレーション層が行う構造になる。
GitHubはまず「しっかりとスコープが切られた最初のターンのコーディングリクエスト」から始めることを推奨している。
詳細はGitHub launches HydraFusion to make several AI models do one coding jobを参照していただきたい。
