AIコーディングは「最適なモデル選び」から「最適な実行計画」へ――GitHub HydraFusionの設計思想

モデルを1つ選ぶ時代から、解き方を自動構成する時代へ

AIコーディングエージェントを使う際、多くの開発者はタスクの難易度に応じてモデルを使い分けています。軽微な修正なら高速で安価なモデル、複雑な設計やデバッグなら高性能モデル、さらに別のモデルにレビューを依頼する、といった運用です。

GitHubが発表した Project HydraFusion は、この判断を実行時に自動化する研究プレビューです。開発者が選択するのはHydraFusionという1つのモデルですが、内部では複数のモデルや実行パターンを組み合わせ、タスクごとに品質・コスト・レイテンシのバランスを取ります。

これは単なる「最適なLLMを選ぶ機能」ではありません。タスクをどのモデルに渡すかだけでなく、どの順番で、どの役割を与え、何を条件に再試行・エスカレーションするかまでを実行計画として構成する点が重要です。

HydraFusionが選択する3つのワークフロー

HydraFusionは、推論、コード生成、デバッグ、ツール利用などの能力シグナルをもとに、現在は次の3パターンから実行方式を選びます。

1. Single：単一モデルで直接解く

1つのモデルがリクエストを最初から最後まで処理します。

単純なコード修正や短い質問など、追加のレビューや再実行が品質向上につながりにくいタスクでは、この方式が適しています。モデル呼び出しが少ないため、3方式の中ではコストとレイテンシを抑えやすいのが特徴です。

2. Cascade：効率的なモデルから始め、必要なら昇格する

まず効率のよいモデルに解答を作らせ、その結果が品質ゲートを通過するか判定します。基準を満たさなければ、より強力なモデルへ処理を引き継ぎます。

この方式は、すべてのタスクを高価なモデルで処理するのではなく、難しいタスクだけを高性能モデルへエスカレーションする設計です。

実務では、次のようなタスクと相性がよいと考えられます。

• 一見単純だが、リポジトリ全体の依存関係が影響する修正
• テスト失敗の原因が明確かどうか判断しにくいデバッグ
• まず候補解を作り、妥当性を判定してから本格的な修正に進みたい作業

3. Critique：独立した批評と1回の改訂を行う

1つのモデルがドラフトを作成し、別のモデルファミリーに属する読み取り専用の批評モデルがレビューします。その後、ドラフトを作ったモデルがレビュー結果を反映して1回だけ改訂します。

重要なのは、批評ステップがリポジトリを変更しない隔離されたコンテキストで実行される点です。レビュー担当モデルが作業ツリーを直接書き換えるのではなく、独立した視点で問題を指摘します。

これは、人間のコードレビューに近い構造です。別モデルの視点を入れることで、見落としや仕様との不一致を検出しやすくします。一方で、追加のモデル呼び出しが発生するため、すべてのタスクに適用すればよいわけではありません。

ベンチマークが示す品質とコストの交換条件

GitHubは、TerminalBench 2.1、DeepSWE、社内のCheckpointBenchという3つのエージェント型コーディングベンチマークでHydraFusionを評価しました。比較対象はClaude Opus 5とGPT-5.6 Solで、同じタスク、ツール、実行制限、価格前提、評価条件を使っています。

Opus 5を基準にした結果は次のとおりです。

TerminalBench 2.1では、品質を高めながらコストも大きく削減しました。DeepSWEでは品質が1.5ポイント下がったものの、コストは36%削減されています。CheckpointBenchでは品質差をほぼゼロに抑えつつ、コストを65%削減しました。

この結果から読み取れるのは、「常に最高性能のモデルを使うより、タスクに応じてモデルとワークフローを組み合わせたほうが、品質を大きく損なわずにコストを抑えられる可能性がある」ということです。

ただし、平均値だけで導入判断をするのは危険です。リポジトリ横断の変更、長い対話、複雑な仕様理解など、タスクの種類によって最適な方式は変わります。ベンチマークごとに結果が異なること自体が、ルーティングの難しさを示しています。

開発者にとっての実務上の意味

モデル選択の知識を減らせる

従来は、開発者がタスクごとにモデルの特性を把握し、手動で切り替える必要がありました。HydraFusionでは、開発者はまずタスクを依頼し、内部のルーターが実行方式を選びます。

これは特に、複数のモデルを導入したものの、どのタスクをどのモデルに割り当てるか決めきれないチームに有効です。モデル選択の専門知識を、個々の開発者ではなく実行基盤側へ移せます。

コスト管理を「モデル単価」から「ワークフロー単位」へ変えられる

複数モデルの利用では、最初のドラフトだけを見て費用を見積もることはできません。批評、改訂、エスカレーション、再試行、フォールバックまで含めた総コストが実際の課金対象になります。

HydraFusionは、ワークフローのすべての段階で利用したトークンを集計し、各モデルの標準料金で課金する設計です。したがって、開発チームが見るべき指標も、単純な「1回のモデル呼び出し単価」から次のように変わります。

• タスク1件あたりの総トークン数
• Single、Cascade、Critiqueの選択比率
• エスカレーションが発生した割合
• 再試行やフォールバックによる追加コスト
• タスク完了までの総レイテンシ
• 品質ゲートを通過できなかった割合

レビューをワークフローの一部として扱える

人間によるレビューは重要ですが、すべての変更を同じ深さで確認するのは困難です。Critiqueのような方式を組み込むと、レビューを単なる開発者の習慣ではなく、実行計画の一部として扱えます。

ただし、AIによる批評は人間の承認を置き換えるものではありません。特に認証、権限、データ移行、決済、インフラ設定など、障害時の影響が大きい変更では、レビュー結果だけでマージ判断を完結させるべきではありません。

リポジトリ操作で重要になる安全設計

複数モデルを連携させる場合、品質だけでなく、途中状態や失敗時の扱いが重要になります。HydraFusionは、リポジトリレベルの作業を想定して、次の運用原則を掲げています。

• ドラフト、批評、改訂、エスカレーション、再試行、フォールバックを含めて利用量とコストを集計する
• 各処理段階にタイムアウトとキャンセル動作を設定する
• レビュー処理をツールなしの隔離コンテキストで実行する
• キャンセルや検証失敗時にはパッチを適用しない
• 実行前にワークフロー定義、モデルの割り当て、フォールバック、利用可能性を検証する

この中で特に重要なのが、失敗したワークフローの中間成果物を、そのままリポジトリへ反映しないことです。

AIエージェントが複数段階で変更を生成すると、途中まで成功したように見える状態が発生します。しかし、レビューや改訂で破棄される可能性があるドラフトを、開発者が完成品と誤認すると、意図しない変更が混入します。HydraFusionは中間ドラフトを保持し、最終的に一貫した結果と変更セットだけを返す方針を取っています。

可観測性がなければ、最適化はできない

マルチモデル orchestration の運用で見落としやすいのが、実行経路の可視化です。最終的に開発者へ1つの回答だけが返ると、内部でどのモデルが何回呼ばれたのか分からなくなる可能性があります。

HydraFusionは内部的に、各実行ステップについて次の情報を記録します。

• 実行時の役割
• 成功、失敗、キャンセルなどの結果
• 各ステップのコスト
• レイテンシ
• 診断情報

このような情報は、単なる監視データではありません。ルーティングポリシーを改善するための学習データになります。

たとえば、次のような分析が可能になります。

• Cascadeでエスカレーションされたタスクは、本当に品質が向上したか
• Critiqueを追加しても結果が変わらないタスクは何か
• 特定の言語やタスク種別で失敗率が高くないか
• コスト削減と引き換えに、どの種類の品質低下が発生しているか
• レイテンシの増加が開発者体験に与える影響はどの程度か

今後、自社で同様の基盤を構築する場合も、モデル精度の比較だけでなく、ワークフロー単位のトレースを最初から設計することが重要です。

ベンダー提供ベンチマークを読むときの注意点

今回の評価結果は有用な判断材料ですが、そのまま自社の開発生産性に置き換えられるわけではありません。

主な理由は次のとおりです。

• 評価対象のベンチマークやバージョンが限定されている
• ワークフロー構成やモデルプールが固定されている
• 価格前提が実際の契約条件と異なる可能性がある
• すべてのモデルが同じ推論レベルで評価されている
• 自社リポジトリの言語、規模、テスト品質、開発プロセスが異なる
• オフライン評価では、開発者が待ち時間や回答をどう受け止めるかを測れない

特に、品質とコストの数値が両立している場合でも、レイテンシが増えていれば、対話型の開発では使いにくくなることがあります。逆に、単発タスクや自動化された処理では、多少の待ち時間より総コスト削減が重要になる場合もあります。

導入時には、次のような自社指標で評価すると実務に近い判断ができます。

• テストが通過した変更の割合
• 人間が修正せずに採用できたパッチの割合
• 1タスクあたりの総コスト
• 初回回答までの時間と最終完了までの時間
• 不要なファイル変更の割合
• ロールバックや手戻りの発生率
• 開発者が手動でモデルを切り替えた回数

Copilot CLIでの試し方

HydraFusionは研究プレビューとして、GitHub Copilot CLIの/experimentalから利用できます。案内されている操作手順は次のとおりです。

1. /updateを実行してCopilot CLIを最新版に更新する
2. /experimentalを有効にする
3. /modelを実行する
4. HydraFusion (Research Preview)を選択する

利用できるのはGitHub Copilotの全プランですが、料金はHydraFusion自体の固定料金ではなく、内部で利用された各モデルの標準レートに基づきます。複数ステップが実行されるタスクでは、単一モデルを直接使う場合より呼び出し数が増える可能性があるため、コストと完了時間を観察しながら使うのが現実的です。

GitHubは、現時点では初回の単発プロンプトによる、まとまりのあるコーディングタスクから試すことを推奨しています。長時間にわたる多ターンのセッションについては、今後の検証対象とされています。

まとめ：競争の軸はモデル性能から実行設計へ

HydraFusionが示しているのは、AIコーディングエージェントの競争軸が変わりつつあることです。

これまでは「最も賢いモデルを選ぶ」ことが中心でした。今後は、タスクの難易度や性質に合わせて、次の要素を動的に組み合わせることが重要になります。

• どのモデルを使うか
• 何回モデルを呼び出すか
• 先にドラフトを作るか
• 独立した批評を挟むか
• どの条件で高性能モデルへ昇格するか
• 失敗時に変更を適用するか破棄するか
• コストとレイテンシをどの単位で管理するか

HydraFusionはまだ研究プレビューであり、モデル、ワークフロー、提供形態、性能は今後変わる可能性があります。それでも、単一モデル中心の設計から、複数モデルを組み合わせた実行計画中心の設計へ移行する方向性は、AIコーディング基盤を考えるうえで重要な示唆を持ちます。

開発者にとっては、モデルの細かな選択から解放される可能性があります。一方、開発リーダーやAI基盤担当者にとっては、品質・コスト・レイテンシ・安全性をワークフロー単位で測定し、制御する新しい運用課題が生まれます。次の大きな改善は、単に強いモデルを作ることではなく、タスクごとに最も適した解き方を自動で構成することから生まれるのかもしれません。

出典： GitHub Blog