Cursor IDE .cursorrules パターン集【2026年4月最新】プロジェクト固有ルールで開発効率を最大化
Cursor IDE の .cursorrules を使ったプロジェクト固有ルール設定の実践ガイド。Next.js・Astro・Laravel など実務で使えるルールパターン集と、チーム開発での運用ノウハウを解説
Cursor IDE で AI の提案精度を劇的に改善したいなら、プロジェクトルートに .cursorrules ファイルを配置するだけで実現できます。
2026年4月現在、Cursor IDE は .cursorrules ファイルによる プロジェクト固有のルール定義機能 を正式にサポートしており、フレームワークの命名規則・コーディングスタイル・禁止パターンなどを AI に学習させることができます。
この記事では、実務で即使える .cursorrules のパターン集と、チーム開発での運用ノウハウを解説します。
.cursorrules とは？ — Cursor に「このプロジェクトの流儀」を教える設定ファイル
.cursorrules は、プロジェクトルートに配置するプレーンテキストファイルで、Cursor の AI エージェント（Composer・Chat・Tab補完すべて）が参照するルール定義です。
基本的な仕組み
flowchart LR
A["開発者がコード入力"] --> B["Cursor がコンテキスト収集"]
B --> C[".cursorrules を読み込み"]
C --> D["プロジェクト固有ルールを適用"]
D --> E["AI が提案生成"]
E --> F["ルールに沿った正確な補完"]従来の設定方法との違い
| 方法 | スコープ | 共有方法 | 更新頻度 |
|---|---|---|---|
| ユーザー設定（Settings） | 全プロジェクト共通 | 各自で設定 | 固定的 |
| .cursorrules | プロジェクト固有 | Git で共有 | プロジェクト進化に応じて更新 |
重要: .cursorrules はプロジェクトルート 1箇所のみ に配置します。サブディレクトリの .cursorrules は読み込まれません。
実務で使える .cursorrules パターン集
パターン1: Next.js App Router プロジェクト
Next.js 15 の App Router を使ったプロジェクトでの典型的なルール設定です。
# Next.js App Router プロジェクトルール
## ファイル構成
- app/ 配下に Server Components を配置
- "use client" は必要最小限のコンポーネントのみに付与
- Server Actions は app/actions/ に集約
## コーディング規則
- TypeScript strict モードを厳守
- props の型定義は interface ではなく type で記述
- async/await は try-catch で囲む
- 環境変数は NEXT_PUBLIC_ プレフィックス以外クライアントで使用禁止
## 禁止パターン
- useEffect 内での直接的な fetch（Server Components または Server Actions を使用）
- getServerSideProps / getStaticProps（App Router では使用不可）
- pages/ ディレクトリの作成（App Router に統一）
## 推奨パターン
- データフェッチは Server Components で直接実行
- クライアント状態管理は Zustand を使用
- フォーム送信は Server Actions + useFormStateこのルールを適用すると、Cursor は次のような提案を自動的に避けるようになります:
- ❌
useEffect+fetchの組み合わせ - ❌
getServerSidePropsの使用 - ✅ Server Components での直接データフェッチ
- ✅
"use server"ディレクティブを含む Server Actions
パターン2: Astro + TypeScript プロジェクト
Astro の アイランドアーキテクチャ を適切に活用するためのルール設定です。
# Astro プロジェクトルール
## ファイル構成
- .astro ファイルは src/pages/ と src/components/ のみに配置
- React コンポーネントは src/components/react/ に配置
- レイアウトは src/layouts/ に配置
## パフォーマンス最適化
- インタラクティブな要素以外は .astro で記述
- client:load は必須の場合のみ使用（優先順位: client:visible > client:idle > client:load）
- 画像は必ず <Image /> コンポーネントを使用（<img> タグ禁止）
## TypeScript
- Props は Astro.props で受け取る
- 型定義は interface Props = { ... } 形式で記述
## 禁止パターン
- useState などの React Hooks を .astro ファイルで直接使用
- client:load の濫用（ページ全体が重くなる原因）効果: このルールにより、Cursor は <img> タグを提案せず、常に <Image /> コンポーネントを使うようになります。
パターン3: Laravel API プロジェクト
Laravel でのバックエンド API 開発における規約を定義した例です。
# Laravel API プロジェクトルール
## ファイル構成
- Controller は app/Http/Controllers/Api/ 配下に配置
- Request Validation は FormRequest クラスに分離
- ビジネスロジックは Service クラス（app/Services/）に記述
## API レスポンス
- 成功: { "data": {...}, "message": "..." }
- エラー: { "error": { "code": "...", "message": "..." } }
- HTTP ステータスコードを適切に設定（200, 201, 400, 401, 404, 500）
## セキュリティ
- 全エンドポイントに認証ミドルウェア適用（auth:sanctum）
- マスアサインメント脆弱性防止のため $fillable を明示
- SQL インジェクション防止のため必ず Eloquent または Query Builder 使用
## 禁止パターン
- Controller にビジネスロジック直書き
- DB::raw() での生SQLの直接実行（Query Builder を使用）
- 認証なしのエンドポイント作成このルールを設定すると、Cursor は Controller に長大なロジックを書こうとせず、Service クラスへの分離を提案するようになります。
パターン4: Python FastAPI プロジェクト
FastAPI での非同期API開発における規約です。
# FastAPI プロジェクトルール
## ファイル構成
- routers/ 配下にエンドポイント定義
- schemas/ に Pydantic モデル定義
- services/ にビジネスロジック
- models/ に SQLAlchemy モデル
## コーディング規則
- 全関数に型ヒント必須
- async/await を積極的に使用
- Pydantic モデルで入出力を厳密に型定義
- 環境変数は pydantic-settings で管理
## 禁止パターン
- 同期処理の DB アクセス（非同期ドライバ使用必須）
- dict 型での API レスポンス（Pydantic モデル使用）
- グローバル変数の使用.cursorrules の運用ノウハウ
チーム開発での共有方法
.cursorrules は Git で管理し、チーム全体で共有 するのがベストプラクティスです。
# .gitignore に .cursorrules を含めない
# （デフォルトで追跡される）
# プロジェクトのクローン後、自動的に適用される
git clone <repository-url>
cd project
# Cursor を開くと .cursorrules が自動認識されるブランチ戦略との統合:
sequenceDiagram
participant Dev as 開発者
participant Git as Git リポジトリ
participant Cursor as Cursor IDE
Dev->>Git: feature ブランチ作成
Dev->>Dev: .cursorrules に新ルール追加
Dev->>Cursor: コード編集
Cursor->>Cursor: 更新されたルールを適用
Dev->>Git: PR 作成（.cursorrules 含む）
Git->>Dev: レビュー・マージ
Dev->>Git: main ブランチに反映ルールの優先順位設計
複数のルールが競合する場合、明示的に優先順位を記述します。
# ルール優先順位
## 最優先: セキュリティ
- 認証・認可の実装は必須
- 機密情報のログ出力禁止
## 次点: パフォーマンス
- N+1 クエリ禁止
- 画像最適化必須
## 通常: コーディング規約
- Prettier / ESLint に従う段階的な導入戦略
既存プロジェクトに .cursorrules を導入する際の推奨手順:
- Phase 1: 基本的な禁止パターンのみ記述（破壊的変更を避ける）
- Phase 2: 推奨パターンを追加（新規コードから適用）
- Phase 3: 既存コードのリファクタリング方針を追加
# Phase 1: 禁止パターン（即適用）
- var 宣言禁止（const / let 使用）
- console.log 禁止（logger 使用）
# Phase 2: 推奨パターン（新規コードのみ）
- 関数は named export で定義
- Props は分割代入で受け取る
# Phase 3: リファクタリング方針（段階的移行）
- Class Component を Function Component に移行
- Redux を Zustand に移行.cursorrules のトラブルシューティング
ルールが適用されない場合
確認ポイント:
- ファイル名が
.cursorrulesか（スペルミス確認） - プロジェクトルートに配置されているか
- Cursor のリロード（Cmd+Shift+P → “Reload Window”）
ルールの記述形式
.cursorrules は プレーンテキスト であり、特定の構文はありません。ただし、以下の形式が読みやすく推奨されます:
# 大見出し（## ではなく # を使用）
## 中見出し
- 箇条書きでルールを記述
- 具体例を併記すると AI の理解精度が上がる
禁止: ❌ を使った明示
推奨: ✅ を使った明示ルールの検証方法
ルールが正しく適用されているか確認する方法:
flowchart TD
A["Cursor Chat を開く"] --> B["「このプロジェクトのルールを教えて」と質問"]
B --> C["AI が .cursorrules の内容を要約"]
C --> D["期待通りのルールが認識されているか確認"]実際に試してみると、Cursor は次のように応答します:
「このプロジェクトでは Next.js App Router を使用しており、Server Components を優先し、useEffect での fetch は禁止されています。」
まとめ
.cursorrules を活用することで、Cursor IDE の提案精度を プロジェクト固有の要件に最適化 できます。
重要なポイント:
.cursorrulesはプロジェクトルート1箇所に配置- Git で共有し、チーム全体で同じルールを適用
- 禁止パターン・推奨パターン・優先順位を明示的に記述
- フレームワーク固有の規約（Next.js, Astro, Laravel など）を定義
- 段階的に導入し、既存コードへの影響を最小化
2026年4月時点で .cursorrules は Cursor の標準機能として安定しており、大規模プロジェクトでの採用事例も増えています。特にチーム開発では、コードレビューの負担軽減と品質の均質化に大きく貢献します。