Cursorでは複数のAIモデルを選べますが、モデル名だけで判断すると、含まれる使用量を早く消費したり、簡単な修正に重い推論を使ったりします。重要なのは、作業の難しさと失敗時の戻しやすさでモデルを分けることです。
30秒でわかる結論
- 小さく明確な変更は通常モードから始める
- モデルを決めきれない場合はAutoを比較対象にする
- Max Modeは長い文脈や高難度の作業へ限定する
- Thinkingは必要な作業だけで有効にする
- 月額プラン名ではなく、ダッシュボードの実使用量を見る
Autoは「無料の万能モード」ではない
Cursorの公式資料では、Autoはその時点のタスクや稼働状況に応じて適したモデルを選ぶ仕組みとして説明されています。自分でモデルを固定する手間を減らせますが、料金や含まれる使用量の扱いはプランと時期によって変わり得ます。
Autoを常に選ぶのではなく、同じ種類の作業を数件試し、処理時間、修正回数、使用量を固定モデルと比較するのが安全です。
通常モードが向く作業
通常モードは、変更範囲が明確で、参照するファイルが限定される作業に向きます。
- 一つの関数の修正
- テスト失敗の原因調査
- 型エラーやLint違反の解消
- 既存パターンに沿った小規模な追加
依頼時に対象ファイル、変更してよい範囲、完了条件、実行するテストを明示すると、不要な探索と再生成を減らせます。
Max Modeを使う前に確認すること
Max Modeは、より長い文脈や難しいタスクで役立つ一方、使用量を速く消費し得ます。次のような仕事へ限定すると判断しやすくなります。
- 多数のファイルにまたがる設計変更
- 通常モードで原因を特定できなかった障害
- 長い仕様書と既存コードを同時に参照する必要がある
- 変更ミスによる影響が大きく、深い検討が必要
単に「回答を良くしたい」という理由だけで切り替えず、通常モードで失敗した条件を記録してから使います。
Thinkingモデルの使い分け
Cursorのモデル選択ガイドでは、Thinking対応モデルは複雑な推論に向く一方、処理時間や使用量が増える場合があると説明されています。
設計、根本原因分析、複数案の比較には適しますが、文言変更や既知パターンの実装では効果が小さいことがあります。作業を「考える工程」と「機械的に変更する工程」に分け、前者だけへ適用するのが有効です。
使用量を減らす依頼の書き方
- 目的を一文で書く
- 対象ファイルを指定する
- 変更禁止範囲を示す
- 完了条件とテストを列挙する
- 大きい作業は調査と実装に分ける
曖昧な依頼は、モデルが広い範囲を探索し、不要なコードを読み込む原因になります。高性能モデルへ上げる前に、入力の範囲を狭める方が費用と精度の両方へ効く場合があります。
まとめ
Cursorのモデル選択は、通常モードを基準にし、Autoを比較し、MaxやThinkingを難しい工程へ限定すると管理しやすくなります。プランの説明だけに頼らず、ダッシュボードの消費量と修正成功率を記録し、自分の作業で最も費用対効果の高い組み合わせを決めましょう。

コメント