GitHub CopilotのAutoモードが、依頼の複雑さやモデルの稼働状況を見て、GPTやClaudeなどの中からモデルを選んでいることは知られています。
ただ、実際には何を「複雑」と判断しているのでしょうか。会話の途中でもモデルを選び直しているのでしょうか。また、新しいLLMが追加されるたびにルーターも学習し直すのでしょうか。
Microsoftの論文「HyDRA: Hybrid Dynamic Routing Architecture for Heterogeneous LLM Pools」では、GitHub Copilot Autoで使われるルーティング方式が説明されています。
本記事では数式の詳細には立ち入らず、ソフトウェアエンジニアの視点から仕組みを整理します。
本記事はarXivのv2を参照しています。論文中の本番評価は、主にVS Code Chatを対象としています。
変更前は「安価モデルか高性能モデルか」の二択だった
論文で比較対象となっている従来の本番ルーターは、binary-v1と既存のヒューリスティックを組み合わせた方式です。
binary-v1は、依頼を大きく次の二つに分類します。
- 安価なモデルで処理できる
- 高性能なモデルが必要である
つまり、タスクを「簡単か難しいか」という一つの軸で捉える方式です。
しかし、開発タスクの難しさは一つの軸では表しにくいものです。
たとえば、複雑な設計判断が必要でもコードをほとんど書かない依頼と、推論は単純でも大量のコード生成やツール操作が必要な依頼では、必要な能力が異なります。
また、特定の強いモデルと弱いモデルを前提に学習したルーターでは、新しい中間モデルが追加されても、その特徴をすぐには活用できません。
HyDRAは、この二つの課題を「必要能力の多次元化」と「モデルカタログとの分離」によって解決しようとしています。
HyDRAはタスクに必要な4つの能力を予測する
HyDRAは、依頼を直接「GPT-5.4へ送る」「Claude Sonnetへ送る」と分類しません。
まず、依頼を処理するために次の4能力がどの程度必要なのかを、それぞれ0から1の値で予測します。
- 推論
- コード生成
- デバッグ
- ツール利用
論文中では、次の依頼が例として使われています。
Fix the race condition in WebSocket reconnect.
この依頼に対する予測値は、次のとおりです。
| 能力 | 要求値 |
|---|---|
| 推論 | 0.91 |
| コード生成 | 0.45 |
| デバッグ | 0.88 |
| ツール利用 | 0.35 |
競合状態の原因を特定する必要があるため、推論とデバッグの要求値が高くなっています。一方、大量の新規コードを書く依頼ではないため、コード生成の要求値は比較的低くなっています。
単純な「難易度」ではなく、何が難しいのかを分けて予測するのがHyDRAの特徴です。
要求値の予測にはModernBERT-baseを使う
4つの要求値を予測するのが、ModernBERT-baseです。
ModernBERTは、GPTやClaudeのように文章やコードを生成するモデルではありません。入力文を読み取り、分類などに利用できる数値表現へ変換するEncoder系のモデルです。
HyDRAでは、現在のユーザーメッセージをModernBERT-baseへ入力し、文全体を表す情報から4つの要求値を出力します。
ユーザーの依頼
↓
ModernBERT-base
↓
推論・コード生成・デバッグ・ツール利用の要求値
ModernBERT-baseは約1億4,900万パラメータです。現在の大規模生成LLMと比べれば軽量で、本番ではCPU上のINT8 ONNXモデルとして動作します。
論文本文の計測では、ルーティング処理のレイテンシはP50で55ms、P99で120msでした。
モデルを選ぶために別の大規模生成LLMを呼ぶのではなく、軽量な分類モデルを前段に置いています。
「不足量マッチング」でモデルを選ぶ
依頼に必要な能力を予測した後、それを各LLMの能力プロファイルと比較します。
各モデルにも、推論・コード生成・デバッグ・ツール利用の4軸で能力値が設定されています。
ここで計算するのが、次の不足です。
依頼が要求する能力に対して、そのモデルでは何がどれだけ足りないか
たとえば、次のような関係があるとします。
| 能力 | 依頼の要求値 | モデルの能力 | 不足 |
|---|---|---|---|
| 推論 | 0.9 | 0.7 | 0.2 |
| コード生成 | 0.5 | 0.8 | 0 |
| デバッグ | 0.8 | 0.4 | 0.4 |
| ツール利用 | 0.3 | 0.5 | 0 |
モデルの能力が要求値を上回っている項目は、不足ゼロです。
重要なのは、コード生成能力の余剰で、デバッグ能力の不足を相殺しない点です。コードを多く生成できるからといって、複雑な不具合を正しく分析できるとは限りません。
各能力には重みも設定されており、論文の分析ではデバッグとツール利用の不足が、推論や通常のコード生成より重く評価されています。
不足が最小のモデルではなく、許容範囲内で最安のモデルを選ぶ
HyDRAは、単純に不足が最も小さいモデルを選ぶわけではありません。
不足量がしきい値τ以下のモデルを候補とし、その中から最も安価なモデルを選びます。
たとえば、τ = 0.10の場合は次のようになります。
| モデル | 不足量 | コスト | 結果 |
|---|---|---|---|
| 高性能モデル | 0.00 | 高い | 候補 |
| 中間モデル | 0.05 | 中程度 | 候補 |
| 安価モデル | 0.09 | 安い | 採用 |
| 最安モデル | 0.15 | 最安 | 候補外 |
不足ゼロの高性能モデルではなく、許容範囲内に入った安価モデルが選ばれます。
τを小さくすると品質重視、大きくするとコスト重視になります。このしきい値は運用中に変更でき、調整のたびにルーターを再学習する必要はありません。
モデル情報を外部設定へ分離している
HyDRAが学習によって予測するのは、依頼に必要な4つの能力です。
一方、各LLMの情報は外部設定として管理されます。
- 4軸の能力プロファイル
- コスト
- 対応機能
- 利用可否
能力プロファイルは製品紹介のスペック表ではなく、複数のベンチマーク結果をルーティング用の4軸へ変換したものです。
新しいモデルが追加された場合は、その能力プロファイルとコストをYAMLへ追加すれば、既存のHyDRAが選択候補として扱えます。
論文では、4か月間に6モデルを追加し、3モデルを削除しましたが、ルーターの再学習は一度も必要なかったとしています。
モデルの追加や廃止が頻繁に発生するサービスでは、この分離が大きな利点になります。
Autoは毎ターンモデルを選び直していない
論文を読んで特に重要だと感じたのが、Autoは毎ターンモデルを選び直しているわけではない点です。
本番の既定値は、会話単位でモデルを固定するper-sessionです。
ルーターが呼ばれるのは、次の3つのタイミングです。
- 新しい会話の最初のターン
- ユーザーが明示的にコンパクションした後
- バックグラウンド要約の後
それ以外のターンでは、会話IDにひも付いた同じモデルを使い続けます。
これはプロンプトキャッシュを維持するためです。会話の途中でモデルを切り替えると、それまで蓄積したキャッシュを利用できず、長いコンテキストを改めて処理する必要があります。
その代わり、会話の途中でタスクの難易度が大きく変化しても、コンパクションまでは同じモデルが使われます。
Autoは「毎ターン最適なモデルを選ぶ仕組み」というより、自然なキャッシュ境界でモデルを選び、その区間では固定する仕組みと捉えた方が実態に近いです。
ルーターはリポジトリの中身を直接見ていない
HyDRAへ渡される入力は、現在のユーザーメッセージと次の7種類のフラグです。
- ターン数の区分
- エラーの有無
- ファイル参照の有無
- URLの有無
- コマンドの有無
- コードの有無
- 短文かどうか
入力は最大512トークンです。
一方、ルーターは次の情報を直接見ません。
- 過去のアシスタント回答
- ツールの実行結果
- リポジトリの実際のコードや状態
モデルを選ぶHyDRAと、選択後にリポジトリを読んで作業するLLMは別です。
このため、対象コードを見なければ難易度が分からない依頼や、「これを直して」のような文脈依存の依頼では、ルーターが利用できる情報に限界があります。
論文の学習データ作成では、リポジトリ状態を再現できない文脈依存クエリに保守的な要求ラベルを設定しています。そのため、本番でもリポジトリ依存性が強く判断の難しい依頼を、安全側に寄せる傾向を学習している可能性があります。
ここは論文に明記された本番ルールではなく、学習方法から考えられる傾向です。本番で曖昧な依頼へ固定値を設定する処理があるとは書かれていません。
評価結果
SWE-Bench Verifiedの500件・5モデルプールの評価では、代表的に次の結果が報告されています。
| 方式 | 解決率 | コスト削減率 |
|---|---|---|
| Claude Sonnet 4.6固定 | 74.2% | 0% |
| binary-v1 | 73.8% | 9.1% |
| HyDRA・保守設定 | 74.0% | 54.1% |
コスト削減率は、評価上の「全件をClaude Sonnet 4.6へ送る場合」を基準とした指標です。
保守設定のHyDRAは、Sonnet固定と比べて解決率の差を0.2ポイントに抑えながら、評価上のコストを54.1%削減しました。
また、約100万人ずつを対象とした14日間のA/B試験では、従来ルーターと比べて完了時間、最初のトークンまでの時間、エラー率が改善し、計測指標上では利用者から見える品質の統計的に有意な低下は確認されませんでした。
QRとOracle Routingについて
論文中のQR（Quality Retention）は、通常の正答率ではありません。
Oracle Routingは、すべての候補モデルの結果を後から確認し、解決できたモデルの中から最も安価なものを選んだことにする評価用の仮想ルーターです。
QRは、このOracle Routingの解決率に対して、対象のルーターがどの程度の品質を維持したかを表します。
まとめ
HyDRAの処理を簡単にまとめると、次のようになります。
- 現在のメッセージと簡易フラグをModernBERT-baseへ入力する
- 推論・コード生成・デバッグ・ツール利用の必要度を予測する
- 各LLMの能力プロファイルとの不足量を計算する
- 不足が許容範囲内のモデルを抽出する
- その中から最も安価なモデルを選ぶ
- 原則として会話中は同じモデルを使い続ける
特定のモデル名ではなく、タスクに必要な能力を予測することで、新モデルの追加や価格変更にも柔軟に対応できます。
一方、HyDRA自身はリポジトリの中身や過去の応答を直接見ておらず、会話途中の難易度変化にもすぐには追従しません。
品質、コスト、可用性、プロンプトキャッシュ、頻繁なモデルの入れ替えを両立するための、現実的な本番ルーターだと理解するのが近そうです。
この記事では、HyDRAの技術的な仕組みを中心に整理しました。
Autoと固定モデルの使い分け、プロンプトの伝え方によるモデル選択への影響、実際にAutoを使って感じた点は、個人ブログ版で詳しくまとめています。