Cursor Rules の書き方ガイド — プロジェクト別テンプレート・ベストプラクティス・CLAUDE.md比較【2026年版】

Cursor Rules とは — AI に「プロジェクトのルール」を伝える仕組み

「Cursorに何度も同じ指示を繰り返していませんか？」 Cursor Rules を正しく書くだけで、AIがプロジェクトのコーディング規約やアーキテクチャを理解した状態でコードを生成してくれます。

Cursor Rules は、AI コーディングエディタ「Cursor」に対してプロジェクト固有のルールや文脈を伝えるための設定ファイルです。Cursorの基本的な使い方は「Cursor完全ガイド」で解説しています。プロジェクトのルートに配置することで、Cursor のAI機能（Tab補完、Chat、Agent Mode）すべてに適用されます。

Cursor Rules が解決する問題

• コーディング規約の不一致: AIが生成するコードがプロジェクトの規約と異なる
• 毎回の説明コスト: 「TypeScriptを使って」「テストはVitestで」と繰り返し指示する手間
• チーム内のAI体験のバラつき: メンバーごとに異なるプロンプトを使っている
• 不適切なライブラリの提案: プロジェクトで使っていないライブラリをAIが提案する

---

Cursor Rules のファイル構成 — 2つの配置方法

Cursor Rules には、プロジェクト全体に適用するルールと、特定のファイルパターンに適用するルールの2種類があります。

方法1: .cursor/rules/ ディレクトリ（推奨）

2025年後半から導入された新しい形式で、複数のルールファイルを分割して管理できます。

project-root/
├── .cursor/
│   └── rules/
│       ├── general.mdc       # プロジェクト全体のルール
│       ├── frontend.mdc      # フロントエンド固有のルール
│       ├── backend.mdc       # バックエンド固有のルール
│       └── testing.mdc       # テスト固有のルール
├── src/
└── package.json

.mdc ファイルの基本構成は以下のとおりです。

---
description: "フロントエンドのコーディングルール"
globs: ["src/components/**", "src/pages/**"]
alwaysApply: false
---

# フロントエンドルール

- React関数コンポーネントのみ使用する
- styled-componentsではなくTailwind CSSを使う
- コンポーネントはnamed exportにする

方法2: .cursorrules ファイル（レガシー）

プロジェクトルートに直接配置する従来の方法です。シンプルですが、ファイルが大きくなりやすいデメリットがあります。

project-root/
├── .cursorrules    # プロジェクトルートに配置
├── src/
└── package.json

.mdc ファイルの frontmatter オプション

オプション	型	説明
description	string	ルールの説明（AIがルール選択の参考にする）
globs	string[]	適用対象のファイルパターン
alwaysApply	boolean	常に適用するかどうか（true=全ファイルに適用）

💡 Tips: globs を指定すると、そのパターンに一致するファイルを編集するときだけルールが適用されます。フロントエンドとバックエンドでルールを分けたい場合に便利です。

---

基本的な書き方 — 効果的な Cursor Rules の構成

必須で書くべき項目

効果的な Cursor Rules には、以下の5つの要素を含めましょう。

# プロジェクト概要
このプロジェクトは Next.js 15 (App Router) で構築された
Webアプリケーションです。

# 技術スタック
- フレームワーク: Next.js 15 (App Router)
- 言語: TypeScript 5.x (strict mode)
- スタイリング: Tailwind CSS v4
- 状態管理: Zustand
- データフェッチ: TanStack Query v5
- テスト: Vitest + Testing Library
- パッケージマネージャー: pnpm

# コーディング規約
- 関数コンポーネントのみ使用（クラスコンポーネント禁止）
- named export を優先する
- any型の使用禁止
- マジックナンバー禁止（定数として定義する）

# ディレクトリ構造
src/
├── app/          # Next.js App Router
├── components/   # UIコンポーネント
│   ├── ui/       # 汎用UIパーツ
│   └── features/ # 機能別コンポーネント
├── hooks/        # カスタムフック
├── lib/          # ユーティリティ
├── types/        # 型定義
└── styles/       # グローバルスタイル

# やってはいけないこと
- node_modules/ の内容を参照しない
- .env ファイルの内容を出力しない
- console.log をプロダクションコードに残さない

書き方のコツ

1. 具体的に書く: 「きれいなコードを書いて」ではなく「変数名はキャメルケース、定数はアッパースネークケース」
2. 例を示す: ルールだけでなく、良い例と悪い例を併記する
3. 優先順位をつける: 矛盾するルールがあった場合の優先順位を明記する
4. 短く保つ: 長すぎるとAIが重要な部分を見落とす可能性がある

---

プロジェクト別テンプレート

Next.js (App Router) プロジェクト

---
description: "Next.js App Router プロジェクトのルール"
alwaysApply: true
---

# Next.js App Router プロジェクト

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

## ルーティング規約
- ファイルベースルーティングを使用
- ページコンポーネントは default export
- レイアウトは layout.tsx に定義
- ローディング状態は loading.tsx
- エラーハンドリングは error.tsx

## データフェッチ
- Server Components でのデータフェッチを優先
- クライアントサイドは TanStack Query を使用
- API Routes は app/api/ に配置

## コンポーネント設計
- Server Components をデフォルトとする
- "use client" は必要な場合のみ追加
- Props の型はコンポーネントファイル内で定義

## 例
```typescript
// ✅ Good: Server Component
export default async function UsersPage() {
  const users = await getUsers();
  return <UserList users={users} />;
}

// ❌ Bad: 不要な "use client"
"use client";
export default function StaticPage() {
  return <div>Static content</div>;
}

### Python (FastAPI) プロジェクト

```markdown
---
description: "Python FastAPI プロジェクトのルール"
alwaysApply: true
---

# Python FastAPI プロジェクト

## 技術スタック
- Python 3.12+
- FastAPI
- SQLAlchemy 2.x (async)
- Pydantic v2
- pytest + pytest-asyncio

## コーディング規約
- 型ヒントを必ず使用する
- docstring は Google スタイル
- import は isort の設定に従う
- フォーマッターは ruff を使用

## ディレクトリ構造
app/
├── api/          # エンドポイント定義
│   └── v1/
├── core/         # 設定、セキュリティ
├── models/       # SQLAlchemy モデル
├── schemas/      # Pydantic スキーマ
├── services/     # ビジネスロジック
└── repositories/ # データアクセス層

## APIエンドポイント規約
- エンドポイントは /api/v1/ プレフィックス
- レスポンスは Pydantic モデルで型定義
- エラーは HTTPException で返す
- 認証は Depends() で注入

## 例
```python
# ✅ Good
@router.get("/users/{user_id}", response_model=UserResponse)
async def get_user(
    user_id: int,
    service: UserService = Depends(get_user_service),
) -> UserResponse:
    """ユーザー情報を取得する。"""
    return await service.get_by_id(user_id)

### Go プロジェクト

```markdown
---
description: "Go プロジェクトのルール"
alwaysApply: true
---

# Go プロジェクト

## 技術スタック
- Go 1.22+
- Echo v4 (Webフレームワーク)
- sqlc (SQLコード生成)
- golang-migrate (マイグレーション)

## コーディング規約
- Effective Go に従う
- エラーは必ずハンドリングする（_ で無視しない）
- インターフェースは利用側で定義する
- パッケージ名は短く、小文字のみ

## ディレクトリ構造（Standard Go Project Layout）
cmd/
├── api/          # メインアプリケーション
internal/
├── handler/      # HTTPハンドラー
├── service/      # ビジネスロジック
├── repository/   # データアクセス
├── model/        # ドメインモデル
└── middleware/    # ミドルウェア
pkg/              # 外部公開パッケージ

## エラーハンドリング
- カスタムエラー型を定義して使う
- errors.Is() と errors.As() で判定する
- エラーメッセージは小文字で始める

React Native プロジェクト

---
description: "React Native (Expo) プロジェクトのルール"
alwaysApply: true
---

# React Native (Expo) プロジェクト

## 技術スタック
- React Native (Expo SDK 52)
- TypeScript
- Expo Router (ファイルベースルーティング)
- NativeWind (Tailwind for RN)

## コーディング規約
- 関数コンポーネントのみ
- StyleSheet.create() ではなく NativeWind を使用
- Platform.select() でプラットフォーム分岐
- アニメーションは Reanimated を使用

## ナビゲーション
- Expo Router のファイルベースルーティングを使用
- Stack、Tabs、Drawer はレイアウトファイルで定義

---

ベストプラクティス — Cursor Rules を最大限活かす

1. ルールは分割して管理する

1つの巨大なルールファイルより、役割ごとに分割した方が効果的です。

.cursor/rules/
├── general.mdc       # alwaysApply: true（全体ルール）
├── frontend.mdc      # globs: ["src/components/**"]
├── api.mdc           # globs: ["src/app/api/**"]
├── database.mdc      # globs: ["prisma/**", "src/lib/db/**"]
└── testing.mdc       # globs: ["**/*.test.ts", "**/*.spec.ts"]

2. 具体的なコード例を含める

ルールだけでなく、期待するコードの例を示しましょう。

## エラーハンドリング

Result型パターンを使用してエラーを処理する。

```typescript
// ✅ Good: Result型パターン
type Result<T, E = Error> = { ok: true; value: T } | { ok: false; error: E };

function parseConfig(raw: string): Result<Config> {
  try {
    const config = JSON.parse(raw);
    return { ok: true, value: config };
  } catch (e) {
    return { ok: false, error: new Error("Invalid config") };
  }
}

// ❌ Bad: try-catchの乱用
function parseConfig(raw: string): Config {
  try {
    return JSON.parse(raw);
  } catch {
    return {} as Config; // 型安全性が失われる
  }
}

### 3. 禁止事項を明記する

AIが「やってしまいがち」なパターンを明示的に禁止しましょう。

```markdown
## 禁止事項
- `any` 型の使用禁止（`unknown` を使って型ガードする）
- `// @ts-ignore` の使用禁止
- `console.log` をプロダクションコードに残さない
- `!important` をCSSで使わない
- 相対パスの import（`../../../`）は `@/` エイリアスを使う
- `var` の使用禁止（`const` / `let` を使う）

4. 定期的に見直す

プロジェクトの進化に合わせて、ルールも更新しましょう。

<!-- ルール管理のヒント -->
## 更新履歴
- 2026-04-01: Tailwind CSS v4 に対応、v3の記法を禁止
- 2026-03-15: テストフレームワークを Jest → Vitest に変更
- 2026-03-01: 初版作成

---

CLAUDE.md との比較 — Cursor Rules と何が違う？

Claude Code にも同様の仕組みとして CLAUDE.md があります。CLAUDE.mdの詳しい書き方は「CLAUDE.md 完全ガイド」を参照してください。ここでは両者の違いを整理します。

基本的な違い

項目	Cursor Rules	CLAUDE.md
対象ツール	Cursor	Claude Code
ファイル形式	.mdc / .cursorrules	.md
配置場所	.cursor/rules/	プロジェクトルート or .claude/
グローバル設定	Cursor設定画面で管理	~/.claude/CLAUDE.md
ファイルパターン指定	globs で指定可能	なし（手動で記述）
自動読み込み	ファイルパターンで自動適用	セッション開始時に読み込み

書き方の違い

# Cursor Rules (.mdc)
---
description: "TypeScriptのコーディングルール"
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

## ルール
- strict mode を有効にする
- any型を禁止する

# CLAUDE.md
## TypeScript ルール
- strict mode を有効にする
- any型を禁止する
- このルールは .ts, .tsx ファイルに適用

両方使う場合のアドバイス

Cursor と Claude Code を両方使っている場合、ルールの内容を同期させることが重要です。

# 同期スクリプトの例
# .cursor/rules/ の内容を CLAUDE.md に反映
cat .cursor/rules/*.mdc > /tmp/cursor-rules.md
echo "以下はCursor Rulesから同期したルールです:" >> CLAUDE.md
cat /tmp/cursor-rules.md >> CLAUDE.md

💡 Tips: 手動で同期するのが面倒な場合は、共通のルールを1つのファイルに書いて、Cursor Rules と CLAUDE.md の両方から参照する方法もあります。

---

トラブルシューティング

ルールが適用されない場合

1. ファイルの配置場所を確認: .cursor/rules/ ディレクトリに正しく配置されているか
2. globs パターンを確認: 対象ファイルにマッチしているか
3. Cursorを再起動: 設定変更後はCursorの再起動が必要な場合がある
4. frontmatter の構文確認: YAML形式が正しいか確認する

ルールが競合する場合

複数のルールファイルが同じファイルに適用される場合、すべてのルールが結合されます。矛盾がある場合は、より具体的な globs パターンを設定して適用範囲を限定しましょう。

AIがルールを無視する場合

• ルールが長すぎる可能性があります。重要なルールを上部に配置しましょう
• 曖昧な表現を避け、具体的な指示にしましょう
• 「〜してもよい」より「〜すること」「〜禁止」のほうが効果的です

---

まとめ — Cursor Rules でAIコーディングの品質を底上げする

Cursor Rules は、AIが生成するコードの品質を大きく左右する重要な設定です。

本記事のポイント

• Cursor Rules はプロジェクト固有のルールをAIに伝える設定ファイル
• .cursor/rules/ ディレクトリに .mdc ファイルとして配置するのが推奨
• globs パターンでファイル種別ごとにルールを分割管理できる
• プロジェクト別テンプレート（Next.js、Python、Go等）を活用して効率的に設定する
• CLAUDE.md との違いを理解し、両方使う場合は内容を同期させる

実際にRulesを活用した体験は「Cursorを1ヶ月ガチで使った結果」でも紹介しています。CursorとClaude Codeの使い分けについては「Claude Code vs Cursor 使い分けガイド」も参考にしてください。

まずは技術スタックとコーディング規約の2つだけでもルールに書いてみてください。それだけでAIの出力品質が目に見えて改善するはずです。