# 動的モデル選択の設計——3種のルーティングパターンと実装指針

> エージェント基盤でタスク複雑度・レイテンシ・コストを実行時シグナルに最適LLMを自動選択するルーター設計。カスケード・分類器・多腕バンディットの3パターンと品質ゲートの組み込み方を示す。

- Canonical: https://kuucorp.com/blog/model-routing-dynamic-selection-design/
- Date: 2026-07-20
- Last modified: 2026-07-20
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
AIエージェントは1回のユーザーリクエストで計画・ツール選択・実行・検証・応答生成と複数のLLM呼び出しを行う。この多段呼び出しをすべて最上位モデルに流すと、単純なタスクでもAPI費用が急増する。「全量を同じモデルに流す」設計はシンプルだが本番スケールに耐えない。

では逆に最安モデルに固定するか。それでは複雑な推論ステップで品質が崩壊する。ルーターの役割は「どの呼び出しをどのモデルで処理すれば品質が維持できるか」を実行時に判断することだ。

## ルーティングが必要な理由——コスト削減は副産物にすぎない

> RouteLLMはリクエストの14%のみ上位モデルに転送してGPT-4品質の95%を維持した実績があります。

コスト最適化を主目的に設計すると品質との緊張関係を見誤る。ルーティングの本質は品質・レイテンシ・コストの三点トレードオフを実行時に最適化することだ。

経済的な根拠も示しておく。Claude APIではモデルによって入力トークン単価が大きく異なる。トラフィックの70%を軽量モデル、30%を上位モデルに振り分けるだけで入力トークンコストは全量上位モデル比で約67%削減できる計算になる（digitalapplied.com, 2026）。ただし「コストが下がった」だけを成功指標にすると品質劣化を見落とす。品質ゲートの組み込みが設計の必須要件だ。

ゲートウェイ層との責任分離については [LLMゲートウェイ設計](/blog/llm-gateway-routing-rate-limiting/) も参照されたい。アプリケーション層のルーターとゲートウェイ層のルーティング設定は補完関係にあり、両者を混在させると運用が複雑になる。

## 設計の3軸——いつ・何を使って・どう判断するか

> ルーティングの設計空間は「いつ判断するか」「何のシグナルを使うか」「どのアルゴリズムで選ぶか」の3軸で整理できます。

2026年のアーキテクチャ調査（arXiv 2603.04445）はこの3軸でルーティング設計の全体像を体系化している。

**タイミング（when）**には3種類ある。リクエスト受信直後に決定するpre-generationは最低オーバーヘッドで決定できる。初回応答後に品質評価して再試行を決めるpost-generationは精度が高いが追加レイテンシが生じる。複数ステージで順次エスカレーションするmulti-stageはその中間に位置する。

**シグナル（what）**はクエリ特性（テキスト構造・意味的複雑度）、モデルメタデータ（単価・レイテンシ・可用性）、応答レベルの信頼度スコア、そして過去の品質フィードバックの4種が主要ソースだ。エージェント基盤では直前ステップの出力品質スコアもシグナルに加えられる。

**アルゴリズム（how）**はヒューリスティック（ルールベース）から教師あり分類器・バンディット・強化学習まで幅がある。次のH2で3パターンに絞って実装を整理する。

## 3種の実装パターン——カスケード・分類器・バンディット

> 動的モデル選択の3パターンはカスケード・分類器・バンディットで、各パターンの精度と実装コストが異なります。

### パターン1：信頼度ベース・カスケード

軽量モデルを先に実行し、応答の確率分布エントロピーが閾値を超えた場合のみ上位モデルにエスカレーションする手法だ。追加の分類器モデルを必要とせず実装コストが最も低い。

```python
def cascade_route(prompt: str) -> str:
    response = haiku.complete(prompt)
    confidence = 1 - entropy(response.token_probs)
    if confidence < THRESHOLD:  # e.g. 0.85
        return opus.complete(prompt)
    return response.text
```

欠点は軽量モデルが「自信満々に誤った回答」を返すケースを見逃す点だ。ハルシネーションが低エントロピー（高信頼）のまま出力される場合があるため、ドメイン知識が求められる呼び出しには単独では使えない。エスカレーション率を継続モニタリングする仕組みが必須だ（[エージェントの可観測性設計](/blog/agent-observability-tracing-instrumentation/)を参照）。

### パターン2：事前分類器ルーティング

リクエストの特性（長さ・キーワード・埋め込みの複雑度）を事前に分類し、モデルを割り当てる。RouteLLMのmatrix-factorizationアプローチやDeBERTaベースの分類器がこのパターンに該当する。

判断オーバーヘッドはルールベース（<1ms）〜MLモデル（50〜100ms）の幅があり（digitalapplied.com, 2026）、頻繁に呼び出されるステップには埋め込みベース（〜5ms）が現実的な選択肢だ。

デメリットは分類器の鮮度管理にある。「以前は複雑に分類されていたタスクが最新モデルでは単純化された」場合、分類器の再訓練が必要だ。分類精度の定期評価ループを運用に組み込む。

### パターン3：文脈バンディット（オンライン学習）

LinUCBなどの文脈バンディットアルゴリズムを使い、過去のルーティング結果（品質スコア・フィードバック）から継続的に選択ポリシーを更新する。MixLLMはこのアプローチでGPT-4品質の97%を24%コストで達成している（arXiv 2603.04445）。

探索・活用のバランスが設計の核心だ。UCBスコアにコストペナルティ項を加えることで、品質を維持しながら安価モデルへの活用（exploit）を制御できる。コールドスタート問題があるため、初期はヒューリスティックルールから始めてデータを蓄積した後、段階的に移行する設計が安全だ。

## 品質ゲートの設計——サイレント劣化をどう防ぐか

> 品質劣化はコスト削減の数日後に顕在化します。CI/CDに50件以上の評価ゲートを組み込みスコア低下でブロックします。

コスト削減の効果は即日のダッシュボードに現れるが、品質劣化はサポートチケットの増加として数日後に可視化される。この時間差が「設計は成功した」と誤認させる主な原因だ。

評価ゲートの構成要素として3点を組み込む。

1. **グラウンドネス検証**: 軽量モデルへの振り分け後も事実性が維持されているかをLLM-as-judgeで採点する
2. **レイテンシSLO監視**: カスケードによる追加レイテンシがp99 SLOを超えていないかを計測する
3. **エスカレーション率のトラッキング**: 想定外にエスカレーション率が高い場合は分類器再調整のシグナルだ

ルーティング変更を本番に出す前に、代表ケース50〜500件でグラウンドネスと品質スコアを検証するCI/CDゲートを設ける。スコアが閾値を下回れば自動的にデプロイをブロックする設計が「サイレント劣化」を防ぐ最低限の安全ネットになる（digitalapplied.com, 2026）。

## 規模別の留意点（SMB / エンタープライズ）

**SMB**: まずLiteLLMのフォールバックリストでルールベースルーティングを実装し、エスカレーションログを記録するところから始める。コスト可視化が先であり、分類器やバンディットは後からの拡張で十分だ。Kuuの[AIエージェント運用サービス](/services/ai-ops/)ではルーター導入から品質ゲートの設計まで支援している。

**エンタープライズ**: 複数チームが同一ゲートウェイを共有する環境では、チーム別のルーティングポリシーとコスト配賦を組み合わせる必要がある。アプリケーション層のルーターとゲートウェイ層の責任を明確に分離し、大規模展開にはKuuの[RDEサービス](/services/rde/)でアーキテクチャ統合を支援する。

## 参考

- [Dynamic Model Routing and Cascading for Efficient LLM Inference: A Survey（arXiv 2603.04445）](https://arxiv.org/html/2603.04445v2)
- [LLM Model Routing in 2026: Cost-Quality Optimization Engineering Guide（Digital Applied）](https://www.digitalapplied.com/blog/llm-model-routing-2026-cost-quality-optimization-engineering-guide)
- [Latency-Quality Routing for Functionally Equivalent Tools in LLM Agents（arXiv 2605.14241）](https://arxiv.org/pdf/2605.14241)

## まとめ

動的モデル選択は「安いモデルへの誘導」ではなく、品質・レイテンシ・コストの三点を実行時に最適化する設計問題だ。出発点はカスケードが最もシンプルで、品質ゲートと可観測性が確立した後に分類器やバンディットへ段階的に移行する。コスト削減の数値を先に出す前に品質評価の基盤を整えることが、本番運用を安定させる鉄則だ。

エージェント基盤の動的モデル選択設計についてご相談は[Kuuのお問い合わせ](/contact/)から。