Cursor 向け RIPER-5 高度エージェント制約モード

RIPER-5 は、コミュニティが作成した制約フレームワークであり、AI の幻覚と不正なコード変更を劇的に減らすことが実証されています。元々は Claude 3.7 向けに設計されましたが、Cursor の Agent モードでも非常に優れた性能を発揮します。このガイドでは、5 つのフェーズとその実装方法について説明します。

RIPER-5 とは？

RIPER-5 は以下を表します：

フェーズ	名前	目的
R	Research（研究）	変更を加えずに情報を収集する
I	Identify（特定）	正確な問題や要件を特定する
P	Plan（計画）	詳細な承認済み計画を作成する
E	Execute（実行）	承認された計画のみを実装する
R	Review（レビュー）	実装を検証しテストする

5 つのフェーズの詳細

フェーズ 1：研究（R）

ルール：読み取り専用。ファイルの変更は許可されません。

アクション：

• 関連ファイルを読み込む
• Grep でコードベースを検索する
• 既存のパターンを分析する
• 依存関係を理解する

出力：調査結果を含む研究サマリー

## 研究フェーズ完了

### 分析したファイル
- `src/auth/login.ts` - 現在の認証フロー
- `src/middleware/auth.ts` - JWT 検証
- `tests/auth.test.ts` - 既存のテスト

### 主な発見
1. 認証は 15 分で期限切れになる JWT を使用
2. リフレッシュトークン機構が存在しない
3. パスワードリセットが未実装
4. テストはログインをカバーするがエッジケースはカバーしていない

### 依存関係
- jsonwebtoken: ^9.0.0
- bcrypt: ^5.1.0

フェーズ 2：特定（I）

ルール：正確な問題文を定義する。

アクション：

• 問題を明確に述べる
• 受け入れ基準を定義する
• 制約を特定する
• 潜在的なリスクを記録する

出力：問題定義ドキュメント

## 問題の特定

### 問題文
ユーザーは 15 分後にログアウトされ、再認証が必要になる。
これは長時間セッションにとって悪い UX を生み出す。

### 根本原因
JWT トークンは 15 分で期限切れとなり、リフレッシュ機構がない。

### 受け入れ基準
- [ ] ユーザーは 7 日間ログイン状態を維持する
- [ ] リフレッシュトークンは使用するたびにローテーションする
- [ ] 古いリフレッシュトークンは無効化される
- [ ] ユーザーはすべてのセッションを取り消せる

### 制約
- 後方互換性を維持する必要がある
- 既存の API に破壊的変更を加えない
- 既存の JWT ミドルウェアと連携する必要がある

### リスク
- リフレッシュトークンが侵害された場合のトークン窃取
- トークン追跡のためのデータベースストレージ

フェーズ 3：計画（P）

ルール：詳細なステップバイステップの計画を作成する。

アクション：

• 修正するすべてのファイルを一覧する
• ファイルごとの正確な変更を指定する
• テスト戦略を定義する
• ロールバック手順を計画する

出力：詳細な実装計画

## 実装計画

### 修正するファイル

#### 1. `src/models/refresh-token.ts` (新規)
```typescript
// リフレッシュトークンのスキーマ
// フィールド：id, userId, token, createdAt, expiresAt, revoked

2. src/services/auth.ts (修正)

• createRefreshToken() 関数を追加
• rotateRefreshToken() 関数を追加
• revokeAllUserTokens() 関数を追加

3. src/routes/auth.ts (修正)

• POST /refresh エンドポイントを追加
• POST /revoke エンドポイントを追加

4. src/middleware/auth.ts (修正)

• より長いセッションをサポートするよう JWT 検証を更新

テスト計画

1. トークンローテーションの単体テスト
2. リフレッシュフローの統合テスト
3. トークン無効化のセキュリティテスト

ロールバック計画

1. リフレッシュトークンモデルを削除
2. 認証サービスの変更を元に戻す
3. 新しいエンドポイントを削除

### フェーズ 4：実行（E）

**ルール**：計画された内容のみを実装する。

**アクション**：
- 計画された変更を行う
- 計画を正確に遵守する
- 各ファイルの後に進捗を報告する
- 計画の修正が必要な場合は停止する

**出力**：進捗追跡付きの実装

```markdown
## 実行フェーズ

### 進捗
- [x] `src/models/refresh-token.ts` を作成
- [x] `src/services/auth.ts` を修正
- [ ] `src/routes/auth.ts` を修正（進行中）
- [ ] `src/middleware/auth.ts` を更新

### 行った変更
1. RefreshToken モデルとフィールドを追加
2. トークンローテーションロジックを実装
3. 無効化サポートを追加

### 次のステップ
- リフレッシュエンドポイントを追加
- ミドルウェアを更新

フェーズ 5：レビュー（R）

ルール：すべてが計画通りに動作することを検証する。

アクション：

• すべてのテストを実行する
• リグレッションを確認する
• 受け入れ基準を検証する
• 逸脱を文書化する

出力：レビューレポート

## レビューフェーズ

### テスト
- [x] 単体テスト合格 (15/15)
- [x] 統合テスト合格 (8/8)
- [x] セキュリティテスト合格 (5/5)

### 受け入れ基準
- [x] ユーザーは 7 日間ログイン状態を維持する
- [x] リフレッシュトークンは使用するたびにローテーションする
- [x] 古いリフレッシュトークンは無効化される
- [x] ユーザーはすべてのセッションを取り消せる

### リグレッション
- 検出なし

### 計画からの逸脱
- トークンクリーンアップの cron ジョブを追加（元の計画にはなし）
- 理由：期限切れトークンによるデータベース肥大化を防止

Cursor での RIPER-5 設定

ステップ 1：ルールファイルを作成

.cursor/rules/riper5-mode.mdc を作成：

---
description: 'RIPER-5 高度制約モード'
globs: ['**/*']
alwaysApply: true
---

# RIPER-5 モード

すべてのタスクで RIPER-5 ワークフローに従う必要があります。

## フェーズ順序
1. **研究** - 読み込みと分析のみ
2. **特定** - 問題を定義
3. **計画** - 詳細な計画を作成
4. **実行** - 計画のみを実装
5. **レビュー** - 検証とテスト

## フェーズルール

### 研究フェーズ
- Read、Grep、Search ツールのみ使用
- ファイル変更は禁止
- コード生成は禁止
- 構造化された形式で発見を提示

### 特定フェーズ
- 問題を明確に述べる
- 受け入れ基準を定義
- 制約を一覧化
- リスクを特定

### 計画フェーズ
- 修正するすべてのファイルを一覧
- 各ファイルの正確な変更を表示
- テスト戦略を含める
- ロールバック計画を含める
- ユーザー承認を待つ

### 実行フェーズ
- 計画された変更のみを実装
- 各ファイルの後に報告
- 行き詰まった場合は質問
- 計画外の変更は禁止

### レビューフェーズ
- すべてのテストを実行
- 受け入れ基準を検証
- リグレッションを確認
- 逸脱を文書化

## 重要
- フェーズをスキップしない
- 研究フェーズでファイルを変更しない
- 実行フェーズで計画外の変更を加えない
- 実行フェーズの前に必ず承認を得る

ステップ 2：システムプロンプトに追加

Cursor 設定で：

## RIPER-5 ワークフロー

すべてのタスクで、以下の 5 つのフェーズに従う必要があります：

1. **研究**：変更なしで読み込みと分析
2. **特定**：正確な問題を定義
3. **計画**：詳細な実装計画を作成
4. **実行**：承認された計画のみを実装
5. **レビュー**：すべてが正常に動作することを確認

現在のフェーズを完了せずに次のフェーズに進むことはできません。
研究フェーズや特定フェーズでファイルを変更することはできません。
実行フェーズで計画外の変更を加えることはできません。

ステップ 3：簡単なタスクで練習

小さなタスクから始めて慣れましょう：

[タスク] 日付をフォーマットするユーティリティ関数を追加する。

RIPER-5 に従う：
1. 既存の日付処理を研究する
2. 必要なものを特定する
3. 実装を計画する
4. 承認後に実行する
5. 結果をレビューする

上級：チェックポイント付き RIPER-5

Git 統合

# 開始前（研究フェーズ）
git checkout -b feature/riper5-task
git commit -m "checkpoint: before RIPER-5 implementation"

# 研究フェーズ後
git add research-notes.md
git commit -m "riper5: research complete"

# 計画フェーズ後（承認前）
git add plan.md
git commit -m "riper5: plan created, awaiting approval"

# 実行フェーズ後
git add -A
git commit -m "riper5: implementation complete"

# レビューフェーズ後
git commit -m "riper5: review passed, tests green"

有効性の測定

以下のメトリクスを追跡しましょう：

メトリクス	RIPER-5 導入前	RIPER-5 導入後
不正な変更	高	ほぼゼロ
計画承認率	該当なし	>90%
変更後のテスト合格率	60%	95%
ロールバック頻度	高	低
ユーザー満足度	まちまち	高

一般的な課題

課題	解決策
エージェントがフェーズをスキップ	厳格なルールで強制
計画が広すぎる	ファイルレベルの特異性を要求
レビューが表面的	テスト実行を義務化
簡単なタスクを遅くする	些細な変更にはショートカットを許可

クイックリファレンス

[RIPER-5 開始]

フェーズ 1/5：研究
[エージェントが読み込みと分析]

フェーズ 2/5：特定
[エージェントが問題を定義]

フェーズ 3/5：計画
[エージェントが計画を作成]
[ユーザー：承認または修正]

フェーズ 4/5：実行
[エージェントが実装]

フェーズ 5/5：レビュー
[エージェントが検証]

[RIPER-5 完了]

関連リソース

• Cursor Agent Mode Masterclass
• Plan vs Act Dual-Mode Workflow
• Cursor Self-Review Hooks Guide