Cursor擦り倒すシリーズ

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

「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 に新しい問いを刻み、開発と向き合います。