作成日: 2026-05-26
目的: 「Cursor公式ベストプラクティス完全準拠」と言える水準に近づけるための、Rules / Skills / AGENTS.md / MCP / 検証 / 棚卸しを含む実務テンプレート。
注意: Cursor社の公式テンプレートではない。公式ドキュメントの現行仕様に沿って、実務で破綻しにくい形に再設計したもの。
1. 結論
多くのプロンプトは、入門用の自動生成プロンプトとしては有用です。
ただし、以下の理由で「Cursor社の公式テンプレート完全準拠」とは言い切れません。
-
.mdcだけを前提にしており、.md/.mdc/AGENTS.md/ Skills の使い分けが弱い。 -
alwaysApply/description/globsの適用条件設計が不足している。 -
skills.md一本化は、長期運用で知見ログ・ルール・設計判断が混ざりやすい。 - ルールの増殖、重複、陳腐化、競合を止める棚卸しフローがない。
- 生成後に「本当に効いているか」を検証するテスト手順がない。
- セキュリティ、秘密情報、生成物、外部ツール連携、承認境界の設計が薄い。
この100点版では、Rulesは常時・条件付きの行動制御、Skillsは再利用可能な作業手順、AGENTS.mdは軽量なプロジェクト説明、MCPは外部データ・ツール接続として分離します。
2. 100点版の基本思想
2.1 Rulesに入れるもの
Rulesは、AIエージェントに毎回守らせたい行動原則・設計規約・プロジェクト固有の判断基準です。
入れてよいもの:
- プロジェクト固有のアーキテクチャ方針
- 既存コードの読み方
- 変更前に確認すべきファイル
- ディレクトリ別の責務
- テスト方針
- 生成物・依存関係・秘密情報を触らないルール
- 反復して発生したAIのミスへの対策
入れない方がよいもの:
- 一般的すぎるコーディング作法
- linter / formatter / CI で機械的に担保できる内容
- 長大な設計書の丸コピー
- 一度しか使わない手順
- まれな例外条件の羅列
- 実装コマンド一覧の百科事典化
2.2 Skillsに入れるもの
Skillsは、Agentに「この作業はこう進める」と教える再利用可能なワークフローです。
入れるべきもの:
- ADR作成
- 障害調査
- リファクタリング計画
- DB変更レビュー
- Pull Request自己レビュー
- ドキュメント更新
- 要件から設計書を起こす作業
- 既存コードから仕様を逆算する作業
- スクリプトやテンプレートを伴う反復作業
Rulesに作業手順を詰め込みすぎると、Agentの常時コンテキストが重くなります。
頻繁に守る判断基準はRules、必要時に呼び出す手順はSkillsに分けます。
2.3 AGENTS.mdに入れるもの
AGENTS.mdは、Project Rulesより軽量なプロジェクト説明です。
向いている内容:
- プロジェクトの目的
- 最重要ディレクトリ
- 起動・テスト・ビルドの代表コマンド
- チーム内での基本方針
- 新規参加者向けの短い説明
複雑な適用条件が必要な場合は、AGENTS.mdではなく .cursor/rules/*.mdc に分けます。
2.4 MCPに任せるもの
MCPは、Cursorに外部ツールや外部データを接続するための仕組みです。RulesやSkillsに、Jira、Notion、GitHub、Redmine、Google Drive、DBなどの情報を長文コピーするのは悪手です。
MCP向きの対象:
- Jira / Redmine / GitHub Issue
- Notion / Google Drive / 社内ドキュメント
- DBスキーマ参照
- ブラウザ・Figma・監視ツール
- 社内API
ただし、MCPは外部ツールやローカルコマンドを実行できるため、秘密情報・権限・承認フローの設計が必須です。
3. 推奨ディレクトリ構成
project-root/
├─ AGENTS.md
├─ .cursor/
│ ├─ rules/
│ │ ├─ 00-core.mdc
│ │ ├─ 10-architecture.mdc
│ │ ├─ 20-frontend.mdc
│ │ ├─ 21-backend.mdc
│ │ ├─ 22-database.mdc
│ │ ├─ 30-testing.mdc
│ │ ├─ 40-documentation.mdc
│ │ ├─ 50-security-and-secrets.mdc
│ │ └─ 90-rule-maintenance.mdc
│ ├─ skills/
│ │ ├─ capture-learning/
│ │ │ └─ SKILL.md
│ │ ├─ create-adr/
│ │ │ └─ SKILL.md
│ │ ├─ audit-rules/
│ │ │ └─ SKILL.md
│ │ ├─ reverse-spec/
│ │ │ └─ SKILL.md
│ │ └─ pr-self-review/
│ │ └─ SKILL.md
│ └─ mcp.json.example
├─ docs/
│ ├─ adr/
│ ├─ ai/
│ │ ├─ learnings/
│ │ ├─ rule-audits/
│ │ └─ prompts/
│ └─ architecture/
└─ scripts/
└─ ai/
4. 適用先の判断表
| 入れたい内容 | 置き場所 | 理由 |
|---|---|---|
| 常に守る安全原則 | .cursor/rules/00-core.mdc |
常時適用する必要がある |
| ディレクトリ別の実装規約 | .cursor/rules/*.mdc |
globs で対象を絞れる |
| Agentが必要時だけ参照すべき作業手順 | .cursor/skills/<name>/SKILL.md |
常時コンテキストに載せない |
| プロジェクト概要 | AGENTS.md |
軽量で読みやすい |
| 設計判断の履歴 | docs/adr/ADR-xxxx.md |
ルールではなく意思決定ログ |
| 日々の学び・バグ対策 | docs/ai/learnings/YYYY-MM.md |
後で棚卸ししてRules/Skillsに昇格 |
| 外部ツール接続 | .cursor/mcp.json |
Rulesに外部情報を貼らない |
| ワンショットの作業依頼 | Chat / 一時プロンプト | 永続化しない |
5. 適用条件の設計
Cursor Rulesは、alwaysApply / description / globs の組み合わせで読み込まれ方が変わります。
100点版では、以下の基準で分けます。
5.1 Always Apply
使う対象:
- セキュリティ
- 秘密情報の扱い
- 変更前の確認姿勢
- 生成物・vendor・依存関係を不用意に編集しない方針
- 不明点がある場合に関連ファイルを読む方針
例:
---
alwaysApply: true
---
5.2 Apply Intelligently
使う対象:
- アーキテクチャ判断
- 設計レビュー
- ADR作成
- 大きめのリファクタリング
- 実装方針相談
例:
---
description: "バックエンドのサービス層、ドメイン層、API境界を変更するときの設計判断ルール"
alwaysApply: false
---
5.3 Apply to Specific Files
使う対象:
- React / Vue / C# / SQL / Python / Terraform など、ファイル種別に強く依存する規約
- テストファイル
- DBマイグレーション
- ドキュメント
例:
---
globs: "src/**/*.ts, src/**/*.tsx"
alwaysApply: false
---
5.4 Apply Manually
使う対象:
- たまにしか使わない監査
- 大規模棚卸し
- リリース前チェック
- 移行計画
例:
---
alwaysApply: false
---
チャットで @90-rule-maintenance のように明示して呼び出します。
6. 100点版 Cursor投入プロンプト
以下を setup-cursor-rules-100.md として保存し、Cursor Agentに @setup-cursor-rules-100.md を実行して と依頼します。
# setup-cursor-rules-100.md
あなたは、シニアアーキテクト、Cursor Rules Engineer、AI開発運用設計者です。
このリポジトリを分析し、Cursor Agentが安全かつ高精度に開発支援できるよう、Rules / Skills / AGENTS.md / 運用ログの構成を生成・更新してください。
## 0. 絶対方針
- いきなりファイルを編集しないでください。
- まず分析結果、作成予定ファイル、変更理由、リスクを短く提示してください。
- ユーザーが承認した後にのみ、ファイル作成・更新を行ってください。
- 既存ファイルがある場合は上書きせず、差分方針を提示してください。
- 秘密情報、認証情報、個人情報、`.env`、秘密鍵、トークン、接続文字列を出力・複製・要約しないでください。
- `node_modules`, `.git`, `dist`, `build`, `.next`, `coverage`, `vendor`, `bin`, `obj`, `tmp`, `logs` などの生成物・依存関係ディレクトリは分析対象から除外してください。
- linter / formatter / CI で担保すべき内容をRulesに長々と書かないでください。
- Rulesは原則として1ファイル500行未満にしてください。
- 長大な設計書やREADMEをRulesにコピーせず、必要なら `@filename` 参照にしてください。
## 1. 分析してください
次の観点でリポジトリを分析し、短いサマリーを出してください。
1. 技術スタック
- 言語
- フレームワーク
- パッケージマネージャ
- DB
- テスト基盤
- ビルド・デプロイ方法
2. ディレクトリ構造
- UI
- API
- ドメイン
- インフラ
- テスト
- ドキュメント
- 生成物
3. 既存規約
- 命名規則
- エラーハンドリング
- ロギング
- 型定義
- DI / レイヤリング
- SQL / Migration方針
4. 既存のAI向け指示
- `.cursor/rules/`
- `.cursor/skills/`
- `.cursorrules`
- `AGENTS.md`
- `CLAUDE.md`
- `GEMINI.md`
- `docs/ai/`
5. 事故リスク
- 秘密情報
- 壊してはいけない生成物
- 自動生成コード
- DB破壊的変更
- 外部API副作用
- 大量変更リスク
## 2. 出力する構成
原則として、次の構成を作成・更新してください。存在しない領域だけ作成し、既存ファイルは差分更新案を出してください。
```text
AGENTS.md
.cursor/rules/00-core.mdc
.cursor/rules/10-architecture.mdc
.cursor/rules/20-frontend.mdc
.cursor/rules/21-backend.mdc
.cursor/rules/22-database.mdc
.cursor/rules/30-testing.mdc
.cursor/rules/40-documentation.mdc
.cursor/rules/50-security-and-secrets.mdc
.cursor/rules/90-rule-maintenance.mdc
.cursor/skills/capture-learning/SKILL.md
.cursor/skills/create-adr/SKILL.md
.cursor/skills/audit-rules/SKILL.md
.cursor/skills/pr-self-review/SKILL.md
docs/ai/learnings/.gitkeep
docs/ai/rule-audits/.gitkeep
docs/adr/.gitkeep
```
ただし、プロジェクトに存在しない領域のRulesは無理に作らないでください。たとえばフロントエンドが存在しないなら `20-frontend.mdc` は作成不要です。
## 3. Rules作成基準
### 3.1 `00-core.mdc`
- `alwaysApply: true` にしてください。
- すべての作業に共通する短い原則のみを書いてください。
- セキュリティ、変更前確認、生成物除外、テスト実行方針、推測で進めない姿勢を含めてください。
- 具体的すぎる実装規約は入れないでください。
例:
```yaml
---
alwaysApply: true
---
```
### 3.2 `10-architecture.mdc`
- `description` を使う Apply Intelligently にしてください。
- レイヤリング、依存方向、ドメイン境界、既存設計の読み方を記述してください。
- 大きな設計変更では、実装前に影響範囲と代替案を提示させてください。
例:
```yaml
---
description: "設計変更、レイヤリング、責務分割、依存方向、アーキテクチャ判断に関するルール"
alwaysApply: false
---
```
### 3.3 ファイル種別Rules
ファイル種別が明確なRulesは `globs` を使ってください。
例:
```yaml
---
globs: "src/**/*.ts, src/**/*.tsx"
alwaysApply: false
---
```
Rules本文には、対象ファイルで守るべきプロジェクト固有ルールだけを書いてください。
### 3.4 `90-rule-maintenance.mdc`
- 原則 `alwaysApply: false` の手動呼び出しにしてください。
- ルール棚卸し、重複削除、古いルールの廃止、Skillsへの移管、AGENTS.mdへの移管を扱ってください。
- 月1回、または大きなアーキテクチャ変更後に使う想定で書いてください。
## 4. Skills作成基準
Skillsは `.cursor/skills/<skill-name>/SKILL.md` として作成してください。
### 4.1 `capture-learning`
目的:
- 日々の開発で得た知見を、その場でRulesに直書きせず、まず `docs/ai/learnings/YYYY-MM.md` に追記候補として整理する。
- ユーザーに確認を求め、承認された内容だけ追記する。
- 後日 `audit-rules` でRules / Skills / ADRに昇格する。
必須仕様:
```yaml
---
name: capture-learning
description: "複雑なバグ解決、設計判断、新しいライブラリ導入、繰り返し発生したAIのミスから、再利用可能な知見を整理する"
---
```
### 4.2 `create-adr`
目的:
- 重要な設計判断を `docs/adr/ADR-YYYYMMDD-title.md` に記録する。
- 背景、選択肢、決定、影響、未決事項を残す。
### 4.3 `audit-rules`
目的:
- `.cursor/rules/`、`.cursor/skills/`、`AGENTS.md`、`docs/ai/learnings/` を棚卸しする。
- 重複、矛盾、古い前提、過剰な常時適用、Rulesに入れるべきでない内容を洗い出す。
- 改善案を出し、承認後に更新する。
### 4.4 `pr-self-review`
目的:
- PR作成前に、差分、テスト、セキュリティ、ドキュメント、後方互換性を自己レビューする。
## 5. AGENTS.md作成基準
AGENTS.mdには、以下だけを簡潔に書いてください。
- プロジェクトの目的
- 主要ディレクトリ
- よく使うコマンド
- 重要な注意点
- 詳細なRules / Skillsへの誘導
AGENTS.mdに長大なルールを書かないでください。
## 6. 生成後の検証
ファイル作成後、次の検証タスクを実施してください。
1. 生成したRulesの一覧を表で出す。
2. 各Ruleの適用方式を示す。
- Always Apply
- Apply Intelligently
- Apply to Specific Files
- Manual
3. 適用方式が妥当な理由を1行で説明する。
4. 重複・矛盾・過剰な常時適用がないか確認する。
5. 代表的な3つの開発タスクを想定し、どのRules / Skillsが適用されるべきかをシミュレーションする。
6. Rulesに入れるべきでない内容が混ざっていないか確認する。
7. 最後に、ユーザーが確認すべき未決事項を列挙する。
## 7. 出力品質条件
- 抽象論で終わらせず、このリポジトリの実ファイル名・実ディレクトリに基づいて書いてください。
- ただし、秘密情報や個人情報は引用しないでください。
- ルールは命令形・肯定形を中心にしてください。
- 「常に」「絶対」は、安全・秘密情報・破壊的変更など、本当に必要な場合だけ使ってください。
- Rulesは短く、具体的に、検証可能にしてください。
- 既存コードに反する理想論を押し付けず、現在の設計と移行可能性を優先してください。
7. 生成されるべき主要ファイルのサンプル
7.1 AGENTS.md
# AGENTS.md
## Project Overview
このプロジェクトは、<プロジェクトの目的を1〜3文で記述>。
## Important Directories
- `src/`: アプリケーション本体
- `tests/`: 自動テスト
- `docs/`: 設計書・運用資料
- `.cursor/rules/`: Cursor Agent向けの永続ルール
- `.cursor/skills/`: 再利用可能な作業手順
## Common Commands
- Build: `<build command>`
- Test: `<test command>`
- Lint: `<lint command>`
## Working Principles
- 変更前に関連ファイルを読み、既存設計に合わせる。
- 破壊的変更は、影響範囲と戻し方を説明してから実施する。
- 秘密情報、認証情報、生成物、依存関係ディレクトリを不用意に編集しない。
- 詳細なルールは `.cursor/rules/`、作業手順は `.cursor/skills/` を参照する。
7.2 .cursor/rules/00-core.mdc
---
alwaysApply: true
---
# Core Agent Rules
- 変更前に、対象ファイルと関連する既存実装を読んでから作業する。
- 不明点がある場合は、推測で大規模変更せず、前提・選択肢・影響範囲を短く提示する。
- `.env`、秘密鍵、トークン、接続文字列、個人情報を出力・複製・要約しない。
- `node_modules`, `.git`, `dist`, `build`, `.next`, `coverage`, `vendor`, `bin`, `obj`, `logs` は原則編集しない。
- 自動生成ファイルを変更する場合は、生成元を特定し、生成手順を優先する。
- 破壊的変更、DB変更、大量リネーム、大量削除は、事前に影響範囲とロールバック案を提示する。
- 実装後は、実行可能な範囲でテスト・型チェック・lint・ビルドのいずれかを行い、結果を報告する。
- ルールと実コードが矛盾する場合は、実コードを確認し、ルール更新候補として報告する。
7.3 .cursor/rules/10-architecture.mdc
---
description: "設計変更、責務分割、依存方向、アーキテクチャ判断、リファクタリング計画に関するルール"
alwaysApply: false
---
# Architecture Rules
- 新しい機能は、既存のディレクトリ責務と依存方向に合わせて配置する。
- 既存のサービス層、ドメイン層、インフラ層、UI層の境界を確認してから変更する。
- 大きな設計変更では、実装前に次を提示する。
- 現状の構造
- 問題点
- 変更案
- 代替案
- 影響ファイル
- テスト観点
- 後方互換性
- 既存パターンがある場合は、まず既存パターンを優先する。
- 既存パターンを変える場合は、理由と移行方針を明記する。
7.4 .cursor/rules/50-security-and-secrets.mdc
---
alwaysApply: true
---
# Security and Secrets Rules
- 秘密情報、APIキー、トークン、パスワード、秘密鍵、接続文字列をチャットやファイルに出力しない。
- `.env` や秘密情報を含む可能性があるファイルを読む必要がある場合は、内容を引用せず、必要なキー名や設定有無だけを扱う。
- 外部API、DB、MCPツール、シェルコマンドを使う変更では、副作用と権限を確認する。
- 認証・認可・権限・監査ログに関わる変更は、テスト観点と悪用シナリオを併記する。
- 依存ライブラリ追加時は、用途、代替手段、ライセンス、メンテナンス状況、セキュリティ影響を確認する。
7.5 .cursor/skills/capture-learning/SKILL.md
---
name: capture-learning
description: "複雑なバグ解決、設計判断、新ライブラリ導入、繰り返し発生したAIのミスから、再利用可能な知見を整理する"
---
# Capture Learning
## When to Use
- 複雑なバグを解決したとき
- 重要な設計判断をしたとき
- 新しいライブラリや外部サービスを導入したとき
- 同じ種類のAIミスが再発したとき
- ユーザーが「これ覚えておいて」「今後のルールにして」と言ったとき
## Instructions
1. 今回の学びを次の形式で要約する。
- 日付
- 背景
- 事象
- 原因
- 対応
- 再発防止
- Rules / Skills / ADR への昇格候補
2. 追記先を `docs/ai/learnings/YYYY-MM.md` とする。
3. 追記前にユーザーへ確認する。
4. 承認後にのみファイルを更新する。
5. すぐにRulesへ直書きせず、後続の `audit-rules` で昇格判断する。
7.6 .cursor/skills/audit-rules/SKILL.md
---
name: audit-rules
description: "Cursor Rules、Skills、AGENTS.md、AI知見ログを棚卸しし、重複・矛盾・陳腐化・過剰適用を整理する"
disable-model-invocation: true
---
# Audit Rules
## When to Use
- 月次棚卸し
- 大きな設計変更後
- Rulesが増えすぎたとき
- Agentの挙動が鈍い・ズレると感じたとき
- 新しい開発チームメンバーが参加したとき
## Instructions
1. `.cursor/rules/` を一覧化する。
2. 各Ruleについて次を確認する。
- 適用方式は妥当か
- 内容は500行未満か
- 重複はないか
- 実コードと矛盾していないか
- SkillsやAGENTS.mdに移すべき内容はないか
3. `.cursor/skills/` を一覧化する。
4. `docs/ai/learnings/` から昇格候補を抽出する。
5. 次の分類で改善案を出す。
- Keep
- Update
- Split
- Merge
- Move to Skill
- Move to AGENTS.md
- Archive
6. ユーザー承認後にのみ更新する。
8. Mermaid図解
8.1 判断フロー
8.2 運用サイクル
9. 検証チェックリスト
9.1 Rules品質
-
alwaysApply: trueが多すぎない。 - セキュリティ系以外を常時適用にしすぎていない。
-
ファイル種別Rulesには
globsがある。 -
Apply Intelligently のRulesには明確な
descriptionがある。 - 手動呼び出しRulesは、常時読み込み不要な内容になっている。
- 各Ruleは500行未満である。
- 長大な設計書をコピーしていない。
- 既存コードと矛盾していない。
- linter / formatter で担保できることをRulesに書きすぎていない。
- 否定形だけでなく、望ましい行動が明記されている。
9.2 Skills品質
-
各Skillは
.cursor/skills/<name>/SKILL.mdにある。 -
nameは親フォルダ名と一致している。 -
descriptionが具体的で、使うタイミングが分かる。 - 常時読ませる必要がない作業手順はSkillsに分離されている。
-
コマンド的に使うSkillには
disable-model-invocation: trueを検討している。 - スクリプトを含む場合、権限・副作用・エラー時の扱いが明記されている。
9.3 運用品質
-
docs/ai/learnings/に一時知見を溜める場所がある。 -
docs/adr/に設計判断を残す場所がある。 - 月次または節目ごとのRules棚卸し手順がある。
- ルール更新前に人間レビューを通す。
- MCPや外部ツール接続の権限を最小化している。
- 秘密情報をRules / Skills / AGENTS.mdに書かない。
10. 元記事からの改善点
| 観点 | 元記事の弱点 | 100点版の改善 |
|---|---|---|
.mdc前提 |
.mdc固定に近い |
.md / .mdc / AGENTS.md / Skillsを使い分け |
| 適用条件 |
globs中心 |
alwaysApply / description / globs / manualを明確化 |
| Skills |
skills.md一本化 |
.cursor/skills/<name>/SKILL.md に分離 |
| 知見蓄積 |
skills.mdに蓄積 |
learnings → audit → Rules/Skills/ADR昇格 |
| 承認 | Accept前提が曖昧 | 変更前に計画提示、承認後編集を明記 |
| 棚卸し | 弱い |
audit-rules Skillを標準化 |
| セキュリティ | 除外対象中心 | 秘密情報、MCP、外部副作用まで明記 |
| 検証 | なし | 適用シミュレーションとチェックリストを追加 |
| 長期運用 | ルールが増える前提 | 分割・統合・廃止・移管を含める |
11. 採点基準
このテンプレートを使っても、生成されたRulesが自動的に100点になるわけではありません。
100点に近づけるには、生成後に以下で採点します。
| 評価軸 | 配点 | 見るポイント |
|---|---|---|
| 公式仕様との整合 | 20 | Rules / Skills / AGENTS.mdの形式と役割が合っているか |
| 適用条件設計 | 15 | alwaysApply過多、globs不足、description不足がないか |
| プロジェクト固有性 | 15 | 実コード・実ディレクトリに基づいているか |
| コンテキスト効率 | 10 | 常時読み込みが重すぎないか |
| セキュリティ | 10 | 秘密情報・外部副作用・破壊的変更を制御できているか |
| 検証可能性 | 10 | 生成後のテスト・シミュレーションがあるか |
| 保守性 | 10 | 棚卸し、統廃合、廃止フローがあるか |
| 実務適用性 | 10 | チームで使える粒度・文体・構成か |
合格ラインは80点。
チーム標準にするなら90点以上。
「完全準拠」とする場合、公式仕様との差分、対象バージョン、検証結果、限界を明記することが大切です。
12. 参考URL
- Cursor Rules: https://cursor.com/docs/rules.md
- Cursor Agent Skills: https://cursor.com/docs/skills.md
- Cursor MCP: https://cursor.com/docs/mcp.md