GitHub Project HydraFusionとは？複数モデル自動オーケストレーションの実力・料金・Copilot CLIでの使い方【2026年9月最新】

Project HydraFusion（ハイドラフュージョン）は、GitHubが2026年9月4日に公開した、1回のリクエストごとに「どのモデルをどう組み合わせて解かせるか」をGitHub側が自動で設計するGitHub Copilotの研究プレビュー機能です。ユーザーは「HydraFusion」というモデルを1つ選ぶだけで、裏側では複数ベンダーのモデルが下書き・品質判定・批評・修正を分担します。

GitHubの公表値では、TerminalBench 2.1でClaude Opus 5単体より推定コスト67%減かつ品質+4.9ポイントという結果が出ていますが、これは3つのベンチマークのうち最も良い1つの数字です。他の2つは「コストは下がるが品質はわずかに下」という結果で、「常にOpus 5を超える」わけではありません。

この記事でわかること

• HydraFusionが従来のモデル選択と何が違うのか（3つの実行パターンの中身）
• 公開されたベンチマーク3種の全数値と、「67%減」の正しい読み方
• GitHub AI Credits体系のなかでどう課金されるのか
• Copilot CLIでのインストールから有効化までの具体的な手順
• planモード非対応・モデル指定不可など、使う前に知っておきたい制約
• 複数プロバイダにコードが渡る点をどう評価すべきか（企業導入の判断材料）

想定読者: GitHub Copilot CLIを業務で使っているエンジニア、AIコーディングのコスト最適化を検討しているテックリード、社内でCopilotの利用範囲を決める立場の情報システム／セキュリティ担当者。

※本記事は2026年9月7日時点の公式情報に基づいています。HydraFusionは研究プレビューであり、GitHubは「結果・モデル・ワークフロー・提供範囲・名称・挙動は変更されうる」と明記しています。

Project HydraFusionとは — 基本情報

出典: GitHub Copilot 公式サイト

HydraFusionは、GitHub Copilotに追加された実行時マルチモデル・オーケストレーションの仕組みです。公式は「runtime orchestration（実行時オーケストレーション）によってフロンティア級の知能を提供する」と表現しています。

GitHub Copilotそのものの全体像は「GitHub Copilotとは」で整理しています。HydraFusionはCopilotを置き換える新製品ではなく、既存のCopilot CLI上で選べるモデル選択肢が1つ増えた、という位置づけです。

「Copilot CLI限定」であることの意味

現時点で使えるのはターミナル上で動くGitHub Copilot CLIのみです。VS Code拡張やデスクトップアプリのモデル一覧には出てきません。デスクトップ側の環境については「GitHub Copilot Appとは」を参照してください。

何が変わったのか — モデルを「選ぶ」から「組み立てる」へ

HydraFusionの本質は、model selection（モデル選択）からmodel orchestration（モデルの実行設計）への転換です。従来のCopilotでは、ユーザーがGPT系・Claude系・Gemini系などから1つを選び、そのモデルがタスクを最初から最後まで担当していました。

HydraFusionでは、GitHub側が受け取ったタスクを解析し、そのタスク専用の実行計画（execution plan）をその場で組み立てます。計画には「どのモデルに下書きさせるか」「品質をどう判定するか」「不十分ならどこへエスカレーションするか」が含まれます。

ルーティングの方針として、GitHubは「要求品質を満たすと見込まれるワークフローのうち、最も複雑度が低いものを選ぶ」としています。追加のモデル呼び出しは、結果が改善する見込みがあるときにだけ行われる設計です。

つまりHydraFusionは「常に一番強いモデルを叩く」仕組みではなく、「必要なときだけ強いモデルに回す」仕組みです。この設計が、GitHubが公表するコスト削減率の根拠になっています。

3つの実行パターン（Single / Cascade / Critique）

出典: The GitHub Blog

2026年9月7日時点で公開されている実行パターンは3種類です。どれが選ばれるかはタスクごとに自動判定されます。

Cascadeの肝は「品質ゲート」

Cascadeでは、下書きが合格基準を満たせばそこで終了します。GitHubの狙いは、全リクエストを最上位モデルに流すのをやめることにあります。単純なタスクにOpus級のモデルを使うのは過剰であり、その差額がコスト削減の主たる源泉です。

Critiqueは「異なるモデルファミリー」であることが重要

Critiqueパターンでは、下書きを書いたモデルとは訓練由来のバイアスが異なるモデルがレビュアーになります。同じファミリーのモデルは同じ盲点を持ちやすいため、別系統のモデルに見せることで構造的な見落としを検出しやすくする、という設計思想です。

レビュアーはツールを持たない読み取り専用で動作し、リポジトリを変更できません。修正はあくまで下書きモデルが行い、しかも1回だけです。無限に往復して時間とコストを溶かす構造にはなっていません。

ベンチマークで見る実力 —「Opus 5超え」はどこまで本当か

HydraFusionがClaude Opus 5を品質面で上回ったのは、公開された3つのベンチマークのうち1つだけです。コスト削減は3つとも一貫して確認されていますが、削減率には36〜67%の幅があります。

見出しで踊りやすい「67%減・Opus 5超え」は、TerminalBench 2.1という1つのベンチマークの数字です。GitHub自身も公式には「36〜67%削減」というレンジで表現しています。

数字を読むときの4つの注意点

• 品質でOpus 5を明確に超えたのはTerminalBench 2.1のみ。残り2つは「ほぼ同等〜わずかに下」で、コストと品質のトレードオフが出ている
• コストは「estimated cost（推定コスト）」であり、実際の請求額そのものではない
• GitHub自身によるオフライン評価であり、2026年9月7日時点で第三者による独立検証は公開されていない
• ベンチマークは特定タスク群の集計値であり、自社のコードベースでの再現は保証されない

比較対象となったモデルの詳細は「Claude Opus 5とは｜料金・性能・Opus 4.8からの進化」で解説しています。Opus 5は現行で最上位クラスのコーディングモデルであり、「そこにコスト1/3で並ぶ・部分的に勝つ」という主張自体は十分に注目に値します。ただし、「常にOpus 5より優秀で常に3分の1のコスト」という理解は誤りです。

料金はどうなるのか — GitHub AI Creditsとの関係

出典: GitHub Copilot 料金プラン 公式ページ

HydraFusion自体に追加料金や専用プランはありません。 公式の表記は「Usage is based on the tokens consumed by the models HydraFusion uses, priced at each model's standard rate.」＝HydraFusionが内部で使った各モデルのトークン消費量に、それぞれのモデルの標準レートを掛けた金額が課金される、という仕組みです。

GitHub Copilotは2026年6月1日に、従来の「プレミアムリクエスト」方式からGitHub AI Credits（1クレジット＝$0.01）を使う従量課金へ移行しています。HydraFusionの消費もこのクレジット枠から差し引かれる形になります。課金体系そのものの詳細は「GitHub Copilot 使用量ベース課金とは｜GitHub AI Creditsと料金変更ガイド」で整理しています。

現行プランと月間クレジット（2026年9月時点・公式ドキュメント）

※コード補完やNext Edit Suggestionsはクレジット非課金です。チャット・エージェント・コードレビューなどがクレジット消費の対象になります。

「安くなる」を二層に分けて理解する

ここが最も誤解されやすい部分です。HydraFusionのコスト構造は、次の2つを分けて考える必要があります。

GitHubが示す「36〜67%削減」は後者、つまりタスクを完了させるまでの総コストの話です。「HydraFusionを選べば毎回のリクエストが必ず安くなる」という意味ではありません。

なお、HydraFusion使用時のAI Credits換算レートや具体的な消費例は、2026年9月7日時点で公式に公開されていません。GitHubの記載は「各モデルの標準レート」までです。導入前に少額で試し、実際のクレジット消費を自分の環境で計測することを推奨します。

コスト管理上の実務的な注意

• クレジット枠を使い切ると追加課金または機能制限になる。チームで一斉に切り替えるのではなく、まず数人で消費傾向を見るのが安全
• どのモデルが何回動いたかの内訳はセッション単位では表示されない。モデル別のコスト按分は現時点では追えない
• 複数のAIコーディングツールを併用している場合は、料金比較の全体像を「生成AI料金比較」で確認しておくと判断しやすくなります

Copilot CLIでのHydraFusionの使い方

出典: github/copilot-cli 公式リポジトリ

HydraFusionを使うには、GitHub Copilot CLIが導入済みで、かつCopilotのライセンスが有効になっている必要があります。手順は「CLIの導入」→「HydraFusionの有効化」の2段階です。

手順1: GitHub Copilot CLIをインストールする

環境に応じていずれか1つを実行します。

# npm（Node.js 22以降が必要）
npm install -g @github/copilot

# Homebrew（macOS / Linux）
brew install --cask copilot-cli

# WinGet（Windows。PowerShell v6以降が必要）
winget install GitHub.Copilot

# インストールスクリプト（macOS / Linux）
curl -fsSL https://gh.io/copilot-install | bash

インストール後、ターミナルで copilot と入力すると起動します。未認証の場合はセッション内で /login を実行してGitHubアカウントを認証します。

CI環境などでパーソナルアクセストークンを使う場合は、「Copilot Requests」権限を付与したfine-grained PATを COPILOT_GITHUB_TOKEN、GH_TOKEN、GITHUB_TOKEN のいずれかに設定します。

なお、旧来の gh copilot 拡張は非推奨です。混在していると紛らわしいので gh extension remove gh-copilot で外しておくとよいでしょう。

手順2: HydraFusionを有効化する

copilot を起動したセッション内で、次の3つのスラッシュコマンドを順に実行します。

/update            # CLIを最新版に更新する
/experimental on   # 実験的機能を有効にする
/model             # モデル一覧から HydraFusion (Research Preview) を選択

/model を実行するとモデル一覧が表示されるので、そこから「HydraFusion (Research Preview)」を選びます。一度選択すると、以降のセッションにも設定が引き継がれます。

つまずきやすいポイント

• --model hydrafusion のような起動フラグでの指定は効かないという報告があります。 セッション内の対話式 /model メニューから選んでください
• /experimental on を実行していないと、モデル一覧にHydraFusionが出てきません
• /update を飛ばすと古いCLIのままで選択肢が現れないことがあります
• planモードに入るとHydraFusionは使われず、直前に選んでいたモデルに戻ります

GitHubが推奨する使い方

公式が想定しているのは「substantial, well-scoped first-turn coding tasks」＝ある程度の規模があり、範囲が明確に切られた、1ターン目の単発プロンプトです。

具体的には次のようなタスクが向いています。

• 「この仕様に沿ってモジュールを1つ実装して」といった、要件が文章で完結する実装依頼
• 失敗しているテストの原因特定と修正
• 既存関数のリファクタリングを1回で仕上げる依頼

逆に、何十ターンも往復しながら仕様を固めていく対話型の使い方は、現時点では最適化の途上とされています。

現時点の制約とハマりどころ

出典: The GitHub Blog Changelog

研究プレビューである以上、割り切って使う必要がある制約が複数あります。導入判断の前に把握しておくべき項目を整理します。

早期利用者から報告されている挙動

GitHub communityのDiscussionでは、次のような報告が上がっています（2026年9月7日時点）。

• タスク完了後もステータスが「Working」のまま残ることがある
• 実装フェーズでどのモデルが動いたのか可視性が低い
• セッション単位のモデル使用内訳が表示されない
• リサーチ主体のタスクで進捗表示が乏しく、止まっているのか動いているのか判断しづらい

GitHub自身も「Waiting without enough visibility is a real trade-off for developers（十分な可視性のないまま待たされることは、開発者にとって現実的なトレードオフだ）」と認めており、長い複合ワークフローの進捗可視化改善をロードマップに挙げています。

セキュリティと企業導入で確認すべきこと

HydraFusionを企業で使うかどうかの判断で、最も重要な論点は「使用モデルを指定できない＝1つのコーディングタスクの内容が複数ベンダーのモデルに渡りうる」という点です。

公式が示す5つの運用ガードレール

GitHubは信頼性確保のための原則を5つ挙げています。技術的には妥当な設計です。

特に「Isolated review」は、レビュアーが評価対象そのものを書き換えてしまうリスクを構造的に排除しており、マルチモデル構成としては手堅い作りです。「Fail-safe application」も、検証を通らない変更が勝手に反映される事故を防ぎます。

それでも残る論点

• データ送信先を選べない。 HydraFusionは「models across multiple providers」を使うと公式に明記されています。どのプロバイダに渡るかをユーザーが制御できない以上、特定ベンダーへのコード送信を制限しているポリシーとは原理的に相性が悪い
• HydraFusion固有のデータ処理ポリシーは、2026年9月7日時点で公式に確認できません。 Copilot CLI全体のポリシーが適用されると考えるのが自然ですが、明文化された専用ドキュメントはまだ出ていません
• Copilot Business / Enterpriseのコンテンツ除外（content exclusion）は、enterprise / organization / repositoryの各レベルでCopilot CLI全体として尊重されます。除外設定はまず先に整備しておくべきです
• Copilot CLIには一般的な制約として、MCPサーバー利用の組織レベル制御が未対応である点、権限スコープがヒューリスティックでtrusted directory外の保護は保証されない旨がドキュメントに記載されています

判断の目安

学習データへの利用可否を制御したい場合は「GitHub Copilot 学習オプトアウト設定」を、AIコーディング全般のリスク整理は「AIコーディングのセキュリティリスク」を確認してください。

Rubber Duckからの系譜と、他のマルチモデル基盤との違い

HydraFusionは突然出てきた仕組みではありません。CritiqueパターンのルーツをたどるとGitHubが2026年4月にCopilot CLIへ導入したRubber Duck（ラバーダック）エージェントに行き着きます。

Rubber Duckは、主モデルとは別のモデルファミリーに「第三者レビュー」をさせる機能です。異なる訓練データで作られたモデルは異なるバイアスを持つため、主モデルが構造的に見落とす誤りを検出できる、という設計根拠に基づいています。GitHubの報告では、Claude Sonnet + Rubber Duckの組み合わせが、SonnetとOpusの性能差の74.7%を埋めたとされています。

公式ドキュメントによれば、Rubber Duckのレビュアーは読み取り専用で、バグ・ロジック誤り・セキュリティ欠陥・設計問題といった実質的な問題に集中し、スタイルや些末なリファクタリングは対象外です。この「異ファミリー×読み取り専用×実質的な問題に限定」という設計がHydraFusionのCritiqueにそのまま継承されています。

他のマルチモデル・オーケストレーションとの違い

「複数のモデルを束ねる」というアプローチ自体は他にも存在します。違いは誰がルーティングを決めるかとどこで動くかです。

HydraFusionの特徴は、ルーティングの設計をユーザーからGitHub側へ完全に引き取った点にあります。自分でルーターを書きたい人には物足りず、「良い感じに安く速く解いてほしい」人には最も手間が少ない、という性格の分かれ方をします。OpenRouterの周辺動向は「StripeによるOpenRouter買収」でも触れています。

他のCLIコーディングエージェントとの位置関係

Copilot CLI以外にも、Claude Code、Gemini CLI、xAI Grok Buildといったターミナル型のエージェントが並立しています。HydraFusionは「Copilot CLIを選んだ場合の、モデル選択の新しい選択肢」であり、CLIエージェント自体を乗り換える話ではありません。ツール全体の比較検討をしている段階なら「AIコーディングツールおすすめ比較」から入るほうが整理しやすいはずです。

こんな人におすすめ

HydraFusionは万人向けの機能ではなく、条件がはっきり分かれます。

おすすめできるケース

• すでにGitHub Copilot CLIを日常的に使っているエンジニア。追加の導入コストがほぼゼロで、コマンド3つで試せる
• AIコーディングのクレジット消費を減らしたいチーム。単純タスクにまで最上位モデルを使っている自覚があるなら、削減余地は大きい
• 範囲の明確な単発タスクを大量に投げる使い方をしている人。GitHubの推奨用途と一致する
• モデル選びに時間をかけたくない人。「どれを選べば速くて安いか」を毎回考える手間がなくなる
• 新技術を早めに検証して社内に共有する役割の人。研究プレビュー段階での挙動を把握しておく価値がある

おすすめしないケース

• 使用モデルを指定・限定する必要がある組織。金融・医療・公共など、契約や規制でモデル提供元が縛られている場合は現時点で採用対象外
• VS Codeやデスクトップアプリ中心で作業している人。CLIを使っていないなら、対応サーフェスが広がるのを待つほうが合理的
• planモードを軸にしたワークフローを組んでいる人。planモードでは動作しないため、恩恵が限定的
• どのモデルが何を出力したかを追跡・監査する必要があるチーム。中間経過とモデル内訳が見えない
• 長い対話を重ねて仕様を詰める使い方が中心の人。マルチターンは最適化の途上
• 本番の自動化パイプラインに組み込みたい人。仕様変更の可能性が明示されているため、安定性を前提にできない

よくある質問

Q. HydraFusionを使うと追加料金はかかりますか？

A. HydraFusion専用の料金プランや追加料金はありません。課金は、HydraFusionが内部で使った各モデルのトークン消費量に、それぞれのモデルの標準レートを掛けた金額です。GitHub AI Creditsの枠から消費されます。ただしHydraFusion使用時の具体的なクレジット換算表は、2026年9月7日時点で公式には公開されていません。

Q. 無料プラン（Copilot Free）でも使えますか？

A. GitHub Blogは「すべてのGitHub Copilotプラン」向けと案内していますが、公式ドキュメントのプラン表ではFree / Studentは「モデルは自動選択のみ」と記載されています。Freeでモデル一覧からHydraFusionを明示的に選択できるかは、2026年9月7日時点で公式に確定できていません。実際に /model を実行して選択肢に出るかを確認するのが確実です。

Q. どのモデルが使われているか確認できますか？

A. できません。使用モデルの指定・除外もできず、セッション単位の使用内訳も表示されません。GitHubは内部で使うモデルのラインナップ自体も公開しておらず、新モデルの投入に応じて変動するとしています。

Q. VS Codeでは使えますか？

A. 2026年9月7日時点ではGitHub Copilot CLIのみです。VS CodeとGitHub Copilot Appへの展開は「2026年9月中のfast follow」として予告されていますが、公開日は確定していません。

Q. 本当にClaude Opus 5より優秀なのですか？

A. 公開された3つのベンチマークのうち、品質でOpus 5を上回ったのはTerminalBench 2.1（+4.9ポイント）だけです。DeepSWEでは−1.5ポイント、CheckpointBenchでは−0.1ポイントと、ほぼ同等かわずかに下回っています。コストは3つとも36〜67%削減されており、「同等前後の品質を大幅に安く出せる」という理解が実態に近いです。加えて、これはGitHub自身によるオフライン評価であり、第三者の独立検証はまだ公開されていません。

Q. 「Working」のまま止まっているように見えるのですが、故障ですか？

A. 早期利用者から同様の報告が複数上がっています。HydraFusionは中間経過を表示しないため、内部でモデル間の受け渡しが進んでいても画面上は変化しません。タスク完了後もステータスが残ることがある点はGitHubも可視性の課題として認識しており、改善がロードマップに挙がっています。

Q. 業務のコードで使っても安全ですか？

A. 批評役が読み取り専用で動く「Isolated review」や、検証に失敗したパッチを適用しない「Fail-safe application」など、公式のガードレールは設計として妥当です。一方で、複数プロバイダのモデルにコードが渡りうる点はユーザー側で制御できません。機密度の高いコードではcontent exclusionを設定したうえで範囲を限定し、規制業種では研究プレビュー段階での採用は避けるのが無難です。

Q. すでにRubber Duckを使っています。HydraFusionに切り替えるべきですか？

A. Rubber Duckは「主モデルを自分で選び、そこに第三者レビューを足す」仕組み、HydraFusionは「モデル選択とレビューの要否そのものをGitHubに任せる」仕組みです。主モデルを自分でコントロールしたいならRubber Duck、判断ごと預けてコストを最適化したいならHydraFusion、という使い分けになります。

まとめ

Project HydraFusionは、GitHub Copilotのモデル選択を「ユーザーが1つ選ぶ」から「GitHubがタスクごとに実行計画を組む」へ変える研究プレビュー機能です。2026年9月7日時点の要点を整理します。

• 提供状況: 2026年9月4日公開。現時点でGitHub Copilot CLIのみ。VS Code / Copilot Appへは9月中のfast followを予告
• 仕組み: Single / Cascade / Critiqueの3パターンから、要求品質を満たす最も複雑度の低いワークフローを自動選択
• 性能: Claude Opus 5比でコスト36〜67%削減。品質で明確に上回ったのはTerminalBench 2.1のみで、他2ベンチはほぼ同等〜わずかに下。GitHub自身のオフライン評価であり第三者検証は未公開
• 料金: 追加料金なし。各モデルの標準レートでGitHub AI Creditsを消費。1リクエストあたりの消費は増えうるが、タスク完了までの総コストは下がりうる
• 制約: モデル指定不可・中間経過が見えない・planモード非対応・マルチターンは最適化途上・仕様変更の可能性あり
• 企業導入: 公式ガードレールは妥当だが、複数プロバイダにコードが渡る点は制御できない。規制業種は現段階での採用を見送るのが無難

今すぐ試す価値があるのは、Copilot CLIを日常的に使っていて、範囲の明確な単発タスクを多く投げているエンジニアです。コマンド3つで切り替えられ、合わなければ元のモデルに戻すだけなので、検証コストはほとんどかかりません。

一方で、監査要件や規制がある環境では、正式提供とデータ処理ポリシーの明文化を待つのが妥当な判断です。研究プレビューである以上、今後の仕様変更を前提に付き合う必要があります。

AIコーディング環境全体の選定を進めている場合は「Claude Code vs GitHub Copilot 徹底比較」や「生成AIツールおすすめ比較」も参考にしてください。エージェント型AIの基礎概念から押さえたい場合は「AIエージェントとは」から読み進めるのが分かりやすいはずです。

参照した主な公式情報

• Project HydraFusion: Frontier quality via multi-model orchestration — The GitHub Blog（2026年9月4日）
• [Research Preview] HydraFusion is live in GitHub Copilot CLI — GitHub community Discussion
• GitHub Docs: Install Copilot CLI
• GitHub Docs: About the rubber duck agent
• GitHub Docs: Copilot plans
• GitHub Blog: GitHub Copilot is moving to usage-based billing