CursorのAutoモードは2026年7月22日のアップデートで「Cursor Router」によるモデル自動振り分けへと切り替わり、Intelligence・Balance・Costの3つの最適化モードから品質とコストの釣り合いを選べるようになりました。課金面の最重要ポイントは2つです。BalanceとIntelligenceは「実際に振り分けられたモデルのAPIレート」で課金されること、そしてTeams/Enterpriseプランではサードパーティモデルへのルーティング時に100万トークンあたり0.25ドルのCursor Token Rateが上乗せされることです。Costモードだけは、どのモデルに振り分けられても100万トークン単位の定額です。
「Autoに任せると、どのモデルが使われていくらかかるのか分からない」、、、Cursorをチームで使っている開発者から、この不安は以前からよく聞かれました。今回のCursor Router導入は、その不透明さに「モードという抽象レイヤー」で答えを出した形です。モデル名を選ぶのではなく、求める品質水準を選ぶ。この設計思想の転換は、Cursorの課金の読み方も、チーム管理者の仕事も変えます。
公式チェンジログと公式ドキュメント（models・pricing）を突き合わせて、仕組み・3モードの違い・課金・管理者制御・汎用ルーターとの違いまで順に確認していきましょう。
Cursor Routerは何を自動化するのか
Cursor Routerは、公式チェンジログ（2026年7月22日付）で「our intelligent model router. It analyzes each request and sends it to the right model for the job（各リクエストを解析し、その仕事に適したモデルへ送るインテリジェントなモデルルーター）」と説明されています。従来のAutoモードもモデル選択を隠蔽する仕組みでしたが、今回の変更で「Routerという名前を持つ独立したコンポーネント」として明示され、挙動を3つのモードで制御できるようになった点が新しいところです。
公式ドキュメント（Models）には「On Teams and Enterprise plans, Cursor Router picks the model for each Auto request based on your optimization mode（Teams/Enterpriseプランでは、Cursor Routerが最適化モードに基づいてAutoリクエストごとにモデルを選ぶ）」と明記されています。つまり判定の単位は「リクエストごと」です。同じセッション内でも、簡単な補完と重いリファクタリングでは別のモデルに振り分けられ得る、ということです。
有効化の既定値はプランによって異なります。チェンジログによると、TeamsプランではRouterが既定でオンになり、Enterpriseでは管理者がダッシュボードから有効化するオプトイン方式です。Enterpriseで「あれ、うちはAutoの挙動が変わってないな」という場合は、管理者がまだ有効化していない可能性が高いでしょう。
Cursorのエージェント機能そのものの使い方はCursor Agentの使い方｜自律コーディングの設定と実力で解説しているので、Autoモード自体に馴染みがない方はそちらから読むのがおすすめです。
Intelligence・Balance・Costの3モードを比べる
3つのモードは「品質の天井」と「課金方式」の組み合わせで整理すると分かりやすいです。公式チェンジログの原文定義と合わせて表にまとめます。
| モード | 公式の品質定義（原文要旨） | 課金方式 | 向いている用途 |
|---|---|---|---|
| Intelligence | 「Frontier quality」— 日常使いには手が届きにくい、最も高価で強力なモデル群に匹敵する品質 | 振り分け先モデルのAPIレート（従量） | 設計判断、大規模リファクタ、難易度の高いデバッグ |
| Balance | 「Strong quality」— 多くの人が日常的に使いたがるフロンティアモデルに匹敵する品質 | 振り分け先モデルのAPIレート（従量） | 日々の実装・レビューなど標準的な開発作業 |
| Cost | 「Good quality」— トークン支出を最適化しながら、その範囲で到達できる最高の知能を狙う | モデルに関係なく100万トークン単位の定額 | 補完中心の軽作業、コスト上限を読み切りたい大量処理 |
チェンジログには「Each mode moves you along the cost-intelligence pareto frontier（各モードはコストと知能のパレートフロンティア上を移動させる）」という表現があります。ポイントは、3モードが「良い・普通・悪い」の序列ではなく、「同じ予算効率カーブ上のどこに立つか」の選択だという点です。Intelligenceを選んでも無駄遣いになるわけではなく、高い品質が本当に必要なリクエストに高いモデルを充てる、という位置づけです。
実際に検証環境でモードを切り替えながら使ってみると、体感が変わるのは「重いタスクを投げたときの初手の精度」です。Balanceでも日常のコーディングはほぼ困りませんが、複数ファイルにまたがる設計変更のようなタスクではIntelligenceとの差を感じる場面がありました。逆に、コード補完やコミットメッセージ生成のような軽作業でIntelligenceを使うのは明らかに過剰です。モードは固定ではなく、タスクの重さに応じて切り替える運用が現実的でしょう。
課金はどう変わるか：Cursor Token Rateに注意
今回の変更で課金面の理解が最も重要です。公式のPricingドキュメントから、確認できた事実を整理します。
- Auto Cost：「Auto Cost pricing is set per million tokens, regardless of which model is used（どのモデルが使われるかに関係なく、100万トークン単位で価格が設定される）」。定額なので支出の予測が立てやすいモードです。
- Auto Balance / Auto Intelligence：「charged at Model API rates for the model used, based on actual usage（実際に使われたモデルのAPIレートで、実使用量に基づいて課金）」。振り分け先次第で単価が変わります。
- Cursor Token Rate：Teams/Enterpriseプランでは、サードパーティモデルへのリクエストに「100万トークンあたり0.25ドル」の手数料が加算されます。これはモデルを直接指定した場合だけでなく、BalanceやIntelligenceがサードパーティモデルにルーティングした場合にも適用されます。
- 適用除外：Auto Costと、Composer 2.5・Grok 4.5・Grok 4.6を含むファーストパーティ扱いのモデルはCursor Token Rateの対象外と明記されています。
つまりBalance/Intelligenceの実効コストは「振り分け先モデルの単価 + （サードパーティなら）0.25ドル/100万トークン」です。どの程度の差になるかを手元で試算できる簡単なスクリプトを用意しました。単価は変動するため、値は必ず公式Pricingページの最新値に差し替えてから使ってください。
月間トークン量とモデル単価から、モードごとの概算コストを比較するPythonスクリプトです。
# Cursor Autoモードのコスト試算スクリプト
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 単価は必ず https://cursor.com/docs/account/pricing の最新値に置き換えること
CURSOR_TOKEN_RATE = 0.25 # USD / 100万トークン（Teams/Enterpriseのサードパーティ加算・2026-08-13時点）
def estimate_monthly_cost(
monthly_tokens_m: float, # 月間トークン量（単位: 100万トークン）
model_rate_per_m: float, # 振り分け先モデルのAPIレート（USD/100万トークン・公式値を入れる）
third_party: bool, # サードパーティモデルへのルーティングか
auto_cost_flat_per_m: float, # Auto Costの定額単価（USD/100万トークン・公式値を入れる）
) -> dict:
balance_intel = monthly_tokens_m * (
model_rate_per_m + (CURSOR_TOKEN_RATE if third_party else 0)
)
auto_cost = monthly_tokens_m * auto_cost_flat_per_m
return {
"balance_or_intelligence_usd": round(balance_intel, 2),
"auto_cost_usd": round(auto_cost, 2),
"diff_usd": round(balance_intel - auto_cost, 2),
}
# 例: 値はダミー。公式ページの実単価に置き換えて実行する
print(estimate_monthly_cost(
monthly_tokens_m=50,
model_rate_per_m=0.0, # ← 公式値に置換
third_party=True,
auto_cost_flat_per_m=0.0, # ← 公式値に置換
))
動作環境：Python 3.11以上（追加パッケージ不要）
ポイントは次の3つです。
- 単価をハードコードで信じない。AI関連の料金は月単位で変わるため、実行のたびに公式値を確認するのが安全です。
- Cursor Token Rateは「サードパーティかどうか」で効いてくるため、後述の管理者設定でモデルの許可/ブロックを絞ると、コストのブレ幅も絞れます。
- トークン量の実測がなければ試算は始まりません。使用量の可視化はAIエージェントのコスト監視入門で扱った考え方がそのまま使えます。
なお、Cursorのコスト表示まわりは過去に方針変更で議論を呼んだ経緯があります。経緯を知っておくと今回の「モードで抽象化する」という方向性の意味も見えやすいので、Cursorがコスト情報を削除した理由と代替追跡法もあわせてどうぞ。
管理者が設定できる4つの制御
チーム導入の観点では、今回のアップデートは「管理者向け機能」としての側面がかなり大きいです。チェンジログによると、管理者は次の4つを設定できます。
- チーム/グループ単位での有効化：Routerを組織全体ではなく、チームやグループごとにオン/オフできます。まず一部チームで試験導入する、という段階的な展開が可能です。
- 利用できるモードの制限：メンバーが使える最適化モードを絞れます。たとえば「一般メンバーはBalanceとCostのみ、Intelligenceはリード層だけ」といった線引きができます。
- 既定モードの指定：組織としてのデフォルトモードを決められます。何も考えずに使うメンバーの支出水準を、管理者側でコントロールできるということです。
- 下位モデルの許可/ブロックリスト：Routerの振り分け先候補となるモデル自体を許可制・ブロック制にできます。コンプライアンス上使えないモデルを候補から外す用途が典型でしょう。
実務での要点は「モード制限」と「モデルブロック」の合わせ技です。Balance/Intelligenceは従量課金なので、放っておくと月末まで支出が読めません。既定モードをCostまたはBalanceに固定し、高単価モデルをブロックリストで外しておけば、支出の上振れリスクをかなり抑えられます。逆にIntelligenceを全員に開放するなら、使用量のモニタリングとセットで運用しないと請求書で驚くことになります。
導入前に確認したいつまずきポイント
つまずき1：Autoに任せた＝定額だと思い込む
❌「Autoモードなんだから料金は一定でしょ」
⭕「定額なのはCostモードだけ。Balance/Intelligenceは振り分け先モデルの従量課金＋サードパーティならToken Rate加算」
なぜ重要か：旧来の「Auto＝おまかせ」の感覚のままBalanceやIntelligenceを使うと、振り分け先次第でコストが変動します。モードと課金方式の対応は導入初日にチームへ共有しておきましょう。
つまずき2：Enterpriseで有効化されていないのに検証を始める
❌「TeamsもEnterpriseも同じ挙動のはず」
⭕「Teamsは既定オン、Enterpriseは管理者がダッシュボードで有効化するまでオフ」
なぜ重要か：プランで既定値が違うため、Enterprise環境の検証では「Routerが動いている前提」が崩れていることがあります。検証前に管理画面で有効化状態を確認してください。
つまずき3：モデル直接指定ならToken Rateを回避できると考える
❌「Autoを使わずモデルを手で選べば手数料はかからない」
⭕「Teams/Enterpriseではサードパーティモデルの直接指定にもCursor Token Rateが適用される」
なぜ重要か：公式ドキュメントは「直接指定時」と「Balance/Intelligenceがサードパーティへルーティングした時」の両方に適用されると明記しています。回避手段になるのはファーストパーティモデルの利用かAuto Costの選択です。
OpenRouter・LiteLLMと何が違うのか
「モデルルーター」という言葉からOpenRouterやLiteLLMを連想した方も多いはずです。役割が重なるようで、レイヤーがまったく違います。
| 項目 | Cursor Router | OpenRouter | LiteLLM |
|---|---|---|---|
| 提供形態 | Cursor製品に内蔵 | ホスティング型API（単一エンドポイントで数百モデル） | OSSライブラリ＋自前デプロイのゲートウェイ |
| ユーザーが選ぶもの | 最適化モード（品質水準） | モデルまたは自動ルーティング | ルーティング設定を自分で記述 |
| ルーティングの制御 | モード選択＋管理者の許可/ブロックリスト | 自動フォールバック・コスト最適化を提供側が処理 | 負荷分散・フォールバック・リトライを自分で設計 |
| 主な用途 | Cursor内のコーディング作業 | 自作アプリからの多モデルAPI利用 | 組織のLLM基盤（キー管理・予算・ログ） |
| カスタマイズ性 | 低（モードの粒度まで） | 中 | 高（コードで全制御） |
OpenRouterは公式ドキュメントで「hundreds of AI models through a single API endpoint（単一APIエンドポイントで数百のAIモデルにアクセス）」と説明されるホスティング型のAPIゲートウェイで、自作アプリケーションに組み込む前提のサービスです。LiteLLMは「100以上のLLMをOpenAI形式の統一インターフェースで呼べる」OSSで、自前でプロキシを立ててキー管理・予算管理・ルーティングを構築します。詳しくはLiteLLM製品ガイドで解説しています。
一方Cursor Routerは、Cursorというエディタの内側だけで完結するルーターです。API経由で外から叩くことはできませんし、ルーティングロジックを自分で書くこともできません。その代わり「品質水準を選ぶだけ」という圧倒的に低い導入コストで、ルーティングの恩恵を受けられます。自作エージェントで同じ発想（タスクの複雑さに応じたモデル振り分け）を実装したい場合は、AIエージェントのモデルルーティング設計ガイドが設計・実装コードまで踏み込んでいます。Cursor Routerは、あのガイドで扱った設計をベンダーが製品に埋め込んだ、と捉えると位置づけが明確になります。
正直にお伝えすると、Cursor Routerには「どのリクエストがどのモデルに振り分けられたかをどこまで細かく追えるか」という透明性の論点が残ります。従量課金モードでは振り分け先が請求に直結するため、チーム導入時は請求明細と使用量ダッシュボードでの検証期間を設けることをおすすめします。
よくある質問
Q1. Cursor RouterはTeams/Enterprise以外でも使えますか？
公式ドキュメントのRouter動作に関する記述はTeams/Enterpriseプランを対象としたものです。Teamsでは既定で有効、Enterpriseは管理者による有効化が必要です。個人プランでの提供範囲は変わる可能性があるため、最新の公式ドキュメントで確認してください。
Q2. Auto Costはどのモデルに振り分けられても同じ料金ですか？
はい。公式Pricingドキュメントに「どのモデルが使われるかに関係なく100万トークン単位で価格設定される」と明記されています。またAuto CostはCursor Token Rateの適用外です。
Q3. 特定のモデルに固定したい場合はどうすればいいですか？
Autoを使わず従来どおりモデルを直接指定すればRouterを経由しません。ただしTeams/Enterpriseプランでは、サードパーティモデルの直接指定にもCursor Token Rate（0.25ドル/100万トークン）が適用される点に注意してください。組織として振り分け先を絞りたい場合は、管理者のモデル許可/ブロックリストを使うのが正攻法です。
ここまでの要点
- 2026年7月22日から、CursorのAutoモードはCursor Routerがリクエスト単位でモデルを自動選択する方式になった
- モードは3つ。Intelligence（フロンティア品質）とBalance（日常使いの主力級品質）は振り分け先モデルのAPIレートで従量課金、Cost（定額）はモデルに関係なく100万トークン単位の固定単価
- Teams/Enterpriseではサードパーティモデルに0.25ドル/100万トークンのCursor Token Rateが加算される。Auto Costとファーストパーティモデルは対象外
- 管理者はチーム/グループ単位の有効化、モード制限、既定モード指定、モデル許可/ブロックリストの4つを制御できる。Teamsは既定オン、Enterpriseはオプトイン
- OpenRouter/LiteLLMがAPI・基盤レイヤーの汎用ルーターであるのに対し、Cursor Routerはエディタ内蔵型。カスタマイズ性を捨てて導入コストの低さを取った設計
まず今日やることとしては、自分のプランでRouterが有効かを確認し、既定モードがどれになっているかを見るところからです。チーム管理者であれば、今週中に既定モードとモデル許可リストの方針を決め、1か月分の請求明細でモードごとの実コストを検証してみましょう。
あわせて読みたい：
- Cursor Agentの使い方｜自律コーディングの設定と実力 — Autoモードを含むCursorエージェント機能の基本
- AIエージェントのモデルルーティング設計ガイド — 同じ発想を自作エージェントで実装する方法
参考・出典
- Cursor Changelog（Cursor Router, Jul 22, 2026） — Cursor公式（参照日: 2026-08-13）
- Cursor Docs: Models — Cursor公式（参照日: 2026-08-13）
- Cursor Docs: Pricing — Cursor公式（参照日: 2026-08-13）
- OpenRouter Documentation: Quickstart — OpenRouter公式（参照日: 2026-08-13）
- LiteLLM Documentation — LiteLLM公式（参照日: 2026-08-13）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
