モデルルーティングの仕組みと検証方法：品質を守るLLMの使い分け

最も高性能なモデルは、その能力が必要な仕事に使うべきです。本人確認済みの注文状況への回答と、記録が食い違う返金トラブルを、最初から同じ経路で処理する必要はありません。難しいのは、安い回答が高くつく手戻りを生む前に、両者を見分けることです。

以下の製品仕様は、2026年10月21日に公開ドキュメントで確認したものです。サポート業務の想定と計算は説明用の例であり、本番環境での測定結果やベンダーによる削減効果の主張ではありません。

モデルルーティングは何をする仕組みですか

モデルルーターは、リクエストごとに回答を担当する大規模言語モデル（LLM）を選ぶルール、または学習済みの分類器です。分類器は、入力をいずれかのカテゴリに振り分けます。モデルの選択には、アプリケーション内のタスクの種類、会話の内容、必要なツール、入力サイズ、推定される難易度などを使います。

サポートチームで仕事を割り振る担当者を思い浮かべてください。定型的な照会は効率よく処理できる人へ、判断が難しいトラブルは専門担当へ回します。誰にも処理権限がない仕事については、上位の判断を仰ぐルールも必要です。

アプリケーションでこれを実現するには、最適化の前に利用条件を確認します。そのモデルは入力を扱えるか、必要なツールを呼び出せるか、承認済みのプロバイダー経由で実行できるか。コストや期待する品質を比較するのは、こうした条件を満たした候補だけです。

モデルルーティング、プロバイダールーティング、フォールバックは、それぞれ決めることが異なります。 モデルルーティングは回答するモデルを選びます。プロバイダールーティングは、選んだモデルをどこで実行するか、たとえばどのホスティング事業者を使うかを選びます。フォールバックは、処理に失敗したときに次に何を試すかを決めます。アプリとモデルAPIの間に置くアクセス層であるゲートウェイは、これらすべてを実装できます。ただし、ゲートウェイを追加するだけで回答品質を踏まえたモデル選択が実現するわけではありません。

本稿でいうフロンティアモデルは、検討している候補の中で最も高性能な汎用モデルを指します。そのモデルも誤った回答を出す可能性があります。ルーティングは能力の配分を決める仕組みであり、回答の正しさを保証する仕組みではありません。

モデルルーティングの3つの方式

まずは、判断の根拠を説明できるルールから始めましょう。 自動選択が役立つのは、ルールでは拾いきれないタスクの違いに対応しながら、合格基準も満たせる場合です。以下は実装方法を3つに整理したもので、互いに排他的ではありません。たとえば、ゲートウェイ上で学習済みルーターを動かすこともできます。

アプリケーション側で定義するルール

既知のタスクの種類や制約に応じて、アプリケーションがモデルを割り当てます。注文状況のエンドポイントから届き、本人確認済みの注文データと承認済みの回答テンプレートがそろったリクエストは、単に短文だから簡単だと分類されたメッセージよりも、小型モデルに任せる根拠が明確です。

アプリケーションが業務フローを把握している場合、ルールは有効です。ただし、曖昧なケースには限界があります。同じエンドポイントでも、単純な照会が来ることもあれば、矛盾する記録を含む苦情が来ることもあります。不安定なキーワード判定を際限なく追加するより、判断できないケースを送る経路を明示的に残しておきましょう。

ゲートウェイによる自動ルーティング

ルーティング用のエイリアスにリクエストを送ると、ゲートウェイがモデルを選びます。選択の仕組みは製品によって異なり、分類器、設定済みのティア、その他の情報などが使われます。動作を一元管理できる一方で、何を「適切な組み合わせ」とみなすかは、そのルーターの基準に従うことになります。

入力されるタスクの幅が広く、自前の選択機構を運用する負担が見合わない場合に向いています。候補は承認済みのモデルに絞り、実際に回答したモデルを記録してください。エイリアスが同じでも、常に同じモデルが使われるとは限りません。

LLMモデルルーターの学習と改善

学習済みルーターは、事例と結果のラベルから、どの候補がよりよい結果を出しそうかを学びます。学習で問うべきなのは、文章が複雑に見えるかどうかではなく、そのリクエストで高性能なモデルを使う価値があるかどうかです。

ルーターの実行と評価を支援するオープンソースのフレームワーク、**RouteLLM**は、回答の選好を学習して高性能モデルと低性能モデルを選び分ける方法と、しきい値の調整方法を公開しています。このしきい値で、高性能モデルが選ばれる頻度を制御します。公開された結果だけでは、自社の問い合わせでも同じ性能が得られるとは判断できません。RouteLLMのドキュメント。

保守で課題になるのは、扱うデータの傾向が変わることです。新しいタスクが増えたり、モデルを入れ替えたりすると、以前は有効だったしきい値が通用しなくなる場合があります。学習や調整には開発用の事例を使い、その後、調整に一度も使っていない別の事例で評価してください。

サポートアプリで振り分けルールを考える

根拠がそろい、回答範囲が限定された仕事は小型モデルへ。未解決の推論が必要な仕事はフロンティアモデルへ回します。 権限の判断はアプリケーションのポリシーに残してください。返金について説明できるからといって、どちらのモデルにも返金を実行する権限が与えられるわけではありません。

定期購入型の小売サービスを想定します。アプリは回答を作る前に、顧客の注文、関連するポリシー、会話履歴を取得します。以下はポリシーの設計例であり、特定の小型モデルがすでにこの基準を満たしているという主張ではありません。

必要な根拠がない場合、小型モデルの経路では回答を控えるべきです。アプリケーション側では、注文フィールドの欠落、出力形式の不備、許可された業務フローを外れる操作要求などを検出できます。事実関係の矛盾には、別の検証機構や人によるレビューが必要になる場合があります。形式が正しい回答でも、内容が正しいとは限りません。

難しいケースにはフロンティアモデルを使い、小型モデルの処理失敗を検出できる場合に限って、その処理をフロンティアモデルへ回します。記録が欠けているなら、必要なのは情報の取得や確認です。同じ不十分な情報を大型モデルへ送っても、欠落は埋まりません。

上位モデルへの再実行も数える

説明用に、1,000件のリクエストをまとめて処理する例を考えます。ポリシーに従って700件を小型モデルへ、300件を直接フロンティアモデルへ送ります。最初に小型モデルへ送ったうち70件がチェックに失敗し、フロンティアモデルで再実行されました。

支払いの対象は、小型モデルの700回とフロンティアモデルの370回の呼び出しに、ルーティングと検証の費用を加えたものです。回答モデルの呼び出しは1,000回ではなく、1,070回になります。利用者に最終回答しか見えなくても、再試行は追加の処理です。

元のリクエスト1件あたりの平均ルーティング費用をr、小型モデルの平均呼び出し費用をs、フロンティアモデルの平均呼び出し費用をf、バッチ全体に追加されるゲートウェイや検証の料金をgとします。計算を単純にするため、全件をフロンティアモデルで処理する基準構成、直接の呼び出し、上位モデルへの再実行で、フロンティアモデルの平均費用は同じと仮定します。

ルーティング時の費用 = 1,000r + 700s + 370f + g

全件をフロンティアモデルで処理する費用 = 1,000f

ルーティングのほうが安くなる条件は、700(f − s) > 70f + 1,000r + gです。左辺は、最初に小型モデルへ回すことで節約できる回答費用です。右辺は、フロンティアモデルでの追加の再試行と、その他の追加費用です。

呼び出し費用は、選んだモデルと料金で計算してください。単価が100万トークンあたりで示されている場合、呼び出し費用 =（非キャッシュ入力トークン数 × 入力単価 + キャッシュ済み入力トークン数 × キャッシュ単価 + 課金対象の出力トークン数 × 出力単価）/ 1,000,000です。別途課金されるツールやリクエスト料金も加えます。

本番環境では、単純化した平均値を、タスク別・経路別の実使用量に置き換えます。難しい問い合わせほど回答が長くなったり、再実行時にコンテキストが増えたり、モデルの切り替えでキャッシュの再利用率が変わったりする可能性があります。該当する場合は、ルーターの分類器が使うトークンや、課金対象の推論トークンも含め、同じ費用を二重計上しないようにしてください。比較する両方の構成で、再試行の方針をそろえます。

目指すべき成果は、品質の下限を守りながら、合格した解決1件あたりの費用を下げることです。請求額が下がっても、根拠のない返金の約束が増えるなら、その基準を満たしたことにはなりません。

各製品のルーティング機能をドキュメントで比較する

ルーティング用のエンドポイントを採用する前に、選択の仕組みを確認してください。 製品ごとに制御している判断は異なります。「ルーター」という名前が共通でも、既定の動作が同じとは限りません。

OpenRouter：タスクに応じて選ぶAuto Router

複数のモデルプロバイダーに接続できるマネージドゲートウェイ、OpenRouterでは、openrouter/autoを指定してAuto Routerを利用できます。現行ドキュメントでは、まずタスクを分類し、直近7日間のコミュニティ全体におけるタスク別の支出を使ってモデルを順位付けした後、価格帯と利用条件で絞り込むと説明されています。これは利用実績を集計した指標であり、自社のサポート品質を判定する基準ではありません。Auto Routerのドキュメント。

cost_tierにはlow、medium、high、xhigh、maxを指定でき、既定の動作はおおむねlowに相当します。ティアは価格帯であり、厳密な支出上限ではありません。allowed_modelsとexcluded_modelsで候補を制限し、レスポンスのmodelフィールドを記録してください。会話内で選択モデルを維持する仕組みはありますが、固定され続ける保証はありません。

環境変数にAPIキーを設定すると、次の最小構成でルーティングのリクエストを送れます。

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

評価時には候補モデルを絞ってください。候補群が変わると、前日に得た品質評価の結果を解釈しにくくなります。

LiteLLM：デプロイ先の振り分けとAuto Routerを区別する

柔軟に設定できるLLMゲートウェイ、**LiteLLM**は、重み付き選択、最も混雑していないデプロイ先の選択、レイテンシに基づく選択、コストに基づく選択などの戦略を公開しています。既定のsimple-shuffleは、サポート問い合わせの難易度を分類する仕組みではありません。Routerのドキュメント。

これとは別に、Auto Routerでは、ヒューリスティック、LLM、キーワードルール、カスタムプラグインを使う分類器が案内されています。SIMPLE、MEDIUM、COMPLEX、REASONINGの各ティアを、設定済みのモデルやモデルプールに対応付けます。ダッシュボードでの設定手順は、Models + Endpoints → Add Model → Auto Routerへ進み、設定後にTest Routingを実行する流れです。Auto Routerのドキュメント。

候補モデルや分類の動作を自分で制御したい開発者に向いています。一方で、運用の責任も自分で持つ必要があります。ティアとモデルを対応付けただけでは、自社の合格基準を満たすと検証したことにはなりません。この基盤選びについては、LiteLLMとOpenRouterの比較で詳しく扱っています。

Vercel AI Gateway：プロバイダー選択と明示的なルーティング制御

モデルAPIへのマネージドなアクセス層である**Vercel AI Gateway**は、直近の稼働率とレイテンシを基に既定のプロバイダーを選びます。プロバイダーオプションで優先順位と絞り込みを制御でき、文字列で指定するモデルフォールバックでは、第一候補が失敗した場合や利用できない場合に予備モデルを試します。いずれも可用性を高めるために役立つ仕組みです。ただし、それだけでサポート問い合わせにフロンティアモデルが必要かどうかを判断するわけではありません。プロバイダールーティングとフォールバックのドキュメント。

ゲートウェイのルーティングルールでは、リクエストされたモデルを別のモデルに書き換えたり、拒否したりすることもできます。書き換えを使えばトラフィックの移行を一元管理できますが、あるモデルへのリクエストをすべて置き換えることと、個々のリクエストの難易度を分類することは異なります。ルーティングルールのドキュメント。

動作を明確に定義したい場合は、アプリケーション側のモデル選択ポリシーの下に、これらの制御を組み合わせてください。注意すべきなのは、プロバイダーの自動選択に、タスクの品質を踏まえたモデルの自動選択まで含まれると思い込むことです。アクセス層全体の選び方は、複数モデルを使うアプリ向けのAIゲートウェイを参照してください。

Microsoft Foundry：プロバイダーが管理する学習済みルーター

Microsoft Foundryのmodel routerは、デプロイメントとして提供される学習済みのモデル選択機構です。Microsoftは、複雑さ、推論、タスクの種類、その他の属性を使って選択すると説明しています。Balanced、Quality、Costの各モードに加え、候補モデルをサブセットに絞る機能もあります。model routerの概念を説明するドキュメント。

すでにFoundryを使っていて、利用条件を満たすモデル間の選択をマネージドな仕組みに任せたいアプリケーションに向いています。大きな制約は候補モデルの範囲です。利用できるモデルはリージョンやアクセス権によって変わり、Microsoftのドキュメントは、構成モデルの中で最小のコンテキストウィンドウが、ルーターが確実に受け付けられる入力を制限すると注意しています。入力要件を満たすモデルだけを候補に残してください。

Qualityというモード名は、タスク評価の代わりにはなりません。実際の会話の長さ、ツール、合格基準を使い、選んだ候補モデル群をテストしてください。

AIモデルルーターはどう選ぶべきですか

簡単な仕事を確実に見分けられるなら、アプリケーションのルールを使い続けましょう。タスクの多様化でルールが不安定になるなら、マネージドな自動ルーティングを検討します。保守の負担に見合うだけの、実態を代表するラベル付きの結果データがそろっているなら、選択機構の学習を検討できます。

ここで扱った仕組み以外の基盤も比較したい場合は、OpenRouterの代替サービスガイドが次の参考になります。それでも、最初に決めるべきなのは候補プロバイダーの数ではなく、振り分けの方針と、それを裏付ける証拠です。

評価セットでルーターの性能を測るには

測るべきなのは、振り分けた結果として得られた回答です。「簡単」「難しい」といったラベルとの一致率ではありません。 タスクのカテゴリを正確に分類できても、小型モデルに任せるべきでないケースを送ってしまうことはあります。

評価セットは、リクエスト、コンテキスト、合格基準をまとめた、繰り返し使える事例集です。サポートアプリなら、各事例に会話、注文データのスナップショット、適用するポリシー、回答に必要な事実、禁止する主張や操作、必要なエスカレーションの動作を含めます。

評価表には、大きな損失につながる誤りが見える指標を入れましょう。

指標の分母に該当する事例がない場合は、ゼロではなく未定義として報告してください。小型モデルへの有害な振り分け率は、各モデルの出力を独立に評価して推定し、上位モデルへの再実行後にも残った最終的な誤りも報告します。両方のモデルが不合格になるケースは別に示してください。その候補しかなければ、選択機構だけで合格する回答を生み出すことはできません。

重大ではない品質差をどこまで許容するかは、テスト前に決めておきます。新たに生じた重大な品質悪化は、すべて調査してください。同じ事例同士を比較する対応のあるサンプルに適した信頼区間を使い、許容できない損失の可能性がまだ残るなら、同等と結論付けずに追加の証拠を集めます。

最後に、本番トラフィックの一部に範囲を絞り、現在のモデルが顧客への回答を続ける横で、ルーターをシャドー運用します。シャドー呼び出しには追加費用がかかります。結果を確認した後、既存のモデル選択方針へすぐ戻せる状態で、限定的に展開してください。リクエストの種類ごとに監視を続け、プロンプト、ツール、モデル、ルーティングの動作が変わったら評価をやり直します。

モデルルーティングで過大評価されがちなこと

「同じ品質で、より安く」は、特定の業務負荷で検証して得られる結果です。ルーター自体に備わる性質ではありません。 どのようなリクエストが来るか、どのモデルを使えるか、何を合格とするかによって変わります。他社の業務で得られた削減率では、自社での測定を代替できません。

APIが正常に応答したことからも、回答品質はほとんど分かりません。エラー時のフォールバックは、利用できないエンドポイントからの復旧には役立ちますが、流暢な回答に架空のポリシーが含まれていても検出できません。品質上の問題で上位モデルへ回すには別のチェックが必要で、そのチェックにも誤りと費用があります。

難易度スコアも同じように精査すべきです。分類器の確信度が、そのまま選択先のモデルが正答する確率になるわけではありません。しきい値は、実際に観測したタスクの結果に照らして調整してください。「これは簡単です」といったユーザー入力によって、アプリケーションの権限や候補モデルの制限を上書きさせてはいけません。

また、アプリケーションのコードを変更していなくても、自動選択の動作は変わり得ます。OpenRouterでは支出に基づく候補が変化し、Microsoftの現行model routerには構成モデルが追加される場合があります。ドキュメントに明記されたこうした動作を考えると、候補モデルの記録と評価の更新は、任意の後片付けではなくルーター運用の一部です。

今取り組むべき人、待つべき人、最初の一歩

開発者が取り組むべきなのは、合格条件が明確で、繰り返し発生する仕事を切り出せる場合です。 根拠のそろった状況説明に小型モデルの経路を追加し、判断できないケースには保守的な経路を残します。失敗を再現できるよう、ポリシーをバージョン管理してください。

運用担当者は、ワークフロー全体での証拠を求めるべきです。 推論の請求額が下がっても、問い合わせの再開、人によるレビュー、解決時間が増えるなら、それだけでは不十分です。オフライン評価と併せて、こうした結果も追跡してください。

導入を判断する担当者は、自社の事例を再実行してもらいましょう。 選択されたモデルとフォールバックの動作を確認できることを求めてください。汎用ベンチマークだけでは、ルーターが自社の返金ポリシーを理解しているとは判断できません。

正しい結果を定義できない、候補モデルを制限できない、運用の手間に見合うだけのトラフィックがない場合は、導入を待ちましょう。固定された狭いタスクで、検証済みの小型モデルをすでに使っているアプリケーションなら、別の選択機構を加えても得られるものは少ないかもしれません。

週明けに着手するなら、まず代表的なサポート事例をエクスポートし、その根拠情報を固定して、現在のモデルと小型の候補を並べて採点してください。小型モデルが合格する範囲に絞って、振り分けルールを書きます。自動ルーターに実トラフィックを任せるのは、同じ品質要件を満たしながら、そのルールより低いコストを実現してからです。

モデルルーティングでよくある質問

AIアプリケーションの開発と評価に役立つ実践ガイドを受け取るには、ニュースレターに登録してください。