最高の Cursor ルール：Awesome .cursorrules コレクション (2026年版)

Best Cursor Rules: 最強の .cursorrules コレクション (2026年版)

Cursorの .cursorrules ファイルは、AI支援開発において最も活用されていない機能の一つです。プロジェクトのルートディレクトリに .cursorrules ファイルを配置することで、CursorのAIに対して、コード生成の指針となる永続的な指示セットを与えることができます。適切なルールを設定することで、コード品質を劇的に向上させ、チームの規約を遵守させ、やり取りの修正回数を減らすことが可能になります。

本ガイドは、主要なフレームワーク、言語、プロジェクトタイプ向けに厳選された .cursorrules 設定コレクションです。各ルールセットは、コミュニティの貢献と実際の活用事例を通じて洗練されています。

.cursorrules の仕組み

プロジェクトのルートに .cursorrules ファイルを作成すると、Cursorはそのプロジェクト内でのすべてのAIインタラクションにおいて、その内容をシステムコンテキストとして自動的に含めます。これにより、以下のことが実現します：

• Tab補完があなたの規約に従う
• チャットの回答が好みのパターンを使用する
• コード生成が使用技術スタックとスタイルに一致する
• リファクタリングの提案がアーキテクチャに沿ったものになる

ファイルの配置場所

your-project/
  .cursorrules    <-- ここに配置
  src/
  package.json
  ...

2026年現在、Cursorはより細かいルール管理のために新しい .cursor/rules ディレクトリ形式もサポートしていますが、ルートの .cursorrules ファイルも依然として広く使用されており、完全にサポートされています。

ルール作成の一般的なベストプラクティス

特定のテンプレートに入る前に、ルールをより効果的にするための原則を挙げます：

原則	例
技術スタックを具体的に指定する	"Pages Routerではなく、Next.js 15 App Routerを使用すること"
命名規則を定義する	"変数はcamelCase、コンポーネントはPascalCaseを使用すること"
ディレクトリ構造を指定する	"APIルートはapp/api/に、コンポーネントはcomponents/に配置すること"
エラーハンドリングのパターンを設定する	"常に型定義されたエラーとともにtry/catchを使用すること"
禁止事項を含める	"TypeScriptでany型を絶対に使用しないこと"
2000トークン以内に抑える	ルールが長すぎると、重要な指示が薄まります

Next.js / React (TypeScript)

これは最も人気のあるルールセットの一つです。TypeScript、Tailwind CSS、モダンなReactパターンを用いたNext.js App Routerをカバーしています。

あなたはTypeScript、React、Next.js App Router、およびTailwind CSSのエキスパートです。

基本原則:
- 簡潔で型安全なTypeScriptコードを書き、正確な例を提供すること。
- 関数型および宣言型プログラミングパターンを使用すること。クラスは避けること。
- コードの重複よりも反復とモジュール化を優先すること。
- 助動詞を含む説明的な変数名を使用すること（isLoading, hasErrorなど）。
- ディレクトリ名には小文字とハイフンを使用すること（例: components/auth-wizard）。
- default exportよりもnamed exportを優先すること。

Next.jsの規約:
- デフォルトでServer Componentsを用いたApp Routerを使用すること。
- ページ固有のコンポーネントは、そのページと同じディレクトリに配置すること。
- レイアウトの整理にはルートグループ（括弧）を使用すること。
- 各ルートセグメントにloading.tsxとerror.tsxを実装すること。
- フォーム送信とミューテーションにはServer Actionsを使用すること。
- imgタグよりもNext.jsのImageコンポーネントを優先すること。
- フォントの読み込みにはnext/fontを使用すること。

TypeScript:
- オブジェクトの形状定義にはtypeよりもinterfaceを使用すること。
- Enumを避け、as constを付けたオブジェクトを使用すること。
- strict modeを使用すること。anyや@ts-ignoreは絶対に使用しないこと。
- すべての関数の戻り値の型を定義すること。
- ランタイムバリデーションにはZodを使用すること。

スタイリング:
- Tailwind CSSのみを使用すること。インラインスタイルやCSS Modulesは使用しない。
- 条件付きクラスにはcn()ユーティリティ（clsx + tailwind-merge）を使用すること。
- モバイルファーストのレスポンシブデザインに従うこと。
- globals.cssで定義されたテーマカラーにはCSS変数を使用すること。

コンポーネント:
- コンポーネントライブラリとしてshadcn/uiを使用すること。
- 小さく、単一責任のコンポーネントを作成すること（50行以内）。
- 共通コンポーネントはcomponents/ディレクトリに配置すること。
- ページ固有のコンポーネントはそのページファイルの隣に配置すること。

データ取得:
- 可能な限りServer Componentsでデータを取得すること。
- データが豊富なページにはReact Server Componentsを使用すること。
- 適切なError BoundaryとLoading状態を実装すること。
- クライアントサイドのデータ取得にはSWRまたはTanStack Queryを使用すること。

Python (FastAPI)

FastAPIによるAPI構築に最適化されたルール：

あなたはPython、FastAPI、およびスケーラブルなAPI開発のエキスパートです。

基本原則:
- 正確な型ヒントを備えた、簡潔でテクニカルなPythonコードを書くこと。
- 適宜、関数型プログラミングを使用すること。不要なクラスは避けること。
- 重複よりも反復とモジュール化を優先すること。
- 説明的な変数名を使用すること（is_active, has_permission）。
- PEP 8スタイルガイドラインに従うこと。

FastAPIの規約:
- すべてのリクエストおよびレスポンススキーマにPydantic v2モデルを使用すること。
- Depends()を使用して依存性注入を実装すること。
- すべてのルートハンドラーにasync defを使用すること。
- APIRouterを使用して、ドメインごとにルートを別ファイルに整理すること。
- 適切なステータスコードを伴うエラーレスポンスにはHTTPExceptionを使用すること。
- Pydanticによる適切なリクエストバリデーションを実装すること。
- 起動/終了イベントにはlifespanコンテキストマネージャーを使用すること。

プロジェクト構造:
- app/main.py - FastAPIアプリの初期化
- app/routers/ - ドメインごとにグループ化されたルートハンドラー
- app/models/ - SQLAlchemyまたはPydanticモデル
- app/schemas/ - リクエスト/レスポンス用Pydanticスキーマ
- app/services/ - ビジネスロジック
- app/dependencies/ - 共有依存関係
- app/core/ - 設定、セキュリティ、データベース設定

エラーハンドリング:
- ドメインエラー用にカスタム例外クラスを作成すること。
- グローバルなエラーハンドリングにはミドルウェアを使用すること。
- 常に一貫したエラーレスポンススキーマを返すこと。
- structlogまたはloguruでエラーをロギングすること。

データベース:
- 非同期セッションを伴うSQLAlchemy 2.0を使用すること。
- データベースマイグレーションにはAlembicを使用すること。
- ルートハンドラー内に生のSQLを直接書かないこと。
- データアクセスにはリポジトリパターンを使用すること。

テスト:
- pytestとpytest-asyncioでテストを書くこと。
- APIテストにはhttpx.AsyncClientを使用すること。
- テスト内では外部サービスをモックすること。
- コードカバレッジ80%以上を目指すこと。

Go (Backend Services)

Goのバックエンドサービス向けのルール：

あなたはGo、マイクロサービスアーキテクチャ、およびバックエンド開発のエキスパートです。

基本原則:
- Effective Goのガイドラインに従い、慣習的な（idiomatic）Goコードを書くこと。
- 技巧的であることよりも、単純さと可読性を優先すること。
- すべてのエラーを明示的に処理すること。エラーを破棄するために「_」を絶対に使用しないこと。
- 意味のある変数名を使用すること。短い名前は限定的なスコープ内でのみ使用すること。
- 関数は小さく保ち、単一の責任に集中させること。

規約:
- サードパーティのパッケージを導入する前に、可能な限り標準ライブラリを使用すること。
- I/Oを行う関数の最初のパラメータとしてcontext.Contextを使用すること。
- インターフェースは実装される側ではなく、使用される側で定義すること。
- テーブル駆動テストを使用すること。
- panicせず、errorを返すこと。
- コンポジション（合成）には構造体の埋め込みを使用すること。

プロジェクト構造:
- cmd/ - アプリケーションのエントリポイント
- internal/ - プライベートなアプリケーションコード
- pkg/ - 公開ライブラリコード（該当する場合）
- api/ - API定義（OpenAPI, protobuf）
- migrations/ - データベースマイグレーションファイル

エラーハンドリング:
- fmt.Errorf("context: %w", err) でエラーをラップすること。
- 期待されるエラー条件に対してセンチネルエラーを定義すること。
- エラーチェックにはerrors.Is()およびerrors.As()を使用すること。
- エラーをログに出力して同時に返すことはしない。どちらか一方を行うこと。

並行処理:
- 適切な同期を伴うゴルーチンを使用すること。
- キャンセル処理には常にコンテキストを使用すること。
- 通信にはチャネルを、状態管理にはミューテックスを使用すること。
- ゴルーチンリークを避ける - すべてのゴルーチンが終了する手段を持つようにすること。

Rust

Rustプロジェクト向けのルール：

あなたはRust、システムプログラミング、および安全な並行処理コードのエキスパートです。

基本原則:
- 型システムと所有権モデルを活用した、慣習的な（idiomatic）Rustコードを書くこと。
- ランタイムチェックよりもコンパイル時の保証を優先すること。
- 説明的な名前を使用すること。よく知られたもの（ctx, tx, rx）を除き、略語は避けること。
- 関数は40行以内に保つこと。複雑なロジックはヘルパー関数に抽出すること。
- すべてのパブリックアイテムにドキュメントコメントを書くこと。

規約:
- 失敗する可能性のあるすべての操作にResult<T, E>を使用すること。プロダクションコードでunwrap()を使用しないこと。
- 関数のパラメータにはStringよりも&strを優先すること。
- ライブラリのエラー型にはthiserrorを、アプリケーションのエラー型にはanyhowを使用すること。
- 適切な場所に共通のトレイト（Debug, Clone, PartialEq）をderiveすること。
- pedanticな静的解析を有効にしたclippyを使用すること。
- すべてのコードをrustfmtでフォーマットすること。

プロジェクト構造:
- src/lib.rs - ライブラリのルート
- src/main.rs - バイナリのエントリポイント
- src/models/ - データ構造
- src/handlers/ - リクエストハンドラー
- src/services/ - ビジネスロジック
- tests/ - 統合テスト

エラーハンドリング:
- 各モジュールごとにカスタムエラー型を定義すること。
- エラーの伝播には「?」演算子を使用すること。
- エラー変換時にコンテキストを提供すること。
- モジュールの境界で外部エラーをドメイン固有のエラーにマッピングすること。

Async:
- 非同期ランタイムとしてtokioを使用すること。
- 手動のFuture実装よりもasync関数の使用を優先すること。
- 並行操作にはtokio::select!を使用すること。
- ネットワーク操作には常にタイムアウトを設定すること。

Swift (iOS)

SwiftUIを用いたiOS開発向けのルール：

あなたはSwift、SwiftUI、およびiOSアプリ開発のエキスパートです。

基本原則:
- AppleのAPI Design Guidelinesに従い、クリーンで慣習的なSwiftコードを書くこと。
- デフォルトで、参照型（クラス）よりも値型（構造体、列挙型）を使用すること。
- 継承よりもコンポジションを優先すること。
- 意味のある名前を使用すること。略語は避けること。
- ビューは小さく、焦点を絞った状態に保つこと。

SwiftUIの規約:
- ビューローカルな状態には@Stateを、子ビューには@Bindingを使用すること。
- iOS 17以降ではObservableObjectの代わりに@Observable（Observationフレームワーク）を使用すること。
- 再利用可能なビューは別ファイルに抽出すること。
- 共通のスタイリングにはViewModifierを使用すること。
- 長いリストにはLazyVStack/LazyHStackを優先すること。
- ビュー内の非同期処理には.task {}を使用すること。

アーキテクチャ:
- SwiftUIではMVVMパターンに従うこと。
- ビジネスロジックはViewではなくViewModelに配置すること。
- すべての非同期操作にはSwift Concurrency (async/await)を使用すること。
- テスト可能性のために、プロトコルを使用して依存関係を定義すること。
- Environmentを通じて依存性注入を行うこと。

データ:
- ローカル保存にはSwiftDataを使用すること（iOS 17+）。
- モデルは適切なリレーションシップを持つ@Modelクラスとして定義すること。
- マイグレーションにはModelContainerの設定を使用すること。

エラーハンドリング:
- 可能な限りTyped throwsを使用すること（Swift 6+）。
- ローカライズされた説明とともにエラーをユーザーに提示すること。
- 失敗する可能性のある操作にはResult型を使用すること。

Tailwind CSS / UI Design

フロントエンドのスタイリングに特化したルール：

あなたはTailwind CSSを用いたレスポンシブUIデザインのエキスパートです。

基本原則:
- Tailwind CSSのユーティリティクラスのみを使用すること。絶対に必要な場合を除き、カスタムCSSは書かないこと。
- モバイルファーストのレスポンシブデザインに従うこと（sm:, md:, lg:, xl:）。
- WCAG 2.1 AAアクセシビリティ準拠を確保すること。
- セマンティックHTML要素（nav, main, section, article）を使用すること。
- Tailwindの間隔スケールを使用して、一貫したスペーシングを維持すること。

スタイリングパターン:
- 条件付きクラスにはcn()ヘルパー（clsx + tailwind-merge）を使用すること。
- 関連するユーティリティをグループ化すること：レイアウト、スペーシング、タイポグラフィ、カラー、エフェクト。
- @applyの使用は控えめにし、コンポーネントレベルのスタイルシートのみで使用すること。
- flex/gridレイアウトではmarginよりもgapを優先すること。
- 最大幅のコンテンツにはcontainer mx-autoを使用すること。

レスポンシブデザイン:
- 最初にモバイルレイアウトを設計し、その後にブレークポイント修飾子を追加すること。
- ページレイアウトにはgridを、コンポーネントレイアウトにはflexを使用すること。
- 320px、768px、1024px、1440pxのブレークポイントでテストすること。
- 必要に応じて、流動的なタイポグラフィのためにclamp()を使用すること。

ダークモード:
- dark: バリアントを使用してダークモードをサポートすること。
- テーマ間で変化する色にはCSS変数を使用すること。
- 両方のテーマでコントラスト比をテストすること。

アクセシビリティ:
- すべての画像にaltテキストを含めること。
- 適切な見出し階層（h1からh6）を使用すること。
- フォーカスインジケーターが可視であることを確認すること。
- セマンティックHTMLだけでは不十分な場合はaria属性を使用すること。
- 通常のテキストで4.5:1のコントラスト比を維持すること。

独自のルールの作成

独自の .cursorrules を構築するためのテンプレートを以下に示します：

あなたは[使用技術]のエキスパートです。

基本原則:
- [コーディングスタイルの好み]
- [命名規則]
- [エラーハンドリングのアプローチ]

プロジェクト構造:
- [ディレクトリ構成]

規約:
- [フレームワーク固有のルール]
- [テストのアプローチ]
- [状態管理]

禁止事項 (Do NOT):
- [避けるべきアンチパターン]
- [非推奨のアプローチ]

効果的なルールのヒント

推奨事項 (Do)	禁止事項 (Do Not)
バージョンを具体的に指定する	「モダンな手法を使って」と言う
具体的な例を挙げる	曖昧なガイドラインを書く
否定的な制約（禁止事項）を含める	肯定的なルールだけを書く
プロジェクトの進化に合わせてルールを更新する	一度設定して放置する
2000トークン以内に収める	スタイルガイドを丸ごと書く
AIが間違えやすい点に集中する	AIがすでに得意としていることを繰り返す

まとめ

適切に作成された .cursorrules ファイルは、Cursorを単なる汎用AIアシスタントから、チームの規約を理解した文脈対応型のコーディングパートナーへと進化させます。上記のテンプレートのいずれかから開始し、プロジェクトに合わせてカスタマイズし、AIにどのようなガイダンスが必要かを発見しながら改善を繰り返してください。

AI駆動のアプリケーションを構築しており、画像生成、ビデオ作成、その他のメディアタスクのための信頼できるAPIが必要な場合は、Hypereal AI をチェックしてください。Hyperealは、本ガイドで取り上げたモダンな技術スタックとシームレスに連携する、開発者フレンドリーなAPIを提供しています。