GitHub Copilot の HydraFusion とは — Copilot CLI が実行時にモデルをルーティングする仕組みと、コストと品質の読み方

「どのモデルを選ぶか」を実行時に決める仕組みが出てきました

GitHub が 2026 年 9 月 4 日、Project HydraFusion を公式ブログで公開しました。ステータスはリサーチプレビューです。

やっているのは、複数プロバイダのモデルの中から使うモデルを選び、草案の作成、批評と修正、より強力なモデルへのカスケードといった処理を、実行時に組み立てることです。開発者が先に 1 つのモデルを選んで固定する形ではありません。

AI コーディングツールの比較は、これまで「どのツールのどのモデルを選ぶか」という話でした (Claude Code・Cursor・GitHub Copilot の実務比較)。HydraFusion はその選択自体を製品側へ寄せます。本記事では、公開された内容と数字を、コストと品質に分けて整理します。

3 つの実行パターン

HydraFusion が組み立てる構成は 3 つに整理されています。

flowchart LR
  IN([入力]) --> R{構成を決める}
  R -->|Single| S[1 つのモデルが解く] --> OUT([出力])
  R -->|Cascade| C1[効率的なモデルが草案] --> G{品質ゲート}
  G -->|受理| OUT
  G -->|エスカレーション| C2[より強いモデル] --> OUT
  R -->|Critique| K1[草案を作るモデル] --> K2[別ファミリーの批評役<br/>読み取り専用]
  K2 --> K3[草案を書いたモデルが 1 回だけ修正] --> OUT

Critique で押さえておきたいのは 3 点です。批評役が 別のモデルファミリー であること、批評役が 読み取り専用 であること、そして修正が 1 回だけ と決まっていることです。

批評役を別ファミリーにするのは、同じモデルに自分の草案を見直させても同じ見落としをする、という前提に立った設計です。読み取り専用に固定しているため、批評役が勝手にコードへ手を入れることはありません。修正回数の上限が 1 回であることは、品質の上限を抑える代わりに、費用と所要時間の上振れを抑える方向に働きます。

ベンチマークはコストと品質を分けて読む

公式ブログには 3 つのベンチマークの数字が出ています。比較対象はいずれも Claude Opus 5 です。

コスト側は 3 つとも下がっています。一方で品質側は、上がったのが TerminalBench 2.1 の +4.9 ポイントだけで、DeepSWE は -1.5 ポイント、CheckpointBench は -0.1 ポイントと下がっています。

つまり公表値は「安くなって品質も上がる」ではありません。大きく安くなり、品質はベンチマークによって上下する、と読むのが正確です。CheckpointBench の -0.1 ポイントは小さい値ですが、公表されている向きは下です。3 つのうち 1 つで品質が上回ったことをもって、Claude Opus 5 より優れていると一般化することはできません。

数字の意味を取り違えないために、2 つの軸を別々に見てください。コスト削減率は、同じ作業をいくらで終えたかを表します。品質のポイント差は、その作業の出来がどれだけ変わったかを表します。片方だけを引用すると、判断の材料としては足りません。

FIXIT

安くなるんでしょ。だったら全部これでいいんじゃないの？

Hayate

3 つのうち 2 つは品質が下がっています。コスパで言うと、下がった分を吸収できる作業かどうかが先です。

FIXIT

じゃあ、どの作業なら下がっても平気なの？

Hayate

やり直しが軽い作業です。調査や下書きは安く回し、手戻りの高い難所は上位モデルを指定するほうが結局速いです。

Copilot CLI で有効にする手順

公式ブログに書かれている手順は 3 段階です。

/update           # Copilot CLI を最新版にする
/experimental on  # 実験機能を有効にする
/model            # 一覧から HydraFusion (Research Preview) を選ぶ

提供範囲は すべての GitHub Copilot プラン です。GitHub Copilot CLI の /experimental 経由で利用します。プランごとに使える・使えないが分かれる形ではないため、手元の契約を確認する手間はかかりません。

Copilot CLI そのものの導入や、モデル一覧が更新されるタイミングについては、GitHub Copilot のモデル提供終了と移行先 でも扱っています。

課金はモデルごとの標準レートで計算される

課金は、HydraFusion が使ったモデルの消費トークンに基づき、各モデルの標準レートで計算されます。HydraFusion 自体に固有の単価が設定されているわけではありません。

この形だと、実行前に金額を見積もりづらくなります。Cascade でエスカレーションが起きれば上位モデルの消費が加算され、Critique では批評役のモデルの消費も乗ります。どの構成が選ばれるかは実行時に決まるため、同じような依頼でも支払額が一定になるとは限りません。

公表されているコスト削減率は、あくまで 3 つのベンチマーク上の数字です。自分のリポジトリで同じ削減率になるかどうかは、実際に測って確かめてください。Copilot 全体の課金の考え方は GitHub Copilot の課金改定 にまとめています。

「モデルを 1 つ選ぶ」から「実行時にルーティングする」へ

ここまでの内容で発想が変わるのは、モデル選択を誰が決めるかという点です。

これまでのモデル選択は、作業の種類ごとに人が振り分ける設計でした。難所の改修は上位モデル、調査やサブエージェントは軽いモデル、という分け方です (Claude の Opus と Sonnet の使い分け)。振り分けの基準を決めるのも、切り替えを運用に乗せるのも人の仕事でした。

HydraFusion は、この振り分けを実行時に製品側が決めます。人が決めるのは「HydraFusion を選ぶかどうか」までで、その先の構成には介入しません。手間が減る代わりに、どのモデルがどこを担当したかを人が指定できなくなります。

どちらが優れているかという話ではなく、何を手放すかという話です。振り分けの設計を自分たちで持ちたいなら従来どおりモデルを指定し、設計の手間を減らしたいなら製品側に委ねる、という選び方になります。

評価するなら何を見るか

リサーチプレビューの段階で見ておくべき点を 3 つに絞ります。

1. 品質が下がっても手戻りが小さい作業から試してください。 調査、下書き、定型的な変更あたりが候補です。公表値で品質が下がっているベンチマークがある以上、失敗のやり直しが高くつく作業をいきなり預ける理由はありません。

2. コストは自分の作業で測ってください。 67% や 65% という削減率はベンチマーク上の値で、リポジトリの構造や依頼の粒度が変われば結果も変わります。判断に使うなら、同じ依頼を従来のモデル指定でも走らせて比べてください。

3. リサーチプレビューである点を見込んでください。 提供条件や挙動が今後変わる前提で触る必要があります。社内の標準ワークフローに組み込むのは、ステータスが変わってからで間に合います。

FIXIT がこの発表をどう見ているか

FIXIT は AI 駆動開発のクリエイティブスタジオとして、Claude Code を主力に据えて日々のクライアントワークを回しています。難所のレビューは上位モデルに寄せ、数で回す調査は軽いモデルへ振り分ける、という使い分けを自分たちで設計してきました。

HydraFusion が提示しているのは、その設計を製品側に委ねる選択肢です。手放す部分がある以上、主力の構成をそのまま置き換える判断にはなりません。一方で、振り分けの設計を持てないチームにとっては、選択肢が 1 つ増えたことになります。自社で振り分けを設計する体力があるかどうかが、評価の分かれ目です。

どのツールをどう組み合わせるか迷っている段階なら、AI 開発ツール導入支援 で現状のフローに合わせた選定と定着まで伴走しています。相談したい内容が固まっていなくても、お問い合わせ から状況を教えていただければ、判断の材料を一緒に整理します。

まとめ

コスト削減率だけを取り出すと判断を誤ります。見るべきなのは、下がった品質を自分たちの工程で吸収できるかどうかです。