Cursor エディタ 設定ガイド for 日本人エンジニア

2025年5月10日

Cursorエディタとは

CursorはAIアシスタントを搭載したコードエディタで、開発効率化を目的として設計されています。

VS Codeをベースにしており、直感的なインターフェースと高度なAI機能を統合しているのが特徴です。

特に、以下の機能が強力です:

  • コード補完
  • デバッグサポート
  • リファクタリング
  • テストコード生成

ルール設定の重要性

Cursorでは「Rules」を設定することで、AIがどのようにコードを生成し、提案し、補完するかを指示できます。

適切なルールを設定することで得られるメリット 👇
  • コード品質の向上: 好みのコーディング規約やベストプラクティスに従ったコードが生成される
  • 開発効率のアップ: 定型的なコードパターンの入力が減少し、AIがより多くの作業をサポート
  • コードの一貫性強化: チームプロジェクトでのコードスタイルの統一が容易になる
  • AIの動作のカスタマイズ: プロジェクトの要件や個人の好みに合わせたAIの動作が可能

User RulesとProject Rulesの違い

Cursorには2種類のルール設定方法があります:

User Rules 📝

  • 適用範囲: すべてのプロジェクトに適用されるグローバルルール
  • 設定方法: Cursor Settings > Rules > User Rules
  • 特徴: 一度設定すれば、すべてのプロジェクトで有効
  • 優先順位: Project Rulesより優先される

Project Rules 📌

  • 適用範囲: 特定のプロジェクトのみに適用されるローカルルール
  • 設定方法: Cursor Settings > Rules > Project Rules または .cursor/rules/ ディレクトリに .mdc ファイルを作成
  • 特徴: プロジェクト固有の要件やコーディング規約を定義できる
  • 注意点: 複数プロジェクトを同時に開いている場合、最初のプロジェクトのルールのみが適用される

20代日本人エンジニア向け推奨設定

以下は、20代の日本人エンジニアがCursorを使う際におすすめの基本的なUser Rules設定です:

# 基本設定 - 日本語での応答を優先する - コードには適切なコメントを日本語で付ける - エラーメッセージの解説は詳細に行う - コーディング規約に従ったコード生成を行う # コード品質 - DRY (Don't Repeat Yourself) 原則に従う - KISS (Keep It Simple, Stupid) 原則を守る - 変数名やメソッド名は日本語の意味を英語に適切に翻訳して命名する - コメントは機能説明に重点を置き、冗長にしない # 開発効率 - 実装前に設計の概要を示す - テストコードも一緒に提案する - エラー発生時は具体的な解決策を複数提示する - リファクタリングの際は変更理由と改善点を明示する # 学習サポート - 使用している技術やライブラリの最新ベストプラクティスを提案する - コード生成時には実装の解説も行う - より効率的な実装方法がある場合は代替案も提示する - 新しい技術やパターンを使う際は簡潔な説明を加える # プロジェクト管理 - コミットメッセージの提案はプロジェクト規約に沿った形式で行う - PRの説明文も自動生成できるようにする - 実装に時間がかかりそうな箇所は事前に指摘する # 常に最後に日本語で応答すること

技術スタック別設定例

🐍 Python開発者向け

## Python Guidelines - Follow PEP 8 style guidelines - Use type hints for function parameters and return values - Prefer list/dict comprehensions over loops when appropriate - Document functions with docstrings using Google or NumPy style - Use meaningful exception handling with specific exception types - Structure projects with clear module organization

⚛️ TypeScript/Next.js開発者向け

## TypeScript/Next.js Guidelines - Use Next.js 14.2.23 with App Router architecture - Organize code by features or domains rather than by file types - Leverage TypeScript's type system fully - avoid using 'any' type - Follow the official Next.js patterns for data fetching and routing ### Component Structure - Use functional components with hooks - Separate UI components from logic/data-fetching components - Create reusable components in a shared component library - Follow component naming convention: `ComponentName/index.tsx` with optional `ComponentName/ComponentName.module.css` ### Styling - Use Tailwind CSS for styling following utility-first approach - Group Tailwind classes logically: layout, sizing, typography, colors - IMPORTANT: Avoid using Grid components directly - use Box components instead for layouts - For complex UI components, use either MUI or Headless UI (prefer Headless UI for better UX) ### Form Handling - Use React Hook Form for all form implementations - Implement validation schemas with Zod - Structure form validations consistently - Handle form errors with clear user feedback ### State Management - Use Zustand for global state management - Keep state minimal and focused - Split stores by domain when appropriate - Use React Query for server state management

実際に私が使っているルール

Cursorには基本的に英文で指示を出すことを推奨します。ただし、英語で記述しても回答を日本語に指定することができます。

以下は英語版のルール設定例です。AI モデルには英語版の方がより正確に指示が伝わる可能性が高いです。

# Python & TypeScript スタック向け Cursor Rules (英語版) ## General Coding Guidelines - Follow clean code principles across all languages - Use descriptive variable names that explain their purpose - Comment complex logic or business rules - Follow DRY (Don't Repeat Yourself) principles - Write unit tests for all core functionality ## Python Guidelines - Follow PEP 8 style guidelines - Use type hints for function parameters and return values - Prefer list/dict comprehensions over loops when appropriate - Document functions with docstrings using Google or NumPy style - Use meaningful exception handling with specific exception types - Structure projects with clear module organization ## TypeScript/Next.js Guidelines - Use Next.js 14.2.23 with App Router architecture - Organize code by features or domains rather than by file types - Leverage TypeScript's type system fully - avoid using 'any' type - Follow the official Next.js patterns for data fetching and routing ### Component Structure - Use functional components with hooks - Separate UI components from logic/data-fetching components - Create reusable components in a shared component library - Follow component naming convention: `ComponentName/index.tsx` with optional `ComponentName/ComponentName.module.css` ### Styling - Use Tailwind CSS for styling following utility-first approach - Group Tailwind classes logically: layout, sizing, typography, colors - IMPORTANT: Avoid using Grid components directly - use Box components instead for layouts - For complex UI components, use either MUI or Headless UI (prefer Headless UI for better UX) ### Form Handling - Use React Hook Form for all form implementations - Implement validation schemas with Zod - Structure form validations consistently - Handle form errors with clear user feedback ### State Management - Use Zustand for global state management - Keep state minimal and focused - Split stores by domain when appropriate - Use React Query for server state management ### Performance Considerations - Implement proper code-splitting with Next.js - Use Next.js Image component for optimized images - Properly memoize components and callbacks where appropriate - Implement proper loading states and error boundaries ## Response Preferences - Provide detailed explanations for any implementation decisions - When suggesting improvements, explain the reasoning - Always include code examples when explaining concepts - Respond in Japanese with UTF-8 encoding

以下は上記の英語版を日本語版に変換したものです。日本人が内容を理解しやすくなっています。

# Python & TypeScript スタック向け Cursor Rules (日本語版) ## 一般的なコーディングガイドライン - すべての言語でクリーンコードの原則に従う - 変数名は目的を説明する説明的な名前を使用する - 複雑なロジックやビジネスルールにはコメントを付ける - DRY(同じことを繰り返さない)原則に従う - すべての主要機能に単体テストを書く ## Pythonガイドライン - PEP 8スタイルガイドラインに従う - 関数のパラメータと戻り値に型ヒントを使用する - 適切な場合はループよりリスト/辞書内包表記を優先する - GoogleまたはNumPyスタイルを使用して関数をdocstringsでドキュメント化する - 特定の例外タイプを使用した意味のある例外処理を実装する - 明確なモジュール構成でプロジェクトを構造化する ## TypeScript/Next.jsガイドライン - Next.js 14.2.23(App Router)アーキテクチャを使用する - ファイルタイプではなく、機能やドメインでコードを整理する - TypeScriptの型システムを最大限に活用し、'any'型の使用を避ける - データフェッチングとルーティングには公式のNext.jsパターンに従う ### コンポーネント構造 - フック付きの関数コンポーネントを使用する - UIコンポーネントとロジック/データフェッチングコンポーネントを分離する - 共有コンポーネントライブラリで再利用可能なコンポーネントを作成する - コンポーネント命名規則に従う:`ComponentName/index.tsx`(オプションで`ComponentName/ComponentName.module.css`) ### スタイリング - ユーティリティファーストアプローチでTailwind CSSを使用する - Tailwindクラスを論理的にグループ化:レイアウト、サイズ調整、タイポグラフィ、色 - 重要:Gridコンポーネントを直接使用せず、代わりにレイアウトにはBoxコンポーネントを使用する - 複雑なUIコンポーネントには、MUIまたはHeadless UI(より良いUXにはHeadless UIを推奨)を使用する ### フォーム処理 - すべてのフォーム実装にはReact Hook Formを使用する - Zodでバリデーションスキーマを実装する - フォームバリデーションを一貫した構造で実装する - 明確なユーザーフィードバックでフォームエラーを処理する ### 状態管理 - グローバル状態管理にはZustandを使用する - 状態は最小限かつ焦点を絞ったものにする - 適切な場合はドメインごとにストアを分割する - サーバー状態管理にはReact Queryを使用する ### パフォーマンスの考慮事項 - Next.jsで適切なコード分割を実装する - 最適化された画像にはNext.js Imageコンポーネントを使用する - 適切な場所でコンポーネントとコールバックをメモ化する - 適切なローディング状態とエラー境界を実装する ## 応答の設定 - 実装の決定に関する詳細な説明を提供する - 改善案を提案する際は、理由を説明する - 概念を説明する際は常にコード例を含める - 日本語(UTF-8エンコーディング)で応答する

実用的なTips

  1. シンボル機能を活用する:

    @Files & Folders@Docs@Git@Cursor Rules などのシンボルを使って、効率的にコンテキストを提供できます。

  2. YOLOモードの活用:

    単純な作業の自動化には「YOLOモード」を活用すると効率的です。ただし、重要なコード変更時は使用を控えましょう。

  3. モデル選択の最適化:

    Claude-3.5-SonnetやClaude-3.7などの高性能モデルを優先的に使用すると、より質の高い応答が得られます。

  4. コマンドキーの活用:
    • ⌘K: コード選択時にインラインで質問
    • ⌘ + .: チャットモード切り替え
  5. ドキュメントの読み込み:

    最新のライブラリやフレームワークのドキュメントは、Cursor Settings > Features > Docs から読み込ませることで、最新情報に基づいた支援を受けられます。

よくある質問

Q: Cursor Rulesが効かない場合はどうすればいいですか?

A: まず、User RulesやProject Rulesが正しく設定されているか確認し、Cursorを再起動してください。それでも解決しない場合は、ルールの構文が正しいか、競合するルールがないかを確認してみてください。

Q: User Rulesを更新するにはどうすればいいですか?

A: Cursor Settings > Rules > User Rulesからルールを直接修正し、保存するだけです。

Q: 日本語化はどのように行いますか?

A: コマンドパレット(F1キー)を開き、「Configure Display Language」を選択し、日本語を選択します。Cursorを再起動すると反映されます。

Q: 複数のプロジェクトで異なるルールを適用するにはどうすればいいですか?

A: 各プロジェクトを個別のウィンドウで開くか、異なるワークスペースに配置することで、それぞれのProject Rulesが適切に適用されます。