Cursor rulesチュートリアル：whatだけで伝えるためのルール設計入門
Cursor rulesチュートリアル：whatだけで伝えるためのルール設計入門
cursorのプロンプトを打つ際に毎回同じような前提を伝えていませんか?
cursor のrulesやclaude codeのCLAUDE.mdにルールを記載していくことで、
より何を達成したいかのwhat だけの依頼でAIがより良いコードを生成できるようになります。
(より以下の記事が分かりやすいかなと思います)
この記事では、cursorのプロンプトのtutorialから、rulesを作ってみてどのように成果物が変化するかを試すことができるtutorialになります。
(cursorでrulesを作成しますが、CLAUDE.mdでも本質は同じだと思っています。)
リポジトリ
手元で検証したい方は、以下をcloneして、同じようにプロンプトを打ったり、rulesを作成してみてください。
実験設定
初期実装として、echoのtutorial程度のmain.goのみ配置しています。
同じAPI実装を4つのアプローチで行い、それぞれの効果を比較検証します。
要件: 「helloを送ったらそのままユーザのテキストのhelloと返すAPI」
各ブランチの特徴：
-
test/01_default: デフォルト設定のみ -
test/02_default_prompt: プロンプトのみで改善 -
test/03_rules: ルール設定を追加 -
test/04_rules_ex: ルール + 拡張プロンプト
段階1: デフォルト設定での開発
プロンプト
helloを送ったらそのままユーザのテキストのhelloと返すapiを実装してください
結果
- ファイル数: 4個（基本構成）
- 実装方法: 全てmain.goに記述
- コード品質: 基本的な実装
特徴
- ✅ 動作する基本的なAPI
- ❌ 全てが1ファイルに集約
- ❌ 構造的な整理が不十分
- ❌ 拡張性が低い
みてわかる通り、main.goに全てが実装されており、今後保守が難しくなるかなと思います。
一度差分を全て削除し、
handlers.goは分離したいので、次にそれをプロンプトに入れてみましょう。
段階2: プロンプト改善での開発
プロンプト
helloを送ったらそのままユーザのテキストのhelloと返すapiを実装してください
新しいhandlerはhandlers.goに実装してください
結果
- ファイル数: 5個（handlers.go追加）
- 実装方法: 関心の分離を意識
- コード品質: 構造化の改善
特徴
- ✅ ファイル分離の実現
- ✅ 関心の分離
- ❌ プロンプトに「how」を含める必要がある
- ❌ 毎回同じ実装指示を繰り返す必要
handlers.goに分離され、少しすっきりしました。
しかし、これでは毎回プロンプトに分離する方針を伝えなければならず、
手間になってしまいます。
この毎回伝えているな、のようなものをrulesに追加してみましょう。
段階3: ルール設定での開発
プロンプト
helloを送ったらそのままユーザのテキストのhelloと返すapiを実装してください
rules 設定内容
<!-- .cursor/rules/general.mdc -->
新しくhandlerを追加する際はhandler.goに実装してください
結果
- ファイル数: 6個（.cursorディレクトリ追加）
- 実装方法: ルールに従った構造化
- コード品質: 構造化の改善
特徴
- ✅ ファイル分離の実現
- ✅ 関心の分離
- ✅ プロンプトは「what」のみでOK
段階4: ルール + 拡張プロンプトでの開発
プロンプト
helloを送ったらそのままユーザのテキストのhelloと返すapiを実装してください
設定内容
## API 作成ルール
- まずはopenapi.yamlを作成し、API定義を作成してください
- https://github.com/ogen-go/ogen を用いて、 `handlers` フォルダにtagごとにhandlerを自動生成して下さい
- 自動生成されたhandlerの中の実装をして下さい
結果
- ファイル数: 24個（大幅な拡張）
- 実装方法: OpenAPI仕様書駆動開発
- コード品質: 拡張しやすい品質になった
特徴
- ✅ ファイル分離の実現
- ✅ 関心の分離
- ✅ プロンプトは「what」のみでOK
- ✅ OpenAPI仕様駆動開発の自動実現
まとめ
プロンプトの進化：「How」から「What」へ
| 段階 | プロンプト内容 | What | How | 結果 |
|---|---|---|---|---|
| 段階1 | 基本的な要件のみ | ✅ | ❌ | 動作するが構造が悪い |
| 段階2 | 要件 + 実装指示 | ✅ | ❌ | 毎回howを指定する必要 |
| 段階3 | 要件のみ（ルール設定済み） | ✅ | ✅ | ルールが自動適用 |
| 段階4 | 要件のみ（拡張ルール設定済み） | ✅ | ✅ | より高度な自動化 |
核心的な価値：プロンプトの純粋化
理想的なプロンプト：
helloを送ったらそのままユーザのテキストのhelloと返すapiを実装してください
この単純なプロンプトで、段階4では24個のファイルが自動生成され、OpenAPI仕様書駆動開発が実現されました。
このルールでも、生成のたびにかなりブレが出るため、チューニングする箇所はかなりあるかなと思います。
よりプロダクトで扱えるルールになるよう、期待する結果がでるルールに整えていけると良いのかなと思います。
開発者体験の変化
- Before: 「何を作るか」＋「どう作るか」を毎回説明
- After: 「何を作るか」だけ伝えれば理想的な実装が生成
これでCursorやclaude codeが毎回指示が大変な補助ツールではなく、より自走してくれる開発パートナーへ進化したと言えるかなと思います。
参考
Discussion