Cursorで新しくなったProject Rules使ってる？めちゃくちゃ便利だよ。

Cursor、使っていますか？ 
AI アシスタント機能を搭載した人気のコードエディタ Cursor に、最近のアップデートで 「Project Rules」 が大幅強化されました。この機能、実はめちゃくちゃ便利なんです。

この記事は、Cursor に慣れている 中級者向け に Project Rules の活用法を紹介しています。

本記事では Cursor の Project Rules について詳しく解説し、実際の活用例も紹介します。Cursor をより効率的に使いたい方は、ぜひ参考にしてください。

Project Rules とは何か？

Cursor の Rules は、Agent モデルや Cmd + K AI の動作に対してシステムレベルのガイダンスを提供する機能です。これを使うことで、プロジェクトや個人の好みに合わせたコンテキスト、プリファレンス、ワークフローを 永続的 に設定できます。

Rules が解決する問題

大規模言語モデル（LLM）は 各応答（completion）間でメモリを保持しません。つまり、毎回同じ指示を繰り返す必要があります。Rules はこの問題を解決し、プロンプトレベルで永続的で再利用可能なコンテキストを提供します。

Cursor では現在、3 種類のルールをサポートしています。

1. Project Rules — .cursor/rules に保存され、バージョン管理され、コードベースにスコープ されたルール
2. User Rules — Cursor 環境全体に適用される グローバル ルール。設定で定義され、常に適用される
3. .cursorrules（レガシー） — まだサポートされていますが非推奨。代わりに Project Rules の使用が推奨されます

ルールの仕組み

ルールが適用されると、その内容は モデルコンテキストの先頭 に挿入されます。これにより、AI がコードを生成する場合でも、編集を解釈する場合でも、ワークフローを支援する場合でも、一貫したガイダンスを提供できます。

つまり、AIに『前も言ったじゃん！』と愚痴る必要がなくなるわけです。

Project Rules の詳細

Project Rules は .cursor/rules ディレクトリに保存され、各ルールはファイルとして バージョン管理 されます。パスパターンを使って自動添付したり、手動で呼び出したり、関連性に応じて含めたりできます。

Project Rules の最大の特徴は、コードベースと一緒にバージョン管理できることです。これにより チーム全体で AI の動作を一貫 させられます。

Project Rules が向いている用途:

• コードベースに関する ドメイン固有の知識 をエンコードする
• プロジェクト固有の ワークフローやテンプレート を自動化する
• スタイル や アーキテクチャ の決定を標準化する

ルールの構造

各ルールファイルは MDC（.mdc）という軽量フォーマットで記述します。メタデータとコンテンツを 1 ファイルで扱えるのが特徴です。Rules は以下のタイプをサポートします。

ルールタイプ	説明
Always	常にモデルコンテキストに含まれる
Auto Attached	glob パターンに一致するファイルが参照されたときに含まれる
Agent Requested	AI が利用可能。含めるかどうかを AI が判断する（説明必須）
Manual	@ruleName を明示的に呼び出したときのみ含まれる

各ルールタイプの使い分け

• Always: プロジェクト全体に適用したいコーディング規約やスタイルガイドに最適
• Auto Attached: 特定のファイルタイプやディレクトリに対するルールに最適
• Agent Requested: AI が必要に応じて参照する補助的なドキュメントに最適
• Manual: 特定タスクや状況でのみ必要なルールに最適

「Manual」タイプは、まるで呼ばれるまで出てこない実家の猫のようなもので、必要なときだけ登場する控えめな性格ですが、私的にはこちらのルールタイプが日々大活躍しています。

MDC ルールの例

---
type: Auto Attached
globs: ["src/services/*.ts"]
---

# サービス実装ガイドライン

コードベースでサービスを実装する際は、以下のパターンに従ってください：

1. すべてのサービスはインターフェースを実装する必要がある
2. 外部依存関係には依存性注入を使用する
3. 包括的なエラーハンドリングを含める
4. すべてのパブリックメソッドにユニットテストを追加する

@service-template.ts

本記事では理解しやすさのため、一部ルールを日本語で記載しています。

Cursor 内から素早くルールを作成するには Cmd + Shift + P → “New Cursor Rule” が便利です。

ネストされたルール

プロジェクト構造全体に .cursor/rules ディレクトリを配置することで、ルールを整理できます。例:

my-project/
├── .cursor/
│   └── rules/
│       ├── general-style.mdc
│       └── api-guidelines.mdc
├── src/
│   ├── frontend/
│   │   └── .cursor/
│   │       └── rules/
│   │           └── component-standards.mdc
│   └── backend/
│       └── .cursor/
│           └── rules/
│               └── database-patterns.mdc

ネストされたルールは

• 対象ディレクトリのファイルが参照されると 自動添付
• コンテキストピッカー／エージェント からも選択可能
• 関連コードの近くにドメイン固有ルールを置ける

モノレポや複数コンポーネントを持つプロジェクトで特に有用です。

ルールの作成

New Cursor Rule コマンド、または Cursor Settings → Rules からルールを作成すると、.cursor/rules にファイルが生成されます。設定画面では全ルールとステータスを一覧できます。

ルールの生成

会話中に /Generate Cursor Rules コマンドを実行して、AI との議論内容から直接ルールを生成することも可能です。

会話で決定したことを即座にルールとして保存できるので、「同じ指示を毎回コピペする」手間がなくなります。

公式によるベストプラクティス

公式のドキュメントによると、
良いルールの条件は 焦点が絞られ、実行可能で、スコープが明確 が満たされていることであり、具体的には下記の条件を満たすようにすると良いそうです。

• 1 ルール 500 行以内を目安にする
• 大きな概念は複数の 組み合わせ可能なルール に分割
• 必要なら具体例や参照ファイルを添付
• あいまいな表現は避け、内部ドキュメントを書くつもりで 明確に
• チャットで同じプロンプトを繰り返していると気付いたら、ルール化を検討

効果的なルール作成のコツ

1. 具体的に書く — 例: 「良いコードを書いて」→「変数名はキャメルケース。関数は単一責任原則に従う」
2. 例を含める — 抽象的説明だけでなく具体的なコード例を入れる
3. スコープを明確に — どのファイル／ディレクトリに適用するか記述
4. 定期的に見直す — プロジェクトの進化に合わせてルールも更新

実際の活用例

1. コーディング規約の自動適用

---
type: Always
---

# コーディング標準

## TypeScript ガイドライン

- オブジェクトの形状にはtypeではなくinterfaceを使用する
- 可能な場合は読み取り専用プロパティを優先する
- 固定値のセットにはenumを使用する
- 関数には必ず戻り値の型を含める
- Promiseを直接使わずasync/awaitを使用する

## React コンポーネント構造

- hooksを使った関数コンポーネントを使用する
- Propsインターフェースは[コンポーネント名]Propsと命名する
- React.FC型は控えめに使用する
- 複雑なロジックはカスタムhooksに抽出する
- コンポーネントは150行以下に保つ

2. プロジェクト構造の理解支援

---
type: Agent Requested
description: "Information about our project architecture and directory structure"
---

# プロジェクトアーキテクチャ

当アプリケーションはモジュラーモノリス構造に従います：

## ディレクトリ構造

- `/src/core` - コアビジネスロジックとドメインモデル
- `/src/features` - 機能固有のモジュール
- `/src/infrastructure` - 外部統合とフレームワーク
- `/src/ui` - ユーザーインターフェースコンポーネント
- `/src/utils` - 共有ユーティリティ

## モジュール境界

機能間では直接インポートしてはいけません。
機能間のコミュニケーションは**コアモジュール経由**で行う必要があります。

## テスト戦略

- ユニットテスト: `/src/**/*.spec.ts`
- 統合テスト: `/tests/integration`
- E2Eテスト: `/tests/e2e`

新メンバーのオンボーディングに Project Rules を活用すると、ドキュメントを読む時間を大幅に削減できます。AI がプロジェクト構造を理解したうえでコードを生成してくれます。

3. 特定ファイルタイプへのルール

---
type: Auto Attached
globs: ["*.test.ts", "*.spec.ts"]
---

# テストガイドライン

テストを書く際は：

1. 期待される動作を説明する分かりやすいテスト名を使用する
2. Arrange‑Act‑Assert パターンに従う
3. 外部依存関係をモックする
4. エッジケースとエラー条件をテストする
5. テスト同士を独立させる

```typescript
describe('MyComponent', () => {
  it('renders correctly with default props', () => {
    // Arrange
    const props = { /* … */ };

    // Act
    const { getByText } = render(<MyComponent {...props} />);

    // Assert
    expect(getByText('Expected Text')).toBeInTheDocument();
  });
});

4. ワークフロー自動化

---
type: Manual
---

# API エンドポイント作成ワークフロー

新しいAPIエンドポイントを作成する際は、以下の手順に従ってください：

1. `/src/types/api.ts`でリクエスト/レスポンス型を定義する
2. `/src/controllers`でコントローラーを作成する
3. `/src/services`でサービスロジックを実装する
4. `/src/validation`でZodを使用してバリデーションを追加する
5. `/src/routes.ts`でルートを登録する
6. `/tests/api`でテストを追加する
7. `/docs/api.md`でAPIドキュメントを更新する

```typescript
import { Request, Response } from 'express';
import { z } from 'zod';

const requestSchema = z.object({
  name: z.string().min(1),
  email: z.string().email(),
});

export const createUser = async (req: Request, res: Response) => {
  try {
    const data = requestSchema.parse(req.body);
    const user = await userService.create(data);
    return res.status(201).json(user);
  } catch (error) {
    if (error instanceof z.ZodError) {
      return res.status(400).json({ errors: error.errors });
    }
    return res.status(500).json({ message: 'Internal server error' });
  }
};

User Rules との使い分け

Project Rules が 特定プロジェクト 用なのに対し、User Rules はすべてのプロジェクトに適用されるグローバルルールです。

User Rules は 個人の作業スタイル に関する設定に最適です。一方 Project Rules はチームで共有すべき プロジェクト固有のルール を定義します。

User Rules は Cursor Settings → Rules で定義し、MDC ではなく プレーンテキスト です。例:

常に日本語で応答してください。
コードには詳細なコメントを追加してください。
変数名はキャメルケースを使用してください。

チームでのルール共有

現在、プロジェクト間でルールを共有する組み込み機能はありません。

チームでのルール共有方法

公式には共有 MDC ルールのサポートが計画中です。それまでは以下が考えられます。

1. 共有ルールを専用リポジトリに保存
2. 各プロジェクトの .cursor/rules にコピーまたはシンボリックリンクを作成
3. CI パイプラインで共有ルールを自動的に反映

.cursorrules（レガシー）からの移行

プロジェクトルートの .cursorrules は依然サポートされていますが 非推奨 です。より柔軟な Project Rules へ移行しましょう。

.cursorrules は将来的に廃止予定です。早めの移行をおすすめします。

最後に

Cursor の Project Rules ありとなしでは、プロジェクト開発での効率に大きな差が出てくるので、早いうちから触れておくと良いと思います。

特に複数人開発や複雑なコードベースでは、Project Rules を導入すると チームの生産性と一貫性 の向上が見込めます。

まだ使ったことがない方は、ぜひ試してみてください。一度設定すれば、その効果を実感できるはずです。

参考リンク

• Cursor 公式ドキュメント — Rules
• Zenn — Cursor の Project Rules 活用と改善