Cursor Rules（プロジェクトルール）設計のベストプラクティス｜レビュー負荷を下げる書き方（例付き・要公式確認）

AIコードエディタとして急速に普及している「Cursor」。その真価を最大限に引き出し、開発チーム全体の生産性を底上げする鍵が「Cursor Rules（プロジェクトルール）」の設定です。単にAIにコードを書かせる段階から、プロジェクト特有の規約やドメイン知識をAIに完全に理解させ、「自分たちのチームに最適化されたAIパートナー」へと進化させるための設計手法を解説します。

Cursor Rulesとは何か：AI開発の「品質」をリポジトリで定義する仕組み

Cursor Rulesは、プロジェクトのリポジトリ内に特定の設定ファイルを配置することで、CursorのAI（LLM）に対して「そのプロジェクト専用の指示書」を自動的に読み込ませる機能です。これを適切に設計することで、以下のような課題を根本から解決できます。

• AIがプロジェクトで不採用のライブラリ（例：AxiosではなくFetchを使いたい等）を提案してくる。
• 命名規則やディレクトリ構成が既存のコードと不一致になる。
• コードレビューで「規約違反」を指摘する不毛な時間が発生している。

プロジェクトルールをリポジトリで管理することは、「生きたドキュメント」をAIに持たせることを意味します。これにより、新人エンジニアが参加したその日から、ベテラン層と同じコーディング規約に則ったコードをAIに生成させることが可能になります。

【公式準拠】Cursor Rulesの2つの設定方法と優先順位

Cursorのアップデートにより、ルールの設定方法は大きく分けて2種類存在します。現在の推奨は、より柔軟な管理が可能な「.cursor/rules/」配下への複数ファイル配置です。

1. .cursorrules（レガシー/単一ファイル形式）

リポジトリのルートディレクトリに .cursorrules という名前のファイルを配置する形式です。全ての指示を一つのファイルに記述するため、小規模なプロジェクトには向いていますが、大規模化すると可読性が落ち、AIが情報を取捨選択しづらくなる欠点があります。

2. .cursor/rules/*.md（モダン/複数ファイル形式）

最新のCursor仕様では、.cursor/rules/ ディレクトリを作成し、その中に .md ファイルを分割して配置することが推奨されています。各ファイルに「どのような状況でこのルールを適用するか」という Context を定義できるため、AIの理解度が飛躍的に向上します。

公式の仕様変更は頻繁に行われるため、常に Cursor Official Documentation を確認することをお勧めします。

レビュー負荷を劇的に下げる「プロジェクトルール」設計の5原則

精度の高いルールを作成するためには、AIが迷わないための「構造化」が不可欠です。以下の5つの原則に従って執筆してください。

1. 技術スタックとディレクトリ構造の明示

まず、そのプロジェクトが何を使っているかを定義します。バージョンまで指定することで、AIが古いAPIを提案するミスを防げます。

例：Next.js 14 (App Router), TypeScript, Tailwind CSS, Prisma, Zod

2. コーディング規約の厳格化

曖昧な表現を避け、具体的な「正解」を提示します。

• 「関数はアロー関数で書く」
• 「コンポーネントは src/components 配下に配置し、1ファイル1コンポーネントとする」
• 「型定義には type ではなく interface を使用する」

3. XMLタグを活用した構造化記述

Markdownの中で、特定の指示を <rules> や <naming_convention> といったXML形式のタグで囲む手法が有効です。LLMはタグ構造を「強い制約」として認識しやすい傾向にあります。

4. 「やってはいけないこと」のネガティブ指示

「〜してください」だけでなく、「〜しないでください」という禁止事項を書くことで、レビュー時の指摘事項を先回りして潰せます。

• 「any 型を絶対に使用しないこと」
• 「インラインスタイルは禁止。必ずTailwindのクラスを使うこと」

こうした厳格な開発プロセスを自動化する考え方は、会計システムの自動化におけるアーキテクチャ設計にも共通します。例えば、手作業を徹底的に排除する設計思想については、こちらの記事が参考になります：楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

【実践】ディレクトリ別・役割別のルール分割例

実際に .cursor/rules/ 配下に作成するMarkdownファイルの構成例を紹介します。

global-rules.md（プロジェクト全体）

Global Rules

Apply to all files in this repository.



Maintain type safety at all times.

Follow Clean Architecture principles.




Responses must be in Japanese.

Keep explanations concise.

frontend-rules.md（フロントエンド専用）

このルールは src/app/ や src/components/ などのパスに限定して適用させます。

Frontend Guidelines

<tech_stack>

React 18, Next.js 14 (App Router)

Shadcn UI, Tailwind CSS
</tech_stack>



Use 'use client' directive only when necessary.

Implement error boundaries for all major features.

UI/UXの改善とデータ連携の最適化という観点では、LINEミニアプリとWebの統合的な設計も非常に重要です。モダンなフロントエンド開発の応用例として、以下の記事もチェックしてみてください：LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤

Cursor Rules vs Custom Instructions 比較表

設定画面から入力する「Custom Instructions」と、プロジェクトごとの「Cursor Rules」の使い分けに迷うことがあります。以下の表を参考に、責務を切り分けてください。

組織全体でのツール導入や管理の自動化を検討されている場合は、アカウント管理の自動化に関する知見も役立ちます：SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

導入手順：最短でプロジェクトルールを本番投入するステップ

STEP 1：既存コードの解析とパターンの抽出

まず、現在のリポジトリで「良い」とされているコードを数件ピックアップし、その共通パターン（命名、モジュール分割、エラーハンドリング）を言語化します。

STEP 2：.cursor/rules フォルダの作成

リポジトリのルートに .cursor/rules ディレクトリを手動で作成します。CursorのUI上からも作成可能ですが、Git管理することを忘れないでください。

STEP 3：ルールファイルの記述と検証

前述のMarkdown形式でルールを記述します。作成後、Cursorのチャット（Cmd+L）やComposer（Cmd+I）で、「このプロジェクトのコーディング規約を教えて」と質問し、作成したルールが反映されているか確認します。

STEP 4：Gitでのチーム共有

.cursor/rules を .gitignore に入れず、リポジトリにコミットします。これにより、チームメンバー全員が同じルールセットでAIを活用できるようになります。

よくあるエラーと解決策

ルールが無視される場合のチェックリスト

• ファイル形式の確認: .md 拡張子になっているか、UTF-8で保存されているかを確認してください。
• 記述の矛盾: 複数のルールファイルで相反する指示が出ていないか確認してください。
• トークン制限: ルールがあまりに長すぎると、AIが重要な指示を見失います。1ファイルあたり2,000文字程度を目安に分割してください。

コンテキスト過多によるレスポンス精度の低下

全てのルールを常に読み込ませると、肝心のソースコードを読むための枠（コンテキストウィンドウ）が狭まります。.cursor/rules/ の各ファイル冒頭に Context: path/to/files/**/* のように適用範囲を指定し、AIが必要な時だけそのルールを参照するように最適化してください。

まとめ：AIとの協働を「運任せ」にしないために

Cursor Rulesの設計は、単なる設定作業ではなく「エンジニアリング品質の定義」そのものです。AIが吐き出すコードに文句を言うのではなく、AIが正しいコードを出力できるようにガードレールを敷く。この「ルール設計」のスキルこそが、AI時代のエンジニアに求められる新しい実務能力と言えるでしょう。

まずは小さなルールからで構いません。頻繁に指摘するコードレビューの内容を .cursor/rules に書き出すことから始めてみてください。その積み重ねが、開発スピードを数倍に加速させる強力な資産となります。