開発における「AIの提案がズレてる…」そんな経験はありませんか？

生成AIの支援を受けながらコードを書く環境が整いつつある現在、単にAIがコードを書くという段階から、「人間とAIのコラボレーションをいかに効率よく進めるか」というフェーズに突入しています。

この記事では、CursorというAIエディタが提供する cursorrules という仕組みに焦点を当て、その目的、記述ルール、導入方法、そして実際にどのようにプロンプトへ影響するのかまでを解説いたします。

cursorrulesとは何か？

Copilotの限界とCursorの役割

GitHub Copilotは非常に優秀なアシスタントですが、その提案内容はGitHub上の一般的なコードパターンに基づくため、プロジェクト固有の意図や制約を加味できません。

たとえば、以下のようなケースです。

• 命名規則に従っていない提案をしてくる
• 特定のユーティリティ関数を使って欲しいのに、独自のロジックを書いてくる
• フォルダ構成を無視してテストコードを置こうとする

このような問題を解消するために、Cursorではプロジェクト単位でAIへの指示をルールとして書ける仕組みを用意しています。それが .cursorrules です。

cursorrulesの基本思想「AIとの対話をルール化」

cursorrulesは、Cursorがプロジェクトに対して提示する提案内容を プロジェクトメンバーが明文化したルールに基づいてチューニングする仕組みです。

ポイントは次の2つです。

1. AIが「どのような書き方が適切か？」をプロジェクト単位で理解できるようになる
2. メンバー間でのコードスタイルや設計方針の認識を一致させることができる

つまり、「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を内蔵しており、日本語で書いたルールも正確に解釈してくれます。たとえば、以下のようなルールも問題なく認識されます：

plaintextCopy codeすべての変数名はキャメルケースを使用する
Reactコンポーネント名はパスカルケースを使うこと
console.logの使用は禁止し、Loggerユーティリティを使う
ユニットテストは必ず__tests__フォルダに格納する
非同期処理は必ずエラーハンドリングを入れること

英語 vs 日本語：どちらを使うべき？

観点	英語で書く	日本語で書く
汎用性	他言語話者やOSS向けに有効	日本のチームや初学者に親しみやすい
明快さ	表現が抽象的になりがち	長文で具体的に書きやすい
一貫性	英語ドキュメントと揃えやすい	社内ルールに直結しやすい

どちらを使ってもAIは正しく理解しますが、プロジェクト内の言語文化に合わせて統一することが重要です。

日本語と英語を混在させてもOK

たとえば次のように、状況に応じて両言語を使い分けるのも可能です。

plaintextCopy codeUse 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

plaintextCopy codeすべての関数はキャメルケースで命名すること
Reactコンポーネントはパスカルケースで命名する
ログ出力には console.log を使わず、Loggerユーティリティを使用する
API通信には utils/fetcher.ts を使う
テストコードは __tests__ フォルダ以下に格納する
フォームUIには shadcn/ui を使用する
ユニットテストは service クラスに対して必ず作成する

簡単なプロジェクトでの導入

ここでは、.cursorrules を実際のプロジェクトに適用する具体的なステップをご紹介します。

ステップ1：.cursorrules を作成

プロジェクトのルートに .cursorrules ファイルを作成します。

bashCopy codetouch .cursorrules

中身の記述例：

plaintextCopy codeUse 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コンポーネント生成

プロンプト

plaintextCopy codeCreate a component to display user profile

ルールなしの出力

tsxCopy codefunction userprofile() {
  return <div>name</div>
}

.cursorrules 適用時の出力

tsxCopy codefunction UserProfile() {
  return <div className="text-sm">{user.name}</div>
}

• コンポーネント名がPascalCaseに
• スタイリングがTailwind風に
• 命名・構造が明確にルールに従っている

ステップ3：ルールの更新・追加

.cursorrules はただのテキストファイルなので、次のように柔軟に更新できます。

plaintextCopy code// 追加ルール
Use shadcn/ui Input and Button components for all forms
All async operations must have error handling

更新後に保存すれば、次の提案から即時反映されます。

ステップ4：チームでの共有

.cursorrules を Git に含めておけば、他のメンバーも同じAIルールで開発できます。

bashCopy codegit add .cursorrules
git commit -m "Add .cursorrules for shared coding conventions"

また、以下のようにREADMEに .cursorrules の意図を書くと、AI以外の開発者にも共有できます。

mdCopy code## Development Guidelines

See `.cursorrules` for enforced coding conventions used by Cursor AI.

まとめ

.cursorrules は、AIによるコード提案をプロジェクトの流儀に合わせるための「チームの暗黙知を形式知にする仕組み」です。

導入メリット

• コードスタイルのばらつきがなくなる
• AIの提案修正コストが減り、スピード向上
• 初学者でもルールに沿ったコードが自然に書ける
• チーム開発でのレビュー指摘が減少

導入のポイント

• まずは「命名」「構造」など影響が見えやすい部分から始める
• 曖昧な表現は避け、自然言語で具体的に書く
• 定期的にプロジェクトに合うようルールを見直す
• チームで合意を取って .cursorrules を進化させていく

まずは小さなプロジェクトから .cursorrules を導入して、AIと開発者の“共同作業”をより良いものにしてみてください。

関連リンク

• Cursor公式ドキュメント（Rules）
• GitHub: Awesome .cursorrules Examples
• Zenn: Cursorを導入した開発現場のルール例