Cursor Rulesの設定・書き方｜TypeScriptで使える3つのルール例

狙いは、レビューでの手直しを減らすことです。たとえば、開発者4人が毎週それぞれ3回、5分ずつ同じ規約に沿って修正しているなら、規約を繰り返し適用するだけで60分を費やしています。これは効果を考えるための例であり、その時間を必ず削減できるという意味ではありません。設定後に不要になった修正を数え、ルールの保守にかかった時間を差し引いて評価してください。サブスクリプションの費用は別の話なので、Cursorの料金で扱っています。

Cursor Rulesはどこに設定する？

チームで共有するコーディング方針は、コードと同じ場所に置きます。回答の好みなど、個人の設定は分けて管理しましょう。

サブディレクトリに置いたAGENTS.mdの指示は、そのディレクトリと配下に適用され、親ディレクトリの指示と併せて使われます。競合する場合は、より具体的な指示が優先されます。Team Rules、Project Rules、User Rulesの競合時については、公式ドキュメントでTeam → Project → Userの優先順位が示されています。Cursorのルールリファレンス

小規模なチームなら、私はまずProject Rulesを使います。「既存のフォームコンポーネントを使う」はリポジトリに属する指示です。一方、「最終回答は短くする」は個人の好みです。この2つを分けておけば、個人の好みがいつの間にかチームの方針になるのを防げます。

各ルールをいつ適用するか決める

ルール本文の上にある小さな設定ブロック、frontmatterで、ルールをコンテキストに含める条件を指定します。

「エージェントの判断で適用」とは、説明文をもとにエージェントがルールを選ぶ方式です。globはファイルパスのパターンを指します。適用条件の動作と構文

ルールの適用は、作業指示書を必要な作業台に届けることだと考えてください。どれほどよく書けた指示でも、そのタスクに届かなければ役に立ちません。セキュリティの基本事項は常に適用し、スタイルの指針は関係するファイルに渡します。エージェントによる選択は、タスクの内容によって必要かどうかが変わる指針に使いましょう。

Cursor Rulesの書き方：TypeScriptアプリに使える3つの例

リポジトリに以下のファイルを作成します。ここで示すのは、Cursorのリファレンスにあるfrontmatterのフィールドとパターン構文を使った、チーム独自の規約の例です。本文の指示は自分たちの環境に合わせて調整するためのたたき台であり、Cursorが定めたコーディング規約ではありません。

スタイル：TypeScriptファイルに適用する

.cursor/rules/style.mdcとして保存します。

---
globs: src/**/*.ts, src/**/*.tsx
alwaysApply: false
---

- Follow the nearest existing module's naming and import conventions.
- Prefer named exports unless the framework requires a default export.
- Reuse existing UI components and utilities before adding alternatives.
- Keep formatting in the repository's formatter and linter configuration.

この例は、アプリケーションのコードがsrc/配下にあることを前提としています。リポジトリに合わせてパスを調整してください。ここでは、既存のボタンや日付処理のヘルパーが使えないかといった、フォーマッターでは決められない判断を意図的に扱っています。exportについてチームで別の方針が決まっているなら、その内容に変えましょう。ルールはリポジトリの現状を記述するものです。知らないうちに設計を変える指示にしてはいけません。

テスト：必要になるタスクを説明する

.cursor/rules/tests.mdcとして保存します。

---
description: Testing requirements when adding features, fixing bugs, or changing TypeScript behavior
alwaysApply: false
---

- Cover changed behavior with a focused regression test.
- Use the existing test runner, fixtures, and file naming conventions.
- Read package.json for the relevant test script; do not invent a command.
- Report the command and actual result, or explain why tests were not run.

求める成果は、役に立つテストと、実際の結果に即した報告です。バグ修正では、元の不具合をテストで検証できる証拠を残します。リファクタリングでは、関係する振る舞いが維持されていることを確認します。どちらの場合も、別のテストフレームワークを追加したり、「テストを書いた」と「テストが通った」を混同する報告をしたりする必要はありません。

このチェックリストを確実に使いたい作業では、依頼に@testsを含めてください。チームとしてすべてのタスクに適用したいなら、適用条件をAlways Applyに変更します。これは意識して決める運用方針です。説明文だけを指定した状態では、使うかどうかの判断はエージェントに委ねられます。

セキュリティ：基本事項は短くまとめる

.cursor/rules/security.mdcとして保存します。

---
alwaysApply: true
---

- Never put secrets in source code, test fixtures, or application logs.
- Use existing server-side authentication and authorization helpers.
- Validate untrusted input at server boundaries with the existing schemas.
- Do not remove permission checks to make a feature or test pass.

リポジトリのモジュールの場所がわかっているなら、「既存のヘルパー」という表現を実際のパスに置き換えます。通常の機能開発の途中でも理解できる内容にとどめてください。「安全にする」だけでは、レビューする側は何を確認すればよいのかわかりません。「認可チェックを維持する」なら、具体的な要件になります。

このファイルは指示書であり、セキュリティを強制する仕組みではありません。コード内のアクセス制御と、セキュリティに関わる変更のレビューは引き続き必要です。Cursor自身も、AIへの指示だけを唯一のセキュリティ対策にしないよう注意を促しています。Team Rulesのガイダンス

実際の変更で設定を検証する

以前から同じ修正を繰り返していた、小さなタスクを使います。フォームのバリデーション変更はよい候補です。コンポーネントに触れ、振る舞いを変え、ユーザー入力も扱うためです。

1. 期待する結果を書き出します。 再利用する既存のコンポーネント、テストする振る舞い、維持すべき入力検証の境界を明示します。
2. 3つのファイルを保存し、設定状況を確認します。 CursorではCustomize → Rulesでルールを確認できます。Agentでは/create-ruleも使えます。ルールの作成方法
3. 関係するファイルをコンテキストに含めて、変更を依頼します。 普段の作業に近い依頼にしてください。すべてのルールを依頼文に書き直してしまうと、設定が役立ったかどうかを判断できません。
4. 差分と、報告された検証結果を確認します。 「ルールに従った」という説明ではなく、実際のコードが規約を満たしているかを見ます。今回の試行でテストのチェックリストを使うことが重要なら、@testsを明示して依頼してください。
5. 役に立ったルールを変更と一緒にコミットします。 チームでレビューできる出発点を用意しましょう。ファイルを増やす前に、曖昧な一文を直します。

規約が守られなかったときは、ルールがタスクに届かなかったのか、届いた指示が機能しなかったのかを分けて考えます。前者なら適用条件を修正します。後者なら、指示を明確にする、例を添える、自動チェックを導入する、といった対応が必要です。

残す価値のある規約に絞る

繰り返すミスのうち、チームの負担が最も大きいものから始めます。以下は検討に値する実用例を、減らせそうなレビュー負担の大きさに沿って並べたものです。

この表を、さらに5つのファイルを作る指示として受け取らないでください。まだ起きていない問題は含めません。要件を機械で正確に検証できるなら、そのチェックを優先します。役に立つルールは、タスクの依頼内容とリポジトリにある既存ツールの間を埋めるものです。

旧形式の.cursorrulesはどう扱う？

現在の公式ドキュメントに沿ってプロジェクトを設定するなら、.cursor/rules/*.mdcを使います。2026年10月11日時点で、ルールのドキュメントに.cursorrulesへの言及はなく、旧形式のファイルが引き続き動作するかは確認できません。 現在のリファレンス

旧ファイルが残っているリポジトリでは、使える指示を目的別のProject Rulesに移すことを勧めます。上で示した3つのファイルを出発点にしてください。適用条件を選び、実際のタスクで検証してから旧ファイルを廃止します。すでに書かれているという理由だけで、不要になった規約を残さないようにしましょう。

CLAUDE.mdやAGENTS.mdとはどう使い分ける？

共通する考え方は、プロジェクトで継続的に使う指示書です。Claude CodeにはCLAUDE.mdがあり、CodexはAGENTS.mdの作業規約を読み込みます。Cursorの通常のMarkdownを使う方式も、同じようにシンプルな指示書として使えます。一方、.mdcファイルでは適用条件を選べます。根底にある規約はそろえつつ、読み込み方は各ツールに合わせて意識的に設定してください。文章をコピーするだけでは、設定まで引き継げるわけではありません。複数のエージェントを使うチームでは、共通規約の管理責任者を1人決めておくと、ファイルごとに異なる方針が正しいものとして扱われるのを防げます。

設定後に作る価値のある小さなツール2つ

エンジニアリングリーダーにとって、より有望なのはリポジトリのルールチェッカーです。ファイル拡張子、有効なfrontmatterのフィールド、追跡対象のファイルに1つも一致しないパターンを確認します。最小限の実用版は、レビュー時にローカルで実行するレポートです。需要を示す材料は限定的です。この記事の調査では、DataForSEOの**「cursor rules examples」の推定月間検索数は140**でした。関連分野への関心は示していますが、対価を払う人がいる証拠にはなりません。注意点も明確です。形式上は正しいルールでも、指示として役に立つとは限りません。指標の定義

チーム規約のレビュー資料をまとめるツールは、複数のリポジトリを管理するリーダーに役立つ可能性があります。繰り返し出るレビューコメントと承認済みの例から、ルールの変更差分を提案し、変更ごとにレビュアーを指定します。DataForSEOの**「cursor team rules」の推定月間検索数は70**でした。まずは社内向けのツールから始めましょう。ルールの配布は標準のTeam Rulesがすでに担っているため、保存用のダッシュボードをもう1つ作っても、プロダクトとしての魅力は乏しいからです。価値があるのは、何を継続的な指示として残すべきかを判断する作業です。指標の定義

Cursor Rulesの設定でよくある質問

来週は、繰り返している修正を1つ選び、対応するルールを具体化して、次の普段どおりのプルリクエストで試してみてください。製品選びまで含めて検討するなら、CursorのレビューやCursorのおすすめ代替ツールも参考になります。

チームの開発ワークフローへの組み込みを依頼したい場合は、AI production systemsで扱っている内容が該当します。