Cursor Rules をプロジェクト別に使い分ける実践設定【2025年版】

結論：Rules はプロジェクトルートに置き、スコープを絞るのが最速

Cursor の AI コーディング精度を上げる最短ルートは、プロジェクトルートに .cursor/rules/ を置いてスタック別に分割することです。「とりあえず .cursorrules に全部書いた」まま運用しているなら、今すぐ見直す価値があります。

2025年現在、Cursor は旧来の .cursorrules（単一ファイル）に加えて、**.cursor/rules/ ディレクトリ配下の複数ファイル（.mdc 形式）**をサポートしています。後者はファイルパターンや適用タイミングを細かく制御できるため、モノレポや複数スタックの混在プロジェクトで特に有効です。

`.cursorrules` と `.cursor/rules/` の違い

項目	`.cursorrules`（旧）	`.cursor/rules/*.mdc`（推奨）
ファイル数	1ファイル	複数ファイルに分割可
適用スコープ	プロジェクト全体	ファイルパターンで絞り込み可
優先度制御	不可	`priority` で制御可
チーム共有	Git で共有可	Git で共有可
個人専用設定	不可（全員に適用）	`.gitignore` で除外可能

注意： .cursorrules は現時点でも動作しますが、公式ドキュメントでは .cursor/rules/ への移行が推奨されています。新規プロジェクトでは最初から .cursor/rules/ を使いましょう。

ディレクトリ構成の設計パターン

基本構成（単一スタック）

my-app/
├── .cursor/
│   └── rules/
│       ├── general.mdc       # プロジェクト共通ルール
│       ├── typescript.mdc    # TS全般
│       └── nextjs.mdc        # Next.js固有
├── src/
└── package.json

モノレポ構成（apps / packages 分割）

monorepo/
├── .cursor/
│   └── rules/
│       ├── common.mdc
│       ├── frontend.mdc      # apps/web/** に適用
│       └── backend.mdc       # apps/api/** に適用
├── apps/
│   ├── web/
│   └── api/
└── packages/

サンプル Rules ファイル集

1. TypeScript 共通（`typescript.mdc`）

---
description: TypeScript全般のコーディングルール
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

# TypeScript Rules

- `any` 型は原則禁止。どうしても必要な場合は `// eslint-disable-next-line` コメントと理由を必ず書く
- 関数の戻り値型は明示する（`void` も含む）
- `interface` より `type` を優先する（ただし `extends` が必要な場合は `interface` を使う）
- `as` キャストは型ガードで代替できないか先に検討する
- エラーハンドリングは `Result` 型パターンか、`unknown` で受けて型絞り込みを行う

2. Next.js App Router（`nextjs.mdc`）

---
description: Next.js App Router プロジェクトのルール
globs: ["apps/web/**/*.tsx", "apps/web/**/*.ts"]
alwaysApply: false
---

# Next.js App Router Rules

## コンポーネント方針
- デフォルトは Server Component。クライアント機能が必要な場合のみ `"use client"` を付与する
- `"use client"` を付けるのは末端の Leaf Component に留め、境界をできるだけ下げる

## データフェッチ
- `fetch` は Server Component 内で直接呼び出す。`useEffect` でのフェッチは原則禁止
- `cache()` や `unstable_cache()` を積極的に使い、重複リクエストを防ぐ

## ルーティング
- ページファイルは `page.tsx`、レイアウトは `layout.tsx` に限定
- 動的ルートは `[slug]` 形式。catch-all は `[...slug]`

## スタイリング
- Tailwind CSS を使用。インラインスタイルは禁止
- クラス名の順序: レイアウト → スペーシング → 色 → その他

3. Hono（APIサーバー向け）（`hono.mdc`）

---
description: Hono を使ったAPIサーバーのルール
globs: ["apps/api/**/*.ts", "src/routes/**/*.ts"]
alwaysApply: false
---

# Hono API Rules

## ルーティング
- ルートは機能ドメインごとにファイルを分割し、`app.route()` でマウントする
- パスパラメータのバリデーションは必ず `zValidator` で行う

## レスポンス
- 成功時: `c.json({ data: ... }, 200)`
- エラー時: `c.json({ error: { code: string, message: string } }, status)`
- 共通エラーハンドラを `app.onError()` で定義する

## 型安全
- `hono/client` を使ってフロントエンドと型を共有する
- `Env` 型を `c.env` から取り出し、環境変数はすべて型定義する

## 例
\`\`\`typescript
// NG: バリデーションなし
app.post('/users', async (c) => {
  const body = await c.req.json()
  ...
})

// OK: zValidator でスキーマ検証
app.post('/users', zValidator('json', createUserSchema), async (c) => {
  const body = c.req.valid('json')
  ...
})
\`\`\`

4. チーム開発向け共通ルール（`general.mdc`）

---
description: チーム共通のコーディング規約
alwaysApply: true
---

# Team General Rules

## コメント・ドキュメント
- 関数には JSDoc を書く（引数・戻り値・throws を記載）
- 「なぜ」そうしたかの理由コメントを書く。「何をしているか」はコードを読めばわかる

## コミット
- コミットメッセージは Conventional Commits 形式: `feat:` / `fix:` / `chore:` など
- 1コミット1変更。複数の変更を混ぜない

## PR / レビュー
- 変更差分は 400 行以内を目安にする
- セルフレビューチェックリストをPR本文に含める

## 禁止事項
- `console.log` を本番コードに残さない（デバッグ後は必ず削除）
- ハードコードされた認証情報・シークレットを絶対にコミットしない

チーム開発での運用ベストプラクティス

Git 管理方針

.cursor/rules/ 配下のファイルは基本的に全員 Git 管理します。これにより「AIへの指示書」がチームの共有資産になります。

ただし、個人の好みによるスタイル設定（コメントを日本語で書くか英語で書くか、など）は個人用に分離したい場合もあります。その場合は：

# .gitignore に個人用 rules を除外
.cursor/rules/personal/

のようにサブディレクトリで分けるとスマートです。

`alwaysApply` の使い分け

設定	用途
`alwaysApply: true`	チーム規約・セキュリティ禁止事項など全員に常時適用したいルール
`alwaysApply: false`	特定スタック専用。`globs` でスコープを絞る

alwaysApply: true の rules が多すぎると AI へのコンテキスト注入量が増え、レスポンスが遅くなることがあります。必要最小限に絞るのがコツです。

Rules の育て方

Rules は「一度書いて終わり」ではなく、コードレビューで指摘が出るたびに育てるものです。以下のフローが実践的です。

PR レビューで「AI がよく間違えるパターン」を発見
.cursor/rules/ に禁止パターンと推奨パターンを追記
次回から AI が同じミスをしにくくなる

個人開発での設定ミニマム構成

個人開発で「とりあえず効果を感じたい」なら、以下の 1 ファイルから始めるのが現実的です。

---
description: 個人開発プロジェクトの基本ルール
alwaysApply: true
---

# My Project Rules

## 技術スタック
- TypeScript (strict mode)
- Next.js 15 App Router
- Prisma + PostgreSQL
- Tailwind CSS v4

## コーディング方針
- 関数は 30 行以内を目安に分割する
- 変数名は省略しない（`e` → `event`、`res` → `response`）
- マジックナンバーは定数に切り出す

## このプロジェクト固有の注意
- 認証は NextAuth.js v5 を使用。独自実装しない
- DB アクセスは必ず `lib/db.ts` の Prisma クライアントを使う
- `app/api/` 以下のルートは tRPC に移行中。新規エンドポイントは tRPC で作る

スタックと「プロジェクト固有の注意」を書くだけで、AI が毎回的外れな提案をする問題が大幅に減ります。

📚 おすすめ書籍

GitHub Copilot & Cursor AI コーディング実践入門

AIツールの使いこなしを体系的に学びたい方に

Amazonで見る →

まとめ

やること	効果
`.cursor/rules/` に移行する	スコープ制御ができチーム共有も容易
`alwaysApply` を絞る	コンテキスト肥大化を防ぐ
スタック別にファイル分割	関係ない指示が混入しない
NG/OK 例をセットで書く	AI が意図を誤解しにくくなる
レビュー指摘をルール化する	Rules が組織の知見として蓄積される

Cursor Rules を「書き捨て」にせず、チームの学習とともに育てていくと、AI コーディングの精度は継続的に上がり続けます。まずは今日のプロジェクトに general.mdc 1 枚追加するところから始めてみてください。