TL;DR
- Cursorの提案品質は「モデル」だけでなく「ルール」で決まる
- ルールをリポジトリ側に置くと、オンボーディングとレビューが一気に楽になる
- ソロでも、未来の自分に向けてルールを残すだけで“事故率”が下がる
何が起きたか
Cursorを日常の開発に組み込むと、次にぶつかる壁は「指示の揺れ」だ。
そこで、プロジェクトの前提（やること/やらないこと、設計、禁止）を Shared Rules としてリポジトリに置き、Cursorの提案を同じ枠内に収める運用が注目されている。
Shared Rulesに書くべきものは、長文の理想論ではなく、レビューで必ず気にする項目だ。
- 変更粒度: 1PR = 1目的（巨大PR禁止）
- 依存追加: 原則禁止（必要なら理由を明記）
- 例外処理: 例外は握りつぶさない、ログ/メトリクスを残す
- セキュリティ: 秘密情報は絶対にコミットしない
なぜ今重要か
AIコーディングは「作る速度」を上げる一方で、壊す速度も上がる。
Shared Rulesは、壊す速度を抑えるための“ガードレール”として機能する。
特に、ソロで継続運用するなら「迷ったらここを見る」という判断基準が必要だ。
ルールを先に書いておくと、Cursorの提案を採用/却下する判断が早くなる。
ソロビルダー視点（どう使うか）
おすすめは、ルールを3層に分けること:
- Product: 何を作るか、誰向けか（非目標も）
- Engineering: どう作るか（テスト/PR粒度/設計）
- Safety: 何をしてはいけないか（権限/秘密/破壊的操作）
この“ルールの見える化”は、ツールを乗り換えても資産として残る。
関連プロダクト
スコア内訳
| 評価軸 | スコア |
|---|---|
| SNS反応量 | 12/20 |
| メディアカバレッジ | 10/20 |
| コミュニティ反応 | 16/20 |
| 技術的インパクト | 15/20 |
| ソロビルダー関連度 | 17/20 |
| 合計 | 70/100 |
所見: 新機能そのものより、運用の“当たり前”が変わるタイプ。AIコーディングを日常化する人ほど効く。
出典: Cursor