Cursor の .cursor/rules でプロジェクトのコーディング規約をAIに覚えさせた話

👀 結論から

Cursor には .cursor/rules というディレクトリにルールファイルを置くことで、AIにプロジェクト固有のコーディング規約を事前に覚えさせる仕組みがあります！

設定してから、「コンポーネントの命名はPascalCaseで…」「型アサーションは使わないで…」と毎回お願いしなくてよくなりました(^^)

AIが最初からプロジェクトのルールを把握した状態でコードを書いてくれるので、レビューで指摘されるパターンが明らかに減っています！

💡 .cursor/rules とはなにか

.cursor/rules は、Cursor のプロジェクトルートに作成するディレクトリです。

ここに .mdc 形式のルールファイルを置いておくと、AIがコードを生成・修正するときに自動でそのルールを参照してくれます(・∀・)

以前は .cursorrules というプロジェクトルート直下のファイル1枚で管理していましたが、.cursor/rules ではルールをファイルごとに分割して管理できるようになりました！

各ルールファイルには frontmatter で「いつ適用するか」を指定できます。

---
description: TypeScriptのコーディング規約
globs:
  - "**/*.ts"
  - "**/*.tsx"
alwaysApply: false
---

globs で対象ファイルを絞り込んだり、alwaysApply: true にして常に適用させたりできます(^_^)

Claude Code の CLAUDE.md と発想が似ていますが、こちらは Cursor 専用の機能です。

👍 実際に設定しているルールの例

私が仕事のプロジェクトで設定しているルールを3つ紹介します！

1. TypeScript 規約（typescript.mdc）

TypeScript 固有のルールをまとめています(^^)

## TypeScript コーディング規約

- `any` 型の使用を禁止。代わりに `unknown` を使うこと
- 型アサーション（`as`）は最終手段。型ガードを優先する
- `interface` より `type` を優先する
- 非同期関数は必ず `async/await` を使い、Promise チェーンは避ける
- 配列型は `Array<T>` より `T[]` を優先する

これを設定してから、AIが as any を使ったコードを出力してくることがほぼなくなりました！

2. React コンポーネント規約（react.mdc）

コンポーネントの書き方に統一感を出すためのルールです(｀・ω・´)

## React コンポーネント規約

- コンポーネント名は PascalCase
- Props の型定義はコンポーネントの直上に書く
- `useState` の初期値には型を明示する
- コンポーネントは 100 行を超えたら分割を検討する
- デフォルトエクスポートを使う（名前付きエクスポートは避ける）

「デフォルトエクスポートで」と毎回言わなくてよくなったのがかなり便利です(^^)

3. ファイル構成規約（structure.mdc）

ファイルの配置場所や命名規則です！

## ファイル構成

- コンポーネント: `src/components/`
- カスタムフック: `src/hooks/`（ファイル名は `use` から始める）
- 型定義: `src/types/`
- ユーティリティ関数: `src/utils/`
- 新しいファイルを作るときはこの構成に従うこと

AIが新しいファイルを作るとき、どこに置くかを勝手に判断してくれるようになりました(^^;)

✨ 使い始めてからの変化

一番大きかった変化は、コードレビューで指摘するパターンが減ったことです！

以前はレビューで「as any は使わないで」「デフォルトエクスポートにして」と同じコメントを繰り返していましたが、AIが最初からルールを守ったコードを出力してくれるので指摘頻度が体感で3割ほど減りました(^^)

また、チームメンバーがAIに実装をお願いしたときも、ルールが反映されたコードが生成されるようになりました。

「AIが出したコードがプロジェクトの規約と違う」という摩擦がかなり減っています！

ルールファイルが .cursor/rules/ に整理されているおかげで、「このプロジェクトのルールって何だっけ」というときにすぐ確認できるのも、さりげなく助かっています(^^)

さらに、ルールをファイル分割できるので「TypeScript 用」「React 用」「テスト用」と関心ごとに整理できます。

一枚の .cursorrules に全部書いていた頃より、メンテナンスがかなりしやすくなりました！

🤔 気になった点

ひとつ注意点として、ルールが複雑になりすぎると AI がすべてを守れないことがあります(・_・;)

ルールは短く、具体的に書いた方が守られやすい印象です。「なるべく〜する」より「必ず〜する」「〜は禁止」のように断定的に書くと精度が上がります！

また、alwaysApply: true にすると全会話に適用されてコンテキストが増えるので、あまり多くのルールに設定しすぎない方がいいです(^^;)

ファイル数が増えてきたときは globs でしっかり対象を絞り込むと、関係ないファイルを編集するときにルールが邪魔になりません！

📂 ディレクトリごとにルールを分ける運用に変えた

3つのルールファイルで運用していたんですが、フロントエンドとバックエンドが同居しているモノレポ構成のプロジェクトで、「共通ルール」と「ディレクトリ固有ルール」を分ける運用に変えたら一段と快適になりました。

Cursor は .cursor/rules をプロジェクトルートだけでなく、各サブディレクトリにも個別に置ける仕様になっています。

より深い階層（具体的なディレクトリ）に置いたルールの方が優先される仕組みなので、私は次のように分けています。

.cursor/rules/          # プロジェクト全体の共通ルール
frontend/.cursor/rules/ # フロントエンド固有（React・Tailwindなど）
backend/.cursor/rules/  # バックエンド固有（API設計・DB命名など）

フロントエンドを触っているときはフロントエンド固有のルールだけが適用されて、バックエンドのルールでコンテキストが無駄に膨らまなくなったのが大きいです(^^)

もうひとつ意識するようになったのが、「同じ指摘を2回した」ときだけルール化するという運用ルールです。

最初から完璧なルールセットを作ろうとすると膨大になってしまうので、実際にレビューで繰り返し指摘したパターンだけを都度 .mdc に追記していく方が、結果的にルールが筋肉質なまま保てると気づきました。

複数プロジェクトで同じルールを使い回したいときは、シンボリックリンクで1つのルールファイルを共有する方法もあるので、チームで横断的に統一したいルール（コミットメッセージの書き方など）はそちらにまとめています！

パパ系Webエンジニア〜愛用ガジェット一覧 🛍️

AI開発・執筆に使っている作業デスク環境を楽天ROOMにまとめています ✨ デスク周りの参考にどうぞ 🙌

🙌 まとめ

Cursor の .cursor/rules、まだ設定していない方にはぜひ試してみてほしいです！

ルールをファイル分割して関心ごとに整理できる
globs で対象ファイルを絞り込み、必要な場面だけ適用できる
毎回お願いしなくても、AIが最初からプロジェクトルールを守ってくれる

コードレビューで繰り返し指摘していたパターンがかなり減って、チーム全体の開発体験が上がった実感があります(^o^)/

設定自体は数分でできるので、Cursor をメインエディタとして使っている方はぜひ試してみてください🎉