Cursor Rules（カーソルルール）完全ガイド【2026年最新】：.mdcファイルの書き方・4種類のルールタイプ・おすすめ設定まで徹底解説
室谷今回はCursor Rulesの話をしましょう。「Cursor使ってるけど、毎回同じことをAIに説明しなきゃいけない」って声、.AI（ドットエーアイ）コミュニティでも本当に多いんですよね・・・
テキトー教師あー、これほんと多いですよね。「TypeScriptで書いて」「ESLintに合わせて」「コメントは日本語で」って、セッションが変わるたびに全部言い直してる人、結構いますよ。
室谷それを解決するのがCursor Rulesなんですよ。一度設定してしまえば、Cursorが自動でその指示を参照してくれる。
MYUUUでも全プロジェクトにCursor Rulesを入れていて、新しいメンバーが入っても即日でチームのコーディング規約に沿ったコードを書いてもらえるようになりましたね。
MYUUUでも全プロジェクトにCursor Rulesを入れていて、新しいメンバーが入っても即日でチームのコーディング規約に沿ったコードを書いてもらえるようになりましたね。
テキトー教師講座でも最初に教えるんですが、受講生さんがCursor Rulesを設定した瞬間から「え、こんなに違うんですか」って言い方が変わりますよね。AIの出力品質が段違いになる。
室谷Claude CodeでいうCLAUDE.mdと役割が近いんですよね。プロジェクトのコンテキストをAIに永続的に与える仕組みです。
ただCursor Rulesの方が、ファイルタイプ別に適用するルールを分けられるという点で、より細かいコントロールができる・・・
ただCursor Rulesの方が、ファイルタイプ別に適用するルールを分けられるという点で、より細かいコントロールができる・・・
テキトー教師そうなんですよ。「フロントエンドのコードを触るときだけこのルールを適用」みたいな使い方ができる。
それが今回のポイントです。この記事では、Cursor Rulesの基本概念から実際の書き方、フレームワーク別のテンプレートまで全部解説します。
それが今回のポイントです。この記事では、Cursor Rulesの基本概念から実際の書き方、フレームワーク別のテンプレートまで全部解説します。
Cursor Rulesとは？役割と概要
室谷まず基本から整理しましょう。Cursor Rulesというのは、Cursorに対して「こういう前提で作業して」と事前に指示を与えておく仕組みです。
テキトー教師チャットを始めるたびに指示を書かなくて良い、というのが最大のメリットですよね。コーディング規約、使っているスタック、命名規則、コメントのルール・・・これを全部Cursor Rulesに書いておけば、AIが自動で参照してくれます。
室谷位置づけとしては「AIへの永続的なシステムプロンプト」ですね。チャットのたびに消えずに残り続ける指示書、という感じ。
テキトー教師ファイルの場所は
拡張子は
.cursor/rules/ ディレクトリの中です。プロジェクトのルートに作成します。拡張子は
.mdc（Markdown with Cursor）という独自形式を使います。室谷以前は
.cursorrules という単一ファイルが主流でしたが、今は .cursor/rules/ ディレクトリに複数の .mdc ファイルを置くのが推奨されています。単一ファイルより、目的別にファイルを分けられる方が管理しやすいんですよね。テキトー教師.cursorrules ファイルはまだ動くんですが、公式ドキュメントではレガシー扱いです。新しく始めるなら .mdc 形式一択ですね。.cursorrules と .mdc の違い
| 比較項目 | 旧: .cursorrules | 新: .cursor/rules/*.mdc |
|---|---|---|
| ファイル数 | 1ファイルのみ | 複数ファイル |
| 適用条件 | 常に全部適用 | ファイルタイプや状況で分岐可能 |
| 公式サポート | レガシー（非推奨） | 推奨 |
| トークン効率 | 全て常に消費 | 必要な時だけ適用 |
| チーム管理 | 煩雑 | Git管理しやすい |
室谷このトークン効率の差が実は大きくて・・・。常に全ルールを参照し続けると、コンテキストウィンドウを無駄に消費します。
.mdc なら「このファイルを編集するときだけこのルールを読む」という設定ができるので、よりスマートに動く。テキトー教師受講生さんが「AIがなんか遅い」って言うとき、ルールを全部 Always 設定にしてることが多いんですよ（笑）。大きなルールを常時読ませると確かに重くなる。
4種類のルールタイプを完全解説
室谷ここが Cursor Rules の核心です。4つのルールタイプがある。
これを理解すると使い方が劇的に変わります。
これを理解すると使い方が劇的に変わります。
テキトー教師整理すると、こういう構造です。
ルールタイプ一覧
| タイプ | 英語名 | 発動条件 | 向いているルール |
|---|---|---|---|
| 常時適用 | Always | 全セッションで自動適用 | 言語・全体コーディング規約 |
| 自動付与 | Auto Attached | 指定ファイルを開いたとき | フレームワーク・ドメイン別規約 |
| AI判断 | Agent Requested | AIが必要と判断したとき | ツール・特定ワークフロー |
| 手動 | Manual | @ルール名で明示的に呼び出す | 補助的な参考資料 |
室谷1つずつ深掘りしましょう。まず Always（常時適用） から。
Always（常時適用）ルール
室谷全てのセッションで自動的に読み込まれるルールです。フロントマターで
alwaysApply: true を設定します。テキトー教師向いているのは「プロジェクト全体に適用したい基本的なルール」ですよね。たとえばコメントは日本語で書く、TypeScriptを使う、といった全体共通の規約。
室谷注意点は 200字以内に収める こと。常時読み込まれるので、長くすると毎回トークンを消費します。
MYUUUでも Always ルールは本当に最小限にして、「プロジェクトの基本情報だけ」にしてますね。
MYUUUでも Always ルールは本当に最小限にして、「プロジェクトの基本情報だけ」にしてますね。
---
alwaysApply: true
---
# プロジェクト基本規約
- 言語: TypeScript（any禁止）
- コメント: 日本語で記述
- テスト: 全関数にユニットテストを追加
- エラーハンドリング: 必ず実装
これくらいシンプルで十分です。Always ルールに詰め込みすぎると逆効果になるので。
Auto Attached（自動付与）ルール
テキトー教師次が Auto Attached。これが一番使いどころが広いですよね。
特定のファイルを編集するときだけ、自動でルールが適用される。
特定のファイルを編集するときだけ、自動でルールが適用される。
室谷たとえば
src/components/**/*.tsx というパターンを設定しておくと、Reactコンポーネントを触るときだけそのルールが読み込まれる。APIルートのファイルを触るときは別のルールが読み込まれる、という使い分けができます。テキトー教師フロントマターに
globs を設定します。---
alwaysApply: false
globs: ["src/components/**/*.tsx", "src/pages/**/*.tsx"]
---
# Reactコンポーネント規約
- 関数コンポーネント + TypeScript インターフェースを使用
- named exportのみ（default exportは禁止）
- コンポーネントは150行以内に収める
- Propsの型定義はコンポーネントの直上に書く
glob パターンの書き方がハマりポイントで・・・。実際のファイルパスと glob パターンが一致しないとルールが発動しない。
ここは後で詳しく解説しましょう。
ここは後で詳しく解説しましょう。
Agent Requested（AI判断）ルール
室谷このタイプが面白くて、AIが「このルールが必要そう」と判断したときだけ読み込む。
description フィールドに「このルールをいつ使うか」を書くと、AIがそれを読んで判断します。テキトー教師たとえば Stripe の決済フローを実装するとき、Stripe 固有のルールだけ読み込む、みたいな使い方ですよね。
---
alwaysApply: false
description: "Stripe決済フローやサブスクリプションの実装を行うとき"
---
# Stripe実装規約
- Stripe Webhookは必ず署名検証を実装
- 金額はセント単位で扱う（日本円はそのままの整数値）
- エラーは Stripe のエラーコードで分岐して処理
この
description の書き方が肝で、曖昧に書くとAIが読み込んでくれないんですよね。「決済関連」より「Stripe決済フローやサブスクリプションの実装を行うとき」の方がAIが判断しやすい。テキトー教師講座でも「description は動詞で始まる具体的な状況を書いて」って教えてます。「〇〇するとき」「〇〇を実装するとき」のフォーマットが効きやすいですね。
Manual（手動）ルール
テキトー教師最後が Manual。チャット画面で
@ルール名 と書いて明示的に呼び出すタイプです。室谷あまり頻繁に使わないけど、たまに参照したい資料的なルールに向いてます。たとえばデプロイ手順書とか、エラーコード一覧とか。
「このルールを参照して」と伝えるだけで読んでくれる。
「このルールを参照して」と伝えるだけで読んでくれる。
テキトー教師使用頻度は低いけど、「書きっぱなし」でいいのが楽ですよね。メンテナンスコストが低い。
ファイル構造と配置方法
室谷実際にどこにファイルを置くか、という話をしましょう。
テキトー教師基本構造はこうなります。
your-project/
├── .cursor/
│ └── rules/
│ ├── general.mdc # 常時適用（基本規約）
│ ├── react-components.mdc # Auto: src/components/**
│ ├── api-routes.mdc # Auto: src/api/**
│ ├── database.mdc # Auto: src/db/**
│ ├── stripe.mdc # Agent Requested
│ └── deploy-guide.mdc # Manual
├── src/
├── package.json
└── .gitignore
ポイントは
チームのコーディング規約をAIに学習させるのと同義ですよね。
.cursor/rules/ ディレクトリを Gitに含める こと。これをチームで共有することで、全員が同じAI動作になる。チームのコーディング規約をAIに学習させるのと同義ですよね。
テキトー教師受講生さんで「チームのCursor設定がバラバラで困ってる」という相談をよく受けるんですが、Cursor Rules を Git 管理することで解消できます。
室谷逆に User Rules という設定もあって、これは Cursor の設定画面（
Cursor Settings > Rules）で設定する、個人の好みの設定です。プロジェクトに関係なく全てのプロジェクトで適用される。テキトー教師使い分けるとこうなります。
User Rules と Project Rules の使い分け
| 項目 | User Rules | Project Rules（.mdc） |
|---|---|---|
| 設定場所 | Cursor設定画面 | .cursor/rules/*.mdc |
| 適用範囲 | 全プロジェクト | そのプロジェクトのみ |
| Git管理 | されない（個人設定） | される（チームで共有） |
| 向いているもの | 個人の癖・好み | チームの規約・プロジェクト固有設定 |
室谷「コメントは絶対に日本語で」は個人設定（User Rules）に入れておいて、「このプロジェクトではSupabaseを使う」はProject Rules に入れる、という使い分けが基本ですね。
テキトー教師User Rules に書くのは「自分が常にAIに知っておいてほしいこと」。僕は「受講生向けのコードは必ず丁寧なコメントを入れる」とか入れてますw
.mdcファイルの書き方：フロントマターと本文
室谷じゃあ実際に
.mdc ファイルをどう書くか、という話に行きましょう。構造はシンプルで、YAMLフロントマターと Markdown 本文の2つのパーツで構成されています。テキトー教師フロントマターは
使えるフィールドはこれです。
--- で囲んだYAML部分です。ここでルールの動作を制御します。使えるフィールドはこれです。
フロントマターのフィールド一覧
| フィールド | 型 | 用途 |
|---|---|---|
alwaysApply | boolean | true で常時適用、false で条件付き |
globs | 文字列 or 配列 | Auto Attached のファイルパターン |
description | 文字列 | Agent Requested の判断テキスト |
室谷--- の間に3つのフィールドがある。これらの組み合わせでどのタイプのルールかが決まります。テキトー教師まとめると、こうなります。
alwaysApply: true→ AlwaysalwaysApply: false+globsあり → Auto AttachedalwaysApply: false+descriptionあり → Agent Requested- 全部なし → Manual
室谷フロントマターの後は普通の Markdown で書けます。見出し、箇条書き、コードブロック、テーブル、全部使えます。
テキトー教師コードブロックを使うと「こういう書き方をして」という例示ができるので積極的に使うといいですよ。「NG/OK例を並べる」パターンは効果的です。
室谷NG/OK例を並べるのはめちゃくちゃ効くんですよね。言葉で「anyを使わないで」と書くより、コードで見せた方がAIが理解しやすい。
テキトー教師これ、人間に教えるときと同じですよね。「ダメな例」を具体的に見せた方が理解が速い（笑）。
Glob パターンの設定方法
テキトー教師Auto Attached ルールの
globs パターン、ここでハマる人が多いので、しっかり解説しましょう。室谷まずはよく使うパターンを覚えてしまうのが早いですよね。
よく使う glob パターン集
# 特定の拡張子を全ファイル
**/*.ts → 全 .ts ファイル
**/*.tsx → 全 .tsx ファイル
**/*.py → 全 .py ファイル
# 特定ディレクトリ配下
src/**/*.ts → src/ 以下の全 .ts
src/components/**/*.tsx → src/components/ 以下の全 .tsx
# 複数パターン（配列）
["src/**/*.ts", "src/**/*.tsx"]
# 特定のファイル名
**/schema.ts → 全ての schema.ts
**/*Controller.ts → Controller で終わる .ts
# ディレクトリ名を含む
src/api/** → src/api/ 以下の全ファイル
tests/**/*.test.ts → tests/ 以下の全テストファイル
注意点が2つあって、1つ目は パスはプロジェクトルートからの相対パス であること。2つ目は で始めない こと。
室谷これが地味なハマりポイントなんですよね。
/src/**/*.ts と書いてしまうと動かない。src/**/*.ts が正しい書き方です。テキトー教師あとは実際のファイルがどこにあるか確認してから書く、という当たり前なんですけど見落としがちな話もあります。
app/ 配下にコンポーネントがあるのに src/components/** を書いてたり（笑）。室谷ルールが動いてるか確認する方法として、チャット画面でルールが読み込まれているかを確認できます。Applied Rules に表示されていれば機能しています。
テキトー教師ルールが効いているか確認するために、ルールの先頭に「このルールを参照しているとき、必ず最初にルール確認しましたと言ってください」みたいな確認コメントを一時的に入れて動作確認するのもアリです。
Cursor Rulesの書き方：実践的なベストプラクティス
室谷じゃあ「良いルールの書き方」の話をしましょう。何でもルールに書けばいいというわけじゃないんですよね。
テキトー教師ルールを書きすぎると逆効果になるんですよ。AIが多すぎる制約に縛られて、本来のタスクに集中できなくなる。
室谷MYUUUで実際に試行錯誤した中で見えてきたのは「ルールは短く、具体的に、行動ベースで書く」という原則ですね。
良いルールの5つの原則
テキトー教師整理するとこうなります。
1. 短く書く
Always ルールは200字以内、Auto Attached でも500字以内が目安。長いと読まれない、あるいはコンテキスト消費が大きくなります。
2. 具体的に書く
「良いコードを書いて」は意味がないです。「関数は単一責任原則に従い、1つの処理だけを行う」のように具体的に。
3. 行動ベースで書く
「〇〇すること」「〇〇を使う」「〇〇は禁止」のように、AIがどう動けばいいかを明確に指示します。
4. NG/OK例を入れる
特にコードスタイルに関するルールは、NG例とOK例を並べると理解精度が上がります。
5. 定期的に見直す
「3回同じことをAIに教えたらルールに入れる」というのが良い追加タイミング。逆に「使わなくなったルールは消す」こともメンテナンスとして重要です。
室谷海外の開発者コミュニティでも「良い Cursor Rules は良いドキュメントと同じ」という言い方がされていて・・・。明確で、具体的で、メンテされている。
これが共通の基準ですね。
これが共通の基準ですね。
テキトー教師「Cursorのルールを書く」という行為自体が、チームの開発規約を整理するいい機会になるんですよ。「うちの命名規則ってなんだっけ？」みたいな話が出てきて、チームで合意形成するきっかけになる。
室谷これ、本当にそうで・・・。MYUUUでも Cursor Rules を整備する過程で「そういえば TypeScript の型定義、どこまで厳密にやるか決めてなかったよね」みたいな話が出てきて、チームの規約を改めて整備することになりましたね。
Cursor Rulesのおすすめ設定：言語・フレームワーク別テンプレート
テキトー教師ここからが実践編ですね。言語やフレームワーク別に、おすすめのルール設定を見ていきましょう。
室谷コピーして使えるレベルで書きますね。まずは汎用的な「プロジェクト基本ルール」から。
汎用：プロジェクト基本ルール（Always）
---
alwaysApply: true
---
# プロジェクト概要
## 技術スタック
- フロントエンド: Next.js 15 + TypeScript
- バックエンド: Supabase (PostgreSQL)
- スタイリング: Tailwind CSS
- テスト: Vitest
## 基本規約
- コメントは日本語で記述
- エラーハンドリングは必須
- anyは使用禁止
- コンソールログは本番コードに残さない
スタック情報を書いておくだけで、AIが最初から適切なライブラリを選んでくれるようになりますよね。「Reactコンポーネントを作って」と言っただけでTailwind CSSでスタイリングしてくれるようになる。
室谷「使っているライブラリの名前」を入れておくのも効果的ですよ。「Next.js 15の最新機能（Server Actions等）を活用して」みたいな指示と組み合わせると特に。
TypeScript プロジェクトルール（Auto Attached）
---
alwaysApply: false
globs: ["**/*.ts", "**/*.tsx"]
---
# TypeScript規約
## 型定義
- 全ての関数に戻り値の型を明記する
- interfaceはI接頭辞なし（UserProfile, not IUserProfile）
- Union型は型エイリアスとして定義する
- anyは使用禁止。unknownまたは具体的な型を使う
## 関数
- アロー関数を推奨（functionキーワードは避ける）
- 非同期処理は async/await（Promiseチェーンは避ける）
- 関数は単一責任、100行以内に収める
## import
- パスエイリアスを使用（@/components/Foo）
- 型のみのimportは import type を使う
interface の命名規則とか、import type の使い方とか、細かいけど地味に統一されてないとコードレビューで毎回指摘しなきゃいけないですよね（笑）。室谷そういう「小さいけど毎回指摘すること」こそCursor Rulesに入れる価値があるんですよ。人間のレビュアーがやることをAIに先にやってもらう、という発想です。
React / Next.js コンポーネントルール（Auto Attached）
---
alwaysApply: false
globs: ["src/components/**/*.tsx", "app/**/*.tsx"]
---
# Reactコンポーネント規約
## コンポーネント設計
- 関数コンポーネント + TypeScript interfaceで定義
- Propsの型はコンポーネントの直上に書く
- named exportのみ（default exportは禁止）
- コンポーネントは150行以内。超えたら分割を検討
## State管理
- ローカルstateはuseState/useReducer
- サーバーstateはTanStack Query
- グローバルstateはZustand
## スタイリング
- Tailwind CSSのユーティリティクラスを使用
- カスタムCSSは最小限に抑える
- className は cn()ヘルパーで結合する
## アクセシビリティ
- インタラクティブ要素には必ずaria-labelを追加
- 画像にはaltテキストを設定
これをチームで共有するだけで、コンポーネントの書き方が自然と統一されますよね。「うちのプロジェクトはZustandを使ってるのに誰かがReduxを入れてた」みたいな問題が起きにくくなる。
室谷named exportのみという制約も地味に大事で・・・。default exportが混在するとindex.tsでの再エクスポートが面倒になる。
AIがルールを覚えてくれると助かります。
AIがルールを覚えてくれると助かります。
Python プロジェクトルール（Auto Attached）
---
alwaysApply: false
globs: ["**/*.py"]
---
# Python規約
## コードスタイル
- PEP 8に準拠
- 型ヒントを全関数に付ける
- docstringはGoogle形式で記述
## 関数・クラス
- 関数は1つの処理のみ（単一責任）
- クラス名: PascalCase
- 変数・関数名: snake_case
- 定数: UPPER_SNAKE_CASE
## 依存関係
- パッケージ管理はuv
- 仮想環境は.venv/に作成
- requirements.txtではなくpyproject.tomlを使用
## テスト
- pytestを使用
- テストファイルはtests/ディレクトリに配置
- テスト関数名はtest_で始める
uvの指定を入れておくのが今の時代では重要ですよね。AIが古いpipで書いてしまうことを防げる。室谷パッケージ管理ツールが何年かに一度変わるので、「今うちが使っているのはこれ」と明示しておくのは大事ですよ。特にPythonエコシステムは変化が速い。
Laravel（PHP）プロジェクトルール（Auto Attached）
---
alwaysApply: false
globs: ["**/*.php"]
---
# Laravel規約
## コントローラー
- リソースコントローラーを優先
- ビジネスロジックはServiceクラスに分離
- FormRequestでバリデーション
- コントローラーは50行以内を目標に
## Eloquent ORM
- N+1問題を避けるためeager loadingを使用（with()）
- スコープで共通クエリをまとめる
- マスアサインメントには$fillableを必ず設定
## セキュリティ
- ユーザー入力は必ずバリデーション
- SQLは必ずEloquentまたはクエリビルダー経由
- 認証にはSanctum/Passportを使用
Laravelはフレームワークとしての「正しい書き方」があるので、それをルールに入れておくとAIが自然とベストプラクティスに沿ったコードを書いてくれますよね。
Cursor Rulesの GitHub での共有・活用
室谷「GitHub で Cursor Rules を公開している」という文化、海外ではすごく広がってるんですよね。
テキトー教師cursor rules github で調べると、各フレームワーク・言語向けのテンプレートが山ほど出てきますよね。自分でゼロから書かなくても、参考になるものがたくさんある。室谷代表的なのが
awesome-cursorrules というGitHubリポジトリで、さまざまなフレームワーク向けのルール集が集まっています。React, Next.js, FastAPI, Django, Laravel など主要なものはほぼ揃っています。テキトー教師ただ、これらはあくまで「参考」で、そのままコピーするのは推奨しません。自分のプロジェクトのスタック、チームの規約、使っているバージョンに合わせてカスタマイズする必要があります。
室谷海外のテンプレートをベースに、「このプロジェクトではこういう規約がある」という部分を上書きするイメージですよね。
テキトー教師チームで Cursor Rules を GitHub 管理するメリットは3つあります。
- 全員が同じ AI 動作になる
- ルールの変更が PR でレビューできる
- 新メンバーが入ったときに設定不要
室谷3番目が地味に大きくて・・・。onboarding コストが下がるんですよね。
「クローンしてCursorで開くだけでAIがプロジェクトの規約を知っている状態になる」というのは快適です。
「クローンしてCursorで開くだけでAIがプロジェクトの規約を知っている状態になる」というのは快適です。
Cursor Rules を Git 管理する際の設定
テキトー教師.gitignore に .cursor/ を入れてしまっているプロジェクトが結構あります。これだと Rules が共有されないので注意が必要です。# .gitignore での正しい設定
# NG（全員のCursor設定がgit管理されてしまう）
# .cursor/
# 推奨（rulesだけ共有、settings等は除外）
.cursor/settings/
.cursor/rules/ は共有したいけど、個人の Cursor 設定（.cursor/settings/）は共有したくない、という使い分けが必要ですよね。Cursor Rulesが効かないときのトラブルシューティング
テキトー教師ここで困っている人が多いですよね。「ルールを設定したのに動かない」という問題。
よくある原因をまとめましょう。
よくある原因をまとめましょう。
室谷私も最初にハマりました。整理するとこういうパターンが多いですね。
よくある問題と解決法
問題1：Auto Attached ルールが発動しない
原因は glob パターンが実際のファイルパスと一致していないケースがほとんどです。
対処法：
- ファイルの実際のパスを確認する（
src/app/なのかapp/なのか） - glob パターンに
/を先頭に付けていないか確認 - 配列形式で複数パターンを指定しているか確認
# NG
globs: "/src/components/**/*.tsx"
# OK
globs: "src/components/**/*.tsx"
# OK（複数パターン）
globs: ["src/components/**/*.tsx", "app/components/**/*.tsx"]
ファイルパス確認が基本ですよね。VSCodeのファイルツリーで確認して、そのまま書けば大体合います。
問題2：Agent Requested ルールが読み込まれない
description の書き方が曖昧すぎるケースです。
対処法：
- 「〇〇するとき」という具体的な状況で書く
- 動詞を使う（「実装する」「設定する」「作成する」）
- 固有名詞（ライブラリ名、機能名）を入れる
# NG（曖昧すぎる）
description: "データベース関連"
# OK（具体的）
description: "Supabaseのテーブル設計、RLS設定、クエリを書くとき"
問題3：ルールはあるのに AI が無視している
原因：ルールが長すぎて重要な指示が埋もれている。
対処法：
- Always ルールは200字以内に絞る
- 重要な指示を先頭に書く
- ルールファイルを分割する
室谷ルールに何でも書きすぎると、本当に大事な指示が後ろに埋もれちゃうんですよね。AIもコンテキストの優先度があるので、ルールは短く核心だけ書くのが正解です。
問題4：複数のルールが競合している
異なるルールが矛盾した指示をしていると、AI が混乱します。
対処法：
- ルール一覧を見直して、矛盾した指示がないか確認
- 同じトピックについて複数の場所で書かない
- より具体的な方のルール（Auto Attached）が Always より優先される
テキトー教師「常時ルールでは TypeScript を使うと書いてあるのに、別のルールでは JavaScript で書くと書いてある」みたいな矛盾、意外に気づかずに起きてたりしますよね。定期的に全ルールを見渡すことが大事です。
「Generate Cursor Rules」コマンドで自動生成
室谷Cursorには「Cursor Rules を自動生成する」コマンドがあって、これも使えますよね。
テキトー教師コマンドパレット（Cmd+Shift+P）で「Generate Cursor Rules」と打つと出てきます。現在開いているプロジェクトを見て、自動でルールの草案を作ってくれます。
室谷最初の取っ掛かりとして優秀なんですよね。ゼロから書くより、自動生成されたものをベースに修正する方が速い。
テキトー教師「チャットで作業していて気づいた改善点を、そのままルールに変換する」という使い方も便利ですよ。「この指示をCursor Rulesに追加して」とCursorに頼むと、既存のルールファイルを更新してくれます。
室谷AI と一緒にルールを育てていく、という感覚ですよね。最初は最小限で始めて、使いながら育てていく。
実践：Cursor Rulesを導入するステップ
テキトー教師じゃあ「今すぐ始める人向けの手順」をまとめましょう。
室谷3ステップで始められます。
Cursor Rules 導入ステップ
ステップ1：ディレクトリを作成する
mkdir -p .cursor/rules
ステップ2：最初の Always ルールを作成する
.cursor/rules/general.mdc というファイルを作成して、プロジェクトの基本情報を書く。
---
alwaysApply: true
---
# プロジェクト概要
（使っている技術スタック、言語、フレームワークを書く）
# 基本規約
（コーディング規約の中で最も重要なものだけ書く）
ステップ3：よく使うファイルタイプに Auto Attached ルールを追加する
.cursor/rules/react.mdc（Reactなら）など、メインの言語・フレームワーク用のルールを1つ追加する。
テキトー教師最初から全部完璧に揃えようとしない方がいいんですよね。まず1つ作って、「これ毎回説明してるな」と気づいたものを追加していく方が長続きします。
室谷MYUUUでも最初は
general.mdc だけでした。半年かけて5〜6ファイルに育っていった感じです。FAQよくある質問
テキトー教師受講生さんからよく来る質問をまとめましょう。
Q. .cursorrules と .cursor/rules/ の両方があったらどうなる？
室谷両方読まれますが、
.cursor/rules/ が優先されます。移行中に両方ある状態になることもありますが、最終的には .mdc に統一するのがおすすめです。Q. ルールファイルの数に上限はある？
テキトー教師公式ドキュメントには明確な上限は書かれていませんが、50ファイルを超えるような状況は整理した方がいいかもしれません。ファイル数より内容の質が大事です。
Q. チームの全員が同じバージョンの Cursor を使っていないと問題が起きる？
室谷基本的なルール機能は後方互換性があるので、バージョンが多少違っても動きます。ただし新機能を使っている場合は注意が必要です。
Q. .mdc ファイルをエディタで普通に編集できる？
テキトー教師はい、普通の Markdown ファイルとして編集できます。Cursor 内でも、VS Code でも、テキストエディタでも。
YAML フロントマターがあるだけで中身は Markdown です。
YAML フロントマターがあるだけで中身は Markdown です。
Q. User Rules に書けることと Project Rules に書けることは同じ？
室谷書ける内容は同じですが、User Rules はファイル形式ではなく Cursor の設定画面（テキストボックス）に直接書く形式です。
Auto Attached 等の細かい設定は Project Rules でしかできないです。
.mdc のフロントマターは使えません。Auto Attached 等の細かい設定は Project Rules でしかできないです。
まとめ：Cursor Rulesで AI の出力品質を底上げする
室谷今回のまとめをしましょう。Cursor Rules は「毎回説明しなくてもいい環境を作る」仕組みです。
テキトー教師ポイントをおさらいすると、こうです。
Cursor Rules のキーポイント：
.cursorrules（レガシー）より.cursor/rules/*.mdc（推奨）を使う- 4種類のルールタイプを使い分ける（Always / Auto Attached / Agent Requested / Manual）
- Always ルールは200字以内に絞る
- Auto Attached の glob パターンは実際のファイルパスに合わせて書く
.cursor/rules/は Git 管理してチームで共有する- 最初は小さく始めて、「毎回説明してること」を都度追加していく
室谷Claude CodeのCLAUDE.mdもCursor Rulesも、本質は同じです。「AIに毎回説明しなくていい状態を作る」こと。
それがAI活用の生産性を上げる最も基本的な方法なんですよね。
それがAI活用の生産性を上げる最も基本的な方法なんですよね。
テキトー教師設定に時間をかけるのが面倒に感じるかもしれませんが、長期的には圧倒的に時間を節約できます。「今日AIに同じ指示を3回した」と気づいたら、それをルールに入れる。
それだけの話です。
それだけの話です。
室谷.AI のコミュニティでも「Cursor Rules どうしてますか？」というスレッドがよく立つんですが、みんな独自のルールを持っていて面白いんですよね。ぜひ自分だけの Cursor Rules を育ててみてください。