.cursorrules 完全設定ガイド：ゼロからプロまで

.cursorrules は、プロジェクトのルートに配置するだけで Cursor の AI に「どう振る舞うか」を指示できるプレーンテキストファイルです。コーディングスタイル、使用フレームワーク、避けるべきパターンなどを定義できます。プロジェクト固有のシステムプロンプトとして、すべての AI インタラクションに自動で注入されると考えてください。

Cursor Forum を少し覗けば、毎週のように同じ質問が出ているのが見えます：「.cursorrules を正しく設定するにはどうすればいい？」 公式ドキュメントでは基礎は網羅されていますが、実際に日々使ってみないとわからない細かいニュアンスがたくさんあります。このガイドは、コミュニティが今までに見つけ出してきた知見を凝縮したものです。

3 種類のルール：どれを使えばいい？

これがフォーラムで最も混乱を招いているポイントです。Cursor には実は3 種類のルール機構があり、それぞれ異なる目的を持っています。以下に整理しました：

Rules for AI（グローバル）

Settings > General > Rules for AI にあります。これは Cursor で開くすべてのプロジェクトに適用されるグローバルルールです。ローカル設定に保存され、プロジェクトディレクトリには存在しません。

適した用途：

• 個人の好み（「常に TypeScript strict モードを使う」など）
• すべてのプロジェクトで共通の規約
• モデルの振る舞い調整（「簡潔に返答し、頼まれない限り説明しない」など）

Rules for AI（グローバル）

Always use functional components with TypeScript.
Prefer named exports over default exports.
When fixing bugs, explain the root cause briefly before showing the fix.

.cursorrules（プロジェクト単位）

プロジェクトのルートディレクトリに .cursorrules という名前で配置するファイルです。これは古典的なアプローチで、1 つのファイル（プレーンテキストまたはマークダウン）に、このプロジェクト内での AI の振る舞いを記述します。

適した用途：

• プロジェクト固有の技術スタックと規約
• チームで共有するルール（Git にコミット可能）
• フレームワーク固有のパターン（Next.js、Django、Rails など）

.mdc ルール（モダンでスコープ付き）

新しいフォーマットです。.cursor/rules/ ディレクトリ内に .mdc ファイルを配置します。各ファイルは特定のファイルパターンにスコープでき、UI から個別のルールをオン/オフできます。

適した用途：

• ルールを適用するタイミングのきめ細かな制御
• 異なるディレクトリで異なる規約を持つ大規模プロジェクト
• ルールを選択的に有効/無効にしたいチーム

.mdc ルールを使ったプロジェクト構造

.cursor/
  rules/
    react-components.mdc
    api-endpoints.mdc
    database.mdc
    testing.mdc

比較表

機能	Rules for AI	.cursorrules	.mdc ルール
スコープ	グローバル（すべてのプロジェクト）	単一プロジェクト	単一プロジェクト
配置場所	Cursor 設定	プロジェクトルート	.cursor/rules/
ファイルパターン	該当なし	該当なし	ルールごとのスコープ設定
UI での切り替え	はい	いいえ	はい
Git での共有	いいえ	はい	はい
複数ファイル	いいえ	いいえ（単一ファイル）	はい
ステータス	安定版	安定版（レガシー）	推奨

ヒント

3 つを同時に使うこともできます。Rules for AI で個人のベースラインを設定し、.cursorrules または .mdc ファイルでプロジェクト固有のルールを管理します。競合した場合、プロジェクト単位のルールが優先されます。

効果的な .cursorrules ファイルの書き方

多くのチュートリアルでは .cursorrules をマークダウンで書くよう勧めています。それでも動作しますが、フォーラムユーザー razbakov さんは構造化された JSON を使う方が良いと強く主張しています。理由は：LLM は散文より構造化データをより確実に解釈するため、ルールがより一貫して守られるということです。

以下は、Next.js + TypeScript プロジェクト向けの JSON アプローチを使った実際の .cursorrules ファイルです：

.cursorrules

{
  "project": {
    "name": "My SaaS App",
    "stack": ["Next.js 14", "TypeScript", "Tailwind CSS", "Prisma"],
    "packageManager": "pnpm"
  },
  "conventions": {
    "naming": {
      "components": "PascalCase",
      "functions": "camelCase",
      "files": "kebab-case",
      "constants": "SCREAMING_SNAKE_CASE"
    },
    "imports": {
      "order": ["react", "next", "lib/*", "components/*", "relative paths"],
      "noCircularImports": true,
      "alias": "@/ for src/"
    },
    "components": {
      "preferFunctional": true,
      "folderByFeature": true,
      "colocateStyles": true
    }
  },
  "rules": [
    "Always define TypeScript interfaces for component props",
    "Use 'use client' directive only when component needs interactivity or hooks",
    "Prefer server components by default in Next.js app router",
    "No default exports -- use named exports for everything",
    "API routes go in app/api/ following REST conventions",
    "Database queries use Prisma client from lib/db.ts only",
    "Error handling: use try/catch with proper error types, never swallow errors",
    "Environment variables must be validated with zod in env.ts"
  ],
  "antiPatterns": [
    "Never use 'any' type -- use 'unknown' and narrow with type guards",
    "Never put business logic in page.tsx files",
    "Never use inline styles -- use Tailwind classes or CSS modules",
    "Never import from relative paths like '../../' -- use @/ alias"
  ]
}

なぜプレーンテキストより効果的なのか

ルールを自然言語の段落で書くと、AI はあなたの意図を「解釈」する必要があります。構造化された JSON では：

• 各ルールは独立した明確な指示になります
• AI がどの部分がルールでどの部分がコンテキストかを推測する必要がありません
• カテゴリ別に整理できるため、メンテナンスが容易です
• ルールの追加や削除がフォーマットを崩しません

注意：マークダウンが好みなら、それでも問題ありません。重要な洞察は散文より構造という点です。マークダウンを使う場合も、長い段落ではなく箇条書きと明確な見出しを使いましょう。

マークダウン版の代替案

JSON が硬すぎると感じる場合は、以下のように「文字の壁」問題を避けつつ、構造化されたマークダウン版も有効です：

.cursorrules（マークダウン版）

# Project Rules

## Tech Stack
- Next.js 14 (App Router)
- TypeScript (strict mode)
- Tailwind CSS
- Prisma ORM

## Naming
- Components: PascalCase (UserProfile.tsx)
- Utilities: camelCase (formatDate.ts)
- Constants: SCREAMING_SNAKE_CASE (MAX_RETRY_COUNT)
- Files: kebab-case (user-profile.tsx)

## Hard Rules
- Always use named exports
- Every component needs TypeScript prop types
- Server components by default, add 'use client' only when necessary
- No `any` type, ever
- All env vars validated with zod

## File Structure
- Components in src/components/[feature]/
- Hooks in src/hooks/
- API utils in src/lib/
- Types in src/types/

AI に .cursorrules を書かせる

フォーラムユーザー tomredman さんからの本当に役立つテクニックです：一からルールを書くのではなく、Cursor の Agent モードを使ってコードベースを分析し、自動生成させるのです。

手順

1. Cursor のチャットパネルを開く
2. Agent モードに切り替える
3. 以下のプロンプトを入力：

Analyze this codebase and generate a comprehensive .cursorrules file.
Look at:
- Existing files and directory structure
- Package.json dependencies
- Config files (tsconfig, eslint, prettier, etc.)
- Existing code patterns and conventions

Output a .cursorrules file that captures the actual conventions
already used in this project. Use JSON format with clear categories
for tech stack, naming conventions, coding rules, and anti-patterns.

4. 出力を注意深く確認してください。AI はあなたが気づいていなかったパターンも捉えます
5. 不正確な部分を削除し、不足を補うよう編集する
6. プロジェクトルートに .cursorrules として保存する

備考

これは、しばらく運用され一貫したパターンがあるプロジェクトで最も効果を発揮します。まったく新しいプロジェクトでは、手動で書くかテンプレートから始める方が良いでしょう。

生成されたルールの反復改善

最初から完璧な結果を期待しないでください。以下が私のワークフローです：

1. Agent モードで生成する
2. Cursor に新しいコンポーネントを書かせてテストする。ルールに従っているか？
3. 逸脱している箇所をメモし、明示的なルールを追加する
4. 数回繰り返し、出力が一貫して正しくなるまで調整する

このプロセス全体で 15〜20 分かかりますが、後で「あれを直して、いやそうじゃなくて」というやり取りで何時間も節約できます。

コミュニティリソース

一から始める必要はありません。コミュニティが構築したいくつかのルールライブラリを紹介します：

cursor.directory

cursor.directory は、フレームワークと言語別に整理された .cursorrules ファイルの厳選コレクションです。スタータールールを探すのにフォーラムで最も人気のあるリソースです。

cursorrules.agnt.one

cursorrules.agnt.one は Agent 向けのルールに特化しています。Agent モードを多用する場合はチェックする価値があります。

GitHub コレクション

GitHub で .cursorrules を検索すれば、数千もの実世界の例が見つかります：

GitHub 検索クエリ

filename:.cursorrules stars:>5

自分のプロジェクトと似た言語やフレームワークでフィルタリングしてみてください。

フォーラムスレッド：Share Your .cursorrules

Cursor Forum には「Share your .cursorrules」という固定スレッドがあり、ユーザーが自分の設定とその説明を投稿しています。本番環境で何が機能するかを知るのに最適な情報源です。

警告

.cursorrules ファイルをそのままコピーしてプロジェクトに入れないでください。必ず自分の実際のスタックと規約に合わせて調整してください。React Native のルールファイルを Django プロジェクトに入れても、害になるだけです。

よくある落とし穴

数十ものフォーラムスレッドを読んだ結果、最も頻繁に出てくる問題は以下の通りです：

1. ルールが長すぎるとパフォーマンスが悪化する

「ルールが多いほど AI の振る舞いが良くなる」という神話が根強く残っていますが、実際は逆です。Cursor はルールをコードや会話とともにコンテキストウィンドウに注入します。長いルールは、実際のコードコンテキストのスペースを圧迫します。

可能な限り 2000 文字以内に収めてください。5000 文字を超えている場合は、容赦なく削る必要があります。

悪い例：冗長すぎる

When you are writing React components in this project, you should always make sure
to use functional components instead of class components, and you should define
your prop types using TypeScript interfaces rather than PropTypes, and you should...

良い例：簡潔で直接的

- Use functional React components only
- TypeScript interfaces for all props
- Named exports, no defaults

2. 競合するルール

グローバルに Rules for AI を設定し、プロジェクトに .cursorrules ファイルがある場合、競合は避けられません。例えば：

• グローバルルール：「2 スペースのインデントを使う」
• プロジェクトルール：「4 スペースのインデントを使う」

Cursor はプロジェクト単位のルールを優先して解決しますが、両方が存在すると AI は混乱することがあります。解決策：グローバルルールは最小限かつ汎用的に保ち、詳細はプロジェクトファイルに入れましょう。

3. AI がすでに知っていることを教えるルール

モデルがすでに得意としていることにルールの予算を浪費しないでください：

避けるべき不要なルール

- Write clean, readable code          # モデルはデフォルトでこれを行う
- Follow best practices               # 曖昧すぎて役に立たない
- Use proper error handling          # すでにデフォルトの振る舞い
- Comment your code                  # しばしば不要なノイズになる

代わりに、モデルのデフォルトと比較してあなたのプロジェクトがどう異なるかに焦点を当てましょう：

実際に価値を追加するルール

- Use Zod schemas for all API input validation
- All database queries go through the repository pattern
- GraphQL resolvers must have @authenticated directive
- Use pnpm workspaces for monorepo package management

4. .cursorrules をコミットし忘れる

チームで作業していて .cursorrules ファイルがバージョン管理に入っていない場合、恩恵を受けているのはあなただけです。Git に追加し、オンボーディングプロセスの一部にしましょう。

.cursorrules を Git に追加

git add .cursorrules
git commit -m "Add project AI rules for Cursor"

注意：開発者ごとに好みが異なる場合、.cursorrules を Git から除外したいチームもあります。その場合は、.cursorrules.example をテンプレートとして使用し、.cursorrules を .gitignore に追加しましょう。

5. ルールをテストしない

ルールを書いたら、すぐにテストしてください。Cursor に以下を依頼してみてください：

• 新しいコンポーネントを生成する
• 既存の関数をリファクタリングする
• バグを修正する

出力が期待と一致しない場合、ルールの調整が必要です。ルールが機能していないことに、機能開発の途中で気づくのを待ってはいけません。

クイックスタートチェックリスト

.cursorrules を初めて設定する場合、最小限の手順は以下の通りです：

• .cursorrules（単一ファイル）と .mdc（複数ファイル）のどちらかを決める
• Agent モードを使ってコードベースを分析し、初稿を生成する
• 2000 文字以内に削る
• 汎用的なアドバイスではなく、プロジェクト固有のルールに焦点を当てる
• Cursor にコンポーネントや関数を生成させてテストする
• 出力が一貫するまで反復改善する
• バージョン管理にコミットする
• チームと共有する

関連記事

• Best Practices for .cursor/rules
• MDC Rules Best Practices
• Using Cursor Rules Effectively
• How to Ignore Sensitive Files in Cursor