Cursor Router 使い方 3モードでコスト最大60%減

Cursorが2026年7月22日に公開したCursor Routerが、Autoモードを賢いモデル振り分け機に作り替えました。

公式ブログの見出しには「60% lower cost」が並び、SNSでは早くもコスト削減の期待値が独り歩きしはじめている印象です。

先に結論から言うと、この「60%」を額面通りに受け取ると期待値がズレます。数字の意味と、そもそもどのプランで使えるのかを一次情報ベースで整理しておきます。

Cursor Routerとは何か

Cursor Routerは、CursorのモデルピッカーでAutoを選んだときに裏側で動くリクエスト分類器です。

新しい独立製品として立ち上がったわけではなく、Autoモードの中身を丸ごと差し替えた、という位置づけがいちばん近い。

対応面はdesktop、web、iOS、CLI、SDKまで一通り揃っています。エージェントセッションからチャットまで同じ振り分けロジックが走ります。

ここで先に釘を刺しておくと、Cursor Routerは2026年8月時点でTeamsとEnterpriseプラン限定です。個人のHobby/Pro/Pro+/Ultraでは、Auto自体は使えても、この新しいルーターは有効化されません。個人プランへの展開時期は公式には未発表なので、待ちの姿勢が現実的です。

Intelligence Balance Costの3モードをどう使い分けるか

Autoの内側に3つのサブモードが用意されました。

管理者側は、この3つのうち一部を選択不可にできます。「うちのチームはBalanceだけでいい」といった運用ができるわけですね。

Costモードだけは固定レート課金という別建ての料金体系が入っていて、入力・出力・キャッシュ読み込みそれぞれに固定単価が適用されます。BalanceとIntelligenceは振り分け先モデルの実レートに従うので、Costだけルールが違う点は覚えておいたほうがよいです。

60%と30から50%の読み方

ここが今回いちばん誤解が広がりそうな部分なので、腰を据えて整理します。

Cursor公式ブログで前面に出ている「60% lower cost」は、IntelligenceモードがFable単独運用に対して同等の満足度をどれだけ安く出せたかというA/Bテストの結果です。数百万リクエスト規模で走らせた検証で、基準線はOpus 4.8ではなくFableである点が重要です。

Opus 4.8を基準にすると、話が変わります。Intelligenceは「Opus 4.8とほぼ同コストで満足度+15%」、Balanceは「Opus 4.8比でコスト36%減」という表現になっています。つまりOpus 4.8対比では、コスト削減より品質向上の色合いが強い。

いっぽう、アーリーアクセス企業の実運用ログでは30〜50%の削減率が報告されています。理想条件のベンチマークではなく、実データでの落ち着きどころという意味では、こちらのほうが導入時の期待値として現実的です。

コミット単価の実例も公開されていて、これを1ドル150円換算で並べるとイメージが掴みやすい。

• Intelligence: 6.76ドル（約1,010円）／コミット
• Balance: 4.63ドル（約695円）／コミット
• Opus 4.8単独: 7.34ドル（約1,100円）／コミット
• Fable単独: 12.69ドル（約1,900円）／コミット

Fable単独が突出して高いので、そこと比べれば60%減が出るのは筋が通ります。ただ実務のCursor利用でOpus 4.8全振りの人が突然60%コスト減する話ではない、というのが正しい読み方です。

リクエストをモデルへ振り分ける仕組み

分類器の中身は60万件以上のライブリクエストで学習し、数百万リクエスト規模のオンラインA/Bテストで評価されています。

判定に使っているシグナルは、クエリ内容・与えられたコンテキスト・タスクの複雑度・ドメイン。この4軸で「今のリクエストならこのモデルが最適」を毎回選び直しています。

面白いのは、キャッシュミスのコストまで計算に入れているところです。同じ品質が出せるモデルが2つあるとき、直近のセッションでキャッシュが効いているほうへ寄せる、といった判断が自動で入ります。エージェントが長い文脈を持ち運ぶ現場では、この設計がじわっと効いてきます。

報酬関数はユーザー満足度。単純なコード生成の成功率ではなく、ユーザーがそのまま採用したか、続けて追加リクエストを投げたかを見て最適化しています。人間側の受容率で強化学習を回している、と読めばだいたい合っています。

CursorのラインナップにGrok 4.5が組み込まれた意味もここに絡みます。低コスト帯の選択肢が広がったぶん、Balance/Costモードで振り先を増やせる。ルーターは選べる駒が多いほど賢く動くので、モデルカタログが揃ってきたタイミングで公開された、というのは実に納得できる順序です。

個人のPro Ultraプランではまだ使えない

ここは期待値を最初に揃えておかないと、あとで肩透かしを食らいやすい箇所です。

• Teams: デフォルトON（管理者が明示的にOFFにしない限り有効）
• Enterprise: デフォルトOFF（管理者が有効化して初めて動く）
• Hobby / Pro / Pro+ / Ultra: 非対応

個人プランでAutoを使っている場合、見た目は同じAuto表記でも、内側で走っているのは旧来の振り分けロジックです。ここを混同すると「自分のPro+アカウントで60%コスト減が来ない」といった話になりがちなので、注意が要ります。

個人開発者側の現実的な選択肢は、ざっくり3つです。

1. Teamsプラン（3人以上から契約可能）を組んで自分1人で入る
2. Cursor外のマルチモデルゲートウェイ（Ramp Router、OpenRouterなど）に切り替える
3. 個人プラン展開のアナウンスを待つ

私は業務システム側の案件で使っているアカウントがTeams構成なので、Cursor Routerは既にBalanceで回しています。実務の体感では、Opus 4.8を意識的に選ぶ回数が明らかに減りました。振り分け精度が悪くない、というのが率直な評価です。

Cursor Originとの違いとCursorのインフラ戦略

Cursorはここ数ヶ月で、エージェント時代のインフラをコード管理層とモデル選択層の両方から整えにきています。

コード管理層がCursor Origin、モデル選択層がCursor Routerという整理が、いまのところ座りがいい。

GitHubでは無理だった——Cursor Originがエージェント時代の新Gitフォージを発表した理由

こんにちは。もるふぉです。Cursorのエージェントを並列で走らせた翌朝、PR一覧が真っ赤に染まっていたことはありませんか。マージ衝突、CIの失敗、レビューが追いつかない通知の山——エージェントが仕事をすればするほど、人間の処理が後ろに積み上がっていくあの構造です。Cursorは2026年6月16日、サンフランシ...

aimanavo.com

Originは、複数エージェントが並列でコミットしても衝突が積み上がらないGitフォージ。Routerは、そのエージェントたちが投げるリクエストをコストと品質の観点で最適配分する分類器。両方が揃うと、エージェントを大量に走らせるほど下流の詰まりが増えるという現在の構造問題を、レイヤー横断で解体しにいける絵になります。

Cursor外のマルチモデルゲートウェイ（Ramp Router、OpenRouterなど）との棲み分けもここで整理できます。あれらはCursor以外のエディタやAPIコールも横断して扱う汎用ゲートウェイ。いっぽうCursor RouterはCursor内部専用で、Cursorのモデルカタログとキャッシュ状態を前提に組まれている。だから振り分け精度は高いが、Cursorから出た瞬間に使えない。この違いは導入判断に直結します。

導入判断と様子見の分かれ目

いま導入を進めて損がない層は、Teams/Enterpriseで既にCursorを標準採用しているチームです。Autoの中身がアップグレードされる、というのが実態なので、有効化コストがほぼゼロで恩恵だけ乗ります。管理者は最初Balanceをデフォルトに置いて、必要なチームだけIntelligenceを許可する構成が無難です。

いっぽう様子見が現実解になるのは、個人プランのユーザーです。Cursor社が個人プラン展開のアナウンスを出すまでは、期待値だけ膨らませず、いまのAutoで回しつつ発表を待つのが妥当です。

数字の一次情報として持っておきたいのは、60%はFable比のA/Bテスト理想値、30〜50%が実運用の落ち着きどころという2段構えの事実。この区別ができていれば、SNSやニュース記事で「60%コスト削減」だけが独り歩きしても、自チームの試算をブレさせずに済みます。

Cursorはここ半年、コード管理からモデル選択まで、エージェント運用のボトルネックを一つずつ潰しにきています。個人プランに降りてくる日を、静かに待ちましょう。