Cursorのカスタムルール（.cursorrules）で開発スタイルを統一する
AIコードエディタ「Cursor」を使い始めたとき、こんな悩みを抱えたことはないでしょうか。
「AIが提案するコードは便利だけど、うちのプロジェクトのコーディング規約と合わない」「チームメンバーによってAIへの指示がバラバラで、生成されるコードのスタイルが統一されない」「毎回同じような注意事項をプロンプトに書くのが面倒くさい」
これらの問題をまとめて解決できるのが、Cursorのカスタムルール機能です。プロジェクトのルートに .cursorrules ファイル（または新しい形式の cursor/rules ディレクトリ）を置くだけで、AIアシスタントがプロジェクト固有のルールや文脈を自動的に理解した上でコードを提案してくれるようになります。
この記事では、カスタムルールの仕組みから具体的な設定方法、実際のプロジェクトで役立つ設定例まで、実践的な観点で徹底解説します。
カスタムルールとは何か？なぜ必要なのか
Cursorにおけるルールの役割
CursorはAIとの対話によってコードを生成・編集しますが、デフォルトではAIは「一般的なベストプラクティス」に基づいた提案しか行えません。あなたのプロジェクトが
- TypeScriptで書かれているのかJavaScriptなのか
- どのUIライブラリを使っているのか
- インデントはスペース2つなのか4つなのか
- エラーハンドリングの方針はどうなっているのか
といった情報を、AIは事前に知ることができないのです。
カスタムルールを設定することで、こうした「プロジェクト固有の文脈」をAIに事前に伝えられます。結果として、AIが提案するコードがそのままプロジェクトに馴染みやすくなり、修正の手間が大幅に減ります。
.cursorrulesとProject Rulesの違い
Cursorのバージョンアップに伴い、ルールの設定方法が2種類になっています。
| 方式 | ファイルパス | 特徴 |
|---|---|---|
| 旧形式 | .cursorrules（プロジェクトルート） |
シンプルな単一ファイル。後方互換性あり |
| 新形式 | .cursor/rules/*.mdc |
複数ファイルに分割可能。ファイルパターンで適用範囲を制御できる |
2025年以降にCursorを新規インストールした場合、新形式の「Project Rules」が推奨されています。ただし、.cursorrules も引き続き動作するため、既存プロジェクトでそのまま使うことも問題ありません。
公式ドキュメントでは以下のように説明されています。
Project Rules allow you to provide instructions and context to the AI that are specific to your project. They are stored in
.cursor/rulesand can be version controlled.
.cursorrulesファイルの基本的な書き方
ファイルの作成と配置
まずはシンプルな .cursorrules ファイルから始めましょう。プロジェクトのルートディレクトリに作成します。
# プロジェクトルートで実行
touch .cursorrules
ファイルの中身はプレーンテキストまたはMarkdown形式で記述します。AIへの自然言語での指示をそのまま書けばOKです。
基本テンプレート
以下はTypeScript + Reactプロジェクト向けの基本テンプレートです。
# プロジェクト概要
このプロジェクトはNext.js 14 + TypeScript + Tailwind CSSで構築されたECサイトです。
## 技術スタック
- フレームワーク: Next.js 14 (App Router)
- 言語: TypeScript 5.x（strict モード有効）
- スタイリング: Tailwind CSS v3
- 状態管理: Zustand
- APIクライアント: TanStack Query v5
- テスト: Vitest + Testing Library
## コーディング規約
### 全般
- インデントはスペース2つを使用すること
- セミコロンは省略しないこと
- シングルクォートを使用すること（JSXの属性は除く）
- ファイル末尾には必ず改行を入れること
### TypeScript
- `any` 型の使用は禁止。不明な型は `unknown` を使うこと
- 型定義は `interface` より `type` を優先すること
- 非null アサーション演算子（`!`）は避け、適切な null チェックを行うこと
- ジェネリクスを活用して型安全性を高めること
### Reactコンポーネント
- コンポーネントは関数コンポーネントで書くこと（クラスコンポーネント禁止）
- propsの型定義は必ず行い、ファイル冒頭に `Props` という名前で定義すること
- デフォルトエクスポートは使わず、名前付きエクスポートを使うこと
- `useEffect` の依存配列は省略しないこと
### ファイル命名
- コンポーネントファイル: PascalCase（例: `UserProfile.tsx`）
- ユーティリティ関数: camelCase（例: `formatDate.ts`）
- テストファイル: `*.test.ts` または `*.test.tsx`
## ディレクトリ構成
src/ app/ # Next.js App Router のページ components/ # 再利用可能なコンポーネント hooks/ # カスタムフック lib/ # ユーティリティ関数 stores/ # Zustand ストア types/ # 型定義ファイル
## 注意事項
- `console.log` はデバッグ用途のみ。本番コードには残さないこと
- 日本語のコメントを積極的に使用すること
- エラーハンドリングは必ず行い、ユーザーに適切なフィードバックを返すこと
このように書くことで、AIはコードを提案する際に常にこのルールを参照した上でコードを生成してくれます。
新形式のProject Rules（.cursor/rules）の活用
ファイルパターンによる適用制御
新形式のProject Rulesでは、特定のファイルやディレクトリにのみルールを適用できます。これにより、フロントエンドとバックエンドで異なるルールを設定したり、テストファイルだけに特別な指示を出したりすることが可能です。
# ディレクトリ構成
.cursor/
rules/
general.mdc # 全体共通ルール
frontend.mdc # フロントエンド向けルール
backend.mdc # バックエンド向けルール
testing.mdc # テストファイル向けルール
.mdcファイルの書き方
.mdc ファイルはMarkdown形式で、ファイル冒頭にフロントマターでメタ情報を記述します。
---
description: フロントエンドコンポーネントの開発ルール
globs:
- "src/components/**/*.tsx"
- "src/app/**/*.tsx"
alwaysApply: false
---
# フロントエンドコンポーネントのルール
## コンポーネント設計方針
- Atomic Designの原則に従い、atoms/molecules/organisms/templatesに分類すること
- 1コンポーネント1ファイルを原則とすること
- ロジックとUIの分離を徹底し、カスタムフックに切り出すこと
## Tailwind CSSの使い方
- インラインスタイルは使用しないこと
- クラス名の順序は tailwind-sort に従うこと
- レスポンシブデザインはモバイルファーストで記述すること（sm: md: lg: の順）
- カラーパレットはデザインシステムで定義した変数のみ使用すること
## パフォーマンス最適化
- 画像には必ず `next/image` を使用すること
- 重いコンポーネントには `React.lazy` と `Suspense` を活用すること
- 不要な再レンダリングを防ぐため `useMemo` / `useCallback` を適切に使うこと
---
description: テストファイルの記述ルール
globs:
- "**/*.test.ts"
- "**/*.test.tsx"
- "**/*.spec.ts"
alwaysApply: false
---
# テストコードのルール
## テスト構成
- describe ブロックでテスト対象のコンポーネント/関数名を明記すること
- テストケース名（it/test）は「〜すべきである」「〜の場合は〜を返す」という形式で書くこと
- AAA（Arrange-Act-Assert）パターンを守ること
## テスト方針
- 実装の詳細ではなくユーザーの振る舞いをテストすること
- モックは最小限にとどめること
- テストカバレッジは80%以上を目標とすること
- スナップショットテストは原則使用しないこと
## Testing Library のベストプラクティス
- 要素の取得には `getByRole` を優先すること
- `getByTestId` は最後の手段とすること
- 非同期処理のテストには `waitFor` を使うこと
globs にファイルパターンを指定することで、そのパターンにマッチするファイルを編集するときだけ、そのルールが自動的に適用されます。
実際のプロジェクトで使える設定例
Python + FastAPIプロジェクト向け
Pythonプロジェクトでの設定例も見てみましょう。
# Python + FastAPI プロジェクトルール
## 技術スタック
- Python 3.12+
- FastAPI 0.110+
- SQLAlchemy 2.0（非同期モード）
- Pydantic v2
- pytest + pytest-asyncio
## コーディング規約
### Python スタイル
- PEP 8に準拠すること
- 型ヒントは必ず付けること（Python 3.10+ の Union 記法を使う: `str | None`）
- docstring は Google スタイルで書くこと
- f-string を優先すること（% や .format() は使わない）
- 1行の最大文字数は88文字（blackのデフォルト）
### FastAPI 固有のルール
- ルーターは機能単位でファイルを分割すること（routers/ ディレクトリ）
- レスポンスモデルは必ず指定すること
- 依存性注入（Depends）を積極的に活用すること
- HTTPステータスコードは明示的に指定すること
- エンドポイントの命名はREST規約に従うこと
### データベース
- SQLAlchemy の非同期セッションを使用すること
- マイグレーションは Alembic で管理すること
- N+1問題に注意し、必要に応じて `selectinload` / `joinedload` を使うこと
### セキュリティ
- パスワードは bcrypt でハッシュ化すること
- JWTトークンの有効期限は必ず設定すること
- SQLインジェクション対策のため生クエリは使わないこと
- 環境変数は pydantic-settings で管理すること
## ディレクトリ構成
app/ api/ # APIエンドポイント core/ # 設定・セキュリティ関連 models/ # SQLAlchemy モデル schemas/ # Pydantic スキーマ services/ # ビジネスロジック repositories/ # データアクセス層 tests/
## コードレビューポイント
- 例外は具体的な例外クラスを使うこと（Exception の直接 catch は禁止）
- ロギングには `logging` モジュールを使い、print は使わないこと
- 設定値はハードコードしないこと
チーム開発での活用ポイント
.cursorrules や .cursor/rules/ はプロジェクトのリポジトリに含めてバージョン管理することを強く推奨します。これにより
- チーム全員が同じルールを共有できる
- ルールの変更履歴をGitで追跡できる
- 新メンバーがジョインしたときも自動的に同じ設定が適用される
という大きなメリットが生まれます。.gitignore には追加せず、リポジトリに含めましょう。
User Rules：グローバルな個人設定
Project Rulesがプロジェクト単位のルールであるのに対し、User Rules はCursor全体に適用される個人用のグローバルルールです。
設定方法
Cursorのメニューから設定を開きます。
Cursor→Settings→Cursor Settingsを開く- 左側のメニューから
Rulesを選択 - 「User Rules」のテキストエリアにルールを入力
User Rulesの活用例
## 私の個人的な設定
### コミュニケーション
- 回答は日本語で行うこと
- 専門用語には必要に応じて説明を付けること
- コードの変更点は箇条書きで説明すること
### コード生成スタイル
- 説明なしにコードだけ出力するのではなく、何をしているかを簡潔に説明すること
- 重要な部分にはコメントを付けること
- 複数の解決策がある場合は選択肢を提示し、トレードオフを説明すること
### セキュリティへの配慮
- APIキーや認証情報をコードに直接書かないこと
- 環境変数を使用する際は .env.example も提示すること
User Rulesは個人の好みや作業スタイルに合わせた設定を書く場所です。Project Rulesと組み合わせることで、「プロジェクトのルール」と「個人の作業スタイル」の両方をAIに伝えられます。
よくある失敗パターンと解決策
ルールが長すぎてAIが読み飛ばす
.cursorrules に大量のルールを詰め込みすぎると、AIがすべてを参照しきれずに一部を無視することがあります。
解決策:
- 新形式の
.cursor/rules/を使ってファイルを分割する - 最も重要なルールを冒頭に配置する
- 箇条書きを活用して簡潔に書く
- 「〜しないこと」という禁止事項は特に明確に書く
矛盾するルールを書いてしまう
User RulesとProject Rulesが矛盾していたり、同じProject Rules内で矛盾が生じていたりすると、AIが混乱して一貫性のないコードを生成します。
解決策:
- ルールを更新したら全体を通して確認する
- 矛盾が生じやすいテーマ（インデント、クォート、セミコロン等）は1箇所にまとめる
- ESLintやPrettierの設定ファイル（
.eslintrc、.prettierrc）と矛盾しないようにする
ルールの効果が出ているか確認する方法
ルールが正しく読み込まれているかを確認するには、Cursorのチャット画面で直接聞いてみるのが一番確実です。
あなたが現在認識しているプロジェクトのルールを要約して教えてください。
このように質問すると、AIが現在認識しているルールの内容を返してくれます。期待通りのルールが返ってこない場合は、ルールファイルの記述を見直しましょう。
実践：既存プロジェクトにルールを導入するステップ
すでに開発中のプロジェクトにカスタムルールを導入する場合の手順をまとめます。
Step 1: 現状のコーディングスタイルを整理する
まず、既存のコードベースを見ながら「暗黙のルール」を明文化します。ESLintやPrettierの設定があれば、それを参考にしてルールをまとめましょう。
Step 2: 最小限のルールから始める
最初から完璧を目指さず、「これだけは絶対に守ってほしい」というルールを5〜10個程度に絞って書き始めます。
Step 3: 効果を確認しながら育てる
実際にCursorを使って開発を進める中で、AIが意図しないコードを生成した場面があれば、その都度ルールを追加・修正していきます。ルールファイルはドキュメントと同じように「生きたファイル」として育てることが大切です。
Step 4: チームでレビューする
ルールファイルへの変更は、通常のコードと同じようにPull Requestでレビューするプロセスを設けると、チーム全員がルールを把握しやすくなります。
まとめ：カスタムルールでAIとの協働をレベルアップ
Cursorのカスタムルール機能を活用することで、以下のメリットが得られます。
- 毎回同じ指示をプロンプトに書く手間が省ける
- チームメンバー間でAIの出力スタイルが統一される
- プロジェクト固有の制約をAIが自然に守るようになる
- コードレビューでのスタイル指摘が減り、本質的なレビューに集中できる
最初は小さなルールファイルから始めて、プロジェクトの成長とともに育てていくアプローチが長続きのコツです。.cursorrules はプロジェクトのリポジトリに含めてチームで共有し、「AIとの協働ルールブック」として活用してみてください。
カスタムルールをうまく整備したチームは、AIとの対話の質が上がり、コード生成→レビュー→マージのサイクルが格段にスムーズになります。ぜひ今日から設定してみましょう。
