MacでCursorのCPUやメモリ使用率が高い場合：原因の処理を特定する

CursorがMacを遅く感じさせる理由はいくつかあります。拡張機能の負荷、処理中の大規模なワークスペース、長時間実行されるAIタスク、作業が終わってもメモリを消費し続けるプロセスなどです。まず、どの操作で使用量が増えるのかを特定してください。キャッシュフォルダーが大きいことは、それを削除すればCPU使用率が改善する証拠にはなりません。

再現可能な比較を1つ保つ

プロジェクトを保存し、Cursorのバージョンを記録します。アクティビティモニタを開いてCursorを検索し、プロジェクトを開く前、問題を再現している最中、タスク終了後のCPUとメモリを比較します。各テストで同じリポジトリと同じ操作を使います。

小さなフォルダーでは正常なのにモノレポではそうならない場合、ワークスペースの範囲が有力な手がかりです。新しいチャットは反応するのに長い会話の1つが反応しない場合は、それを別にテストします。同じ作業を繰り返すと使用量が着実に増える場合は、増加量と経過時間を記録します。大きな数値を1回読んだだけではメモリリークとは断定できません。

エディターを、エディターが起動する処理から切り分ける

Cursorのセッションには、エディターウィンドウ、拡張機能、言語サーバー、ターミナル、AIタスクが含まれることがあります。これらの処理の一部は、エディターがアイドル状態でも続行される場合があります。何かを無効化する前に、ビルド、テストウォッチャー、開発サーバー、モデルがターミナルでまだ実行中でないかを確認してください。停止するのは、ターミナルまたはアプリケーションの通常の操作方法で識別できたジョブだけにし、その作業を保存してから行ってください。

アクティビティモニタで、ビジー状態のプロセスを3つの時点で比較します。ワークスペースを開いたがタスクを開始していないとき、遅く感じる操作の最中、その操作が終わった後です。プロセス名と、症状が入力遅延、高いCPU使用率、メモリ増加のどれかを記録します。ヘルパープロセスの名前だけでは原因の拡張機能を特定できることはほとんどないため、次の比較で絞り込んでください。

複数のリポジトリを格納した親フォルダーではなく、実際のプロジェクトフォルダーを開いてみてください。このテストのためにプロジェクトを移動したり削除したりしないでください。より小さなワークスペースで結果が改善する場合は、より広いワークスペースに何が含まれていたかを特定します。生成されたアセット、別プロジェクトの依存関係、稼働中のウォッチャー、より多くのファイルをスキャンしている言語ツールなどです。これは範囲に関する証拠であり、大きなディレクトリをすべて除外する理由ではありません。

たとえば、開発サーバーが出力を繰り返し書き込んでいる場合、それはエディターが観測している稼働中の処理かもしれません。フォルダーの除外とそのサーバーの停止は、異なる説明を検証するものです。両方を一度に変更すると区別が失われるため、繰り返される操作に影響する単一の変更がどれかを記録してください。

エディターをリセットする前に拡張機能をテストする

Cursorのパフォーマンスガイドは拡張機能を無効にした状態での実行を推奨しています。作業を保存してCursorを通常どおり終了した後、ターミナルから次のコマンドで起動します。

cursor --disable-extensions

これはcursorシェルコマンドがインストールされていることを前提としています。利用できない場合は、Cursorの拡張機能ビューで必須でない拡張機能を無効にして比較します。テストを元に戻せるよう、無効にしたものを記録しておきます。

同じプロジェクト操作を繰り返します。改善した場合は、症状が再発するまで拡張機能を1つずつ復元します。改善しない場合は、以前の拡張機能の状態に戻して続行します。開いているファイルが異なるテストを、拡張機能が原因でない証拠として扱わないでください。また、次の手順としてユーザーデータディレクトリ全体を削除しないでください。

成功した拡張機能テストを絞り込む

拡張機能を無効にした実行で同じ操作が改善した場合は、すべての拡張機能を再インストールしたり、設定を破棄したりしないでください。記録した有効なセットから始め、候補が少数だけの場合は1つずつ復元します。拡張機能が多い場合は、半分ずつ復元することでグループをより速く絞り込めますが、各テストで同じプロジェクトを開き、同じ操作を完了することが条件です。

グループ方式は調査の近道であり、障害のある拡張機能がちょうど1つだけであることの証明ではありません。2つの拡張機能が相互作用する場合もあり、言語拡張機能を無効にすると、その作業負荷を引き起こす機能自体も失われることがあります。候補が判明したら、その候補を除いて、実際に必要なすべての拡張機能を有効にした状態でテストを繰り返してください。応答性だけでなく、コード補完、診断、ビルドも確認してください。

最終的な比較でもまだ1つの拡張機能を指している場合は、その名前とバージョンを記録してください。そのオプションが存在する場合、すべてのプロジェクトを変更するよりもワークスペース限定で無効にする方が適していることがあります。無効にすると必須機能が壊れる場合は、それを復元し、高速だが不完全なエディターを望ましい結果として扱うのではなく、再現手順をメンテナーに残してください。

不要な生成出力を除外する

AI支援の作業では、ビルド出力、エクスポートされたバンドル、生成画像、大きなログが生じることがあります。すべてのプロジェクトを含む親フォルダーを開くと、タスクに必要な量をはるかに超える内容にさらされます。まず実際のプロジェクトルートを開いてください。

Cursorは、ターミナルとMCPツールを例外として、AIによるプロジェクトファイルへのアクセスを制限する.cursorignoreを文書化しています。パフォーマンスガイドは大きな生成フォルダーを除外することを推奨しています。これはインデックス作成のみの変更より広い範囲に及びますが、すべての言語サーバーやファイルシステムウォッチャーを止めるものではありません。

これらのディレクトリが実際に生成出力であるプロジェクトでは、.cursorignoreファイルに次を含められます。

dist/
build/
.next/

まずフォルダーを確認し、既存の無視ルールを保持します。buildという名前のディレクトリに、プロジェクト内の手動管理のビルドスクリプトが含まれている場合があります。パターンを追加してもファイルは削除されませんが、AI機能から有用なコンテキストが失われる可能性があります。その後、インデックス作成の状態と同じエディター操作を再確認します。

まだ動作しているプロセスを追う

Macのメモリプレッシャーガイドは、使用済みメモリだけが信頼できる警告にならない理由を説明しています。使っていないワークスペースを閉じると、その内容を削除せずに稼働中の作業を助けられる場合があります。

除外によって何が変わったかを確認する

.cursorignoreを変更した後、ファイルの差分を確認し、遅い操作と、引き続きアクセス可能であるべきコードに関する通常の質問の両方をテストします。表示されるプロジェクトコンテキストが小さくなるのは、Cursorがタスクに必要なソースをまだ持っている場合にのみ有用です。重要なものを除外してしまった場合は、新しいパターンだけを削除してください。ignoreファイル全体を空のものに置き換えないでください。

これらの境界は別々に保ってください。Gitのignoreルールは、未追跡ファイルに対するGitの扱いを規定します。CursorのAIアクセス除外は、文書化されたAI機能を規定します。言語サーバー、拡張機能、ターミナルウォッチャーにはそれぞれ独自の動作があります。ビジー状態のコンポーネントを特定せずに同じパターンをあらゆる場所に追加すると、症状を隠し、有用な機能を削除してしまう可能性があります。

CPUが正常なのに回答の到着が遅い場合は、エディターのリソース使用状況とは別にAIリクエストを調査してください。作業が終わった後でも繰り返すたびにメモリが増加する場合は、比較可能な測定値を複数回と経過間隔を記録し、ワークスペースを開き直すとパターンが変わるかをテストします。その方が、ビルド中に観測された最大値だけを報告するよりも、メンテナーにとってはるかに有用です。

ディスク容量が問題の場合にのみディスクの残骸を整理する

Cursorのキャッシュ、古いツールのバージョン、セッション履歴、ワークツリーは、所有者も復元の必要性も異なります。ワークツリーには未コミットの変更や、他に存在しないコミットが含まれている場合があります。チャット履歴はまだ必要な作業である場合があります。

この別のストレージ作業にはAIコーディングツールのクリーンアップガイドを使用してください。CPUやメモリの問題が続く場合は、最小の再現ケース、バージョン、拡張機能の比較をCursorに送ります。ログにはプロジェクト名やコードが含まれる場合があるため、共有する前に確認してください。これにより、無関係なクリーンアップの結果ではなく、実際の速度低下に焦点を当てた報告になります。