カスケードルーティング（カスケードルーティング）
LLMのリクエスト処理において、まず軽量・低コストモデルで応答を生成し、応答品質が基準を満たさない場合に段階的に上位モデルへエスカレーションする多段ルーティング戦略。品質保証とコスト削減を両立する。
カスケードルーティングとは
カスケードルーティング（Cascade Routing）とは、LLMへのリクエストを処理する際に、最初にコストの低い軽量モデルで応答を試み、その応答品質が一定の基準を満たさない場合にのみ上位の高性能モデルへエスカレーションする多段階のルーティング戦略である。「滝（カスケード）」のように段階的に処理が流れ落ちていく構造からこの名称がつけられている。
カスケードルーティングの動作フロー
| ステージ | モデル例 | コスト | 処理内容 |
|---|---|---|---|
| Stage 1 | Haiku 4.5 | $0.80/MTok | 全リクエストをまず処理。品質スコア算出 |
| Stage 2 | Sonnet 4.6 | $3/MTok | Stage 1で品質不足のリクエストを処理 |
| Stage 3 | Opus 4 | $15/MTok | Stage 2でも品質不足の高難度リクエストを処理 |
品質判定の仕組み
カスケードの核心は「いつエスカレーションするか」の判定にある：
1. 自己評価型（Self-Assessment）
応答モデル自身に「この回答の確信度は？」と追加質問し、確信度スコアが閾値未満ならエスカレーションする。実装が簡単だが、モデルの自己評価は過信傾向があるため信頼度には限界がある。
2. 検証モデル型（Verifier Model）
別の小型モデル（分類器やBERTベース）で応答品質を評価する。応答の一貫性、事実性、完全性をスコア化し、閾値未満でエスカレーション。評価モデルの追加コストが発生するが、自己評価より客観的な判定が可能。
3. ルールベース型（Rule-Based）
応答の長さ、特定キーワードの有無、拒否パターンの検出などのヒューリスティクスで判定する。「I'm not sure」「I don't have enough information」等の不確実性表現を検出してエスカレーションする。低コストだが表層的な判定に限定される。
4. ハイブリッド型
ルールベースの高速フィルタでまず明確なケースを振り分け、曖昧なケースのみ検証モデルで精密判定する。実運用で最も推奨されるアプローチ。
コスト削減効果のシミュレーション
3段カスケード（Haiku→Sonnet→Opus）の典型的な分配比率と効果：
- Stage 1 通過（Haikuで完了）: 約65%のリクエスト
- Stage 2 通過（Sonnetで完了）: 約25%のリクエスト
- Stage 3 到達（Opusが必要）: 約10%のリクエスト
この分配での加重平均コスト： $0.80×0.65 + $3×0.25 + $15×0.10 = $0.52 + $0.75 + $1.50 = $2.77/MTok
全件Opus（$15/MTok）比で 81.5%のコスト削減。ただし品質判定のオーバーヘッドコストを加算する必要がある。
カスケードの課題
- レイテンシの増加: エスカレーション発生時、Stage 1の応答生成＋品質判定＋Stage 2の応答生成が順次発生し、応答時間が2-3倍になる
- 品質判定の精度: 判定閾値が低すぎるとエスカレーション過多（コスト増）、高すぎると低品質応答の見逃し（品質低下）が起きる
- ストリーミングとの相性: ストリーミング応答中にエスカレーションが必要と判定された場合、途中まで送信した応答の取消しが困難
- 同一性の維持: Stage 1とStage 2で異なるモデルが応答するため、口調やフォーマットの一貫性が崩れる場合がある
カスケード vs 事前ルーティング
| 比較項目 | カスケードルーティング | 事前ルーティング |
|---|---|---|
| 判定タイミング | 応答生成後（事後判定） | 応答生成前（事前判定） |
| レイテンシ | エスカレーション時に増加 | 一定（ルーター判定分のみ） |
| 品質保証 | 高い（実応答を評価） | 中程度（クエリのみで推定） |
| コスト効率 | Stage 1のコストが常に発生 | 無駄な処理コストなし |
| 実装複雑度 | 中程度 | 低い |
実運用では両者を組み合わせ、事前ルーティングで明確なケースを振り分けた後、曖昧なケースにカスケードを適用するハイブリッド構成が最も効果的とされる。
FAQ
Q1: カスケードルーティングは何段階が最適ですか？
A1: 2-3段階が実用的です。段階を増やすほど細かいコスト最適化が可能ですが、品質判定の累積コストとレイテンシが増加します。一般的にはHaiku相当→Sonnet相当の2段、高品質が必要な場合はOpus相当を加えた3段が推奨されます。
Q2: エスカレーション時にStage 1の応答は無駄になりますか？
A2: 基本的にはStage 1の応答は破棄されます。ただし、Stage 1の応答をStage 2へのコンテキスト（「以下の回答を改善してください」）として渡す「リファインメント型カスケード」も存在します。この方式はStage 2の品質向上に寄与しますが、入力トークン数が増加します。
Q3: カスケードルーティングはリアルタイムアプリケーションに向いていますか？
A3: エスカレーション発生時のレイテンシ増加（2-3倍）を許容できるかによります。チャットボットなど対話型アプリケーションでは体感品質に影響するため、エスカレーション率を10-15%以下に抑える閾値設定が重要です。バッチ処理や非同期タスクでは問題なく適用できます。