Cursorのプラン選び｜Agent利用量と追加課金を含めて予算を立てる

結論

Cursorは月額だけでなくAgentの実消費とon-demand超過を1週間記録し、月次へ換算してプランを選びます。モデル選択で消費が変わるため固定回数だけでは見積もりません。

判断の順番は 必須条件→費用/性能の得失→運用条件 です。価格、plan、求人、hardware仕様など時間で変わる事実には 2026-09-13 の観測日を付け、未測定の速度・品質・時間・電力を公式仕様から推測して数値化しません。

判断表：1週間の実行ログを月次予算へ換算するシート

日付	Model/mode	Agent task	usage表示/請求単位	on-demand	成功/再実行	備考
Day1…7	実値	task名	dashboardのraw値	実値	回数	large context等

週次Agent費 = base planに含まれない実課金の合計
月次予算目安 = 週次実績 × 4.35   # 季節変動が大きい場合は使わない
再実行率 = retry/re-run task ÷ 全task

モデルごとのcredit倍率やplan包含量は変わり得るため、固定「何回使える」で記事を凍結せず、Cursor dashboardの実usage 7日分を入力にします。

判断の前提

開発/自動化ツールは、表示月額だけで比べると課金境界を誤ります。認証経路、含有利用、従量単位、超過、team管理を分けて見ます。

Agent系では「生成できる」ことと「実行してよい」ことを分離します。filesystem書込み、shell実行、外部network、Git操作に承認点を置き、失敗時にdiffとlogから戻れることを必須にします。

価格・plan・creditの名称は変化が速いため、固定ランキングではなく、自分の1週間のusageまたは1workflowを現在の課金単位へ換算する方が再利用できます。

7日ログで分かること

CursorのAgent費用は、開く時間ではなくtaskの重さとmodel/mode選択で変わり得ます。1週間だけでも、feature実装・bugfix・質問・大規模refactorを分けて記録すると、どのtaskがusageを消費しているか見えます。再実行が多いtaskは、上位planにする前にprompt/acceptance 検証を改善した方が安くなる場合もあります。

月次換算は繁忙週をそのまま4.35倍しないよう、少なくとも通常週と繁忙週を分けます。plan変更前にはCursor公式のcurrent pricingとdashboard単位を再確認し、旧プランの記事にある回数を流用しません。

plan変更の閾値は「今月ちょっと足りなかった」ではなく、通常週の実usageをcurrent plan上限へ当てた結果で決めます。繁忙期だけ超過するなら追加usage、恒常的に超えるなら上位planというように、固定費と変動費を分けます。

team利用では平均だけを見ず、heavy userと通常userを分けます。少数のheavy userのため全seatを上位化するより、role別planや追加usageの方が安い場合があります。通常週と繁忙週を分け、超過が一時的なら変動費、毎週続くなら固定plan変更というruleにします。plan変更前にはcurrent dashboardのusage unitと追加課金条件を再確認します。

選ばない・進めない条件

請求経路・利用上限・実行権限・rollbackのいずれかが不明なまま本番導入しない。

これは「慎重に」という抽象論ではなく、比較表の必須条件を満たさない候補をランキングから外すための公開条件です。

一次情報

• Cursor — Pricing
• Cursor — Models and pricing
• GitHub Copilot — Plans
• OpenAI — Codex upgrades

まとめ

Cursorは月額だけでなくAgentの実消費とon-demand超過を1週間記録し、月次へ換算してプランを選びます。モデル選択で消費が変わるため固定回数だけでは見積もりません。

変化が速い領域ほど固定ランキングより、同じinputで更新できる1週間の実行ログを月次予算へ換算するシートを正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。