Cursor 料金とモデルの選び方：10月の変更後に使えるモデル

2026年10月25日確認済み。 Cursorが公開しているモデル、サブスクリプション、Router、サブエージェントのドキュメントに基づきます。ここで押さえたいのは、「モデルを使えること」と「その利用量がプラン料金に含まれること」は別だという点です。

Cursor 料金プラン別に使えるモデルは？

Cursorでは、自社モデルのGrokとComposerに加え、サードパーティのClaude、GPT、Geminiも利用できます。ただし、使えるモデルはサブスクリプションによって異なります。 現行のサブスクリプション体系「The X Subscription」では、有料アカウントにGrokと共有するCursorモデルの週次利用枠が付与されます。サードパーティモデルへのリクエストにはプリペイドクレジットを使います。この区分はCursorの現行モデル資料に記載されています。

以下の表では、現行プランと旧プランを分けて示します。「プランに含まれる」とは所定の利用枠を消費するという意味で、リクエストが無制限になるわけではありません。Freeには利用制限があり、有料プランの利用枠はアカウントによって異なります。

出典：利用可能なモデル、現行サブスクリプション、旧プラン。TeamsとEnterpriseでは、対象のサードパーティリクエストにCursor Token Rateも加算されます。対象外のリクエストもあるため、除外リストの確認が必要です。個人アカウントには、この追加料金はかかりません。

Cursorの公表価格によると、個人向けプランの税別月額はFreeが$0、Plusが$8、Premiumが$30、Superが$100、Ultraが$200です。利用枠、チームのシート料金、旧プランの詳細はCursorの料金解説を参照してください。

Cursorの無料モデルとPlusの制限

Freeは自社モデルを試すためのプランで、Plusは自社モデルによるコーディングに用途を絞ったプランです。 PlusではFastがオフ、推論の思考量がmediumに固定され、Grok 4.7のコンテキストウィンドウは256kです。Auto、サードパーティモデル、自分のAPIキーは利用できません。これらはプランに明記された制限なので、Claudeが選択肢にないからといって、インストールに問題があるとは限りません。

Composerで小さな変更を加える開発者なら、この範囲で足りる場合もあります。一方、ClaudeやGPTを使うことが前提のワークフローでは、出力品質を比べる以前にPlusは要件を満たしません。加入前に、どのモデルを使う必要があるかを決めておきましょう。

Premium以上と旧プランで変わる利用枠

Premium以上ではサードパーティモデルを使えますが、新サブスクリプションにはその利用枠が含まれていません。 既存のPro、Pro+、旧Ultraアカウントは扱いが異なり、毎月のOther Models枠で、モデルのAPI定価に基づくサードパーティ利用をまかなえます。その枠を使い切った後は、オンデマンド利用を有効にしていれば追加料金で使い続けられます。違いはCursorの旧プラン資料に明記されています。

新プランは、定番メニューが会費に含まれ、外部シェフの料理は別料金になる会員制サービスのようなものです。旧プランには、その外部シェフの料理にも使える枠があります。同じモデル名が両方のアカウントに表示されても、差し引かれる残高は異なるわけです。

旧プランを契約しているなら、移行前にサードパーティモデルの実際の利用量を確認してください。Cursorによると、新サブスクリプションへの切り替えは任意ですが、切り替えると元には戻せません。最もよく使うモデルがClaudeなら、自社モデルの枠が増えても、プランに含まれていたClaudeの利用枠の代わりにはなりません。

Cursorのおすすめモデルは？日常作業と難しいタスクで使い分ける

モデルは、作業がどこでつまずくかに合わせて選びます。応答が遅いのか、長い作業を完遂できないのか、それとも特定モデルの振る舞いが必要なのか、という切り分けです。 Cursorのモデル選択ガイドは、対話型のコーディングにはComposer、特に難しく時間のかかるタスクにはGrok 4.7、複雑な複数ステップの作業にはClaude OpusまたはGPT-5.6 Solを勧めています。以下では、その指針を日々の開発に当てはめて考えます。

Composer 2.5：編集の方向を自分で示しながら進めるなら、まず試したいモデルです。 Cursorは、ツールの使用、ファイル編集、ターミナル操作に合わせて調整したモデルと説明しています。モデル紹介ページには、200kのコンテキストウィンドウ、対話向けの高速版、トークンコストを抑える標準版が記載されています。

失敗するテストが明確なコンポーネントの変更は、試しやすい題材です。最小限の変更を依頼し、差分を確認しながら対話を進めます。根本原因が解決しないまま修正を繰り返すようになったら、そこで立ち止まりましょう。成果の出ない対話を延々と続けるより、仕様を具体化するか、より適したモデルに切り替えます。「Composer」を単一の利用特性で捉える前に、速度設定も確認してください。

Grok 4.7：粘り強い調査と検証が必要なタスクに向いています。 Cursorによると、Grok 4.6に比べて自己検証と長時間にわたる作業が改善されています。複数ファイルにまたがる認証処理の変更は、その粘り強さが問われる作業です。エージェントはリクエストハンドラ、セッション処理、テスト、エラー時の処理を関連づけて確認する必要があります。任せる前に、何を検証すべきかを定義しておきましょう。

Grok 4.7の資料では、標準のコンテキストが256k、最大が500kと区別されています。単位はトークンで、モデルが処理するテキストやコードのまとまりを指します。コンテキストは、リクエストごとにモデルが参照できる情報量です。ただし、容量が大きくても、重要な依存関係に気づく保証はありません。ファイルを増やすだけでなく、問題の起きる挙動と完了条件を伝えることが大切です。

Grok 4.6とGrok 4.5：既存のワークフローで成果が出ているなら、引き続き使う理由があります。 Cursorは今も両方を掲載していますが、Grok 4.6のページでは、自己検証や長時間の作業を重視するなら4.7を推奨しています。新たな難題に取り組む際、慣れているというだけで旧バージョンを標準にする理由はあまりありません。同時に、うまく動いているワークフローを、代替モデルの評価もせずに変える理由もありません。移行の判断についてはGrok 4.7とGrok 4.6の比較で詳しく扱っています。

Claude OpusとGPT-5.6 Sol：複雑な作業や別のアプローチが必要なときに、目的を持って選びます。 別モデルの解釈が役立つ問題では、選択肢として価値があります。切り替える際は、タスクと受け入れテストの条件をそろえてください。説明の説得力ではなく、結果を比較できるようにするためです。

CursorのGPT-5.6 Solのページでは、粘り強いエージェント作業や、計画・デバッグに関する簡潔な応答が紹介されています。一方で、サブエージェントを使いすぎることや、実行を明示的に指示されるまで待つ場合があることも挙げられています。適切な修正案を出して止まったら、実装するようはっきり指示しましょう。整った計画ができても、チケットが完了したことにはなりません。

Gemini：選びたい理由がすでにあるなら、評価する価値があります。 Cursorの一般的な案内には、Gemini Proを好むユーザーもいると記載されています。ただし、特定のコーディング分野でGeminiが優位だと公表しているわけではありません。現行カタログにはGemini 4 Argon、Gemini 3.1 Pro、Gemini 3.8 Flashがあり、ClaudeにもOpus 5.5やSonnet 5.5といった新しいモデルが掲載されています。Autoの振り分け対象とは別なので、直接選択できるモデルの一覧を確認してください。

実務上の出発点は、随時レビューできる作業にはComposer、継続的な調査が課題になる作業にはGrok 4.7です。追加の利用料に見合う出力が得られるなら、利用が承認されたサードパーティモデルを選びます。どのモデルでも、人によるレビューとリポジトリの検証を合格基準にしてください。

Cursor AutoのCost・Balance・Intelligenceはどう違う？

Autoはモデルを選ぶ仕組みであり、独立したモデルではありません。また、新しいCursor Routerを使うには、現時点ではTeamsまたはEnterpriseが必要です。 CursorのRouter資料は、BalanceとIntelligenceをこの仕組みの対象としています。PlusではAutoが明示的に除外されています。どのアカウントにも同じAutoメニューが表示されるとは考えないでください。

各モードの定義と課金ルールは、CursorのRouterドキュメントに基づきます。Cursorは新規ユーザーの標準設定をBalanceとしていますが、提供するモードはチーム管理者が制御します。表の「想定する用途」は、実務への当てはめです。日常的なチケットは通常の設定で始め、興味本位ではなくタスク上の必要性があるときに、より高性能な設定へ切り替えます。

現在ドキュメントに記載されているRouterの対象モデルは、GPT-5.5、Claude Opus 5、Grok 4.6、Claude Fable 5です。Cursorは、対象モデルが変わることや、ルーティングの対象になる前に直接選択できるようになるモデルもあることを説明しています。したがって、選択メニューにGrok 4.7やGPT-5.6 Solがあるだけでは、Autoがそれらを選ぶとは判断できません。公開されている対象モデルを基準にしてください。

チームリーダーは、ルーティング設定の依存関係にも注意が必要です。Grok 4.6をブロックするとRouterが無効になります。GPT-5.5とClaude Opus 5の両方をブロックした場合も同様です。Cursorによると、後者の片方だけをブロックすると、ルーティングの品質が下がります。許可リストは好みのベンダーを並べるだけでなく、実際に動くルーティング設定として見直してください。

Enterpriseでは管理者によるRouterの有効化が必要です。また、チーム設定でモードを制限したり、Autoの使用を必須にしたりできます。他のアカウントでは見える設定を変更できない理由は、管理者向け設定から確認できます。サードパーティモデルに振り分けられた処理には、引き続きサードパーティ用の課金ルールが適用されます。Autoを選んでも、プランに含まれる自社モデルの利用に変わるわけではありません。

Cursorのモデルを切り替えるとき、どの設定を確認する？

チャットまたはエージェントのパネルでモデルを変更し、次のタスクを送る前に設定を確認します。 Cursorによると、選んだモデルは別の会話にも引き継がれます。便利な仕組みですが、昨日選んだ高額なモデルや特定用途向けのモデルが、気づかないうちに今日の標準になることもあります。モデルを指定する場合もAutoを使う場合も、まずはモデルの切り替え手順を確認してください。

Cursorで複数モデルを使う：サブエージェントのモデルはどう決まる？

親エージェントのモデル選択だけで、すべてのサブエージェントのモデルが決まるわけではありません。 サブエージェントは、作業の一部を任される独立したワーカーです。Cursorの組み込みワーカーはサブタスクに合わせてモデルを選びます。カスタムワーカーは、標準ではinheritで親のモデルを引き継ぎますが、モデルIDを指定することもできます。親エージェントがワーカーを起動する際にモデルを指定する方法もあります。これらの選択方法はCursorのサブエージェント資料に記載されています。

たとえば、.cursor/agents/local-review.mdに次のようなカスタム設定を置けます。

---
name: local-review
description: Reviews a bounded code change for correctness.
model: "composer-2.5[fast=false]"
---
Review the supplied diff and relevant tests.
Report concrete defects with file references. Do not edit files.

この設定は、標準速度のComposer 2.5を明示的に選びます。親エージェントのモデルを引き継がせたい場合は、代わりにmodel: inheritを使います。モデル指定の構文は、Cursorの設定リファレンスに基づいています。

見落としやすいのが課金への影響です。親エージェントがGrok、Composer、Autoを使っていても、指定したサードパーティモデルに作業を委任することがあります。そのワーカーは、新サブスクリプションではプリペイドクレジットを、旧プランではOther Models枠を消費します。実行したモデルはワーカーのタスクカードに表示され、利用量ダッシュボードにも対応するモデルが記録されます。ただし、設定でモデルを指定しても、プランの制限や管理者によるブロックが優先される場合があります。

チームで想定外の請求を調べるなら、まずワーカーの記録を確認してください。メインチャットに自社モデルが表示されていたというだけで、利用枠の適用を誤ったと判断しないことです。各サブエージェントには独立したコンテキストとトークン消費があります。委任する際も、独立した調査、別の観点からのレビュー、コンテキストを分ける利点がある作業など、明確な目的が必要です。

Cursorで自分のAPIキーを使うには？

自分のAPIキーを使うと、対応する推論処理の支払い先は変わります。ただし、プラン、機能、プロバイダーの制限がなくなるわけではありません。 PlusではBYOK、つまり自分のキーを持ち込む「bring your own key」は利用できません。CursorのAPIキーのドキュメントでは、OpenAIの標準的な非推論チャットモデル、Anthropic Claude、Google Gemini、Azure OpenAI、AWS Bedrockに対応しています。それぞれのプロバイダーでサポートされる設定の範囲内で利用できます。

接続するには、Cursor Settings > Modelsを開き、プロバイダーを選んでキーを入力し、保存します。対象の個人向けプランでは、リクエストの料金はプロバイダーから直接請求され、Cursorのプラン内モデル利用枠やプリペイドクレジットは消費しません。TeamsとEnterpriseでは、対象リクエストに引き続きCursor Token Rateがかかります。Tab補完は、引き続きCursorの組み込みモデルを使います。

組織がすでにプロバイダーのアカウントを持ち、推論処理の請求をそちらにまとめたい場合には便利です。ただし、すべてのモデルの派生版やCursorの全機能が、そのアカウントを使うとは限りません。チームの課金に関する前提を変える前に、使いたいモデルが選択メニューに表示され、必要なワークフローがサポートされているかを確認してください。

データの取り扱いにも注意点があります。プロンプトを構築するため、リクエストは引き続きCursorのバックエンドを経由します。Cursorによると、キーは安全に送信され、永続保存されません。ただし、CursorのZero Data RetentionポリシーはBYOKには適用されず、プロバイダー側のポリシーが適用されます。請求先の都合だけでなく、組織の要件に合う接続方法を選びましょう。

利用地域によって選べるモデルが変わることもある

モデルが表示されない原因は、プランだけでなく、プロバイダーの地域制限にもあります。 Cursorの対応地域の資料によると、プロバイダーの制限によってモデルが選択メニューから除外されることがあります。その場合は別の利用可能なモデルを選ぶか、アカウントで使えるならAutoを利用します。プロバイダーのAPIキーも、そのプロバイダーがアクセスを認める地域でしか使えず、地域制限を回避する手段にはなりません。

複数の地域に開発者がいるチームでは、全員に同じモデルメニューが表示される前提で標準環境を決める前に、それぞれの地域から想定した構成を使えるか確認しましょう。モデルが見つからないときは、プラン、管理者の許可リスト、プロバイダーの提供地域の順に確認します。エディタの再インストールを繰り返すより、原因の特定につながります。

10月の変更だけでは判断できないこと

サブスクリプションの選択肢が変わったことは、CursorからGPTがなくなった証拠ではありません。 確認日時点でも、CursorはGPT-5.6 Solの資料を公開しています。SNSへの投稿だけでは、提供終了や打ち切り日を確定できません。いまのワークフローは、現行カタログと自分のアカウントで実際に使えるモデルを基に判断しましょう。

Autoも、「毎回最新モデルを選ぶ」という意味ではありません。検証済みの振り分け対象は全モデルのカタログと異なり、タスクに応じてモデルを選ぶための仕組みです。特定モデルの使用が完了条件に含まれるなら、ルーターが選ぶことを期待するのではなく、利用可能な範囲で直接指定してください。

また、大きなコンテキストウィンドウや高い思考量設定も、明確なタスク定義の代わりにはなりません。難しいバグなら、再現手順、期待する挙動、通すべきテストを伝えます。容量が増えれば扱える材料は増えますが、欠けている要件までは補えません。

複数のコーディングクライアントで同じプロバイダーへのアクセスを使い回せることが要件なら、その判断はCursorの代替ツール比較で扱っています。特定のプロバイダーがCursorから撤退したと決めつけなくても、移行のしやすさを理由に代替手段を評価することはできます。

いま見直すべき人、移行を待つべき人、そのまま使える人

開発者が標準モデルを変えるのは、それによって解決したい問題を説明できるときです。 Composerが日常作業でレビュー可能な変更を出せているなら、そのまま使いましょう。難しいタスクで未完了が続くなら、明確な完了条件を用意してGrok 4.7を評価します。原因が曖昧な仕様にあるなら、先に仕様を直してください。

チームリーダーはいま、ルーティングとサブエージェントを確認しましょう。 許可されたモデル、表示されるAutoモード、実際の振り分け先の表示、カスタムワーカーによるモデル指定を確認します。親エージェントのモデルだけを承認する運用では、実際のワークフローの一部が確認から漏れます。

Claude、GPT、Geminiが必要なら、契約候補からPlusを外してください。旧プランの契約者は、失う利用枠を理解するまで移行を待ちましょう。 公開されているプラン名が変わったからといって、問題なく使えている旧プランから新しい課金体系への移行を強いられるわけではありません。

月曜日に、自分のバックログから日常的なチケットと難しいチケットを選んで試してみてください。選択したモデル、設定、ワーカーのモデル、完了した検証、利用量を記録します。修正の手間が少なく、利用量も予測しやすい状態で、求める品質の作業を完了できる構成を残しましょう。モデル名だけでチーム全体の標準を決めるより、そうした観察のほうが役立ちます。

よくある質問

モデルの変更と、影響を受けるワークフローの実践的なガイドは、ニュースレターに登録してお読みください。