cursorrulesって何?Cursorで開発を加速するためのルール設定
開発における「AIの提案がズレてる…」そんな経験はありませんか?
生成AIの支援を受けながらコードを書く環境が整いつつある現在、単にAIがコードを書くという段階から、「人間とAIのコラボレーションをいかに効率よく進めるか」というフェーズに突入しています。
この記事では、CursorというAIエディタが提供する cursorrules という仕組みに焦点を当て、その目的、記述ルール、導入方法、そして実際にどのようにプロンプトへ影響するのかまでを解説いたします。
cursorrulesとは何か?
Copilotの限界とCursorの役割
GitHub Copilotは非常に優秀なアシスタントですが、その提案内容はGitHub上の一般的なコードパターンに基づくため、プロジェクト固有の意図や制約を加味できません。
たとえば、以下のようなケースです。
- 命名規則に従っていない提案をしてくる
- 特定のユーティリティ関数を使って欲しいのに、独自のロジックを書いてくる
- フォルダ構成を無視してテストコードを置こうとする
このような問題を解消するために、Cursorではプロジェクト単位でAIへの指示をルールとして書ける仕組みを用意しています。それが .cursorrules です。
cursorrulesの基本思想「AIとの対話をルール化」
cursorrulesは、Cursorがプロジェクトに対して提示する提案内容を プロジェクトメンバーが明文化したルールに基づいてチューニングする仕組みです。
ポイントは次の2つです。
- AIが「どのような書き方が適切か?」をプロジェクト単位で理解できるようになる
- メンバー間でのコードスタイルや設計方針の認識を一致させることができる
つまり、「AI向けのREADME」 のようなものと捉えると分かりやすいかもしれません。
どんなときに使うのか?
よくある開発フローの課題
実際の開発で次のような悩みを感じたことはないでしょうか?
- 「なぜAIがReactコンポーネントを関数名
MyComponentで毎回出してくるの?」 - 「このプロジェクトでは
axiosじゃなくてfetcher.tsを使ってるのに…」 - 「
src/直下にファイル置かないでって言ってるのに…」
これらは人間同士なら口頭で共有したり、コードレビューで修正できる範囲ですが、AIとの開発ではその“認識のズレ”が何度も繰り返されがちです。
cursorrules導入での変化例
では実際にcursorrulesを導入することで、何がどう変わるのかをBefore / Afterで見てみましょう。
| # | Before(ルールなし) | After(cursorrulesあり) |
|---|---|---|
| 1 | AIが冗長なconsole.logを毎回挿入してくる | Avoid console.log in productionのルールで抑止 |
| 2 | テストファイルが__tests__以外に出力される | Place all test files in __tests__ foldersで統一 |
| 3 | 命名がMyButton、Clickerなどバラバラ | Use PascalCase for componentsで一貫性確保 |
| 4 | commitメッセージがUpdate codeなど曖昧 | Use conventional commit formatで明確化 |
このように、AIが生成する出力がプロジェクトの開発ルールや文化と一致するようになり、毎回修正する手間やレビュー時の指摘が減ります。
cursorrulesの構文と記法
.cursorrules ファイルとは
.cursorrules は、Cursor AIエディタにおいて、プロジェクト独自の開発ルールやスタイルガイドを記述するための設定ファイルです。AIにとっての「指示書」とも言える存在で、開発者が日々行っているようなレビューコメントや口頭でのコーディング指針を、明文化してAIにも伝えることができます。
このファイルを使うことで、以下のようなことが可能になります:
- 命名規則やフォルダ構成を明示して、AIの提案を一貫させる
- 推奨するライブラリや記法を固定する
- 禁止事項を定義して不適切なコードを排除する
英語だけでなく、日本語でも書ける
.cursorrules の最大の魅力のひとつが、「英語だけでなく日本語でも記述できる」ことです。
Cursorは自然言語処理に長けたAIを内蔵しており、日本語で書いたルールも正確に解釈してくれます。たとえば、以下のようなルールも問題なく認識されます:
plaintextすべての変数名はキャメルケースを使用する
Reactコンポーネント名はパスカルケースを使うこと
console.logの使用は禁止し、Loggerユーティリティを使う
ユニットテストは必ず__tests__フォルダに格納する
非同期処理は必ずエラーハンドリングを入れること
英語 vs 日本語:どちらを使うべき?
| 観点 | 英語で書く | 日本語で書く |
|---|---|---|
| 汎用性 | 他言語話者やOSS向けに有効 | 日本のチームや初学者に親しみやすい |
| 明快さ | 表現が抽象的になりがち | 長文で具体的に書きやすい |
| 一貫性 | 英語ドキュメントと揃えやすい | 社内ルールに直結しやすい |
どちらを使ってもAIは正しく理解しますが、プロジェクト内の言語文化に合わせて統一することが重要です。
日本語と英語を混在させてもOK
たとえば次のように、状況に応じて両言語を使い分けるのも可能です。
plaintextUse camelCase for variable names
API通信には fetcher.ts を使用する
Avoid any in TypeScript
Reactのフォーム部品は shadcn/ui を使う
よく使われるルール例(英語/日本語対訳)
| # | 内容 | 英語 | 日本語 |
|---|---|---|---|
| 1 | 命名 | Use camelCase for all variables | 変数はすべてキャメルケースで命名すること |
| 2 | コンポーネント名 | Use PascalCase for components | コンポーネント名はパスカルケースで命名すること |
| 3 | ログ制限 | Avoid using console.log | console.logの使用は禁止する |
| 4 | データ取得 | Use SWR for data fetching | データ取得にはSWRを使用すること |
| 5 | テスト配置 | Place test files in tests | テストファイルは__tests__フォルダに配置する |
| 6 | スタイル | Use Tailwind CSS | Tailwind CSSを使用すること |
| 7 | エラーハンドリング | Always handle errors in async functions | 非同期関数では必ずエラーハンドリングを行うこと |
記述例:日本語のみの .cursorrules
plaintextすべての関数はキャメルケースで命名すること
Reactコンポーネントはパスカルケースで命名する
ログ出力には console.log を使わず、Loggerユーティリティを使用する
API通信には utils/fetcher.ts を使う
テストコードは __tests__ フォルダ以下に格納する
フォームUIには shadcn/ui を使用する
ユニットテストは service クラスに対して必ず作成する
簡単なプロジェクトでの導入
ここでは、.cursorrules を実際のプロジェクトに適用する具体的なステップをご紹介します。
ステップ1:.cursorrules を作成
プロジェクトのルートに .cursorrules ファイルを作成します。
bashtouch .cursorrules
中身の記述例:
plaintextUse camelCase for variables and function names
Use PascalCase for React components
Do not use console.log; use src/utils/logger.ts instead
Place all tests in the __tests__ directory
Use Zod for all schema validation
Avoid declaring any type in TypeScript
ステップ2:Cursorでプロジェクトを開く
Cursorでこのプロジェクトを開くと、自動的に .cursorrules が読み込まれ、提案されるコードが変わります。
例:Reactコンポーネント生成
プロンプト
plaintextCreate a component to display user profile
ルールなしの出力
tsxfunction userprofile() {
return <div>name</div>
}
.cursorrules 適用時の出力
tsxfunction UserProfile() {
return <div className="text-sm">{user.name}</div>
}
- コンポーネント名がPascalCaseに
- スタイリングがTailwind風に
- 命名・構造が明確にルールに従っている
ステップ3:ルールの更新・追加
.cursorrules はただのテキストファイルなので、次のように柔軟に更新できます。
plaintext// 追加ルール
Use shadcn/ui Input and Button components for all forms
All async operations must have error handling
更新後に保存すれば、次の提案から即時反映されます。
ステップ4:チームでの共有
.cursorrules を Git に含めておけば、他のメンバーも同じAIルールで開発できます。
bashgit add .cursorrules
git commit -m "Add .cursorrules for shared coding conventions"
また、以下のようにREADMEに .cursorrules の意図を書くと、AI以外の開発者にも共有できます。
md## Development Guidelines
See `.cursorrules` for enforced coding conventions used by Cursor AI.
まとめ
.cursorrules は、AIによるコード提案をプロジェクトの流儀に合わせるための「チームの暗黙知を形式知にする仕組み」です。
導入メリット
- コードスタイルのばらつきがなくなる
- AIの提案修正コストが減り、スピード向上
- 初学者でもルールに沿ったコードが自然に書ける
- チーム開発でのレビュー指摘が減少
導入のポイント
- まずは「命名」「構造」など影響が見えやすい部分から始める
- 曖昧な表現は避け、自然言語で具体的に書く
- 定期的にプロジェクトに合うようルールを見直す
- チームで合意を取って
.cursorrulesを進化させていく
まずは小さなプロジェクトから .cursorrules を導入して、AIと開発者の“共同作業”をより良いものにしてみてください。
関連リンク
著書
使い方Cursor の Claude Code 拡張機能 2.1.312、2.1.313 の不正な版: 拡張機能を消しても、まだ裏で動いている
使い方2026年11月3日Cursor の Restore Checkpoint で Agent の変更を元に戻す手順: 戻るものと戻らないもの
使い方2026年11月3日Cursor で過去のチャット(Agent の会話)を探す手順: Cmd + K の検索と Cmd + F
トラブルシュート2026年11月3日【解決方法】Cursor が重い、遅いときの原因と対処: 拡張機能を止めて比べる
トラブルシュートCursor エディタ:キャッシュクリアで動作改善!Windows/Mac での手順とマウスカーソルの直し方
使い方Cursor コスト最適化:トークン節約・キャッシュ・差分駆動で費用を半減
使い方Orca の権限の初めの設定と直し方: 入れた直後、Claude Code が勝手に起動する
検証・比較Orca で Claude Code と Codex を GUI で使う手順: ターミナルだけだった Orca が、チャットの画面で使えるように
挙動Claude Code の context-mode の使い方: 入れただけでは、実は効いていなかった
使い方Postman が Claude Code と Codex に入れたプラグインの確かめ方: Superset も、開いただけでフックが11個
使い方Claude Code の settings.local.json の秘密が漏れる理由: その API キー、GitHub に出てない?
使い方Orca の差分の画面の使い方: エージェントへの指摘、1つずつ送っていない?
