モデルのルーティング: 適切なモデルを、適切な仕事に、適切な価格で
多くのチームは、最先端モデルを必要としない作業にまで、最先端価格を払っています。誰かが見つけた中で最も強力なモデルを選び、それをデフォルトに設定すると、その後のすべてのリクエストが最高料金で処理されます。支出は、リリースされる成果物の品質よりも速いペースで膨らんでいきます。
モデルのルーティングこそが、その解決策です。すべてのリクエストを1つのモデルに送るのではなく、ルーターが各リクエストを見て、それに合ったモデルを選びます。単純な作業は高速で安価なモデルへ。難しく長いホライズンの作業は、最先端モデルへ。
モデルのルーティングは、チームが LLM を活用するうえでの標準的なレイヤーになりつつあります。十分な性能を持つ最も安価なモデルと、最も高価なモデルの差は非常に大きく、しかも日々の作業の大半は簡単な側にあります。うまくルーティングすれば、品質を保ったまま支出を大幅に削減できます。このガイドの残りでは、ルーティングが実際にどう機能するのか、きちんと機能していると判断するには何を測るべきか、そしてそれをどう有効にするかを説明します。
モデルのルーティングが今重要な理由
2つの変化が同時に起きました。幅広い価格帯でモデルの性能が向上し、さらにエージェントがより多くの作業を担うようになったことで、開発者はモデル経由で送るリクエストの数を大幅に増やしました。この組み合わせによって、単一モデルをデフォルトにするとコストがかさみます。
Cursor を使う開発者の約60%が、日常的に使うモデルとして単一のモデルを選んでいます。つまり、定型的な作業が最先端価格で実行されることになり、AI への支出は出力品質の向上よりもはるかに速く膨らんでいきます。Composer 2.5 のようなファーストパーティモデルは、入力100万トークンあたり2.50ですが、最先端モデルはその数倍のコストがかかります。使用量の大半が通常のコーディング作業であるなら、どのモデルをデフォルトにするかが請求額の大部分を左右します。
業界も同じ結論にたどり着いています。Microsoft の Foundry は、コスト、バランス、品質の各モードを備えたモデルルーターを提供しています。RouteLLM のような研究システムでも、最先端品質に近い水準を保ちながら大幅なコスト削減を実現したと報告されています。こうした動きが一斉に広がっているのは、この考え方の合理性が数字の上でも明らかだからです。
ルーティングの前に答えておくべき質問
モデルのルーティングを評価する際は、まず次の点を整理しましょう。上から順に検討してください。
モデルルーターとは何ですか？
モデルルーターとは、ユーザーと複数のモデルの間に入り、各リクエストをどのモデルに処理させるかを選ぶシステムです。リクエスト (プロンプト、コンテキスト、タスクの種類) を読み取り、最も低いコストで適切に処理できる可能性が最も高いモデルに振り分けます。優れたルーターは、単に長さだけを見るのではなく、タスクの種類や複雑度を踏まえて判断します。性能の低いルーターは大ざっぱなルールで振り分けるだけで、本質を見誤ります。
ルーティングはどのように使用するモデルを決めるのでしょうか？
優れたシステムでは、どのモデルを実行する前にも、まず各リクエストを分類します。たとえば Cursor Router は、クエリ、コンテキスト、タスクの複雑度、ドメインに加え、各モデルの振る舞いに関する知見も踏まえて、各リクエストに対して分類器を実行します。UIまわりの作業はコスト効率の高いモデルへ、UIまわりの作業はセンスの最も優れたモデルへ、複雑で長いホライズンの問題は最先端の推論モデルへ振り分けられます。分類は最初に行われるため、高価なモデルが呼び出される前に選択が決まります。
ルーティングは自動にすべきか、それともエンジニアが引き続き選ぶべきか？
どちらも必要ですが、レベルが異なります。各リクエストごとの選択は自動にすべきです。というのも、1日に何百回も手動でモデルを選びたい人はいませんし、適切な答えはタスクごとに変わるからです。チームが求めているのは、コストと品質のトレードオフ全体の中で、どのあたりに位置するかを調整できる手段です。一般的には、いくつかのモード (コスト、バランス、品質) を用意し、それによってチーム全体をそのカーブに沿って動かしつつ、リクエストごとの判断はその裏側で処理する設計が採られます。
ルーティングは品質を損なうのか？
ルーターがコストだけでなく品質でも評価されているなら、その心配はありません。モデルのルーティングでは、難しいタスクは最も高性能なモデルに任せ、簡単なものだけを下位のモデルに振り分けます。Cursorの数百万件のリクエストにまたがるA/Bテストでは、Intelligence modeはユーザー満足度で最先端モデルに迫りながら、コストを約60%削減しました。また、先行アクセス中の企業では、すべてを最上位モデルにルーティングする場合と比べて30〜50%のコスト削減を実現しつつ、品質の低下はありませんでした。ほとんどのリクエストでは、十分によい仕事をするモデルが、必ずしも最も高価なモデルとは限りません。
何を測るべきでしょうか？
リクエストあたりのコストだけでなく、実際の成果につながる作業1単位あたりのコストを見てください。これは、ユーザー満足度 (その人は結果を受け取って先に進めたのか、それとも戻って修正したのか) と、キープ率 (生成されたコードのうち、後になってもどれだけがコードベースに残っているか) によって測定できます。Cursor は最終的な指標としてコミットあたりのコストを報告しています。テストでは、Cursor Router は 6.76 in Intelligence, versus $7.34 for an all-Opus 4.8 baseline を達成しています。コミット あたりのコスト (または PR あたりのコスト) は、支出をリリースされた成果に結び付けられるため、予算の話し合いで持ち出すべき数字です。
ルーティングはキャッシュやモデルの切り替えをどのように扱いますか？
会話の途中でモデルを切り替えると、プロンプトキャッシュが効かず、そのぶんコストが増えることがあります。Cursor は、ルーティング判断によって生じるキャッシュミスのコストを公表している節約額に含めることで、この点を織り込んでいます。ルーターを評価する際は、その数値がキャッシュを織り込んだものかどうかを確認してください。そうでなければ、節約額を過大に見積もっている可能性があります。
Cursor でモデルのルーティングを使う方法
Cursor Router は、Teams プランと企業プランで Auto を支えるモデルのルーティングシステムです。最適化の度合いを選びます。Balance と Intelligence では、ルーターが各リクエストに応じたモデルを選択します。
モードを選びます。 モデルピッカーで Auto を選択し、最適化モードを選びます。Cost はトークン利用コストを最適化します。Balance は日常使いに好まれる最先端モデルに近いバランスを目指し、Intelligence は最上位の品質を重視します。すべての Auto モードは、ルーティングされたモデルの定価で課金されます。
分類は任せます。 Balance と Intelligence では、ルーターは各リクエストを読み取り、タスクの種類と複雑度に応じてルーティングします。難しい作業は最も高性能なモデルに回し、定型的な作業は最先端モデルの料金がかからないようにします。Grok 4.5 は有効にしておく必要があります。ルーターは、最先端モデルを呼び出さない場合のコスト効率のよい選択肢としてこれを使うためです。
ガードレールを設定します (管理者) 。 チームまたはグループごとに Router を有効にし、メンバーが使えるモードを選び、デフォルトを設定し、特定のモデルを許可またはブロックします。Teams プランではデフォルトで有効です。企業の管理者はダッシュボードから有効にします。
数値を確認します。 使用量ダッシュボード で使用量を確認し、どれだけが Cursor のモデル経由で処理され、どれだけがそれ以外なのかを把握したうえで、ロールアウトを広げる前に節約効果が実際に出ていることを確かめます。
次のステップ: モデルピッカーで Auto を有効にし、Balance または Intelligence を選択して、cursor.com/docs/cursor-router で完全な設定手順に従ってください。管理者はチームダッシュボードから Router を有効にし、ガードレールを設定できます。
モデルを仕事に合わせる
モデルのルーティングが機能するのは、普段の作業のほとんどで最も強力なモデルが最適とは限らないからです。仕事に合わせてモデルを使い分ければ、品質水準を維持しつつ、そもそも最先端モデルを必要としない作業のコストを大幅に抑えられます。実際に成果を出すルーターは、実際のタスクの複雑度に応じて振り分け、難しい問題は高性能なモデルに任せ、リリースした変更あたりのコストで自らを評価します。これが今のチームの進め方に合っているなら、まずは稼働の多い1チームでルーティングを有効にし、1週間コミットあたりのコストを見て、その数字をもとにどこまで広げるか判断してみてください。