OmnigentのSmart Routingを試す: サブエージェントごとにhaikuとopusが自動で振り分けられるまで

Posted at 2026-08-23

はじめに

Omnigent v0.9.0のリリースで、Smart Routingが大きく強化されました。各タスクとそのサブエージェントを、最適なモデルとハーネスに自動でルーティングする機能です。

Smart Routingには、Unity AI Gatewayのルーティングを使うDatabricks連携版と、LLM分類器を使うOSS版の2系統があります。今回はローカルのOmnigentサーバーでOSS版を有効化し、難易度の異なるサブエージェントがどうルーティングされるかを確かめました。有効化までに何度かハマったので、そのあたりも含めて書いていきます。

OmnigentのSmart Routingとは

Omnigentは、Claude CodeやCodexなどの複数のコーディングエージェントを1つ上のレイヤーから束ねる、Databricks発のオープンソースのメタハーネスです。開発者は毎回「このタスクにはどのモデル・どのハーネスが良いか」を自分で選ぶ代わりに、Smart Routingを選んでおけば、ルーターがタスクの内容を読んで判断してくれます。

ルーティングの実装は2系統あります。

Databricks連携版: ルーティング判断をUnity AI GatewayのSmart Routing (ベータ) に委ねる。タスク単位で判定され、アカウントレベルでのプレビュー有効化が必要
OSS版: OmnigentサーバーがLLM分類器 (ビルトインジャッジ) を使って自前で判定する。追加のインフラ不要で、サーバー設定だけで有効化できる

今回試すのはOSS版です。判定の粒度はセッション開始時の最初のメッセージが基本ですが、v0.9.0以降はセッション中に生成されるサブエージェントも、生成のたびに個別にルーティングされます。この「サブエージェントごとの判定」が今回の検証の主役です。

OSS版の仕組み: ジャッジ用のLLMが別に必要

OSS版Smart Routingの構造を先に整理しておきます。登場するLLMは2種類です。

ジャッジ: 「このタスクは軽いか重いか」を分類するLLM。サーバー設定の llm: ブロックで指定する。セッションやサブエージェントの開始時に1回呼ばれるだけなので、軽量・安価なモデルで十分です
実作業のモデル: ルーティング先の候補。Claude CodeやCodexなど、ホストに登録済みのハーネスと資格情報がそのまま使われます

ここで1つ注意点があります。実作業側はClaude Pro/MaxやChatGPTのサブスクリプション連携で動かせますが、ジャッジにサブスクリプション認証は使えません。サブスクリプションのCLIログインはハーネス起動用の資格情報であって、サーバーが行う汎用のLLM API呼び出しには使えない作りになっています。Anthropicの規約上も、サブスクリプションのOAuthトークンをClaude Code以外のサードパーティから利用することは禁止されています。

つまり「実作業はサブスク、ジャッジだけAPIキーかDatabricksプロファイルで従量課金」という構成になります。今回はジャッジをDatabricksホストの基盤モデルにしました。~/.databrickscfg のプロファイルで認証できるので、新しいAPIキーを発行せずに済みます。

セットアップ

環境はmacOS、Omnigent 0.10.0です。ハーネスとしてClaude Code (サブスクリプション) とCodexを omni setup で登録済みの状態から始めます。

サーバー設定にllm:ブロックを追加

サーバー設定は ~/.omnigent/config.yaml です。ホストやプロバイダーの定義が入っている既存のファイルに、llm: ブロックを追記します。

llm:
  model: databricks-claude-haiku-4-5
  profile: DEFAULT

model はワークスペースで利用できるトークン単位の従量課金エンドポイント名です。databricks- プレフィックス付きで指定すると、Omnigentがワークスペース経由でルーティングしてくれます。利用可能なエンドポイント名はワークスペースのサービングタブ、または以下のドキュメントで確認できます。

基盤モデルAPIで利用できるDatabricksホストの基盤モデル

profile は ~/.databrickscfg のプロファイル名です。

ハマりどころ1: llm:ブロックはフラットに書く

ここが最初のハマりどころです。OmnigentにはエージェントをYAMLで定義する仕組みがあり、そちらのドキュメントではDatabricks認証を次のように書きます。

# これはエージェントYAML (executor:) の書き方。サーバーのllm:ブロックでは使えない
auth:
  type: databricks
  profile: DEFAULT

この auth: の入れ子をサーバーの llm: ブロックにそのまま持ち込むと、認証設定として認識されません。サーバー設定では model と profile (またはAPIキーなら api_key) をブロック直下にフラットに書くのが正しい形式です。同じプロダクト内に2つの書き方が共存しているので、コピペ元のドキュメントがどちらの文脈かを確認してください。

ハマりどころ2: プロファイルのトークン切れはクラッシュで教えてくれる

設定を直して起動したところ、今度はサーバーがクラッシュしました。

OSError: Could not resolve Databricks workspace credentials.
Tried: (1) databricks-sdk Config(profile='DEFAULT').authenticate(),
(2) profile [DEFAULT] in /Users/.../.databrickscfg, ...

原因はプロファイルのOAuthトークンの期限切れでした。確認は次のコマンドでできます。

databricks auth profiles

Valid列が NO になっていたら、再ログインします。

databricks auth login --host <workspace-url>

これでValidが YES になれば解消です。ジャッジの認証エラーが起動時のクラッシュとして明確に出るのは、原因の切り分けという意味ではむしろ親切な挙動でした。

ローカルサーバーの起動とホスト登録

設定ファイルを指定してサーバーを起動します。

omni server -c ~/.omnigent/config.yaml

別のターミナルで、ローカルサーバーに対してホストを登録します。ルーターの選択肢 (どのモデル×ハーネスから選ぶか) はホストのモデルカタログから来るので、この登録は必須です。

omni host --server http://localhost:6767

ブラウザで http://localhost:6767 を開けばWeb UIにアクセスできます。

ハマりどころ3: Smart Routingは「Model」ドロップダウンにいる

ドキュメントを読むと、ルーターが構成されているとハーネスピッカーに「Auto」オプションが表示される、とあります。ところが私の環境 (0.10.0) では、ハーネスピッカーにもその中の「More」にも見当たりませんでした。

正解は、ハーネス (Claude Code) を選んだ状態でコンポーザーのギアアイコンを開き、「Model」ドロップダウンの中でした。

ドロップダウンを開くと、Default・Opus・Sonnet・Haikuといったモデルの並びの先頭に「Smart Routing」が選択肢として入っています。これを選んでSaveすれば有効化完了です。v0.9.0でハーネスピッカーがサポートティア別に再編された影響か、ルーティングは「ハーネスの一種」ではなく「モデル選択の一種」として置かれています。ここに気づくまでにかなり遠回りしました。

サブエージェントでルーティングを観察する

有効化できたので、本題の検証です。OSS版のルーティングはセッション開始時の1回に加えて、サブエージェントの生成ごとに走ります。これを1セッションで観察するには、難易度の異なるサブタスクを意図的に混ぜたプロンプトが効果的です。全サブタスクが同じ重さだと、全員が同じモデルに行ってしまい、ルーティングの妙が見えません。

検証プロンプト

CSV分析のCLIツールを、責務を分けた3つの並列サブエージェントで作らせます。

Build a small CLI tool for CSV analysis using parallel subagents with clearly separated responsibilities:

1. One subagent writes the argument parsing boilerplate (standard argparse setup)
2. One subagent implements the statistics engine (percentiles, correlation, outlier detection with proper numerical stability)
3. One subagent writes the README with usage examples

Integrate their outputs into a working tool at the end.

argparse係とREADME係は軽量タスク、統計エンジン係は数値安定性まで要求する重量級タスク、という設計です。

結果: 難易度に応じてhaikuとopusに分かれた

期待通り、3つのサブエージェントがきれいに割れました。Web UIには各サブエージェントの生成時にSmart routingカードが表示され、判定結果と理由が読めます。

結果を表にまとめます。

サブエージェント	判定	選ばれたモデル	ルーターの理由 (要約)
argparse係	SIMPLE	claude-haiku-4-5	ビジネスロジックのない純粋なボイラープレート。最安モデルを選択
統計エンジン係	COMPLEX	claude-opus-5	Welford法、パーセンタイル補間、相関計算など数値安定性が要る実装。最上位モデルを選択
README係	SIMPLE	claude-haiku-4-5	コード実行のない単一ドキュメントの執筆。最安モデルを選択

注目したいのは、理由の具体性です。「統計エンジンだから重い」という表面的な判定ではなく、プロンプト内のWelford's algorithmやpercentile interpolationといった要求内容まで読んだ上でCOMPLEXと判定しています。3タスク中2つが最安モデルに落ちているので、全部を中位以上のモデルで回す運用と比べると、コスト面のインパクトは相当大きいはずです。

ハーネスの要求をルーターがオーバーライドする

もう1つ、カードをよく見ると面白い記述があります。

Spawn requested system.ai.claude-sonnet-4-6[1m]; overridden — the router picked claude-haiku-4-5.

サブエージェントを起動する際、親のClaude CodeはSonnetを要求しています。しかしルーターはその要求をオーバーライドして、タスク難易度に応じたモデル (haikuまたはopus) に差し替えています。ハーネス自身のモデル選択よりもルーターの判断が優先される、という階層関係がここから読み取れます。ハーネス任せだと3タスクとも一律Sonnetで動いていたところが、軽いタスクは安く、重いタスクはより高品質に、という配分に組み替えられたわけです。

まとめ

OmnigentのOSS版Smart Routingを試して分かったことをまとめます。

OSS版はサーバー設定の llm: ブロックでジャッジ用LLMを指定するだけで有効化できる。routing: ブロックは不要
llm: ブロックは model と profile をフラットに書く。エージェントYAMLの auth: 入れ子とは別形式
ジャッジにサブスクリプション認証は使えない。APIキーかDatabricksプロファイルが必要 (実作業側はサブスクのままでよい)
Databricksプロファイルのトークン切れは起動時のクラッシュとして明確に出る。databricks auth login で解消
UI上のSmart Routingはハーネスピッカーではなく、ギアアイコン内の「Model」ドロップダウンにある
ルーティングはセッション開始時に加えてサブエージェント生成ごとに走り、判定理由がUIカードで確認できる
ハーネスが要求したモデルをルーターがオーバーライドする。難易度混合の3並列サブエージェントで、SIMPLE 2件がhaiku、COMPLEX 1件がopusに振り分けられた

一番の収穫は、ルーティングの判定理由がそのままUIに表示されることでした。「なぜこのモデルが選ばれたのか」がブラックボックスにならないので、判定の傾向を観察しながら運用に載せるかを判断できます。難易度の異なるサブタスクを混ぜたプロンプトを1本流すだけで、この振り分けの様子が一望できるので、Smart Routingの評価を始める最初の一歩としておすすめです。