技術要約：エージェント・アズ・ア・ルーター（Agent-as-a-Router）

1. 問題提起

現実世界のユーザーは、異なるドメイン（アルゴリズム設計、データサイエンス、コード補完など）でそれぞれ優れた能力を持つ、異なるプロバイダーの複数の大規模言語モデル（LLM）を利用できることが多いが、すべてのタスクにおいて支配的なモデルは存在しない。現在のコーディングエージェントは、通常、すべてのタスクに対して単一の固定されたLLMに依存しており、この設計は、ユーザー中心のコスト効率やタスクレベルの品質よりも、プロバイダー側の予測可能性を優先している。

核心となる問題は、自動モデルルーティングである。すなわち、パフォーマンスを最大化しつつコストを最小化するために、どのモデルが各入力コーディングタスクを処理すべきかを決定することである。既存のルーティング手法は、これを静的な一回限りの分類問題として扱っており、多くの場合、言語モデルをルーティングポリシーとして採用している。しかし、予備的な実験により、静的なルーターと「パータスク・オラクル（各特定のタスクに対して最適なモデルを知っているもの）」との間には、顕著な性能差があることが明らかになった。本論文は、既存のルーターのボトルネックは推論能力の欠如ではなく、**情報の欠乏（information deficit）**であると指摘している。つまり、静的なルラーは、デプロイメント中に実行に基づいた経験を蓄積できないのである。

2. 手法

2.1. 診断：情報の欠乏

著者らは、ゼロショットLLMルーター（Claude Sonnet 4.6による駆動）を用いたアブレーション研究を実施した。

• バニラ・ルーター（Vanilla Router）: 平均性能 41.41%。
• +性能統計（+Perf Stats）: ホールドアウト・プロービング・セットからの事前の性能統計が提供された場合、スコアは47.74%に上昇し（相対利得 +15.3%）、同じ静的事前分布をエンコードした最良のヒューリスティック・ルーター（47.50%）をも上回った。
• 結論: 主要な制限は、ルーターモデル自体の推論能力ではなく、動的かつ実行に基づいた情報の欠如である。

2.2. エージェント・アズ・ア・ルーター・フレームワーク

情報の欠乏に対処するため、著者らはエージェント・アズ・ア・ルーターを提案する。これは、ルーティングをコンテキスト・アクション・フィードバック（C-A-F）ループとして定式化したフレームワークである。静的なルーターとは異なり、このフレームワークはタスクのストリームを通じて進化する。

1. コンテキスト ($c_i$): ルーターはタスクプロンプト、メタデータ、および過去のループから蓄積された履歴（メモリ）を観察する。
2. アクション ($a_i$): ルーターは候補プールからモデルを選択する。
3. フィードバック ($f_i$): 選択されたモデルの出力はサンドボックス内で実行され、検証器（verifier）がスコアとコストを生成する。
4. 更新: フィードバックは記憶され、次のタスク ($c_{i+1}$) のためのコンテキストへとマージされる。

この定式化は、コンテキスト付きマルチアームドバンディット問題に関連しており、評価の自然な指標は累積リグレット（cumulative regret）（ルーターの性能とパータスク・オラクルとの間の蓄積された差）である。

2.3. ACRouterの実装

このフレームワークは、以下の3つのコアモジュールからなるACRouterとして実装される。

• オーケストレーター（Orchestrator）: DimensionBest事前分布、メモリからのトップ10の履歴近傍（余弦kNNによる検索）、およびタスクメタデータを統合してルーティング決定を行う。軽量で微調整されたQwen3.5-0.8Bモデルを、重み付き投票によるヒューリスティック・ルールと組み合わせて使用する。
• 検証器（Verifier）: サンドボックス環境内でモデルの出力を評価する。信号（AST解析、実行結果、LLM-as-Judge）を集約し、統一された性能スコア ($u_i \in [0, 1]$) を生成する。
• メモリ（Memory）: タスク埋め込みをキーとするオンライン・ベクトルストア。選択されたモデル、性能、コスト、および検証トレースをログに記録する。細粒度でコンテキストに応じた過去の成功と失敗の検索を可能にするため、FIFO制限付きストア（20Kエントリ）を使用する。

2.4. CodeRouterBench

ストリーミングタスクにおけるルーティングを評価するために、著者らはCodeRouterBenchを導入した。これは以下の要素で構成される。

• 約10,000のタスク: 10のコーディング次元（9つのイン・ディストリビューション単一ターンタスクと、1つのアウト・オブ・ディストリビューション・エージェンティック・プログラミング・タスク）にわたる。
• 8つのフロンティアLLM（Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5などを含む）。
• 実行検証済みスコア: タスクはサンドボックス実行またはLLM-as-Judgeを通じてスコアリングされ、リグレットベースの比較のためのグラウンドトゥルース（正解）観測行列を提供する。

3. 主な貢献

1. フレームワーク: ルーティングをC-A-Fループとして定式化し、ルーターが実行に基づいたフィードバックを通じて能動的に情報のギャップを埋めることを可能にするエージェント・アズ・ア・ルーターの提案。
2. 成果物:
   • ACRouter: オーケストレーター、検証器、メモリモジュールを備えたフレームワークの具体的な実装。
   • CodeRouterBench: ストリーミングタスクにおけるリグレットベースのルーター比較のために特別に設計された、標準化された評価環境（約10Kタスク、8つのLLM、およびOODエージェンティック・プログラミング・テストベッドを含む）。
3. 知見:
   • 情報の欠乏: ルーティングのボトルネックは情報のアクセスであり、推論ではない。性能統計を提供することで、15.3%の相対的利得が得られる。
   • パフォーマンス: ACRouterは、イン・ディストリビューションのタスクにおいて最低の累積リグレットを達成し、OOD（アウト・オブ・ディストリビューション）のエージェンティック・プログラミング・タスクにも効果的に適応する。
   • 静的な限界: 軽量な静的ルーター（学習済み分類器、ヒューリスティック）は、イン・ディストリビューションのタスクでは妥当な性能を示すが、OODタスクでは著しく失敗する。一方、ACRouterは強力な性能を維持する。

4. 実験結果

実験は、イン・ディストリビューション（ID）およびアウト・オブ・ディストリビューション（OOD）の両方のタスクストリームに対して行われた。

• イン・ディストリビューション・パフォーマンス:

  • ACRouterは、最高の平均性能（49.98%）と最低の累積リグレット（205.5）を達成し、静的な「DimensionBest」ヒューリスティック（47.50%）およびすべての学習済みポリシー・ベースラインを上回った。
  • また、最強の単一モデルを常に使用する場合（Always-Opus 4.6、比率は1.29）と比較して、優れたコスト効率（Perf/$ 比 3.79）を示した。

• アウト・オブ・ディストリビューション（OOD）への汎化:

  • エージェンティック・プログラミング・テストベッド（176タスク）において、ACRouterは**62.50%**の平均性能を達成し、Always-Opusベースライン（57.14%）および他のすべてのルーターを大幅に上回った。
  • 静的分類器（例：LogReg, RouteLLM-BERT）はOODタスクで崩壊し、性能は8.93%～21.43%に低下し、ランダム選択よりも低くなった。
  • ストリーム中に検証済みの経験を蓄積するACRouterの能力は、新しいタスク分布への適応を可能にしたが、静的な手法は凍結された事前分布に依存していたため失敗した。

• コスト分析:

  • ACRouterはメモリおよび検証器モジュールのオーバーヘッドが発生するものの、最も高価なモデル（Opus 4.6）を常に選択する場合よりもコスト効率が高く、かつ高い品質を提供できる。
  • 「Always-Kimi-K2.5」戦略は、最高のコスト効率（Perf/$ 12.62）を提供したが、絶対的な性能面で大きな犠牲（AvgPerf 36.66%）を伴った。

5. 意義と主張

本論文は、実行に基づいたフィードバックを通じて能動的に情報のギャップを埋めることが、ヘテロジニアスなツールやモデル間でルーティングを行う必要があるエージェンティック・システムを構築するための一般的な原則であると主張している。

• パラダイムの転換: 本研究は、ルーティングを静的な分類問題から、動的で自己適応的なプロセス（C-A-Fループ）へと移行させるものである。
• 実用的な有用性: ユーザーは、単一の「最良」モデルに頼るのではなく、動的にルーティングを行うことで、オラクルに近い性能とコスト効率を達成できることを示している。
• 汎用性: C-A-Fループは、単なるルーティングメカニズムとしてだけでなく、ツール選択、APIエンドポイント選択、および労力配分に適用可能な、より広範な意思決定パラダイムとして提示されている。
• 謙虚な姿勢: 著者らは、プロバイダー側のキャッシュヒット率を観察できないこと（コスト見積もりが絶対的ではなく相対的であること）や、予算の実行可能性を維持するためにOODタスクのステップ制限を減らしたことなどの限界を認めている。また、現在の実装はkNNメモリを用いたLLMポリシーを使用しているが、代替となるパラメータレベルのメモリ技術の探索が今後の課題であるとしている。

要約すると、本論文は、コーディング用エージェントシステムにとっての未来は、単一の支配的なモデルを見つけることではなく、適切な仕事に対して適切なツールを選択するために、実行フィードバックから学習する適応型ルーターを構築することにあると論じている。