Cursor Rules 上級設定：自分専用のAIプログラミングアシスタントを作る
こんな経験ありませんか？同じプロジェクトでも、Cursorが生成するコードは時にはエレガントで自分のスタイルに合っているのに、時には全く違う書き方になることがあります。.cursorrulesにルールを書いたのに、AIが「見て見ぬふり」をする。さらに困るのは、プロジェクトを変えるたびに設定し直さないといけないこと……
正直、私も最初にCursor Rulesを使った時は同じ失敗をしました。何時間もかけてルールを書いたのに、AIが生成するコードは変わらない。後で分かったのは、問題はルールそのものではなく、このシステムの理解が完全に間違っていたということです。
この記事では、Cursor Rulesの上級テクニックを紹介します。「.cursorrulesとは何か」という入門編ではなく、このツールを本当に使いこなすための実践的な経験をお伝えします。
1. Cursor Rulesのコア概念を再構築
1.1 .cursorrulesから.cursor/rulesへ：ルールシステムの進化
Cursorをしばらく使っているなら、従来の.cursorrules単一ファイルを使っているかもしれません。確かに動きますが、正直なところ、限界は明らかです。
単一ファイルの問題は何か？まず、すべてのルールが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. 実践設定：ゼロからイチへの完全ガイド
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が使用しているフレームワークを把握し、次にコードスタイルを指定して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. デバッグと最適化：ルールを本当に有効にする
3.1 ルールデバッグのコツ
ルールを書いたのにAIが従わない？これが最も一般的な問題です。私がまとめた診断チェックリストはこれです：
1. ファイルの場所を確認
ルールファイルは正しいディレクトリにある必要があります：
.cursor/rules/ディレクトリ（推奨）- またはプロジェクトルートの
.cursorrulesファイル
場所が間違っていると、AIは読み込めません。
2. glob パターンを確認
globsの設定が間違っていると、ルールは有効になりません。Cursorでファイルを開き、AIに直接聞いてみてください：「現在読み込まれているルールを教えて」AIが見ているルールを教えてくれます。
3. YAML フォーマットを確認
MDCファイルの先頭のfrontmatterはYAML形式です。インデントが間違っていたり、コロンが抜けていたりすると、パースに失敗します。
4. ルールの競合を確認
複数のルールが競合している可能性があります。同じことに対して異なる要件を持つ2つのルールがないか確認し、マージしてください。
3.2 ルール最適化戦略
多くの人がルールは長ければ長いほど良いと思っています。実は違います。ルールが長すぎると、AIは「消化不良」を起こします。
原則1：簡潔さ第一
最も重要なルールを先に置く。AIはルールを最初から最後まで読むので、前の内容ほど覚えられやすくなります。
原則2：具体的に
2つのアプローチを比較してみましょう：
❌ 曖昧な書き方：
# コードスタイル
- 簡潔なコードを書く
- ベストプラクティスを使用
- パフォーマンスに注意✅ 具体的な書き方：
# コードスタイル
- 関数コンポーネントを使用、クラスコンポーネントは避ける
- early return パターンを使用、ネストを減らす
- パフォーマンス敏感なコンポーネントは React.memo でラップ
- ループ内でインライン関数を避ける2番目の書き方なら、AIは何をすべきか明確に分かります。1番目の書き方は、AIは「推測」するしかありません。
原則3：レイヤー構成
「技術スタック → コードスタイル → ベストプラクティス → エラー処理」の順で整理。ロジックが明確で、AIも理解しやすくなります。
原則4：継続的改善
ルールは書いて終わりではありません。しばらく使って、AIが生成するコードの品質が上がったか確認し、悪いところは調整してください。
3.3 ルールの効果評価
ルールが役に立っているかどうかを知るには？これらの指標を見てください：
- 一次通過率：AIが生成したコードが、そのまま使える割合はどれくらい？
- スタイル一貫性：異なる時期に生成されたコードのスタイルは統一されている？
- バグ数：ルールが有効になった後、バグは減った？
- 開発効率：コーディングは速くなった？
これらの指標を記録し、ルール使用前後の変化を比較すれば、ルールが本当に役立っているか分かります。
4. 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. まとめとアクションプラン
5.1 クイックスタートチェックリスト
今すぐ始めたいなら、このステップに従ってください：
ステップ1：プロジェクトタイプを決定。React？Next.js？Python？それとも他？
ステップ2：コミュニティから近いテンプレートを選択。cursor.directoryまたはawesome-cursorrulesにあります。
ステップ3：プロジェクトの特徴に合わせてカスタマイズ。技術スタックのバージョンを変更し、自分の好みを追加。
ステップ4：効果をテスト。いくつかコードを書いて、AIが生成するコードが期待に近づいたか確認。
ステップ5：チームと共有。効果が良ければ、ルールをバージョン管理にコミットして、チーム全体で使えるように。
5.2 避けるべき落とし穴
最後に、私が経験した落とし穴をいくつか紹介します：
❌ ルールが曖昧すぎる — AIは何を望んでいるか分からない。具体的に書く。
❌ ルールファイルが長すぎる — 200行以内に抑える。長すぎるとAIが読みきれない。
❌ テストせずに使用 — まず小規模で検証し、効果を確認してから本格的に導入。
❌ 更新しない — プロジェクトは変わる、ルールも変わる必要がある。定期的に見直す。
5.3 さらなる学習リソース
より深く理解したい場合は、これらのリソースをチェック：
- Cursor公式ドキュメント — 最も権威ある説明
- awesome-cursorrules — コミュニティのキュレートされたルール
- Cursorコミュニティフォーラム — 問題の議論と経験の共有
今すぐプロジェクトを開いて、最初のCursor Rulesを設定してみましょう。シンプルなところから始めて、徐々に改良していく。AIがますます「あなたを理解する」ようになることに驚くはずです。
FAQ
Cursor Rulesの3つのタイプの違いは何ですか？
なぜ.cursorrulesのルールが効かないのですか？
• ファイルの場所が間違っている — プロジェクトルートディレクトリにある必要があります
• globパターンの設定が間違っている — ファイルマッチングが正しいか確認
• YAMLフォーマットエラー — frontmatterのインデントと構文を確認
• ルールの競合 — 同じことに対して異なる要件を持つ複数のルールがないか確認
CursorでAIに直接聞くことができます：「現在読み込まれているルールを教えて」問題を診断できます。
MDCフォーマットと従来の.cursorrulesの違いは何ですか？
ルールファイルはどのくらいの長さが良いですか？
ルールの効果をどう評価しますか？
• 一次通過率 — AIが生成したコードがそのまま使える割合
• スタイル一貫性 — 異なる時期に生成されたコードのスタイルが統一されているか
• バグ数 — ルールが有効になった後、バグが減ったか
• 開発効率 — コーディングが速くなったか
2週間かけてデータを比較し、ルールの実際の価値を定量化してください。
5 min read · 公開日: 2026年3月20日 · 更新日: 2026年3月22日
関連記事
Computer-Use Agent：AIにあなたのPCを操作させる
Computer-Use Agent：AIにあなたのPCを操作させる
RAG + Agent：次世代 AI アプリケーションアーキテクチャ
RAG + Agent：次世代 AI アプリケーションアーキテクチャ
エージェントツール呼び出し実践：AIに外部APIとサービスを呼び出させる
コメント
GitHubアカウントでログインしてコメントできます