Cursorが遅いときの対処法 — レスポンスを3倍速くする10の設定 (2026年版)

Cursorが遅いときの対処法 — レスポンスを3倍速くする10の設定 (2026年版)

この記事のポイント Cursorが重くなる原因のほとんどは、パソコンの性能ではなく「読ませすぎ」です。プロジェクト全体をインデックス(検索用の索引)に取り込みすぎ、AIに渡す情報が膨らみ、返事が遅くなります。 効くのは3つ。.cursorignoreで索引から除外する、チャットをこまめに切る、モデルを用途で使い分ける。 拡張機能の整理とメモリ設定は、上の3つをやっても遅いときの追加手当てです。 最低8GBメモリ・推奨16GBという公称スペックに届いていない場合は、設定より先にそこが原因です。

保存した瞬間に虹色のカーソルが回り、チャットに一行書くたび数秒待たされる。Cursorを使っていて、そんな状態になっていませんか。

多くの場合、犯人はパソコンではありません。索引に取り込むファイルが多すぎて、AIに毎回大量の情報を渡している状態です。ここを削るだけで、体感速度は目に見えて変わります。

この記事は、効果の大きい順に10個の設定を並べました。上から3つやれば大半は解決します。


Cursorが遅いとは、そもそも何が遅いのか

Cursorが遅いときの対処法 — レスポンスを3倍速くする10の設定 (2026年版) 図2

Cursorが遅いとは、コード補完の表示・チャットの初回応答・エージェントの実行という3つのうち、どれかが数秒以上待たされる状態です。原因も対処も別物なので、まず切り分けます。

同じ「遅い」でも中身はまったく違います。混同したまま設定をいじると、効かない対策に時間を溶かします。

症状主な原因効く対処
Tab補完が出るまで待つエディタ側の負荷・拡張機能の競合拡張機能の整理、補完系拡張の停止
チャットの1文字目が遅いコンテキスト過多・モデル選択会話を切る、軽いモデルへ切替
エージェントの作業が止まるインデックス肥大・回線.cursorignore、回線確認
起動やファイル切替が重いメモリ不足・ワークスペース肥大メモリ割当、フォルダ分割

つまり、まず「どこが遅いのか」を10秒で判定してから設定に手を付けます。

上の表の右側は、これから順に説明していく項目そのものです。


なぜCursorは重くなる?遅さの正体は3つだけ

Cursorが遅いときの対処法 — レスポンスを3倍速くする10の設定 (2026年版) 図3

Cursorが重くなる要因は、インデックス肥大・コンテキスト過多・拡張機能の競合の3つに集約されます。ハードのスペック不足はその次です。

インデックスとは、AIがプロジェクト内を検索するために作る索引のことです。ファイル数が増えるほど作成も参照も重くなります。

コンテキストとは、AIに毎回渡す前提情報のことです。会話が長引くほど雪だるま式に膨らみます。

拡張機能の競合は見落とされがち。CursorはVS Codeのコードをベースにしているため、VS Code向けの拡張機能がそのまま入ります。AI補完系の拡張が2つ動いていれば、当然どちらも遅くなります。

ここが効く順番 ① インデックスから要らないものを外す ② 会話を切ってコンテキストを軽くする ③ 拡張機能を減らす ④ ハード側(メモリ・回線)を疑う

この4段を、次のセクションから具体的な操作に落としていきます。


対処1: `.cursorignore` で索引から外す(効果は最大)

.cursorignoreは、Cursorに「このファイルは読まなくていい」と伝えるための設定ファイルです。プロジェクト直下に置くだけで、索引の対象から外れます。

一番効きます。node_modulesdist、ビルド成果物、大きなデータファイル。これらは開発中に読み返す必要がほぼないのに、索引には全部乗っています。

プロジェクト直下に.cursorignoreという名前のファイルを作り、除外したいパスを1行ずつ書きます。書き方は.gitignoreと同じです。

node_modules/
dist/
build/
.next/
coverage/
*.log
*.lock
public/assets/
data/*.json

除外すべきものの目安を、影響の大きい順にまとめました。

除外対象典型的な容量感除外の可否
node_modules/数百MB〜数GB迷わず除外
ビルド成果物(dist, .next数十MB〜数百MB迷わず除外
画像・動画・PDFプロジェクト次第基本は除外
大きなJSON・CSV数MB以上なら重い参照しないなら除外
テストのスナップショット数MB〜読まないなら除外
自分が書いたソース小さい残す

つまり、「自分が手で書いていないファイル」は原則すべて除外対象です。

.gitignoreをすでに書いているなら、その中身をコピーして始めるのが手っ取り早いです。それだけで索引が数分の一になるプロジェクトは珍しくありません。


対処2: チャットをこまめに切る — 長い会話ほど遅くなる

チャットは1つのスレッドが長くなるほど、AIに渡す情報が増えて応答が遅くなります。話題が変わったタイミングで新規チャットに切り替えるのが、無料でできる最速の改善です。

同じスレッドで50往復もすれば、最初の方の関係ない話まで毎回読み直されます。トークン(AIが扱う文字のかたまり)が増えれば、その分だけ待ち時間になる。当然の話です。

切るタイミングの目安を持っておくと迷いません。

  • ファイルや機能が変わったとき
  • 20往復を超えたとき
  • AIが同じ間違いを繰り返し始めたとき
  • 前の話を引きずった変な提案が出たとき

3つ目と4つ目は速度だけの問題ではありません。コンテキストが汚れると、精度も落ちます。遅くて、しかも間違える。最悪の組み合わせ。

長い会話を切るのが惜しいときは、要点だけ自分でまとめて新しいチャットに貼り直します。手間は30秒、効果は数秒×残りの往復すべて。


対処3: モデルを用途で使い分ける — Autoに任せきらない

Cursorはモデルを選べます。重い作業には高性能モデル、単純な修正には軽いモデル、と切り替えるだけで待ち時間が変わります。

Cursor公式の料金ページによると、Proプラン(月20ドル)ではTabとAuto内のモデルが無制限に使え、フロンティアモデル(最新の高性能モデル)は月20ドル分までAPI単価で利用できる仕組みになっています(2026年8月時点)。つまり、高性能モデルを何にでも使うのは速度的にもコスト的にも損。

用途別の選び分けはこう考えます。

作業内容選ぶモデル理由
変数名の変更・整形軽いモデル / Tab秒で返る。高性能は過剰
関数1つの実装中位モデル速度と精度のバランス
設計の相談・大規模リファクタフロンティアモデル待つ価値がある
大量ファイルの一括変更エージェント+高性能途中で止まると損

つまり、待ち時間の大半は「軽い作業に重いモデルを使っている」ことから生まれます。

Autoは便利ですが、常に最適を選ぶわけではありません。「今なぜか遅いな」と感じたら、モデル欄を一度見る癖をつけてください。地味に効きます。

AIツール全般のモデル選びで迷うなら、検索系AIの使い分けを整理したFeloの完全ガイドが参考になります。調べ物をCursorの外に逃がすだけでも、コンテキストは軽くなります。


拡張機能はどこまで削るべき?

Cursorの拡張機能は、AI補完系・リンター・重量級のテーマを中心に整理します。特にAI補完系が2つ以上動いている状態は、遅さの直接原因です。

CursorはVS Codeベースなので、拡張機能がそのまま移植できます。移行時に全部持ってきた人ほど重い。

削る優先順位はこうです。

  • 他社のAIコード補完拡張(Cursor本体と競合する)
  • 使っていない言語のリンター・フォーマッター
  • Gitの履歴をリアルタイム表示する重い系
  • アイコンテーマ・装飾系のうち複数入っているもの

判定方法は簡単です。コマンドパレットから拡張機能の実行時間を計測する機能を開き、起動に時間がかかっているものを上から止めます。

拡張の種類目安判断
AI補完系(他社製)Cursor本体と重複無効化一択
大規模言語サーバー使う言語なら残すプロジェクト単位で有効化
Git系の重い拡張起動が1秒超なら疑う必要時だけ有効化
テーマ・アイコン複数入りがち1つに絞る

つまり、拡張機能はワークスペース単位で有効・無効を切り替えるのが正解です。全部グローバルに入れっぱなしにしない。

削る作業そのものが面倒なら、社内のツール棚卸しと同じ発想が使えます。使っていないものを定期的に洗い出す手順は、社内監査向けAIツールの記事の考え方がそのまま応用できます。


メモリとストレージはどれだけ必要?

Cursorの推奨構成はメモリ16GB・SSD 20GB・回線50Mbps以上です。最低要件は8GBメモリ・5GBストレージですが、この線では大規模プロジェクトの索引作成やエージェント実行が遅くなります。

数字で押さえておくと、設定をいじるべきか買い替えを検討すべきかの判断が早いです。

項目最低要件推奨構成
CPUIntel i5 / AMD Ryzen 5以上Intel i7 / AMD Ryzen 7 / Apple M2
メモリ8GB16GB
ストレージ5GB20GB SSD
回線安定したブロードバンド50Mbps以上

つまり、8GBのマシンで大きなリポジトリを開いているなら、設定の前にプロジェクトを分割するほうが速いです。

メモリが足りているのに重い場合は、Cursorが同時に開いているワークスペースの数を疑ってください。3つも4つも開けば、それぞれが索引を保持します。

回線も見落とされがち。エージェント機能はネットワーク接続が必須で、オフラインでは動きません。テザリング環境で「Cursorが遅い」と感じるなら、それは設定の問題ではないです。


インデックスの再構築はいつやるべき?

インデックスの再構築は、.cursorignoreを書き換えた直後と、ブランチを大きく切り替えた後に実行します。それ以外のタイミングでは不要です。

除外設定を書いても、すでに作られた索引は自動で消えるとは限りません。設定画面からインデックスを削除して作り直すと、除外が確実に反映されます。

再構築が必要な場面と不要な場面を整理します。

  • 必要: .cursorignoreを新規作成・大幅編集した直後
  • 必要: 大量のファイルを削除・移動した後
  • 必要: AIが存在しないファイルを参照し始めたとき
  • 不要: 日常的なコード編集の後(自動で追随します)

再構築中は一時的に重くなります。昼休みやビルド待ちのタイミングでやるのが賢いです。

索引が壊れていると、遅いだけでなく「もう消したファイル」をAIが提案してきます。心当たりがあれば、まず再構築。


Composerとエージェントが止まるときの見方

エージェントの実行が止まったように見えるときは、ファイル数の読み込みが原因です。作業対象を明示的に絞ると、体感速度が変わります。

エージェントは、指示があいまいなほど広く探します。「このプロジェクトのバグを直して」は最も遅い頼み方。

速くなる頼み方の型はこうです。

  • 対象ファイルを@で明示する
  • 変更範囲を「この関数だけ」と限定する
  • 一度に頼むタスクを1つにする
  • 大きい作業は分割して連続で頼む

@でファイルを指定すると、AIは索引全体を探し回らずに済みます。これは速度だけでなく、余計な場所を書き換えられる事故の防止にもなります。

止まったように見えて実は動いている、という場合もあります。エージェントの実行ログを開き、ファイルを読んでいる最中かどうかを確認してから中断してください。


設定ファイルで効く項目はどれ?

Cursorの設定で速度に効くのは、インデックス関連・補完の遅延時間・テレメトリ関連の3つです。それ以外の項目は体感に響きません。

設定画面をすべて眺めるのは時間の無駄です。触るべき箇所だけ挙げます。

設定項目変更内容期待できる効果
インデックス対象.cursorignoreで絞る索引の作成・参照が軽くなる
補完の待ち時間遅延を長めに設定打鍵中の無駄な呼び出しが減る
自動保存遅延保存にする保存トリガーの解析が減る
大きいファイルの扱い開かない・分割するエディタ側の描画負荷が下がる

つまり、設定画面で稼げるのは「呼び出し回数を減らす」方向の調整だけです。劇的な高速化はここでは起きません。

エディタ本体の描画が重いときは、ミニマップやインラインの装飾表示を止めるのも手です。ただし効果は限定的。索引を削るほうが先です。


それでも遅いときに疑う3つのこと

設定を全部やっても遅い場合は、ネットワーク・アカウント側の利用上限・OSやアプリのバージョンを確認します。この3つはローカル設定では解決しません。

順に潰していきます。

ネットワークは、社内プロキシやVPN経由だと遅延が乗ります。エージェント機能は常時接続が前提なので、回線が細いと素直に遅い。

利用上限も見落としがちです。Cursor公式の説明によると、Proプランではフロンティアモデルの月20ドル分を超えると、追加分は原価ベースの購入という扱いになります(2026年8月時点)。上限周辺の挙動で「遅くなった」と感じるケースがあります。

バージョンは、Cursor本体だけでなくOS側も見てください。古いままだと既知の不具合を踏み続けます。

確認箇所症状の出方対処
VPN・プロキシチャットの初回応答だけ遅い直結で試す
プラン利用量特定モデルだけ遅い・使えないプラン設定を確認
バージョン特定操作で固まる本体とOSを更新

つまり、ここまで来たらローカル設定ではなく環境側の問題です。切り分けの順番を守れば、10分で原因にたどり着けます。


高速化の効果はどれくらい期待できる?

改善の効き方は環境で変わりますが、体感で最も差が出るのは索引の除外設定とチャットの切り替えです。この2つで待ち時間の大半は削れます。

「3倍速くなる」という言い方をしましたが、正確には「3倍待たされていた状態が正常に戻る」が実態です。索引に数千ファイル乗っていた状態から必要な数百ファイルに絞れば、単純に処理量が減ります。

期待値の目安をまとめます。

施策効きやすい症状手間
.cursorignore全般(特にエージェント)5分
チャットを切るチャットの応答遅延即時
モデル使い分け軽作業の待ち時間都度
拡張機能の整理補完・起動の遅さ20分
ハード増強全般費用がかかる

つまり、上4つは全部無料で、合計30分もかからないということです。ハードを疑うのはその後で十分。


AI PICKS編集部の判定

Cursorが遅いという相談の9割は、.cursorignoreを書いていないことが原因です。逆に言えば、5分の作業で解決する問題を放置している人が多すぎます。ここは断言します。まず.gitignoreの中身をコピーして.cursorignoreを作り、インデックスを再構築してください。それだけで別のアプリになります。

その次に効くのがチャットの切り替え。長い会話を大事に育てる癖は、Cursorでは逆効果です。話題が変わったら捨てる。要点だけ持ち越す。この運用に切り替えるだけで、往復あたり数秒が積み上がって効いてきます。

一方で、設定画面を細かくいじる系の高速化は正直イマイチです。補完の遅延時間を調整しても、索引が肥大したままなら焼け石に水。順番を間違えると徒労に終わります。

メモリ8GBのマシンで大規模リポジトリを扱っているなら、それは設定の問題ではありません。推奨は16GBです。プロジェクトを分割するか、マシンを見直すか。ここだけは無料では解決しません。


よくある質問(FAQ)

Q. `.cursorignore` と `.gitignore` は何が違いますか?

.gitignoreはGitの管理対象から外す設定、.cursorignoreはCursorの索引対象から外す設定です。役割は別ですが、除外したい中身はほぼ重なります。まず.gitignoreの内容をコピーして始めるのが手軽です。

Q. インデックスを再構築すると作業内容は消えますか?

消えません。索引はあくまで検索用の索引で、ソースコードそのものには影響しません。ただし再構築中はAIの検索精度が一時的に落ちるので、作業の合間に実行してください。

Q. 無料のHobbyプランだから遅いのでしょうか?

プランによる速度差はありますが、遅さの主因ではないことが多いです。Hobbyプランはエージェントリクエストに制限があるため、上限に達すると使えなくなります。ただし「重い・もたつく」という症状は、索引や拡張機能の問題であることがほとんどです。

Q. VS Codeより明らかに重いのですが、仕様ですか?

仕様ではありません。CursorはVS Codeのコードをベースにしているので、素の状態なら重さはほぼ同じです。差が出るのは、AI機能が索引を作り、コンテキストを送っている分です。除外設定でその負荷を減らせば、差は小さくなります。

Q. モデルを変えても遅い場合はどうしますか?

コンテキストの量を疑ってください。同じ質問を新規チャットで投げ直して速くなるなら、原因は会話の長さです。新規チャットでも遅いなら、索引かネットワーク側の問題になります。

Q. Windowsだと遅いという話は本当ですか?

OSによる差より、ウイルス対策ソフトのリアルタイムスキャンの影響が大きいです。プロジェクトフォルダとnode_modulesをスキャン対象から外すと改善する場合があります。設定変更は社内規定を確認してから行ってください。

Q. 大きいプロジェクトを分割するとして、どう分けますか?

フロントエンドとバックエンド、あるいは機能単位で別ウィンドウにするのが基本です。1つのワークスペースに全部載せるより、作業中の領域だけ開くほうが索引も軽く、AIの精度も上がります。

Q. Proプランに上げれば速くなりますか?

速度そのものより、使える上限が変わるという理解が正確です。Proは月20ドルで、Tabとauto内のモデルが無制限、フロンティアモデルは月20ドル分までAPI単価で使えます。上限で止まって遅く感じていたなら効果があります。索引が原因なら、課金しても変わりません。


あわせて見たいツール・カテゴリ

次に読むなら、AIコーディングツールのカテゴリ一覧です。Cursorを速くしても限界を感じるなら、そもそも別のツールが向いている可能性があります。乗り換えの判断材料が一通りそろいます。