カスケードルーティング（カスケードルーティング）
カスケードルーティング（Cascade Routing）とは、LLMへのリクエストを最初に小型・低コストモデルで処理し、品質が閾値を下回った場合にのみ段階的に大型・高コストモデルへエスカレーションするルーティング手法である。Stanford大学が2023年に発表したFrugalGPTで提唱された概念であり、「安いモデルで解ける問題は安いモデルで解く」という経済合理性に基づく。最大98%のコスト削減が理論上可能であり、LLMの本番運用コスト最適化の中核技術として広く採用されている。
カスケードルーティングとは
カスケードルーティング（Cascade Routing）は、複数のLLMモデルをコスト順に階層化し、低コストモデルから順番に推論を試みる多段階フォールバック方式のルーティング手法である。各段階で品質検証（Quality Verification）を行い、閾値を超えた時点でそのモデルの回答を採用する。閾値を下回った場合のみ、次の上位モデルにリクエストをエスカレーションする。
この手法の理論的基盤は、Stanford大学のLingjiao Chen、Matei Zaharia、James Zouらが2023年5月に発表した論文「FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance」に遡る。FrugalGPTは、GPT-4の品質を維持しながらAPI費用を最大98%削減できることを実験的に示し、LLM業界に大きなインパクトを与えた。
カスケードの基本フローは以下の通りである。
リクエスト → Model_1（最安） → 品質OK? → Yes → 回答返却
→ No → Model_2（中間） → 品質OK? → Yes → 回答返却
→ No → Model_3（最高品質） → 回答返却
カスケードの設計パラメータ
カスケードルーティングの性能は、以下の設計パラメータに大きく依存する。
| パラメータ | 説明 | 典型的な設定値 | 影響 |
|---|---|---|---|
| モデルチェーン | エスカレーション順のモデルリスト | Haiku → Sonnet → Opus | コスト-品質トレードオフ |
| 品質閾値（θ） | エスカレーション判断の境界値 | 0.7〜0.9 | 低いほどコスト削減、高いほど品質維持 |
| 品質検証器 | 回答品質を評価するメカニズム | LLM-as-Judge / 確信度スコア | 検証精度がシステム全体の鍵 |
| 最大段数 | カスケードの最大エスカレーション回数 | 2〜4段 | 多いほど柔軟だがレイテンシ増大 |
| タイムアウト | 各段の応答待ち時間上限 | 5〜30秒 | 短いと不完全な回答でエスカレーション |
| 並列実行 | 複数モデルを同時呼び出し | Off（コスト優先）/ On（速度優先） | Onだとコスト削減効果が低下 |
品質検証メカニズム
カスケードルーティングの核心は「品質検証器（Quality Verifier）」の設計にある。回答が十分な品質かどうかを自動判定する仕組みが不正確であれば、不適切なエスカレーション（必要ないのに上位モデルを呼ぶ）や品質劣化（不十分な回答をそのまま返す）が発生する。
主要な品質検証手法を比較する。
| 手法 | 原理 | 精度 | コスト | レイテンシ |
|---|---|---|---|---|
| 確信度スコア（Logprobs） | モデル出力のトークン確率を使用 | ○ 中 | ◎ 無料 | ◎ 0ms |
| LLM-as-Judge | 別のLLMで回答品質を評価 | ◎ 高 | △ 追加コスト | △ +1-3秒 |
| ルールベース検証 | 回答長・フォーマット・キーワードで判定 | △ 低 | ◎ 無料 | ◎ 0ms |
| アンサンブル投票 | 複数モデルの回答一致度で判定 | ◎ 高 | × 高コスト | × 遅い |
| 専用分類器 | 訓練済みの品質判定モデル | ○ 高 | ○ 低コスト | ○ 10-50ms |
確信度スコア（Logprobs）方式は、モデルが出力する各トークンの対数確率（log probability）を利用する。確信度が高い（logprobが0に近い）回答はそのモデルの能力範囲内と判断し、確信度が低い場合にエスカレーションする。OpenAIのAPIではlogprobsパラメータで取得可能であり、追加コストなしで品質推定ができる利点がある。ただし、モデルが「自信を持って間違える」ケース（Hallucination）には対応できない。
LLM-as-Judge方式は、小型の専用LLM（例: GPT-4o-mini、Claude Haiku）を品質判定に使用する。回答の正確性・完全性・関連性を5段階等でスコアリングし、閾値と比較する。精度は最も高いが、判定用LLMのAPI費用とレイテンシが追加される。
実装パターン
パターン1: Anthropicモデルチェーン
Anthropicのモデルファミリーは、Haiku → Sonnet → Opusの3段階で性能とコストが明確に階層化されているため、カスケードルーティングとの相性が極めて良い。
| モデル | 入力コスト（/1Mトークン） | 出力コスト（/1Mトークン） | 速度 | 用途 |
|---|---|---|---|---|
| Claude Haiku 4.5 | $1.00 | $5.00 | 最速 | 単純QA、分類、要約 |
| Claude Sonnet 4.6 | $3.00 | $15.00 | 中速 | コード生成、分析、複雑な推論 |
| Claude Opus 4.5 | $15.00 | $75.00 | 低速 | 最高品質が必要なタスク |
この構成では、リクエストの70-80%がHaikuで処理完結し、15-25%がSonnetにエスカレーション、5%未満がOpusに到達する。結果として、全リクエストをSonnetで処理する場合と比較して40-60%のコスト削減が可能である。
パターン2: クロスプロバイダーチェーン
異なるプロバイダーのモデルを組み合わせることで、各モデルの得意分野を活かしたカスケードを構築できる。
段階1: Gemini 1.5 Flash（Google、最安、高速）
段階2: Claude Sonnet 4.6（Anthropic、コード/分析に強い）
段階3: GPT-4o（OpenAI、汎用性最高）
パターン3: ローカル+クラウドハイブリッド
コスト削減を最大化するため、第一段階にローカルLLM（Llama 3.1 8B、Gemma 2 9B等）を配置し、クラウドAPIへのフォールバックを最小限にするアプローチ。
段階1: Llama 3.1 8B（ローカル、コスト$0）
段階2: Claude Haiku 4.5（クラウド、低コスト）
段階3: Claude Sonnet 4.6（クラウド、高品質）
自社GPUを保有している場合、推論コストは電気代のみとなり、ローカルモデルで処理完結するリクエストの割合を高めるほどコスト削減効果が大きい。
カスケードの数学的モデル
カスケードルーティングの期待コストは以下の式で表される。
E[Cost] = Σ_{i=1}^{N} P(reach_i) × C(model_i)
ここで:
P(reach_i) = Π_{j=1}^{i-1} (1 - pass_rate_j) （段階iに到達する確率）
C(model_i) = 入力トークン × 入力単価 + 出力トークン × 出力単価
pass_rate_j = 段階jで品質閾値を通過する確率
例えば、3段階カスケード（Haiku/Sonnet/Opus）で、pass_rate = [0.75, 0.90, 1.00] の場合:
- 段階1（Haiku）到達率: 100%、通過率75%
- 段階2（Sonnet）到達率: 25%、通過率90%
- 段階3（Opus）到達率: 2.5%、通過率100%
期待コスト = 1.0 × C_haiku + 0.25 × C_sonnet + 0.025 × C_opus
全リクエストをSonnetで処理する場合の期待コストC_sonnetと比較して、大幅なコスト削減が実現できる。
導入時の注意点
カスケードルーティングの導入にあたっては、以下の点に注意が必要である。
レイテンシの累積問題: 最悪ケースでは全段階を通過するため、レイテンシが各段階の合計値になる。3段階カスケードで各モデルが3秒かかる場合、最悪9秒の応答時間となる。リアルタイム性が求められるユースケースでは、最大段数を2段に制限するか、並列実行を検討すべきである。
品質検証器の精度: 品質検証器が不正確な場合、「安いモデルの不十分な回答をそのまま返してしまう」（偽陽性）リスクがある。特に、Hallucination（幻覚）を含む回答は確信度スコアが高くなりやすいため、logprobsのみに依存するのは危険である。
コールドスタート問題: 新しいタスクドメインやプロンプトパターンに対して、各段階のpass_rateが不明なため、初期段階では最適なカスケード設定が困難である。最低1,000-5,000リクエスト分のデータ収集期間が必要とされる。
モデル更新への追従: プロバイダーのモデル更新（GPT-4o → GPT-4o-2024-11-20等）により各段階の品質が変動する。定期的なベンチマークとカスケード設定の再調整が必要である。
よくある質問（FAQ）
Q1: カスケードルーティングとロードバランシングの違いは何ですか？
A1: ロードバランシングは同一品質のモデルインスタンス間でリクエストを分散させる手法であり、目的は負荷分散と可用性向上である。一方、カスケードルーティングは品質とコストが異なるモデル間で段階的にエスカレーションする手法であり、目的はコスト最適化である。両者は併用可能であり、各カスケード段階内でロードバランシングを行う構成が実運用では一般的である。
Q2: カスケードの段数は何段が最適ですか？
A2: 実運用では2-3段が最も一般的である。段数を増やすほど理論上のコスト削減余地は大きくなるが、（1）品質検証の累積誤差、（2）レイテンシの増大、（3）運用・監視の複雑化、というデメリットが増大する。FrugalGPTの実験でも、3段以上でのコスト削減の限界効用は急速に逓減することが示されている。まずは2段構成（安価モデル + 高品質モデル）から開始し、効果を確認してから段数を増やすアプローチが推奨される。
Q3: カスケードルーティングが不向きなユースケースはありますか？
A3: 以下のケースではカスケードが不向きまたは非効率となる。（1）全リクエストが高難易度でpass_rateが低い場合（例: 全リクエストの90%が最上位モデルにエスカレーションするなら、最初から最上位モデルを使うべき）。（2）レイテンシ要件が極めて厳しい場合（100ms以内等）。（3）ストリーミング応答が必要な場合（エスカレーション時に途中まで生成した回答を破棄する必要がある）。（4）長文生成タスク（各段階での出力トークンコストが嵩む）。
Q4: FrugalGPTの「98%コスト削減」は本当に実現可能ですか？
A4: 98%という数値はHELLASWAG等の特定ベンチマーク上での理論的最大値であり、多くのリクエストが最安モデルで正解できる単純なタスクに偏っている。実運用では、タスクの難易度分布、品質検証器の精度、エスカレーション率に依存して30-70%程度のコスト削減が現実的な期待値である。ただし、カスタマーサポートのFAQ応答など、定型的なクエリが大半を占めるユースケースでは80%以上の削減も十分に達成可能である。