Cursor 料金プラン比較｜無料/Pro/Businessの選び方

『Cursor』の料金を見て迷いやすいのは、無料のHobbyとProの差だけでなく、月額固定に従量課金を重ねるクレジットプール制へ変わったことで請求の見え方が複雑になった点です。
この記事は、まず無料・Pro・Business（公式表記は『Teams』）の違いを比較表で短時間につかみたい個人開発者と、SSO・SCIM・RBACまで含めて導入判断したいチーム担当者に向けて書いています。
あわせて、Business/Enterprise 文脈で見落としやすいのが SSO・SCIM・RBAC の適用範囲です。
本稿は 2026年3月時点の情報を基準にしつつ、契約前に確認すべき具体項目（Pricing ページ、Docs の Identity/SCIM ページ、管理画面の Billing/Spending Limit 表示、契約書や営業経由の Enterprise 範囲）を示して要点をまとめます。

Cursorの料金プラン比較表【無料/Pro/Business】

3プラン比較表

まず表だけ見て、自分がPro寄りか『Business』寄りかの当たりを付ける読み方がいちばん早いです。
個人で毎日コードを書くならPro、複数人で請求管理や権限管理まで必要なら『Business』という切り分けで、最初の迷いはほぼ解けます。
そのうえで本文を読むと、月額の差ではなく「使用量の増え方」と「管理機能の有無」で納得しやすくなります。

料金確認日：2026年3月時点。
最新情報は公式の Pricing ページと Docsでご確認ください。
この表で最初に見るべきなのは、月額そのものよりも「利用上限の考え方」の列です。
『Cursor』は2025年以降、固定回数だけで割り切る仕組みではなく、使用量プールを消費していく設計へ寄っています。
見た目は月額制でも、実際の使い心地はクレジット消費に左右されます。
ここで誤解しやすいのが、Proで無制限に使えると受け取られる点です。
実際には Pro は Tab 補完や Agent の利用枠が拡張され、日常の開発で止まりにくくなる傾向がありますが、具体的な回数や秒間レートは公式に明示されていないため、管理画面の表示や契約画面で確認することを推奨します。
ここで誤解しやすいのが、Proにすると無制限で気にせず使える、という見方です。
実際には、Pro は Tab 補完や Agent の利用枠が拡張され、日常の開発で止まりにくくなるという性質のプランだと捉えるのが実態に近いです。
たとえば軽い補完中心の日と、長い Agent 実行を何度も回す日では消費の伸び方が別物になります。

毎日使う個人開発者の判断軸としては、まずHobbyで上限に触れる頻度を見ると差がはっきり出ます。
Tab補完を常時出しつつ、チャットやAgentでコード生成と修正を繰り返す使い方では、Hobbyのままだと途中で手が止まりやすくなります。
逆に、週末だけ少し触る程度なら無料でも役割は果たします。
平日に毎日開いて、レビュー、実装、リファクタリングまで『Cursor』に寄せるなら、Proの月額は「使える回数が増える」ではなく「作業の流れを切らさないための固定費」と見たほうが腹落ちします。

チーム導入では見方が変わります。
個人利用の延長で『Business』を選ぶというより、請求をまとめたい、管理者がコントロールしたい、組織として利用状況を扱いたい、といった要件があるかで決まります。
表の月額だけだとProを人数分並べたほうが安く見える場面もありますが、管理機能が必要な時点で比較の軸が変わります。

Cursor · 料金プラン

自分に合ったプランを選ぶ

cursor.com

補足：Pro+とUltraの位置づけ

主軸はHobbyPro『Business』ですが、使用量の多い個人にはPro+とUltraも視野に入ります。
Pro+は $60/月、Ultraは $200/月で、どちらもProを基準にした使用量プールの拡張版です。
位置づけはわかりやすく、Pro+がProの3倍、UltraがProの20倍です。

この2つは、チーム機能を付けるプランではなく、あくまで個人側の使用量を厚くする方向の選択肢です。
なので「個人かチームか」で迷っている人に対して、『Business』の代わりにPro+を並べる比較は少しずれます。
毎日使う個人開発者で、すでにProのプールを超えやすいならPro+Ultra、複数人で管理が必要なら『Business』という分け方のほうが実態に合います。

体感としても、この2つを検討する段階では「月額が上がるか」より「どのモデルをどの頻度で使うか」が支配的です。
軽い補完中心なら伸びは穏やかですが、重めのモデルで長いコンテキストを何度も回すと、消費の速さが一段変わります。
Cursor側の手数料として見える部分は1M tokensあたり $0.25 のように小さく収まりやすく、コストの主因はモデルAPI側に寄るので、使用量を読むときはモデル選択の影響を先に考えたほうがぶれません。

まず押さえたい：Cursorの料金は月額固定＋使用量ベースで考える

月額とクレジットプールの関係

『Cursor』の料金で最初に押さえたいのは、月額を払えば終わりではなく、その月額に「使える利用枠」が付いてくるという見方です。
Cursor 料金プランを見ると、個人向けはProが$20/月、Pro+が$60/月、Ultraが$200/月で、上位プランほど含まれる使用量が増えます。
公式上でもPro+はProの3倍、UltraはProの20倍のOpenAI／Claude／Gemini利用量が含まれる整理です。

ここでいう利用枠は、旧来の「毎月何回まで」という固定回数で捉えるより、クレジットプールから消費していく枠として理解したほうが実態に合います。
Docs でも two usage pools の考え方が案内されており、高速側のプールを先に使い、そこから外れると低速側の扱いに移る構造になっています。

実際に使っていると、この差は1日の中でも出ます。
日中は『Tab』補完を中心に細かくコードを書いているぶんには、消費はなだらかです。
ところが、夕方に大型リファクタを『Agent』へ相談して、関連ファイルを広く読ませながら何往復か始めると、そこでクレジットがまとまって減る感覚があります。
月の使用量は一直線ではなく、静かな時間帯と一気に減る“山”がある、と捉えると腑に落ちます。
実際に使っていると、この差は1日の中でも出ます。
日中は Tab 補完中心で細かくコードを書いているぶんには、消費はなだらかです。
ところが、夕方に大型リファクタで Agent を連続稼働すると、一気にクレジットが減ることがあります。
無料のHobbyでも試用はできますが、毎日使う前提なら「月額だけ」ではなく「その月額にどの程度の作業量が含まれているか」で見る必要があります。
個人開発でProを基準に考え、使用量そのものが足りないならPro+Ultraへ広げる、チーム請求や管理機能が必要なら『Teams』系へ寄せる、という分け方が自然です。

モデル選択（OpenAI/Claude/Gemini）で消費が変わる

クレジットの減り方を左右する最大の要因は、どのモデルを使うかです。
OpenAI、AnthropicのClaude、GoogleのGeminiのようなプレミアムモデルは、同じ1回の依頼でも消費量が揃いません。

この仕組みを知らないまま使うと、「同じ『Agent』を1回動かしただけなのに、月によって減り方が違う」と感じます。
実際は、依頼の重さだけでなく、背後で選ばれているモデルと、そのモデルのAPIレートが効いています。
長いコンテキストを渡したり、複数ファイルをまたぐ編集を頼んだりすると、補完中心の使い方より消費が進みます。

『Auto』も混乱しやすい判断材料になります。
『Auto』は固定の1モデルではなく、タスクに応じて『Cursor』側がプレミアムモデルを自動で選ぶモードです。
実際に触ると、短い修正では気にならなくても、設計変更や横断的な修正では裏側の選択が変わり、消費の感覚も変わります。
「Autoなら常に同じコスト」と思っていると、ここでズレます。

なお、費用の主因は多くのケースでモデル側です。
『Cursor』側の手数料としては、Docsで Cache Read が100万トークンあたり$0.25と示されています。
たとえば利用量が10M tokens規模でも、この部分は$2.50です。
請求を押し上げる中心はモデルAPI側になりやすいので、コスト感を読むときは『Cursor』の月額よりも、OpenAI／Claude／Geminiのどれを、どの場面で使っているかのほうが効いてきます。

Models & Pricing ｜ Cursor Docs

Explore all frontier coding models, two usage pools, plan pricing, and per-model API rates.

cursor.com

超過課金（overage）とSpending Limitの設定

月額に含まれる利用枠を超えると、即座に利用が停止するわけではなく、overage（超過課金）として実際の使用量に応じて請求されることがあります。
2025年以降の『Cursor』では、この「月額＋超過分」という読み方が前提です。

この設定は、ダッシュボードの Billing → Spending Limit で Monthly Spending Limit を設定できる項目です。
ユーザー報告では、ここを $0 にして従量課金を抑える運用例があることが知られています。
ただし、上限到達時の厳密なシステム挙動（完全停止になるのか通知のみか、あるいはプール移行が行われるかなど）は UI のバージョンや契約形態（個人・Teams・Enterprise）によって差があり得ます。
運用に当たっては、管理画面の該当設定の表示内容を確認し、必要ならサポートに挙動を問い合わせてください。

2025年の体系変更で何が変わったか

2025年の大きな変化は、固定リクエスト制から、使用量ベースのクレジットプール制へ軸足が移ったことです。
なお、ダッシュボードの Billing → Spending Limit に関する運用例はユーザー報告がありますが、上限到達時の厳密なシステム挙動（サービス停止・通知・プール移行のいずれか）は UI のバージョンや契約形態（個人・Teams・Enterprise）で差があり得ます。
管理画面の表示内容を必ず確認し、必要ならサポートへ挙動を問い合わせてください。
以前は「月に何回まで」という見方が中心でしたが、現在は「どのモデルで、どの密度の処理を回したか」で請求の姿が決まります。

無料プラン（Hobby）でできること・向いている人

Hobbyで実際に試せる範囲

『Cursor』の無料プランであるHobbyは、クレジットカード不要で始められるのがまず大きいところです。
課金設定を先に考えなくても、インストールしてすぐに補完や『Agent』の雰囲気を触れます。
無料枠としての位置づけが明確です。

そのうえで、Hobbyは「無料で何でも使い続ける」プランではなく、Tab補完とAgentリクエストに上限がある範囲で試すプランです。
具体的な回数はUIの最新版で見ておきたい項目ですが、用途の感覚としては、学習中に小さな関数を書き換える、週末に個人アプリの画面を1つ整える、既存コードの軽い修正を進める、といった作業に収まりやすいのが利点です。

実際、最初の1週間をHobbyで触ると、自分の作業のどこで詰まりやすいかが見えてきます。
補完が途中で細くなるタイミングや、『Agent』のレスポンス制限を意識する場面が出てくると、「自分はその場の補完を多用するタイプなのか」「それとも長めの指示でまとめて直させる使い方なのか」が直感的に分かります。
ここが見えると、無料のままでも十分なのか、Proの月額を払う価値があるのかを机上の比較ではなく作業感で判断できます。

向いているのは、まず『Cursor』そのものに慣れたい人です。
たとえばVS Codeから移ってきて、補完の癖やチャット編集の流れを試したい段階なら、Hobbyの枠内でも得られる情報は多いです。
業務導入前の検証というより、個人で学ぶ、軽く作る、相性を見るための入口として捉えるとズレません。

制限に当たりやすい操作の例

上限を意識しやすいのは、1回の依頼が重い操作です。
たとえば、複数ファイルをまたいで設計変更を指示する、長い仕様説明を貼ってまとめて実装させる、失敗した応答に対して何度も再実行する、といった使い方では『Agent』の消費が早く進みます。
短い会話の積み重ねより、長文で密度の高い依頼を連発するほうが先に効いてくる場面です。

高性能モデルを続けて使う操作も、無料枠の感覚をつかみにくくする要因です。
前のセクションで触れた通り、『Cursor』は月額だけでなく、モデル選択や処理の重さで体感が変わります。
Models & Pricing | Cursor Docsにある考え方の通り、軽い補完と重いエージェント処理は同じではありません。
無料で試す段階では、1回で完璧に仕上げようとするより、範囲を絞って使ったほうがHobbyの枠に収めやすくなります。

Tab補完でも、連続して大きな変更を流し込むような書き方をすると、無料プランの範囲では物足りなさが出ます。
1行ずつの補助や、定型コードの下書きには十分でも、長時間の実装セッションを補完中心で押し切るスタイルだと、途中で「今日はここまでか」という感覚が出やすいのが利点です。
初週でこの感覚をつかめると、ボトルネックが補完回数なのか、『Agent』依頼の重さなのかを切り分けやすくなります。

Cursor Docs

Cursor is the best way to build software with AI.

docs.cursor.com

Hobbyが向いている人

Hobbyが合うのは、毎日長時間使う前提ではなく、必要なときに開く個人利用です。
プログラミング学習中で、エラーの意味を聞いたり、簡単なサンプルを書かせたりする段階なら、無料の範囲でも得るものがあります。
週末だけ触る個人開発、ポートフォリオ用の小規模アプリ、既存プロジェクトの軽微な修正にも噛み合います。

反対に、平日に毎日開いて実務の中心に据えるなら、無料枠の上限を意識する場面が増えてきます。
レビュー対応、リファクタ、テスト修正、関連ファイルの横断編集まで『Cursor』に任せる使い方になると、Hobbyは「相性確認の段階」を超えたあたりで物足りなくなります。
この段階で無料枠の止まり方を一度体験しておくと、Proの月額が単なるコストではなく、作業が中断しにくくなるための支出として見えてきます。

つまりHobbyは、学習・お試し・軽い個人開発向けという位置づけがいちばんしっくりきます。
無料で始められて、クレジットカードも不要。
その代わり、Agentリクエスト数とTab補完数には制限がある。
ここを前提に見ると、Hobbyは節約版のProというより、自分の作業量と『Cursor』の相性を測るための実用的な入口です。

Proプランで増えること・元が取れる使い方

Proで快適になる利用シーン

Proの価値は、単に無料版より多く使えることではなく、毎日の開発で止まりにくくなることにあります。
前述のHobbyは相性確認や軽い個人開発には十分ですが、平日に継続して触る個人開発者だと、レビュー、バグ調査、テスト生成、リファクタ相談を積み重ねるうちに、上限を意識する場面が早めに出てきます。
Cursor 料金プランでProは月額 $20 と案内されており、位置づけとしては「毎日使う個人開発者」向けです。

体感差が出るのは、1回の派手な依頼よりも、日中に何度も挟む細かな往復です。
たとえばプルリク前のレビューで命名や責務分割を相談し、午後は再現しにくいバグの追跡でログの読み解きを任せ、夜にテストコードのひな型を出させる、といった流れです。
こういう使い方では、単発の大仕事より「細かく何度も使えること」のほうが効いてきます。
ProはHobbyより利用上限とクレジットプールが広がるので、日常の編集サイクルに組み込みやすくなります。

特に元が取りやすいのは、コードを書く時間そのものより、詰まった時間を減らせる場面を多く持つ人です。
自分の運用では、実装そのものよりも、既存コードの把握、失敗した修正のやり直し、テストの土台づくりで『Cursor』を開く回数が増えました。
そこが無料枠だと途切れやすく、Proだと「この相談も投げておくか」が自然に増えます。
月額を回収する感覚は、1回の大成功より、日々の小さな詰まりを何度も外せるかで決まります。

運用の目線では、日次の開発メモと一緒に「今日はどのプロンプトでどれくらい消費したか」を1週間だけ記録すると、自分に合うラインが見えてきます。
自分もこの記録を取ってみて、設計相談より、テスト生成の再実行や長めのバグ調査のほうが消費が伸びやすいことに気づきました。
逆に、短いレビュー補助や局所的なリファクタ相談は、作業の進み方に対して消費が重くなりにくい傾向でした。
こうした癖が分かると、Proが余裕を生むのか、それとも上位プランまで視野に入るのかを感覚で判断できます。

モデル・Auto設定と消費量の関係

ここで押さえたいのは、Proが無制限寄りの使い放題プランではなく、あくまで使用量ベースの土台が広がるプランだという点です。
『Cursor』は月額固定に加えて使用量ベースで計上される仕組みで、プランに含まれる範囲を超えると従量課金の考え方が関わってきます。
課金の見え方そのものはHobbyより分かりやすくなるのではなく、毎日使うからこそ把握しておきたい設計です。

消費量に効くのは依頼の長さだけではありません。
Docs にある通り、モデル選択で計上のされ方が変わります。
高精度寄りのモデルやClaude相当の重いモデルを多用すると、同じ「1回の相談」でも消費は大きくなります。
反対に、軽い補助で済む場面で重いモデルを固定すると、満足度に対して消費だけが先に進むリスクがあります。

『Auto』も便利ですが、便利さと消費の読みやすさは別です。
『Auto』はタスクに応じて『Cursor』側がモデルを切り替えるので、毎回どのモデルを明示的に選ぶより判断の手間は減ります。
ただ、利用感としては「何も考えず無限に回せる」ではありません。
日常の短い相談では収まりがよくても、長文コンテキストや複数ファイルをまたぐ修正、再試行を重ねる作業では、結果として使用量が積み上がります。

この差は、料金表だけ眺めていても見えにくいところです。
実際には、モデルのAPIコストが主な要因で、『Cursor』側のトークン手数料は補助的な加算にとどまる構造です。
公式Docsで確認できるCache Readは 100万トークンあたり $0.25 なので、コスト感を左右する中心はモデル選択のほうにあります。
毎日使う個人開発者ほど、「高精度モデルを常用する場面」と「軽いモデルや『Auto』で十分な場面」を分けたほうが、月額の納得感が出ます。

Pro+ / Ultraを検討すべきケース

Proで足りるかどうかは、単に毎日使うかだけで決まりません。
分かれ目は、1回あたりの仕事の重さがどれだけ膨らむか、という点です。
Proで足りるかどうかの分かれ目は、毎日使うかどうかだけではなく、1回あたりの仕事の重さがどこまで膨らむかです。
Cursor 料金プランではPro+が月額 $60、Ultraが月額 $200 で、Pro+はPro比で3倍の使用量、UltraはPro比で20倍の使用量とされています。
個人開発でも、使い方が重いとProの延長では収まりません。

Pro+を考えたいのは、長めのエージェント実行を日常的に回す人です。
たとえば、複数ファイルをまたぐ改修を連続で投げる、レビューと修正の往復を深く回す、テスト生成を何度も再実行する、といった開発スタイルです。
毎日開く個人開発者でも、相談の中心が「短い補助」ならProで足りる場面が多い一方、実装の主導権を『Agent』側に大きく預ける運用ではPro+のほうが噛み合います。

Ultraまで視野に入るのは、個人でも月間の開発量が一段重いケースです。
長時間のエージェント運用、大きなコードベースの継続的な解析、複数プロジェクトをまたいだ並行利用があると、Proの枠内で細かく節約するより、上位プランのほうが作業の流れを保ちやすくなります。
ここでは「上位ほどお得」という話ではなく、節約しながら使う前提を外したいかどうかが判断軸になります。

自分の感覚では、ProかPro+かで迷う人は、月額の差よりも、1週間のログを見ると答えが出やすいのが利点です。
日々のメモに消費の傾向を書き残すと、重いのが一時的な山なのか、毎日の平常運転なのかがはっきりします。
前者ならProで十分回せますし、後者ならPro+以上のほうが運用に無理がありません。
Ultraは、個人向けの標準プランというより、月間を通して大規模開発を回す人の検討枠として見ると位置づけがつかみやすくなります。

Businessプランが必要になるケース

Businessを選ぶ条件

個人で使うProと、組織で契約する『Business』相当のプランを分ける軸は、利用量そのものより 請求と管理を誰が持つか にあります。
数人で試験導入する段階では、まず各自がProで使い始めるほうが自然です。
実際、自分が見てきた導入でも、最初は個人契約で十分回りました。
ところが、メンバーが増えて「誰の請求をどこで処理するのか」「退職した人のアカウントをどう止めるのか」「新しく入った人に同じ条件で配るにはどうするか」が日常業務に入り始めると、個人課金の寄せ集めでは運用のほうが先に破綻します。
その段階でチーム契約へ集約する流れがいちばん無理がありませんでした。

この分岐を具体化すると、一括請求、席管理、管理者コントロール、SSOのどれかが必要になった時点で、個人向け有料プランの延長ではなく組織向けプランの検討に入る、という考え方になります。
公式Pricing上のチーム向け表記は『Teams』で、料金は $40 / user / mo です。
外部記事では『Business』と呼ばれることがありますが、現行UIやPricingの見え方は『Teams』寄りなので、社内で話すときも名称をそろえておいたほうが混乱が減ります。

判断材料として見たいのは、開発者が何人いるかより、運用の責任が個人から組織へ移ったかどうかです。
たとえば、経費精算で毎月ばらばらに処理している、利用者一覧を手で管理している、退社時の停止漏れが怖い、といった状態なら、コストの絶対額より管理負荷が問題になります。
反対に、まだ少人数で、使う人も固定され、請求も各自で持てるなら、個人契約のまま始めるほうが軽いこともあります。
プラン選びというより、運用単位を個人に置くか組織に置くかの違いとして見ると、線引きがはっきりします。

Enterprise機能（SCIM/RBAC/MDM）の位置づけ

ここで混同しやすいのが、『Business』文脈で語られがちな管理機能と、『Enterprise』で扱うべき統制機能の境目です。
SSOはチーム導入を考える段階で出てくる代表的な要件で、『Teams』や『Enterprise』の文脈で語られます。
一方で、SCIM、RBAC、MDMまで必要になると、話は単なるチーム請求ではなく、企業のIAMと端末統制の領域に入ります。
Identity and Access Management | Cursor DocsやSCIM | Cursor Docsで整理されている通り、これらはEnterprise寄りの機能として見るべきです。
具体的には、SCIMや権限管理、デバイス管理が該当します。

SCIMが必要になるのは、入社・異動・退社に合わせてアカウントの作成と停止を自動化したい場面です。
人の手で招待と削除を回しているうちは運用できますが、人数が増えると抜け漏れが起きます。
RBACは、誰が組織設定を触れるのか、誰が請求を見られるのか、誰が利用ポリシーを変更できるのかを分ける仕組みです。
管理者が1人だけの小さなチームでは目立たない機能ですが、情シス、開発管理者、経理の役割が分かれた瞬間に必要になります。
MDMは、会社管理端末でのみ利用を許可したい、端末ポリシーと連動させたい、といった要件で効いてきます。
これは単なる料金プランの差ではなく、会社の端末管理ルールと結びついた話です。

運用面では、ツールを契約する前に、アイデンティティ管理の基準をどこに置くかを決めている組織ほど導入後のブレが少なくなります。
たとえば「認証は社内IdP経由に統一する」「退社当日に利用停止される状態を保つ」「管理権限は最小限に分ける」「私物端末と会社端末の扱いを分ける」といったルールです。
『Cursor』側の機能だけで全部を解決するというより、既存のIAMやMDMの運用にどう載せるかで導入の難易度が変わります。
チーム向け課金が必要なのか、Enterpriseの統制まで要るのかは、この運用ルールの有無で見分けると整理しやすくなります。

契約・命名の注意

この領域でまず気をつけたいのは、『Business』という呼び方が外部記事では広く使われる一方、公式Pricingでは『Teams』表記が前面に出ていることです。
Cursor 料金プランで確認できるチーム向けプラン名は『Teams』で、Enterpriseは別枠のカスタム契約として並んでいます。
そのため、「Businessを契約する」という言い回しを社内資料で使うと、外部記事の呼称なのか、現行UIの正式名称なのかがぶれます。
見積もり依頼、稟議、情シスとの調整では、『Teams』と『Enterprise』を明確に分けて書いたほうが認識がそろいます。

契約の観点では、『Teams』はチーム運用の入口で、Enterpriseは企業統制のための拡張と考えると位置づけがつかみます。
前者は一括請求、利用者管理、組織設定の集中管理が中心です。
後者はそれに加えて、SCIMのような自動プロビジョニング、より細かい権限制御、請求やサポート体制の企業向け運用が絡みます。
同じ「組織向け」でも、マネージャーがメンバー数を把握して請求を一本化したい段階と、情シスが監査やアカウントライフサイクルを統制したい段階では、求めているものが違います。

名称のぶれは、SSOの扱いでも起きがちです。
SSO自体はBusiness相当の話として理解されやすい機能ですが、SCIMやRBACまで一緒に「Businessの管理機能」とまとめてしまうと、要件定義が粗くなります。
SSOが必要なのか、ユーザー作成・削除の自動化まで必要なのか、権限分離まで必要なのかで、契約の意味合いが変わるからです。

自分の感覚では、数人での試験導入なら、まず個人のProで利用実態をつかみ、請求の散らばりとユーザーライフサイクル管理が面倒になったところで『Teams』へ寄せる流れがもっとも現実的でした。
そこから先は、情シスやセキュリティ部門が「誰が使っているか」ではなく「どう統制するか」を問う段階で、Enterpriseの機能が必要になります。
つまり、個人向け有料とチーム契約の分岐は利用人数だけでは決まらず、請求、認証、権限、端末管理の責任をどこまで組織で引き受けるかで決まります。

用途別のおすすめプラン

学習・検証

『Cursor』を初めて触る段階なら、出発点はHobbyで十分です。
Cursor 料金プランで示されている通り無料で始められるので、まずはエディタ内での基本操作、モデルの切り替え、Agentへの簡単な依頼、Tab補完の感触を一通りつかむところに向いています。
学習フェーズでは、毎日長時間使い倒すよりも、「どの作業で便利さが出るか」を体で理解することのほうが先だからです。
この段階で見ておきたいのは、コード補完が速いかどうかより、質問の投げ方で返答の質がどう変わるか、既存コードを読ませたときにどこまで文脈を拾うか、テスト生成や軽いリファクタ提案が自分の手に馴染むか、といった点です。
無料枠でもこのあたりの判断材料は十分に得られます。
学習用でいきなり上位プランへ入るより、まずHobbyで操作感の相性を見たほうが、後でProへ上げたときの差も把握しやすくなります。

個人開発

個人開発で毎日『Cursor』を開くなら、基準はProです。
お試しではなく日常の作業道具になると、Agentへの相談回数、修正案の往復、Tab補完の利用頻度が一気に増えるので、無料枠のままでは足りなくなりやすい場面が出てきます。
特に、実装しながらテストコードも同時に作らせる使い方や、複数ファイルをまたいで相談する使い方では、Proのほうがテンポを保ちやすい構成です。

毎日使う個人開発でも、全員が最初からPro+まで必要になるわけではありません。
基準としては、連日Agentに設計相談を投げる、テスト生成を何度も回す、1日の中で長い会話を積み上げる、といった使い方が続くなら上位枠を検討する流れです。
Pro+はPro比で3倍の使用量があるので、負荷が高い月だけ上げるという考え方も成り立ちます。
逆に、補完中心で、ときどき設計相談を挟む程度ならProで収まることが多いです。

従量課金の見え方が気になる場合も、個人開発ではまずProを基準にしつつ、必要ならBilling設定でSpending Limitを持たせる運用が現実的です。
Models & Pricing | Cursor Docsにある通り、課金は月額だけでなく使用量ベースの考え方も入るので、毎日使う人ほど「どのモデルをどの作業に使うか」の設計が効いてきます。
実際に使っていると、Cursor側のトークン手数料そのものは小さく、総額はモデル選択の影響を受けやすいと感じます。
細かいコスト差より、重い相談をどこで回すかのほうが支出に効きます。

受託や副業では、基準としてProを軸にし、繁忙期だけ上位プランを使う運用が現実的です。
案件が落ち着いている月はProで十分なことが多く、納品前や改修集中月だけ上位へ上げると固定費を抑えつつ対応できます。

受託や副業では、Proを軸にして繁忙期だけ上位へ広げる運用がいちばん噛み合います。
案件が落ち着いている月は、要件整理や軽い実装補助が中心なのでProで足りることが多く、納品前や改修集中月だけAgentの往復とテスト生成が増えます。
そこに合わせてPro+へ上げると、固定費を膨らませずに作業量へ追従できます。

自分の運用でも、副業案件の繁忙月だけ上位枠に上げて、落ち着いたらProへ戻す形がいちばん収まりました。
毎月ずっと大きな枠を持つより、コードレビュー代わりにAgentを回し続ける月、実装と修正確認が重なる月だけ広げたほうが、支払いと仕事量のズレが小さくなります。
副業は本業ほど利用量が均一ではないので、この“スケール運用”が素直に効きます。

受託では、作業時間の圧縮がそのまま利益率に響くので、単純な月額の安さだけでは決めにくい面もあります。
仕様確認、既存コード読解、テストケースのたたき台作成までを『Cursor』に寄せる月なら、上位枠の価値は出ます。
反対に、ミーティング中心で実装量が少ない月はProで十分です。
案件の波に合わせて上げ下げする前提で見ると、受託・副業の最適解は「常時最上位」より「必要な月だけ厚くする」に寄ります。

小規模チーム

数人規模の開発チームなら、立ち上がりは各自Proから始める形が現実的です。
最初の段階では、メンバーごとの使い方に差があり、ある人は設計相談中心、別の人は補完中心ということも珍しくありません。
全員まとめて『Teams』へ入るより、まず個人契約で利用実態を見たほうが、どこに費用が乗るのかが見えます。

転機になるのは、利用量そのものよりも、席管理と請求集約が面倒になった瞬間です。
誰が使っているかを一覧で持ちたい、メンバーの増減に合わせて権限を整理したい、会社の経費として一括で処理したいとなると、個人Proの寄せ集めでは運用が散らばります。
そこで『Teams』へ移すと、料金以上に管理の手間が減ります。
『Teams』は公式Pricingで$40 / user / moとされていて、個人利用の延長というより、組織として回すためのプランと捉えたほうが納得しやすいのが利点です。

小規模チームでは、コストの主因は単に人数だけでなく、誰がどのモデルをどう使うかにもあります。
チーム全体でトークンを多く使っても Cursor 側の手数料だけでは影響は限定的で、実際にはモデル選択が支出を左右しやすい構造です。

企業導入

ID管理が厳格な企業では、候補は『Teams』か『Enterprise』です。
ここでは「人数が多いから上位プラン」というより、認証とアカウント運用をどう統制するかが分岐点になります。
SSOが前提で、入退社や異動に連動した自動プロビジョニングまで要るなら、Proを並べる発想では運用が持ちません。

特に、社内IdPとの連携、権限の分離、端末管理のルールがある組織では、料金比較だけで判断すると実運用とずれます。
Identity and Access Management | Cursor Docsで整理されているように、SAML/OIDC SSO、RBAC、MDMの観点が入ると導入テーマは変わります。
具体的には、個人向け開発ツールの延長ではなくなります。
さらに、SCIMまで必要ならSCIM | Cursor Docsにある通り、Enterprise寄りの要件整理が前提です。

このクラスの導入では、先に洗い出すべきなのはプラン名ではなく要件です。
SSO必須なのか、SCIMで入退社連動まで行うのか、RBACで請求権限と管理権限を分けるのか、会社管理端末だけに利用を限定するのか。
この4点が固まると、『Teams』で足りるのか、『Enterprise』まで必要なのかが見えてきます。
人数だけで決めるより、IAMの責任範囲から逆算したほうが、導入後の運用と契約が噛み合います。

学習ならHobby、毎日使う個人開発はPro、繁忙期の受託はProを軸にPro+を重ねる、という並べ方が実務に近いです。
小規模チームは各自Proから始めて請求と席管理の必要が出たら『Teams』へ、SSOやSCIMが前提の企業は IAM 要件から『Teams』か『Enterprise』を整理してください。

Cursorの料金でよくある疑問

無料プランはどこまで使える？

無料のHobbyは、まず触ってみる段階や、短時間のコード補完、軽い質問、学習用途には十分に機能します。
実際、設定確認や小さなスクリプト修正、既存コードの読み解き補助のような「1回ごとの処理が軽い作業」なら、無料の範囲でも使いどころはあります。
反対に、長い会話を前提に『Agent』を回し続ける使い方や、高性能モデルを前提に何度も往復する運用になると、無料枠の中では足りなくなりやすいのが利点です。

無料で足りるかどうかの分かれ目は、作業の重さより「連続してどれだけ任せるか」にあります。
たとえば、補完中心でたまに相談する程度ならHobbyで収まりますが、実装、リファクタ、テスト作成、エラー調査まで一気に任せると、Proに上げたほうが作業の流れが止まりません。
毎日『Cursor』を開いていて、ひとつのタスクを数ターン以上かけて進めるなら、無料で粘るよりPro前提で考えたほうが実態に合います。

Proで従量課金は発生する？

発生する可能性があります。
Proは月額だけで完結する固定料金プランというより、月額に含まれる利用量を土台にしつつ、それを超えたぶんが usage-based pricing に入る設計です。

ここで誤解しやすいのは、「Proなら全部定額」と思ってしまう点です。
実際には、どのモデルをどれだけ使ったかで追加分が積み上がる余地があります。
特に『Auto』任せの時間が長い月や、重いモデルで長文コンテキストを頻繁に扱う月は、月額の見え方だけでは実支出を読み切れません。
なお、ダッシュボード側にはSpending Limit系の設定があり、上限の置き方で overage を抑える運用は可能です。
最終的な項目名や配置はUIで見るのが前提ですが、上限設定を入れておくかどうかで安心感はまったく変わります。

BusinessとEnterpriseは何が違う？

この比較は、価格差というより運用責任の違いで見ると整理しやすくなります。
公式 Pricing では組織向けの基本プランが Teams 表記で示され、目安として $40 / user / mo が案内されています。
外部記事で『Business』と呼ばれることがありますが、公式表示では 'Teams' を基準に読むのが自然です。

『Teams』で中心になるのは、請求の一元化、席管理、管理者による利用統制といったチーム運用の土台です。
一方で『Enterprise』は、その延長線上にある大規模組織向けの契約です。
SSOだけでなく、SCIMによる自動プロビジョニング、RBAC、MDMのような統制機能まで踏み込みます。
Identity and Access Management | Cursor DocsやSCIM | Cursor Docsの文脈に沿って見ると、請求と席管理が主題なら『Teams』、IDライフサイクルや端末管理まで含めるなら『Enterprise』という切り分けです。

つまり、数人の開発チームで「誰に何席配るか」「請求をまとめたい」が中心なら『Teams』で話が進みます。
入退社連動、権限分離、会社支給端末への制御まで要件に入ると、『Enterprise』側の機能が前提になります。

超過課金を避ける具体策は？

超過課金を避けるうえで効くのは、節約テクニックよりも「どのモデルに何を任せるか」を固定化することです。
軽いリファクタや補完は軽量寄り、設計相談や難所だけ高性能寄り、と役割を分けるだけで、月末のブレは目に見えて小さくなります。
『Auto』は便利ですが、毎回最適化を任せる運用にすると、自分で思っている以上に高コスト側へ寄る場面があります。
なので、定型作業まで『Auto』で流さず、重い場面だけ使う形のほうが支出を読みやすく保てます。

もうひとつ効いたのが、日次で「モデル別の消費トップ3」だけを見る運用です。
細かいログを全部追わなくても、どのモデルが上位にいるかを毎日眺めるだけで、翌週の超過リスクがぐっと下がりました。
支出が膨らむ月は、たいてい同じモデルに偏りが出ます。
そこに早く気づけると、「この用途は別モデルへ逃がす」「この作業は『Auto』を切る」といった修正がその場で入れられます。
もうひとつ効果があったのは、日次で「モデル別の消費トップ3」だけを確認する運用です。
細かいログを全部追わなくても、どのモデルが上位にいるかを眺めるだけで翌週の超過リスクが下がりました。
加えて、月次のSpending Limitを先に置いておくと、想定外の伸びを止めやすくなります。
特に、副業案件や短期案件のように利用量が月ごとに揺れる運用では、上限を決めずに放置するより、先に枠を切っておいたほうが請求の読み筋が崩れません。

Cursor Docs

Cursor is the best way to build software with AI.

docs.cursor.com

年額・キャンペーンはある？

年額払いやキャンペーンは、恒常メニューとして固定的に読めるものと、時期によって見え方が変わるものが混ざっています。
月額表示が中心で、恒常的な年額割引率までは読み取れませんでした。
外部では年額割引や学生向け施策に触れる記事もありますが、少なくとも執筆時点では、一般ユーザー向けに一律の条件として断言できる並びではありません。

そのため、この部分は「ある・ない」を単純化するより、公式Pricingや管理画面にその時点で出ている条件をベースに扱うのが実務的です。
料金体系は2025年6月にも大きく見直されており、割引やキャンペーンの扱いも固定情報として持つより、都度の表示内容で読む前提のほうがズレません。
特に組織導入では、通常の月額表示と営業経由の契約条件が分かれることもあるため、個人向けのキャンペーン情報と同列には置けません。

まとめ

最終判断フロー

迷った段階ではHobbyで操作感を確かめ、日常的に『Cursor』を開くならProへ進み、請求の一元化やID管理、監査の要件が出たら『Teams』や『Enterprise』を検討する、という順番がいちばん失敗が少ないです。
実際、最初にHobbyで癖を掴み、Proで定着させ、必要になってから組織向けへ広げる進め方が、コストと運用負荷の釣り合いを取りやすいと感じました。

次にやること

まずはHobbyで1週間ほど普段の作業に混ぜ、補完とAgentの感触が仕事の流れに乗るかを見ます。
そのうえで毎日開く状態になったらPro移行を考えます。
複数人導入やSSO、SCIMの話が出る段階ではCursor 料金プランとCursor Docsを見て、『Teams』または『Enterprise』の条件を確認する流れが堅実です。
料金や契約条件は2026年3月時点の情報として捉え、判断前に公式表示を見直しておくとズレを防げます。