【保存版】明日から使える、組織のための Cursor Rules 運用

はじめに

こんにちは株式会社キカガクの @tetsuro_b です。

株式会社キカガクでは 2025 年 4 月に全エンジニアへ Cursor を導入しました。（約 15 名）
メンバーの中にはこれまで Cursor を半年以上使い続けている熟練者から、これを機に Cursor を触り始めた方まで様々です。

そこで組織全体として Cursor を最大限効果的に活用するために「全員の知識の底上げ」 + 「Cursor Rules の運用方針」を定めるべく、本来は社内向けの情報としてカジュアルに用意するつもりだったのですが、せっかくならということで本ブログを執筆することにしました！

小手先のテクニック論ではなく、LLM の進化によってなるべく陳腐化しないような情報でまとめたつもりなのでぜひ最後までご覧ください！

対象読者

• Cursor を組織に導入したは良いものの Rules をどう運用していくか方向性が固まっていない方
• Cursor を触ってはいるものの Rules の整備などに関しては何から初めていいのかわからない方

Cursor Rules とは

AI エージェント向けのコーディングガイドラインのようなものです。

https://docs.cursor.com/context/rules

プロジェクトルートの .cursor/rules/*.mdc で管理します。

なぜ Rules を書くべきか

Cursor が生成するコード品質をある程度コントロールするためというのは既知だと思いますが、その他にも以下の観点から Cursor Rules の積極的な整備を進めていきます。

• 人間用のオンボーディング & ナレッジにもなる
• Devin などの自立型 AI エージェントのコンテキストにも使えるなど応用が効く

これから LLM の進化で AI が理解できるコンテキストの量は益々増えていくのは明らかなので、将来も見据えた AI フレンドリーな環境の整備を組織としての責務としていきます。

いつ Rules を作成するべきか

Agent/Ask モードを使っていて以下のような場面に遭遇したら積極的に Rules への記載を検討しましょう。

• Cursor の出力が意図しているものではなく「こうしてほしい」が明確にある
• いつも同じようなプロンプトを入力している（例：テストを書く際はこのファイルを参考にしてください。

前提： これからはもっともっと Agent モード使おう

Tab キー補完が正直快適すぎて、Agent モードの存在を忘れてしまうこともしばしば...。
※ 特に複雑なロジックばかり実装しているとそうなりがち。

ただ Tab キーでのコーディングは人間がコーディングのハンドルを握っている割合が多く、LLM の性能が進化してもその恩恵を受けにくいのが弱点でもあるかなと考えています。

一方で Agent モードについては、人間が司令塔の役割となりコーディング部分は圧倒的に AI によるハンドリング割合が多いため LLM の進化の恩恵を受けやすいです！
※ LLM が進化していくことで、プロンプトの意図を正確に汲み取り一度にコーディングできる量が増えていくという意味で記載（つまり作業指示して放置で進めてもらえる作業量と質の増加）

また、後述するとおり Rules でプロジェクトに沿った Cursor を育てていけるので今後はなるべく余裕があれば Agent モードを使ってコーディングしていきましょう。

Cursor Rules 運用方針

フロー図にしてみるとざっくりこんな感じです。
以降でもう少し詳しく説明していきます。

Cursor Rules に記載する際は、まずは以下のチェック項目を参考に記載しましょう。

運用方針詳しく説明

✅ まずは静的解析 （ESLint など） などの仕組みで対応できないか考えよう

ESLint などで縛れる内容であればまずはそちらを検討しましょう。
※ 命名規則や使ってほしくないメソッドの縛りなど

理由は以下のとおりです。

• Agent の挙動に左右されることもなく100% そのルールが遵守される
• lint エラーになれば Cursor が直してくれることもあるので Rules にわざわざ記載するよりも確度が高い

ただし、Cursor は ESLint に従ったコーディングを最初からしてくれるわけではないので 「あぁこの ESLint のルールいつも守ってくれないな、コーディング終わったあとに Lint エラー直しだして時間無駄にかかってるなぁ」 があれば Rules にも記載して OK です。

✅ ケースに適した Rule Type を選択しよう

.mdc にはいつその Rules を反映してコーディングを行うかの設定が可能です。

Rule Type	説明
Always	常に Agent/Ask の会話に適用される → Cursor の振る舞い方やプロジェクトの情報など必要最低限を記載（コンテキスト量をむやみに増やさない）
Auto Attached	globパターンに一致するファイルがコンテキストとして設定されている場合に適用される → spec など特定のファイルでのみ適用したい Rules に設定
Manual	@ruleName で会話にこの .mdc を参照させた場合にのみ適用される → PR 作成や AI に DDD してもらう時など特定のケースでしか使わない Rules に設定
Agent Requested	Descrition に設定された内容が会話の内容に関連のある場合に適用される → 上記いずれにも属しない Rules に設定

適切な Rule Type を設定して運用をすることで今後、.mdc のファイル数が増え続けた場合でも Cursor が安定した挙動をしてくれるはずです。徹底していきましょう。

✅ 設定した Cursor Rules で AI が意図どおりに動くか確認しよう

Cursor Rules に記載すればすべてその通りに動くかと言われると全くそんな事はありません。
Rules が複雑であったり曖昧な指示の場合は 無視されることが多いです。
※ 明確に具体的に記載したとて守られないことも多いです。

Cursor Rules に記載した内容で本当に意図した出力になるのか複数回確かめたものを追加していきましょう。

複数回と書いたのは AI による出力はガチャ的な要素も多く、なんか１回はうまく行ったけど次にやってみたら全く精度高くないということがあるからです。
また、意味のない Rules が増えていくことで重要な情報がどんどん薄まっていき、Rules が最大限に性能を発揮できなくなってしまう 可能性があります。

✅ うまく Rules が動かない場合は記載内容を見直そう

前項で Cursor が Rules を守ってくれなかったとしても諦めるのはまだ早いです！
表現を変更することで Cursor が正しく Rules を認識してくれる可能性があります。

• Cursor が守ってくれなかった時のコードに対して「なぜこのようなコードを書いたのか」聞く
• 「どのような Rules の記載の方法であれば守れそうか」Cursor に聞く

その他にも具体的なコード例を記載できるのであれば、良い例と悪い例を記載することや、「〇〇 は使わない」など否定的な情報ではなく「XX を使うこと」など肯定的な表現に書き換えることも有効です。

✅ Cursor に効果がなかった Rules は doc/*.md などに記載しよう

たとえ Cursor に効果がなかったとしても以下の条件に当てはまるものであればせっかくなので .md に記載しましょう。

1. AI の行動規範ではなくコーディングガイドラインなどのナレッジ
   ※ AI の行動規範については Rules 以外に書いても効果はほぼ無いので .md には記載しない
   ※ 行動規範：例えば「必ず確認を取ってから次の手順に進んでください」など
2. 人間にとってもオンボーディングなどには重要な情報

Cursor が実装中に grep する際や Devin などのような自立型エージェントが必要なタイミングで読み取ってコンテキストとして活用してくれるかもしれません。

💬 こんなときどうする？

上記の内容で Cursor Rules を運用をしていくうえで、チーム内で議論したことや質問を抜粋して以下に記載していきます。（今後も追加予定）

🙋‍♂️ 設定した Cursor Rules は Tab の補完にも効く？

Cursor Rules は Tab の補完には効かないです。

https://docs.cursor.com/context/rules#how-rules-work
Rules apply to both Chat and Cmd K

• 自動適用： 会話の内容に関連した Rules が自動で適用
  • Agent/ASK モード（Rule Type: Always/Auto Attached/Agent Requested）
• 手動適用： @filename でコンテキストとして設定しないと適用されない
  • Agent/ASK モード（Rule Type: Manual）
  • command + K

🙋‍♂️ 決まった手順でなにか実行させたいときはいい方法ある？

Rules に手順を記載したうえで /hoge などのようにコマンドを設定しておくのが便利です。

例）PR を作りたいとき → /pr を設定

※ 以下の X のポストを参考にさせていただきました。
https://x.com/RateteDev/status/1891844918412509408

🙋‍♂️ 少し普段使いしてみてからリポジトリに入れるか判断したい Rules がある

迷ったら Rules に入れてみてしばらく運用してみましょう。
もしくは *.local.mdc などに記載し、しばらく手元で運用をしてみるという方法もあるようなので参考にしましょう。
※ Cursor の機能で *.loca.mdc をサポートしているわけではないので事前に .gitignore に *.loca.mdc を追加する必要あり

※ 参考：Loglass さんの「.mdc 駆動ナレッジマネジメント」より
https://speakerdeck.com/yodakeisuke/dot-mdc-driven-knowledge-management?slide=11

🙋‍♂️ リポジトリをまたいで共有したいルールがある

現状は Cursor 自体にはその仕組はないので簡単にやるならコピペしか無いです。

ただ Cursor のドキュメントに「プロジェクト間で共有できる Cursor Rules のサポートを予定」との記載があるのでそこに期待しましょう。

We plan to support shared, MDC-formatted rules that can be referenced across team projects. Until then, you can:
https://docs.cursor.com/context/rules#team-rules

まとめ

• まずは静的解析等の仕組みで補えないか考える
• 本当に効果のある Rules のみを育てていく
• 効果はないけど必要な情報は .md で管理していく

基本的には上記の方針で、今後 Cursor Rules をキカガクでも各プロジェクトで育てていきます。

---

X でも AI 活用情報を発信しています！ぜひフォローお願いします！

https://x.com/tetsuro_b