メインコンテンツまでスキップ

モデルルーティングパターン:カスケード、分類器、そして実際に本番投入されるもの

中級

プロダクトが 1 種類以上の仕事をするようになった瞬間から、あらゆるリクエストに対して単一のモデルが正解ではなくなります。チケットを分類する、フィールドを抽出する、返信を下書きする、レビューする——これは 4 つの別の仕事で、それぞれコスト・レイテンシ・品質の予算が違います。2026 年に業界全体が収束したパターンは、各リクエストをその仕事に合ったモデルへルーティングし、安いモデルでは不十分なときにエスカレーションするというものです。このページはそれらのパターンの編集ガイドです:何なのか、いつ本番投入されるのか、うまくいくレシピ、そして避けるべき失敗モードを扱います。

What you'll learn
  • 本番に投入される 6 つのルーティングパターンと、それぞれをいつ使うかを知る
  • ルーティング(前もって 1 回だけ決める)とカスケード(失敗したらエスカレーションする)の違いを理解する
  • コピペで使えるプロンプトと 1 週間のロールアウト計画で、最初の分類器ルーターを構築する
  • コストの計算を読む:ルーティングが本当にお金を節約するのはいつか、そしてオーバーヘッドが節約分を食いつぶすのはいつか
  • ルーターを障害の火種に変えてしまうアンチパターンを見抜く

なぜ 2026 年にルーティングがデフォルトのパターンなのか​

「あらゆることを 1 つの巨大モデルで」の時代は静かに終わりました。3 つの力がこの変化を推し進めました。

  • 広く、行儀のよい価格カーブ。 主要プロバイダはいずれもファミリーを揃えています——Anthropic(Haiku / Sonnet / Opus)、OpenAI(small / mid / frontier)、Google(Flash / Pro)、加えてオープンウェイトの階層。安い階層はフロンティアより 10〜100 倍安く、限定的なタスクではわずかしか劣りません。安い階層を遊ばせておくのは、お金を燃やしているのと同じです。
  • 現実のレイテンシ予算。 サポートエージェントの前に置く分類ステップは 300 ms 以内に答える必要があります。フロンティアモデルはコスト以外の理由でも間違ったツールになりがち——その工程には単純に遅すぎるのです。
  • 専門化。 異なるモデルが異なるタスクで本当にリードしています——構造化 JSON に強いもの、長文コンテキストに強いもの、コードに強いもの、多言語に強いもの。ランキングは毎月入れ替わりますが(モデルを選ぶ を参照)、「仕事ごとに違うツール」という形は長持ちします。

結果:モデルの前に置くルーターが、リクエストごとに仕事の送り先を決めるようになりました。以下はそのルーターの設計語彙です。

2 大ファミリー:ルーティング対カスケード​

以下のほぼすべてのパターンは、2 つのアイデアのバリエーションです。この違いさえ押さえれば、あとは呼び名の問題です。

  • ルーティングはモデルが走る前に、前もって 1 回だけ決定します。分類器(ルール、小型モデル、大きめのモデルのいずれか)がリクエストを読んでターゲットを選び、引き渡します。定常状態では速く安いですが、分類器が間違ったら答えも間違いで、それが分かるのは後になってからです。
  • カスケードはまず安いモデルを走らせ、定義された合図が「この答えは不十分だ」と告げたときにだけ、より強いモデルへエスカレーションします。合図が実際の出力に根ざしているのでロバストですが、エスカレーションのたびに両方のモデルにお金を払います——だから、安い階層が単独でトラフィックのほとんどをさばけるときにだけ勝ちが残ります。

両者は組み合わさります。本番システムはたいてい両方やります:タスク種別に基づいて正しいレーンにルーティングし、レーンの中で安いモデルの信頼度に基づいてカスケードする。Anthropic の分類では、前段の決定を「Routing」、動的な分解を「Orchestrator-Workers」と呼びます。カスケードは同じ発想の「まず小さく試して、失敗したらエスカレーション」派生に対する業界通称です。

実際に本番投入される 6 つのパターン​

1. ルールベースルーティング​

手書きのルール(正規表現、キーワード、リクエストフィールド、メッセージ長)がターゲットを決めます。決定のためにモデルは走りません。

  • 勝つとき。 シグナルが明瞭で安いとき:「リクエストにコードフェンスが含まれていたらコーディングモデルへ送る」「顧客が Enterprise プランならフロンティア階層へ送る」「入力が 200k トークン超なら長文コンテキストモデルへ送る」。
  • 壊れるとき。 ドメインが変化するとルールは静かに腐ります——新しい言い回し、新しい意図、正規表現が想定していなかったエッジケース。あらゆる「もし X なら Y」は小さな技術的負債です。
  • 投入する条件。 高価値の切り出しが 1〜2 個あり(有料階層、コードパス、言語)、レイテンシのオーバーヘッドをゼロにしたいとき。

2. 分類器ルーティング(LLM をルーターとして)​

小さくて速いモデルがリクエストを読み、ラベルを返します——"billing" | "technical" | "sales" | "other"——これで下流のハンドラーが選ばれます。Anthropic はこれを代表例のひとつに挙げています:簡単な質問を Haiku へ、難しいものを Sonnet へ。

  • 勝つとき。 カテゴリの集合が小さく安定していて、それぞれが独自のプロンプト/ツールセット/モデルに値するとき。カテゴリごとに専門化された 1 つのプロンプトのほうが、なんでもやる巨大システムプロンプト 1 個より強いのです。
  • 壊れるとき。 カテゴリが重なる(現実の多くのリクエストは「請求 かつ 技術」)、分類器が黙って誤ルーティングする、あるいはラベル集合が 10 カテゴリ以上に膨らんで選択が雑音まみれになる。
  • 投入する条件。 リクエストの上位 5〜8 種を列挙でき、それぞれが別ハンドラーから実質的に恩恵を受けるとき。

分類器ルータープロンプト(Claude/GPT/Gemini で互換)

You are a request classifier for a support product.

Read the CUSTOMER MESSAGE below and return a JSON object with:
- "category": one of ["billing", "technical", "account", "sales", "other"]
- "confidence": a number from 0.0 to 1.0
- "reason": one short sentence explaining the pick

If you are less than 0.7 confident, use "other" and say why.
Return ONLY the JSON, no prose, no code fence.

CUSTOMER MESSAGE:
"""
{{message}}
"""

3. 複雑度ベースルーティング​

リクエストの内容ではなく、どれだけ難しいか——長さ、エンティティ数、数値やコードへの参照、ツール使用の可能性——を推定し、それに応じて階層を選びます:易しいものは安価、中程度は中位、難しいものはフロンティア。

  • 勝つとき。 タスク種別はおおむね均質(たとえば「コーディングの質問に答える」)なのに、個別のリクエストの難易度が大きくばらつくとき。2 行の構文質問にフロンティア価格を払う代わりに、そういうものは Haiku 価格で処理し、フロンティアは複数ファイルにまたがるリファクタリング用に取っておきます。
  • 壊れるとき。 「難易度スコア」の正体が「プロンプト長」で、長いプロンプトが必ずしも難しいプロンプトではない場合。ユーザーが巨大なスタックトレースを貼って、それについて些細な質問をする——ルーターは無用にアップグレードします。
  • 投入する条件。 タスク種別内で難易度に計測可能なばらつきがあり、それと相関する明確なシグナル(長さ、コードの有無、サブ質問の数)があるとき。

4. カスケード(安いモデル優先、失敗時にエスカレーション)​

まず安いモデルを試します。答えを失敗シグナルと照合します。失敗していたら、より強いモデルで再試行します。これは業界が他のどのパターンより多く本番投入しているパターンです。なぜなら「シグナル」がモデルが実際に言ったことに根ざしているから——何を言うだろうという推測ではなく。

  • 何がシグナルになるか? 安くて信頼できるものならなんでも:JSON 出力のスキーマ検証、LLM ジャッジによる「これは質問に答えているか?」チェック、モデルが不安なときに出せる明示的な "needs_help": true フィールド、コードを走らせる下流のテスト、プロバイダが露出するときの回答トークンの低い logprob。
  • コストの計算。 節約が生き残るのは、安い階層がトラフィックの大半をさばけるときだけです。安いモデルでリクエストの 90% が解決され、10% だけがエスカレーションするなら、あなたは 0.9 × cheap + 0.1 × (cheap + strong) ≈ ほとんど cheap を払います。半分がエスカレーションすると、常に強いモデルを使うより多く払っていることになります。
  • 勝つとき。 「これでうまくいったか?」の明確なシグナルがあるタスク——走るか走らないコード、検証を通るか通らない JSON、フィールドがソースに一致するかしない抽出。
  • 壊れるとき。 安いモデルの失敗シグナルがない、あるいは安いモデルが成功していないのに成功したと思っている(サイレント失敗——最悪ケース)。
  • 投入する条件。 失敗シグナルを 1 文で言い表せ、そのチェックに強いモデルが必要ないとき。

5. アンサンブル/検証と多数決​

同じリクエストを N 個のモデルに並列に投げて、答えを整合させます——多数決を取る、最初にスキーマが通ったものを取る、N 個全部をジャッジモデルに渡してベストを選ばせる、のいずれか。

  • 勝つとき。 コストやレイテンシより品質が重要なとき:法務リサーチ、医療の要約、大きな金銭の絡む財務抽出、「この契約書の赤旗をレビューして」。異なるモデルが異なる間違いを犯し、それらの共通部分が単一モデルより信頼できる、難しい数学とコードにも有用です。
  • 壊れるとき。 コストを N 倍払い、あらゆるリクエストで最遅モデルのレイテンシを引き受けることになります。アンサンブルは品質のために受け入れる税であって、お金を節約する方法ではありません。
  • 投入する条件。 答えを間違えるコストが、N 回のモデル呼び出しコストより少なくとも 1 桁大きいとき——コンシューマトラフィックではまずないし、エンタープライズワークフローでは往々にしてそうです。

6. フォールバック(コストではなく可用性)​

まずプライマリを試す。429/5xx/タイムアウト時に、透過的に別プロバイダのセカンダリで再試行する。これは他のパターンをまったく使わなくても、真面目なマルチモデルアプリなら必ず必要なパターンです。

  • 勝つとき。 プライマリプロバイダに障害があったり、最悪のタイミングでレート制限されたりするたび。フォールバックは信頼性パターンであってコスト最適化パターンではありません——セカンダリはたいてい、より安いモデルではなく別プロバイダの同等階層です。
  • 注意点。 フォールバックパスはほとんどの時間、動作確認されていないコードです。必ず退行します。少なくとも本番トラフィックのわずかな割合を継続的にセカンダリへ通して、レスポンス形状がドリフトしていたことを、障害時に頼る前に発見できるようにしてください。
  • 投入する条件。 あなたの稼働率 SLO が単一プロバイダのそれより高いとき、あるいは単一プロバイダ依存が事業リスク(契約、リージョン可用性、地政学)であるとき。

一目でわかる比較​

パターン決定のタイミングレイテンシ増?コスト増?主なリスク
ルールベースモデル実行前なしなし入力の変化とともにルールが静かに腐る
分類器実行前、小型モデルで+高速呼び出し 1 回+安価呼び出し 1 回カテゴリが重なると誤ルーティングする
複雑度ベース実行前、ヒューリスティックで無視できる無視できる「難しさ」がしばしば「長さ」を意味する
カスケード安いモデルが試した後+エスカレーション時の再試行定常状態ではほぼ cheap誤答でサイレントに成功扱い
アンサンブルN 個を並列実行し整合N 個中最遅N 倍品質を買っているのであってコストを節約していない
フォールバックプライマリ失敗時のみ正常系では 0正常系では 0重要になるまで動作確認されない

実際の本番投入レシピ​

上のパターンはレゴです。本番では組み合わさります。繰り返し目にする 3 つのレシピ:

  • カスタマーサポートエージェント。 分類器ルーターがレーン(billing / technical / account / sales)を選び、レーンごとに独自のシステムプロンプトとツールセットを持ち、technical レーンの内側ではカスケードがまず安いモデルを試し、「エスカレーションが必要」ツール呼び出しが発火したらフロンティアへエスカレーションします。全体をプロバイダ横断のフォールバックで包む。結果:トラフィックの 70〜90% はフロンティアモデルに触れないまま処理されます。
  • コーディングアシスタント。 ファイル種別と diff サイズに対するルールベースルーティングが、小さな編集を安価階層へ、複数ファイルのリファクタリングをコーディング特化モデルへ送ります。出力に対するカスケード——「パッチはクリーンに当たり、スモークテストを通るか?」——が失敗をより強いモデルへエスカレーションします。Claude vs GPT vs Gemini for coding のフィールドガイドと比較してください。
  • ドキュメントコーパスに対する RAG QA。 分類器が「コンテキストから答える」(cheap)と「クロスドキュメント推論が必要」(mid)を選び分けます。重要度の高い文書(契約書、届出)については、2 モデルのアンサンブルが回答を相互チェックします。検索拡張生成 と比較してください。

最初のルーターを 1 週間で構築する方法​

Guided walkthrough1 of 7
  1. あなたのプロダクトが実際に送っている*本物の*プロンプトを計測してください。少なくとも数百件、理想的には結果(解決/エスカレーション/誤答)で分類されたものが必要です。地に足のついたトラフィックがなければ、ルーターの送り先は推測でしかありません。

実際に何がデプロイされているか(2026 年フィールドノート)​

  • 学習型ルーターより、カスケードのほうがはるかに多く本番投入されている。 RouteLLM のような研究システムは選好データでルーターを学習し、標準ベンチマークでコストを 2 倍以上削れる場合があります(RouteLLM 論文 参照)——ただし学習型ルーターの訓練と保守は本物のエンジニアリングです。ほとんどのチームは、cheap 優先+明示的エスカレーションでほぼすべての勝ちを得ています。
  • 分類器はほぼ常に安価なチャットモデルであって、fine-tune ではない。 良いプロンプトを与えれば、Haiku クラスや Flash クラスのモデルは 5〜8 カテゴリで精度基準を満たします。fine-tune するのは、規模が十分にあり、かつ安価な分類器がボトルネックになったときだけです。
  • 評価器のほうがルーターより重要。 指標ループのないルーターは推測でしかありません。あらゆるルーティング決定を リクエスト → 選ばれたモデル → 結果 で計装し、週次でレビューしてください。計測できないものはチューニングできません。
  • インフラと設計は分離できる。 上記のパターンは言語やプロバイダに中立です。配管——プロバイダごとの 1 エンドポイント、仮想キー、チーム別の支出上限、プロンプトキャッシュ——は AI ゲートウェイが提供するものです。欲しいパターンが分かったら、具体的な選択については AI ゲートウェイ:LiteLLM、OpenRouter、Portkey、Vercel を参照してください。

避けるべきアンチパターン​

  • フロンティアモデルを呼ぶ分類器。 レーンを選ぶのに強いモデルを走らせるのと同じコストがかかるなら、あなたは何も節約しておらず、レイテンシを追加しただけです。分類器は安くなければなりません。
  • 失敗シグナルのないカスケード。 「安いモデルが何か返した、だから終わり」はシグナルではありません——賭けです。あらゆるカスケードには、安いモデルが失敗しうる定義されたチェックが必要です。
  • ルールの増殖。 10 個のルールは管理可能です。100 個はテストのない手コード分類器です。ルールセットがおおよそ 15 分岐を超えたら、破り捨てて小型モデルを使ってください。
  • コスト戦略としてのアンサンブル。 お金を節約するために 3 モデルを並列に走らせるのはカテゴリエラーです——アンサンブルは品質を買うために N 倍かかるのであって、コストを節約するためではありません。悪いプライマリモデルを補うためにアンサンブルを使っているなら、そのプライマリを修正してください。
  • フォールバックパスがない。 すべてのモデルプロバイダはいずれ落ちます。単一プロバイダのプロダクトはその障害を引き継ぎます。配管については AI ゲートウェイ を参照してください。
  • 可観測性のないルーティング。 何もかも間違ったレーンへ静かに送るルーターは、2 週間後に品質が急降下するまで問題なく見えます。あらゆる決定を、入力ハッシュ、選ばれたモデル、結果、コストとともに記録し、週次でレビューしてください。

理解を確認する​

Check yourself

0/3
  1. サポート製品を持っていて、リクエストの 90% は安いモデルで正しく答えられるが、残り 10% はフロンティアが必要だとする。最大のコスト勝ちを得るパターンはどれ?
  2. Anthropic の「Building Effective Agents」ガイドはルーティングを次のように定義している:
  3. 分類器ルーターを構築中だ。分類器プロンプトは「精度が重要」だからフロンティアモデルで動かしている。何が問題?

次に​

出典​

  • Anthropic — Building Effective Agents — Routing と Orchestrator-Workers ワークフローの代表的定義。
  • RouteLLM 論文(arXiv 2406.18665) — 選好データで訓練された学習型ルーター。パターンの伸びしろを示すが、ほとんどの本番チームは学習型ルーティングではなく、依然としてルール+分類器+カスケードを投入している。