「.cursorrulesに書いてるのに、Cursorが全然言うこと聞かない」——こんな経験、ありませんか？

正直に言います。2025年以降、その設定方法はすでに非推奨・廃止方向です。今のCursorは.cursor/rules/ディレクトリ配下の.mdcファイルで管理する新方式が標準になっています。

この記事では、旧方式からの移行手順・フロントマターの正確な書き方・React/Python/API別のコピペ用テンプレートまで一気に解説します。読み終えれば、今日中にプロジェクト固有のルール設計が完成します。

Cursor Rulesとは何か・2026年時点の最新仕様

そもそもCursor Rulesが必要な理由

CursorのAIはデフォルト状態だと「汎用的なコード生成アシスタント」として動作します。つまりプロジェクトの規約、命名ルール、使用ライブラリのバージョン、禁止パターン——こういった文脈を何も知らない状態です。

毎回チャットで「このプロジェクトはTypeScript strictモードで、コンポーネントはnamed exportで…」と説明するのは現実的ではありません。Cursor Rulesはそのコンテキストを永続的にAIに持たせる仕組みです。

ユーザー数は2025年末時点で約400万人を超え（公式発表ベース）、GitHub上のcursorrules関連リポジトリは前年比約3倍に増加しています。awesome-cursorrules系リポジトリが10,000 Starを超えたのも2025年中のこと。チーム開発でのルール設計が、今や当たり前の工程になっています。

Global Rules vs Project Rules——どちらに何を書くか

種類 設定場所 適用範囲 用途例
Global Rules Cursor設定画面 > Rules 全プロジェクト共通 返答言語、口調、基本的なコーディングスタンス
Project Rules .cursor/rules/*.mdc そのリポジトリのみ フレームワーク規約、命名規則、禁止パターン

よくある誤解として「Global Rulesに全部書けばいい」というものがあります。これは罠です。Global Rulesを肥大化させると、関係のないプロジェクトにも余計なコンテキストが混入します。プロジェクト固有の情報はProject Rulesに分離するのが鉄則です。

4つの適用タイプを正しく使い分ける

2025年以降、Project Rulesには適用スコープを制御する4タイプが標準化されました。

タイプ 動作 使いどころ
Always 常時適用 セキュリティルール、コメント言語指定
Auto Attached globパターン一致時に自動適用 *.tsx→Reactルール、*.py→Pythonルール
Agent Requested AIが必要と判断した時に参照 アーキテクチャ設計の指針など
Manual 手動で@rulenameと指定した時のみ 特定作業にしか使わないルール

コミュニティアンケート（n=約500）によると、Auto Attachedタイプが開発者の利用率の約60%を占めています。「このファイルを触る時だけこのルールを適用する」という設計が、実務でもっとも使いやすいからです。

旧.cursorrulesとの違い——今すぐ移行すべき理由

# 旧方式（非推奨）
.cursorrules  ← 1ファイルに全部詰め込む

# 新方式（推奨）
.cursor/rules/
├── general.mdc
├── react.mdc
├── python.mdc
└── security.mdc

旧方式の.cursorrulesも現時点では動作します。ただしCursorの公式ロードマップでは廃止方向であり、新UIの「Project Rules」パネルでは管理できません。今から新しいプロジェクトを始めるなら、.mdc形式一択です。既存プロジェクトも早めに移行することを強くすすめます。

💡 関連教材: ChatGPT業務自動化 実践テンプレート集（¥1,480） — API・スプレッドシート・メール・議事録・請求書をコピペで自動化する実装特化型テンプレート集（全22ページ）

設定の始め方｜.mdc形式ファイルの作成〜UI確認手順

Step 1：ディレクトリとファイルを作成する

UIから作成する場合：Cursor左サイドバーの「…」メニュー > 「New Cursor Rule」を選択。ファイル名を入力すると.cursor/rules/配下に自動生成されます。

手動で作成する場合：プロジェクトルートで以下を実行します。

mkdir -p .cursor/rules
touch .cursor/rules/general.mdc
touch .cursor/rules/react.mdc

Step 2：フロントマターを正確に書く

.mdcファイルはYAMLフロントマター＋Markdownという構造です。フロントマターの書き方を間違えるとルールが一切適用されないので注意。

---
description: React コンポーネント作成ルール
globs: ["**/*.tsx", "**/*.jsx"]
alwaysApply: false
---

# ルール本文をここに書く

globsを設定するとAuto Attachedとして機能します。alwaysApply: trueにするとAlwaysタイプになります。globsなし・alwaysApply: falseの状態はManual扱いです。

Step 3：UIで適用状況を確認する

Cursorの設定画面（Cmd+Shift+J / Ctrl+Shift+J）を開き、「Project Rules」タブを選択。作成したルールファイルが一覧表示され、各ファイルのタイプ（Always / Auto Attached等）が確認できます。

ここに表示されていないファイルは読み込まれていません。ファイルパスのタイポや、フロントマターのYAMLエラーを疑ってください。

推奨フォルダ構成

.cursor/rules/
├── general.mdc      # 共通ルール（言語・口調・命名）← Always
├── react.mdc        # React/TSX専用 ← Auto Attached (*.tsx, *.jsx)
├── python.mdc       # Python専用 ← Auto Attached (*.py)
├── api.mdc          # API設計ルール ← Auto Attached (**/api/**)
├── test.mdc         # テスト規約 ← Auto Attached (*.test.*)
└── security.mdc     # セキュリティチェック ← Always

この分割設計のポイントは、ファイルを触った時だけ関連ルールが読み込まれることです。1ファイルに全部詰め込む旧方式と比べると、コンテキスト消費量が大幅に減ります。

コピペで使えるテンプレート4選

実際に使っているテンプレートをそのまま掲載します。プロジェクトに合わせて書き換えるだけで即使用できます。

テンプレート①：general.mdc（共通ルール）

---
description: プロジェクト共通ルール
globs: []
alwaysApply: true
---

## 言語・コミュニケーション
- コメントは必ず日本語で記述する
- コードレビューコメントも日本語
- エラーメッセージの説明は日本語で行う

## 命名規則
- 変数・関数名は英語（camelCase）
- コンポーネント名はPascalCase
- 定数はSCREAMING_SNAKE_CASE

## 禁止事項
- `any`型の使用禁止（TypeScript）
- `console.log`の本番コードへの混入禁止
- マジックナンバーの直書き禁止（定数化すること）

テンプレート②：react.mdc（React/TypeScript専用）

---
description: React コンポーネント設計ルール
globs: ["**/*.tsx", "**/*.jsx"]
alwaysApply: false
---

## コンポーネント設計
- 関数コンポーネントのみ使用（クラスコンポーネント禁止）
- named exportを使う（default export禁止）
- Propsの型定義は`interface`で記述する

## Hooks
- カスタムHookのファイル名は`use`プレフィックス必須
- `useEffect`の依存配列は省略しない
- データフェッチは`React Query`を使用する

## スタイリング
- Tailwind CSSを使用する
- インラインstyleは使用しない
- クラス名は`clsx`でまとめる

テンプレート③：python.mdc（Python専用）

---
description: Python コーディング規約
globs: ["**/*.py"]
alwaysApply: false
---

## スタイル
- PEP 8に準拠する
- 型ヒントを必ず付ける（Python 3.10+の`X | Y`記法を使う）
- docstringはGoogle Styleで記述する

## 設計
- 関数は単一責任の原則を守る（20行超えたら分割を検討）
- グローバル変数の使用禁止
- 例外は具体的な例外クラスでキャッチする（`except Exception`は最終手段）

## 依存関係
- 外部ライブラリのインポートは`requirements.txt`に記載済みのものだけ使う
- 標準ライブラリを優先し、外部ライブラリは最小限にする

テンプレート④：security.mdc（セキュリティチェック）

---
description: セキュリティ必須チェック
globs: []
alwaysApply: true
---

## 必ずチェックする項目
- APIキー・トークンをコードにハードコードしない（環境変数を使う）
- SQLクエリは必ずプリペアドステートメントを使う
- ユーザー入力値は必ずバリデーションとサニタイズを行う

## 生成コードへの要求
- 認証・認可が必要な箇所には必ずコメントで`# AUTH REQUIRED`を付ける
- 外部APIへのリクエストにはタイムアウトを設定する
- シークレット情報を含む可能性のある変数名を見つけたら警告する

セキュリティルールをalwaysApply: trueにしているのは意図的です。ファイルの種類を問わず、常にセキュリティ視点でコードを見てほしいからです。

よくある失敗とトラブルシューティング

失敗パターン①：ルールが長すぎて逆効果

「詳しく書けば精度が上がる」と思って500行のルールファイルを作った結果、コンテキストウィンドウが圧迫されてコード生成の質が落ちた——これ、かなりあるあるです。

非公式の目安として、1ファイルあたり500〜1,000トークン以内が効果的とされています（コミュニティ知見）。日本語で書いた場合、おおよそ300〜700字が目安です。

解決策：「してほしくないこと」を優先的に書く。肯定的な指示より否定的な制約のほうが、AIは確実に守ります。「named exportを使う」より「default exportは禁止」のほうが効果的です。

失敗パターン②：フロントマターのYAMLエラー

# NG：globsの書き方が間違っている
globs: **/*.tsx

# OK：配列形式で書く
globs: ["**/*.tsx", "**/*.jsx"]

YAMLはシングルクォートとダブルクォートの混在、インデントのズレでもエラーになります。ルールが適用されない時はまずフロントマターのYAML構文を疑ってください。

失敗パターン③：Global RulesとProject Rulesの役割を混同

Global Rulesに「このプロジェクトはNext.js 14を使う」と書いてしまうケースがあります。別プロジェクトでVueを使う時に混乱します。

切り分けの判断基準はシンプルです。「どのプロジェクトでも通用するか？」→Yes ならGlobal、No ならProject Rulesです。

失敗パターン④：一度設定して放置

Cursorのモデルはアップデートされます。半年前に書いたルールが現在のモデルでは冗長になっていることもあります。3ヶ月に1回はルールファイルを見直すことをおすすめします。特にモデルバージョンアップ後は要確認です。

チームでのGit共有運用フロー

.cursor/rules/はGitで管理する

.cursor/rules/ディレクトリはGitにコミットしてください。.gitignoreに入れてしまっている人を見かけますが、これではチームメンバー全員が異なるAI挙動で開発することになります。

# .gitignoreに追加すべきでないもの
# .cursor/rules/  ← これは管理対象にする

# .gitignoreに追加すべきもの
.cursor/chat/  # チャット履歴は個人のものなので除外

PRレビューにルール変更を含める

実際に運用してみて有効だったフローがこれです。

  1. ルールの変更・追加はコードと同じPRに含める
  2. PRの説明欄に「このルールを追加した理由」を書く
  3. レビュアーがルール変更に同意してからマージ

ルールファイルの変更は、実質的に「チーム全員のAIの挙動を変える」ことです。コードレビューと同じ重みで扱うべきです。

新メンバーへのオンボーディング

リポジトリをクローンした時点で.cursor/rules/が存在すれば、新メンバーのCursorも即座に同じルールで動作します。README.mdに「Cursorのルール設計についてはdocs/cursor-rules.mdを参照」と1行書いておくだけで、オンボーディングコストが大幅に下がります。

よくある質問

Q1：.cursorrules（旧方式）はまだ使えますか？

動作はします。ただし公式の廃止方向であり、Cursor UIの「Project Rules」パネルで管理できません。今後のアップデートで突然動かなくなるリスクがあります。移行コストは低いので、早めに.mdc形式へ移行することを強くすすめます。移行手順は：旧.cursorrulesの内容を.cursor/rules/general.mdcにコピー→フロントマターを追加→元ファイルを削除、これだけです。

Q2：ルールが効いているか確認する方法はありますか？

Cursorのチャットで「現在適用されているProject Rulesを教えて」と聞くと、AIが参照しているルールを返答してくれます。また設定画面の「Project Rules」タブで各ファイルの適用タイプが確認できます。「Auto Attached」と表示されているなら、対象ファイルを開いた状態でチャットする時に自動読み込みされています。

Q3：無料プランでもCursor Rulesは使えますか？

使えます。Cursor Rulesはモデルへのシステムプロンプトとして機能するため、プラン問わず利用可能です。ただしコンテキストウィンドウの消費は有料プランと同じように発生します。無料プランでは月間のリクエスト上限が存在するため、ルールファイルを肥大化させると1回のやり取りで消費するコンテキストが増え、実質的なリクエスト数が減ります。無料プランこそルールを簡潔に保つことが重要です。

Q4：Agent Requestedタイプはどんな場面で使いますか？

Alwaysにするほどではないが、AIが必要と判断した時に自動参照してほしいルールに使います。例えば「データベース設計の指針」「マイクロサービスの境界設計ルール」など、特定の設計作業の時だけ参照してほしい内容です。毎回読み込まれると重くなる・でも手動指定は面倒、という中間的なユースケースに向いています。

まとめ：今日やるべき1つのアクション

Cursor Rulesの設定は「複雑な仕組み」ではありません。要点を整理します。

  • 旧.cursorrules→新.cursor/rules/*.mdcへの移行が急務
  • フロントマターのglobs設定で「ファイル種別×ルール」を紐付ける
  • ルールは短く・具体的に。長文は逆効果
  • .cursor/rules/はGit管理してチーム共有する

今日やるべきことは1つだけです。

既存プロジェクトを開いて、.cursor/rules/general.mdcを作成し、今まで.cursorrulesや毎回のチャットで指定していたルールを移植してください。所要時間は15分もかかりません。

Cursorのルール設計が整うと、AIへの指示コストが下がり、その分だけAPI利用効率も上がります。MCP連携やAPI設定と組み合わせれば、さらに開発体験が変わります。気になる方は関連記事も参考にしてみてください。

関連記事

📘 もっと深く学びたい方へ

この記事で紹介した内容を、さらに体系的に・実務レベルで習得できる教材を販売中です。

ChatGPT業務自動化 実践テンプレート集（¥1,480）

API・スプレッドシート・メール・議事録・請求書をコピペで自動化する実装特化型テンプレート集（全22ページ）

  • 動くGASコード・API設定手順・プロンプトをワンセット収録
  • スプレッドシート連携／メール／議事録／請求書を実務レベルで自動化
  • コピペで即動く実装コード（Python / GAS）付き

👉 今すぐ購入する

ChatGPT＆Claude AIプロンプト集50選（¥980）

コピペで即使える実践プロンプト50種を全24ページに凝縮

  • ビジネスメール・企画書・分析・コーディング等 8カテゴリ網羅
  • ChatGPT / Claude / Gemini 全対応
  • 変数を埋めるだけで即実務投入

👉 今すぐ購入する

関連ツール紹介

AIスキルを収益化するなら → ココナラでサービスを出品できる。AIライティング・画像生成・データ分析など、AIスキルを活かした案件の需要は増えている。

おすすめツールの一覧はこちらにまとめている。