Cursor擦り倒すシリーズ
- Cursorで要件定義がエラいスムーズになった話
- （続）Cursorで「詳細設計→ガントチャート草稿」作成がめっちゃ楽になった話
- 「Cursor」×「A5:SQL Mk-2」でテーブル定義書をリッチにする
- 「Cursor」×「Obsidian」内部リンク生成＆最適化プロンプト
- 「Cursor」で「難解コード」のリーディングがめちゃ楽になった話
- 「Cursorで要件定義をめっちゃ簡単に」を「rules」にしてさらに簡単にした ←本稿こちら
- 「Cursor」で「素の議事録」を「要件定義書」に高速でまとめなおした話
- 「Cursor」で新人向け「SQLトレーニング問題作成」するプロンプト作成
Claude Code擦り倒すシリーズ、はじめました
はじめに
Cursorに 「思考の型」 を埋め込むことで、要件定義という曖昧で感情の揺らぎやすいフェーズを 機械的になぞれるのではないか、という期待は徐々に現実のものとなってきています。シリーズ第 6 回となる今回は、その試行錯誤を rules ディレクトリ に収めた瞬間のメモです。
こんな感じで楽になりました
呼べば動いてくれる
要求したら回答してくれる
確認しながら進んでくれる
指摘したら直したうえで進めてくれる
ポイント
ポイントは二つ。
- rules に格納したことで、要件定義の導線が“手続き”に落ちたこと
- 冒頭 3 行―― description / globs / triggers ――がもたらす「号令と安心感」
そうして、Cursor はもはや「ちょっと便利な AI エディタ」ではなく、自分の代謝リズムごとコードに焼き付ける拡張器官 になりつつあります。超大げさ。
なぜ rules なのか ― “場”と“型”の埋め込み
要件定義は、言語化されない期待 と 潜伏している制約 を同時に掘り起こす作業です。私たちは往々にして「次は詳細設計だから…」と段階を飛ばしたくなる。しかし、飛ばせば必ず後戻りが発生する――何度も身をもって体験してきました。
Cursor はチャット欄に Prompt を投げるだけでも十分便利です。ただ、人間に依存する運用 は長期でぶれる。そこで「決まりごとをファイルに封じ込める」というrulesのアプローチです。当然といえば当然ですね。Git でバージョン管理でき、メンテナンスフローに乗せられる。それがわざわざ要件定義フォーマットも rules に込めた目的です。
お気に入りの triggers 行
triggers: ["要件定義！！！"]
この“！！！付き”は冗談半分で書いたのですが、思考のスイッチ として驚くほど機能しました。コマンドパレットで「要件定義」と叩くたび、Cursor が「要件定義、はっじめるよー！！！！！！！」と返してくれる。
この 音読したくなるほどのテンション が、「ああ、ここからの要件定義は“Cursorがガイドしてくれるんだ”」とと安心させてくれます。「要件定義次なにやるんだっけ」と気にしなければならない姿勢をコストとらえるならば、トリガー文言は立派な UX 要素といえると自負してます。
rulesの内容
けっこう長いですが、「実際の運用イメージ」を掴む参考になれば幸いです。
---
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 が上記ガイドラインに沿ってプロンプトを流してくれると、「確認フェーズが自動的に挿入される」 ことに気づきます。
- 要件定義：静的解析＋ジャッジ
- 詳細設計：変更点とデータ設計を列挙
- レビュー：mermaid と工数、リスクを添えて再チェック
- アウトプット：ドキュメント統合
従来であれば、レビュー担当の私が “抜け漏れ探し” に注意を払っていなければなりませんでした。しかし今は、Cursor が「未確定事項」を黄色くハイライトし、「追加ヒアリング文」を自動生成してくれる。私は 判断と承認 に集中でき、1 時間の窓 でもレビューを完遂できるようになりました。
それでも残る課題 ― 「問いの質」は自分で磨くしかない
もっとも、rules に全てを託しても、ヒアリング項目を“問えるだけの視座” が育たなければ意味がありません。Cursor が提案する追加質問は優秀ですが、その 優秀さの上限 は私の経験に依存する。
良い Prompt は、良い現場経験の上にしか立たない。
この事実と向き合う覚悟は、やはり人間側に残ります。だから私は、レビューのたび 「自分なら何を聞き漏らすか」 を日誌に書き残す――それをまた rules にフィードバックする。この循環が、つよつよエンジニア へ至る遠回りにして唯一の近道なのだろうと考えています。
結 ― rules は“外付けの第二言語”
Cursor の rules は、私にとって 「プロジェクトという日本語」 を話すための文法書になりました。ガイドラインを読めば、誰でも“私の考え方”で対話できる。逆に言えば、私がいなくても組織が学習を続けられる。
システムは、人の思考を越えたとき に初めてレバレッジを生む。
もし、要件定義が属人化し、レビューが燃えがち… という現場があれば、まずは 50 行ほどの rules を書いてみてください。Cursor が「はっじめるよー！！！！！！！」と叫ぶたび、あなたのチームにも“第二言語”が根付くはずです。
これからも、rules に新しい問いを刻み、開発と向き合います。