プロジェクトルールはもう自動生成する時代。Cline が Cursor に続く

プロジェクトのルールをどう作ればいいのかと悩んだことがありませんか？ルールは必要だと分かっていても、何から始めていいか分からず、結局作らないままになってしまうことも多いのではないでしょうか。

本記事では、最近リリースされた Cline のルール自動生成機能を紹介し、Cursor との違いも比較しながら解説します。この記事を読めば、簡単なプロンプトで効果的なプロジェクトルールを生成する方法が分かります。

プロジェクトルール自動生成の価値

プロジェクトルールの自動生成は単に「便利」というだけでなく、自動生成されるルールの特徴を知ることで、以下のメリットがあります

• 自分でルールを作成する際の参考になる
• AI の得意分野（構造化、網羅性）を活かしたルール作成ができる

先日、以下で紹介した Cursor のルール自動生成機能に続き、Cline からも同様の機能がリリースされましたので両者を比較することで、より効果的なルール作成のヒントが得られるはずです。

https://zenn.dev/m0t0taka/articles/97da4c1b6e9300

Cline のルール自動生成機能詳細

Cline は 2024 年 5 月 1 日に公式 X アカウントでこの新機能をアナウンスしました。

https://x.com/cline/status/1919119386738393487

機能の特徴は以下の通りです：

• 使用方法：/newrule コマンドを実行
• 生成場所：.clinerules ディレクトリ下に自動保存

実際に生成されたルールの分析

個人開発のブログのプロジェクトで試してみました。単純なプロンプトでどの程度のルールが生成されるか検証します。

使用したプロンプト

/newrule このプロジェクトのアーキテクチャルールを作成して

生成結果

## Brief overview

このドキュメントは Next.js と Supabase を使用したブログプラットフォームのアーキテクチャルールを定義します。プロジェクトは TypeScript で記述され、Prisma ORM、Tailwind CSS、Stripe 決済、Kinde 認証などの技術を活用しています。

## プロジェクト構造

- `app/` - Next.js App Router を使用したメインアプリケーションコード
  - `api/` - すべての API エンドポイント
  - `blog/` - ブログ関連のページ
  - `components/` - アプリケーション固有のコンポーネント
  - `dashboard/` - ダッシュボード関連のページ
  - `utils/` - ユーティリティ関数
- `components/` - 再利用可能な UI コンポーネント
- `lib/` - 共通ライブラリコード
- `prisma/` - データベーススキーマと移行
- `public/` - 静的アセット

## コンポーネント設計

- コンポーネントは機能ごとに分離し、単一責任の原則に従う
- 共通 UI コンポーネントは `components/ui/` に配置
- アプリケーション固有のコンポーネントは `app/components/` に配置し、機能別にサブディレクトリに整理
- コンポーネントは可能な限り純粋関数として実装
- 状態管理は React のコンテキストまたはサーバーコンポーネントを活用

## データフロー

- サーバーコンポーネントを優先し、必要な場合のみクライアントコンポーネントを使用
- データベースアクセスは Prisma クライアントを通じて行う
- API ルートは `app/api/` ディレクトリに配置
- サーバーアクションは `actions.ts` に定義し、フォーム送信やデータ変更に使用

## 認証とセキュリティ

- Kinde Auth を使用した認証システム
- ミドルウェアを使用して保護されたルートへのアクセスを制御
- `requireUser.ts` ユーティリティを使用して認証済みユーザーのみがアクセスできるページを保護

## API 設計

- RESTful 原則に従った API エンドポイント
- API ルートは機能ごとにサブディレクトリに整理
- Webhook エンドポイントは専用のサブディレクトリに配置
- レスポンスは一貫した形式で返す

## データベース設計

- Prisma スキーマで明確なリレーションシップを定義
- 外部キー制約を適切に使用
- インデックスを効率的なクエリのために設定
- 列名は一貫した命名規則に従う（camelCase）

## スタイリング

- Tailwind CSS を使用したスタイリング
- コンポーネント固有のスタイルはコンポーネントファイル内に定義
- グローバルスタイルは `globals.css` に定義
- ダークモードサポートは ThemeProvider を通じて実装

## ファイル命名規則

- コンポーネントファイル: PascalCase（例: `Hero.tsx`）
- ユーティリティファイル: camelCase（例: `db.ts`）
- ページファイル: `page.tsx`
- レイアウトファイル: `layout.tsx`
- API ルート: `route.ts`

## エラー処理

- try/catch ブロックを使用した明示的なエラーハンドリング
- ユーザーフレンドリーなエラーメッセージを表示
- サーバーエラーは適切にログに記録

## パフォーマンス最適化

- 画像最適化に Next.js の Image コンポーネントを使用
- コンポーネントの適切な分割とコード分割
- 不要なレンダリングを避けるためのメモ化
- サーバーコンポーネントを活用したクライアントバンドルサイズの削減

生成されたルールの特徴

Cline が生成したルールには以下のような特徴があります

• 項目ごとに見出し（##）で明確に区分けされている
• 単一ファイルに全ての情報が集約されている
• 一般的なドキュメントのような読みやすい構造
• セクションごとに簡潔にまとまっており視認性が高い
• 実装者が必要な情報にすぐにアクセスできる構造

Cursor との比較分析

同じプロジェクトで、Cursor を使ってルールを自動生成した場合との違いを見てみましょう。公平な比較のため、同じ Claude モデル（3.7 Sonnet）を使用しています。

使用したプロンプト

/Generate Cursor Rules このプロジェクトのアーキテクチャルールを作成して

生成結果（一部抜粋）

# プロジェクト構造

このプロジェクトはNext.jsとPrisma（PostgreSQL）を使用したブログプラットフォームです。

## 主要ディレクトリ

- `app/` - Next.jsのApp Router構造に基づくページとルート
- `components/` - 再利用可能なUIコンポーネント
- `lib/` - ユーティリティ関数と共通ロジック
- `prisma/` - データベーススキーマと設定
- `public/` - 静的アセット

## 重要なファイル

- @app/layout.tsx - メインレイアウトコンポーネント
- @prisma/schema.prisma - データベースモデル定義
- @app/actions.ts - サーバーアクション

# コンポーネントアーキテクチャ

## コンポーネント構造

- `components/ui/` - 再利用可能な基本UIコンポーネント（shadcn/ui）
- `app/components/` - 特定のページやセクション向けのコンポーネント

## 設計ルール

1. **Atomic Design原則** - コンポーネントは原子、分子、有機体の階層で構築
2. **コンポーネントの再利用** - 共通要素は抽象化してcomponentsディレクトリに配置
3. **ページ固有のコンポーネント** - 特定のページでのみ使用するコンポーネントはapp/[route]/componentsに配置

## 命名規則

- コンポーネント名はPascalCase（例：`Button.tsx`、`PostCard.tsx`）
- フックはuse接頭辞を使用（例：`useAuth.ts`）

# データモデルと状態管理

## データベースモデル

このプロジェクトはPrismaを使用してPostgreSQLと連携します。主要なモデルは：

- `User` - ユーザー情報と認証
- `Site` - ブログサイト情報
- `Post` - ブログ記事
- `Subscription` - 課金とサブスクリプション

詳細は@prisma/schema.prismaを参照してください。

## データフェッチ

1. **サーバーコンポーネント** - React Server ComponentsとServer Actionsを優先使用
2. **クライアントアクション** - フォーム送信などはapp/actions.tsで定義されたServer Actionsを使用

## 状態管理

1. **サーバー状態** - Prismaクライアントを使用したデータベースアクセス
2. **認証状態** - Kinde Auth（@kinde-oss/kinde-auth-nextjs）を使用

Cursor は合計で 10 個のファイルを生成しました。各ファイルは特定の関心領域に焦点を当てており、詳細な情報を提供しています。

生成されたルールの特徴

• 機能ごとに独立したファイルに分割されている（合計 10 ファイル）
• @file アノテーションを使用して関連ファイルへの参照を提供
• 各トピックについて深い専門知識を反映した詳細な内容
• ファイル間の相互参照により、関連情報に容易にアクセス可能
• プロジェクト固有の詳細情報をより多く含む

まとめ

Cline に新しく追加されたルール生成機能で何ができるのか、どのようなルールを生成してくれるのかをみてみました。

結論、めっちゃ使えるのではと個人的には思います。

また、Cursor での生成ルールとの比較もしてみましたが、結構な違いがありましたので、Cline と Cursor の両方を使用しているユーザーにとっては同じルールを使用するとはいかなさそうです。
ただ、Cline のルールを基に Cursor のルールを生成させるみたいなことは可能なため、自分で一からルールを作成するのに比べると格段にハードルが下がったことは間違いないですね！

いっぱい活用していきましょう！