モデル選択はオーケストレーション選択へと変わりつつある

GitHubは9月30日、HydraFusionをコマンドラインからエディターへと移した。このリサーチプレビューは現在、VS Code 1.140以降とGitHub Copilotアプリで動作し、ごく普通の開発者の前にかなり異例の考え方を持ち出す。モデルを選ぶのはやめて、ワークフローを選ぼう、というものだ。

HydraFusionはモデルではない。各ターンについて、そのタスクがいくつのモデルロールを必要とするかを決める層である。

1つのリクエストに3つの形

Singleはおなじみのケースだ。1つのモデルがリクエストを処理する。Copilot Autoがすでにそう動いているのと同じやり方である。

Cascadeは安く始まる。効率的なモデルが最初のドラフトを書き、品質ゲートがそれを受け入れるか、より強力なモデルへ作業をエスカレーションするかを決める。ねらいは、定型的な編集を安価なモデルに留め、高価なモデルを本当に必要な問題のために取っておくことだ。

Critiqueは安全性のために多くを費やす。あるモデルがドラフトを作り、別のモデルファミリーに属する2つ目のモデルが読み取り専用の批評家として振る舞い、ドラフトを作ったモデルがそのフィードバックに基づいて一度だけ改訂する。批評家はコードに一切触れない。それにより、このループが2つのモデルの口論になるのを防いでいる。

Autoとの違いはアーキテクチャにある。Autoは、どの単一モデルがあなたのプロンプトを受け取るべきかを決める。HydraFusionは、そのターンにいくつのロールが必要で、それらがどう相互作用するかを決める。これは、知能の制御がどこにあるかという点で意味のある転換だ。これまでは、自分の仕事の種類に優れているからモデルを選んだ。ここでは最適化ポリシーを選び、その下でモデルを構成するのはプラットフォームに任せる。

経済性は現実であり、同時に自己申告でもある

落とし穴は課金だ。GitHubは、選択された各モデルの標準料金でトークン単位で課金する。Critiqueの実行は少なくとも2つのモデルを呼び出すので、リクエストあたりのコストは単一呼び出しより高くなりうる。Cascadeは、簡単な作業を下位に押しやることでコストを下げるよう設計されている。その節約は、どのモデルの割引でもない。大半のターンは最高のものを必要としない、という賭けである。

GitHub自身の統制された評価では、3つのコーディングエージェントベンチマークにおいて、Claude Opus 5ベースラインに対してワークフローコストが36〜67パーセント削減されたと報告されている。品質はTerminalBench 2.1で4.9ポイント高く、DeepSWEで1.5ポイント低く、CheckpointBenchで0.1ポイント低かった。これらはGitHub自身のテスト環境でベンダーが作成した数値である。あなたのリポジトリに関する仮説であって保証ではなく、HydraFusionに参加するモデルプールも完全には公開されていない。プレビュー上に構築するものは、ルーティングの挙動を予告なく変わりうるものとして扱うべきだ。

純粋なレイテンシコストもある。ドラフトとレビューは1つの回答より時間がかかる。BusinessおよびEnterpriseプランのチームは、利用ダッシュボードを注意深く監視する必要がある。いつエスカレーションするかを決めるのはシステムであり、その判断は無料ではないからだ。

検査できない最適化は信頼しにくい

ルーティングの厄介な点は、意思決定を行っているのが開発者ではなくプラットフォームだということだ。どのモデルが答えたかは後から見られるが、なぜシステムがそのワークフローを選んだのか、品質ゲートが何を測定したのか、Cascadeの実行がどれだけエスカレーションに近づいたのかは、簡単には見えない。GitHubのベンチマークの主張は自社テストセット全体の平均を述べており、平均は重要なケースを隠してしまう。

このギャップは、オーケストレーションを純粋に技術的な問題ではなく、ガバナンスの問題に変える。特定のプルリクエストがなぜ2つのモデルファミリーによってレビューされ、それに応じて課金されたのかを説明しなければならないエンジニアリングチームは、ルーティングのテレメトリを必要とするが、プレビューはまだそれを公開していない。対処法はこの機能を避けることではない。内部が隠されたあらゆる依存関係をテストするのと同じようにテストすることだ。すなわち、固定された退屈なリポジトリタスク群で、単一のフロンティアモデルに対する完了タスクあたりのコストを測定し、1回の選択の表示価格ではなく、リトライとレビュー作業を注視するのである。

Autoとの比較は心に留めておく価値がある。Autoは、どのモデルがプロンプトに最も適しているかという問いに答える。HydraFusionは、そのターンがどれだけのプロセスに値するかという問いに答える。そしてプロセスは常にソフトウェア作業の中で高価な部分だった。

興味深い副作用は、モデル選択がより感情的でなくなることだ。開発者は特定のモデルに愛着を持つが、その愛着はたいてい、記憶に残るいくつかの成功体験の上に築かれている。タスクの種類でルーティングし、失敗時にエスカレーションするシステムは、どの単一モデルもあらゆるカテゴリーで勝つわけではないことを静かに認めている。それはしばらく前から事実であり、めったに行動に移されないことだ。

エディターの次のポケットはこのために作られている

Insidersビルドはすでに次の行き先を示している。Compare Agentsという「Run Multiple Agents」とラベルされた機能は、1つのプロンプトを複数のエージェントに並列で送り、それぞれを独自のgit worktreeで動かし、その後、審判エージェントが勝者を選ぶか、候補リストを人間に渡す。

興味深いのは、審判が何を見るかだ。変更されたファイルとdiff統計、テスト結果、ビルド状態、診断、タイミング、アーキテクチャ上の違いを比較する。テストスイートを実行する。別の言語モデルにコードを読ませて推測させることはしない。これは小さな判断だが大きな結果を伴う。比較が、モデルの意見ではなく、プロジェクトの実際の状態に基づくものになるからだ。

同じリリースの残りは、エージェントが並列で動いて初めて意味を持つ、より地味なインフラだ。マルチフォルダーセッションでは、1つのセッション内の各会話が独自のフォルダーやworktreeを使えるので、変更が衝突しなくなる。リモート委任は、接続されたリモートエージェントホストにタスクを渡す。共有worktreeフォルダーは、無視されたディレクトリを再利用して、ブランチごとに依存関係を再インストールするのを避ける。Dev Containersは5分間のアイドル後に停止し、要求に応じて再起動するようになった。

ガバナンスは機能と同じコミットで届き続ける

このリリースのIT向けの半分は後付けではない。AI機能が利用できないとき、エディターは一般的な更新を促す文言ではなく、最低要件バージョンを示すようになった。管理者はAutoモデルのデフォルト階層を設定できる。新しいOpenTelemetry設定は、Copilotの使用量を個々の開発者に紐づける。

この3つをまとめて読むと、形は明らかだ。複数のモデルを複数のターンにわたって調整するプラットフォームは、単一モデルのオートコンプリートが決して生まなかったコスト、テレメトリ、権限の問いを生む。コストの帰属は財務上の珍しい関心事ではなくなり、この機能を本番環境に近づけるための前提条件になる。

マルチモデルレビューは、慎重なエンジニアリングチームの間でしばらく前から標準的な慣行だ。あるモデルに書かせ、別のモデルに誤りを探させる。あるいはまず高速なモデルを試し、出力に満足できなければエスカレーションする。HydraFusionはその習慣を取り、自動化する。それは便利であり、同時に、手作業で決めることを好むチームもあった判断を奪う。

プレビュー機能がどれだけの間プレビューであり続けるべきかは、もっともな疑問だ。ツールはそれを取り巻くポリシーより速く世に出ており、価格の予測可能性が最初の犠牲者になる。大規模リポジトリで2つのフロンティアモデルを静かに呼び出すCritiqueの実行は、誰も気づかないうちに本当の金を使い込む可能性がある。HydraFusionがデフォルトへ昇格するかどうかは、ルーティングが機能するかどうかよりも、GitHubが請求額を誰かが承認できるほど読みやすくできるかどうかにかかっている。