Copilot Autoの中身を知りたくてHyDRA論文を読んだ

GitHub CopilotのAutoモードは、依頼の複雑さやモデルの稼働状況を見て、GPTやClaudeなどの中から適したモデルを選びます。

複雑さに応じて選択していること自体は知っていましたが、実際には何を見て判断しているのか、会話の途中でも選び直しているのか、新しいモデルが追加されたときにルーターを学習し直すのかまでは分かりませんでした。

そこで、GitHub Copilot Autoで使われるルーティング方式を説明した論文「HyDRA: Hybrid Dynamic Routing Architecture for Heterogeneous LLM Pools」を読みました。

機械学習の数式を詳しく追うというより、普段Copilotを使うエンジニアとして気になった点を中心に整理します。

本記事は2026年8月4日時点の情報をもとにしています。
HyDRA論文はarXivのv2を参照しています。論文中の本番評価は主にVS Code Chatを対象としています。

前回記事との関係
前回は、Autoで選ばれたSonnet 4.6とCodex、Terra、Sonnet 5のAIクレジット単価を比較しました。今回はその前提として、そもそもAutoがどのようにモデルを選んでいるのかを、HyDRA論文から整理します。
GitHub CopilotのAutoモデル選択とAIクレジット単価を調べた前回記事

Autoのルーターは何が変わったのか

2026年5月20日、GitHubはVS CodeのAutoモデル選択について、モデルの可用性や信頼性だけでなく、タスク内容も評価してモデルを選ぶ方式を発表しました。

GitHubの説明では、推論、コード生成の複雑さ、バグ診断の難しさ、ツール操作の必要性などを評価するとされています。

論文で現在の方式として紹介されているのが、HyDRAです。

変更前：binary-v1＋ヒューリスティック

論文で比較対象となる以前の本番ルーターは、binary-v1と既存のヒューリスティックを組み合わせた方式です。

binary-v1は、依頼を大きく次の二つに分けます。

安価なモデルで処理できる
高性能なモデルが必要である

つまり、タスクを「簡単か難しいか」という一つの軸で判定します。

しかし、開発タスクの難しさには種類があります。

複雑な設計判断が必要でもコードをほとんど書かない依頼もあれば、推論は単純でも大量のコード生成やツール操作が必要な依頼もあります。同じ「難しい」でも、求められる能力は同じではありません。

また、特定の強いモデルと弱いモデルを前提に学習する方式では、新しい中間モデルが追加されても、その特徴をすぐに利用できません。

変更後：タスクに必要な能力を4軸で予測する

HyDRAは、依頼を直接「GPTへ送る」「Claudeへ送る」と分類しません。

まず、依頼の処理に必要な能力を次の4軸で予測します。

推論
コード生成
デバッグ
ツール利用

それぞれ独立した0から1の値として出力されるため、「推論とデバッグは難しいが、コード生成量は少ない」といった依頼も表現できます。

論文では、次の依頼が例として使われています。

Fix the race condition in WebSocket reconnect.

予測結果は次のとおりです。

能力	要求値
推論	0.91
コード生成	0.45
デバッグ	0.88
ツール利用	0.35

競合状態の原因を追う必要があるため、推論とデバッグが高くなっています。一方、大量のコードを新規生成する依頼ではないため、コード生成は相対的に低くなっています。

単に難しいかどうかではなく、何が難しいのかを分けているわけです。

要求能力を予測するModernBERT-base

4つの要求値を予測するのが、ModernBERT-baseです。

GPTやClaudeのように回答文やコードを生成するモデルではありません。入力文を読み取り、分類などに使える数値表現へ変換するEncoder系のモデルです。

ユーザーの依頼
  ↓
ModernBERT-base
  ↓
推論・コード生成・デバッグ・ツール利用の要求値

ModernBERT-baseは約1億4,900万パラメータです。現在の生成LLMと比べれば軽量で、HyDRAではCPU上のINT8 ONNXモデルとして動作します。

論文本文の計測では、ルーティング処理はP50で55ms、P99で120msでした。

モデルを選ぶために、もう一度大規模な生成LLMへ判断を依頼するわけではありません。回答を生成する前に、軽量な分類モデルを通しています。

「不足量マッチング」とは何か

依頼に必要な4能力を予測した後は、各LLMの能力と比較します。

各モデルにも、推論・コード生成・デバッグ・ツール利用の4軸で能力プロファイルが設定されています。

HyDRAが見るのは、次の不足です。

依頼が要求する能力に対して、そのモデルでは何がどれだけ足りないか

たとえば、次のような関係があるとします。

能力	依頼の要求値	モデルの能力	不足
推論	0.9	0.7	0.2
コード生成	0.5	0.8	0
デバッグ	0.8	0.4	0.4
ツール利用	0.3	0.5	0

モデルの能力が要求値を上回っている項目は不足ゼロです。

コード生成が要求以上に得意でも、その余剰でデバッグ能力の不足を相殺しません。コードを多く生成できることと、複雑な不具合の原因を正しく分析できることは別だからです。

各能力には重みもあり、論文の分析では、デバッグとツール利用の不足が、推論や通常のコード生成より重く扱われています。安価なモデルは定型的なコード生成には対応できても、微妙なバグ調査や複数段階のツール操作では失敗しやすかったためです。

最も高性能なモデルではなく、条件を満たす最安モデルを選ぶ

HyDRAは、不足が最小のモデルをそのまま選ぶわけではありません。

不足量がしきい値τ以下のモデルを候補にして、その中から最も安価なモデルを選びます。

モデル	不足量	コスト	結果
高性能モデル	0.00	高い	候補
中間モデル	0.05	中程度	候補
安価モデル	0.09	安い	採用
最安モデル	0.15	最安	候補外

たとえばτ = 0.10なら、不足ゼロの高性能モデルではなく、不足0.09の安価モデルが選ばれます。

τを小さくすると品質重視、大きくするとコスト重視になります。この値は運用中に変更でき、調整のたびに学習し直す必要はありません。

Autoは「最も強いモデルを当てる」仕組みではなく、必要な品質を満たせそうなモデルの中から、なるべく効率のよいものを選ぶ仕組みです。

新しいモデルが増えてもルーターを再学習しなくてよい

HyDRAが学習によって予測するのは、依頼に必要な4つの能力だけです。

各LLMの情報は、外部のYAML設定に分離されています。

4軸の能力プロファイル
コスト
対応機能
利用可否

能力プロファイルは、製品紹介に書かれているカタログスペックではありません。複数のベンチマーク結果を基に、ルーティング用の4軸へ変換した値です。

新しいLLMが追加された場合、そのモデルの能力プロファイルとコストを設定へ追加すれば、既存のHyDRAが選択候補として扱えます。

論文では、4か月間に6モデルを追加し、3モデルを削除しましたが、ルーターの再学習は一度も必要なかったとしています。

Copilotでは利用できるモデルが頻繁に変わります。特定のモデル名を予測するのではなく、要求能力とモデル能力を分離した設計は、実運用ではかなり大きな意味を持ちます。

Autoは毎ターンモデルを選び直していなかった

今回、特に意外だったのはここです。

本番の既定値は、会話単位でモデルを固定するper-sessionです。

ルーターが呼ばれるのは、次の3つのタイミングに限られます。

新しい会話の最初のターン
ユーザーが明示的にコンパクションした後
バックグラウンド要約の後

それ以外のターンでは、会話IDにひも付いた同じモデルを使い続けます。

Autoという名前からは、毎回の依頼を見てモデルを細かく切り替える印象もあります。しかし実際には、自然なキャッシュ境界で選び直し、その区間では固定する仕組みです。

なぜ同じモデルを使い続けるのか

理由はプロンプトキャッシュです。

複数ターンの会話では、過去のやり取り、読み込んだコード、ツール実行結果など、多くのコンテキストが蓄積します。

同じモデルを使い続ければ、そのプロンプト接頭辞をキャッシュして再利用できます。途中でモデルを切り替えると、新しいモデル側には同じキャッシュがないため、長いコンテキストを改めて処理しなければなりません。

HyDRAは、タスクの変化へ毎ターン追従することより、キャッシュによる速度と効率を優先しています。

そのため、最初は簡単な質問だった会話で、途中から複雑な設計やバグ修正へ移っても、コンパクションまでは同じモデルが使われます。

反対に、最初に高性能モデルが選ばれた会話で、その後は単純な作業だけになっても、同じモデルのままになる可能性があります。

ルーターはリポジトリの中身を見ていない

HyDRAへ入力されるのは、現在のユーザーメッセージと次の7種類のフラグです。

ターン数の区分
エラーの有無
ファイル参照の有無
URLの有無
コマンドの有無
コードの有無
短文かどうか

入力は最大512トークンです。

一方、HyDRAは次の内容を直接見ません。

過去のアシスタント回答
ツールの実行結果
リポジトリの実際のコードや状態

モデルを選ぶHyDRAと、選択後にリポジトリを読んで作業するLLMは別です。

そのため、「このテストが失敗する理由を調べて」のような依頼が実際にどれほど難しいかを、ルーターがコードを読んで判断しているわけではありません。

曖昧な依頼やリポジトリ依存タスクは安全側に寄りやすいのか

論文では、学習データをリポジトリ依存性によって分類しています。

リポジトリ状態を再現できず、依頼文だけでは正しく評価できないクエリについては、4つの能力すべてに保守的な要求ラベルを設定します。公開リポジトリの場合は、記録されたコミットを取得して当時の状態を再現しています。

これは学習データを作るときの処理であり、本番で「これ」「それ」と書かれたら固定値を設定するルールではありません。

ただし、このようなデータから学習しているため、ファイル参照や過去の文脈が必要で、ルーターだけでは難易度を判断しにくい依頼を、安全側に寄せる傾向を獲得している可能性はあります。

通常の会話途中で「それで進めて」と書いた場合は、そもそも再ルーティングされないことが多いため、同じLLMが会話履歴を見て処理します。

問題になりやすいのは、新しい会話の最初から曖昧な依頼をした場合や、コンパクション後に再ルーティングされた場合です。

プロンプトの伝え方で選ばれるモデルは変わり得る

HyDRAはユーザーのメッセージから必要能力を予測します。

そのため、実質的には同じ作業でも、伝え方によって要求値が変わる可能性があります。

たとえば、次の二つを比べます。

この関数を修正してください。

すべての競合状態、スレッド安全性、メモリリーク、エッジケースを精査し、高度なツール操作を用いて修正してください。

後者では、推論・デバッグ・ツール利用の要求値が高くなると考えられます。

実際にそれらの確認が必要なら、高性能モデルが選ばれるのは正しい動作です。

一方、作業自体は単純なのに、念のため難しそうな表現を大量に加えると、安価なモデルでも処理できる依頼が、より高性能なモデルへ送られる可能性があります。

難しそうな文を付けて高性能モデルへ誘導できるか

論文では、この性質を使った診断試験も行っています。

本来は安価なモデルへ送られる単純なプロンプトに、次のような文を追加します。

深い多段階推論と複雑なデバッグが必要
競合状態やスレッド安全性を考慮する
最先端モデルの能力を必要とする
ビザンチン障害耐性を分析する
推論0.95、デバッグ0.90、ツール利用0.85が必要

元のタスク内容を変えず、難しそうな表現だけを追加して、高価なモデルへ誘導できるかを調べています。

本番で使われるINT8版ルーターでは、キーワードを詰め込んだ文を追加したケースで、12%のクエリが最先端モデルへ送られ、平均コストは元の3.56倍になりました。

人間が確認した30件では、追加文を付けても元のタスク内容は変わっておらず、そのうち28件は引き続き安価なモデルで十分と評価されています。

つまり、実際のタスクが難しくなったのではなく、表面的な表現によってルーターの判断だけが変わった例です。

ただし、難しそうな単語を書けば必ず高性能モデルが選ばれるわけではありません。「推論=0.95」と書いた値が、そのままルーターへ入力されるような単純な仕組みでもありません。

評価結果をどう読むか

論文では、HyDRAの品質を測るためにOracle Routingを基準として使います。

Oracle Routingは、すべての候補モデルの実行結果を後から確認し、解決できたモデルの中から最も安価なものを選んだことにする仮想ルーターです。

どのモデルが成功するかを事前に知っている前提なので、本番では利用できません。

論文のQR（Quality Retention）は、Oracle Routingの解決率に対して、HyDRAがどの程度の品質を維持できたかを表します。QRが80.6であれば、通常の正答率が80.6%という意味ではありません。

SWE-Bench Verified

実際のGitHub Issueを基にしたコード修正ベンチマーク、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試験でも、従来ルーターと比べて完了時間、最初のトークンまでの時間、エラー率が改善しています。計測指標上では、利用者から見える品質の統計的に有意な低下は確認されませんでした。

GitHubはAutoを推奨していますが、常に自分に合うとは限らない

GitHubは、AIクレジットを効率的に使う方法として「まずAutoを使う」ことを推奨しています。

タスクごとに適したモデルを自動で選び、不要なモデル切り替えを避けてプロンプトキャッシュを維持できるため、一般的なデフォルトとしては合理的です。

ただし、Autoが最適化するのは、利用者個人のモデルの好みではありません。

タスクの要求能力、モデルの能力、コスト、可用性、稼働状況などを基に選ぶため、出力傾向が自分に合わないモデルが選ばれることもあります。

私の環境では、Autoを使うとSonnet系が選ばれる場面が多く、必ずしも好みの結果になるわけではありません。

そのため、私は次のように考えています。

難易度を自分で判断しにくいタスクではAutoを使う
出力傾向や使いたいモデルが明確な場合は固定する
タスクの性質が大きく変わったら新しい会話に分ける

Autoは強いデフォルトではありますが、常にAutoへ任せる必要があるわけではありません。

GitHubの公式ドキュメントでも、利用者がAutoから特定モデルへ切り替えられることは維持されています。モデルごとの癖を把握している場合は、Autoと固定モデルを使い分ける方が実用的です。

Autoを使うときに意識したいこと

HyDRAの仕組みから考えると、次の使い方が合っています。

タスクの性質が変わったら会話を分ける

Autoは原則として会話単位でモデルを固定します。

簡単な質問から始めた会話で、後から複雑な実装へ移っても、最初に選ばれたモデルが使われ続ける可能性があります。

反対に、複雑な設計相談の後に単純なMarkdown整形を依頼しても、高性能モデルのままになる可能性があります。

最初のメッセージで本題を伝える

会話の最初はルーティングが行われるタイミングです。

「これを見て」とだけ書いて、次のターンで本題を伝えるより、最初から何を調査・修正したいのかを示した方が、必要能力を判断しやすくなります。

必要な条件は省かない

高性能モデルを避けるために、必要な品質要件や考慮事項を省くのは本末転倒です。

本当に競合状態やエッジケースの確認が必要なら、それを明記した結果として高性能モデルが選ばれるのは、想定どおりの動作です。

一方、実際には不要な「極めて高度な」「すべてを徹底的に」といった表現を加えると、安全マージンの大きいモデルが選ばれる可能性があります。

まとめ

HyDRAの処理を簡単にまとめると、次のようになります。

現在のメッセージと簡易フラグをModernBERT-baseへ入力します
推論・コード生成・デバッグ・ツール利用の必要度を予測します
各LLMの能力プロファイルとの不足量を計算します
不足が許容範囲内のモデルを抽出します
その中から最も安価なモデルを選びます
原則として会話中は同じモデルを使い続けます

特定のモデル名を予測するのではなく、タスクに必要な能力とモデル側の能力を分離したことで、新しいLLMの追加にも再学習なしで対応できます。

一方、HyDRA自身はリポジトリの中身や過去の応答を直接見ていません。また、プロンプトキャッシュを守るため、会話途中の難易度変化にもすぐには追従しません。

Autoは、毎ターン状況を完全に理解して最適なモデルを選び続ける魔法の仕組みではありません。

品質、コスト、可用性、応答速度、プロンプトキャッシュ、頻繁なモデルの入れ替えを両立するために設計された、現実的な本番ルーターです。

仕組みを理解すると、GitHubがAutoを推奨する理由も分かります。一方で、自分の好みや用途が明確なら、固定モデルと使い分けるのも自然な選択だと思います。