ダイナミックプロンプトルーティングとは？クエリに応じてLLMを最適選択する設計

ダイナミックプロンプトルーティングとは、入力クエリの内容や特性に応じて、最適なLLMやプロンプトを実行時に自動で振り分ける設計パターンである。 単一の高性能モデルにすべてを任せると、簡単な質問にも高いコストとレイテンシを払うことになり、逆に小型モデルだけでは難しいタスクで品質が出ない。

ルーティング層を挟むことで、「簡単なクエリは安く速いモデル、難しいクエリは高性能モデル」と振り分け、コスト・精度・速度のトレードオフを動的に最適化できる。本記事は、LLMアプリのコストと品質を両立させたい開発者・アーキテクト向けに、主要な振り分け戦略の違いから、比較の観点、実装ステップ、そして陥りやすい設計ミスまでを体系的に解説する。

ダイナミックプロンプトルーティングは、複数のモデルやプロンプトを「使い分ける」ための仕組みだ。まずは静的な選択との違いと、何を解決するための技術なのかを押さえる。

静的なモデル選択とは、アプリ内で「このエンドポイントは常にこのモデルを使う」と固定する方式だ。実装は単純だが、すべてのクエリが同じモデルを通るため、簡単な問い合わせにも高価なモデルのコストがかかり、専門的なクエリには能力不足が起きる。

ダイナミックルーティングでは、クエリが来るたびに「このクエリにはどのモデル・どのプロンプトが最適か」を判断してから実行する。たとえば、FAQ的な短い質問は小型モデルへ、長文の分析やコード生成は高性能モデルへ、と振り分ける。

違いを一言で言えば、静的選択が「設計時に決め打ち」なのに対し、動的ルーティングは「実行時にクエリ単位で決める」点にある。この一段の判断層を挟むだけで、同じ機能を保ちながらコストと品質のバランスを大きく改善できる。

ルーティングが狙うのは、相反しがちな3つの指標の同時最適化だ。

1. コスト: 高性能モデルは1トークンあたりの単価が高い。クエリの大半を占める「簡単な処理」を安価なモデルに逃がせば、全体の推論コストを大きく下げられる。
2. 精度: すべてを小型モデルで処理すると難問で破綻する。難しいクエリだけを高性能モデルに回すことで、平均品質を保ちつつ無駄な高コストを避けられる。
3. 速度: 小型・軽量モデルは応答が速い。即答でよいクエリを速いモデルに振れば、体感レイテンシが改善する。

ポイントは、この3つはトレードオフ関係にあり、単一モデルでは同時に満たせないことだ。ルーティングは「クエリごとに最適点を選ぶ」ことで、全体としてこのトレードオフを動かす。

ルーティングは、マルチエージェント構成の入口としても機能する。

マルチエージェントシステムでは、役割の異なる複数のエージェント（検索担当・コード担当・要約担当など）が協調してタスクを進める。このとき「どのエージェントに最初に渡すか」「次にどの専門モデルへ回すか」を決めるのが、まさにルーティングの役割だ。

つまり、プロンプトルーティングは単なるコスト削減策にとどまらず、複数の専門モデルを束ねて使いこなすための基盤になる。小さく始めるなら「2つのモデルの振り分け」から、発展させれば「多数の専門エージェントへのディスパッチャ」へと、同じ考え方を拡張できる。逆に言えば、ルーティング層の設計が雑だと、マルチエージェント全体の精度とコストもそこで頭打ちになる。

ルーティングが注目される背景には、モデル選択肢の急増とコスト圧力がある。ここでは、いま振り分け設計が実務上の論点になっている理由を整理する。

利用できるモデルは、高性能なフラッグシップから軽量モデルまで幅広く揃い、価格も性能も大きな幅がある。同じタスクでも、どのモデルを選ぶかで単価が桁違いになることは珍しくない。

この「選択肢の多さ」と「価格差」が、ルーティングの前提条件を作っている。かつてのように選べるモデルが限られていれば振り分ける意味は薄いが、性能とコストの異なるモデルが多数並ぶ今、「クエリに対して過剰でも過小でもないモデルを選ぶ」こと自体が最適化の余地になる。

特にトークン量の多いプロダクトでは、全クエリをフラッグシップで処理する構成と、ルーティングで安価なモデルに逃がす構成とで、運用コストが大きく変わる。モデルが多様化したからこそ、その多様性を使い分ける層が必要になっている。

コスト削減の中心になるのが、SLM（Small Language Models）とLLMの使い分けだ。

SLMは小規模で安価・高速だが、複雑な推論や広い知識を要するタスクは苦手な傾向がある。LLMはその逆で、高品質だが高コスト・低速になりやすい。実運用のクエリを観察すると、多くは定型的・反復的で、SLMでも十分に処理できるものが相当の割合を占めることが多い。

そこで、まずSLMで処理を試み、信頼度が低い・難しいと判断されたものだけをLLMにエスカレーションする構成（カスケード）が有効になる。安価な層で大半を捌き、高コストな層を「本当に必要なときだけ」使うことで、品質を大きく落とさずにコストを下げられる。SLMをローカルやエッジで動かせば、さらにAPIコストを圧縮できる。

企業利用では、コストと精度だけでなく、可観測性とガバナンスがルーティング設計の要件に入ってくる。

どのクエリがどのモデルに振られ、いくらかかり、どんな出力を返したか——これらを記録・追跡できないと、コスト管理も品質改善も障害対応もできない。ルーティング層は全リクエストが通る関所なので、ここでログ・メトリクス・トレースを取るのが理にかなっている。

また、規制やポリシー上「特定のデータは外部APIに出せない」「この用途は承認済みモデルに限る」といった制約がある場合、ルーティングはそれを強制するポイントにもなる。機密データを含むクエリはローカルモデルに固定で振る、といった制御を一箇所に集約できる。コスト最適化の仕組みが、そのままガバナンスの実装場所になるわけだ。

ルーティングの実装方式は大きく3つに分けられる。判断の賢さと実装コストはトレードオフの関係にあり、用途に合うものを選ぶ。

最もシンプルなのがルールベースだ。キーワードの一致、入力長、明示的なタスク種別（フラグやメタデータ）などの条件で振り先を決める。

たとえば「コード」「翻訳」を含むクエリは専用モデルへ、入力が一定トークン以上なら長文対応モデルへ、といった分岐をコードで書く。利点は、挙動が決定的で説明しやすく、デバッグも容易なことだ。判断コストもほぼかからない。

欠点は、表現のゆれや想定外のクエリに弱いこと。「バグを直して」はコード系だが「コード」という語を含まない、といった取りこぼしが起きる。ルールが増えるほどメンテナンスも重くなる。

それでも、用途が限定的で分類が明確な場合は、まずルールベースから始めるのが定石だ。シンプルさは本番運用での安定性に直結する。

埋め込みベースは、クエリをベクトル化し、あらかじめ用意したカテゴリ（の代表ベクトル）との意味的な近さで振り分ける方式だ。

キーワード一致ではなく意味で判断するため、「バグを直して」も「コードが動かない」も同じ『コード支援』カテゴリに寄せられる。表現のゆれに強く、ルールベースの取りこぼしを補える。

実装では、各カテゴリの代表例文を埋め込み、入力クエリの埋め込みとの類似度が最も高いカテゴリへ振る。埋め込み計算は軽量モデルで高速に行えるため、追加レイテンシは小さい。

注意点は、カテゴリ設計と代表例の質に精度が左右されること、そして類似度の閾値設計だ。どのカテゴリにも近くないクエリをどう扱うか（デフォルト送り先やフォールバック）を決めておかないと、判断の境界で不安定になる。明確なものはルール、曖昧なものは埋め込み、と併用する構成もよく使われる。

最も柔軟なのがメタLLMルーティングだ。軽量なLLMに「このクエリはどのモデルで処理すべきか」を判断させ、その結果で振り分ける。

人間が分類軸を定義しなくても、文脈や難易度を含めて総合的に判断できるのが強みだ。新しい種類のクエリにも、ルールの追加なしである程度対応できる。

一方で、判断のために毎回モデルを1回呼ぶため、レイテンシとコストが上乗せされる。判断役のモデルが間違えれば振り先も間違うため、ルーティング自体が誤りの発生源になりうる。判断が不安定な場合に備えたフォールバックも要る。

判断役には、安価で速いモデルを使い、出力を厳密な形式（モデル名の列挙など）に制約するのが定石だ。賢さと引き換えにオーバーヘッドを払う方式なので、振り分けの難易度が高く、ルール・埋め込みでは捌けない場合に採用する。

結論: クエリの分類が明確ならルールベース、表現のゆれが大きいなら埋め込みベース、分類軸を事前に定義できない複雑な振り分けならメタLLMが向く。 まず全体像を表で示す。

この後の各セクションで、3軸（コスト・レイテンシ・精度）と、実装・保守の観点を掘り下げる。万能な戦略はなく、要件に対して過不足のない方式を選ぶことが重要だ。

3軸で見ると、各戦略の性格がはっきりする。

コスト: ルールベースは判断自体がほぼ無料。埋め込みベースは軽量な埋め込み計算分のわずかな上乗せ。メタLLMは判断のたびにモデルを呼ぶため、最も高くつく。ただし、振り分けの精度が上がって高コストモデルの呼び出しが減れば、トータルでは逆に安くなることもある。

レイテンシ: 同様に、ルール＜埋め込み＜メタLLMの順で判断時間が増える。ただし「振り分けの判断時間」より「振り先モデルの推論時間」の方が支配的なことが多いので、適切なモデルに振れているかの方が体感を左右する。

精度: 振り分けの正確さはルール＜埋め込み＜メタLLMの順に上がりやすいが、メタLLMは判断ミスのリスクも抱える。3軸はトレードオフであり、自社のクエリ分布で実測して評価するのが前提になる。

運用を続ける視点では、初期実装より保守コストが効いてくる。

ルールベースは作るのは簡単だが、クエリの種類が増えるたびにルールを追記する必要があり、ルールが数十・数百に膨らむと「どの条件が効いているか」が追えなくなる。条件の競合も起きやすい。

埋め込みベースは、カテゴリと代表例を整備すれば、新しい表現には自動で追従しやすい。ただしカテゴリ自体を増やす・見直す際は、代表例の再設計と閾値の再調整が必要になる。

メタLLMは、判断ロジックをプロンプトで表現できるため柔軟だが、モデルの挙動が変われば振り分けも変わり、再現性の確保とテストが難しい。

現実には、骨格はルールベースで決定的に保ちつつ、曖昧な部分だけ埋め込みやメタLLMで補う、というハイブリッドが保守性とのバランスを取りやすい。

ルーティングは、RAGやチェーンオブソート（CoT）といった他の手法と組み合わせて使う。

RAGとの組み合わせ: 「外部知識が必要なクエリか」を判定し、必要なものだけ検索を挟むルーティングは効果的だ。すべてのクエリで検索すると遅く高コストになるため、知識参照が要るクエリだけRAG経路に振る。

CoTとの組み合わせ: 簡単なクエリにまで段階推論をさせると無駄に遅くコストもかさむ。難しいクエリだけCoT（やより強力なモデル）に振り、簡単なものは即答させる、という出し分けが有効だ。

つまりルーティングは、これらの重い手法を「必要なときだけ起動する」ためのスイッチとして働く。RAGもCoTも常時オンにするのではなく、ルーティングで適用対象を絞ることで、品質を保ちながら平均コストとレイテンシを下げられる。

ここからは実装の進め方を、クエリ分類器の設計、モデル割り当て、フォールバックの3ステップで具体化する。小さく始め、計測しながら育てるのが基本方針だ。

ルーティングの心臓部は、クエリを分類する仕組みだ。

まず、振り分けたいカテゴリを定義する（例: 雑談・FAQ・コード・長文分析・要約）。次に、実際のクエリログを集め、各カテゴリに分類してデータを作る。この「自社の実クエリ」が何より重要で、想像で作ったサンプルだけでは本番分布とずれる。

分類器は、ルールベースなら条件式、埋め込みベースならカテゴリ代表ベクトル、メタLLMなら判定プロンプトとして実装する。いずれの方式でも、最初から完璧を目指さず、主要カテゴリだけで始めてよい。

収集したデータは、分類器の精度評価にも使う。「正しい振り先」を付けた評価セットを用意し、分類器がどれだけ正解するかを定期的に測る。本番のクエリ分布は時間とともに変わるため、ログ収集と再評価は継続的なプロセスとして組み込む。

カテゴリが決まっても、割り当て先のモデルは「能力」だけでなく「入出力のサイズ」で選ぶ必要がある。

長文の文書分析なら、コンテキストウィンドウの大きいモデルでないと入力が収まらない。逆に短い対話なら、コンテキストの大きさは不要で、速さと安さを優先できる。クエリの入力トークン数を見て、それを処理できる最小のモデルに振るのが基本だ。

また、出力の長さも考慮する。長い生成を求めるタスクを、出力の遅いモデルに振ると体感が悪化する。

実務では、(1)入力トークン数で「収まるモデル群」を絞り、(2)その中からカテゴリの難易度に応じて性能と価格のバランスを選ぶ、という二段で決めると整理しやすい。トークン数の見積もりはルーティング判断の前に行い、超過しそうなら入力の要約・分割を挟む。

本番では、振り先のモデルがエラーを返す・タイムアウトする・レート制限に当たる、といった障害が必ず起きる。これに備えるのがフォールバックとサーキットブレーカーだ。

フォールバック: 第一候補のモデルが失敗したら、代替モデルへ自動で切り替える。高性能モデルが落ちたら別系統のモデルへ、外部APIが不通ならローカルモデルへ、と段階的に逃がす経路を用意する。

サーキットブレーカー: あるモデルでエラーが連続したら、一定時間そのモデルへの送信を止め、回復を待つ。落ちている先に投げ続けて全体の遅延を悪化させるのを防ぐ。

これらをルーティング層に組み込むことで、個々のモデルの障害がサービス全体の停止に直結しないようにできる。エッジやマルチプロバイダ構成では特に重要で、「どれか一つが落ちても縮退して動き続ける」設計が信頼性を支える。

最後に、ルーティング設計で繰り返し起きる失敗と、その回避策をまとめる。コスト最適化に気を取られて、品質と安全をおろそかにするのが典型的な落とし穴だ。

よくある失敗が、ルーティングの判断を過信することだ。

安価なモデルに振りすぎると、本来は高性能モデルが必要だったクエリで品質が落ち、誤った回答（ハルシネーション）が増える。コスト削減の数字だけを見て振り分けを攻めすぎると、見えないところで出力品質が劣化していく。

回避策は、コストと品質の両方を計測することだ。振り分けの変更がコストだけでなく正答率や満足度にどう影響したかを、評価セットで継続的に確認する。また、信頼度の低い出力は上位モデルに再エスカレーションする仕組みを入れると、攻めた振り分けでも品質の下限を守れる。

「安く振れたか」ではなく「安く、かつ十分な品質で振れたか」を指標にする。この視点を欠くと、コスト削減が品質劣化に化ける。

もう一つの見落としが、セキュリティだ。ルーティング層は全入力が通る関所であり、ここを攻撃対策の場所として使わない手はない。

プロンプトインジェクション（入力に紛れた不正な指示でモデルを誤動作させる攻撃）への対策として、ルーティング層で入力を検査し、危険なパターンを検出・遮断する。振り分けの判断材料に「安全性チェック」を含め、疑わしいクエリは制限付きの経路や拒否に回す。

また、出力側にもガードレール（不適切な内容や機密の漏洩を検査するフィルタ）を置き、どのモデルに振られた結果でも一定の安全基準を通す。

コスト・精度・速度の最適化に集中するあまり、この安全層を後回しにするとリスクが残る。ルーティングを設計する時点で、ガードレールを「振り分けと同じ層の標準機能」として組み込んでおくのが望ましい。