Cursor使っているけど、もっと楽に文章少なく指示出して反映できるようにしたい・・・
特に作業量が多いエンジニアの皆さんはそう思うことが少なくないと思います。
そんな時に効くのがCursor Rulesです。ルールを一度定義すれば、コーディング規約・回答スタイル・ワークフローを継続的に適用できます。
この記事では、最新仕様に対応したCursor Rulesテンプレートを、実務でそのまま使える形でまとめました。コピペして少し調整するだけで導入できます。
まず押さえる最新仕様（2026年版）
- 推奨は
.cursor/rules/配下で管理（.md/.mdc） .cursorrulesはレガシー（非推奨・移行推奨）AGENTS.mdはシンプル代替として利用可能CLAUDE.mdもCursorで読み取り可能（互換運用）- Rulesは主にAgent（Chat）向け。Tab/Inline Editには非適用
.cursor/rules を前提に作るのが安全です。既存の .cursorrules は早めに移行しましょう。
Rulesの基本構造（コピペ用）
.mdc（frontmatterあり）の最小テンプレ
---
description: "プロジェクト共通ルール"
alwaysApply: false
globs: ["**/*.{ts,tsx,js,jsx}"]
---
- 変更理由を必ず説明する
- 既存スタイルに合わせる
- 破壊的変更は提案前に確認する
適用タイプの使い分け
| タイプ | 向いている用途 | 例 |
|---|---|---|
| Always Apply | 全会話で必ず守る方針 | 日本語回答、命名規約 |
| Apply Intelligently | 関連時だけ適用 | テスト追加時の方針 |
| Apply to Specific Files | ファイル種別で制御 | **/*.tsx だけUIルール |
| Apply Manually | 必要時に手動呼び出し | @review-rule |
コピペで使えるテンプレート15選
1) 回答言語固定（日本語）
- すべての回答は日本語で行う
- 専門用語は必要に応じて補足する
- 変更理由を簡潔に説明する
2) TypeScript厳格運用
- anyの使用は禁止。必要なら型を定義する
- exportする関数には戻り値型を明示する
- 型エラーを放置せず修正して完了する
3) Reactコンポーネント規約
- 関数コンポーネントを使用する
- Props型を先頭で定義する
- 副作用はuseEffectで最小化する
4) API実装ルール
- 入力バリデーションを必須化する
- エラーレスポンス形式を統一する
- 失敗時のログ方針を守る
5) テスト追加ルール
- 新規機能には最低1つのテストを追加する
- 正常系/異常系を1ケースずつ含める
- 既存テストを壊す変更は避ける
6) セキュリティ注意ルール
- .envや秘密情報を出力・変更しない
- 認証/権限チェックを省略しない
- 外部入力は必ず検証する
7) Git運用ルール
- コミット前に差分要約を提示する
- 破壊的変更は事前確認する
- 変更対象外ファイルを不用意に触らない
8) UI文言ルール
- ボタンラベルは動詞で始める（例：「保存する」「削除する」）
- エラーメッセージはユーザーが次に何をすべきか含める
- placeholder は入力例を記載する（例：「例：tanaka@example.com」）
9) コメント方針ルール
- コメントは日本語で書く
- 「何をしているか」ではなく「なぜそうしているか」を書く
- TODOコメントには担当者と期限を記載する（例：// TODO(yamada): 2026-04末までに対応）
10) パフォーマンス優先ルール
- 不要な再レンダリングを避ける（React.memo / useMemo / useCallback を適切に使用）
- N+1クエリが発生しない設計にする
- 画像はWebP形式・遅延読み込みを基本とする
11) 例外処理統一ルール
- try-catchは最小範囲で使用する
- catchブロックでは必ずログ出力する
- ユーザー向けエラーと開発者向けエラーを分離する
- 空のcatchブロックは禁止
12) ログ設計ルール
- ログレベルを正しく使い分ける（error / warn / info / debug）
- APIリクエスト・レスポンスはinfoレベルで記録する
- 個人情報・トークン・パスワードをログに含めない
- 構造化ログ（JSON形式）を使用する
13) PR説明テンプレ生成ルール
- PRの説明文を以下の形式で生成する：
## 変更内容（1行要約）
## 変更理由
## 影響範囲
## テスト方法
## レビュー観点
- 変更ファイル数が5以上の場合はファイル一覧も含める
14) ドキュメント更新ルール
- API変更時はREADMEまたはAPI仕様書を同時に更新する
- 環境変数を追加した場合は.env.exampleも更新する
- 破壊的変更はCHANGELOGに記録する
15) リファクタリング専用ルール
- 機能変更とリファクタリングを同一コミットに混ぜない
- リファクタリング前後でテストが全パスすることを確認する
- 変更前の挙動を維持する（外部インターフェースを変えない）
- 大規模リファクタは計画を提示してから実行する
上記15個のテンプレートは、プロジェクトに合わせて個別ルールファイルに分割すると管理しやすくなります（1ファイル1テーマ推奨）。
おすすめ構成（そのまま使える）
.cursor/rules/
00-global-language.mdc
10-typescript.mdc
20-react.mdc
30-api.mdc
40-testing.mdc
50-security.mdc
移行ガイド（.cursorrules → .cursor/rules）
- 既存
.cursorrulesの内容をコピー .cursor/rules/legacy-migrated.mdcを作成alwaysApply: trueで挙動を合わせる- 内容を分割して用途別ルールへ整理
.cursorrulesを削除
実体験
★ 実体験①：最初に効いたルール
「日本語回答 + 変更理由説明」をAlways Applyにしただけでレビュー効率が上がった。
★ 実体験②：失敗したルール設計
一気に大量のファイルを読み込ませようとするとクラッシュしたのでこまめに分けて読み込ませた
よくある質問
Q. .cursorrulesはもう使えませんか？
A. 現時点で読まれるケースはありますが、非推奨です。新規は`.cursor/rules`を推奨します。
Q. Rulesはどの機能に効きますか？
A. 主にAgent（Chat）です。Tab補完やInline Editには基本適用されません。
Q. AGENTS.mdと併用できますか？
A. 可能です。シンプル運用はAGENTS.md、細かい制御はRulesと使い分けると効果的です。
Q. チームで統一するには？
A. `.cursor/rules`をGit管理し、必要ならTeam Rulesで強制適用すると運用が安定します。
■ プログラミングを本格的に学びたい方へ
Cursor Rulesを最大限活用するにはプログラミングの基礎があると効果が何倍にもなります。Winスクールなら、Python・JavaScript・AIプログラミングなど300以上の講座から選べて、プロ講師の個人レッスンで指導。給付金対象講座なら最大70%還元。
※ オンラインでも参加OK。無理な勧誘はありません
■ おすすめ書籍
まとめ：まずは3ルールから始める
最初は次の3つだけで十分です。
- 回答言語・説明方針（Always Apply）
- 言語/フレームワーク規約（Specific Files）
- テスト・セキュリティ方針（Intelligently）
運用しながら「同じミスが繰り返されるポイント」をルール化していくと、Cursorの品質と一貫性が大きく上がります。
