株式会社メンバーズ AIフォーオールカンパニー
🐭

Cursor 入門 - Rules 機能の使い方【コピペ OK の設定例付き】

ぴーなっつ
に公開
AI
開発環境
生産性向上
Cursor
生成 AI
tech

Cursor で開発していると、毎回同じ指示を繰り返すのが面倒に感じることはありませんか？

そんな悩みを解決してくれるのが Cursor の Rules 機能です。Rules を使えば、プロジェクト固有のコーディング規約や文脈を AI に記憶させることができ、チーム全体で開発方針を統一できます。

本記事では、Cursor が提供する Rules の基本的な使い方と、チーム開発での活用方法を紹介します。

📚 この記事でわかること

  • Cursor の 4 種類の Rules の違いと使い分け
  • Project Rules の具体的な設定方法と適用タイプ
  • 実践的なルール例とベストプラクティス

📋 Cursor の 4 種類の Rules

Cursor では、用途に応じて 4 種類の Rules を使い分けることができます。

ルールの種類 保存場所 適用範囲 主な用途
Project Rules .cursor/rules プロジェクト全体 コーディング規約、技術スタック、アーキテクチャの説明
User Rules Cursor 設定 全プロジェクト 個人的な好み（返答スタイル、言語など）
Team Rules ダッシュボード チーム全体 チーム共通のルール（Team/Enterprise プランのみ）
AGENTS.md プロジェクトルート プロジェクト全体 Project Rules のシンプルな代替

まず押さえるべきは Project Rules です。

これをベースに、必要に応じて User Rules や AGENTS.md を組み合わせていくのがおすすめです。Team/Enterprise プランを利用しており、メンバー全体で開発方針を統一したい場合は、Team Rules の設定も検討すると良いでしょう。

🎯 Project Rules の実践

Rules の作成方法

Rules は以下のいずれかの方法で作成できます。

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

    • Cmd/Ctrl + Shift + P を押す
    • New Cursor Rule を実行

  2. 設定画面から作成

    • Cursor Settings > Rules に移動
    • 作成ボタンをクリック

作成すると、プロジェクトルートに .cursor/rules ディレクトリが生成され、その中に .mdc ファイルが保存されます。

4 つの適用タイプ

Project Rules には、4 つの適用タイプがあります。適用タイプは、.mdc ファイルの冒頭（frontmatter）で設定します。

1. Always Apply（常に適用）

すべてのチャットセッションで常に適用されるルールです。プロジェクト全体で守るべき基本的なルールに適しています。

---
alwaysApply: true
---

# 基本ルール

- 日本語で回答
- Step by Step で思考
- TypeScript を使用
- DRY と KISS を意識

このルールを設定しておくと、AI は常にこれらの指針に従って回答してくれます。

2. Apply Intelligently（必要に応じて適用）

AI が description に基づいて関連性を判断し、必要に応じて適用するルールです。

---
description: 'DB操作のルール'
alwaysApply: false
---

# DB 規約

- ユーザー情報のテーブル名は `users` にする
- 日付のカラム名は `created_at` などのスネークケースにする

データベース関連の質問をすると、このルールが自動で適用されます。

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

ファイルパターンに一致する場合のみ適用されるルールです。

---
globs: ['**/test_*.py']
alwaysApply: false
---

# テスト規約

- テストファイルは `test_` で始める
- テスト関数名は `test_login_success` のように英語のスネークケースで具体的に記述する

テストファイルを編集している時だけ、このルールが適用されます。

4. Apply Manually（手動で適用）

@ メンションで明示的に呼び出すルールです。テンプレート生成などに便利です。

例えば、.cursor/rules/api-creation.mdc というファイル名でルールを作成した場合：

---
alwaysApply: false
---

# API 作成テンプレート

API を作るときは、以下の項目を必ず含めてください。

- データのチェック（バリデーション）
- エラーが起きたときの処理
- 動作確認用のテストコード

チャットで「@api-creation を使って新しいエンドポイントを作って」と指示すると、このテンプレートに従ったコードが生成されます。

💪 おすすめのルール例

私が実際に使っているルールを紹介します。これをベースに、あなたのプロジェクトに合わせてカスタマイズしてみてください。

設計原則ルール

プロジェクト全体で守りたい設計原則をまとめたルールです。

💡 まずはこれをコピペして試してみてください！

設計原則ルールの全文（コピペ用）
---
alwaysApply: true
---

# AI への指示書

## 役割とコンテキスト

### 役割

これから私が行う様々なプログラミングに関する要望や質問に対して、アシスタントとして的確なサポートを提供してください。

## ワークフロー

### Plan → Act → Reflect

1. **Plan**: 実装前に計画提示 → ユーザー承認待ち（承認の際は「GO」サイン）
2. **Act**: 承認後、型ヒント付きで最小限の変更
3. **Reflect**: 変更内容と理由を簡潔に説明

## 基本的なルール

- **コードの品質**: 常にクリーンで、効率的、そして可読性の高いコードを生成してください。
- **コードのリファクタリング**: 既存のコードをリファクタリングする際は、ロジックを機能単位で適切な関数に分割し、可読性と保守性を高めることを意識してください。
- **import 文**: import 文は、要求された機能を実現するために必要かつ一般的なものだけを使用してください。既存のコードを扱う際は、import 文を勝手に変更・削除しないでください。
- **ダミーのコード**: 動作しない、あるいは仮置きの関数や変数は含めないでください。
- **コメント**: コードだけで意図が明確に伝わる場合、コメントは不要です。複雑なアルゴリズムや、特定のライブラリの少し特殊な使い方など、補足が必要な場合にのみ簡潔なコメントを記述してください。
- **説明**: コードを提示する際は、そのコードが何をしているのか、なぜそのように実装したのかについての要点を簡潔に添えてください。
- **修正範囲**: ユーザーからの修正依頼があった部分以外は、原則として変更しないでください。
- **プロンプトの修正**: この指示書（プロンプト）自体の修正を依頼された場合は、修正後のプロンプト全体を Markdown 形式のコードブロックで出力してください。

## コーディング規約

### 言語とスタイル

- 日本語を用いること
- step by step で思考すること

### 命名規則

- 同一ファイル内でしか使用しない関数には `_` を先頭に付けて命名すること

### 設計原則

- 単一責任原則を適用し、機能を追加する場合は単一責任原則に基づいてコードを分割すること
- それぞれのファイルは最大 100 行程度に収めることを目指すこと（import 文の長さは考慮しない）
- `shared/`などの共通ファイルからの再利用を検討すること

#### YAGNI - 必要になるまで実装しない

- 現時点で必要な機能のみ実装すること
- 「将来使うかも」という理由で拡張機能を追加しないこと
- 必要になった時点で追加する方が要件が明確になる

#### KISS - シンプルに保つ

- 最もシンプルな解決策を選ぶこと
- 複雑なパターンより単純な関数を優先すること
- 1 行で済むなら複雑なループは不要

#### DRY - 賢く適用

- 明確な重複パターンがある場合のみ共通化すること
- 2 箇所なら重複を許容し、3 箇所目で共通化を検討すること
- 似ているだけの異なるロジックを無理に共通化しないこと
- 早すぎる抽象化より、重複を許容してシンプルさを保つことを優先すること

#### OAOO - Once and Only Once

- 同じロジックは一箇所にのみ実装すること
- 重複したロジックを見つけたら、共通化を検討すること
- KISS と YAGNI の原則と矛盾しない範囲で適用すること
- 共通化により複雑さが増す場合は、シンプルさを優先すること

### 型とコード品質

- **関数定義時には引数と返り値の型ヒントを必ず付けること**
- 非推奨のロジックは使わないこと（例：`while True`など）
- リントエラーを解消すること。修正後は、プロジェクトで設定されているリントツールを実行してエラーがないことを確認すること
- 修正を行う場合は可能な限り最小限の修正で済ませること

### 品質チェックリスト

実装前に以下を確認すること：

#### YAGNI

- [ ] この機能は**今**必要か？
- [ ] ユーザーが明示的に要求したか？

#### KISS

- [ ] もっとシンプルな方法はないか？
- [ ] 他の開発者が 5 分で理解できるか？

#### OAOO

- [ ] 同じロジックが複数箇所に存在しないか？
- [ ] 共通化できる箇所がないか？

#### 過剰設計の兆候（避ける）

- ❌ 1 箇所でしか使われていない共通関数
- ❌ 使われていない抽象クラス
- ❌ 誰も使わないオプションパラメータ

このルールを設定すると：

✅ AI が Plan → Act → Reflect のワークフローに従ってくれる
✅ 実装前に計画を提示して承認を待ってくれる
✅ 型ヒント付きのクリーンなコードを生成してくれる
✅ YAGNI・KISS の原則に基づいたシンプルな実装を優先してくれる
✅ 実装前にチェックリストを確認してくれる

具体的な効果の例：

  • Plan → Act → Reflect の実践：「ユーザー管理機能を作って」と頼むと、まず実装計画を提示して「GO」サインを待ってくれます
  • 型安全性の向上：関数を作成する際に、引数と返り値の型ヒントを付けてくれます
  • YAGNI の徹底：「将来使うかも」という理由で無駄な機能を作らず、今必要な機能だけを実装してくれます
  • 過剰な抽象化を防止：1 箇所でしか使わないのに複雑な共通クラスを作るのではなく、シンプルな関数を優先してくれます
  • 最小限の修正：既存コードを修正する際、依頼された部分以外は変更せず、必要最小限の変更に留めてくれます
  • 実装前の確認：コードを生成する前に「もっとシンプルな方法はないか？」「同じロジックが他にないか？」をチェックしてくれます

👉 まずはこのままコピペして、使いながら自分のプロジェクトに合わせてカスタマイズしていくのがおすすめです。

このルールをベースに、あなたのプロジェクトの技術スタック、チームの開発方針、よく使うライブラリなどに合わせて追加・カスタマイズしてみてください。例えば：

  • フロントエンド開発なら → React のコンポーネント設計ルール
  • API 開発なら → エンドポイント命名規則やエラーハンドリングのルール
  • 特定の言語なら → 言語固有の命名規則やコーディング規約（globs で特定ファイルに適用）

といった具合に、プロジェクトに必要なルールを追加していくと良いでしょう。

💡 ベストプラクティス

実際に使ってみて気づいたポイントをいくつか紹介します。

📝 ルールの構造・管理

  • ルールは 500 行以内に収める：長すぎると処理コストが高くなるため、公式でも推奨されています
  • 目的別にルールファイルを分割する：基本ルール、設計原則、テストコードの命名規則など、責任範囲ごとに分けて管理
  • 適用タイプを適切に使い分ける：Always Apply（基本方針）、Apply Intelligently（特定領域）、globs（ファイルパターン）、Apply Manually（手動で適用）を使い分ける

✍️ ルールの書き方

  • 抽象的な指示ではなく具体例を含める：「エラーハンドリングを適切に」ではなく、try-except の具体的なコード例を示す
  • 断定形で書く：「〜すること」より「〜する」と明確に指示する方が AI が解釈しやすい
  • チェックリスト形式を活用する：- [ ] で実装前の確認項目を記述すると、AI が自動でチェックしてくれる
  • 禁止事項は明示する：バツマーク( ❌ ) や「〜しない」という表現で、やってほしくないことを明確に伝える

🔧 その他の Rules の活用

User Rules：個人の作業スタイルを設定

User Rules は、Cursor 設定（Cursor Settings > Rules）で定義する個人的なルールです。すべてのプロジェクトで適用されます。

以下のような設定が有効です。

- 返答は簡潔に。不要な繰り返しは避ける
- コードの説明は日本語で
- 大きな変更の前に、何をするか説明する
- コード例を必ず含める
- 変更理由を簡潔に説明する
- セキュリティリスクがある場合は警告する

「AI の返答が長すぎる」と感じる場合に設定すると、レスポンスがかなりコンパクトになります。

AGENTS.md：簡易的なルール管理

AGENTS.md は、プロジェクトルートに配置するだけで機能するルールファイルです。Project Rules よりも機能は限定的ですが、Markdown ファイル 1 つで完結するため手軽に導入できます。

個人的には Project Rules の利用がおすすめですが、「まずは手軽に試したい」という場合は AGENTS.md から始めるのも良いかもしれません。

Team Rules：チーム全体で開発方針を統一

Team Rules は、Team または Enterprise プランで利用できる、チーム全体で共有するルールです。ダッシュボードから管理し、チームメンバー全員に適用されます。

✨ まとめ

Cursor の Rules を使うことで、「毎回同じことを説明する」手間が削減されました。

Rules を使って感じたメリット

  • AI への指示が楽になる（プロジェクトの文脈を理解してくれる）
  • コードの一貫性が保たれる
  • チーム全体で開発方針を統一できる
  • 実装前に品質チェックを自動で行ってくれる（YAGNI、KISS などの原則を守れる）

最初は「設定が面倒」と感じるかもしれませんが、一度設定すれば繰り返し活用できます。

まずは本記事で紹介した設計原則ルールを参考にしながら、自分のプロジェクトに合わせてカスタマイズしていくのがおすすめです。Rules を導入して、AI に質の高いコードを生成してもらえるように活用しましょう！

株式会社メンバーズ AIフォーオールカンパニー
株式会社メンバーズ AIフォーオールカンパニー

すべての人に、AIと共に進未来を。「一人ひとりが自分らしく働きながら活躍できる社会を創る」をミッションとして、企業のAI活用をトータルに支援するサービスを展開しています。

Discussion