モデルルーティングとは？LLMのコストと品質を両立する設計・導入判断

結論：モデルルーティングは、十分な件数と品質差があるときに効く

モデルルーティングが向くのは、同じ入口に定型処理と高難度処理が混在し、モデル間の単価差が大きく、誤配分を評価できるログがあるサービスです。全件を高性能モデルで処理している大量トラフィックでは、小型モデルへ安全に移せる割合が利益になります。反対に、件数が少ない、高リスク案件だけを扱う、候補モデルの価格差が小さい場合は、ルーターの追加費用と運用負荷を回収しにくくなります。

判断指標は『小型モデルへ送れた割合』ではありません。ルーター料金、実行モデル料金、誤配分による再試行、人手確認、評価・監視を合算し、品質・安全・SLAを満たした1件当たりの総原価を、単一モデル運用と比較します。まず固定ルールと2モデルで始め、十分なラベルが集まってから学習型ルーターを検討するのが堅実です。

2026年11月2日時点で、AWS BedrockとMicrosoft Foundryにはマネージドなルーターがあり、RouteLLMやvLLM Semantic Routerは自社で制御しやすいOSSの選択肢です。ただし、独立ベンチマークでは高度なルーターが単純な単一モデル基準を安定して上回らない例も報告されています。製品名ではなく、自社タスクの分布と失敗コストで選びます。

モデルルーティングとは：Gatewayや負荷分散との違い

モデルルーティング（LLMルーティング）は、入力や実行中の状態を見て、複数のLLMから適切な実行先を選ぶ処理です。問い合わせ分類は小型モデル、複雑なコード生成は高性能モデル、個人情報を含む処理は特定リージョンのモデル、といったポリシーを1つの入口で実行します。

LLM Gatewayは認証、レート制限、請求集計、監査、プロバイダー接続をまとめる基盤です。Gatewayにルーティング機能を載せることはできますが、役割は同じではありません。単純なprovider routingやload balancingは、障害・レイテンシ・容量に応じて同等の処理先を切り替えます。モデルルーティングは、回答品質と原価が異なるモデルをタスクごとに選ぶ点が核心です。

したがって『障害時だけ別事業者へ切り替える』構成はフォールバックであり、必ずしもモデルルーティングではありません。難度や品質リスクを推定し、平常時から異なる能力・単価のモデルへ配分するとき、品質劣化を測る評価系が必要になります。

この節の一次情報：vLLM公式｜Semantic Router overview

5つの方式：固定ルールから学習型ルーターまで

最も説明しやすいのは固定ルールです。用途、入力長、顧客tier、言語、規制、tool利用の有無をif／elseで分けます。判定は速く監査しやすい一方、文章の難しさや曖昧さを捉えにくく、条件が増えると保守が難しくなります。まず固定ルールで経済性を確認し、誤配分のパターンを集める用途に向きます。

予測型は分類器や報酬モデルが『小型モデルで十分か』を推定します。RouteLLMは強いモデルと弱いモデルへの選好データからルーターを学習します。意味ベースは埋め込み、類似例、intentを使い、vLLM Semantic RouterはBERT系・decoder系分類器、semantic cache、guard、observabilityを組み合わせられます。生成型は別のLLMや判断モデルに選択させ、柔軟な代わりに追加token、遅延、同じ誤りを生むリスクがあります。

adaptive cascadeは小型モデルで先に回答し、信頼度、検証結果、tool errorなどに応じて上位モデルへ昇格します。初回の判定だけでなく実行中に切り替えられるためagentに向きますが、二重実行と長いtail latencyが発生します。実務では複数方式を重ね、規制・地域は固定ルール、難度は分類器、低信頼時はcascadeにする構成が一般的です。

この節の一次情報：UC Berkeley SkyLab｜RouteLLM ／ vLLM公式｜Semantic Router integration

料金と損益分岐：ルーター費、再試行、評価を足す

マネージド製品にはモデル料金とは別のルーター料金が発生する場合があります。AWS Bedrock Intelligent Prompt Routingは2026年11月2日時点で1,000リクエスト当たり1ドルです。AWSは品質を維持しながら最大30%のcost削減を掲げていますが、これは開発元の説明であり、自社taskに保証される削減率ではありません。Microsoft Foundry Model Routerはルーター入力と選択された基盤モデルの利用が課金対象ですが、公開料金ページの表示はregionや契約条件で確認が必要です。

損益分岐は、全件を高性能モデルへ送った費用から、ルーター導入後のモデル費、ルーター費、再試行、人手確認、評価・運用費を引いて求めます。OSSでも無料ではありません。分類器のcompute、配備、telemetry、model更新時の再評価、on-callを計上します。cache hitやbatch割引が実行先によって変わる場合は、ルーティング後の実請求で比較します。

仮に100万件、1件当たり入力1,000・出力300tokens、強いモデルを入力2ドル・出力10ドル、小型モデルを入力0.20ドル・出力0.80ドル／100万tokensとします。全件を強いモデルなら5,000ドルです。70%を小型、30%を強いモデルへ送り、ルーターが1,000件1ドルなら、モデル費1,808ドル＋ルーター費1,000ドル＝2,808ドル、名目43.8%減です。これは編集部の仮定試算で、税、cache、再試行、tool、人件費は含みません。これらを足しても差額2,192ドル以内かつ品質基準を満たすかが判断点です。

この節の一次情報：AWS公式｜Amazon Bedrock pricing ／ Microsoft公式｜Model Router pricing

AWS・Microsoft・OSSをどう選ぶか

AWS Bedrock Intelligent Prompt Routingは、同じmodel family内の候補から、予測した回答品質とrouting criteriaに基づいて選びます。managedで導入しやすい一方、任意のproviderやmodelを自由に混ぜる用途とは異なります。公式文書は英語prompt向けの最適化で、application固有のperformance dataをrouting判断へ反映できない制約も明記しています。すでにBedrockへ集約し、対応family内の英語taskでcostを下げたい組織に向きます。

Microsoft Foundry Model Routerは、OpenAI、DeepSeek、Meta、xAI、Anthropicなど複数の基盤modelを候補にし、Balanced、Cost、Qualityなどのmodeを提供します。Balancedは品質を1〜2%、Costは5〜6%の範囲で考慮すると公式文書は説明していますが、企業の主張であり自社評価が必要です。また、利用できるcontext長は候補のうち最小の上限に制約されます。既存のAzure契約・監査下で幅広いmodelを選びたい場合に検討します。

RouteLLMは強弱2modelの学習型routerを研究・実装しやすく、vLLM Semantic Routerはpolicy、classifier、cache、guard、observabilityを自社基盤へ組み込みやすいOSSです。制御性とvendor中立性は高い一方、SLA、security patch、capacity、評価を自社が負います。『managedかOSSか』はrouter単価ではなく、変更頻度、監査、運用人員、許容停止時間で決めます。

この節の一次情報：AWS公式｜Intelligent prompt routing ／ Microsoft公式｜Foundry Model Router ／ RouteLLM公式GitHub ／ vLLM Semantic Router公式GitHub

公式の削減主張と独立検証を分けて読む

RouteLLMのICLR 2025論文は、強いmodelと弱いmodelを振り分け、品質を落とさず2倍超のcost削減が可能と報告しました。project pageはMT-BenchでGPT-4性能の95%を維持しながら85%以上、MMLUで45%、GSM8Kで35%の削減を掲げています。いずれも特定のmodel組合せ、benchmark、価格を前提にした研究結果で、一般的な本番削減率ではありません。

より新しい独立benchmarkのLLMRouterBenchは、40万件、21 datasets、33 models、10 routersを評価し、model間の補完性は確認できる一方、多くのrouterは単純なbest-single-model基準を安定して上回らず、候補modelを増やす効果も逓減すると報告しています。高機能routerを導入すれば自動的にcostと品質が改善する、とは言えません。

安全性にも固有のriskがあります。EACL 2026の研究は、routerがcategoryに引きずられて不適切なmodelを選び、弱いmodelへ送ることでjailbreak耐性が下がる例を示しました。医療、金融、個人情報、外部操作では、安いmodelへ送ってはいけないhard ruleを学習型判定より先に置き、router自体を攻撃対象として監視します。

この節の一次情報：ICLR 2025｜RouteLLM ／ ACL 2026 Findings｜LLMRouterBench ／ EACL 2026｜How Robust Are Router-LLMs?

導入に向くケース・向かないケース

向く例は、customer supportの一次分類、document抽出、社内search、code agentなど、件数が多く難度に幅がある処理です。問い合わせの大半を小型modelで処理し、返金、法務、高額契約、低信頼だけを高性能modelや人へ送れます。agentでは、検索・要約は小型model、最終計画と外部操作は高性能modelに分けます。

向かないのは、全件が高リスクで同じ品質水準を求める処理、低頻度でrouter運用費を回収できない処理、正解やtask successを測れない処理です。候補modelのoutput形式やtool calling互換性が違い、切替のたびにadapterと再評価が必要な場合も、単一modelの方が総原価を抑えやすくなります。

長時間agentはprompt一発のroutingだけでは評価できません。途中でtask状態が変わり、各stepの安い選択が最終成功率や再試行を悪化させるためです。stepごとのmodel費に加え、end-to-endの完了率、総API spend、完了時間、人手介入を測ります。

• 向く：大量・反復・難度差あり・正解ラベルあり・安全な昇格経路あり
• 条件付き：agent、multilingual、複数provider。end-to-end評価と互換性確認が必要
• 向かない：少量・全件高リスク・評価不能・model差が小さい・運用担当なし

この節の一次情報：arXiv｜TwinRouterBench

導入手順：2モデル、shadow評価、段階配信で始める

第1段階は、現在の単一modelをbaselineにし、task IDごとに入力属性、model、token、latency、retry、最終結果、人手時間を記録します。成功条件はaccuracyだけでなく、業務完了、重大誤り、p95・p99、cost per successful taskで定義します。過去logを難度・risk・顧客tierで分け、安いmodelでも合格する範囲を探します。

第2段階は、候補を2modelに限定して固定ruleをshadow実行します。実trafficの実行先は変えず、routerの提案と両modelの結果を保存し、false downgrade、つまり上位modelが必要なのに小型modelを選んだ割合を測ります。高risk categoryはhard ruleで上位modelへ固定し、学習型routerのthresholdより優先します。

第3段階は低risk・低割合のcanaryです。予算上限、timeout、circuit breaker、上位modelへのfallback、router停止時のdefaultを用意します。導入後もmodel version、価格、traffic分布が変わるたびに再評価します。routerの精度だけでなく、選択比率の急変、再試行率、safety violation、provider別の請求差をalertにします。

導入前チェックリスト

契約と仕様では、候補model、region、data retention、routerが入力を保存・学習へ使うか、障害時のfallback先、context上限、tool・JSON・visionの互換性を確認します。Microsoft Foundryのように候補modelの最小contextがrouter全体の上限へ影響する製品もあります。modelごとのSLAや予約容量がrouter経由でも有効かを契約で確かめます。

評価では、平均accuracyだけでなくcategory別のfalse downgrade、重大誤り、confidence calibration、p50・p95・p99、timeout、再試行、人手介入を確認します。費用は通常入力、cached input、出力、tool、router、egress、observability、評価、人件費へ分解し、請求明細と同じ粒度で追跡します。

運用では、model廃止や価格改定時の再学習、policy変更の承認、router versionと実行先のaudit log、緊急停止、単一modelへの切り戻しを準備します。routerが選んだ理由を完全に説明できない場合でも、入力特徴、score、threshold、候補、最終選択、fallback履歴を残せば事故調査が可能になります。

• 契約：region、保持、学習利用、SLA、予約容量、障害時のfallback
• 互換性：context、JSON、tool calling、vision、streaming、safety policy
• 評価：category別品質、false downgrade、p99、retry、人手介入
• cost：router、model、cache、tool、通信、監視、評価、運用人件費
• 運用：version固定、audit log、drift検知、kill switch、再評価日

FAQ：モデルルーティングのよくある質問

Q. LLM Gatewayを入れればモデルルーティングもできますか？ A. Gatewayにruleやpluginで実装できる場合はありますが、認証・quota・接続管理だけでは品質を見たroutingになりません。評価data、threshold、昇格経路を別に設計します。

Q. 何モデルから始めるべきですか？ A. 安い小型modelとbaselineの高性能modelの2つが基本です。候補を増やすほど評価組合せ、context・tool互換性、障害時の挙動が増えます。独立benchmarkでも候補数の効果は逓減しています。

Q. routerの正解率は何%なら導入できますか？ A. 一律の値はありません。低risk分類の誤配分と、法務・安全・外部操作の誤配分では損失が違います。category別のfalse downgradeと期待損失でthresholdを決めます。

Q. prompt cacheと併用できますか？ A. できますが、modelやproviderを跨ぐとcacheを共有できない場合があります。routingでhit率が下がる影響も含め、経路ごとの実請求を測ります。

Q. routerを別のLLMにすると高くなりませんか？ A. 追加tokenとlatencyが発生します。固定rule、小型classifier、embeddingで十分かを先に比較し、生成型routerは複雑なpolicyで差額を回収できる場合に限ります。