すべての依頼を最も強く高価なAIモデルへ送れば品質は安定して見えます。しかし分類、形式変換、短い抽出まで同じ遅延と費用を払うことになります。逆に全件を安価なモデルへ移すと、難しい推論や例外で再試行が増え、節約分が消える可能性があります。
モデルルーティングは、依頼の種類・難易度・リスクを判定して適切なモデルを選び、品質ゲートに失敗した時だけ強いモデルへ昇格する設計です。目標は最初の呼び出しを最安にすることではなく、成功した作業1件の総費用を下げることです。
1. ルーティングは順位表ではなく判断規則
Anthropicは、入力を明確なカテゴリへ分類できる場合にルーティングが有効で、簡単で一般的な依頼を小型モデルへ、難しい例外を高性能モデルへ送る例を示しています。Google Researchの言語モデルカスケードも、小型モデルが容易な依頼を処理し、不確かな依頼だけを大型モデルへ委ねる構造です。
ただし自動的に成功する技術ではありません。2026年のLLMRouterBenchプレプリントは、40万件超、21データセット、33モデルを統合評価し、複数の高度なルーターが単純な基準を安定して上回らないと報告しました。一方、良い構成では最良単一モデルと同等の性能で最大31.7%の費用削減、または平均精度を最大4%高めた結果もあります。いずれも著者報告値であり、実際の業務で再検証が必要です。
2. モデルより先に作業階層を定義する
モデル名から規則を作ると、新モデルのたびに書き換えが必要です。先に持続的な作業階層を定義し、現在のモデルを割り当てます。
| 階層 | 代表的な作業 | 基本処理 | 昇格条件 |
|---|---|---|---|
| 高速経路 | 分類、抽出、形式変換 | 小型・低コスト | スキーマ失敗、低確信 |
| 標準経路 | 要約、下書き、一般質問 | 中位モデル | 根拠不足、評価未達 |
| 専門経路 | 複雑な推論、コード変更 | 高性能モデル | 高リスクなら人が確認 |
| 制限経路 | 決済、法務・医療判断 | 自動実行しない | 明示的な人の承認 |
文章の長さだけでは足りません。メール件名の分類と返金確定はどちらも短文ですが、失敗の影響が違います。作業種類、リスク、必要ツール、個人情報の有無もルーターへ渡します。
3. 最初は規則ベースのカスケードにする
初日からニューラルルーターを学習する必要はありません。LLMRouterBenchは、候補を無制限に増やすより、よく選んだ小さなモデル集合が重要で、高度な方式同士の差も限定的な場合があると示します。業務規則が明確なら、決定的なゲートと軽量分類器の組み合わせが監査しやすいでしょう。
1. 個人情報・金銭・法的判断・削除か → 制限経路 + 人の承認
2. 固定スキーマの分類・抽出か → 高速モデル
3. 長文脈・多段推論・コード実行が必要か → 専門モデル
4. その他 → 標準モデル
5. 出力検査失敗または低確信 → 1段階昇格
6. 専門モデルも失敗 → 停止し根拠と共に人へ渡す入力分類だけで終わらせず、JSONスキーマ、引用、テスト、禁止規則、事実整合性を第二の信号にします。安価に始めても失敗を早期検出できれば、工程全体の再実行を減らせます。
4. 作業当たり費用で本当の差を見る
AIZIGOO最新AIモデル比較で使ったArtificial Analysisの2026年9月11日スナップショットでは、ベンチマーク作業当たり費用はGPT‑5.6 Lunaが$0.18、Muse Spark 1.3が$1.60、GPT‑6 Astraが$3.26です。これは単純なAPIトークン定価ではなく、その評価を実行した費用です。
例として1,000件すべてをAstraで処理すると$3,260です。60%をLuna、30%をMuse Spark、10%をAstraへ送ると$108 + $480 + $326 = $914です。約72%低いものの、全経路の成功率が同じという非現実的な仮定による説明であり、実運用の予測ではありません。
次の式で比較します。
成功1件当たり費用 =
(初回呼び出し + ルーター + 検査 + 再試行 + 昇格) ÷ 最終成功件数ルーター呼び出しと再試行を除外すると、安く見える構成が実際には高くなります。キャッシュ、入力長、ツール呼び出し、遅延、人の確認時間も記録します。
5. 曖昧さを一つの確信度へ縮めない
生成モデルの確信度は万能な難易度計ではありません。Googleのカスケード研究は、長さが変わる生成でトークン確率を一値に集約しても全作業に通用する保留規則にならないと説明します。複数の信号を組み合わせます。
- 入力：作業種類、長さ、言語、添付、必要ツール
- リスク：個人情報、外部送信、決済、削除、規制判断
- 難易度：多段推論、複数資料の照合、コード実行、希少領域
- 出力：スキーマ、テスト、引用、禁止規則、事実整合性
- 運用：残り予算、遅延上限、障害、処理速度
希少で重要な依頼は見落とされやすい点に注意します。LLMRouterBenchは、正答モデルが3個以下だった難しい一部の質問で、代表的ルーターの選択精度が約23～25%だったと報告します。高リスク依頼は確信度が高くても安価な経路へ自動降格しない安全規則が必要です。
6. オフライン評価後に少量の実トラフィックで確認する
過去依頼から個人情報を除き、正解または合格基準を付けます。通常、境界、高リスク、希少ケースを分け、既存の単一モデルと候補ポリシーを同じ集合で実行します。
| 指標 | 確認すること | 失敗信号 |
|---|---|---|
| 最終合格率 | 検査とレビューを通過したか | 単一モデルより低下 |
| 成功当たり費用 | 再試行を含む総額 | 呼び出しは安いが総額上昇 |
| 過少昇格 | 難しい作業を弱いモデルへ送ったか | 重大エラーと再作業増加 |
| 過大昇格 | 簡単な作業を高価なモデルへ送ったか | 節約効果が消える |
| P95遅延 | 遅い5%の体験 | 昇格連鎖で急増 |
| 安全回避 | 制限作業が自動実行されたか | 1件でも発生 |
最初はシャドー評価または少量の読み取り専用トラフィックへ適用し、選択と実結果を記録します。品質下限を先に決め、その範囲で最も安いポリシーを選びます。
7. よくある四つの失敗
- モデルが多すぎる。 補完性は増えても希少な強みを呼び出せず、運用が複雑になります。
- 精度だけを見る。 同じ精度でも遅延、費用、ツール安定性、個人情報条件が違います。
- ルーターが自己採点する。 分類と検証に同じ誤りが出るため、決定的検査か別評価器を使います。
- 価格変化を無視する。 バージョン、価格、遅延が変われば昨日のパレート最適は維持されません。
配備前チェックリスト
- [ ] 高速・標準・専門・制限の定義がモデル名から独立している
- [ ] 重大な依頼では費用より人の承認を優先する
- [ ] 検査失敗時に昇格し、無限再試行しない
- [ ] 同じ評価集合で単一モデル基準と比較した
- [ ] ルーターと再試行を含む成功当たり費用を計算した
- [ ] 過少・過大昇格率とP95遅延を監視する
- [ ] モデルと価格の版を記録し再評価できる
結論：最良モデルより最良の配分
ルーティングは弱いモデルですべてを安く済ませる方法ではありません。簡単な作業を速く終え、難しい作業へ計算を集中し、重大な作業を人へ戻す配分規則です。
二、三モデルと透明な規則から始めます。単一モデル基準を上回れなければ、学習型ルーターを足す前に失敗集合と昇格条件を直します。費用削減は品質下限と安全ゲートを守った結果でなければなりません。
主な資料
- Anthropic: Building effective agents
- Google Research: Language Model Cascades
- LLMRouterBench — プレプリント
- LLMRouter / xRouteBench — プレプリント
- Artificial Analysis model leaderboard
ベンチマークと費用は条件と時点で変わります。導入前に自社依頼と最新価格で再評価してください。