Cursorが重い・遅い原因と対処法 — 拡張機能だけが犯人じゃない【2026年版】
Cursorが重い・カクつく原因を拡張機能／インデックス肥大化／チャット履歴／メモリリークの4系統で切り分け。.cursorignoreと.cursorindexingignoreの使い分け、Claude Code CLIとの違いまで実体験ベースで整理。
エンジニアのゆとです。
Cursorが重いと感じる瞬間は、大体決まっている。タイピングしてから文字が画面に出るまでワンテンポ遅れる、Tab補完の候補が出るまで固まる、チャット欄に何か打つとファン回転数が上がる——このあたりは、Cursorを常用しているとほぼ全員が一度は通る道だと思う。自分もClaude CodeとCursorを併用していて、案件によってはCursorのAgentモードでガリガリ書かせることもあるので、この重さには何度も付き合ってきた。
厄介なのは、原因が1つじゃないこと。「拡張機能を切ったら直った」という報告と「拡張機能は関係なかった」という報告が両方ネットに転がっていて、どれが自分のケースに当てはまるか切り分けないと、的外れな対処に時間を溶かす。この記事では原因を4系統に分けて、それぞれの診断手順と対処法を整理する。
結論 — 大体この4系統のどれか
| 症状 | 疑うべき原因 |
|---|---|
| 特定の拡張機能を入れてから重くなった | 拡張機能のCPU/メモリ食い過ぎ |
| 大きいリポジトリを開いた時だけ重い | インデックス対象ファイルが多すぎる |
| 長時間使い続けると徐々に重くなる | チャット履歴・コンテキストの肥大化 |
| 何もしていないのにCPU使用率が高いまま | バックグラウンドプロセスのメモリリーク・ゾンビ化 |
上から順に切り分けていくのが早い。まずはセーフモードで一番大きい容疑者（拡張機能）を除外するところから始める。
まず切り分ける — セーフモードで拡張機能を疑う
CursorはVS Codeのフォークなので、VS Codeと同じく--disable-extensions起動、あるいはコマンドパレットの「Reload With Extensions Disabled」でセーフモードに入れる。この状態でも重さが変わらないなら、拡張機能は犯人から除外できる。逆にセーフモードで軽くなるなら、犯人は拡張機能側にいる。
拡張機能が原因の場合、次はどれが犯人かを特定する。Cursorの内蔵コマンドパレットから「Developer: Show Running Extensions」を実行すると、拡張機能ごとのアクティベーション時間とCPU負荷が一覧で見られる。Import Cost系の重量級Linter、大量のファイルウォッチャーを張るタイプの拡張機能（Live Server、一部のGitクライアント拡張）はここで真っ先に疑うべき候補だ。
原因1 — インデックス対象が肥大化している
セーフモードでも重さが変わらない場合、次に疑うのはインデックスだ。Cursorはコードベース検索・チャットの参照精度を上げるために、プロジェクト内のファイルを継続的にインデックス化している。ここでいうインデックスとは、コードをベクトル化して意味検索できるようにする仕組みのことで、対象ファイルが多いほどインデックス処理自体が重くなるし、インデックスが終わっていない間はAgentやチャットの応答精度・速度も落ちる。
対応するのが.cursorignoreと.cursorindexingignoreの2つのファイルで、書式はどちらも.gitignoreと同じ。プロジェクトのルートに置く。ただし役割がはっきり違うので、ここを混同すると効果がない。
| ファイル | 効果 | 用途 |
|---|---|---|
.cursorignore | Agent・Tab補完・Inline Edit・@メンションからそのファイルへのアクセスを遮断する（インデックスからもベストエフォートで除外） | 秘密情報など、AIに一切触らせたくないファイル |
.cursorindexingignore | インデックス（自動的な検索対象）からのみ除外。AI機能自体は手動で参照可能 | ビルド成果物・依存パッケージなど、重いが完全に触らせないわけではないファイル |
「Cursorが重い」で困っている場合に効くのは基本的に後者の.cursorindexingignoreだ。node_modules/・dist/・.next/・画像やモデルファイルなどインデックス対象から外しても実害が少ないディレクトリをここに書く。.cursorignoreは「AIに絶対見せたくないファイル」向けであって、パフォーマンス改善が主目的なら混同しない方がいい（公式ドキュメントでも.cursorignoreは”best-effort”、つまり完全にブロックされる保証はないと明記されている）。
自分の場合、モノレポでpackages配下に複数のNext.jsアプリが同居している案件があって、.next/のキャッシュとビルド成果物だけで数GBに膨れ上がっていたことがあった。.cursorindexingignoreに**/.next/と**/dist/を1行足しただけで、インデックス完了までの待ち時間が体感で半分以下になった。地味だけど効くという意味では、これが一番コスパのいい対処法だと思う。
原因2 — チャット履歴・コンテキストの肥大化
同じチャットスレッドで長時間やり取りを続けていると、UIが徐々に重くなることがある。これはチャット履歴そのものがコンテキストとして保持され続け、レンダリングとメモリ使用量の両方を圧迫するため。特にAgentモードで大きめのファイルを何度も出し入れしたセッションは、履歴の中に古いファイル内容が何重にも溜まっていく。
対処はシンプルで、新しいチャット・新しいComposerセッションを開始すること。作業の区切りが来たら、律儀に同じスレッドを使い続けずにリセットする習慣をつけると、これだけで重さの大半は解消する。長期プロジェクトで過去のやり取りを参照したい場合は、要点だけをルールファイルやメモに書き出しておいて、チャット履歴自体は使い捨てにする運用が現実的だ。
原因3 — バックグラウンドプロセスのゾンビ化
何もしていないのにCPU使用率が高止まりしている場合は、拡張機能でもインデックスでもなく、Cursorのバックグラウンドプロセスそのものが詰まっている可能性がある。CursorはNode.jsベースのヘルパープロセス（Mac版だとCursor Helperという名前でアクティビティモニタに複数出てくる）を裏で動かしていて、これが何らかの理由で解放されずに積み上がることがある。リモート接続（SSH経由でリモートのCursor Serverを使う構成など）を使っている場合は特に起きやすい。
Macならアクティビティモニタ、WindowsならタスクマネージャーでCursor Helper系のプロセス数とメモリ使用量を確認する。プロセスが異常に多い、あるいは1つあたりのメモリ使用量が数GBに達しているようなら、Cursorを完全に終了（Dockアイコンを右クリックして終了、タスクトレイからも完全終了）してから起動し直す。それでも再発する場合は、リモート接続を使わずにローカル単体で開いて再現するかどうかを確認すると切り分けが進む。
独自視点 — なぜClaude Code CLIでは同じ重さを感じないのか
自分はCursorとClaude Code CLIを行き来しながら使っているんだけど、Claude Codeの方でこの手の「重さ」を感じたことはほとんどない。理由は設計思想の違いにあると思っている。
Cursorはエディタに常駐して、開いているプロジェクトを継続的にインデックス化し、Tab補完やチャットの参照精度を上げるために裏でずっと計算し続けている。つまり「使っていない時間」も含めてリソースを使う設計だ。
一方Claude Code CLIはターミナルから起動するエージェントで、必要になったタイミングでgrepやreadのようなツール呼び出しを介してファイルを読みにいく。バックグラウンドで常時インデックスを構築し続けるような仕組みは持っていない。セッションを終えれば（明示的にバックグラウンドタスクを走らせていない限り）リソースを食い続けることもない。エディタに統合されている分の利便性はCursorの方が高いけど、「起動しっぱなしでも重くならない」という点はCLIベースのツールの方が構造的に有利だと感じる。
ちなみにClaude Codeには.claudeignoreのようなファイルは公式には存在しない（コミュニティでは広く使われているが、Anthropic公式の除外設定はsettings.jsonのpermissions.denyとrespectGitignoreだ）。Cursorの.cursorignoreと混同して同じ感覚で探すと見つからずに戸惑うので、Claude Code側でファイル除外をしたい場合は別記事を参考にしてほしい。
複数タスクを並行で進める場合、CursorでもGit Worktreeに近い構成（プロジェクトを複数ウィンドウで開く）を組むことはできるけど、ウィンドウを増やすごとにインデックス処理とヘルパープロセスも増える。自分はコード生成量が多いタスクほどClaude Code CLI側に寄せて、Git Worktreeで並行運用するようにしている。この構成にした経緯は別記事にまとめてある。
それでも直らない時の最終手段
ここまでの対処を一通り試しても改善しない場合、残っている手段は3つ。
- アプリデータの完全リセット — Cursorの設定・キャッシュ・インデックスデータを一度全部消して作り直す。破損したインデックスデータが残っているケースはこれで直ることがある
- バージョンのロールバック — 直近のアップデート後から重くなった場合は、そのアップデート自体にリグレッションが入っている可能性がある。旧バージョンに戻して再現するか確認する
- Cursorのフォーラム・GitHub Issueで同じ症状を検索する — 自分の環境だけの問題なのか、既知の不具合として報告されているのかを先に確認した方が早い場合が多い
FAQ
拡張機能を1つずつ有効化して調べるのは面倒。もっと早い方法は？
セーフモードで軽くなることを確認したら、怪しい拡張機能から先に有効化していく総当たりよりも、「Developer: Show Running Extensions」でCPU負荷順にソートして、上位から順に無効化していく方が早い。ほとんどの場合、上位1〜2個の拡張機能が原因の大半を占めている。
.cursorindexingignoreを書いても既存のインデックスには反映されない気がする
インデックスは差分ではなく定期的な再構築で更新される仕組みなので、設定変更後にすぐ反映されないことがある。コマンドパレットから「Cursor: Rebuild Codebase Index」を実行すると強制的に再構築されるので、設定変更後はこれを叩いた方が確実だ。
モノレポの一部だけを軽くしたい。プロジェクト全体を.cursorindexingignoreで除外できない？
できるが、その場合はAIがそのディレクトリの内容をそもそも把握しなくなるため、そこを触る作業ではCursorの支援を受けられなくなる点は理解した上で使う。普段触らないディレクトリ（別サービスのコードが同居しているモノレポなど）に限定するのが無難だ。
CursorとClaude Code、両方使う意味はある？
自分は用途で使い分けている。エディタ上で細かい編集を素早く確認しながら進めたい時はCursor、大きめのタスクをバックグラウンドで長時間走らせたい時はClaude Code CLIという住み分けだ。両方の設計思想の違いは比較記事にまとめてある。
まとめ
Cursorが重い場合の原因は「拡張機能」「インデックス肥大化」「チャット履歴」「バックグラウンドプロセスのゾンビ化」の4系統にほぼ収束する。セーフモードで拡張機能を切り分け、.cursorindexingignoreでインデックス対象を絞り、長時間セッションは定期的にリセットする——この3つを先にやれば、大半のケースは体感できるレベルで改善する。
それでも直らない場合は、Cursor特有の「常時インデックスを回し続ける」というアーキテクチャそのものが自分のプロジェクト規模に合っていない可能性もある。その場合は、ターミナルベースのエージェントに作業の一部を寄せてみるのも選択肢の1つだ。
