LLMルーティングとは？振り分けの評価と運用

2026年9月、​「依頼ごとに​使う​モデルを​変える」​発表が​続いた。​11日に​Sakana AIが​「Fugu Max」を​公開し、​14日には​GitHub Copilotの​自動モデル選択に​コストと​品質の​優先度の​設定が​入った。​15日に​TypeSafe AIが​判断特化モデル​「Jev」を​発表し、​25日には​LLM Gatewayが​Jevを​難易度の​判定に​使える​「Smart Routing」を​ベータで​公開した。

どれも​LLMルーティング​（モデルルーティング）である。​簡単な​依頼は​軽い​モデルへ、​難しい​依頼は​上位モデルへ。​製品は​揃ってきたが、​難しいのは​入れた​後に得をしているかを確かめることである。

• ルーターは、品質の低下とコストの削減を交換する仕組みである。​両方を​同じ​評価セットで​測らないと​判断できない
• 公開値は​条件付きで​読む。​LLM Gatewayの​試験の​「33.2%削減」は​信頼区間が​削減ゼロを​含み、​RouteLLMの​「85%以上の​削減」は​MT Benchでの​数字である
• 導入後は、​モデルの​更新・廃止、​キャッシュ、​フォールバックが​前提を​崩す。再評価の引き金を先に決めておく

本記事は​範囲を​クラウドAPI間の​振り分け​（複数社の​モデル間、​または​同一社の​上位モデルと​軽量モデルの​間）に​絞り、​判定方​式の​選び方、​評価方​法、​導入後の​運用を、​公式ドキュメントと​論文を​一次​資料と​して​整理する。​ローカルLLMと​クラウドAPIの​振り分けはローカルLLM比較2026で、​振り分け以外の​節約策はLLMトークン節約5パターンで、​各モデルの​料金はLLM APIの​比較と​料金で扱っている。

この​​記事の​​対象読者

• 複数の​LLM APIを​業務に​組み込み、​上位モデルの​費用が​膨らんでいる​開発責任者
• ゲートウェイ製品や​クラウドの​モデルルーターを​検討している​実装担当者
• 自動モデル選択を​社内に​展開する​前に、​品質の​責任の​持ち方を​決めたい情報システム部​門
• 振り分け導入後の​監視と​見直しの​体制を​設計したい​AI推進担当者

LLMルーティングとは​​（要点3行）

1. LLMルーティングとは、​依頼ごとにどのモデルに処理させるかを自動で選ぶ仕組みで、​判定を​担う​部品を​LLMルーター​（モデルルーター）と​呼ぶ
2. 目的は、​軽量モデルで​足りる​依頼を​上位モデルから​外し、品質の低下を許容範囲に収めたまま費用と​待ち時間を​下げる​ことである
3. 効果は​業務と​候補モデルで​大きく​変わる。自社の依頼で測り、モデルが変わるたびに測り直す運用が​前提に​なる

2026年9月に​​続いた​​発表

各社の​公式発表​（2026年9月29日確認）を​並べると、​振り分けの​単位と、​利用者が​決められる​ことが​製品ごとに​違う。

クラウド各社にも​同種の​機能が​ある。​Microsoft Foundryの​「model router」は、​Balanced​（既定）では​最高品質の​モデルとの​差が​1〜2%程度の​範囲から​最も​費用対効果の​高い​モデルを​選び、​Costでは​その​範囲を​5〜6%程度に​広げると​説明している。​Amazon Bedrockの​「Intelligent Prompt Routing」は、​同じ​モデルファミリー内の​2モデル間で​応答品質の​予測に​基づいて​振り分ける。

振り分けの判断は、アプリケーションの外側へ移りつつある。 それでも​品質を​確かめる​責任は​利用者に​残る。​Bedrockの​ドキュメントは、​英語の​プロンプトに​最適化されている​ことを​制約と​して​明記している。

判定方​​式を​​どう​​選ぶか

ルールベース・​小型分類モデル・ゲートウェイ製品と​いう​実装手段の​比較は、​ローカルと​クラウドの​振り分けと​して記事22で​扱った。​クラウドAPI間の​振り分けでは、​手段より​先に​「いつ判定するか」と​「誰が​判定を​持つか」を​決める​ほうが、​後の​評価と​運用を​左右する。

事前振り分け・カスケード・製品任せ

カスケードは、​FrugalGPT​（Chen, Zaharia, Zou, 2023）が​費用削減の​方法の​1つと​して​整理した​考え方である。​両者は​排他ではなく、​明らかに​簡単な​依頼だけ事前に​軽量モデルへ​送り、​残りを​カスケードで​扱う​組み合わせも​ある。

判定の​材料は、​依頼元の​システムや​業務の​種別のように​ルールで​取れる​ものから​使い、​決まらない​残りだけを​分類器に​判定させる。​Jevのような​判断特化モデルを​判定器に​使う​設計はJevの記事で扱っている。

判断基準と​​確認方​​法

振り分けの​​評価方​​法

見る​べきは​ルーター単体の​正解率ではなく、業務全体の品質とコストがどう動いたかである。

測るのは​​3つの​​数字

拡大 ⤢

1. 誤振り分け率。 軽量モデルへ​送ったが​上位モデルが​必要だった​「過小振り分け」と、​上位モデルへ​送ったが​軽量で​足りた​「過大振り分け」の​2種類が​ある。​前者は​品質を​落とし、​後者は​費用を​無駄に​する。​1つの​正解率に​まとめると​相殺されて​見えなくなる​ため、​別々に​測る。​過小振り分けは​利用者から​見えに​くいので、​業務の​リスクに​応じて​上限を​先に​決める。

2. コスト削減率。 上位モデル固定と、​中位または​軽量モデル固定の​両方と​比べる。​上位固定とだけ​比べると、​ほとんどの​ルーターは​得に​見える。​費用には​判定器の​呼び出し代と​カスケードの​やり直し分も​含める。

3. 品質低下。 業務カテゴリ別に​測る。​Microsoft Foundryの​評価ガイドも、​全体の​集計が​特定カテゴリの​劣化を​隠し、​平均の​応答時間が​遅い​依頼を​隠すと​注意を​促している。

公開ベンチマークの​​数字を​​どう​​読むか

研究で​よく​引かれるのは、​LMSYSの​RouteLLM​（2024年）である。​公式ブログは、​GPT-4 Turboを​強い​モデル、​Mixtral 8x7Bを​弱い​モデルとし、​Chatbot Arenaの​人に​よる​比較データなどで​学習した​ルーターが、​GPT-4の​95%の​性能を​保ちつつ、​GPT-4だけを​使う​場合より​MT Benchで​85%以上、​MMLUで​45%、​GSM8Kで​35%費用を​削減したと​報告している。同じ研究でも、ベンチマークが変わると削減率が大きく変わる。

製品側では、​LLM Gatewayが​2026年9月26日に、​Smart Routingの​小規模な​試験を​条件ごと​公開している。​80問​（簡単な​作業25問、​正解が​1つに​決まる​推論15問、​指示追従の​評価データIFEvalから​40問）を​4つの​構成で​比べた​主試験の​結果は​次の​とおりである。

上位固定より​33.2%安いが、​95%信頼区間は​「4.3%高い〜66.1%安い」で​削減ゼロを​含む。​中価格モデル固定の​3.69倍、​低価格モデル固定の​35.57倍の​費用が​かかっている。​上位固定の​不合格は​採点の​あいまいさ​（末尾の​句読点の​扱いなど）に​よると​同社は​説明しており、​あいまいな​問題を​除くと​上位固定は​79問すべて、​Smart Routingは​75問に​合格した。​p95の​応答時間は​Smart Routingが​66.57秒、​上位固定が​41.09秒である。

同社​自身、​1ターン・テキストのみの​小さな​合成ワークロードで、​「同じ​品質で​より​安い」とは​言えないと​明記している。価値は、測り方を公開した点にある。 安い​固定モデルとも​比べ、​区間で​示し、​失敗した​呼び出しも​残す。​自社で​評価する​ときの​型に​なる。

正解ラベルは​​「両方に​​答えさせて」作る

誤振り分け率を​測るには、​依頼ごとに​「軽量モデルで​足りたか」の​正解が​要る。​同じ​依頼を​軽量モデルと​上位モデルの​両方に​投げて​採点し、​軽量が​合格なら​「軽量で​足りた」、​軽量が​不合格で​上位が​合格なら​「上位が​必要だった」と​する。

採点は​正解との​照合や​スキーマ検査を​優先し、​文章の​質を​見る​場合だけLLMの​採点者を​使う。​採点者の​条件と​評価セットの​育て方はAIエージェントの​Eval設計で扱っている。

シャドーモードで​​本番に​​影響させずに​​測る

拡大 ⤢

本番の​応答は​現行の​モデルのまま​返し、​ルーターには​判定だけを​させて​記録する。​これが​シャドーモードである。​ためた​判定を​上の​方法で​付けた​正解と​突き合わせれば、​利用者に​影響を​出さずに​誤振り分け率と​コスト削減率を​見積もれる。

合格ラインは​結果を​見る​前に​業務カテゴリごとに​決める。​Foundryの​ガイドも、​量の​多い​分類業務なら​小さな​品質差を​許容し、​影響の​大きい推奨を​出す業務では​同等以上の​品質を​求める、と​基準を​変えるよう​書いている。​切り​替えは​合格した​カテゴリから、​依頼の​一部に​限って​始める。

導入後の​運用

モデル更新の​​たびに​​測り直す

ルーターの​評価は、​候補モデルが​変われば​無効に​なる。​そして​候補は​利用者の​意図と​関係なく​変わる。

• Microsoft Foundryの​model routerは、​最新版が​同じ​版番号のまま​新しい​モデルを​追加する。​自動更新を​選ぶと​モデル集合が​変わり、​性能と​費用に​影響しうると​公式が​書いている
• Anthropicは、​公開済みモデルの​提供終了の​少なくとも​60日前に​通知し、​置き換え先で​十分前に​テストするよう​勧めている

再評価の​引き金は、​候補モデルの​追加・廃止・版の​更新、​マネージドルーターの​版の​更新、​業務カテゴリの​構成比の​変化、​料金改定の​4つを​基本に​する。​評価セットを​固定しておけば、​同じ​手順を​回すだけで​済む。​評価を​仕組みに​組み込む​考え方はハーネスエンジニアリングで​整理している。

フォールバックは​​振り分けと​​別に​​設計する

• 再試行の対象を絞る。 LLM Gatewayの​現行ドキュメント​（2026年9月29日確認）は、​5xx・タイムアウト・接続失敗・上流の​レート制限に​加え、​提供元の​認証や​残高、​モデルの​対応に​起因する​401・402・403・404・405と​一部の​400を、​別の​提供元での​再試行の​対象と​している。​一方、​検証エラーのように​依頼その​ものが​不正な​4xxと​コンテンツフィルタは​再試行しない。​セッションIDで​提供元を​固定している​間は、​別の​提供元への​自動再試行が​無効に​なる
• 許可外のモデルに逃がさない。 LLM Gatewayの​Smart Routingは、​候補の​どれも​処理できない​依頼には​許可外の​モデルへ​退避せず400を​返す。​Foundryも、​指定した​モデルの​集合が​退避先を​兼ねる​ため、​2モデル以上を​選ぶよう​勧めている
• 判定器が失敗したときの行き先を決める。 Smart Routingの​分類器は、​タイムアウトや​エラーの​ときは​設定した​退避モデルへ、​未設定なら​候補の​うち最も​安い​適格モデルへ​依頼を​送る。​難しい​依頼が​軽量モデルへ​流れうるので、​退避モデルを​明示的に​設定し、​判定器の​失敗件数を​監視する
• モデルごとの仕様差を吸収する。 Anthropicの​ドキュメントは、​Claude Opus 4.7以降で​temperatureなどを​既定値以外に​設定すると​400エラーを​返すと​明記している。​モデルごとに​リクエストを​組み直す層が​要る
• 退避で費用が跳ねることを想定する。 軽量モデルの​障害時に​上位へ​退避すると、​その間は​上位固定と​同じ​費用に​なる。​予算上限は記事21で扱っている

プロンプトキャッシュと​​ぶつかる

プロンプトキャッシュは​モデルごとに​効く。​会話の​途中で​モデルを​切り​替えると​キャッシュを​捨て、​振り分けで​下げた​費用が​戻ってしまう。​各社も​これを​前提に​している。​Copilotの​自動選択は​キャッシュの​自然な​区切りで​振り分けを​判断し、​LLM Gatewayの​Smart Routingは、​プロジェクトで​セッション単位の​振り分けを​有効に​している​場合に​限り、​セッションIDの​付いた​依頼を​最初の​ターンで​判定し、​以降は​判定結果を​使い回す。​ただし現行ドキュメント​（2026年9月29日確認）に​よれば、​提供元の​プロンプトキャッシュが​期限切れに​なった​ときと​4ターンごとに​再確認し、​難しくなった​作業は​すぐ​上位の​モデルへ、​易しくなった​作業は​残りの​セッションで​見込める​節約が​留まる​費用を​十分上回る​ときだけ移す。​セッション単位でも​モデルは​切り​替わりうるので、​費用は​キャッシュの​期限切れと​切り​替えを​含めて​見積もる。​Foundryの​同じ​モデルを​使い続ける​設定は、​ベストエフォートで​キャッシュの​ヒットを​保証しないと​明記されている。​エージェントや​長い​対話では、判定の単位をセッションにするのが​基本に​なる。​コスト削減率も、​キャッシュの​割引を​含めた​実際の​請求額で​測る。

監視する​指標

依頼ごとに​処理した​モデルを​必ず​ログに​残す。​Foundryは​応答の​ model と routing_trace、​LLM Gatewayは​レスポンスヘッダーで​確認できる。​そのうえで​次の​指標を​見る​（編集部の​設計例）。

FDXの​支援

FDXは​AX​（AI Transformation）の​実装パートナーと​して、​業務の​分解から​実装・現場定着・運用移管までを​対応領域と​する。

LLMルーティングの​成否は、​製品選びより、依頼を業務カテゴリに分け、合格ラインを決め、同じ評価セットで測り続けられるかで​決まる。​業務と​評価の​設計の​問題である。

AX Factoryでは、​評価セットの​設計から​シャドーモードでの​計測、​ゲートウェイを​使った​実装、​監視までを​支援する。​どの​業務から​検討すべきかは、​業務と​タスクを​棚卸しするFDX Expertの​AIアセスメントが​入口に​なる。​FDXが​支援した​ECの​問い​合わせAI化では、​月1,200件の​うち約83%を​AIが​回答しており​（導入事例）、​定型の​依頼が​多い​業務の​構成は​振り分けを​考える​出発点に​なる。

まず​現状を​把握したい​場合はAX診断から、​具体的な​相談はお問い合わせからどうぞ。

よく​​ある​​質問​（FAQ）

Q1. LLMルーティングと​​LLMゲートウェイは​​同じ​​ものか？

A. 同じではない。​LLMゲートウェイは​複数の​LLM APIへの​接続を​1か所に​まとめる​中継の​層で、​認証や​ログ、​再試行を​担う。​LLMルーティングは​依頼ごとに​モデルを​選ぶ機能で、​ゲートウェイの​一機能と​して​提供される​ことが​多い。

Q2. ルーターを​​入れると​​どの​​くらい​​安くなるのか？

A. 業務の​構成と​候補モデルの​組み合わせで​大きく​変わる​ため、​一般的な​数字は​言えない。​研究の​RouteLLMでも、​削減率は​MT Benchで​85%以上、​GSM8Kで​35%と​開きが​ある。​自社の​依頼で​シャドーモードの​計測を​してから​見積もるのが​確実である。

Q3. 全部を​​上位モデルで​​処理すれば​​よいのではないか？

A. 依頼が​少ない、​または​誤りの​影響が​大きい​業務では、​それが​正しい​判断に​なりうる。​ルーターは​品質と​コストを​交換する​仕組みで、​評価と​監視の​手間も​増える。​LLM Gatewayの​試験でも​中価格モデル固定がはるかに​安く​合格数も​同程度だったように、​まず固定モデルの​見直しで​足りないかを​確かめる​価値が​ある。

Q4. マネージドルーターを​​使えば​​評価は​​不要か？

A. 不要には​ならない。​Microsoft Foundryの​ドキュメント自身が、​現在の​構成と​比べて​自社の​ワークロードで​効果を​確かめるよう​求めている。​製品が​判定を​担っても、​品質を​確かめる​責任は​利用者に​残る。

Q5. 評価セットは​​何件​あれば​​始められるか？

A. 決まった​基準は​ない。​総数より、​業務カテゴリごとに​判断できる​件数が​ある​ことが​重要である。​小さな​セットで​始め、​結論が​出ない​カテゴリだけ件数を​足すのが​現実的である。

Q6. ローカルと​​クラウドの​​振り分けにも​使えるか？

A. 誤振り分けを​2種類に​分けて​測る、​シャドーモードで​並走させる、と​いった​考え方は​使える。​ただし機微情報を​外に​出さない​要件が​品質や​コストより​優先される​ことが​多く、​判定の​材料も​変わる。

次に​​読むべき記事

• LLMトークン節約5パターン：振り分け以外の​節約策と、​予算上限の​設計
• ローカルLLM比較2026：ローカルLLMと​クラウドAPIの​ハイブリッド設計
• Jevとは？​判断に​特化した​AIの​使いどころ：ルーティングの​判定器にもなる​判断特化モデル
• AIエージェントの​Eval設計：採点者の​設計と​評価セットの​育て​方
• LLM APIの​比較と​料金：候補モデルの​料金と​用途別の​比較

まとめ

• LLMルーティング​（モデルルーティング）は​依頼ごとに​使う​モデルを​自動で​選ぶ仕組みで、振り分けの判断は製品の中へ移りつつある
• 判定方​式は​「いつ判定するか」と​「誰が​判定を​持つか」で​選ぶ
• 評価は、過小振り分け率・過大振り分け率・コスト削減率・カテゴリ別の品質低下を​同じ​評価セットで​測り、​安い​固定モデルとも​比べる
• 公開値は​条件付きで​読む。​RouteLLMの​削減率は​ベンチマークで​35〜85%以上と​開き、​LLM Gatewayの​33.2%は​信頼区間が​削減ゼロを​含む
• 正解ラベルは​両方の​モデルに​答えさせて​作り、​シャドーモードで​測る
• 候補モデルの​更新・廃止、​ルーターの​版の​更新、​構成比の​変化、​料金改定を再評価の引き金に​する。​フォールバックは​許可リストの​範囲に​限り、​判定は​セッション単位に​する

出典・参考文献

• Sakana AI​「Introducing Fugu Max and Fugu Ultra v2: Orchestrating the Pareto Frontier」​（2026年9月11日。​多数の​オープンウェイトモデルと​専門モデルの​統合、​最も​軽い​モデルへの​動的な​振り分け、​OpenAI互換API。​2026年9月29日確認）
• GitHub Changelog​「Configure cost and quality in Copilot auto model selection」​（2026年9月14日。​Efficiency・Balance・Intelligenceの​3段階、​選ばれた​モデルでの​課金。​2026年9月29日確認）
• GitHub Docs​「Auto model selection」​（タスクの​複雑さと​システムの​状態に​よる​選択、​キャッシュの​区切りでの​判断、​管理者ポリシーに​よる​除外。​2026年9月29日確認）
• LLM Gateway​「Smart Routing」「Automatic Model Selection by Request Difficulty」​（2026年9月25日。​Jevに​よる​判定、​候補モデル、​許可外に​退避せず400を​返す挙動、​セッション単位の​判定。​2026年9月29日確認）
• LLM Gateway​「Smart Routing Benchmark」​（2026年9月26日。​80問・4構成の​試験、​費用指数、​信頼区間、​採点結果、​制約。​2026年9月29日確認）
• LLM Gateway Docs​「Routing」​（再試行の​対象と​なる​状態コードと​自動再試行が​無効に​なる​条件、​セッション中の​再確認と​モデルの​切り​替え、​分類器が​失敗した​ときの​退避先、​使われた​モデルを​示すヘッダー。​9月25日の​発表文と​異なる​点は​現行ドキュメントに​従った。​2026年9月29日確認）
• TypeSafe AI​「Introducing System One Models & Jev」​（2026年9月15日）
• Microsoft Learn​「Model router for Microsoft Foundry concepts」「Evaluate model router for your workload」「Monitor model router in Microsoft Foundry」​（ルーティングモード、​版と​自動更新、​退避先の​集合、​キャッシュと​セッションの​扱い、​評価の​進め方、​routing_trace。​2026年9月29日確認）
• Amazon Bedrock User Guide​「Understanding intelligent prompt routing in Amazon Bedrock」​（同一ファミリー内の​振り分け、​応答品質の​差と​フォールバック​モデル、​英語への​最適化などの​制約。​2026年9月29日確認）
• Anthropic​「Model deprecations」​（提供終了の​60日以上​前の​通知、​置き換え先での​事前テスト、​パラメータの​非推奨。​2026年9月29日確認）
• LMSYS「RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing」​（2024年7月1日。​モデルの​組み合わせ、​ベンチマーク別の​削減率）
• Isaac Ong ほか​「RouteLLM: Learning to Route LLMs with Preference Data」​（arXiv:2406.18665、​2024年6月初出）
• Lingjiao Chen, Matei Zaharia, James Zou​「FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance」​（arXiv:2305.05176、​2023年）

※ 英語資料からの​引用・要約は​編集部に​よる​翻訳である。​判定方​式の​判断表、​監視指標の​表、​評価と​切り​替えの​手順は​公開情報を​踏まえた​編集部の​設計例であり、​各社の​公式機能や​性能を​保証する​ものではない。