Cursorをもっと賢く使いたい人のための12のヒント

(stdy.blog)

99 ポイント投稿者 spilist2 2025-06-23 | 22件のコメント | WhatsAppで共有

6/23時点の内容で、私の経験 + CursorのReddit + Cursorコミュニティ + SNS + 複数のブログ記事を組み合わせて作成しました。反論、批判、議論は歓迎です。

ヒント 1. 戦略的にモデルを選択しよう

モデルごとにコーディング能力、速度、コストが異なるため、状況に応じて選ぶことが重要。
Thinkingモデル（Claude 4、Gemini 2.5 Pro など）は自律性が高いが、速度は遅い。
Non-Thinkingモデル（GPT 4.1 など）は明確な指示によく従い、速度が速い。
作業の種類によって推奨モデルは異なる（例: 単純な変更は Sonnet、複雑な計画は Opus）。
Auto-select機能は信頼性が低いため、複数のモデルを自分で使ってみて、自分なりのスタイルを見つけるのがよい。

ヒント 2. 複雑なアプリを修正するときは、まずAskモードで計画を立てよう

Agentモードはコードを直接修正するため、複雑なアプリでは既存機能を壊す可能性がある。
Askモードはファイルを修正しない読み取り専用モードで、計画を立てる際に非常に有用。
まずAskモードでAIと計画を議論し、その後にAgentモードで実行するのが安全。
「今すぐ修正しないで」のようにプロンプトを明確にすると、Askモードの不要な動作を減らせる。
Manualモードは参照するファイルを自分で指定する必要があるため、活用度は低め。

ヒント 3. デバッグではすぐにファイルを修正させず、テストと一緒に原因を把握しよう

AIにいきなりバグ修正を任せると、失敗を繰り返しやすい。
1段階（Agent）: バグを再現する「失敗する」テストコードを先に書かせる（TDD方式）。
- 「XページでYを押すとAのように動作すべきなのに、Bのように動作する。TDD方式で直したいので、この現象を再現するテストコードを書いて実行して。現時点ではテストコードはひとまず失敗する必要があることを覚えておいて。私が間違っている可能性もあるので、再現できなければ教えて。私の指示なしに問題の修正を始めないで。」
2段階（Ask）: あり得る原因と確認方法を説明させ、根本原因を把握する。
- 「バグの根本原因を把握したい。この現象がなぜ、どのようなときに起こるのか、考えられる選択肢を示して。さらに、その選択肢のうちどれが正しいかを確認する方法も一緒に話して。どんな情報がさらに必要か、何をログに出してみるべきかなど。実行する必要はなく、説明だけして。もしテストコードを書いている時点で原因がすでに分かっていたなら、それも説明して。」
3段階（Agent）: テストコードを .cursorignore でロックしたうえで、テストが通るまでコード修正を指示する。
- 「さっき作ったテストコードを .cursorignore に追加して。その次に、あなたが示したとおり可能性の高いものから根本原因を把握しつつ、理想的な動作フローをフローチャートにまとめて。そしてその理想的なフローを使って、テストコードが通るまでコードを修正して。私が確認または介入すべきことがあれば教えて。」
広告
テストコード作成のルールも作っておくとよい

ヒント 4. Cursorにルールを自分で管理させて、少しずつ賢くしていこう

チャットセッションで意味のある会話が交わされたなら、/Generate Cursor Rules機能を活用できる。
「今回の会話内容をもとにRuleを作成または修正して」と依頼すればよい。
特にデバッグ後にバグの原因が分かったなら、同じミスを繰り返さないようにRuleを追加・修正させると有用。
これにより、Cursorが自ら学習・保守し、徐々に賢くなっていくようにできる。

ヒント 5. 複数タブとAuto系オプションで生産性を高めよう

Cursorでは複数のチャットタブを同時に使える。あるタブでAgentがコードを修正している間に、別のタブでAskモードによる別作業ができる。
Auto-run オプションを有効にすると、ターミナル実行やファイル書き込みなどをいちいち承認せずに自動で進められる。
Auto-Fix Lints オプションを有効にすると、型エラーなどを自動で修正してくれて便利。

ヒント 6. 1つのチャットセッションを長く続けすぎないようにしよう

チャットが長くなると、コンテキストサイズの制限によりAIが以前の重要情報を忘れることがある。（Cursorが自動で要約してしまう）
1つの作業が終わったら、新しいチャットセッションを始めるほうが有利。
新しいチャットでは @Past Chats を使って、以前の会話要約をコンテキストとして注入できる。
重要な内容はルール化しておけば（ヒント4）、長いチャットを維持する必要性が減る。

ヒント 7. 意味のある変更が完了したら、必ずコミットしよう

1つの作業が終わったら、必ずGitにコミットする習慣が重要。
コミットは、AIがコードを誤って修正したときに戻れる最低限の安全装置になる。
Cursorチャットを通じて、Gitの初期設定からコミットメッセージ作成まで支援を受けられる。
- 「このコードベースをGitHubにアップロードしたい。ただ、私はGitとGitHubについて何も知らず、アカウントもない。Gitがインストールされているかどうかも分からない。ステップバイステップで手伝って。」
広告
AI Commit Message機能を使えば、コミットメッセージを自動生成することもできる。

ヒント 8. Cursorにコード構造を伝え、ファイルの長さとファイル名を調整しよう

Cursorの内部Toolsの特性を理解しておくとよい
- List Directory はファイル内容は読まず、ディレクトリ名とファイル名だけを読む
- Read File はファイル内容を一度に最大250行までしか読めない（Maxモードでは750行）
- 参照したファイルやディレクトリのサイズが大きすぎると、全体が入る代わりに関数呼び出し部のような重要部分だけが残り、圧縮される
- 1つのチャットセッションでTool呼び出しは25回までで、それ以上行うには Continue を自分で押す必要がある（Auto apply editオプションが有効でも同様。MaxモードではContinueなしで200回まで可能）
したがって、役割が明確になるようにファイル名とディレクトリ名を付け、ファイルの長さは500行以内に保つのがよい。
コアとなるディレクトリ構造やコンポーネント情報は Always Applied ルールとして追加しておくと、AIが毎回探索する必要がない。
AIがコード構造を把握できるよう、ドキュメントを作ってルールに追加してほしいと依頼できる。
- 「このコードベースの構造と重要ファイルを、あなたがひと目で把握できるドキュメントとして作成して。mermaid diagramを使ってもいい。そしてそれを適切なプロジェクトルールとして追加して。AlwaysApply: true にして。」

ヒント 9. ファイルが長くなったら、Cursorにモジュール化させよう

ファイルが長くなりすぎたら、AIにモジュール化を依頼するのがよい。
1段階（Ask）: 「このプロジェクトをモジュール化するなら、どの観点や戦略で進めるのがよいか提案して。例えば: 1) Layered Architectureの観点 2) AOPの観点 3) FSDの観点 4) クリーンアーキテクチャの観点」
2段階（Ask）: 「あなたが示した戦略を総合して、適切なモジュール化計画を立てて。」
3段階（Agent）: 「その計画を文書化したうえで実行して。」

ヒント 10. @を使って積極的にコンテキストを注入しよう

@ 記号を使って、ファイルやフォルダ以外にもさまざまなコンテキストを直接注入すると、AIがよりうまく作業できる。
@Code: コード内の特定の関数や変数など、一部だけを参照できる。
@Docs: ライブラリの公式ドキュメントを参照させ、より正確なコードを書かせる。Cursorがすでに持っているdocsもあり、URL経由で追加することも可能
@Git: 特定ブランチやコミット内容を参照させ、比較や説明をさせることができる。
@Web、@Link: Web検索をしたり、特定リンクの内容を読み込ませたりできる。
@Recent Change: コードベースの最近の変更を参照させられる。正確な動作方式は見つけられなかったが、unstaged changesと最近のコミットをもとにしているように見える。コミット管理を厳密にしていない非開発者には有用そう

ヒント 11. セキュリティが重要ならPrivacyモードを有効にしよう

Privacyモードを有効にしないと、コードやプロンプトなどのデータが収集され、モデル学習に使われる可能性がある。
Privacyモードを有効にすると、コードの一部が暗号化されて一時保存されることはあるが、永続保存されたり学習に使われたりはしない。
ただし、Privacyモードではバックグラウンドエージェントなど一部の最新機能は使えない。
詳細は、Cursorがプライバシーモードについて説明しているドキュメントを参照

ヒント 12. 開発を快適かつ正確にするMCPとツールを使おう

タスク管理の面では、Memory Bank、TaskMaster、Voosterがおすすめ
Cursorの公式ドキュメントのMCPはディープリンクで一括インストール可能
- Browserbaseでブラウザ起動、クリック、コンソール読み取り、スクリーンショット取得など
- PlayWrightでE2Eテストを追加する
- Sentryでエラーを監視して修正する
- StripeとPaypalで決済する
- NetlifyとHerokuでデプロイする
- SnykとSemgrepでセキュリティ検査を行う
- SupabaseでDBテーブルを読み書きする → Cursor公式ドキュメントには載っていないものだが、バイブコーダーなら必須インストールだと思う
会社内で作業していて、会社の状況や複数プロダクトに関するコンテキストをしっかり伝える必要があるなら、MCPを自作してみるのもよい。（参考: Working with Documentation）
StageWiseのような外部ツールを活用して、UIの特定部分を指してバグ修正などを依頼することもできる。

そのほかの細かなヒント

Maxモード: リクエスト課金ではなくトークンベース課金で、より大きなコンテキストとより多くのTool利用が可能。
モデル追加: 設定でClaude 4 Opusなど、デフォルトで隠れているモデルを有効化できる。
Custom API Key: 自分のLLM APIキーを連携する機能。活用度は低め。なお、これを使ってもCursorサーバーは必ず経由する
設定同期: 複数PC間での設定同期は、まだ公式には十分サポートされていない。Profile Export/Importはうまくいかないという報告があり、数週間前に拡張機能が1つ出たが、6/23時点ではいくつか問題がある
- VSCode Marketplaceには表示されるが、CursorのExtension一覧では検索されない
- VSCodeでインストールした後、Cursorの Import VSCode Settings and Extensions 機能で取り込むことは可能。だが実際には拡張機能が正しく初期化されない（関連Issue）
- よさそうなので、開発者が早く修正してくれることに期待

22件のコメント

elddytbt 2025-06-25

ヒント4、ヒント6、いいですね~~

気になることがあるのですが、私は1か月500個ではあまりにも少ないのですが、この問題はどう解決していますか？

spilist2 2025-06-25

最近、制限はなくなったのではありませんか？

私はClaude Codeも併用していますし、主にAI Studioで議論を十分に詰めたうえで洗練された依頼をするように努めていること、さらにルール設定や、必要に応じてタブ補完で直接実装することなどもあってか、不足だと感じたことはあまりありません。

fanotify 2025-06-24

基本的に、有料サブスクリプションに加入しないとその機能は使えないのでしょうか？それとも、利用量が少なければ無料の基本会員でも試せるのでしょうか？

spilist2 2025-06-24

私の経験では、Cursor は無料プランの機能と提供量がかなり限られているので、無料で使うのは簡単ではないと思います。

無料で使えるモデルはありますが、そのぶんコーディングもあまり得意ではありません。

eususu 2025-06-24

とても良いヒントです。
ありがとうございます！

dnltmdwhd 2025-06-24

知らなかった便利な内容もいくつかあって、とても参考になりました。ありがとうございます！

jk34011 2025-06-24

良いヒントをありがとうございます〜とても勉強になりました。

dkmin 2025-06-24

有益な内容の共有ありがとうございます。 =b

"ただし、Privacyモードではバックグラウンドエージェントなど一部の最新機能は使用できない。"
=> 具体的な内容が気になります。出典をお願いします。

ref.
https://docs.cursor.com/background-agent

Background Agents are available in Privacy Mode. We will never train on your code, and we will only retain code for the purposes of running the agent. Learn more about Privacy mode

spilist2 2025-06-24

あっ、少し前までは使えなかったのに変わったんですね!! ありがとうございます。

baeba 2025-06-23

私の場合、
AIがソースコードを変更する前、またはプロンプトで質問する前に、
ソースコード全体をローカルにバックアップしています。
./history/ の下に
./hisrory/r0001/
./hisrory/r0002/ ...
このような構造のディレクトリを作成し、開発ソースをバックアップするスクリプトを実行しています。

Windowsの開発環境なので ps1 ファイルです。

# backup.ps1  
$base = "./src"  
$history = "./history"  
  
# 最新の rXXXX フォルダを探す  
$latest = Get-ChildItem -Path $history -Directory | Where-Object { $_.Name -match '^r\d{4}$' } | Sort-Object Name -Descending | Select-Object -First 1  
if ($latest) {  
    $num = [int]($latest.Name.Substring(1)) + 1  
} else {  
    $num = 1  
}  
$next = "r{0:D4}" -f $num  
$dest = "$history/$next"  
  
# バックアップフォルダ作成  
New-Item -ItemType Directory -Path "$dest" -Force | Out-Null  
New-Item -ItemType Directory -Path "$dest/css" -Force | Out-Null  
New-Item -ItemType Directory -Path "$dest/js" -Force | Out-Null  
New-Item -ItemType Directory -Path "$dest/html" -Force | Out-Null  
New-Item -ItemType Directory -Path "$dest/images" -Force | Out-Null  
New-Item -ItemType Directory -Path "$dest/doc" -Force | Out-Null  
New-Item -ItemType Directory -Path "$dest/server" -Force | Out-Null  
  
# ファイル/フォルダをコピー  
Copy-Item "$base/SPA_index.html" "$dest/SPA_index.html"  
Copy-Item "$base/css/*" "$dest/css/" -Recurse  
Copy-Item "$base/js/*" "$dest/js/" -Recurse  
Copy-Item "$base/images/*" "$dest/images/" -Recurse  
Copy-Item "$base/doc/*" "$dest/doc/" -Recurse  
  
# サーバーファイルをコピー: node_modules は除外  
Copy-Item "$base/server/*" "$dest/server/" -Recurse -Exclude "node_modules"  
  
Write-Host "バックアップ完了: $dest"

spilist2 2025-06-23

Gitを使うことと、この方法にはどのような長所と短所がありますか？

baeba 2025-06-24

Gitも同時に使っています..
実際に開発するとき、AIがソースコードを大きく変更することがあるので..
これを一つひとつ丁寧にチェックしても、ビルドしたときにエラーやバグが発生することがある
ため..

以前のコードにロールバックするときに便利です。

Gitでコードをロールバックすることもできますが..
コード全体がまるごとバックアップされているので
素早く見つけて、どこが変更されたかを見ながら実装するのに役立ちました。

turastory 2025-06-25

git subtree を活用するとよさそうですね。

lux1024 2025-06-25

git worktree?

turastory 2025-06-26

あ、名前を勘違いしていましたね（笑）worktree が正しいです

spilist2 2025-06-24

ご回答ありがとうございます！

joyoo 2025-06-24

何の利点もありません……そうした行為をしないために生まれたのがバージョン管理システムです。
私が見る限りでは、gitをもっと勉強されたほうがよさそうです。

nakyup 2025-06-23

context7 というMCPが便利なので、ライブラリの使い方を尋ねるときによく使っています。

spilist2 2025-06-23

あ、これを紹介し忘れていたのを思い出して講義資料は更新していたのですが、ブログの更新はしていませんでした。おかげで追記できました。ありがとうございます。

aqqnucs 2025-06-23

ヒント 2 質問。ask モードでも、修正しないようにと伝えなければ修正を試みますか？

spilist2 2025-06-23

はい、修正を試みているうちにタイムアウトして edit_files が使えなくなり、「あれ？」と思いながら別の作業をすることがあります。

kissdesty 2025-06-23

実際に修正を行わない場合でも、Askモードでも修正直前までの不要な予備動作を減らしてくれる、という意味のようです。

Cursorをもっと賢く使いたい人のための12のヒント

ヒント 1. 戦略的にモデルを選択しよう

ヒント 2. 複雑なアプリを修正するときは、まずAskモードで計画を立てよう

ヒント 3. デバッグではすぐにファイルを修正させず、テストと一緒に原因を把握しよう

ヒント 4. Cursorにルールを自分で管理させて、少しずつ賢くしていこう

ヒント 5. 複数タブとAuto系オプションで生産性を高めよう

ヒント 6. 1つのチャットセッションを長く続けすぎないようにしよう

ヒント 7. 意味のある変更が完了したら、必ずコミットしよう

ヒント 8. Cursorにコード構造を伝え、ファイルの長さとファイル名を調整しよう

ヒント 9. ファイルが長くなったら、Cursorにモジュール化させよう

ヒント 10. @を使って積極的にコンテキストを注入しよう

ヒント 11. セキュリティが重要ならPrivacyモードを有効にしよう

ヒント 12. 開発を快適かつ正確にするMCPとツールを使おう

そのほかの細かなヒント

関連記事

22件のコメント