【国内正規品】MonsGeek(モンスギーク) FUN60 Pro SP 有線モデル HEセンサー 0.01mm ラピッドトリガー対応 磁気スイッチ Akko Glare Magnetic Switch 英語配列 テンキーレス サイドプリント 有線8K ホットスワップ SnapKeys (SOCD)対応 ARGB対応 高コスパ ゲーミングキーボード Black
¥5,980 (2025年5月1日 13:06 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
はじめに
こんにちは株式会社キカガクの @tetsuro_b です。
株式会社キカガクでは 2025 年 4 月に全エンジニアへ Cursor を導入しました。(約 15 名)
メンバーの中にはこれまで Cursor を半年以上使い続けている熟練者から、これを機に Cursor を触り始めた方まで様々です。
そこで組織全体として Cursor を最大限効果的に活用するために「全員の知識の底上げ」 + 「Cursor Rules の運用方針」を定めるべく、本来は社内向けの情報としてカジュアルに用意するつもりだったのですが、せっかくならということで本ブログを執筆することにしました!
小手先のテクニック論ではなく、LLM の進化によってなるべく陳腐化しないような情報でまとめたつもりなのでぜひ最後までご覧ください!
対象読者
- Cursor を組織に導入したは良いものの Rules をどう運用していくか方向性が固まっていない方
- Cursor を触ってはいるものの Rules の整備などに関しては何から初めていいのかわからない方
Cursor Rules とは
AI エージェント向けのコーディングガイドラインのようなものです。
プロジェクトルートの .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 による出力はガチャ的な要素も多く、なんか1回はうまく行ったけど次にやってみたら全く精度高くないということがあるからです。
また、意味のない Rules が増えていくことで重要な情報がどんどん薄まっていき、Rules が最大限に性能を発揮できなくなってしまう 可能性があります。
✅ うまく Rules が動かない場合は記載内容を見直そう
前項で Cursor が Rules を守ってくれなかったとしても諦めるのはまだ早いです!
表現を変更することで Cursor が正しく Rules を認識してくれる可能性があります。
- Cursor が守ってくれなかった時のコードに対して「なぜこのようなコードを書いたのか」聞く
- 「どのような Rules の記載の方法であれば守れそうか」Cursor に聞く
その他にも具体的なコード例を記載できるのであれば、良い例と悪い例を記載することや、「〇〇 は使わない」など否定的な情報ではなく「XX を使うこと」など肯定的な表現に書き換えることも有効です。
✅ Cursor に効果がなかった Rules は doc/*.md
などに記載しよう
たとえ Cursor に効果がなかったとしても以下の条件に当てはまるものであればせっかくなので .md
に記載しましょう。
-
AI の行動規範ではなくコーディングガイドラインなどのナレッジ
※ AI の行動規範については Rules 以外に書いても効果はほぼ無いので.md
には記載しない
※ 行動規範:例えば「必ず確認を取ってから次の手順に進んでください」など - 人間にとってもオンボーディングなどには重要な情報
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
)
- Agent/ASK モード(Rule Type:
-
手動適用:
@filename
でコンテキストとして設定しないと適用されない- Agent/ASK モード(Rule Type:
Manual
) - command + K
- Agent/ASK モード(Rule Type:
🙋♂️ 決まった手順でなにか実行させたいときはいい方法ある?
Rules に手順を記載したうえで /hoge
などのようにコマンドを設定しておくのが便利です。
例)PR を作りたいとき → /pr
を設定
※ 以下の X のポストを参考にさせていただきました。
🙋♂️ 少し普段使いしてみてからリポジトリに入れるか判断したい Rules がある
迷ったら Rules に入れてみてしばらく運用してみましょう。
もしくは *.local.mdc
などに記載し、しばらく手元で運用をしてみるという方法もあるようなので参考にしましょう。
※ Cursor の機能で *.loca.mdc
をサポートしているわけではないので事前に .gitignore
に *.loca.mdc
を追加する必要あり
※ 参考:Loglass さんの「.mdc 駆動ナレッジマネジメント」より
🙋♂️ リポジトリをまたいで共有したいルールがある
現状は 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 活用情報を発信しています!ぜひフォローお願いします!
Views: 0