Cursor初期設定ガイド - Rulesとコードベースインデックスの活用

はじめに

Cursorは強力なAI機能を備えていますが、プロジェクト固有のコーディング規約やアーキテクチャをAIに理解させることで、さらに精度の高いコード生成が可能になります。

本記事では、CursorのRules機能とコードベースインデックスを設定し、AIがプロジェクトのコンテキストを理解する環境を構築する方法を解説します。この記事を読むことで、以下のことができるようになります。

• Project Rules（.cursor/rules）を作成し、プロジェクト固有のルールをAIに伝えられる
• AGENTS.mdを使ったシンプルな指示の記述方法がわかる
• コードベースインデックスの仕組みを理解し、セマンティック検索を活用できる
• User Rules/Project Rules/Team Rulesを適切に使い分けられる

実行環境と前提条件

本記事の内容を実践するための環境要件は以下のとおりです。

前提条件

• Cursorがインストールされ、アカウントでログイン済みであること
• プロジェクトがワークスペースとして開かれていること
• Gitの基本操作（commit、pushなど）を理解していること（Team Rulesのバージョン管理に有用）

期待される結果

本記事の手順を完了すると、以下の状態になります。

• プロジェクト固有のRulesが作成され、AIがコーディング規約を理解している
• コードベースインデックスが有効化され、セマンティック検索でコードを見つけられる
• 適切なRulesの使い分けができ、個人・プロジェクト・チームでルールを管理できる

Rulesとは何か

Rulesは、Cursor Agentに対するシステムレベルの指示を提供する機能です。大規模言語モデルは各補完のあいだで状態を保持しませんが、Rulesを使うことでプロンプトレベルで永続的かつ再利用可能なコンテキストを提供できます。

ルールが適用されると、その内容がモデルのコンテキストの先頭に含まれます。これにより、AIはコード生成、編集内容の解釈、ワークフロー支援の際に一貫した指針を得られます。

Rulesの4つの種類

Cursorは以下の4種類のルールをサポートしています。

ルールの優先順位

ルールは次の順序で適用されます。

1. Team Rules（最優先）
2. Project Rules
3. User Rules

指示内容が競合する場合は、先に適用されるソースが優先されます。

Project Rulesの作成

Project Rulesは .cursor/rules ディレクトリに配置され、バージョン管理されるプロジェクト固有のルールです。

ディレクトリ構造

Project Rulesは以下のような構造で管理します。

.cursor/rules/
├── frontend-components/
│   └── RULE.md
├── api-design/
│   └── RULE.md
│   └── scripts/
│       └── generate-openapi.sh
└── testing/
    └── RULE.md

各ルールフォルダには以下を含めることができます。

• RULE.md: フロントマターのメタデータと指示を含むメインのルールファイル
• scripts/: ルールから参照される追加のスクリプト（任意）
• その他の参照ファイル（任意）

ルールの作成方法

ルールを作成する方法は2つあります。

コマンドパレットから作成

1. コマンドパレットを開く（Ctrl + Shift + P / Cmd + Shift + P）
2. 「New Cursor Rule」を検索して選択
3. ルール名を入力
4. .cursor/rules/[ルール名]/RULE.md が自動作成される

設定画面から作成

1. Ctrl + Shift + J（macOSは Cmd + Shift + J）でCursor設定を開く
2. 「Rules, Commands」に移動
3. 「+ Add Rule」をクリック
4. ルール名を入力して作成

RULE.mdの基本構造

RULE.md ファイルは、フロントマターのメタデータと本文からなるMarkdownファイルです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

---
description: "フロントエンドコンポーネントとAPIバリデーションの標準"
globs: 
alwaysApply: false
---

## コンポーネント設計ガイドライン

- Reactコンポーネントは関数コンポーネントで記述する
- Propsには必ずTypeScriptの型定義を付ける
- コンポーネント名はPascalCaseを使用する

## 参照ファイル

@component-template.tsx

ルールタイプの設定

フロントマターの設定によって、ルールの適用方法を制御できます。

ルールタイプ別の設定例

Always Apply（常に適用）

プロジェクト全体で常に従うべき基本ルールに使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

---
description: "プロジェクト全体のコーディング規約"
alwaysApply: true
---

## 基本ルール

- TypeScriptを使用する
- ESLintとPrettierの設定に従う
- コミットメッセージはConventional Commitsに従う

Apply to Specific Files（特定ファイルに適用）

特定のファイルタイプや領域にのみ適用するルールに使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
description: "Reactコンポーネントのスタイルガイド"
globs: ["src/components/**/*.tsx", "src/features/**/*.tsx"]
alwaysApply: false
---

## コンポーネント規約

- カスタムフックは`use`プレフィックスで始める
- スタイルはCSS Modulesを使用する
- テストファイルは同じディレクトリに配置する

Apply Intelligently（インテリジェント適用）

AIが関連性を判断して自動適用するルールに使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

---
description: "データベースマイグレーションとスキーマ設計のガイドライン"
alwaysApply: false
---

## マイグレーション規約

- カラム名はsnake_caseを使用する
- 外部キーには`_id`サフィックスを付ける
- DELETEではなくSOFT DELETEを推奨

効果的なルールの記述パターン

良いルールは、焦点が明確で、実行可能で、スコープが適切に絞られています。

ベストプラクティス

効果的なルールを書くためのポイントは以下のとおりです。

• ルールは500行以内に収める
• 大きなルールは分割し、複数の組み合わせ可能なルールにする
• 具体的な例や参照ファイルを提示する
• あいまいな指示は避け、社内ドキュメントのように明確に記述する
• チャットで同じようなプロンプトを繰り返す場合は、ルール化を検討する

実践的なルール例

TypeScript/Reactプロジェクトのルール例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

---
description: "React/TypeScriptプロジェクトのコーディング標準"
globs: ["src/**/*.tsx", "src/**/*.ts"]
alwaysApply: false
---

## TypeScript規約

- `any`型の使用を禁止する。型が不明な場合は`unknown`を使用
- 関数の戻り値には明示的に型を付ける
- interfaceよりtypeを優先する（拡張が必要な場合を除く）

## React規約

- 関数コンポーネントのみを使用する（クラスコンポーネント禁止）
- 状態管理にはReact Queryとzustandを使用
- カスタムフックは`hooks/`ディレクトリに配置

## ファイル命名規則

- コンポーネント: `PascalCase.tsx`（例: `UserProfile.tsx`）
- フック: `useCamelCase.ts`（例: `useUserData.ts`）
- ユーティリティ: `camelCase.ts`（例: `formatDate.ts`）

## 参照テンプレート

@templates/component-template.tsx
@templates/hook-template.ts

API設計のルール例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

---
description: "REST API設計とバリデーションのガイドライン"
globs: ["src/api/**/*.ts", "src/routes/**/*.ts"]
alwaysApply: false
---

## エンドポイント設計

- リソース名は複数形を使用（例: `/users`, `/posts`）
- ネストは2階層まで（例: `/users/:id/posts`）
- クエリパラメータはcamelCaseを使用

## レスポンス形式

\`\`\`typescript
interface ApiResponse<T> {
  data: T;
  meta?: {
    page: number;
    limit: number;
    total: number;
  };
}

interface ApiError {
  error: {
    code: string;
    message: string;
    details?: Record<string, string[]>;
  };
}
\`\`\`

## バリデーション

- 入力バリデーションにはzodを使用
- バリデーションエラーは422ステータスで返す
- エラーメッセージは日本語で記述

AGENTS.mdによるシンプルな指示

AGENTS.md は、エージェント用の指示を定義するためのシンプルなMarkdownファイルです。Project Rulesの代替として、プロジェクトのルートディレクトリに配置して使用できます。

AGENTS.mdの特徴

AGENTS.mdの記述例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Project Instructions

## Code Style

- Use TypeScript for all new files
- Prefer functional components in React
- Use snake_case for database columns

## Architecture

- Follow the repository pattern
- Keep business logic in service layers
- Use dependency injection for testability

## Testing

- Write unit tests for all utility functions
- Use integration tests for API endpoints
- Maintain 80% code coverage minimum

ネストされたAGENTS.mdのサポート

Cursorは、プロジェクトのルートディレクトリだけでなく、サブディレクトリ内のAGENTS.mdもサポートします。

project/
├── AGENTS.md           # プロジェクト全体の指示
├── frontend/
│   └── AGENTS.md       # フロントエンド固有の指示
└── backend/
    └── AGENTS.md       # バックエンド固有の指示

各ディレクトリのAGENTS.mdは、そのディレクトリ内のファイルを編集する際に参照されます。

Project RulesとAGENTS.mdの使い分け

User Rulesの設定

User Rulesは、すべてのプロジェクトに適用されるグローバルな設定です。個人の好みの会話スタイルやコーディング規約を設定するのに最適です。

User Rulesの設定方法

1. Ctrl + Shift + J（macOSは Cmd + Shift + J）でCursor設定を開く
2. 「Rules」セクションに移動
3. 「User Rules」テキストエリアにルールを入力

User Rules記述例

簡潔なスタイルで返信してください。不要な繰り返しや冗長な表現は避けてください。

コードを提案する際は以下に従ってください:
- 日本語でコメントを記述する
- 変数名・関数名は英語を使用する
- エラーハンドリングを必ず含める

User Rulesの適用範囲

• Agent（Chat）で使用される
• Tab補完やインライン編集（Ctrl+K）には適用されない
• Project RulesやTeam Rulesより優先度が低い

Team Rulesの活用

Team Rulesは、Cursorダッシュボードから管理されるチーム全体のルールです。Team/Enterpriseプランで利用可能で、組織標準をすべてのプロジェクトで維持できます。

Team Rulesの作成

1. Cursorダッシュボードにアクセス
2. チーム管理者としてログイン
3. 「Team Rules」セクションで「Add Rule」をクリック
4. ルール名と内容を入力
5. 適用オプションを設定

Team Rulesの設定オプション

Team Rulesの特性

• プレーンテキスト形式（Project Rulesのようなフォルダ構造やメタデータはなし）
• 有効なTeam Ruleは、チームのすべてのリポジトリとプロジェクトでAgentのモデルコンテキストに含まれる
• Team Rules → Project Rules → User Rules の順で優先適用される

Team Rules活用のポイント

組織全体で統一したい基本方針をTeam Rulesに設定します。

# 組織コーディング標準

## セキュリティ
- 機密情報をハードコードしない
- 環境変数または secrets manager を使用する
- SQLインジェクション対策としてパラメータ化クエリを使用する

## ドキュメント
- 公開APIには必ずJSDocコメントを付ける
- READMEには実行方法を記載する

## レビュー
- PRには必ずユニットテストを含める
- 破壊的変更にはマイグレーションガイドを添付する

コードベースインデックスの仕組み

Cursorのコードベースインデックスは、プロジェクト全体をセマンティック解析し、自然言語クエリに対応した検索を可能にする機能です。

インデックス作成の流れ

コードベースインデックスは以下の7つのステップで構築されます。

flowchart LR
    A[ワークスペース] --> B[ファイル同期]
    B --> C[チャンク化]
    C --> D[AI埋め込み]
    D --> E[ベクターDB]
    F[検索クエリ] --> G[クエリ埋め込み]
    G --> H[類似検索]
    E --> H
    H --> I[検索結果]

1. ワークスペースのファイルがCursorサーバーと安全に同期される
2. ファイルが関数・クラス・論理的なコードブロックなど意味のあるチャンクに分割される
3. 各チャンクがAIモデルでベクトル表現に変換される
4. 埋め込みが専用のベクトルデータベースに保存される
5. 検索時にクエリも同じAIモデルでベクトルに変換される
6. クエリのベクトルと保存済みの埋め込みが比較され、類似するコードチャンクが特定される
7. セマンティックな類似度でランク付けされた検索結果が返される

インデックスの自動同期

インデックスは以下のタイミングで自動的に更新されます。

セマンティック検索 vs Grep

セマンティック検索は、従来のgrep検索と比較して以下の利点があります。

例えば、Agentに「トップナビゲーションを更新して」と指示すると、ファイル名に「navigation」が含まれていなくても、セマンティック検索は header.tsx を見つけられます。

インデックス設定の確認と管理

インデックス状況の確認

1. Ctrl + Shift + J（macOSは Cmd + Shift + J）でCursor設定を開く
2. 「Indexing & Docs」セクションに移動
3. インデックスの進捗状況を確認（80%で検索が利用可能に）

インデックス対象ファイルの確認

1. 設定画面の「Indexing & Docs」セクションで「View included files」をクリック
2. インデックス済みの全ファイルを一覧した.txtファイルが開く

インデックス対象の制御

Cursorは .gitignore や .cursorignore に指定されたファイルを除くすべてのファイルをインデックスします。大きなコンテンツファイルを無視することで、回答の精度が向上します。

.cursorignoreの設定例

# 生成ファイル
dist/
build/
node_modules/

# 大きなデータファイル
*.csv
*.json
data/

# ドキュメント
docs/

# テスト用のモックデータ
__mocks__/
fixtures/

プライバシーとセキュリティ

コードベースインデックスのセキュリティは以下の層で保護されています。

• ファイルパスはサーバー送信前に暗号化され、プロジェクト構造は秘匿される
• コード本体が平文でサーバーに保存されることはない
• コードはインデックス作成中のみメモリに保持され、その後破棄される

Rulesのインポートと共有

GitHubからのリモートルールインポート

アクセス権のある任意のGitHubリポジトリ（パブリック/プライベート）から、ルールを直接インポートできます。

1. Cursor Settings → Rules, Commandsを開く
2. 「Project Rules」の横にある「+ Add Rule」をクリック
3. 「Remote Rule (GitHub)」を選択
4. ルールを含むGitHubリポジトリのURLを貼り付け
5. Cursorがそのルールを取得してプロジェクトに同期

インポートしたルールは元のリポジトリと継続的に同期されるため、リモートルールを更新するとプロジェクトにも自動的に反映されます。

Agent Skillsからのインポート

CursorはAgent Skillsシステムからルールを読み込むことができます。

1. Cursor Settings → Rulesを開く
2. 「Import Settings」セクションを見つける
3. 「Agent Skills」をオンに切り替え

Agent Skillsはエージェント決定ルールとして扱われ、コンテキストに基づいて関連性があるかどうかをCursorが判断します。

レガシールールからの移行

.cursorrules（レガシー）

プロジェクトルートにある .cursorrules ファイルは引き続きサポート対象ですが、将来的に廃止される予定です。Project RulesまたはAGENTS.mdへの移行を推奨します。

.mdc形式のルール

Cursor 2.2以降も .mdc 形式のルールは引き続き利用できますが、新しく作成されるルールはすべて .cursor/rules 配下のフォルダとして作成されます。

まとめ

本記事では、CursorのRules機能とコードベースインデックスの設定方法を解説しました。

• Project Rules（.cursor/rules）でプロジェクト固有のコーディング規約をAIに伝えられる
• AGENTS.mdでシンプルな指示を素早く定義できる
• コードベースインデックスにより、セマンティック検索でコードを見つけられる
• User Rules/Project Rules/Team Rulesは、個人・プロジェクト・組織の各レベルで適切に使い分ける

これらの設定を適切に行うことで、CursorのAIがプロジェクトのコンテキストを理解し、より精度の高いコード生成やアシスタンスを提供できるようになります。

参考リンク

• Cursor Rules公式ドキュメント
• Cursorコードベースインデックス
• Cursor Ignoreファイル設定
• Cursorダッシュボード（Team Rules）
• Cursor Agent Skills
• Cursorフォーラム