0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@koji0705(康治 河村)

Cursorがメモリを異常に大きくなる要因と対処法（備忘録）

0
Last updated at Posted at 2026-05-28

はじめに

最近、Cursorを利用していると、利用中にメモリが10GBまでいき、処理がダウンしてしまう事が発生。
再起動とかすれば一時的に治るのですが、また再発します。根本的に治したいなと思い、備忘録として残しておきます。

本記事では、実際に調査した結果と、効果があった対処法をまとめます。

※ 記事内のディレクトリ名（.workspace-links/、frontend-web など）は説明用の仮称です。実プロジェクトのパス・名称は意図的に伏せています。

対象環境

  • OS：mac
  • エディタ：Cursor
  • プロジェクト：バックエンド API リポジトリ（Go、ワークスペース単体で約数百 MB）
  • 構成上の特徴：ワークスペース内のシンボリックリンク用ディレクトリ経由で、別リポジトリのフロントエンド 2 つを参照

想定読者

  • Cursor で大規模・複数リポジトリ構成のプロジェクトを開いている方
  • 再起動では一時的にしか治らないメモリ問題に悩んでいる方

結論（先に要点）

対策 効果 優先度
.cursorignore にシンボリックリンク先を除外 インデックス対象を大幅削減 最高
search.followSymlinks: false シンボリックリンクを辿らない 高
files.watcherExclude / search.exclude ファイル監視・検索の負荷軽減 高
argv.json の max-old-space-size Node.js ヒープの上限設定 中
Cursor の完全再起動 設定反映・インデックス再構築 必須

症状

  • Cursor 利用中にメモリ使用量が 10GB 前後まで増加する
  • 再起動すると一時的に改善するが、しばらくすると再発する
  • Activity Monitor などで Cursor / Helper プロセスのメモリが異常に大きい

調査の流れ

1. ワークスペースの実サイズを確認

du -sh /path/to/your/project/

今回のバックエンド API リポジトリ本体は 数百 MB 程度でした。一見、10GB まで膨らむほど大きくはありません。

2. シンボリックリンクの有無を確認

# ルート直下のシンボリックリンク
ls -la /path/to/your/project/ | grep "^l"

# 再帰的に symlink を探す
find /path/to/your/project -type l

# シンボリックリンクをまとめているディレクトリの中身（今回の犯人）
ls -la /path/to/your/project/.workspace-links/

ルートに シンボリックリンク用ディレクトリ（ここでは .workspace-links/ と呼ぶ）があり、その中に別リポジトリへのシンボリックリンクがありました。

.workspace-links/
├── frontend-web   -> /path/to/other-repo/frontend-web   (約 1.1GB)
└── frontend-app   -> /path/to/other-repo/frontend-app   (約 1.3GB)

node_modules だけでも合計 約 1.6GB。Cursor はシンボリックリンクを辿ってインデックスするため、見た目数百 MB のプロジェクトが、実質 2.8GB 以上として扱われていました。

3. .cursorignore の中身を確認

もともと /tmp や .env.* 程度しか書かれておらず、シンボリックリンク用ディレクトリが除外されていませんでした。

根本原因

主因：シンボリックリンク経由の巨大プロジェクトのインデックス

Cursor（VS Code 系）は、ワークスペース内のシンボリックリンクを辿り、リンク先のファイルもインデックス対象にします。

  • バックエンド API 本体：数百 MB
  • リンク先のフロントエンド 2 リポジトリ：合計 2.4GB 超
  • その中の node_modules：大量の小ファイル → インデックス・ファイルウォッチの負荷が極端に高い

これが 10GB 級メモリ使用の最大の要因でした。

見た目はバックエンドだけ開いているのに、実質 2.8GB 以上を Cursor が抱え込んでいた、という構図です。

副因：参照頻度の低い大量ファイル

ディレクトリ 内容 備考
migrations/ 大量の SQL マイグレーションファイル 編集時以外は不要
seeds/ 多数の JSON シードファイル 同上
go.sum 自動生成 編集不要

単体では小さいですが、インデックス対象に含めると無駄なメモリ・CPU を消費します。

よく聞くが、今回は副次的な対策

ネット上では次のような Tips も見かけます。

  • Settings → Application → Performance の Memory Limit
  • Developer Tools → Clear site data（キャッシュ削除）
  • Extensions の Auto Update を none に
Tips 今回の評価 理由
Memory Limit（Settings） 補助的 UI 上の制限。argv.json の方が Node ヒープに直接効く
Clear site data 一時的 インデックス肥大の根本にはならない
Extensions Auto Update = none 影響小 更新チェックのオーバーヘッド削減程度
Suggestions 無効化 影響小 補完コストの微減
Follow Symlinks 無効化 有効 今回の symlink 問題に直結 → settings.json で実施済み

ネットでよく見る「パフォーマンス最適化」記事のうち、シンボリックリンク対策だけは今回のケースでは必須でした。

実施した対処法

対策 1：.cursorignore の強化（最重要）

Before（抜粋）

/tmp
/logs
.env
.env.*

After（追記分）

プロジェクトルートの .cursorignore に以下を追加しました。

# ===== メモリ最適化 =====

# シンボリックリンク先（別リポジトリのフロントエンド等）
# Cursorはシンボリックリンクを辿ってインデックスするため除外必須
.workspace-links/

# DBマイグレーション履歴（参照頻度低）
/migrations

# シードデータ
/seeds

# 自動生成ファイル
go.sum
coverage.out

# コーディング時に不要なディレクトリ
/assets
/deploy
/.ai-notes
/tests/fixtures

ポイント：

  • .cursorignore は Cursor の AI・インデックスが読み込む対象を制限する
  • .gitignore とは別ファイルなので、Git で無視していても Cursor には読まれることがある
  • /migrations を除外すると、AI にマイグレーションを渡したくない場合は有効だが、必要なら行を外す
ファイル 主な役割
.gitignore Git の追跡対象から除外
.cursorignore Cursor のインデックス・AI コンテキストから除外
.vscode/settings.json エディタの監視・検索挙動の制御

対策 2：.vscode/settings.json の設定

{
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/.workspace-links/**": true,
    "**/migrations/**": true,
    "**/seeds/**": true,
    "**/assets/**": true,
    "**/deploy/**": true,
    "**/.ai-notes/**": true,
    "**/tmp/**": true,
    "**/persist/**": true
  },
  "search.exclude": {
    "**/.workspace-links/**": true,
    "**/migrations/**": true,
    "**/seeds/**": true,
    "**/assets/**": true,
    "**/deploy/**": true,
    "**/.ai-notes/**": true,
    "go.sum": true,
    "coverage.out": true
  },
  "search.followSymlinks": false
}
設定 役割
files.watcherExclude ファイル変更の監視対象から除外（CPU・メモリ削減）
search.exclude Cmd+Shift+F の検索対象から除外
search.followSymlinks シンボリックリンクを辿らない（今回の核心）

対策 3：argv.json で Node.js ヒープの上限を設定

~/.cursor/argv.json に以下を追加しました。

{
  "locale": "ja",
  "max-old-space-size": 4096
}
  • 単位は MB（4096 = 4GB）
  • デフォルトは実質無制限に近く、際限なく増えることがある
  • 変更後は Cursor の完全終了（Quit）→ 再起動が必須
# macOS で Cursor を完全終了
osascript -e 'quit app "Cursor"'

設定後の確認手順

  1. Cursor を完全終了して再起動する
  2. Activity Monitor で Cursor のメモリを確認する
  3. しばらく通常作業を続け、再発しないか様子を見る

目安として、インデックス再構築直後は一時的に上がることもありますが、安定後は以前より大幅に低いはずです。

うまくいかないときのチェックリスト

  • .cursorignore にシンボリックリンク用ディレクトリ（例：.workspace-links/）が入っているか
  • search.followSymlinks が false になっているか
  • argv.json 変更後に Cursor を再起動したか
  • ワークスペースを「フォルダごと」開いているか（親ディレクトリを開いていないか）
  • 別の巨大リポジトリをマルチルートで追加していないか

まとめ

現象 原因 対策
メモリ 10GB 級 シンボリックリンク先（フロント + node_modules）のインデックス .cursorignore + search.followSymlinks: false
再起動で一時回復 インデックスの再構築でリセットされるだけ インデックス対象そのものを減らす
Go の定義ジャンプ不可 Go 拡張 / gopls の状態 拡張の有効化・Language Server 再起動

再起動は対症療法。インデックス対象を減らすのが根本対策です。

特にモノレポや「別リポジトリへの symlink をワークスペースに置いている」構成では、シンボリックリンク用ディレクトリを最初から .cursorignore に入れておくことを強くおすすめします。

フロントエンドを参照したいときは、別ウィンドウでフロントのリポジトリを直接開く方が、バックエンドのワークスペースに symlink を置くより安全です。

免責

環境・Cursor のバージョン・拡張機能の組み合わせによって挙動は異なります。本記事の設定を適用する際は、必要に応じてバックアップを取ったうえで、段階的に試してください。

参考

投稿時のタグ例（Qiita）

Cursor VSCode メモリ パフォーマンス Go gopls シンボリックリンク cursorignore

変更履歴

  • 2026-05-27：初版（調査・対処の備忘録）
  • 2026-05-27：固有名を汎用表現に置換（公開用）
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?