Cursor Rules 上級設定：自分専用の AI コーディングアシスタントを作る
同じプロジェクトでも、Cursor が生成するコードは、ときに洗練されたスタイルなのに、ときにまったく習慣に合わないことがあります。.cursorrules にルールを山ほど書いたのに、AI はまるで「見て見ぬふり」。プロジェクトを変えるとまた一から設定し直し……。
初めて Cursor Rules を使ったときも、この落とし穴にはまりました。何時間もかけてルールを書いたのに、AI が生成するコードは相変わらず。後になって分かったのは、問題はルールそのものではなく、この仕組みに対する理解がすっかりずれていたことでした。
この記事では、Cursor Rules の上級テクニックを扱います。「.cursorrules とは何か」という入門ではなく、仕組みを理解したうえで実際に使いこなし、開発効率を上げるための実戦ノウハウです。
一、Cursor Rules のコアコンセプトを再構築する
1.1 .cursorrules から .cursor/rules へ：ルールシステムの進化
Cursor をしばらく使っていると、まだ従来の .cursorrules 単一ファイルを使っているかもしれません。これでも確かに動きますが、正直なところ限界はかなりはっきりしています。
単一ファイルの問題はどこにあるのか。1つは、すべてのルールが1つのファイルに詰め込まれていて、メンテナンスが面倒なこと。もう1つは、ファイル種別ごとに異なるルールを設定できないことです。たとえば、プロジェクトに React コンポーネントと Python スクリプトの両方があり、ルールを分けて書きたいとしても、単一ファイルでは無理です。
2026 年、Cursor は新しい .cursor/rules/ ディレクトリ構造を導入し、MDC 形式と組み合わせることで、これらの問題はほぼ解決しました。
新しいディレクトリ構造はこのようになります：
.cursor/
└── rules/
├── base.mdc # 基本規約
├── frontend.mdc # フロントエンドルール
├── backend.mdc # バックエンドルール
└── testing.mdc # テストルール各ファイルは独立したルールモジュールで、glob パターンで適用範囲を指定できます。たとえば frontend.mdc は .tsx ファイルにのみ効き、backend.mdc は .py ファイルにのみ効きます。
移行も難しくありません。古いプロジェクトの .cursorrules はそのまま使え、新しいプロジェクトは新形式をそのまま使えばよいだけです。古いプロジェクトをアップグレードしたいなら、単一ファイルを複数の .mdc ファイルに分割すればよく、後方互換なので問題が起きる心配はありません。
1.2 3種類のルールの正しい使い分け
Cursor のルールシステムは3種類に分かれており、多くの人がその関係を把握できていません。
Project Rules（プロジェクトルール） は .cursor/rules/ ディレクトリに置き、現在のプロジェクトにのみ効きます。プロジェクト固有のことを書くのに向いています。たとえば React 18 + Tailwind を使っているなら、技術スタックの宣言をここに置きます。チームの他のメンバーがプロジェクトを clone すると、自動的にこれらのルールを使えます。
Team Rules（チームルール） はクラウドに保存され、チームメンバーで共有します。チームのコーディング規約を置くのに向いています。たとえば「すべてのコンポーネントは名前付きエクスポートを使う」「API レスポンス形式を統一する」など。利用には Cursor の Team プランが必要です。
User Rules（ユーザールール） は Cursor の設定で構成し、あなたのすべてのプロジェクトに効きます。個人の好みを置くのに向いています。たとえばインデントは Tab か空白か、コメントは日本語か英語か、といったことです。
優先度はこうなっています：User Rules が最も高く、次に Team Rules、最後に Project Rules。つまり、User Rules に「空白でインデント」と書き、Project Rules に「Tab でインデント」と書いた場合、最終的には User Rules が優先されます。
1.3 ルールが効く仕組み
この部分は少し技術寄りですが、理解しておくとルールを書くうえで大いに役立ちます。
AI はあなたのリクエストを処理する際、ルールファイルの内容をコンテキストの一部としてモデルに「与え」ます。つまりルールはトークンを消費するということです。だからルールは長ければよいわけではなく、無駄なことを山ほど書いてもトークンを浪費するだけで、効果はかえって悪くなります。
ファイルのパターンマッチング（globs）の仕組みは .gitignore に似ています。["**/*.tsx"] と書けばすべての tsx ファイルに一致し、["app/api/**/*"] と書けば app/api ディレクトリ配下のすべてのファイルに一致します。
複数のルールが同じファイルに効く場合はどうなるのか。Cursor はファイル名の辞書順で読み込み、先に読み込まれたルールの優先度が高くなります。そのため、00-base.mdc、01-frontend.mdc のように数字のプレフィックスで読み込み順を制御できます。
二、実戦設定：ゼロからイチまでの完全ガイド
2.1 基本設定：React + TypeScript プロジェクト
まずはシンプルな React プロジェクトから始めましょう。以下は完全なルール設定で、そのまま .cursor/rules/react.mdc にコピーできます：
---
description: React + TypeScript プロジェクトルール
globs: ["**/*.{ts,tsx}"]
---
# 技術スタック
- React 18+
- TypeScript 5.0+
- Tailwind CSS
# コードスタイル
- 関数コンポーネントを使い、function キーワードで宣言する
- TypeScript のインターフェースで Props を定義する
- コンポーネントのファイル構造：exported component → subcomponents → helpers → types
- 名前付きエクスポートを使い、default export を避ける
# React のベストプラクティス
- 可能なら Server Components を優先する（Next.js の場合）
- 状態管理は useState と useReducer を使う
- 副作用は useEffect を使い、クリーンアップ関数を忘れずに書く
- パフォーマンスに敏感なコンポーネントは React.memo で最適化する
# エラー処理
- early return パターンを優先する
- 境界ケースは guard clauses で処理する
- ユーザーにわかりやすいエラー表示をし、生のエラーをそのまま投げないこのルールの構造はとてもシンプルです。まず技術スタックを宣言して AI に使っているフレームワークを知らせ、次にコードスタイルで望む書き方を伝え、最後にベストプラクティスとエラー処理で具体的な指針を与えます。
2.2 上級設定：Next.js 14 のフルスタックプロジェクト
Next.js プロジェクトはフロントとバックの両方が関わるため、もう少し複雑になります。モジュール式でルールを整理するのがおすすめです：
.cursor/
└── rules/
├── base.mdc # 基本規約
├── api.mdc # API ルートのルール
├── components.mdc # コンポーネントのルール
├── database.mdc # データベースのルール
└── testing.mdc # テストのルールapi.mdc の例を見てみましょう：
---
globs: ["app/api/**/*.{ts,tsx}"]
---
# API ルート規約
- Route Handlers (app/api/) を使う
- すべてのレスポンスに統一の APIResponse 型を使う
- Zod でリクエストパラメータを検証する
- エラー処理は next-safe-action を使う
# レスポンス形式
- GET リクエスト：{ success: boolean, data?: T, error?: string } を返す
- POST リクエスト：入力検証 → 処理ロジック → レスポンス返却
- エラー分類：検証エラー、業務エラー、システムエラーをそれぞれ処理するこうする利点は、API 関連のルールが app/api/ ディレクトリ配下のファイルを編集するときだけ効くことです。コンポーネントを書いているときに、AI が API 関連の提案を山ほど出してくることはありません。
2.3 高度な設定：Python FastAPI バックエンドプロジェクト
バックエンドを Python で書いている場合、ルールの書き方は少し変わります：
---
description: Python FastAPI プロジェクトルール
globs: ["**/*.py"]
---
# 技術スタック
- Python 3.12+
- FastAPI 0.100+
- SQLAlchemy 2.0
- Pydantic v2
# コードスタイル
- Black でコードをフォーマットする
- isort でインポートを並べ替える
- type hints を書く、手を抜かない
- 関数の命名は snake_case を使う
# FastAPI のベストプラクティス
- 依存性注入でデータベース接続を管理する
- Pydantic モデルで入力を検証する
- background tasks で非同期タスクを処理する
- 統一されたエラー処理ミドルウェアを実装する
# データベース
- SQLAlchemy 2.0 の非同期 API を使う
- Alembic でデータベースマイグレーションを管理する
- 論理削除と監査ログを実装するPython プロジェクトのルールのポイントは、スタイルツール（Black、isort）と型ヒントです。AI はコードを生成する際、これらの規約に自動的に従います。
2.4 チーム協業の設定：複数人プロジェクトの管理
あなたがチームの Tech Lead で、チームのコーディングスタイルを統一したいなら、このように整理できます：
プロジェクトルート/
├── .cursor/
│ └── rules/
│ ├── README.md # ルールの使い方説明
│ ├── base.mdc # グローバル基本規約
│ ├── frontend.mdc # フロントエンドルール
│ ├── backend.mdc # バックエンドルール
│ └── team-guidelines.mdc # チーム規約
└── .cursorrules # 後方互換（任意）いくつかの実践的なアドバイス：
ルールをバージョン管理に含める。こうすれば各自がプロジェクトを clone するだけで使え、追加の設定が要りません。
各ルールファイルにコメントで説明を加える。新メンバーがチームに加わったとき、ルールファイルを見ればチームのコーディング規約を理解できます。
定期的にルールをレビューして更新する。プロジェクトは進化するので、ルールもそれに合わせて変えていく必要があります。イテレーションごとにルールの効果を振り返ることをおすすめします。
三、デバッグと最適化：ルールを本当に効かせる
3.1 ルールのデバッグのコツ
ルールを書いたのに AI がルールに従わない？これは最もよくある問題です。以下は私がまとめた診断チェックリストです：
1. ファイルの配置を確認する
ルールファイルは正しいディレクトリに置く必要があります：
.cursor/rules/ディレクトリの下（推奨）- またはプロジェクトルートの
.cursorrulesファイル
配置が間違っていると、AI はそもそも読み込めません。
2. glob パターンを確認する
globs の設定を間違えると、ルールは効きません。Cursor でファイルを開き、AI に直接「現在どのルールが読み込まれているか教えてください」と尋ねます。AI がどのルールを認識しているか教えてくれます。
3. YAML 形式を確認する
MDC ファイル冒頭の frontmatter は YAML 形式です。インデントの間違いやコロンの抜けがあると、解析に失敗します。
4. ルールの衝突を確認する
複数のルールが互いに衝突しているかもしれません。2つのルールが同じことに異なる要求をしていないか確認し、見つかったら統合すればよいです。
3.2 ルールの最適化戦略
ルールは多く書けば書くほどよい、と思っている人が多いですが、実はそうではありません。ルールが長すぎると、AI はかえって「消化不良」を起こします。
原則一：簡潔第一
最も重要なルールを前に置きます。AI もルールを先頭から末尾へ読むので、前にある内容のほうが記憶されやすいです。
原則二：具体的で明確に
比べてみましょう：
曖昧な書き方：
# コードスタイル
- 簡潔なコードを書く
- ベストプラクティスを使う
- パフォーマンスに注意する具体的な書き方：
# コードスタイル
- 関数コンポーネントを使い、class コンポーネントを避ける
- early return パターンを使い、ネストを減らす
- パフォーマンスに敏感なコンポーネントは React.memo でラップする
- ループ内でインライン関数を書くのを避ける2つ目の書き方なら、AI は何をすべきか明確に分かります。1つ目の書き方では、AI は「推測」するしかありません。
原則三：階層的に整理する
「技術スタック → コードスタイル → ベストプラクティス → エラー処理」の順で整理します。論理が明確で、AI も理解しやすくなります。
原則四：継続的に改善する
ルールは書いて終わりではありません。しばらく使い、AI が生成するコードの品質が上がったか確認し、よくないところは調整します。
3.3 ルールの効果評価
ルールが役立っているかどうかをどう知るか。次のいくつかの指標を見ます：
- 一発通過率：AI が生成したコードのうち、そのまま使える割合はどのくらいか？
- スタイルの一貫性：異なる時点で生成されたコードのスタイルは統一されているか？
- バグの数：ルールが効いたあと、バグは減ったか？
- 開発効率：コードを書くのが速くなったか？
これらの指標を記録し、ルール導入の前後を比べれば、ルールが本当に役立っているかどうかが分かります。
四、2026 年の最新実践：MDC 形式とモジュール化
4.1 MDC 形式の詳細解説
MDC は Cursor が導入した新しいルール形式で、従来の .cursorrules よりずっと柔軟です。
ファイル構造はこのようになります：
---
description: ルールの説明（任意）
globs: ["ファイルマッチングパターン"]
alwaysApply: false（任意、デフォルトは false）
---
# ルール内容
具体的なルール内容をここに書きます……description は人が読むためのもので、このルールの用途を理解しやすくします。
globs はファイルマッチングパターンで、ルールがどのファイルに効くかを決めます：
["**/*.tsx"]— すべての tsx ファイルに一致["app/api/**/*"]— app/api ディレクトリ配下のすべてのファイルに一致["*.test.{ts,tsx}"]— テストファイルのみに一致
alwaysApply を true にすると、ルールは常に効き、ファイルマッチングの制限を受けません。一般的には推奨されません。トークンを浪費するからです。
4.2 モジュール式ルールアーキテクチャ
大型プロジェクトでは、より細かいモジュール式構造がおすすめです：
.cursor/
└── rules/
├── 00-base.mdc # 基本規約
├── 01-tech-stack.mdc # 技術スタック宣言
├── 02-code-style.mdc # コードスタイル
├── 10-frontend/ # フロントエンドルール（サブディレクトリ）
│ ├── react.mdc
│ └── tailwind.mdc
├── 20-backend/ # バックエンドルール（サブディレクトリ）
│ ├── api.mdc
│ └── database.mdc
└── README.md # ルール使用ドキュメント数字のプレフィックスで読み込み順を制御します。00- で始まるものが先に、10- のものが後に読み込まれます。こうして基本規約を先に効かせられます。
サブディレクトリはより細かい管理に対応します。フロントエンドルールは 10-frontend/、バックエンドルールは 20-backend/ に置けば、探しやすくなります。
4.3 ルール生成ツールのおすすめ
ゼロからルールを書きたくない？手伝ってくれるコミュニティツールがいくつかあります：
cursor.directory — オンラインのルールライブラリ。各種フレームワークのテンプレートがあり、そのままコピーできます。
cursorrules.org — 対話式のルールジェネレーター。いくつかの質問に答えると、自動でルールファイルを生成します。
awesome-cursorrules — GitHub にある厳選ルール集。100以上のテンプレートがあり、20以上のフレームワークをカバーします。
ただし、テンプレートから始めつつもプロジェクトに合わせてカスタマイズすることをおすすめします。丸写しはせず、ルールの背後にある原理を理解してこそ、本当に自分に合ったルールを書けます。
五、まとめと行動の提案
5.1 すぐ始めるチェックリスト
今すぐ始めたいなら、この手順でどうぞ：
第一歩：プロジェクトの種類を決める。React？Next.js？Python？それとも別のもの？
第二歩：コミュニティテンプレートから近いものを1つ選ぶ。cursor.directory や awesome-cursorrules にあります。
第三歩：プロジェクトの特性に合わせてカスタマイズする。技術スタックのバージョンを変え、自分の習慣をいくつか加えます。
第四歩：効果をテストする。コードをいくつか書いて、AI が生成するコードが期待により合っているか確認します。
第五歩：チームで共有する。効果がよければ、ルールをバージョン管理にコミットして、チームみんなで使います。
5.2 落とし穴回避ガイド
最後に、私がはまった落とし穴をいくつか：
ルールが大ざっぱすぎる — AI はあなたが何を望むのか分かりません。もっと具体的に書きましょう。
ルールファイルが長すぎる — 200 行以内がよいです。長すぎると AI は読み切れません。
テストせずに使う — まず小さな範囲で検証し、有効だと確認してから全面展開しましょう。
まったく更新しない — プロジェクトは変わるので、ルールもそれに合わせて変えます。定期的に振り返りましょう。
5.3 さらに学ぶためのリソース
もっと深く知りたいなら、これらのリソースが参考になります：
- Cursor 公式ドキュメント — 最も権威のある説明
- awesome-cursorrules — コミュニティ厳選ルール
- Cursor コミュニティフォーラム — 問題の議論と経験の共有
さあ、あなたのプロジェクトを開いて、最初の Cursor Rules を設定してみましょう。シンプルなものから始めて、少しずつ充実させていきます。AI がどんどん「あなたを分かってくれる」ようになるのに、きっと驚くはずです。
Cursor Rules の上級ルールを設定する
ゼロからプロジェクトにモジュール式の Cursor Rules を設定し、AI コーディングアシスタントの理解力を高める
⏱️ 目安時間: 30 分
- 1
ステップ1: ルールのディレクトリ構造を作る
プロジェクトのルートに .cursor/rules/ ディレクトリを作成します：
```bash
mkdir -p .cursor/rules
```
古い .cursorrules から移行する場合は、まず元のファイルを残しておきます。新旧の形式は共存できます。 - 2
ステップ2: 基本ルールファイルを作る
base.mdc ファイルを作り、プロジェクトの基本規約を定義します：
```markdown
---
description: プロジェクト基本規約
globs: ["**/*"]
---
# プロジェクト情報
- プロジェクト名：あなたのプロジェクト名
- 技術スタック：主要な技術を列挙
# 共通規約
- コードスタイルの要点
- 命名規約
- コメント規約
```
このファイルはすべてのファイルに適用されます。 - 3
ステップ3: ファイル種別ごとに専用ルールを作る
特定のファイル種別向けのルール、たとえば frontend.mdc を作ります：
```markdown
---
globs: ["**/*.{ts,tsx}"]
---
# フロントエンドルール
- コンポーネント規約
- 状態管理の取り決め
- スタイル規約
```
globs は複数のパターンに対応します：`["**/*.ts", "**/*.tsx"]` - 4
ステップ4: ルールが効いているか確認する
Cursor で対象ファイルを開き、AI に直接尋ねます：
「現在どのルールが読み込まれているか教えてください」
AI が認識したルールファイルを列挙します。何も出ない場合は次を確認してください：
- ファイルの配置が正しいか
- glob パターンが現在のファイルに一致しているか
- YAML 形式に構文エラーがないか - 5
ステップ5: バージョン管理に含める
ルールを Git にコミットします：
```bash
git add .cursor/rules/
git commit -m "feat: add cursor rules configuration"
```
チームメンバーがプロジェクトを clone すると、ルール設定が自動的に手に入ります。
FAQ
Cursor Rules のルールファイルはどのディレクトリに置くべきですか？
.cursorrules と .cursor/rules/ の違いは何ですか？
なぜ私のルールが効かないのですか？
• ファイルの配置が間違っている — `.cursor/rules/` かルートの `.cursorrules` に置く必要がある
• glob パターンの記述ミス — 現在のファイルに一致していない
• YAML frontmatter の形式が不正
• ルール内容が長すぎる、または曖昧すぎて AI がうまく理解できない
Cursor で AI に直接「現在どのルールが読み込まれているか教えてください」と尋ねて診断できます。
ルールファイルはどのくらいの長さが適切ですか？
User Rules、Team Rules、Project Rules の優先度はどうなっていますか？
MDC 形式の globs はどう書きますか？
• `["**/*.tsx"]` — すべての tsx ファイルに一致
• `["app/api/**/*"]` — app/api ディレクトリ配下のすべてのファイルに一致
• `["*.test.{ts,tsx}"]` — テストファイルのみに一致
• `["**/*.ts", "**/*.tsx"]` — 複数のファイル種別に一致
配列の形式で複数のパターンを書けます。
すぐ使えるルールテンプレートはありますか？
6分で読めます · 公開日: 2026年3月20日 · 更新日: 2026年6月15日
Cursor 完全ガイド
検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。
前の記事
Cursor Rules 完全ガイド：プロジェクト規範に沿ったコードを AI に書かせる（実戦設定付き）
5 分で Cursor Rules を設定し、AI が生成するコードをプロジェクト規約に完全準拠させる方法。設定手順、実戦例、2026 年の最新機能まで、初心者でも迷わず設定できます。
第 5 / 25 記事
次の記事
Cursor Agent 大規模プロジェクト実践：ファイルが見つからない・コード修正ミスの 7 つの対処法
深夜のトラブルからまとめた実践テクニック。コンテキスト管理、タスク分割、コードレビューまで、大規模プロジェクトで Agent の成功率を 50% から 90% へ引き上げる方法。
第 7 / 25 記事
関連記事
もう使い方を間違えるな！Cursor 3 機能の正しい開き方
もう使い方を間違えるな！Cursor 3 機能の正しい開き方
Cursor Agent モード完全ガイド：3 ステップで始める自動化プログラミング（2026 年最新）
Cursor Agent モード完全ガイド：3 ステップで始める自動化プログラミング（2026 年最新）
Cursor Agent Mode 完全ガイド：AI アシスタントにプログラミングを任せる
コメント
GitHubアカウントでログインしてコメントできます