GitHubの最新のCopilot実験で最も興味深い数字は、品質スコアではなく請求額です。難度の高いターミナル系ベンチマークで、コストは67％少なく、スコアはClaude Opus 5を4.9ポイント上回りました。これがGitHubの公表したProject HydraFusionの目玉となる結果です。このリサーチプレビューは、コーディングタスクをどのモデルに任せるかを問うのをやめ、いくつのモデルをどの順番で使うかを問い始めました。
要点
- HydraFusionはTerminalBench 2.1でClaude Opus 5のベースラインを4.9ポイント上回り、推定コストは67％低く抑えました。他の2つのスイートでもそれぞれ36％、65％安く、ほぼ同等の成績を収めています。
- 単一モデルに振り分けるのではなく、リクエストごとに下書き・上位モデルへの引き上げ・他系列モデルによる読み取り専用のレビューを組み合わせた実行計画を組み立てます。
- すべてのCopilotプランがCopilot CLI上で有効化でき、実際に呼び出されたモデルの通常のトークン料金以外に追加費用はかかりません。
品質の行よりコストの行が重い理由
エージェント型コーディングには、ベンチマーク表が覆い隠しがちな経済性の問題があります。長くツール呼び出しの多いタスクをフロンティアモデルに丸ごと預けるチームは、ループのすべての区間にフロンティア価格を払います。安価なモデルでも問題なく片づいたはずの区間まで含めてです。HydraFusionは、その区間ごとに値付けし直そうというGitHubの試みです。
公開された根拠は、エージェント系3スイートのオフライン実行結果です。Opus 5とGPT-5.6 Solを参照値に置き、すべてのモデルの推論レベルを中程度に固定しました。3つのうち2つは実質的に「同等の性能をより安く」買った形です。リポジトリ横断の作業に負荷をかけるDeepSWEでは、Opus 5との差が1.5ポイント以内で36％安く終わり、CheckpointBenchでは0.1ポイント差で65％安く済みました。明確な品質上の上積みが出たのはTerminalBench 2.1だけで、GitHubはこのスイートが比較的飽和していると付け加えています。残る2つも回した理由はそこにあります。
CheckpointBenchはGitHub自身が作ったものだけに、もう一度見ておく価値があります。実際のCopilotセッションの軌跡を集めて構築し、各会話を公開リポジトリの不変のコミットに固定して再実行できるようにしたうえで、言語・タスク種別・難易度のバランスを取っています。公開リーダーボードよりも実トラフィックに近い一方で、GitHubの外部からは誰も検証できません。
開発記録には、珍しく率直な注記が添えられています。8月11日から25日にかけて評価基盤で2件の運用障害が発生し、無効となった実行結果はトレンド線を引く前に除外されたというものです。
1つのプロンプトが複数モデルの計画になるまで
HydraFusionは推論の深さ、コード生成、デバッグ、ツール利用といった能力シグナルを読み取り、基準を満たせると判断した3つの形のうち最も安いものを選びます。1つのモデルが単に答える場合もあります。高速なモデルが下書きを書き、品質ゲートがそのまま出すか、より強力なモデルへ引き上げるかを判断する場合もあります。あるいはGitHubがラバーダックレビューになぞらえる形もあります。下書き役が成果物を出し、別系列のレビュー役がツールを一切持たずにそれを読み、下書き役には構造化された修正の機会がちょうど一度だけ与えられます。
これらの閾値は人手で決めたものではありません。GitHubは固定したベースラインに対して能力別スコアにビームサーチをかけ、特定のスイートを追いかけるのではなく3つを同時に見ながら調整しました。目玉の数字が出たベンチマークが飽和気味である以上、この選択には意味があります。
これまでのところ、［HydraFusionの］推論能力と課題解決能力はOpusと同等かそれ以上だ。
社内で検証したマイクロソフトのプリンシパルソフトウェアエンジニアによる評価です。
先に固めておく必要があったこと
複数のモデルを1つの作業ツリーに向けると、単一モデルのループにはない失敗の形が現れます。審査役が審査対象のコードを書き換えてしまう、中断された実行が中途半端に当たったパッチを残す、コストが6つの区間に分散して誰にも帰属できなくなる、といった具合です。GitHubの答えは強い制約を課すことでした。レビュー役はツールなしで動き、書き込みはできません。検証で弾かれたりキャンセルされたりした場合、パッチは部分適用ではなく丸ごと破棄されます。すべての区間にタイムアウトとキャンセル用のハンドルを持たせ、実行前にモデルのバインディングを検証します。トークン消費は下書き・批評・修正・引き上げ・再試行・フォールバックをすべて合算し、ワークフロー全体に1つの数字として紐づけられます。
有効化の方法と、まだできないこと
入り口はCopilot CLIです。クライアントを更新し、実験的な設定を有効にすると、モデル選択の一覧にHydraFusionが現れます。ただし2回引き上げが起きたり批評フェーズが挟まったりするタスクは、一発で片づく同じタスクより高くつきます。課金は実際に呼び出されたモデルに従うためです。
GitHubは初期利用者に対し、範囲が明確で規模の大きい単発プロンプトの作業を勧めており、長い反復セッションへの対応は次の技術課題だとしています。自ら認める粗さもあります。プレビューは一貫した答えが1つ仕上がるまで途中の下書きを出しません。破棄される作業が完成品のように見えてはいけない、という理由ですが、実際には何が起きているのか分からないまま進捗表示を眺めることになります。意見はCopilotコミュニティのスレッドで集められています。
今後の見通し
これらの数字は結論ではなく仮説として扱うべきです。オフラインの計測であり、特定のモデルプールと特定の価格前提に結びついています。プレビュー自体が、実際の開発者が雑然とした仕事を投げ込んだときにも同じ数字が保たれるかを確かめるために存在します。もし保たれるなら、競争の問いは「誰のモデルが最も強いか」から「誰が最もうまく振り分けるか」へ移ります。単一の研究所よりも、複数のプロバイダーを使える立場のプラットフォーム事業者に有利な移り方です。しかもこの実験は、GitHubが自社インフラ全体でエージェント由来の処理量急増を受け止めている最中に出てきました。その点はコミット数の伸びを扱った記事で取り上げています。
よくある質問
Project HydraFusionはGitHub Copilot CLI以外でも使えますか？
まだ使えません。Copilot CLI内で実験的な設定を有効にした場合にのみ提供されます。IDE拡張やCopilotアプリへの展開時期は公表されていません。
Copilotの購読料に加えて追加費用はかかりますか？
別建ての料金はありません。ワークフローが呼び出した各モデルについて通常のトークン料金を支払うため、タスクの価格は完了までにいくつの区間を経たかで変わります。
HydraFusionはどのモデルを使っていますか？
GitHubはプールの内訳を公開しておらず、複数のプロバイダーにまたがるとだけ説明しています。レビュー役は下書き役とは意図的に別系列から選ぶとしています。Opus 5とGPT-5.6 Solは評価のベースラインであり、必ずしもプールの構成モデルというわけではありません。
