Cursor の推奨スペックとは、AI コードエディタ Cursor を快適に動かすために必要な PC の構成のこと。要点は GPU ではなく、RAM・CPU・SSD にあります。
Cursor は VS Code をベースにした AI コードエディタで、コード生成や補完の推論はクラウド側（Cursor や各モデル提供者のサーバー）で実行されます。そのため、AI 推論のための専用 GPU は通常必要ありません。ところが「Cursor が重い・固まる」と感じる場面もあります。手元で負荷になりやすいのは、Electron 製エディタの常駐、拡張機能、TypeScript などの言語サーバー、そしてコードベースのインデックス処理です。同じクラウド型でも、ターミナルで動く Claude Code や Codex CLI がエディタ本体を別に持つのに対し、Cursor はエディタと AI とインデックスを一つに抱えるぶん、RAM の比重が上がります。本記事は、公式が示すデータの扱いと、大規模リポジトリで問題になりやすいインデックス・言語サーバーの挙動をふまえ、Cursor の実務的なスペックの目安と「重い・固まる」を避ける設定を整理します。なお後述のとおり、Cursor のコードベースインデックスはローカルだけで完結せず、コードの一部をサーバーへ送って埋め込みを生成します。
- ・Cursor の AI 推論はクラウド側で実行されるため、AI 用の専用 GPU は通常不要。手元で効くのは RAM・CPU・SSD
- ・「重い・固まる」の原因は一つに決まらない。拡張機能・設定・大規模リポジトリのインデックス・言語サーバー（tsserver 等）を順に切り分ける
- ・RAM は実務上の目安として 16GB を起点、大規模モノレポなら 32GB（公式が最小 RAM を要件として明記しているわけではなく、本記事の推奨）
- ・コードベースのインデックスはサーバー側での埋め込み生成を含む。機密コードでは Privacy Mode の状態と利用モデルを確認する
Cursor に AI 用の GPU は通常要らない｜効くのは RAM・CPU・SSD
Cursor のコード補完やエージェント機能は、モデルの推論を Cursor や各モデル提供者のクラウド側で実行します。手元の GPU でモデルを動かすわけではないので、画像生成やローカル LLM のように VRAM を要求しません。AI 機能を使うために専用 GPU を積む必要は通常なく、内蔵グラフィックスの一般的な開発用 PC でも動きます。クラウド型の AI コーディングという点では、Claude Code や Codex CLI と同じ前提です。
Cursor は Windows・macOS・Linux に対応し、各 OS 向けに配布されています。注意したいのは、公式が具体的な最小 RAM やディスク容量を「動作要件」として大きく掲げているわけではない点です。そのため、本記事で示す RAM・ストレージの数値は公式要件ではなく、実務で快適に使うための目安として扱ってください。Cursor の体感を実際に決めるのは、最小値よりも、次に説明するインデックスと言語サーバーの負荷だからです。
| 対応 OS | Windows・macOS・Linux（各 OS 向けに配布） |
|---|---|
| AI 推論 | クラウド側で実行（AI 用の専用 GPU は通常不要） |
| RAM・ディスク | 公式は要件として明記せず。目安は本文の推奨（実務）を参照 |
| ネットワーク | AI 機能の利用に必須 |
Cursor 固有①｜インデックスと言語サーバーが RAM・CPU を使う
Cursor の特徴のひとつが、プロジェクト全体を対象にした意味検索（セマンティック検索）です。これを支えるため、Cursor はワークスペースのファイルを走査してインデックスを作ります。ここで押さえておきたいのは、この処理がローカルだけで完結しないことです。公式の Data Use & Privacy の説明によれば、Cursor はコードを小さなチャンクに分けてサーバーへ送り、埋め込み（ベクトル表現）を計算します。埋め込み計算に使った平文コードはリクエストの後に破棄される一方、埋め込みとメタデータ（ハッシュやファイル名）はデータベースに保存され得るとされています。「ローカルだから外には出ない」と思い込んでいると、ここで取り違えます。
手元の RAM・CPU を使うのは、ファイルの走査やインデックスの保持に加えて、VS Code 系として併走する言語サーバーです。とくに TypeScript の言語サーバー（tsserver）は、大規模なプロジェクトでメモリを多く使うことが知られています。コミュニティの報告では、大規模モノレポで言語サーバーのメモリ消費が大きく増える、長時間のセッションでメモリが膨らむ、といった例が挙がります（いずれも環境や拡張機能しだいの非公式の話です）。ここで大事なのは、何 GB 使ったという単発の数字より、開くリポジトリが大きいほど RAM の要求が跳ねやすい、という点です。
インデックスは初回がもっとも時間を要し、その後はファイルの変更を取り込みます。@ 記号でファイルやシンボルを明示的に指定すると、エージェントが探す対象を絞りやすくなります。環境によっては 8GB でも起動・利用できますが、これは公式の最小 RAM 要件ではありません。複数の依存を抱えるリポジトリを開いたり、AI に投げて待つ間に別作業を回したりするなら、RAM は 16GB からにしておくと無難です。
Cursor 固有②｜Electron ベースの常駐メモリと固有機能の上乗せ
Cursor は VS Code を基盤にしたデスクトップエディタ（Electron 系）です。ブラウザ技術を内包する構造のぶん、ターミナルで動く CLI ツールよりも起動時点の常駐メモリは大きめです。ここに前述のインデックス処理と、拡張機能・言語サーバーが積み上がっていきます。
同じ AI コーディングでも、Claude Code や Codex CLI のようなターミナル常駐のツールは、エディタ本体を別に使う前提です。Cursor は「エディタ＋ AI ＋インデックス」を一つのプロセス群で抱える設計だと理解しておくと、RAM の見積もりを外しません。ブラウザやコンテナ、別のエディタを並走させる開発スタイルなら、その分の余裕も上乗せして考えます。逆に、拡張機能を入れすぎている場合は、使っていないものを無効化すると常駐メモリが下がることがあります。VS Code 系の拡張がそのまま使えるのは便利ですが、入れた拡張のぶんだけ重くなります。
Cursor の推奨スペック早見表（実務上の目安）
前述のとおり公式は最小 RAM・ディスクを要件として明記していないため、以下は実務で快適に使うための目安です。推奨はプロジェクト規模で変わるので、二段で示します。
| 項目 | 目安（中規模まで） | 目安（大規模・モノレポ） |
|---|---|---|
| CPU | 4〜8 コア（Core i5 / Ryzen 5 級以上） | 8 コア以上（Core i7 / Ryzen 7 級） |
| RAM | 16GB | 32GB |
| GPU | AI 用の専用 GPU は不要（推論はクラウド実行。内蔵グラフィックスで可） | |
| ストレージ | NVMe SSD 512GB | NVMe SSD 1TB |
| ネットワーク | 安定したインターネット接続（AI 応答はクラウド往復） | |
※ 上表は公式の動作要件ではなく、本記事の実務上の目安です（実測ベンチマークではありません）。
RAM は実質的にいちばん効く要素です。16GB あれば中規模プロジェクトでインデックスと補完を並行させても窮屈になりにくく、モノレポや重い依存を扱うなら 32GB を見ておくと再起動の頻度を抑えやすくなります。ストレージは NVMe SSD を選んでおくと、プロジェクトのクローンや依存パッケージの解決、インデックスの読み書きで待たされにくいでしょう。RAM の選び方そのものはAI 用 PC のメモリ選び方も参考になります。
大規模リポジトリ・モノレポで「重い・固まる」を避ける
モノレポを丸ごと開いているなら、PC スペックを上げる前に、ワークスペースの切り方を見直したほうが早いことがあります。設定でインデックスや解析の負荷を下げるだけで軽くなるケースが多いからです。公式に案内されている対処と、その使い分けを整理します。
.cursorindexingignore |
検索インデックスからのみ除外する。大きな生成物や vendor 依存を対象から外しつつ、ファイル自体は AI 機能からアクセス可能なまま残せる |
|---|---|
.cursorignore |
意味検索・Tab・Agent・Inline Edit・@ 参照などからのアクセスを制限する。ただし terminal や MCP ツールには効かず、公式も完全な保護は保証していないため、秘密情報はリポジトリに置かない運用や権限管理・シークレット管理と併用する |
.gitignore / 既定の無視リスト |
Cursor は .gitignore と既定の無視リストをインデックス対象から外す。node_modules は既定の無視リストにも含まれるが、Git 管理の観点でも .gitignore に入れておくのが一般的 |
| ワークスペースを絞る | モノレポ全体ではなく、作業対象のパッケージ単位で開く |
TypeScript のプロジェクトで言語サーバーがメモリ不足になる場合、VS Code 公式はプロジェクトの分割や、上限メモリの引き上げ（typescript.tsserver.maxTsServerMemory）を案内しています。逆に RAM 節約を狙って上限を下げすぎると、補完や型解析が不安定になることがあります。まずは .cursorignore やワークスペースの分割で対象を絞り、それでも詰まるほどリポジトリが大きいときに、はじめて RAM 32GB 級を検討する。この順番なら、無駄な出費を避けられます。
ノート PC で Cursor を使うときの注意点
ここは Cursor 固有というより、開発用ノート全般に近い話です。Cursor は専用 GPU 非搭載（内蔵グラフィックスのみ）の薄型ノートでも動きますが、デスクトップにない注意点があります。第一に RAM。ノート PC は購入後に増設できない機種が多く、後から 16GB を 32GB にできないことがあります。モノレポ・Docker・ブラウザ・テストの並走を見込むなら、購入時点で 32GB を選んでおくと後悔しにくい。第二に排熱です。インデックス処理や大規模プロジェクトの読み込みで CPU が回り続けると、薄型筐体ではサーマルスロットリングが起きて性能が頭打ちになります。長時間使うなら電源接続を前提にしたほうが安定します。第三にストレージで、NVMe SSD を選んでおくと読み込みや依存解決で待たされにくくなります。Mac を選ぶ場合は Apple Silicon 向けのネイティブバイナリが用意されますが、大規模リポジトリでは結局メモリ容量が効くため、統合メモリは多めの容量を選んでおくと安心です。
料金プランと PC 要件は別物
Cursor の料金プランは、必要な PC スペックとは直接関係しません。Pro にしたから PC が軽くなる、という話ではない、ということです。変わるのは主に AI の利用枠や使えるモデルで、ローカル側の重さはリポジトリや拡張機能、言語サーバーの負荷で決まります。2026 年 6 月時点の構成は次のとおりです（金額・含まれる利用枠は改定され得るため、契約前に公式の Pricing を確認してください）。
| プラン | 位置づけ |
|---|---|
| Hobby（無料） | クレジットカード不要。エージェント要求・補完が限定。まず試す向け |
| Pro（月額 20 ドル） | 利用上限の拡張、各社のフロンティアモデル、MCP・スキル・フック、クラウドエージェント |
| Pro+ / Ultra | Pro の上位にあたる個人向け枠（2026 年 6 月確認時点で Pro+ は月額 60 ドル、Ultra は月額 200 ドル。利用枠・金額は改定され得るため公式 Pricing を確認） |
| Teams | 公式 Pricing では 1 ユーザー月額 40 ドルから。Standard・Premium の区分や上位枠の金額・利用枠は改定され得るため、契約前に公式 Pricing で確認。集中管理・SSO・チーム単位のプライバシーモードなど |
| Enterprise（個別見積もり） | プール利用・監査ログ・アクセス制御などを追加 |
プランを変えただけでローカル PC の要件が大きく変わるわけではありません。ただし実際に必要な余裕は、開くリポジトリの規模、拡張機能、言語サーバー、Docker・テスト・ビルドの並走の有無で変わります。
プライバシーと外部送信｜「ローカルで完結」ではない
スペックとあわせて押さえておきたいのが、コードの送信先です。Cursor は推論をクラウドで行い、コードベースのインデックスでもコードの一部をサーバーへ送って埋め込みを生成します。つまり、手元だけで完結するツールではありません。
Cursor には Privacy Mode があり、設定で有効にできます（特定の上位プラン専用ではありません）。公式の説明では、有効にすると Cursor もモデル提供者も送られたコードを学習に使わず、すべての提供者との間で zero data retention の取り決めがあるとされています。一方、Privacy Mode をオフにすると、コードベースのデータ・プロンプト・エディタ操作・コード片などが、Cursor の AI 機能改善やモデル学習に使われ得るとされています。
ただし、Privacy Mode が有効でも例外はあります。利用規約違反を検知する分類器にフラグされた場合は調査のためにデータが保存され得ること、zero data retention でないモデルはその旨が示される（または管理者の有効化が必要）ことなどが公式に挙げられています。機密性の高いコードを扱うなら、「ローカルだから安全」という思い込みは捨てて、Privacy Mode の状態・選ぶモデル・組織のポリシーを先に確認しておきましょう。
Claude Code・Codex CLI とのスペック比較
同じクラウド型でも、Cursor とターミナル型のツールでは手元 PC への負荷の出方が違います。Cursor はエディタ本体・拡張・インデックス・言語サーバーを一つに抱えるため、ローカル常駐の負荷が乗りやすい一方、ターミナル型はエディタを別に使う前提です。ただし実際の負荷はプロジェクト規模・拡張・走らせるビルドやテストに依存するため、下表は形態と公式の説明の範囲に絞った整理にとどめます（各ツールの「手元で効きやすい要素」は公式のスペック要件ではなく、ローカルの編集・ビルド・テストを含む実務上の目安です）。
| 観点 | Cursor | Claude Code | Codex CLI |
|---|---|---|---|
| 形態 | Electron 製エディタ（VS Code ベース） | ターミナル CLI | ターミナル CLI |
| AI 推論 | クラウド実行 | クラウド実行 | クラウド実行（--oss 時はローカル） |
| AI 用 GPU | 通常不要 | 不要 | 不要（--oss は別途） |
| 手元で効きやすい要素 | RAM・CPU（エディタ常駐＋インデックス＋言語サーバー） | RAM・SSD・回線 | RAM・SSD・回線 |
※ 「手元で効きやすい要素」の行は各ツール公式のスペック要件ではなく、ローカルの編集・ビルド・テストを含む実務上の整理です。
マシンそのものの選び方や予算帯の考え方は、共通部分が多いClaude Code 推奨スペックの記事を入口にすると早いはずです。Cursor 固有のインデックス・言語サーバーの負荷を、その共通項に上乗せして考えてください。
まとめ
Cursor の推奨スペックは、GPU ではなく RAM・CPU・SSD で決まります。AI 推論はクラウド実行なので AI 用の専用 GPU は通常不要。一方で Cursor はエディタとコードベースのインデックス、言語サーバーを手元で抱えるため、RAM の比重がターミナル型より上がります。公式は最小 RAM を要件として明記していませんが、実務では 16GB を起点に、大規模モノレポなら 32GB が目安。重い・固まるときは増設の前に、拡張機能の切り分け、.cursorignore や .cursorindexingignore での除外、ワークスペースの分割を試すのが先です。インデックスはサーバー側の埋め込み生成を含むので、「ローカルで完結」ではない点と Privacy Mode の条件も確認しておく。ご自身が扱うリポジトリは、小〜中規模とモノレポ、どちらに近いでしょうか。そこが RAM を 16GB にするか 32GB にするかの分かれ目になります。
よくある質問（FAQ）
Q: Cursor に GPU は必要ですか？
A: AI 用の専用 GPU は通常必要ありません。Cursor の推論はクラウド側で実行されるため、VRAM を要求しません。専用 GPU を求める公式要件は確認できず、対応 OS 上で Cursor 本体が動く PC なら、専用 GPU なしで使う前提で考えられます。効いてくるのは GPU ではなく、RAM・CPU・SSD です。
Q: Cursor が重い・固まる原因は？
A: 原因は一つに決まりません。拡張機能・設定・大規模リポジトリのインデックス・言語サーバー（tsserver 等）を順に切り分けます。VS Code 系の切り分けとして拡張機能を無効化して試す、生成物を除外する、node_modules などを .gitignore に入れる、といった方法があります。AI 推論用の専用 GPU を増設しても、補完や Agent の応答が速くなるとは限りません。描画まわりや言語サーバーなど別の要因もあるため、原因を順に切り分けてください。
Q: 最低でも RAM はいくつ必要ですか？
A: 公式は最小 RAM を要件として大きく掲げていません。小規模プロジェクトでは 8GB 環境でも利用できる可能性はありますが、公式の最小 RAM 要件ではなく、本記事で実測を保証するものではありません。複数の依存を抱えるリポジトリや並行作業を見込むなら、16GB を起点にしておくと後で困りにくくなります。
Q: モノレポを扱うなら何 GB の RAM が要りますか？
A: 32GB を見ておくと安心です。コミュニティの報告では、大規模モノレポで TypeScript の言語サーバーのメモリ消費が大きく増える例が挙がります（環境・バージョン依存の非公式報告で、具体的な数値は条件次第です）。あわせて、検索インデックスから外したい生成物は .cursorindexingignore へ、ワークスペースをパッケージ単位で開く運用も有効です。tsserver の上限を下げる場合は補完・型解析が不安定になることがある点に注意してください。
Q: Cursor に送ったコードは学習に使われますか？
A: 条件によります。推論やインデックスでコードはサーバーへ送られますが、Privacy Mode を有効にすると学習には使われないと公式に説明されています（特定プラン専用ではありません）。オフのときは AI 機能改善やモデル学習に使われ得ます。規約違反の検知でフラグされた場合の保存や、zero data retention でないモデルなどの例外もあります。機密コードを扱うなら、Privacy Mode の状態と利用モデルを先に確認してください。
参考資料
- Cursor 公式: Documentation（機能・設定）
- Cursor 公式: Pricing（Hobby / Pro / Pro+ / Ultra / Teams / Enterprise）
- Cursor 公式: Data Use & Privacy（インデックス時のコード送信・Privacy Mode・例外）
- Cursor 公式: Security（Privacy Mode・データ取り扱い）
- Cursor 公式: Ignore files（.cursorignore と .cursorindexingignore の違い）
- RAM 使用量やモノレポでの言語サーバーのメモリに関する数値は、開発者コミュニティの報告にもとづく非公式の目安であり、公式の動作要件ではありません（環境・バージョンに依存）。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
