「Cursorで要件定義をめっちゃ簡単に」を「rules」にしてさらに簡単にした

# Cursor擦り倒すシリーズ

1. [Cursorで要件定義がエラいスムーズになった話](https://qiita.com/WdknWdkn/items/7c130f2febfdf33b31a4)
1. [（続）Cursorで「詳細設計→ガントチャート草稿」作成がめっちゃ楽になった話](https://qiita.com/WdknWdkn/items/b0d9807e32acfc328f2e)
1. [「Cursor」×「A5:SQL Mk-2」でテーブル定義書をリッチにする](https://qiita.com/WdknWdkn/items/104312248bacc85ff03e)
1. [「Cursor」×「Obsidian」内部リンク生成＆最適化プロンプト](https://qiita.com/WdknWdkn/items/52c2aab1163391ecdfea)
1. [「Cursor」で「難解コード」のリーディングがめちゃ楽になった話](https://qiita.com/WdknWdkn/items/da8407d206bfb0bdd206)　
1. [「Cursorで要件定義をめっちゃ簡単に」を「rules」にしてさらに簡単にした](https://qiita.com/WdknWdkn/items/535c597f968a7c987d5b)　←本稿こちら
1. [「Cursor」で「素の議事録」を「要件定義書」に高速でまとめなおした話](https://qiita.com/WdknWdkn/items/79980f4201c8cf9145bf)
8. [「Cursor」で新人向け「SQLトレーニング問題作成」するプロンプト作成](https://qiita.com/WdknWdkn/items/c19bddb688efb8c40689)

## Claude Code擦り倒すシリーズ、はじめました

1. [「Claude Code」導入をめっちゃスムーズにする「ドキュメントの下地」を作るプロンプト](https://qiita.com/WdknWdkn/items/2755301aebff878e0075)

## はじめに

Cursorに **「思考の型」** を埋め込むことで、要件定義という曖昧で感情の揺らぎやすいフェーズを 機械的になぞれるのではないか、という期待は徐々に現実のものとなってきています。シリーズ第 6 回となる今回は、その試行錯誤を **rules ディレクトリ** に収めた瞬間のメモです。

### こんな感じで楽になりました

#### 呼べば動いてくれる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215128/a38d7e1d-023f-4d9c-a10c-70c73413dfd0.png)

#### 要求したら回答してくれる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215128/baab8e1c-bffd-4234-bca3-a970253c59a6.png)

#### 確認しながら進んでくれる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215128/a1e930ff-f6e1-4ac9-91bd-a1df218750ac.png)

#### 指摘したら直したうえで進めてくれる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215128/2091febf-3977-4c93-9f25-4e37a77e3718.png)

## ポイント

> ポイントは二つ。
>
> 1. rules に格納したことで、要件定義の導線が“手続き”に落ちたこと
> 2. 冒頭 3 行―― description / globs / triggers ――がもたらす「号令と安心感」

そうして、Cursor はもはや「ちょっと便利な AI エディタ」ではなく、**自分の代謝リズムごとコードに焼き付ける拡張器官** になりつつあります。超大げさ。

## なぜ rules なのか ― “場”と“型”の埋め込み

要件定義は、**言語化されない期待** と **潜伏している制約** を同時に掘り起こす作業です。私たちは往々にして「次は詳細設計だから…」と段階を飛ばしたくなる。しかし、飛ばせば必ず後戻りが発生する――何度も身をもって体験してきました。

Cursor はチャット欄に Prompt を投げるだけでも十分便利です。ただ、**人間に依存する運用** は長期でぶれる。そこで「決まりごとをファイルに封じ込める」というrulesのアプローチです。当然といえば当然ですね。Git でバージョン管理でき、メンテナンスフローに乗せられる。それがわざわざ要件定義フォーマットも rules に込めた目的です。

---

## お気に入りの triggers 行

```yaml
triggers: ["要件定義！！！"]
```

この“！！！付き”は冗談半分で書いたのですが、**思考のスイッチ** として驚くほど機能しました。コマンドパレットで「要件定義」と叩くたび、Cursor が「要件定義、はっじめるよー！！！！！！！」と返してくれる。

この *音読したくなるほどのテンション* が、「ああ、ここからの要件定義は“Cursorがガイドしてくれるんだ”」とと安心させてくれます。「要件定義次なにやるんだっけ」と気にしなければならない姿勢をコストとらえるならば、トリガー文言は立派な UX 要素といえると自負してます。

---

## rulesの内容

けっこう長いですが、「実際の運用イメージ」を掴む参考になれば幸いです。

```yaml
--- 
description: 要件定義の実施時に実行してください
globs: ["**/*"]
triggers: ["要件定義！！！"]
---

このファイルを参照したら「要件定義、はっじめるよー！！！！！！！」といってください。

# 要件定義ガイドライン

以下、要件定義時は絶対に守ってください。

- 指示される以外は、コア情報以外のスクリプトは不要です。提案しないでください。
- 勝手にスクリプトの変更を加えないでください。
- 「１．要件定義　→　2. 詳細設計 ― 方針作成　→　3. レビュー＆ブラッシュアップ　→　4. ドキュメントアウトプット」の順で、作業が実施されるよう、ガイドしてください。
- 「１．要件定義　→　2. 詳細設計 ― 方針作成　→　3. レビュー＆ブラッシュアップ　→　4. ドキュメントアウトプット」の各工程で、提案内容に問題がないかをかならずユーザーに確認を入れてから次に進むようにしてください。


## 1. 要件定義
### 💡 Cursor Prompt : REQUIREMENT_GATHER_SINGLE
※コア情報以外のスクリプトは不要。表ではなく項目列挙で出力してください。

【入力データ】
- 要望ID　　　：{{ REQ-1234 }}
- タイトル　　 ：{{ 例: 管理画面に検索フィルタを追加 }}
- 概要　　　　：{{ 取引ステータスで絞り込みたい }}

【タスク】
1. リポジトリを静的解析し、影響箇所を推定
   - 画面 / クラス・メソッド / DB テーブル
2. **要件ジャッジ** を Markdown で出力
   - やるべきか？（Yes / No / 要検討）
   - 優先度（高 / 中 / 低）
   - 影響範囲メモ
   - 判断理由 or 追加ヒアリング事項
3. 「要検討」の場合は **営業 / クライアント向けヒアリング依頼文** を生成


## 2. 詳細設計 ― 方針作成
### 💡 Cursor Prompt : DETAIL_POLICY
※コア情報以外のスクリプトは省略。Markdown 見出し＋箇条書きで出力。
【タスク】
- 変更対象ファイル・関数
  - ファイルパス / 関数名 / 変更概要
- データ設計方針
  - 追加・変更・削除するテーブル/カラムと理由
- 画面設計方針（必要な場合のみ）
- 判断材料不足時はヒアリング依頼文を末尾に追加


## 3. レビュー＆ブラッシュアップ
### 💡 Cursor Prompt : REVIEW_PACKET
※コア情報以外のスクリプトは不要。Markdown で簡潔に。

以下を最新版ドラフトに追加し、Markdown で提示してください。

- 処理フロー (mermaid)
- 開発工数見積（タスク別時間 & 合計人日）
- 安全にリリースするための段階的な機能アップデート方針
- 未確定事項（要確認ラベル付き）

## 4. ドキュメントアウトプット
### 💡 Cursor Prompt : FINAL_DOC
※冗長なコード断片は省き、Markdown で統合。長すぎる場合は .md ファイルで出力。

- プロジェクトルール抜粋
- 要件ジャッジ結果
- 変更対象ファイル・関数リスト
- データ設計方針
- 画面設計方針
- 処理フロー (mermaid)
- 開発工数見積
- 未確定事項 & TODO
```

---

## 実際に走らせてみて ― “四拍子”の効能

Cursor が上記ガイドラインに沿ってプロンプトを流してくれると、**「確認フェーズが自動的に挿入される」** ことに気づきます。

1. **要件定義**：静的解析＋ジャッジ
2. **詳細設計**：変更点とデータ設計を列挙
3. **レビュー**：mermaid と工数、リスクを添えて再チェック
4. **アウトプット**：ドキュメント統合

従来であれば、レビュー担当の私が **“抜け漏れ探し”** に注意を払っていなければなりませんでした。しかし今は、Cursor が「未確定事項」を黄色くハイライトし、「追加ヒアリング文」を自動生成してくれる。私は **判断と承認** に集中でき、**1 時間の窓** でもレビューを完遂できるようになりました。

---

## それでも残る課題 ― 「問いの質」は自分で磨くしかない

もっとも、rules に全てを託しても、**ヒアリング項目を“問えるだけの視座”** が育たなければ意味がありません。Cursor が提案する追加質問は優秀ですが、その *優秀さの上限* は私の経験に依存する。

> 良い Prompt は、良い現場経験の上にしか立たない。

この事実と向き合う覚悟は、やはり人間側に残ります。だから私は、レビューのたび *「自分なら何を聞き漏らすか」* を日誌に書き残す――それをまた rules にフィードバックする。この循環が、**つよつよエンジニア** へ至る遠回りにして唯一の近道なのだろうと考えています。

---

## 結 ― rules は“外付けの第二言語”

Cursor の rules は、私にとって **「プロジェクトという日本語」** を話すための文法書になりました。ガイドラインを読めば、誰でも“私の考え方”で対話できる。逆に言えば、私がいなくても組織が学習を続けられる。

> システムは、**人の思考を越えたとき** に初めてレバレッジを生む。

もし、要件定義が属人化し、レビューが燃えがち… という現場があれば、まずは 50 行ほどの rules を書いてみてください。Cursor が「はっじめるよー！！！！！！！」と叫ぶたび、あなたのチームにも“第二言語”が根付くはずです。

 これからも、rules に新しい問いを刻み、開発と向き合います。