モデルピッカーに「Hydrafusion (Preview)」という項目が増えた。これは新しいモデルなのか、Autoと何が違うのか、課金はどうなるのか。Copilotを使う開発者も、全社で許可するか迷う管理者も、最初に引っかかるのはこの3点です。
HydraFusionはモデルではなく、1回の依頼ごとに「どのモデルを何回、どの順で使うか」を決める仕組みです。便利そうに見える一方で、待ち時間が延びる、専用割引がない、研究プレビューでSLAがない、といった条件も付いています。
2026年10月時点の公式ドキュメントとchangelogをもとに、仕組み、有効化手順、コストの読み方、組織としての試し方までを整理します。公式に書かれていない点は、書かれていないと明記します。
この記事でわかること
- HydraFusionがAutoや通常のモデル選択と何が違うか
- Single・Cascade・Critiqueの3つの実行パターンとMaxオプションの位置づけ
- VS Code・GitHub Copilot app・Copilot CLIでの有効化手順と、項目が出ないときの確認先
- 「コスト67%減」が3つのベンチマークのうち最良値である理由と、課金の実務
- 向く作業・向かない作業、管理者が確認すべきポリシーと少人数パイロットの進め方
HydraFusionは複数モデルを指揮するオーケストレーター
HydraFusionは「新しいモデル」ではありません。ランタイムで動くモデルオーケストレーターで、リクエストごとに実行パターン、推論effort（どれだけ深く考えさせるかの設定）、使うモデルを選び、最終的に1つの応答だけを返します。仕様はGitHub Docsの解説ページにまとまっています。
ユーザーから見れば、モデルピッカーに並ぶ選択肢の1つです。中でどのモデルが動いたかは選べません。
Autoとの違いは「1モデルを選ぶ」か「ワークフローを組む」か
Autoは1リクエストにつき1つのモデルを選びます。HydraFusionは1ターンの中で作業の流れ（ワークフロー）を選び、複数のモデルを調整します。GitHub公式の日本語ブログでもこの対比が使われています。
たとえるなら、Autoは「案件を見て担当者を1人アサインする」仕組みです。HydraFusionは「新人が下書きを書き、別チームのレビュアーが見て、必要ならシニアに回す」という工程そのものを自動で組みます。判断の材料は、推論・コード生成・デバッグ・ツール利用といった能力のシグナルで、品質基準を満たす範囲でいちばん効率のよい経路が選ばれます。
3つの実行パターンはプロンプトごとに切り替わる
選ばれるワークフローは3種類です。1つのセッションの中でも、プロンプトによって混ざります。
| パターン | 動き | 向いている場面 | 注意点 |
|---|---|---|---|
| Single | 1つのモデルが直接解く | 単純な依頼 | 通常のモデル利用に近い |
| Cascade | 効率的なモデルが下書きし、judge（品質ゲート）が採用か上位モデルへのエスカレーションかを判定 | 大半は軽く済むが、一部だけ難しい依頼 | 品質ゲートの判定基準は公式に記載がない |
| Critique | 1つのモデルが下書きし、別ファミリーのモデルが読み取り専用でレビューし、下書きモデルが1回だけ修正 | 見落としが怖い複雑な修正 | 時間がかかる |
Cascadeは「安いモデルで済むものは安く済ませる」ための経路です。Critiqueは「別の目で見る」ための経路で、レビューのやり方はCopilotのRubber Duckと同じパターンだと説明されています。CascadeとCritiqueは追加のパスを踏むため、Singleより待たされます。
10月14日の更新で、現行仕様は次のように変わりました。効率の観点では下書きのeffortがmedium、レビューがhighにステージごと分けられています。Cascadeには、初回結果を検査して必要なときだけ修復を求めるjudgeが入りました。Critiqueは、ツールで実際のワークスペースを直接検査し、並列の批評モデルを使います（10月14日のchangelog）。
古い解説記事に「批評役はツールにアクセスできない」と書かれていることがありますが、それは9月時点の仕様です。
モデルプールは時期で変わり、ユーザーは選べない
10月14日のchangelogでは、プールとして Claude Opus 5.5、GPT-6 Astra、GPT-6.1 Sol、GPT-6 Luna が挙がっています。どのタスクにどのモデルを当てるかは、ワークフロー次第です。
一方、ドキュメント側には固定のモデル一覧がなく、構成は時期で変わると書かれています。9月30日時点のchangelogにはモデル名がなく、「効率的なモデル」「強いモデル」「別ファミリーの批評役」という表現でした。上のモデル名は2026年10月時点の例として読んでください。
MaxはHydraFusionの上位設定
Maxは、同じ仕組みを高難度タスク向けに調整したオプションです。最も深い推論と網羅的な分析が要る作業を想定しています。ドキュメントでは、HydraFusionがバランス型でトークンを中程度に節約する設定、Maxは推論の深さを重視してextra-highの推論を加える設定、Autoは日常的で定型的な作業向け、と整理されています。
Maxの並列criticが増える、という解説を見かけますが、公式からは確認できていません。Maxの具体的なeffortは10月14日のchangelog自体には書かれておらず、extra-highはドキュメントの記述です。
有効化はVS Code・Copilot app・CLIで手順が違う
3つの経路のどれも、設定を1つ有効にしてモデルピッカー（CLIなら/model）で選ぶ流れです。ただし前提条件が違うので、先に対象プランと権限を確認しておくと、後で「出てこない」と迷いません。
対象プランは資料によって書き方が違う
プランの書き方は、公式の中でも食い違っています。
| 時期・資料 | 書かれている対象 |
|---|---|
| 9月4日のブログ（CLIの初回公開） | 全Copilotプラン |
| 9月30日のchangelog（VS Code・app拡大） | Copilot Pro / Pro+ / Business / Enterprise |
| ドキュメント | プラン名は列挙せず、プランに含まれ、組織やエンタープライズのモデルポリシーで許可されたモデルのみを使う。使えるモデルがなければピッカーに出ない |
Freeプランで使えるかは、公式からは確認できていません。個人で試す人は、自分の画面にピッカー項目が出るかどうかで判断するしかありません。
BusinessとEnterpriseでは、管理者によるプレビュー機能の許可が必要です。10月14日のchangelogには、実験的・プレビュー機能を有効にし、組織のモデルポリシーに従う必要があると書かれています。
経路ごとの手順
VS Codeでは、1.140以降またはInsidersを使います。Copilot Chatのモデルピッカーで選びます。項目が出ない場合は設定chat.copilot.hydraFusion.enabledを有効にします（9月30日のchangelog）。
{
"chat.copilot.hydraFusion.enabled": true
}GitHub Copilot appでは、最新版に更新してSettings（ドキュメント上はSettings > Experimental）でHydraFusionをオンにし、モデルピッカーから選びます。
Copilot CLIは次の流れです。
copilot update
copilot --experimental
# 起動後に /model を実行し、HydraFusion または
# HydraFusion Max (Research Preview) を選ぶ/experimental onで実験機能をオンにして再起動する方法もあります。1回だけ実行するなら、次のように指定します。
copilot -p "このテストが落ちる原因を調べて修正して" --model hydrafusionプレリリース版を使うときは/update prereleaseです。
モデルピッカーに出ないときの確認先
出ないときは、次の順で見ます。
- 設定（VS Codeなら
chat.copilot.hydraFusion.enabled、appならExperimental）が有効か - VS Codeのバージョンが1.140以降か、appが最新か
- BusinessまたはEnterpriseなら、管理者がプレビュー機能を許可しているか
- 組織のモデルポリシーで、プールのモデルが許可されているか
4つ目は見落とされやすい点です。HydraFusionは許可されたモデルだけを使う作り上、許可されたモデルが足りなければ項目そのものが出ません。「設定は有効なのに出ない」場合は、ポリシー側を疑うのが近道です。
ここまでで試すだけの準備は整います。ただし、組織で何を決めておくべきかは、次の2つのセクションを読んでからのほうが判断を誤りません。
「コスト67%減」は3つのベンチのうち最良値で、課金は標準レートの積み上げ
HydraFusionの数字は、見出しだけ読むと誤解します。専用の追加料金はなく、呼び出した各モデルの標準レートで課金されます。単一モデルより消費が増える場面もあります。
公式ベンチマークは条件付きで読む
9月4日のブログの評価は、Claude Opus 5を基準にしたオフライン評価です。全モデルをmedium effortで動かしています。
| ベンチマーク | 検証済みタスク品質（基準との差） | 推定コスト |
|---|---|---|
| TerminalBench 2.1 | +4.9pt | 67%減 |
| DeepSWE | -1.5pt | 36%減 |
| CheckpointBench（GitHub内部のマルチターン） | -0.1pt | 65%減 |
「67%減」はTerminalBench 2.1の値で、3つの中の最良値です。DeepSWEでは品質が1.5pt下がり、削減幅は36%でした。しかもコストは実測の請求額ではなく推定値です。特定のベンチマーク版、ワークフロー設定、モデルプール、価格の仮定で出た結果で、評価ハーネスの失敗2回分は除外されています。最も調整した構成の結果で、評価セット全体で方針を改良しているため楽観的な可能性がある、とも書かれています。TerminalBench 2.1自体も飽和気味と書かれています。
この表を読むなら「品質を大きく落とさずに、おおむね3〜6割台のコストを削れる可能性が、特定条件で示された」が限度です。自社のリポジトリで同じ比率が出る保証はありません。
10月14日に入れ替わった新しいプール（Claude Opus 5.5やGPT-6系）とMaxでのベンチマーク数値は、公式からは確認できていません。上の数字は9月4日時点の構成のものです。
課金の実務は5点に絞れる
ドキュメントと9月4日のブログから、実務で効く点を挙げます。
- 専用料金はなく、使った各モデルの標準レートで課金される
- Autoにあるような割引は適用されない
- 単一モデルよりAI creditsを多く消費しうる
- コスト追跡には、下書き・批評・修正・エスカレーション・リトライ・フォールバックの各トークンが含まれる
- CLIでは
/usageでモデル別の使用量を確認できる
節約のコツも書かれています。メインの会話はできるだけ1つのモデルに固定してキャッシュされたトークンを温存し、補助モデルには必要な文脈だけを渡す設計です。ユーザー側が操作できる余地は少ないため、「コストを下げる機能」というより「コストと品質の配分を任せる機能」と理解したほうが実態に合います。
premium requestsとの関係は、ドキュメントにも9月30日・10月14日のchangelogにも記載がありません。請求画面でどう数えられるかは、自分のアカウントで確認するしかないのが現状です。
待ち時間もコストの一部になる
下書きの途中経過は、最終結果が出るまで表示されません。9月4日のブログも、これを現状の現実的なトレードオフとして認めています。その後の更新で、ワークフローの各ステップの可視化、進捗更新の頻度向上、長時間タスクの状態表示が入りました。
待ち時間は、Cascade・Critiqueを通るほど延びます。1回あたりは小さな差でも、1日に何度も依頼する人にとっては、積み重なってチーム全体の生産性に響きます。
ツール選定の比較軸については、AIコーディングツール比較で整理しています。HydraFusionの数字を、他のツールのコストと並べて見る前提知識になります。
HydraFusionが向く作業と、組織で確認すべきこと
向くのは、追加パスの時間とクレジットに見合う、範囲の明確な作業です。日常的な定型作業はAutoのままで足ります。そのうえで組織が確認すべきは、ポリシー、コスト検証、本番での扱いの3つです。
向く作業と向かない作業
ドキュメントと9月4日のブログが挙げる適性を、判断しやすい形にまとめます。
| 作業 | 判断 | 理由 |
|---|---|---|
| 複雑なバグ修正、複数ファイルにまたがる変更 | 向く | 下書きとレビューの追加パスが品質に効く |
| 初回ターンの単発プロンプト、範囲が明確なコーディング | 向く | 推奨されている使い方 |
| 最深の推論と網羅的な分析が要る作業 | Maxを検討 | extra-high推論を追加した設定 |
| 日常・定型の作業 | Auto | 待ち時間と消費に見合わない |
| 長いマルチターンの対話 | 慎重に | マルチターン性能は現状の重点外と書かれている |
Autoは「安く速く済ませたい日常作業」、HydraFusionは「時間とクレジットを払ってでも失敗を減らしたい作業」と使い分けるのが自然です。Cursorなど他の環境との役割分担を考えるときは、CursorとGitHub Copilotの比較も判断材料になります。
制約は運用ルールに落とす
ドキュメントに書かれた制約のうち、運用に直結するものは次のとおりです。
- 採用されなかった下書きが加えた編集は、自動では元に戻らない。コミット前に差分を必ず確認する
- サブエージェントとは別の動きで、起動しない
- コンテキストウィンドウは各ステップのモデルの上限になる。画面に出る値は、最小のモデルに合わせた保守的な値
- 研究プレビューのため、仕様は変わる。SLAはなく、本番のワークロードは想定されていない
とくに下書きの編集は、実務で効きます。HydraFusionにリポジトリを触らせるなら、作業用ブランチを切ってからにするのが前提です。エージェントハーネスの考え方でいう、実行の安全な枠の中に置くということです。
管理者が見るポリシーと廃止モデルの論点
管理者が押さえる論点は、公式に書かれたことと、そこから導ける運用上の推測を分けて考えます。
公式に書かれていることは3つです。第一に、HydraFusionは組織やエンタープライズのモデルポリシーで許可されたモデルだけを使います。第二に、BusinessとEnterpriseでは管理者のプレビュー許可が必要です。第三に、Copilot model policy APIが10月19日に一般提供になりました。RESTのGET/PATCHで、エンタープライズ、エンタープライズのチーム、エージェントアプリ、組織の各階層のモデルポリシーを操作でき、制御を組織やチームへ委任できます。必要な権限とプラン条件はchangelogに書かれていません。
ここから先は推測です。HydraFusionとこのAPIを公式が直接結びつけた記述は確認できていません。ただ、プールのモデルが許可されていなければHydraFusionが使えない構造なので、「パイロット対象チームだけにプールのモデルを許可する」運用をAPIで管理する、という使い方は十分に考えられます。
廃止モデルも絡みます。10月19日にGPT-5.5/5.4系などが廃止され、置換先モデルは管理者が有効化する必要があります（廃止のchangelog）。プールの新しいモデルが有効化されていなければ、HydraFusionも期待どおりに動きません。HydraFusion固有の利用状況メトリクスへの対応は、確認できていません。
モデルポリシーの設計は、AIコーディングの導入全体の設計とつながります。コード生成AIの導入全般はコード生成AIの解説が参考になります。
少人数パイロットの進め方
ここからは、公式の記述ではなく当協会の提案です。判断基準は「Autoや単一モデルより、同じ作業が少ない手戻りで終わるか」の1点に置きます。
- 管理者がプレビュー許可とモデルポリシーを、対象チームだけに限定して設定する
- 5〜10人程度のチームを選び、作業用ブランチで使うルールを決める
- 同種のタスク（複雑なバグ修正など）を、Auto・単一の上位モデル・HydraFusionで回して並べる
- 所要時間、手戻り（レビュー指摘の数）、
/usageなどで見たクレジット消費を記録する - 2〜4週間分の記録から、HydraFusionを使うタスクの種類を絞って運用ルールにする
測るのは、67%のような削減率そのものではありません。自社のコードで、待ち時間を払う価値がある作業の種類が見つかるかどうかです。見つからなければ、プレビュー期間中は静観するのも立派な判断になります。
こうした検証と運用ルールづくりを、チームで進める方法を体系的に学びたい場合は、AI駆動開発研修で、AIコーディングツールの使い分けと開発プロセスへの組み込み方を扱っています。
よくある質問
HydraFusionは新しいAIモデルですか？
違います。リクエストごとに実行パターン・推論effort・使うモデルを選び、複数モデルを調整して1つの応答を返すオーケストレーターです。モデルピッカーに表示されますが、中で動くモデルは選べません。
HydraFusionは追加料金がかかりますか？
専用の追加料金はありません。使った各モデルの標準レートで課金され、Autoの割引は適用されません。単一モデルより多くのAI creditsを消費する場合があります。premium requestsとの関係は、公式から確認できていません。
Freeプランでも使えますか？
確認できていません。9月4日のブログは全プラン、9月30日のchangelogはPro・Pro+・Business・Enterpriseと書いており、食い違っています。ピッカーに出るかどうかで確認してください。
表示されないときはどうすればよいですか？
設定の有効化、VS Codeまたはappのバージョン、管理者のプレビュー許可、組織のモデルポリシーの4点を確認します。許可されたモデルがなければ、ピッカーに出ない仕様です。
本番の開発業務で使ってよいですか？
研究プレビューで、SLAはなく、本番のワークロードは想定されていません。作業用ブランチで使い、コミット前に差分をレビューする運用が前提です。
まとめ
まず試すなら、個人は自分のVS Codeかターミナルで有効化し、複雑なバグ修正1件をAutoと並べて比べるのがいちばん早い方法です。管理者は、先にプレビュー許可とモデルポリシーを確認し、対象を小さなチームに絞ってから許可します。
67%減のような数字を根拠に全社展開を決めるのは早すぎます。自社のコードで、手戻りと消費クレジットがどう動くかを数えてからです。公式のとおり仕様が変わりうるプレビューなので、採用の判断は期間を区切って見直すのが現実的です。
AIコーディングツールの選定と運用ルールの設計を、チームとして進めたい場合は、AI駆動開発研修で、実際の開発フローに合わせた使い分けと検証の進め方を学べます。
