8月14日、Databricksが「Smart Routing in Unity AI Gateway: Match frontier quality with 30%+ lower cost per task」と題した記事を公開した。この記事では、LLMコーディングエージェントのタスク複雑度に応じてモデルを自動選択し、コストを30%以上削減するルーティング機能「Smart Routing」について詳しく紹介されている。
コスト削減の核心：「全タスクに最高モデル」をやめる
LLMを活用したコーディングエージェントのコスト管理は、2026年だけで33本の新モデルがリリースされるほど選択肢が爆発している現状では、現実的な課題だ。Databricksが自社コードベースを使ったベンチマーク実験（詳細は先行記事）で確認したように、モデルは能力ティアでクラスタリングされており、フラグの切り替えや単一ファイルの編集、スコープの明確なバグ修正といった日常的な作業は、最高スペックのモデルを必要としない。
ところが実態では、選択肢の多さに圧倒されたユーザーが「最も高性能なモデルを常に最高エフォートで使う」設定に流れている。安価なモデルを適切に使い分けるだけで50%以上のコスト削減が可能にもかかわらず、だ。
この問題を解決するのが、今回ベータ提供を開始したSmart Routingである。統合先となるUnity AI Gatewayは、企業全体のAIアクセス・支出管理・ガバナンスを一元化するDatabricksのプラットフォームだ。単一のエンドポイントを通じて複数のLLMプロバイダーを束ね、コスト可視化やレート制限、アクセス制御といった機能を提供する。Smart RoutingはそのUnity AI Gatewayに統合されており、タスクの複雑度に応じたモデルの自動選択を実現する。初めてUnity AI Gatewayを利用する場合は、公式ドキュメントも参照されたい。
実測コスト削減の数字
Databricks社内のコーディングワークロードでの結果は以下のとおりだ：
- 社内ベンチマーク（外部ラボ未アクセス）：Opus 5単体比でコスト35%削減（コスト比65%）
- 公開コーディングベンチマーク：56%のコスト削減（Opus 5と同等の性能を半額以下で達成）
総合すると、Smart RoutingはOpus 5単体と比較してコストを35%削減しながら、単一モデルを上回る性能を示した。
Smart Routerの仕組み
ルーティングのタイミングには大きく2つのアプローチがある。
- リクエスト単位のルーティング：各メッセージのプロンプト複雑度でモデルを切り替える。ただし、スケールではキャッシュヒット率がコストを支配するため、連続ターンを別モデルに振ると逆効果になりやすい。
- タスク単位のルーティング：セッション開始時にタスク全体の複雑度を評価し、セッション中はそのモデルを維持する。キャッシュ効率を保ちながら最適化できる。
DatabricksはキャッシュヒットレートのためにTaskルーティングを採用した。処理の流れは次のとおりだ。
まずタスクを分類する。 低コスト・低レイテンシの小型モデルがタスク説明文を読み込み、以下の意味的フィールドでラベリングする：
- 変更対象のシステム箇所
- プロンプトに含まれるコードエビデンス（スニペット、トレースバック、なし）
- 障害の性質
- 修正の局所性
- プロジェクト種別
これらからタスクタイプファミリーと言語ファミリーを導出する。フロンティアモデルを分類器に使うと、節約したい簡単なタスクにまでコストが発生するため、意図的に小型・高速なモデルを使う設計だ。
次にモデルクラスを決定する。 デフォルトは中規模モデルで、ラベルに応じてフロンティアモデルへのエスカレーション、または安価モデルへのダウングレードを行う。
Omnigentによるモデル＋ハーネスの同時最適化
Smart RoutingはClaude CodeやCodex上でネイティブに動作するが、Databricksはさらに踏み込んで、モデルとコーディングハーネス（エージェントの実行基盤）を同時に最適化するOmnigent（メタハーネス）と組み合わせることで、より大きな効果を得られるとしている。
Omnigent上のSmart Routingは2層で機能する：
- セッションレベル：開発者がハーネスを手動選択する代わりにSmart Routingを指定すると、Unity AI GatewayのSmart Routing APIがモデルとハーネスを自動決定する。
- サブエージェントレベル：すべてのサブエージェント起動もSmart Routing APIを経由するため、親タスクとは異なるモデル・ハーネスを使える。例えば、大規模コードベースのサマリー作業は安価なモデルに振り、アーキテクチャ設計は高価なモデルに振るといった細粒度の制御が可能だ。
現在の課題と今後の方向性
Databricksは現状の限界も率直に認めている。ベンチマークタスクは「自己完結した仕様書」として届くが、実際の開発者セッションはそうではない。
- 最初のプロンプトはほぼ曖昧：開発者が最初に打つのは症状や大まかな意図であって仕様ではなく、ルーターはその最初のメッセージで判断を確定してしまう。
- セッションは再利用される：1回目のリクエストに適切だった判断が4回目には間違っている場合でも、ルーターに再問合せされない。
これに対して検討中のアプローチは次の4点だ：
- スコープが最初から明確なタスクから着手（PRレビュー、サブエージェント起動、バッチ処理など）
- 数ターン後にルーティング：安価なモデルで初期の対話を処理し、タスクの輪郭が見えてからルーティングを確定する
- セッションを短く保つ：単一タスクに集中するセッション設計を促すツール作り
- モデル切り替えコストの低減：コンテキストコンパクション（キャッシュミスが既に発生しているタイミング）を自然なモデル切り替えの継ぎ目として活用する
Smart Routingは現在ベータ版としてUnity AI Gateway経由で利用可能だ。詳細はSmart Routing in Unity AI Gateway: Match frontier quality with 30%+ lower cost per taskを参照していただきたい。
