2026年10月1日時点で、HydraFusionはGitHub Copilotのモデルの選択肢(モデルピッカー)に並ぶ研究プレビューの機能で、1つのモデルではなく、依頼ごとにSingle・Cascade・Critiqueの3つの実行パターンから1つを選び、複数のモデルを動かして1つの回答を返します。GitHubは2026年9月30日(米国時間)の変更履歴で、それまでCopilot CLIだけだった提供先を、VS Code(バージョン1.140以上かInsiders)とGitHub Copilotアプリに広げました。対象はCopilot Pro・Pro+・Business・Enterpriseで、BusinessとEnterpriseでは管理者がプレビュー機能を有効にする必要があります。HydraFusion自体に別料金はなく、使ったモデルごとの標準の単価でAIクレジットが減ります。
この記事の要点(2026年10月1日時点)
- HydraFusionはモデルの選択肢に出ますが、モデルではありません。依頼ごとに実行パターンと、それを動かすモデルを選び、最後に1つの回答を返す仕組みです
- 2026年9月30日から、Copilot CLIに加えてVS Code(1.140以上かInsiders)とGitHub Copilotアプリで使えます。研究プレビューのため、SLAはなく、本番のワークロード向けではありません
- 料金は使ったモデルごとの標準の単価で計算し、AIクレジット(1クレジット=0.01ドル、約1.5円)で引かれます。Autoの割引は付かず、1つのモデルより多く使うことがあります
- GitHubが9月4日の研究ブログで公開したオフライン評価では、Claude Opus 5と比べて推定費用が36〜67%低く、品質はTerminalBench 2.1で4.9ポイント高く、DeepSWEで1.5ポイント低い結果でした
- 公式の使い分けは、日常の作業はAuto、範囲がはっきりした大きめのコーディング作業はHydraFusionです
対象読者:GitHub Copilotを使っている開発者と、組織でCopilotを管理している担当者。読み終えたらできること:HydraFusionを自分の環境で有効にし、Autoや自分で選んだモデルとどう使い分けるか、使った量をどこで確かめるかを決められます。
この記事は、GitHubの変更履歴「HydraFusion in VS Code and the GitHub Copilot app」(2026年9月30日)、GitHub Docsの「Using HydraFusion」、HydraFusionを最初に紹介した研究ブログ「Project HydraFusion: Frontier quality via multi-model orchestration」(2026年9月4日)を、2026年10月1日に読んで整理したものです。料金は、GitHub Docsの料金ページと、旧来のリクエスト課金の倍率表で確かめました。
HydraFusionとは|1つのモデルではなく、複数のモデルを動かす仕組み
HydraFusionは、GitHub Copilotの中で動く、実行時のモデルの編成役です。モデルの選択肢から選びますが、それ自体はモデルではありません。公式ドキュメントは、Autoは依頼ごとに1つのモデルを選ぶ仕組みで、HydraFusionは作業ごとに実行パターンを選ぶ仕組みだ、と違いを説明しています。実行パターンを選ぶと、そのパターンを動かすモデルも決まり、途中で複数のモデルが動いても、利用者に返るのは1つの回答です。

選び方について、変更履歴は「ワークフローの選択を最適化の問題として扱う」と書いています。推論・コード生成・デバッグ・ツールの使用という4つの能力の信号をもとに、品質の基準を満たす中で最も効率のよい実行パターンを選びます。2026年10月1日時点で選ばれるのは、Single・Cascade・Critiqueの3つのどれかです(次の節で表にします)。変更履歴は、Autoとの違いを「Autoは依頼ごとにモデルを選ぶ。HydraFusionは、1回のやり取りの中でワークフローを選び、複数のモデルを連携させる方法を探るもの」とも書いています。
GitHubは9月4日の研究ブログで、HydraFusionを、ローカル・クラウド・複合のモデルの間で依頼の中身に合わせて自動で振り分ける、という全体の方針の中に位置づけています。利用者から見ると、ほかのモデルと同じように選ぶだけで、性能・費用・待ち時間の釣り合いを取ったワークフローが作業ごとに選ばれる、という形です。
使う前に知っておきたい性質
公式ドキュメントには、使い方に関わる性質がいくつか書かれています。
- 実行パターンは依頼(プロンプト)ごとに選ばれます。同じセッションでも、最初の依頼はSingle、次の依頼はCritiqueということがあります
- 実行パターンを選ぶ処理は軽く、時間はほとんど増えません。この処理が回答の一部を作ることはありません
- 使うモデルは、単純な作業向けの速いモデルから、難しい問題向けの推論の強いモデルまでの組み合わせです。新しいモデルの登場やGitHubの評価によって変わるため、決まったモデルの一覧はありません
- どのモデルを使うかを利用者は選べません。使われるのは、自分のプランで使え、組織や企業のモデルのポリシーで許可されたモデルだけです
- HydraFusion自体には文脈の長さ(コンテキストウィンドウ)がありません。各段階は、その段階を動かすモデルの上限の中で動き、表示される値は、使うモデルの中で最も小さい上限をもとにした控えめな値です
- HydraFusionはサブエージェントとは別に動き、サブエージェントを起動しません
3つの実行パターン|Single・Cascade・Critiqueの違い
3つの実行パターンは、品質と費用の釣り合いの取り方が違います。研究ブログは、Singleは1つのモデルで直接解ける時に速さと効率を保つ、Cascadeは効率的なモデルに最初の挑戦を任せつつ、合格の基準に届かない時に強いモデルへ進む道を残す、Critiqueはもう一度1人で解き直すより見直しが役に立つ作業に、別の視点を加える、と説明しています。

| 実行パターン | 何が起きるか(変更履歴の記載) | 向いている作業(研究ブログの説明) | かかる時間(公式ドキュメント) |
|---|---|---|---|
| Single | 選ばれた1つのモデルが解く | 1つのモデルで直接解ける作業 | 1つのモデルへの依頼とほぼ同じ |
| Cascade | 効率的なモデルが下書きし、品質ゲートが、そのまま受け入れるか、強いモデルへ引き上げるかを決める | まず効率的なモデルに任せ、基準に届かなければ強いモデルに進めたい作業 | 見直しの段階がある分、長くかかる |
| Critique | 1つのモデルが下書きし、別系統のモデルが批評し、下書きしたモデルが1回だけ修正する | もう一度解き直すより、見直しが役に立つ作業 | 見直しの段階がある分、長くかかる |
Critiqueの批評役について、変更履歴は「別のモデルファミリーの、独立した読み取り専用の批評役」と書き、Copilot CLIのRubber Duckと同じレビューの型をとると説明しています。研究ブログが挙げる設計の原則でも、レビューの段階は道具を持たない切り離された環境で動き、リポジトリを書き換えないとされています。下書きを作る段階は、共有の作業場所を使い、通常の権限確認つきのエージェントの流れで動きます。
HydraFusionは、作業に必要な時だけモデルの実行を足します。公式ドキュメントの言い方では、単純な作業が、必要のない見直しを待ったり、その分の費用を払ったりすることはありません。どのパターンが選ばれたかは、VS Codeではチャット欄の表示で、Copilot CLIでは進捗の表示で確かめられます。
なお、名前が似ているものにMicrosoft 365 CopilotのCritiqueがあります。こちらはMicrosoft 365 Copilotの機能で、GitHub CopilotのHydraFusionとは別の製品の話です(姉妹メディアのMicrosoft 365 CopilotのCritiqueの記事)。
有効にする手順|VS Code・Copilotアプリ・Copilot CLI
2026年10月1日時点で、HydraFusionが使えるのはCopilot CLI、VS Code、GitHub Copilotアプリの3つです。どれも、まず機能を有効にし、モデルの選択肢でHydraFusionを選ぶ、という流れは同じです。組織や企業からCopilotを使っている場合は、先に管理者がプレビュー機能を許可している必要があります。

VS Codeで有効にする
VS Codeのバージョン1.140以上か、VS Code Insidersが必要です。公式ドキュメントの手順は次のとおりです。
- 設定エディターを開く(Windows・LinuxはCtrl+,、MacはCommand+,)
chat.copilot.hydraFusion.enabledを検索し、チェックを入れる- タイトルバーのチャットのアイコンから、Copilot Chatを開く
- チャット欄の下にある、いま使っているモデル名のメニューを開き、HydraFusionを選ぶ(Autoの下に出る)
- 依頼を入力する。HydraFusionが動いている間、チャット欄に実行パターンの各段階が表示される
変更履歴は、モデルの選択肢にHydraFusionが出ない時にこの設定を有効にする、という書き方をしています。選択肢に出ない時は、バージョンが1.140以上か、この設定がオンかを先に確かめます。使われたモデルは、完了した回答の下部(フッター)にマウスを重ねると表示されます。
GitHub Copilotアプリで有効にする
- Copilotアプリを最新版に更新する
- Settings(設定)を開き、Experimentalを選ぶ(変更履歴では、Settingsで「HydraFusion」を検索する手順)
- HydraFusionをオンにする
- モデルの選択肢でHydraFusionを選ぶ
使われたモデルは、回答にマウスを重ねると表示されます。Settingsにこの項目が見当たらない時は、アプリの設定でプレリリースのチャンネルに切り替えるよう、公式ドキュメントは案内しています。
Copilot CLIで有効にする
Copilot CLIでは、2026年9月4日の研究ブログの発表から、実験的な機能として使えました。公式ドキュメントの手順は、最新版に更新し、実験的な機能をオンにして起動するものです。
copilot update
copilot --experimental
すでにセッションの中にいる場合は、/experimental onを入力してから、Copilot CLIを起動し直します。そのあと/modelを入力し、「HydraFusion (Research Preview)」を選びます。スクリプトなどで1回の依頼だけHydraFusionを使う時は、--modelで指定します。YOUR-PROMPTの部分を自分の依頼に置き換えます。
copilot --experimental --model hydrafusion -p "YOUR-PROMPT"
実行中のCopilot CLIには、選ばれた実行パターン、予定している各段階とその状態(完了・実行中・待機中)、いまの段階がしていること(ツールの実行や出力の受け取りなど)、経過時間が表示されます。Escで中断でき、終わった後の会話には、実行パターンと各段階の要約が警告も含めて残ります。選択肢に出ない時は、/update prereleaseでプレリリースのチャンネルに切り替える方法も案内されています。Copilot CLIのほかの使い方は、Copilot CLIのworktree対応の記事で扱っています。
組織・企業では管理者がプレビュー機能を許可する
Copilot BusinessとCopilot Enterpriseでは、管理者がプレビュー機能を有効にしないとHydraFusionは使えません。管理者が確かめることは次の2つです。
| 確かめること | 公式ドキュメントの記載 |
|---|---|
| プレビュー機能の許可 | プレビュー機能を使えるかどうかは、組織と企業のポリシーの設定で決まる。設定の場所はGitHub Docsの「Managing policies and features for GitHub Copilot in your organization」と、企業向けの同名のページ |
| モデルのポリシー | HydraFusionは、プランで使え、組織や企業のモデルのポリシーで許可されたモデルだけを使う。使うモデルが1つも許可されていないと、モデルの選択肢に出ない |
利用者がHydraFusionの使うモデルを選ぶことはできません。管理者が決められるのは、モデルのポリシーでどのモデルを許可するかです。社内で認めていないモデルの提供元がある場合は、利用を広げる前に、HydraFusionが選択肢に出るか、出た時にどのモデルが使われたかを確かめておくと安心です。
9月30日の変更点|提供先の拡大と進捗の表示
9月30日の変更履歴によると、提供先を増やすことは、初期のフィードバックでいちばん多かった要望でした。あわせて、動いている間の見え方が次の3点で改善されました。
- 透明性:ワークフローの各段階でHydraFusionが何をしているかが、より分かりやすくなった
- リアルタイムの進捗:動いている間に、進捗の更新をより頻繁に送るようになった
- 長い作業での状態の表示:作業が長引いても、まだ動いていることが分かりやすくなった
9月4日の研究ブログは、当時の状態を「ワークフローの段階は見せるが、途中の下書きは1つの結果を返すまで出さない」と書き、十分に見えないまま待つことは開発者にとって実際の負担だと認めたうえで、進捗の更新をよくする方法を探っている、としていました。9月30日の改善の3点は、この課題に当たる内容です。なお、途中の下書きは見直しや修正で捨てられることがあるため、最終の回答だけを表示する点は、2026年10月1日時点のドキュメントでも変わっていません。
| 日付(米国時間) | 出来事 | 出典 |
|---|---|---|
| 2026年9月4日 | 研究ブログでProject HydraFusionを発表。Copilot CLIの実験的な機能(/experimental)で研究プレビューを開始 | GitHub Blog |
| 2026年9月10日 | 週ごとの変更のまとめ(9月7日の週)で、Copilot CLIの/experimentalに入ったことを掲載 | GitHub Changelog |
| 2026年9月30日 | VS Code(1.140以上かInsiders)とGitHub Copilotアプリに拡大。進捗の表示を改善 | GitHub Changelog |
| 項目 | 9月4日の研究ブログ | 9月30日の変更履歴と現在のドキュメント |
|---|---|---|
| 使える場所 | Copilot CLI | Copilot CLI・VS Code・GitHub Copilotアプリ |
| 対象プランの書き方 | Copilot CLIの/experimentalで、すべてのCopilotのプラン | Copilot Pro・Pro+・Business・Enterprise(BusinessとEnterpriseは管理者がプレビュー機能を有効にする) |
| 動いている間の表示 | 段階は見せるが、途中の下書きは出さない | 各段階の様子と進捗の更新を増やした。途中の下書きは引き続き出さない |
| 費用の数え方 | 使ったモデルのトークンを、各モデルの標準の単価で計算 | 同じ。Copilot CLIの/usageでモデルごとのAIクレジットを表示できる |
研究プレビューへの感想や不具合は、Copilot CLIの/feedbackか、GitHub CommunityのHydraFusionのフィードバックの議論に送れます。
ベンチマークの読み方|Opus 5と比べたオフライン評価
GitHubは9月4日の研究ブログで、3つのコーディングのベンチマークでの結果を公開しています。比べる相手はClaude Opus 5で、表の数字は、最もよく調整したHydraFusionの設定での結果です。品質は「正しく答えたと確認できたタスクの割合」、費用はワークフロー全体の推定費用で、下書き・批評・修正・引き上げ・再試行・代わりの実行まで、すべての段階を含めて数えています。
| ベンチマーク | 研究ブログの説明 | 推定費用(Opus 5と比べて) | 品質(Opus 5と比べて) |
|---|---|---|---|
| TerminalBench 2.1 | ターミナルでの、複数の手順がある複雑な作業 | 67%低い | 4.9ポイント高い |
| DeepSWE | 大きなコードベースで、ファイルをまたぐ依存関係を理解して直す、リポジトリ単位の作業 | 36%低い | 1.5ポイント低い |
| CheckpointBench | 実際のGitHub Copilotの作業セッションから作った、GitHub社内の複数ターンのベンチマーク | 65%低い | 0.1ポイント低い |
読むときの注意も、研究ブログに書かれています。
- 管理された環境でのオフライン評価で、評価したベンチマークの版、ワークフローの設定、モデルの組み合わせ、料金の前提に固有の結果です
- すべてのモデルを、同じ中程度の推論の設定で評価しています
- GPT-5.6 Solも比較の基準に使ったと書かれていますが、表に載っているのはOpus 5との比較です
- TerminalBench 2.1は飽和に近づいているため、より広い検証が大事だとして、リポジトリ単位の作業が多いDeepSWEも加えています
- 研究プレビューを通じて、実際の開発の作業でこの結果がどう出るかを確かめる、としています
つまり、TerminalBench 2.1では品質が上がり、DeepSWEとCheckpointBenchでは品質がわずかに下がった一方、3つとも推定費用は大きく下がった、という結果です。自社の作業で費用がこの割合で下がるとは読まず、次の節の方法で実際の消費を記録して比べるのが安全です。比較の基準になったClaude Opus 5を、エージェントの設計でどの役割に置くかは、Claude Opus 5とモデルの振り分けの記事で扱っています。
費用と対象プラン|AIクレジットとプレミアムリクエストの扱い
HydraFusionを使うと、HydraFusionが使ったモデルごとに、そのモデルの標準の単価で課金されます。公式ドキュメントによると、HydraFusion自体の料金はなく、Autoで受けられる割引は付きません。1つのタスクで複数のモデルを使うことがあるため、同じ作業を1つのモデルでするより、多くのAIクレジットを使うことがあります。

| 項目 | 公式の記載(2026年10月1日時点) |
|---|---|
| HydraFusion自体の料金 | HydraFusionの別料金はなし |
| 使ったモデルの料金 | 使ったモデルごとに、そのモデルの標準の単価(入力・出力・キャッシュのトークン)で計算し、AIクレジットに換算する |
| Autoとの違い | Autoの割引は適用されない |
| AIクレジットの単位 | 1 AIクレジット=0.01ドル(1ドル150円換算で1.5円) |
| キャッシュ | 本体の会話はできるだけ同じモデルで続け、キャッシュの効いたトークンを活かす。レビュー役などの補助のモデルには、必要な文脈だけを渡す |
| モデルごとの単価 | GitHub Docsの「Models and pricing for GitHub Copilot」に、100万トークンあたりの単価の表がある |
公式ドキュメントの例のように、下書きのモデルとレビューのモデルの2つが動いた依頼では、それぞれのモデルが使ったトークンが、それぞれの単価で足し合わされます。どのモデルが使われるかは依頼ごとに変わり、事前に選べないため、1回の依頼の費用を前もって決めることはできません。
使った量を確かめる場所
- Copilot CLI:
/usageを入力すると、そのセッションでモデルごとに使ったAIクレジットが表示される - Copilot全体:GitHub Docsの「Monitoring your GitHub AI Credits usage」の手順で確かめる
- 詳しい記録:Copilot CLIで
/collect-debug-logsを入力すると、どの実行パターンで、どのモデルが各段階を動かしたかを含むデバッグログがまとめて保存される(不具合の報告などに使う)
対象プラン|変更履歴と研究ブログで書き方が違う
対象プランは、出典によって書き方が違います。2026年10月1日時点で確認できた範囲を表にまとめます。
| プラン | 9月30日の変更履歴 | 補足 |
|---|---|---|
| Copilot Pro | 対象 | 個人向けのプランは、プランごとに決まったAIクレジットの枠がある |
| Copilot Pro+ | 対象 | 同上 |
| Copilot Business | 対象(管理者がプレビュー機能を有効にする) | 利用者ごとのAIクレジットの枠を、契約の単位でまとめて使う |
| Copilot Enterprise | 対象(管理者がプレビュー機能を有効にする) | 同上 |
| Copilot Free | 記載なし | 9月4日の研究ブログは、Copilot CLIで「すべてのCopilotのプラン」と書いていた。9月30日の4つには入っておらず、使えるかは2026年10月1日時点で公式に確認できていない |
| Copilot Max | 記載なし | 料金ページに個人向けのプランとして載っている。HydraFusionの対象かは、2026年10月1日時点で公式に確認できていない |
プレミアムリクエストで数える旧方式の扱い
GitHubは2026年6月1日に、Copilotの課金を使用量にもとづく方式(AIクレジット)へ移しました。プレミアムリクエストの倍率で数える旧方式が残っているのは、年払いのCopilot Pro・Pro+を契約していて、6月1日以降も旧方式にとどまった人だけです。
旧方式の倍率表に、HydraFusionは載っていません。同じページには「旧方式の年払いプランの利用者は、新しいモデルと機能を利用できない」と書かれています。HydraFusionがプレミアムリクエストを何回消費するかは、2026年10月1日時点で公式に確認できていません。また、Autoの割引の率は、旧方式の倍率表のページでは10%(倍率1のモデルが0.9として数えられる)と書かれていますが、AIクレジットでの割引の率は2026年10月1日時点で公式に確認できていません。課金の移り変わりは、姉妹メディアのGitHub Copilotの課金変更の記事にまとめています。
Auto・HydraFusion・自分で選ぶの使い分け(当社の見方)
公式ドキュメントの使い分けは、日常の作業はAuto、複雑なバグの修正や複数のファイルにまたがる変更のような、範囲がはっきりした大きめの作業はHydraFusion、というものです。研究ブログは、いまの研究プレビューでは、Copilotにautopilotモードで1つの依頼として任せられる、1回目のコーディングの作業から始めるのがよいとし、長く続く複数ターンの作業での性能は次に力を入れると書いています。ここに、自分でモデルを選ぶ場合を加えて、当社の見方で整理します。

| 場面 | 選び方 | 理由 |
|---|---|---|
| 質問、小さな修正、決まった手順の作業 | Auto | 公式の使い分けで、日常の作業はAuto。依頼ごとに1つのモデルを選び、有料プランではモデルの費用に割引がある |
| 複雑なバグの修正、複数のファイルにまたがる変更 | HydraFusion | 公式の使い分けで、範囲がはっきりした大きめの作業はHydraFusion。追加のモデルの実行に、時間とAIクレジットを使う価値がある場面 |
| 1つの依頼で渡せる、最初の作業 | HydraFusion | 研究ブログが、いまの研究プレビューを始める場所としていちばんよいとする使い方 |
| 長いやり取りを続ける作業 | Autoか、自分でモデルを選ぶ(当社の見方) | 複数ターンの性能は次に強化するとされている。途中で切り替えると、会話を縮める(compact)よう求められることがある |
| 費用やモデルを固定したい作業 | 自分でモデルを選ぶ(当社の見方) | HydraFusionは使うモデルを選べず、1つのタスクで複数のモデルを使うことがある |
| 納期や品質の約束がある本番の作業 | Autoか、自分でモデルを選ぶ(当社の見方) | 研究プレビューの間はSLAがなく、本番のワークロード向けではないと公式は書いている |
自分でモデルを選ぶ場面
モデルごとの挙動を比べたい時や、チームで使うモデルをそろえたい時は、これまでどおりモデルの選択肢から自分で選びます。Copilotで選べるモデルの例として、Grok 4.7の使い方はGrok 4.7をAPI・Copilot・Cursorで使う記事に、手元のLLMをCopilotにつなぐ方法はGitHub Copilot×Ollama接続ガイドにまとめています。エディターでモデルを自動で選ぶ仕組みはほかの道具にもあり、Cursorの仕組みはCursor RouterとAuto Intelligenceの記事で扱っています。
自社のエージェントで同じ考え方を使う
研究ブログによると、開発者はすでに、作業に合うモデルを選び、別のモデルに見直させ、難しい問題は強いモデルに回す、という調整を手で行っています。HydraFusionはこの流れを実行時に自動で組み立てる仕組みで、研究ブログは、複数のモデルを1つの安定したコーディングの体験にまとめるための、5つの設計の原則を挙げています。
| 原則(研究ブログの表記) | 研究ブログの説明 |
|---|---|
| Complete accounting | 下書き・批評・修正・引き上げ・再試行・代わりの実行まで、すべての段階の費用と使用量を合算する |
| Bounded execution | 各段階に時間切れと取り消しの動きを決め、実行と費用を決めた範囲に収める |
| Isolated review | レビューの段階は道具を持たない切り離された環境で動かし、リポジトリを書き換えない |
| Fail-safe application | 取り消されたか、検証を通らなかったワークフローの変更は適用しない |
| Validated routing | 実行を始める前に、ワークフローの定義・モデルの割り当て・代わりの動き・モデルが使えるかを確かめる |
自社のエージェントで複数のモデルを使い分ける時も、この5つはそのまま点検の項目になります(当社の見方)。とくにCascadeの品質ゲートとCritiqueの批評役は、評価用のモデルに採点させる設計と近い考え方です。モデルの振り分けの設計はモデルルーティング設計ガイドとCisco9万人のAIエージェント導入に学ぶモデルルーティング設計、評価用のモデルの作り方はLLM-as-a-Judgeの設計ガイドで扱っています。
【要注意】よくある失敗パターン
研究プレビューの段階で起こりやすい読み違いと、設定の失敗を5つ挙げます。
失敗1:HydraFusionを1つのモデルとして比べる
❌ 「HydraFusionの性能」を、ほかのモデルと同じように1つのモデルの性能として比べる
⭕ 依頼ごとに、選ばれた実行パターンと使われたモデルを記録してから比べる(VS Codeは回答の下部、Copilot CLIは/collect-debug-logs)
なぜ重要か:実行パターンは依頼ごとに選ばれ、使うモデルの組み合わせも決まっていません。動いたモデルが違えば、同じ依頼の結果でも比べる意味が変わります。
失敗2:費用を1つのモデルと同じに見積もる
❌ いつも使っているモデルの単価で、HydraFusionの費用を見積もる
⭕ /usageで実際の消費を確かめ、小さな作業や決まった手順の作業はAutoに戻す
なぜ重要か:CascadeとCritiqueは複数のモデルを動かすため、時間もAIクレジットも多くかかることがあります。Autoの割引も付きません。
失敗3:捨てられた下書きの変更は残らないと思い込む
❌ HydraFusionの回答だけを見て、作業中のファイルをそのままコミットする
⭕ コミットの前に、ファイルの変更をすべて見直す
なぜ重要か:公式ドキュメントの制限事項に、下書きが捨てられても、その下書きがすでに加えたファイルの編集などは自動で元に戻らない、と書かれています。研究ブログの設計の原則には「取り消しや検証失敗の変更は適用しない」とありますが、ドキュメントは変更を見直してからコミットするよう求めています。
失敗4:ベンチマークの数字で予算を下げる
❌ 「推定費用67%減」を前提に、Copilotの予算を下げる
⭕ 自分たちの作業で、Auto・HydraFusion・自分で選んだモデルのAIクレジットを記録し、比べてから決める
なぜ重要か:数字は、最もよく調整した設定でのオフライン評価の結果です。DeepSWEとCheckpointBenchでは、品質がOpus 5よりわずかに低く出ています。
失敗5:長い会話の途中で切り替えて止まる
❌ 長く続けた会話の途中で、モデルをHydraFusionに切り替える
⭕ 切り替える前に会話を縮める(compact)。研究ブログが勧めるように、1つの依頼で渡せる作業から使い始める
なぜ重要か:HydraFusionで表示される文脈の長さは、使うモデルの中で最も小さい上限をもとにした控えめな値です。会話がそれより大きいと、切り替える前に縮めるよう求められます。
よくある質問
HydraFusionはモデルですか?
いいえ。モデルの選択肢から選びますが、HydraFusionは実行時に複数のモデルを動かす仕組みです。依頼ごとにSingle・Cascade・Critiqueのどれかの実行パターンを選び、そのパターンを動かすモデルも選んで、最後に1つの回答を返します。
HydraFusionの料金はいくらですか?
HydraFusion自体の料金はありません。使ったモデルごとに、そのモデルの標準の単価で計算され、AIクレジット(1クレジット=0.01ドル、約1.5円)で引かれます。Autoの割引は付かず、1つのタスクで複数のモデルを使うと、1つのモデルより多く使うことがあります。プレミアムリクエストで数える旧方式での扱いは、2026年10月1日時点で公式に確認できていません。
HydraFusionが使ったモデルは確かめられますか?
はい。VS Codeでは完了した回答の下部(フッター)に、GitHub Copilotアプリでは回答に、マウスを重ねると表示されます。Copilot CLIでは、/usageでモデルごとのAIクレジットを、/collect-debug-logsで実行パターンと各段階のモデルを含む詳しい記録を確かめられます。
モデルの選択肢にHydraFusionが出ないのはなぜですか?
公式ドキュメントが挙げる原因は、使っている場所ごとに次のとおりです。Copilot CLIは実験的な機能がオフ(/experimental onの後は起動し直す)、VS Codeはバージョンが1.140より古いか、設定chat.copilot.hydraFusion.enabledがオフ、CopilotアプリはSettingsのExperimentalでHydraFusionがオフ、組織や企業ではプレビュー機能が許可されていないか、使うモデルがモデルのポリシーで1つも許可されていない場合です。Copilot CLIとCopilotアプリでは、プレリリースのチャンネルに切り替える方法も案内されています。
Visual StudioやJetBrainsのIDEでも使えますか?
2026年10月1日時点で公式ドキュメントが挙げる提供先は、Copilot CLI、VS Code、GitHub Copilotアプリの3つです。それ以外のエディターで使えるかは、2026年10月1日時点で公式に確認できていません。
まとめ
HydraFusionは、GitHub Copilotのモデルの選択肢に並ぶ研究プレビューの機能で、依頼ごとにSingle・Cascade・Critiqueの実行パターンを選び、複数のモデルを動かして1つの回答を返します。2026年9月30日に、Copilot CLIに加えてVS CodeとGitHub Copilotアプリで使えるようになりました。HydraFusion自体の料金はなく、使ったモデルごとにAIクレジットが減り、Autoの割引は付きません。対象プランは9月30日の変更履歴ではPro・Pro+・Business・Enterpriseで、FreeとMaxは確認できていません。
試すときは、次の3つから始めると判断しやすくなります。範囲がはっきりした大きめの作業を1つ選んでHydraFusionに渡す、/usageや回答の表示で使われたモデルと消費を記録する、コミットの前に変更をすべて見直す。社内でCopilotのモデルの使い方や決まりを設計する段階で相談先が必要な場合は、UravationでもAIエージェントの導入を支援しています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る(無料)
参考・出典
- HydraFusion in VS Code and the GitHub Copilot app — GitHub Changelog(2026年9月30日・参照日: 2026-10-01)
- Using HydraFusion — GitHub Docs(参照日: 2026-10-01)
- Project HydraFusion: Frontier quality via multi-model orchestration — GitHub Blog(2026年9月4日・参照日: 2026-10-01)
- GitHub Copilot weekly releases — September 7 — GitHub Changelog(2026年9月10日・参照日: 2026-10-01)
- Models and pricing for GitHub Copilot — GitHub Docs(参照日: 2026-10-01)
- Model multipliers for annual plans on request-based billing (legacy) — GitHub Docs(参照日: 2026-10-01)
