Cursor Rules 完全ガイド：プロジェクト規範に沿ったコードを AI に書かせる（実戦設定付き）

Cursor が生成したばかりのコードを前に、エンターキーの上で指が止まりました。これで 3 回目です。

最初は var で変数を宣言し、次はクラスコンポーネント、今回は TypeScript の型がすべて消え、大量の any が追加されていました。コードを消して、自分で書くことにしました。

その瞬間に気づきました。AI が賢くないのではなく、こちらの「ルール」を伝えていなかっただけだと。

Cursor を使い始めたころは、AI が「良いコード」を自分で分かっているはずだと思っていました。チームから「Cursor で作ったコンポーネントが、うちのスタイルと全然違う」と言われて、ようやく AI にも明確な規約が必要だと理解しました。

この記事では、まさにその問題を解決する方法を説明します。5 分で Cursor Rules を設定すれば、AI が生成するコードはプロジェクト規約に沿うようになります。技術スタックの取り違えや、コーディングスタイルのブレに悩まされなくなります。

Cursor Rules とは？なぜ必要か？

Cursor Rules の本質：AI にルールを決める

一言でいうと、Cursor Rules は AI にコーディング規約を教える設定ファイルです。

新入社員に「開発マニュアル」を渡すのと同じです。使う技術スタック、命名のしかた、ファイルの置き方が書いてあります。Cursor Rules は、AI 向けの「入社研修マニュアル」です。

仕組みは単純です。Cursor と対話するとき、ルールファイルの内容が自動的にプロンプトに付加されます。AI はそれを読んで「このプロジェクトは React Hooks で、クラスコンポーネントは使わない」と理解し、規約どおりのコードを生成します。

Rules を設定しないとどうなる？私の失敗談

初めて Cursor でプロジェクトを進めたとき、宝を見つけた気分でした。AI のコード生成はとても速い。しかし 3 日後、問題がはっきりしました。

コードスタイルがバラバラ。あるファイルは camelCase、別のファイルは PascalCase、さらに snake_case まで混在。自分でもどれがどれか分からなくなりました。

技術スタックの取り違え。関数コンポーネントが欲しいのに、class Component extends React.Component が次々と出てくる。「Hooks を使って」と言っても、次のファイルでは元に戻る。

プロジェクト規約違反。チームでは全関数にコメント必須なのに、生成コードはコメントゼロ。エラー処理も try-catch 必須なのに、API をそのまま呼び出すコードばかり。

そのあと 2 日かけてリファクタリングし、手が痛くなるほど直しました。

Rules を設定したあとは？効果が実感できる

その後、5 分で .cursorrules を作り、次を明記しました。

• 技術スタック：React 18 + TypeScript
• 関数コンポーネントと Hooks のみ
• 命名は camelCase に統一
• 型定義必須、any 禁止

どうなったか。

その日から、Cursor が生成するコンポーネントはすべて規約どおりになりました。コードの一貫性は少なくとも 80% 向上し、コードレビューの時間は半分になりました。チームメンバーから「Cursor をこんなに従わせるにはどうしたの？」と聞かれました。

コミュニティの実践でも効果は確認されています。適切な Rules 設定で一貫性が大きく上がり、後からのリファクタリングコストを減らせます。GitHub の awesome-cursorrules はすでに 2000+ star で、多くの開発者にとって必須の仕組みだと分かります。

Cursor Rules の設定方法（2026 年最新）

まず押さえること：新旧の設定方式

ネットで Cursor Rules を調べると、.cursorrules ファイル派と .cursor/rules ディレクトリ派の 2 通りが出てきます。どちらも正しく、時期が違うだけです。

旧方式（2025 年以前）：
プロジェクトルートに .cursorrules を 1 つ置き、すべてのルールをそこに書く。手軽です。

新方式（2026 年推奨）：
ルートに .cursor/rules を作り、その中に複数の .mdc を置く。機能ごとにルールを分け、適用範囲も設定できます。

公式は新方式への移行を推奨しています。旧方式は今も動きますが、将来のバージョンで廃止される見込みです。

おすすめ：新規プロジェクトは新方式。既存プロジェクトは余裕があるときに移行すれば十分です。

2 つのルールレベル：グローバルとプロジェクト

Cursor は 2 段階のルールをサポートします。違いを理解しておくことが大切です。

User Rules（グローバルルール）

個人のコーディング嗜好で、すべてのプロジェクトに効きます。

設定パス：File → Preferences → Cursor Settings → Rules → User Rules

向いていること：プロジェクトをまたぐ共通ルール。例えば：

• 「すべてのプロジェクトで TypeScript を使う」
• 「var は嫌い。const か let に統一」
• 「非同期はすべて async/await、.then() は使わない」

個人の「コードのこだわり」設定と考えてよいです。

Project Rules（プロジェクトルール）

単一プロジェクト向けの規約で、現在のプロジェクトだけに効きます。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

設定方法：

1. プロジェクトルートに .cursor フォルダを作成
2. その中に rules フォルダを作成
3. rules 内に .mdc を作成（例：frontend.mdc、typescript-rules.mdc）

向いていること：プロジェクト固有の技術スタックと規約。例えば：

• 「Next.js 14 + TypeScript + Tailwind CSS のプロジェクト」
• 「API は RESTful に統一」
• 「コンポーネントは components/ に置き、PascalCase で命名」

優先順位は明確で、プロジェクトルール ＞ グローバルルール です。衝突したらプロジェクト側が勝ちます。

ルールの適用範囲：広げすぎない

2026 年版の重要機能として、ルールがいつ効くかを制御できます。.mdc 内で設定します。

Always（常時適用）：何をしていてもこのルールが効く。中核規約（例：「var 禁止」）向き。ただし Always を増やしすぎると AI のコンテキストが圧迫されます。

Auto Attached（自動付与）：ファイル種別で自動トリガー。例：「.tsx には React ルール」「.py には Python ルール」。いちばんおすすめの方式です。

Agent Requested（AI が判断）：会話内容から AI が必要と判断したときだけ読み込む。補助的なルール向き。

Manual（手動）：明示的に使うよう指示したときだけ。パフォーマンス最適化専用やテスト専用など特殊な場面向き。

実践では 80% を Auto Attached、10% を Always、残り 10% を状況に応じて 配分するのが扱いやすいです。

2026 年 1 月の新機能：/rules コマンド

2026 年 1 月 8 日の CLI 更新で、/rules コマンドが追加されました。

Cursor のターミナルで /rules と入力すると、ルールファイルの作成・編集がすぐできます。フォルダを手で探す手間が減り、ルールを頻繁に直す人には助かります。

詳細は Cursor 公式フォーラムの更新告知 を参照してください。

効果的な Cursor Rules の書き方

ここがいちばん重要です。ルールの質が、Cursor が従うかどうかを決めます。

ルール内容の 3 大カテゴリ

ルールは次の 3 層で書くと整理しやすいです。

A. 技術・アーキテクチャ層

まず「どんなプロジェクトか」を伝えます。

プロジェクト技術スタック:
- フロントエンド: React 18 + TypeScript 5.3
- 状態管理: Zustand
- スタイル: Tailwind CSS 3.4
- ビルド: Vite 5.0
- Node.js バージョン: 18+

アーキテクチャ規約も書きます。

アーキテクチャ規約:
- フロント・バック分離
- API は RESTful スタイル
- フォルダ構成:
  - components/ 再利用可能なコンポーネント
  - pages/ ページコンポーネント
  - utils/ ユーティリティ
  - hooks/ カスタム Hooks

なぜここまで詳しく書くか

「React を使う」だけだと、React 16 の書き方と React 18 の書き方が混ざることがあります。バージョンまで書いたら、その問題はほぼ消えました。

B. コード規範層

スタイルを揃える中心部分です。

コード規約:

命名規則:
- コンポーネント名: PascalCase（例: UserProfile）
- ファイル名: kebab-case（例: user-profile.tsx）
- 変数・関数: camelCase（例: getUserData）
- 定数: UPPER_SNAKE_CASE（例: MAX_RETRY_COUNT）

コードスタイル:
- 関数コンポーネントのみ。クラスコンポーネント禁止
- const を優先、次に let。var 禁止
- 矢印関数を使用（this が必要な場合を除き function キーワードは使わない）
- すべてのコンポーネントに TypeScript 型定義必須

ファイル長:
- 1 ファイル 300 行以内
- 1 関数 50 行以内

コメント:
- 重要な関数には JSDoc 必須
- 複雑なロジックには行内コメント
- コメントは「何を」ではなく「なぜ」を書く

C. 品質・テスト層

エラー処理:
- すべての非同期処理に try-catch 必須
- API 失敗時はユーザー向けの分かりやすいメッセージ
- エラーを握りつぶさず、少なくとも console.error

パフォーマンス:
- リストレンダリングに key 必須
- 大きなリストは仮想スクロール
- 画像に width / height を指定し、レイアウトシフトを防ぐ

テスト:
- ユーティリティ関数に単体テスト必須
- 重要なビジネスロジックにテストカバレッジ

ルール記述の黄金原則

原則 1：具体的・実行可能・検証可能

いちばん大切な原則です。

❌ 悪い例：「コードをきれいに書く」「ベストプラクティスに従う」「パフォーマンスに注意」

これでは AI も読者も何をすればよいか分かりません。「ベストプラクティス」がどれを指すのか、AI には判断できません。

✅ 良い例：

• 「関数コンポーネントを使い、クラスコンポーネントは使わない」
• 「Props は interface で定義し、type は使わない」
• 「非同期は必ず async/await を使い、.then() は使わない」

良いルールは、そのまま実行できる指示です。曖昧な助言ではありません。

原則 2：500 行以内に収める

コミュニティのベストプラクティスです。長すぎると AI の理解が難しくなり、コンテキストも圧迫されます。

500 行を超えたら分割を検討します。

• frontend.mdc — フロント関連
• backend.mdc — バックエンド関連
• typescript.mdc — TypeScript 関連
• testing.mdc — テスト関連

原則 3：言葉だけでなくサンプルコード

AI は例を見ると理解しやすいです。

❌ 言葉だけ：

コンポーネントは関数式で書き、型定義を付ける

✅ サンプル付き：

コンポーネント例:

interface UserCardProps {
  name: string;
  email: string;
}

export const UserCard = ({ name, email }: UserCardProps) => {
  return (
    <div className="user-card">
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
};

例があると、Cursor は求めているコードの形を把握しやすくなります。

原則 4：重要なルールを先頭に

AI は上の方をより強く参照する傾向があります。

1 優先：技術スタックとバージョン
2 優先：コードスタイル
3 優先：ファイル構成
最後：任意の最適化提案

よくある間違い

間違い 1：ルールが広すぎる

「React のベストプラクティスに従う」— 2016 年版と 2024 年版では内容が違います。

改善例：「React Hooks を使う。状態は useState と useEffect を優先し、複雑な状態は useReducer」

間違い 2：ルール同士が矛盾

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

「TypeScript 必須」と「any は許可」— 矛盾すると AI が混乱し、どちらも守らないことがあります。

間違い 3：バージョンを書かない

React 16 のクラスコンポーネントと React 18 の Hooks では書き方が大きく違います。「React を使う」だけだと、バージョンがランダムに選ばれることがあります。

必ず React 18.2+、TypeScript 5.3+、Node.js 18+ のように書いてください。

間違い 4：論文のように長く書く

理論や背景を長々と書く人がいますが、AI に説得する必要はありません。何をするかだけ伝えれば十分です。

❌ 「TypeScript を選んだ理由は静的型検査によりコンパイル時にエラーを検出し…」（さらに 300 字）

✅ 「TypeScript を使用。any 型は禁止」

短く、はっきり。

実践：React + TypeScript プロジェクト向けルール

理論だけでは足りないので、具体例で進めます。

想定スタック：

• React 18
• TypeScript 5.x
• Tailwind CSS 3.x
• Vite 5.x

チーム規約：

• 関数コンポーネントのみ
• 厳格な型、any 禁止
• ファイル・命名の統一
• エラー処理必須

ここからルールファイルを順に作ります。

Step 1：ルールファイルを作成

プロジェクトルートで：

mkdir -p .cursor/rules
cd .cursor/rules
touch react-typescript.mdc

Step 2：技術スタックを定義

react-typescript.mdc を開き、まず技術スタックを書きます。

# React + TypeScript プロジェクトルール

## 技術スタック

- React 18.2+
- TypeScript 5.3+
- Tailwind CSS 3.4+
- Vite 5.0+
- Node.js 18+

## 依存管理

- パッケージマネージャ: pnpm
- npm や yarn は使わない

Step 3：コードスタイル規約

続けてコードの書き方を定義します。

## コード規約

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

- 関数コンポーネントのみ。クラスコンポーネント禁止
- コンポーネント名は PascalCase
- ファイル名は kebab-case
- 名前付きエクスポートを使い、デフォルトエクスポートは使わない

例:

// ❌ 誤り
export default function userProfile() { }

// ✅ 正しい
export const UserProfile = () => { }

### TypeScript 規約

- すべてのコンポーネントに型定義必須
- Props は interface を使い、type は使わない
- any 禁止。unknown または具体型を使う
- 関数の戻り値型を明示

例:

// ✅ 正しいコンポーネント定義
interface UserCardProps {
  name: string;
  email: string;
  age?: number;
}

export const UserCard = ({ name, email, age }: UserCardProps): JSX.Element => {
  return (
    <div className="p-4 border rounded">
      <h3 className="text-lg font-bold">{name}</h3>
      <p className="text-gray-600">{email}</p>
      {age && <p>Age: {age}</p>}
    </div>
  );
};

### 命名規則

- 変数・関数: camelCase
- コンポーネント: PascalCase
- 定数: UPPER_SNAKE_CASE
- ファイル名: kebab-case
- CSS クラス: Tailwind のユーティリティのみ。カスタム CSS は書かない

### 非同期処理

- すべての非同期は async/await
- .then() チェーン禁止
- try-catch によるエラー処理必須

例:

// ✅ 正しい
const fetchUserData = async (userId: string): Promise<User> => {
  try {
    const response = await fetch(`/api/users/${userId}`);
    if (!response.ok) throw new Error('Failed to fetch user');
    return await response.json();
  } catch (error) {
    console.error('Error fetching user:', error);
    throw error;
  }
};

Step 4：ファイル構成規約

## ファイル構成

### ディレクトリ構造

src/
├── components/     # 再利用可能なコンポーネント
├── pages/          # ページコンポーネント
├── hooks/          # カスタム Hooks
├── utils/          # ユーティリティ
├── types/          # TypeScript 型定義
├── services/       # API 呼び出し
└── constants/      # 定数

### ファイル命名

- コンポーネント: user-card.tsx
- ユーティリティ: format-date.ts
- 型定義: user.types.ts
- Hook: use-user-data.ts

### import の順序

1. React 関連
2. サードパーティ
3. プロジェクト内コンポーネント
4. ユーティリティ
5. 型定義
6. スタイル

Step 5：品質要件

## 品質要件

### エラー処理

- API 呼び出しに try-catch 必須
- エラーメッセージはユーザー向けに分かりやすく
- エラーログを記録

### パフォーマンス

- リストレンダリングに key 属性必須
- レンダー関数内で新しいオブジェクトや関数を作らない
- 不要な再レンダーには React.memo を検討
- 画像に width と height を指定

### コード品質

- 1 ファイル 300 行以内
- 1 関数 50 行以内
- 複雑なロジックにはコメント
- 重要な関数には JSDoc コメント

Step 6：完成したルールファイル

上記をまとめると、.cursor/rules/react-typescript.mdc のひととおりが完成します。

プロジェクトに合わせて調整できます。例えば：

• Redux を使うなら Redux の規約を追加
• React Query ならデータ取得の規約を追加
• 業務固有のルールがあれば追記

効果をテストする

設定後、Cursor にユーザーカードコンポーネントの生成を頼んでみてください。

プロンプト例：「ユーザー名・メール・アバターを表示するユーザーカードコンポーネントを作成して」

ルール設定前、Cursor は次のようなコードを出すことがあります。

export default function UserCard(props) {
  return <div>...</div>
}

ルール設定後は、次のような形になりやすいです。

interface UserCardProps {
  name: string;
  email: string;
  avatarUrl: string;
}

export const UserCard = ({ name, email, avatarUrl }: UserCardProps): JSX.Element => {
  return (
    <div className="p-4 border rounded shadow">
      <img src={avatarUrl} alt={name} className="w-16 h-16 rounded-full" width="64" height="64" />
      <h3 className="text-lg font-bold mt-2">{name}</h3>
      <p className="text-gray-600">{email}</p>
    </div>
  );
};

規約どおりか確認：

• ✅ 関数コンポーネント
• ✅ TypeScript 型定義
• ✅ 名前付きエクスポート
• ✅ Tailwind スタイル
• ✅ 画像に width / height

一度で仕上がり、手戻りが減ります。

応用テクニックとよくある質問

ルールの優先順位：どれが勝つか

複数レイヤーのルールがあると、衝突することがあります。Cursor の優先順位は次のとおりです。

プロジェクトルール ＞ グローバルルール

グローバルで「シングルクォート」、プロジェクトで「ダブルクォート」なら、プロジェクト側が優先されます。

子ディレクトリのルール ＞ 親ディレクトリのルール

例：

project/
├── .cursor/rules/general.mdc
└── frontend/
    └── .cursor/rules/react.mdc

frontend/ で作業するときは react.mdc の方が優先されます。

手動指定 ＞ 自動トリガー

会話で特定のルールを明示すると、そのルールが優先されやすくなります。適用範囲が Manual でも同様です。

複数ルールファイルの管理：分割のコツ

プロジェクトが大きくなると、1 ファイルでは足りなくなります。次のように分けるのが扱いやすいです。

.cursor/rules/
├── core.mdc              # コア技術スタック（Always）
├── frontend.mdc          # フロント（Auto Attached: *.tsx, *.ts）
├── backend.mdc           # バックエンド（Auto Attached: *.py, *.go）
├── testing.mdc           # テスト（Auto Attached: *.test.*）
└── performance.mdc       # パフォーマンス（Manual）

領域ごとに責務を分けると、メンテナンスもしやすくなります。

デバッグ：ルールが効かないとき

問題 1：ルールが読み込まれているか分からない

Composer または Chat で「どのルールが見えている？」と聞いてください。

Cursor は読み込んだルールファイルを返します。出てこない場合は：

• パスが間違っている
• 適用範囲の設定が合っていない
• ファイル形式に問題がある

のいずれかが考えられます。

問題 2：ルール同士が衝突

矛盾があると、AI がどちらも守らないことがあります。

対処：

🔥 需要のない製品に3ヶ月も無駄にするな！少額の予算で Adsterra を使い、SaaS の訴求を今すぐ検証 ➡️

今すぐ検証 →広告

1. ルールファイルを見直し、衝突箇所を特定
2. 優先順位を決め、低優先度のルールを削除
3. 高優先度のルールに「他のルールより優先」と明記

問題 3：AI がルールを無視する

ルールを書いても従わないことがあります。

よくある原因：

1. ルールが曖昧 — 具体指示に書き換える
2. ルールが長すぎる — 後半が無視されやすい。重要項目を先頭へ
3. プロンプトとルールが矛盾 — 会話で「クラスコンポーネントで」と言い、ルールで「関数コンポーネントのみ」と書いていると、会話内容が優先されやすい

対処：

• ルールを書き直し、サンプルコードを増やす
• 会話で「プロジェクトルールに従って」と明示
• Auto Attached から Always に変更して強制力を上げる

既成ルールを使う：巨人の肩の上に

ゼロから書かなくても、コミュニティに豊富なリソースがあります。

awesome-cursorrules

GitHub で人気の Cursor Rules 集。2000+ star。含まれるもの：

• React、Vue、Angular などのフロント
• Python、Go、Java などのバックエンド
• Next.js、Astro、Nuxt などのフルスタック
• TypeScript、テスト、Docker などの専門ルール

必要なファイルをコピーし、プロジェクトに合わせて調整するだけで使えます。

awesome-cursorrules-zh

中国語圏向けに最適化されたルール集。React と FastAPI をマージした全スタック例などもあります。

cursor.directory

オンラインのルール集。ブラウザでプレビュー・コピーでき、30+ フレームワークに対応しています。

dotcursorrules.com

実践事例やベストプラクティスが多い別サイトです。

おすすめ：まずコミュニティルールで運用し、しばらく使ってからプロジェクトに合わせて調整する。最初から全部自分で書く必要はありません。

チーム連携：ルールをチームの資産にする

チーム開発なら、ルールをバージョン管理に入れるのが有効です。

1. Git にコミット

.cursor/rules をリポジトリに含めます。

git add .cursor/rules
git commit -m "Add Cursor rules for project standards"

メンバーが pull すれば、各自の Cursor が同じプロジェクトルールを読み込み、AI の挙動が揃います。

2. 新メンバー向けの README

README に次のような説明を足すと親切です。

## Cursor での開発

本プロジェクトは `.cursor/rules` に Cursor Rules を配置しています。

Cursor 利用時、AI は次の規約に自動で従います:
- React 18 + TypeScript
- 関数コンポーネント + Hooks
- Tailwind CSS
- 厳格な型定義

ルールを変更する場合は、先にチームで相談してください。

3. 定期 Review

技術スタックも規約も変わります。四半期に 1 回、ルールファイルを見直すのがおすすめです。

• 古くなったルールはないか
• 取り入れるべき新しいベストプラクティスはないか
• チームからのフィードバックはどうか

ルールは一度きりの設定ではなく、生きたドキュメントとして育ててください。

まとめ

核心はひとことです。AI にルールを決めてあげれば、期待どおりに動いてくれる。

Cursor を始めたころ、次のような経験はありませんか。

• コンポーネントを頼むとスタイルがバラバラ
• TypeScript で書いてほしいのに、こっそり any が増える
• コードが「AI っぽく」て、チームの書き方と違う

これは Cursor のせいではなく、こちらのルールを伝えていなかったからです。

いま、次のことが分かりました。

1. ルールファイルを作る — 新規は .cursor/rules、既存はまず .cursorrules でも可
2. 技術スタックをはっきり書く — バージョン、フレームワーク、ツールチェーンまで具体化
3. コード規約を定義する — 命名、スタイル、エラー処理。サンプルコード付きで
4. 長さを抑える — 500 行以内。必要なら分割
5. 継続的に直す — ルールは一度きりではなく、プロジェクトとともに更新

今すぐできること：

• まだルールがなければ、5 分で最初の 1 ファイルを作る
• すでにあるなら、曖昧な表現がないか見直し、サンプルコードを足す
• チーム開発なら、ルールを Git にコミットして全員で共有する

1 か月後には、次の変化を実感しやすいです。

• コードレビューの時間が半分近くになる
• コードスタイルが揃う
• 新メンバーの立ち上がりが速くなる
• AI が本当の「右腕」に近づく

最後に、ゼロから書かなくてよいリソースです。

• awesome-cursorrules — 2000+ star のルール集
• awesome-cursorrules-zh — 中国語圏向け最適化版
• cursorrules.org — オンラインルール集