Cursor Rules設定で自分専用AI開発環境を作る方法
Cursorの.cursorrules設定ファイルを使い、プロジェクトごとにAIの振る舞いをカスタマイズする方法を実践的に解説します。
Cursor Rules設定で自分専用AI開発環境を作る方法
AIアシスタントが「あなたの開発スタイル」を覚えてくれたら？
Cursorを使い始めて、こんな経験はないでしょうか。
「毎回『TypeScriptで書いて』と伝えなければいけない」「コードのインデントスタイルがプロジェクトのルールと違う」「AIが生成するコードに、うちのチームでは使わないパターンが混じっている」。
こういった小さなストレスが積み重なると、AIアシスタントの恩恵を十分に受けられなくなってしまいます。
Cursorには、こうした問題をすべて解決できる「Cursor Rules」という強力な仕組みがあります。
.cursorrulesファイルや、より新しい.cursor/rules/ディレクトリを使うことで、プロジェクトごと・言語ごとにAIの振る舞いを細かくカスタマイズできます。
この記事では、Cursor Rulesの基本的な仕組みから、実際に使える設定例、チームでの運用方法まで、ステップバイステップで解説します。 これを読み終えれば、あなただけの「自分専用AI開発環境」が完成します。
Cursor Rulesとは何か？仕組みを理解する
.cursorrulesファイルの役割
Cursor Rulesとは、Cursorに対して「このプロジェクトでどのように振る舞ってほしいか」を定義するテキストファイルです。
CursorのAIは、コードを生成したり補完したりする際に、このルールファイルを自動的に参照します。 つまり、一度設定しておけば毎回同じ指示を出す必要がなくなります。
2種類のルール設定方法
Cursorでは現在、2つの方法でルールを設定できます。
方法①: .cursorrules（従来型・プロジェクト単位）
- プロジェクトルートに
.cursorrulesファイルを1つ作成する - シンプルで扱いやすく、小〜中規模プロジェクトに向いている
- すべてのルールが1ファイルに集約される
方法②: .cursor/rules/（新形式・モジュール型）
.cursor/rules/ディレクトリ内に複数の.mdcファイルを作成する- ファイルごとに適用条件（glob パターン）を指定できる
- 大規模プロジェクトやモノレポ構成に特に強い
- Cursor公式ドキュメントでは、こちらが推奨されている
グローバルルールとプロジェクトルールの違い
ルールには「グローバルルール」と「プロジェクトルール」の2階層があります。
グローバルルールは、Cursorの設定画面（Cursor Settings > General > Rules for AI）から設定します。
すべてのプロジェクトに共通して適用されるため、自分のコーディングスタイルや好みの言語設定など、普遍的なルールを書くのに適しています。
プロジェクトルールは、プロジェクトのルートディレクトリに.cursorrulesまたは.cursor/rules/として配置します。
そのプロジェクト固有の技術スタック、命名規則、ドメイン知識などを定義します。
チームでGitリポジトリに含めて共有するのが一般的な使い方です。
基本的な.cursorrulesファイルを作ってみよう
ファイルの作成場所
まずはシンプルな.cursorrulesファイルから始めましょう。
プロジェクトのルートディレクトリに、以下の場所に配置します。
my-project/
├── .cursorrules ← ここに作成
├── src/
│ └── index.ts
├── package.json
└── tsconfig.json
Next.js + TypeScriptプロジェクト向けの設定例
以下は、Next.js + TypeScriptプロジェクト向けの実践的な.cursorrulesファイルの例です。
# プロジェクト概要
このプロジェクトはNext.js 14（App Router）とTypeScriptを使用したWebアプリケーションです。
# 技術スタック
- フレームワーク: Next.js 14 (App Router)
- 言語: TypeScript（strictモード有効）
- スタイリング: Tailwind CSS
- 状態管理: React Query（サーバー状態）+ Zustand（クライアント状態）
- テスト: Vitest + Testing Library
# コーディング規則
## TypeScript
- `any`型の使用は禁止。不明な型には`unknown`を使用すること
- 型定義は`interface`より`type`を優先する
- 非null断言演算子（!）の使用を避け、適切な型ガードを使うこと
- exportする関数・型には必ずJSDocコメントを付けること
## React・Next.js
- コンポーネントは必ず関数コンポーネントで記述する
- Server Componentsをデフォルトとし、必要な場合のみ'use client'を付与する
- データフェッチはServer Componentsで行い、クライアントへの受け渡しはpropsを使う
- コンポーネントファイル名はPascalCase（例: UserCard.tsx）
- ユーティリティ関数ファイル名はcamelCase（例: formatDate.ts）
## ファイル構成
- ページコンポーネント: app/（Next.js App Router構成）
- 共通コンポーネント: components/
- カスタムフック: hooks/
- 型定義: types/
- ユーティリティ: lib/
## インポート順序
1. Reactおよびサードパーティライブラリ
2. Next.jsモジュール
3. 内部モジュール（@/エイリアスを使用）
4. 型のみのインポート（import type）
# コミュニケーション
- コードの説明は日本語で行うこと
- エラーの原因と解決策を具体的に説明すること
- 複数の実装方法がある場合はトレードオフを説明すること
これだけの設定を入れておくだけで、Cursorは毎回これらのルールを考慮した上でコードを生成・提案してくれます。
.cursor/rules/を使った高度なモジュール型設定
なぜモジュール型が強力なのか
大規模なプロジェクトや、フロントエンド・バックエンドが混在するモノレポでは、.cursor/rules/ディレクトリを使ったモジュール型設定が特に効果的です。
この方式では、.mdc（Markdown with Cursor metadata）形式のファイルを使い、どのファイルに対してどのルールを適用するかをglobパターンで細かく指定できます。
ディレクトリ構成例
my-project/
├── .cursor/
│ └── rules/
│ ├── general.mdc # 全ファイルに適用する共通ルール
│ ├── typescript.mdc # .ts/.tsxファイルへのルール
│ ├── react-components.mdc # Reactコンポーネント向けルール
│ ├── api-routes.mdc # APIルート向けルール
│ └── testing.mdc # テストファイル向けルール
├── src/
└── package.json
.mdcファイルの記述形式
.mdcファイルは、YAMLフロントマターとMarkdown本文で構成されます。
以下はTypeScript向けのルールファイルの例です。
---
description: TypeScriptファイルに適用するコーディング規則
globs:
- "**/*.ts"
- "**/*.tsx"
alwaysApply: false
---
# TypeScript コーディング規則
## 型安全性
- `any`型は使用禁止。代わりに`unknown`を使い、型ガードで絞り込むこと
- `as`によるキャストは最終手段とし、使用する場合はコメントで理由を明記する
- `!`（非null断言）は使用しない。`??`や`?.`を活用すること
## 関数の書き方
- 純粋関数はアロー関数で記述する
- 副作用を伴う関数はfunction宣言で記述し、明確に識別できるようにする
- 引数が3つ以上の場合はオブジェクト形式にまとめること
## エラーハンドリング
- try-catchのcatch節では必ず`error`の型チェックを行うこと
- カスタムエラークラスを定義して、エラーの種類を明確にすること
## 命名規則
- 変数・関数: camelCase
- クラス・型・インターface: PascalCase
- 定数: UPPER_SNAKE_CASE
- プライベートなクラスメンバー: _camelCase（アンダースコアプレフィックス）
globsフィールドに指定したパターンにマッチするファイルを開いているときだけ、そのルールが自動的に適用されます。
alwaysApply: trueにすると、ファイルに関わらず常にルールが適用されます。
実際に効果が出るルールの書き方のコツ
コツ①: プロジェクトの「なぜ」を伝える
単純な「こうしてください」という指示より、「なぜそうするのか」という背景を添えると、AIはより適切な判断をしてくれます。
悪い例：
- Reduxを使わないこと
良い例：
- 状態管理にReduxは使わないこと。このプロジェクトではZustandを採用しており、
シンプルなAPIと軽量さを重視している。グローバル状態が必要な場合は
useStoreフックを使うこと
コツ②: 具体的なコードサンプルを含める
ルールファイル内にコードサンプルを直接書くことができます。 「このパターンで書いてほしい」という意図が正確に伝わります。
## API呼び出しのパターン
以下のパターンを使ってAPIを呼び出すこと:
// ✅ 正しい例
const fetchUser = async (userId: string): Promise<User> => {
const response = await apiClient.get(`/users/${userId}`);
return userSchema.parse(response.data); // Zodでバリデーション
};
// ❌ 避けるべき例
const fetchUser = async (userId: string) => {
const response = await fetch(`/api/users/${userId}`);
return response.json(); // 型検証なし
};
コツ③: ネガティブルールより、ポジティブルールを優先する
「〜しないこと」というルールより「〜すること」というルールの方が、AIは適切な代替案を提示しやすくなります。 もしネガティブルールを書く場合は、必ずポジティブな代替案もセットで書くようにしましょう。
コツ④: ルールは定期的に見直す
プロジェクトが成長するにつれて、ルールも進化させる必要があります。 「このAIの提案は毎回直している」と感じたら、それはルールに追加すべきサインです。 チームのレトロスペクティブで「Cursor Rulesの見直し」をアジェンダに加えるのも効果的です。
チームでCursor Rulesを共有・運用する
Gitリポジトリに含めて共有する
Cursor Rulesの最大のメリットの1つは、Gitリポジトリに含めてチーム全員で共有できることです。
.cursorrulesや.cursor/rules/ディレクトリをコミットするだけで、チーム全員が同じルールのもとでAIアシスタントを使えるようになります。
.gitignoreでCursor関連ファイルを除外していないかを確認しましょう。
# .gitignoreの確認
cat .gitignore | grep cursor
# .cursorrulesをGitに追加する
git add .cursorrules
git commit -m "chore: add Cursor Rules for project coding standards"
# .cursor/rules/ディレクトリを追加する場合
git add .cursor/rules/
git commit -m "chore: add modular Cursor Rules"
チームルールとして整備するためのテンプレート
チームで運用する場合、以下の構成をベースにすることをおすすめします。
# [プロジェクト名] Cursor Rules
## プロジェクト概要
（プロジェクトの目的・技術スタック・アーキテクチャを簡潔に）
## 絶対に守るルール（Must）
（チームの合意で決定した、例外なく守るべきルール）
## 推奨するパターン（Should）
（基本的に推奨するが、合理的な理由があれば例外を認めるルール）
## 使用しない技術・パターン（Must Not）
（禁止事項とその理由、代替案）
## よく使うコードパターン
（プロジェクト固有のよく使うパターンのサンプル）
## ドメイン知識・用語集
（AIが正確に理解すべきビジネスロジック・ドメイン固有の用語）
## 参考資料
（社内ドキュメント・設計書・ADRへのリンク）
ルールの品質を上げるためのプロセス
Cursor Rulesは「書いたら終わり」ではなく、継続的に改善していくものです。 以下のサイクルを回すことで、チームの開発効率がどんどん向上していきます。
① 問題を発見する: AIが繰り返し「修正が必要な提案」をしてくることに気づく
② ルールに追加する: その問題を防ぐためのルールを.cursorrulesに追記する
③ チームでレビューする: PRに含めてコードレビューと同様のプロセスで承認を得る
④ 効果を測定する: 同じ種類の修正が減ったかを確認する
⑤ また①に戻る: 継続的な改善ループを続ける
よくあるトラブルと解決方法
ルールが反映されていないように感じる
Cursorを再起動するか、チャットウィンドウを新しく開くことで解決するケースが多いです。
.cursorrulesの文法エラー（特にYAMLフロントマターの.mdcファイル）が原因のこともあります。
また、ルールファイルが長すぎるとコンテキストウィンドウを圧迫し、重要なルールが無視されることがあります。
一般的に、.cursorrulesファイルは500〜1000行以内に収めることが推奨されています。
特定のファイルだけルールを変えたい
.cursor/rules/のモジュール型設定に移行し、globsパターンでファイルごとにルールを分けるのが最善策です。
たとえば、テストファイルだけに別のルールを適用したい場合は以下のように設定します。
---
description: テストファイル向けの規則
globs:
- "**/*.test.ts"
- "**/*.spec.ts"
- "**/__tests__/**/*.ts"
alwaysApply: false
---
# テストコーディング規則
## テストの構造
- AAA（Arrange・Act・Assert）パターンで記述すること
- テスト名は「〜の場合、〜であること」の形式で日本語で書くこと
- 1つのテストケースで1つの振る舞いだけを検証すること
## モック
- vi.mock()はファイルの先頭で宣言すること
- 外部APIの呼び出しは必ずモックすること
- ファイルシステムへのアクセスはモックするか、tmpディレクトリを使うこと
AIがルールを無視しているように見える
ルールの書き方が曖昧すぎる可能性があります。 「なるべく〜してください」「できれば〜」という表現より、「必ず〜すること」「〜は禁止」という断定的な表現の方がAIは従いやすいです。
また、矛盾するルールが複数存在すると、AIが混乱して従わなくなることがあります。 ルール同士の一貫性を定期的に確認しましょう。
まとめ：あなただけのAI開発環境を育てよう
Cursor Rulesは、「AIに毎回同じ説明をする」という繰り返しの手間をゼロにしてくれる、非常に強力な仕組みです。
この記事でお伝えしたポイントを整理します。
.cursorrules（従来型）: シンプルで始めやすく、小〜中規模プロジェクトに最適.cursor/rules/（モジュール型）: ファイルタイプごとにルールを分けられ、大規模プロジェクトに強い- グローバルルール: 自分の普遍的なコーディングスタイルをCursor設定に書く
- 「なぜ」を含めて書く: 背景や理由を書くとAIがより賢く動く
- Gitで共有する: チーム全員が同じルールで開発できる
- 継続的に改善する: 「修正した」と感じたら、それをルールに追加するサイクルを回す
最初から完璧なルールを作ろうとする必要はありません。
まずは今日から、5〜10行の簡単な.cursorrulesファイルを作ることから始めてみてください。
使いながら少しずつ育てていくことで、あなたのプロジェクトに完璧にフィットした「自分専用のAI開発環境」が完成します。
Cursorの機能についてさらに詳しく知りたい方は、Cursor公式ドキュメントを合わせてご参照ください。