> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w30-model-harness-an-intelligent-routing-vision.md).

# W30-Model × Harness：インテリジェントルーティングの構想

最近、Databricksの[Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)を読んだ。

社内でマージ済みのPRから評価タスクを作り、実際の数百万行のコードベースで、モデルとCoding Agent Harnessを比較した記事だ。最も注目すべき結論は、Harness自体が結果を大きく変え、モデルの順位はそれほど重要ではなかったことにある。

Databricksは同じモデル、同じthinking effortを使い、Claude Code、Codex、PiなどのHarnessでタスクを実行した。一部の比較では品質はほぼ同じでも、費用に2倍以上の差があった。Piが各ターンに送るコンテキストは約3分の1で、より小さな作業集合と少ないターンで完了できた。

これは、私たちが普段の問いを間違えていることを示す。

私たちはいつも、コードを書くにはどのモデルが最適かと問う。しかし、実際の実行単位は、すでに一組の設定へ変わっている。

> model × harness × thinking effort × tools × policy

ここでのHarnessは、Agent loopを動かす実行環境だ。モデルは能力の上限を決める。Harnessはコードベースの理解、コンテキストの管理、ツールの呼び出し、結果の検証、停止の方法を決める。最終的な働きは、設定全体から生まれる。

### 設定単位で振り分けるサービス

記事を読んで、一つのサービスを思いついた。

1. 最新のmodel × harnessの組み合わせを継続的に評価する。
2. 入ってきたタスクの種類、複雑さ、リスクを見分ける。
3. 品質、費用、遅延、リスクの制約のもとで、パレート最適な設定へ自動で振り分ける。

維持するのは静的なランキングではなく、時とともに変わる、条件付きの性能地図だ。

> ある種類のタスクを、あるコードベースと制約のもとで解くとき、どの設定が最も適しているか。

設定Aはfeature flagの変更に最適かもしれない。Bはモジュールをまたぐリファクタリングが得意かもしれない。Cは成功率が数ポイント高いだけなのに、費用が5倍かかるかもしれない。全体の王者はいない。異なるタスク分布に応じた局所的な最適解があるだけだ。

ルーターはタスクを受け取ると、まず特徴を取り出す。対象言語とディレクトリ、変更範囲の見積もり、明確なテストの有無、コード検索の必要量、ロールバックの可否、権限のリスクなどだ。そのうえで、現在有効なパレートフロンティアから設定を選ぶ。終了後はテスト結果、人による手直し、token消費、実行時間、ツール操作の履歴を、評価システムへ戻す。

こうして一つのループができる。

> 非公開のタスク集合 → 組み合わせの評価 → タスクの識別 → 設定への振り分け → 実際の結果 → 評価の更新

### すでに存在する三つの要素

この方向に誰も近づいていないわけではない。ただ、既存製品の多くは、それぞれ異なる層にとどまっている。

第一は、モデルルーターだ。

[Not Diamond](https://docs.notdiamond.ai/docs/key-concepts)は入力を分析し、候補モデルの間で品質、費用、遅延についてパレート最適化する。[OpenRouter Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router)も、種類と複雑さに応じてモデルを選ぶ。Not Diamondは自社の評価データで専用ルーターを訓練でき、Coding Agent向けのCode Routerも予告している。

これらが標準で判断する対象は、今も主にモデルである。Not Diamondは独自モデルやagentic workflowを候補エンドポイントとして包めるので、技術的には組み合わせの振り分けも実現できる。ただし、Harnessを独立した、観測でき、継続評価できる第一級の軸としては扱っていない。

OpenRouterも、一般的なモデルゲートウェイより一歩進んでいる。Pareto Code Routerは外部のcoding benchmarkに合わせて品質の階層を更新し、Auto Exactoは実時間のスループット、ツール呼び出し成功率、内部評価でproviderの順序を調整する。評価と本番の信号をルーティングへ取り込めることは、すでに示した。ただ、顧客独自のコードベースやHarnessは認識していない。

第二は、評価と可観測性のプラットフォームだ。

[Braintrust](https://www.braintrust.dev/articles/best-llm-routers-2026)は、公表する位置づけの中で、Gateway、実験、本番の採点、実行trace、ルーティングを一つのワークフローに置いている。チームは実際のトラフィックでモデルを比べ、正答率、費用、遅延に応じてrouting policyを調整できる。

継続評価がルーティングを動かす仕組みにかなり近いが、公開されている製品の説明は、依然としてモデルとそのエンドポイントを軸にしている。評価結果が判断に影響することと、model × harnessの組み合わせ空間で方針を自動更新していることは同じではない。

第三は、Harnessの制御層だ。

[Omnigent](https://omnigent.ai/docs/build/harnesses)は、Claude Code、Codex、Cursor、Piなどの上に統一層を提供する。モデル、ツール、方針を変えず、設定を一行変えるだけでHarnessを切り替えられる。実行時にHarnessとモデルを別々に上書きすることもできる。複雑さに応じて高価なモデルを制限するポリシーフックがすでにあり、2026年7月のv0.5.0では、routing judgeがタスクごとにモデルを選ぶインテリジェントルーティングも加わった。

そのため、Omnigentがこの構想に最も近い。Harnessを交換、組み合わせ、管理できるようにしている。Databricksには、内部PRによる評価集合と、Unity AI Gatewayが集めた実際の呼び出しデータもある。記事の末尾でも、今後Unity AI GatewayとOmnigentのintelligent routingを紹介すると明言している。

ただし、今公開されているOmnigentの実装は、選んだHarnessの中でモデルを選ぶものだ。タスクに応じてClaude Code、Codex、PiなどのHarnessを自動で選ぶ仕組みは、公開資料には示されていない。その選択をPR benchmarkから継続更新する仕組みもまだ見えない。組み合わせ評価、Harnessの抽象化、複雑さの認識、モデルルーティング、Gatewayは存在する。しかし、企業の非公開タスクで組み合わせを評価し続け、そのままHarnessとモデルの自動選択方針に変える独立した外部向けサービスは、まだ見当たらない。

余地はある。ただし、最初に見えたより狭い。

### 本当に難しいのは評価システム

ルーティングのアルゴリズム自体が、核となる参入障壁とは限らない。難しいのは、信頼できる比較結果を継続して得ることだ。

#### 1. 評価は個別のコードベースに属する必要がある

公開benchmarkは事前の手がかりにはなるが、企業の最終判断を代行できない。

DatabricksがSWE-benchを直接使わなかったのは、公開問題が訓練データに含まれる可能性があり、Scala、Go、Rust、Java、Python、Bazel、Protobufを含む内部コードベースを代表しないからだ。最近マージされた人間のPRからタスクを取り出し、元の実装を隠し、既存のテストでAgentの結果を確かめた。

だから、価値のあるルーターは業界共通のランキングを売るだけでは足りない。各社のコード、テスト、開発規約、タスク分布について、独自の性能地図を作る必要がある。

#### 2. 組み合わせは急速に膨らむ

モデル10個、Harness5個、thinking effortが3段階あれば、それだけで150通りになる。ツール集合、コンテキスト方針、権限方針まで加えると、総当たりはすぐに不可能になる。

段階的な評価が必要だ。少数のサンプルで明らかに劣る設定を落とし、パレートフロンティア付近へ予算を集中する。新しいモデルやHarnessが出たら、少量の探索タスクで、どの能力帯に位置するかを推定する。単なるランキングより、実験計画やcontextual banditに近い。

#### 3. 複雑さはpromptに付ける一つのラベルではない

簡単に見える変更でも、コードの責任範囲、依存関係、テスト不足で高リスクになりうる。実行中にも複雑さは変わる。最初は一つのファイルだけを直すつもりでも、調べるとプロトコルの変更とデータ移行が必要だとわかることがある。

入口で一度分類するだけでは足りない。リポジトリのメタデータを読み、実行途中の設定の格上げも認める必要がある。安いモデルで探索し、モジュールをまたぐ影響が見つかったら強いモデルへ渡す。軽量なHarnessで場所を特定し、長い変更作業になれば、コンテキスト管理に適したHarnessへ切り替える。

すると、別の問題も生まれる。有効な状態を保ちつつ、古いHarnessのコンテキストの雑音まで移さずに、どう切り替えるか。

#### 4. 最適な方針には探索の費用が必要

すべての本番タスクを現在の首位へ送れば、比較データはすぐ失われる。モデルの更新、価格の変化、Harnessの改善によって、以前の結論も古くなる。

継続的なルーティングでは、少量の探索用トラフィックを残し、canaryタスクやオフライン再実行で新しい組み合わせを試す必要がある。失敗の原因も分けなければならない。モデルの能力不足、Harnessによるコンテキスト管理の失敗、ツールが使えないこと、テスト環境の不安定さは、一つの総合点に押し込めるべきではない。

定期的なbenchmarkの再実行は、継続評価の一部にすぎない。データを新鮮に保ち、失敗の原因を判断し、探索のリスクを制御することも必要だ。

### この製品の強みはどこに生まれるか

Gatewayと統一APIは同質化しやすい。長期的な価値は、むしろ三種類のデータから生まれるだろう。

第一は、企業自身のタスク分布。何が頻繁で、何に費用がかかり、どの失敗が実害を生むのか。

第二は、組み合わせ単位の実行履歴。同じモデルが、異なるHarnessを通じて、どうコンテキストを読み、ツールを呼び、tokenを使い、誤りを直すのか。

第三は、最終結果。テストは通ったか、PRは受け入れられたか、人はどれだけ直したか、公開後にロールバックしたか。

三つがつながって初めて、安いことと有効であることの本当の意味がわかる。最適化するのは、タスクが入ってから受け入れられるまでの総費用だ。API一回の価格は、その一部でしかない。

データの好循環も生まれる。長く使うほど、その会社のコードベースや開発の習慣を理解する。振り分けが正確になるほど、チームは仕事を任せたくなる。実際の結果が増えれば、さらに選択が改善する。モデルもHarnessも交換できるが、企業独自の評価資産と意思決定の履歴は、制御層に残る。

### より現実的な入り方

最初の製品で、Coding Agentのすべてのトラフィックを引き受けるべきではない。まずオフラインの意思決定システムを作るほうが堅実だ。

1. コードリポジトリと、最近マージされたPRへ接続する。
2. 検証可能な非公開のタスク集合を自動生成する。
3. 少数のmodel × harness設定を定期的に再実行する。
4. タスクの種類別に、費用と品質のフロンティアを示す。
5. まず設定を推奨し、その後、低リスクのタスクで自動振り分けを始める。
6. 実際の結果で分類器と評価集合を較正する。

これで、先に二つを確かめられる。組み合わせの間に安定した差が本当にあることと、振り分けによる節約が評価費用を上回ることだ。

成立しなければ、自動ルーティングは複雑な層を一つ増やすだけになる。成立すれば、推奨ツールから制御プレーンへ、段階的に進めればよい。

### 私の判断

この方向には実需がある。モデルが増え、Harnessの違いが費用と品質に直接影響し始めた。それでも企業は、すべてのタスクに一つの既定モデルと、一つの既定Coding Agentを設定する習慣を残している。静的な設定は計算能力を浪費し、一部のタスクを適切でない能力帯にとどめる可能性が高い。

今、完全なループに最も近いのはDatabricksだ。OmnigentはHarnessの抽象化、Unity AI Gatewayは統一入口と呼び出しデータ、社内PRは独自の評価集合を提供する。記事で予告された次の段階は、まさに評価とルーティングをつなぐことかもしれない。

独立企業の機会は、大きなモデルランキングを先に作ることではない。より価値のある位置は、ベンダー中立のAgent設定の制御層だ。各社独自のタスクを評価し続け、Harnessを振り分け可能な軸にし、品質、費用、遅延、リスクの間で、説明できる選択を行う。

機会はあるが、長く空白ではいない。Not Diamondはagentic workflowへ広がれ、Braintrustは評価とGatewayの接続を自動化でき、Databricksは内部システムを製品にできる。新しい製品は、もっと具体的な一点を早く証明する必要がある。

> 実際の企業コードベースで、設定単位のルーティングは、最強モデルと既定Harnessを固定して使うより安く、最終的な納品品質も下げない。

これを安定して証明できれば、Coding Agentの競争単位は再び上の層へ移る。モデルとHarnessはなお重要だが、最良の組み合わせを選び続けるシステムへ、より多くの価値が集まるだろう。

### 参考資料

* [Databricksの数百万行のコードベースでCoding Agentを比較する](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)
* [Omnigent：Harnesses](https://omnigent.ai/docs/build/harnesses)
* [Omnigent：組み込みポリシー](https://omnigent.ai/docs/policies/builtin)
* [Omnigent v0.5.0](https://omnigent.ai/releases/0.5.0)
* [Databricks：Unity AI Gateway](https://docs.databricks.com/aws/en/ai-gateway)
* [Not Diamond：主要な概念](https://docs.notdiamond.ai/docs/key-concepts)
* [Not Diamond：専用ルーターの訓練](https://docs.notdiamond.ai/docs/router-training-quickstart)
* [OpenRouter：Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router)
* [OpenRouter：Pareto Router](https://openrouter.ai/docs/guides/routing/routers/pareto-router)
* [OpenRouter：Auto Exacto](https://openrouter.ai/docs/guides/routing/auto-exacto)
* [Braintrust：2026年のLLMルーターとモデルルーティング基盤](https://www.braintrust.dev/articles/best-llm-routers-2026)