プログラミング

cursor ProjectRulesとNotepadsの使い分け、設定例を公開

 
記事内に商品プロモーションを含む場合があります

Cursor は近年注目を集める AIエディタ/IDE で、コードの自動生成や編集、ターミナルコマンド実行など、さまざまな支援機能を備えています。

バージョンアップを繰り返すなかでNotepads と Project Rules という2つの機能が登場・進化し、それぞれ異なる形で「AIへの追加コンテキスト」を提供する枠組みを整えてきました。

  • Notepads は、ユーザーが任意のドキュメントやメモをまとめ、必要な時に @Notepad名 で AIチャットやComposerに読み込ませる機能。
  • Project Rules は、.cursor/rules/ディレクトリ以下に Markdown形式のルールファイルを置き、該当ファイルやディレクトリの操作時に自動的にそのルールを AI に適用させる機能。

本記事ではまず Notepads の機能概要と具体的使用例を、次に Project Rules の動作原理や設定例を解説します。最後に両者を比較して、プロジェクトやチームでどう使い分ければいいか、効果的な活用方法は何か、といった観点を示していきます。

特に、Go言語のオニオンアーキテクチャやドメイン駆動設計(DDD)、さらにMySQLスキーマの管理など複雑なアーキテクチャを想定したとき、「AIにどこまでルールや設計情報を教えるべきか？」が大きなテーマになります。

NotepadsとProject Rulesはそれぞれ違ったアプローチでこれを実現できるため、上手に組み合わせることでチーム開発の生産性やコード品質を飛躍的に向上できます。

Contents
  1. 1. Notepads の概要と使い方
  2. 2. Project Rules の概要と使い方
  3. 3. NotepadsとProject Rulesの比較
  4. 4. 効果的な使用事例とワークフローへの組み込み
  5. 5. まとめ
  6. 6. 参考文献・ドキュメント一覧

1. Notepads の概要と使い方

1.1 Notepadsとは？

Notepads は Cursor のいわゆるコンテキスト共有機能の一つで、ユーザーが任意の「メモ」や「資料」をまとめておける領域です。作成したNotepadはチャットやComposerで @Notepad名 と参照すれば、そこに記載された内容をAIが読んでくれます。

主な特徴

  • 能動的に呼び出す
    Notepadに書いてある情報は、ユーザーが @ で指定したときにだけAIのコンテキストへ渡ります。常に適用されるわけではないため、「必要なときだけAIへ提示する」性質があります。
  • 自由形式の文書
    NotepadsではMarkdown形式でテキストを記述し、さらに関連ファイルを添付できます。設計文書、コードスニペット、データベーススキーマなど好きな情報をまとめられます。
  • チーム共有は個別
    Notepadsは、基本的にローカルのCursor環境に保存されるため、他メンバーに自動で同期されません。個人で扱う場合は問題ありませんが、チームで共通ルールを持たせるならProject Rulesの方が適しています。

1.2 Notepadsの特長: 能動的に呼び出せる「ドキュメント置き場」

Notepadsは「通訳してほしい文書」をその都度 @参照する感覚で使うことができ、AIとのやり取りで豊富な文脈をスムーズに付加できます。例えばバラバラに存在する資料を1つのNotepadにまとめておけば、@MyDomainSpec と1回打つだけで「ドメインモデル図」「関連コメント」「注意点リスト」などの文脈が一挙にAIへ渡るわけです。

また、割と長めのドキュメントをドサッと置いておくことも多く、文字数制限に注意しながら設計書やリファレンスをNotepad化しておけば、「AIと対話しながら仕様書を参照し続ける」という理想的なワークフローが実現します。


例えば、Go言語＋DDD＋オニオンアーキテクチャのプロジェクトで、各レイヤの責務やディレクトリ構成をMarkdownでまとめたNotepad「DDDRules」を作成し、必要なときに @DDDRules と呼び出すだけでAIに構造を理解させた上でコード生成・編集を行えます。

1.3 具体的な使用例（Go言語/DDD/オニオンアーキテクチャ/MySQL関連）

(1) Go言語向けNotepad例

# Golang Project Guidelines
Here are important guidelines for our Go project:

- Use Go modules (go.mod) with `1.20`.
- Directory structure:
  - `cmd/` for main entry points
  - `internal/` for core packages
  - `pkg/` for reusable components
- `package main` only in cmd/* files.

We use an Onion Architecture:
- Domain layer (`internal/domain/`) has no external dependencies
- Application layer (`internal/app/`) handles business logic
- Infrastructure layer (`internal/infra/`) has DB, external services

@my_mysql_schema.sql
(Attaching MySQL schema for reference)
  • ここではGo言語全体の構造（ディレクトリ、バージョン、アーキテクチャ）をまとめ、かつMySQLスキーマファイルを添付しています。
  • Composerでコードを生成する際に @GolangProjectGuidelines と指定すれば、AIがGoのプロジェクト構造やオニオンアーキテクチャに配慮した提案を行う。

(2) DDDドメイン定義例

# Domain-Driven Design Notepad
We adopt Domain-Driven Design with these aggregates:

- **User**:
  - Entities: User, Profile
  - Value Objects: Email, Username
  - Repositories: UserRepository
- **Order**:
  - Entities: Order, OrderItem
  - Value Objects: OrderID
  - Services: PricingService

Use cases:
- CreateUser, UpdateProfile, etc.
- PlaceOrder, CancelOrder, etc.

Constraints:
- Domain layer does not import any other layer.
- Use domain services for cross-aggregate logic.
  • これはDDDで管理する主要なドメインモデル群を記載し、不変条件やレイヤー依存ルールを簡単にまとめています。
  • AIに「Orderアイテムの合計金額を算出する関数を書いて」と頼むときに @DomainDrivenDesign を付ければ、AIがOrderエンティティやValue Objectを意識した実装を提案してくれやすくなります。

(3) MySQLスキーマ例

# MySQL Database Schema
Below is an excerpt of our MySQL schema (prod environment):

```sql
CREATE TABLE users (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  username VARCHAR(50) NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE orders (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  total_amount DECIMAL(10,2),
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY(user_id) REFERENCES users(id)
);

Constraints/Conventions:
- Table names in lowercase plural
- Use underscored column names(no camelCase)
- Each table has id, created_at at minimum
  • ここではMySQLのテーブル定義と、命名規則、テーブル共通カラムのポリシーなどをまとめたNotepadを作成
  • SQL関連のコードやマイグレーションをAIに提案してもらう際に `@MySQLSchema` と付け加えると、スキーマを踏まえた正しいJOINやINSERT文などが期待できる

1.4 Notepadsのメリット・注意点

メリット

  • 呼び出しが簡単: @Notepad名 で好きな時に追加文脈を与えられる
  • 柔軟な文書: Markdownで長文、付随ファイル添付、コードブロックなど何でも書ける
  • セッションをまたぐ知識共有: Composer/Chat間で繰り返し参照できる
  • テンプレ化: 繰り返し使う指示文や設定をテンプレとして保管可能

注意点

  • チーム共有には向かない: Notepadsは基本ローカル保存のため、チームで同じNotepadを使いたい場合は手動でインポート/エクスポートが必要
  • 手動呼び出しが必要: 常に自動参照されないので、つい呼び出しを忘れるとAIが文脈を把握しない
  • 大容量Notepadはトークンを圧迫: 不要に大きい内容をまとめるとAIが混乱やトークン制限に引っかかる恐れがある

2. Project Rules の概要と使い方

2.1 Project Rulesとは？

Project Rules は .cursor/rules/ ディレクトリ配下に Markdown形式のルールファイルを置き、特定のファイルパターンや状況で自動適用される仕組みです。

v0.45以降で導入され、従来の.cursorrulesをさらに細分化・強化した形式といえます。

主なポイント

  • Globsで適用対象を指定: たとえば Globs: **.go と書けばGoファイルに限って適用される。これにより言語やフォルダ単位で異なる規約をセット可能
  • ルール本文はMarkdown: “Description”や”Globs”のYAMLフロントマターを先頭に書き、その下に具体的なコーディング規約や設計ポリシーを箇条書きで記述する
  • 自動的にコンテキスト追加: 該当ファイルを編集・生成するとき、CursorがこのルールのMarkdownをLLMに渡してくれる
  • 参照ファイルチェーン: ルール本文中に @somefile.md と書けば、さらにそのファイル内容もAIに追加できる

2.2 Project Rulesの特長: ファイルパターンによる自動適用ルール

Notepadsは手動で呼び出すのに対し、Project RulesはCursorがプロジェクト内の操作状況を見て必要なルールを自動適用してくれます。

つまり「Goファイルを編集している」というだけでGo向けの規約やコーディングスタイルがAIに注入されるわけです。ユーザーが毎回 @GolangGuidelines と書く手間がなく、チームメンバーもこの仕組みを恩恵として受けられます。

2.3 具体的な設定例（Go言語/DDD/オニオン/DB操作など）

(1) Go言語ファイル専用ルール



---
Description: Go Code Convention
Globs: **/*.go
---
# Go Guidelines
- Use only the standard library plus well-reviewed packages
- Avoid global variables; prefer explicit DI
- Test files with `_test.go`
- Keep lines under 100 characters

@go-architecture.md


この .mdc ルールファイルを .cursor/rules/go-code.mdc として作成。
Globs: **/*.go により全Goファイル編集時に適用され、「Go Guidelines」の内容がコンテキストに入り、
さらに @go-architecture.md と記述したファイルも連動して読み込まれます。




(2) DDD/オニオンアーキテクチャ




---
Description: DDD + Onion Architecture
Globs: internal/domain/**/*.go
---
## DDD Domain Rules

- No imports from `infra/` or `app/` in `domain/`
- Entities + Value Objects must be pure logic
- Aggregates hold invariants

@onion_layers.md



Globs: internal/domain/**/*.go でドメイン層にのみ適用。オニオンアーキテクチャの原則（他レイヤーへの依存禁止など）を記述しておくことで、AIがドメインコードを編集するときに自動でこれを踏まえた提案を行う。


(3) MySQLのマイグレーション用ルール






---
Description: MySQL Migration Best Practices
Globs: db/migrations/**/*.sql
---
# MySQL Migration Rules
- Table names are lowercase, snake_case, plural
- Always include `created_at` and `updated_at` columns
- Index foreign keys to avoid performance issues
- Use `utf8mb4` charset







Globs: db/migrations/**/*.sql なので、SQLマイグレーションファイルを編集する際にこのルールを読み込み、命名規則やカラム必須などを意識してくれる。「外部キーにはインデックスが必要」という点もAIはコード提案・レビュー時にチェックしてくれる可能性がある。


2.4 Project Rulesのメリット・注意点


メリット


    

  • 自動適用: 特定のファイルやディレクトリ操作時にルールが勝手に読み込まれる。ユーザーが毎回 @ しなくてもよい
    • 

  • 細かな適用範囲指定 (Globs): ファイルの種類や場所ごとに異なる規則を与えられる
    • 

  • チーム共有が容易: ルールファイルはプロジェクトに含まれGit管理されるため、全メンバーが同じAIルールを得る
    • 

  • コードの一貫性維持: 開発規約やアーキテクチャ指針を明確化・自動化できる
    • 



注意点


    

  • ルール本文を大量に書きすぎない: コンテキストウィンドウ圧迫によるトークン消費増大を招く
    • 

  • ユーザーが見落とす可能性: ルールは自動適用ゆえ、何が適用されているか分かりにくい場合がある
    • 

  • 細分化しすぎ: ファイルパターンを大量に作ると管理が複雑になる
    • 

  • 手動で呼び出したい文脈には不向き: たとえば「今回だけ特別仕様を参照したい」といった場面ではNotepadsの方が合う
    • 



3. NotepadsとProject Rulesの比較


両者はAIへの「追加文脈を与える」手段ですが、使いどころや適用タイミングに大きな違いがあります。


    

  1. 

    適用タイミング
    

      

    • Notepads: @Notepad名 を明示しない限り適用されない
      • 

    • Project Rules: 該当するファイル・パターンを編集するとき自動適用される
      • 

    

    2. 

  2. 

    想定ユースケース
    

      

    • Notepads: “随時参照する大部のドキュメント・メモ”、個人利用の注意書き、都度呼び出したいテンプレなど
      • 

    • Project Rules: “プロジェクト内の全員で共有すべきコーディング規約や設定”、特定のファイル種別にいつも適用したいルールなど
      • 

    

    3. 

  3. 

    チーム共有の有無
    

      

    • Notepads: ローカル環境のファイルとして扱われ、Git共有はされない
      • 

    • Project Rules: .cursor/rules/配下に置くため、リポジトリとともに共有可能
      • 

    

    4. 

  4. 

    ベータか標準か
    

      

    • Notepads: ベータ機能（将来仕様変更の可能性あり）
      • 

    • Project Rules: Cursor公式が現行標準として推奨（旧 .cursorrules の発展形）
      • 

    

    5. 

  5. 

    ファイル構造
    

      

    • Notepads: GUIベースで作成し、内容は自由度が高い Markdown
      • 

    • Project Rules: 基本的にテキストエディタで.mdcファイルを編集し、YAMLフロントマター+本文の形式
      • 

    

    6. 



4. 効果的な使用事例とワークフローへの組み込み


4.1 Composerやチャットとの連携


CursorではチャットモードとComposerモードを使い分けることが多いです。以下のようなワークフローが典型的な例です。


    

  1. チャットモードで相談

      

    • 新機能の概要や要件をAIに説明し、追加仕様を検討
      • 

    • Notepadにそのときの内容（結論やTODO）をまとめておく
      • 

    

    2. 

  2. Composerモードで実装

      

    • 該当するProject Rules（言語・フォルダ別規約など）が自動適用される
      • 

    • 必要に応じて、先ほど作成したNotepadを @ で呼び出し、検討時に出た決定事項をAIに参照させる
      • 

    

    3. 

  3. 他のチームメンバーもProject Rulesを自動適用

      

    • 統一的なコーディング規約で開発を進め、レビュー効率を上げる
      • 

    

    4. 



Notepadsが “チャット→実装” での知識橋渡しとして役立ち、Project Rulesが “常に守るべき共通ルール” を維持してくれます。


4.2 チーム開発でのガイドライン共有


チーム全体で同じAIルールを使用するなら、Project Rules が最適です。例えばゴールデンルール：


    

  • “DDDドメイン層はインフラ層を参照しない”
    • 

  • “Goファイルは100行を超えたら分割推奨”
    • 

  • “SQLマイグレーションは必ずテーブル名をsnake_caseに”
    • 



などを .cursor/rules/*.mdc として書いておけば、新メンバーが参加してもすぐAIが同じ基準でコードを提案してくれます。


一方、個人レベルで参照したいアーキテクトメモや具体的実装サンプルはNotepadsにまとめ、必要な時だけ呼び出すといった二段構えが便利です。


4.3 コードレビュー支援・エラー削減


    

  • Notepadsで 「レビュー観点チェックリスト」 を用意
    • 

  • Project Rulesで 「特定のファイル編集時のルール」 を定義
    • 



たとえば “DB操作のたびにSQLインジェクション対策を確認” などをProject Rulesに書いておけばAIが自動でコールアウトし、さらに “セキュリティチェック項目” のNotepadを参照して「具体的にどう対策すべきか？」を提示させる、という流れが自然に実現します。半自動的なレビューが回り、人的見落としを減らす効果が期待できます。


4.4 エージェントモードとの併用


Cursorのエージェントモードは自動でファイルを修正・実行まで行う高度な機能ですが、Project Rulesと組み合わせると、さらに安全性・的確さが増します。


    

  • ルールで “変更前にテストを走らせる” “Infrastructureコードはドメイン層に触れない” などを書いておくと、エージェントが暴走的に改変するのを防ぎやすくなる
    • 

  • Notepadsで “自動作業の手順書” を用意し、エージェントに @AutoDeploymentSteps を参照させてビルド→テスト→デプロイを半自動化する
    • 



このように2つの機能をエージェントに活用させれば、高度な自動化フローを実践可能です。


5. まとめ


Cursor AIエディタの Notepads と Project Rules は、共に「AIへの追加文脈を与える」ための重要な機能ですが、性質が大きく異なります。


    

  • 

    Notepads:
    

      

    • 能動的呼び出し(手動@)
      • 

    • 個人のドキュメント置き場、都度参照したいテンプレ
      • 

    • Markdown記述・ファイル添付OK
      • 

    • チーム共有は自動ではないが大部の資料もOK
      • 

    

    • 

  • 

    Project Rules:
    

      

    • 自動適用(Globsマッチ)
      • 

    • チーム共有前提、リポジトリ管理
      • 

    • 簡潔な規約や設計指針を書くのに向く
      • 

    • 特定ファイル/フォルダ操作時に常時アクティブ
      • 

    

    • 



両者を併用すると、大規模プロジェクトでのドメイン駆動設計やオニオンアーキテクチャを反映した知識をAIと共有でき、Go言語の規約やMySQLの使用方針なども適切に守りながらコード生成・レビューができます。


チーム開発なら、共通規約はProject Rules、個人のメモや仕様書はNotepadsでサポートする、という使い分けが理想的です。


また、Composerやエージェントモードでコードを自動生成・修正する際に不必要な変更を行わせないようProject Rulesにルールを入れたり、Notepadsにセキュリティチェックリストを入れることでレビューをAIに補助させるなど、多彩なワークフローが考えられます。


総じて、Notepadsは「AIと都度共有したい文書の保管庫」、Project Rulesは「特定状況で常に適用される規則」として位置付けるとわかりやすいでしょう。


以下にまとめると：


    

  1. ドキュメント性の高い大部の資料や個人的な作業テンプレはNotepadsで管理
    2. 

  2. チーム共通のコーディング規約やアーキテクチャ指針はProject Rulesで自動適用
    3. 

  3. 大規模になるほどProject Rulesが重要になり、細かなファイルパターンで規則を分割できる
    4. 

  4. Notepadsはファイル添付もできるため、大量のコード例やDBスキーマなどをまとめられるが、チーム共有には一手間必要
    5. 



どちらもCursor AIの生産性を高める強力な仕組みです。プロジェクトやチームの状況に合わせて効果的に使い分け、AIをより賢くプロジェクト固有の知識で武装させることで、コード提案・レビュー・ドキュメント化まで一貫した効率を実現できるでしょう。


6. 参考文献・ドキュメント一覧



以上の資料を参考にまとめました。



本記事がCursorでNotepadsやProject Rulesを本格的に活用したい方の助けとなれば幸いです。ぜひ自分のプロジェクトに合わせて2つの機能を使い分け、より効率的かつチーム/アーキテクチャに適したAI支援を実現してください。



































									
																		
									
									
 cursor
									
									
									
									



										
				

					
					

						
						


					

					

						
						


					

					

				

						

									
																		

																		
																			

																		
									

															
								

							

						

						
														

				
								
																
								




		

		
RELATED POST