はじめに
なぜプロンプト評価フレームワークが必要なのか
AIエージェントとのペアプログラミングが当たり前になった今、その成果の質は「どう指示を出すか」に大きく依存します。しかし、一部を除く多くの現場では「なんとなく」でプロンプトを書いているというのが実情のようです。
私自身、Cursor導入初期は「バグを直して」「ログイン機能を追加」といった曖昧な指示を出していました。結果は予想通り、AIが見当違いな修正を繰り返し、かえって時間がかかる始末。「AIをどう使っていいかわからない」という声は必ず上がってきます。
一方でベテランのエンジニア・マネージャーになるほど、思った通りにAIを動かし、今まで以上の成果を上げています。
差分を解決するため、折を見て新人のエンジニアにはCursorのやり取り履歴を一緒に見てFBを重ねていました。
その中でふと気づいたのは、このレビューすらも体系化できるな？ということです。
指示の質を客観的に評価し、改善点を明確にするフレームワークにすれば、今まで以上に全体の生産性を上げられるのでは？と。
実際、私がＦＢをするにあたっての入り口として効率化された手ごたえもあるので、まとめてプロンプトとして公開したいと思います。
使い方としては、Cursorのやり取りがひとしきり終わったら、一番最後に以下のプロンプトを投げてみるのがいいと思いますが、要するに「Cursorの履歴とセットで投げるプロンプト」ということなので、タイミングはよしなにご活用いただけますと幸いです。
Cursorプロンプト評価フレームワーク
あなたは「AIコーディングエージェントとの協働評価」の専門レビュワーです。以下のチャット履歴に基づき、"ユーザー（人間）がCursor系AIエージェントへ出した指示"の質を評価し、改善提案を出してください。評価対象は**ユーザーの指示**であり、エージェント出力の出来に引きずられないようにします。
## 評価原則
- 目的志向（Done定義の明確さ）
- 制約の明示（技術的/ビジネス的）
- 文脈共有（ファイル、入出力例、ログ等）
- Cursor特有の活用（@file, YOLO, TDD, .cursorrules, Index同期）
- 段階的進行
- デバッグ手順（ログ活用）
- リファクタ安全策
- 検証/テスト
- セキュリティ/プライバシー配慮
- Planner/Executor分担
- コンテキスト管理（スコープドリフト防止）
## 出力仕様（Markdownレポートのみ）
以下の見出し・形式でレポートしてください。
# 総評
- 全体の印象と最大の改善ポイント（1〜3行）
## 成熟度レベル
- **L1〜L5**（理由を1〜2文で）
## スコア表
| 指標 | 点数 | 根拠 |
|---|---:|---|
| 目的志向 | x | |
| 制約の具体性 | x | |
| 文脈共有 | x | |
| Cursor機能活用 | x | |
| 段階的進行 | x | |
| デバッグ反復 | x | |
| リファクタ保護 | x | |
| 検証/テスト | x | |
| セキュリティ/プライバシー | x | |
| Planner/Executor分担 | x | |
| スコープ管理 | x | |
## 強み
- 箇条書きで3〜5点
## 改善点（コメントと改善案セット）
以下の形式で複数列挙してください：
- **ユーザーコメント（抜粋）:** 「#17: ログイン機能を作って」
- **問題点:** Done定義や制約が不明確
- **改善案:** 「#17: ユーザー認証を目的にログイン機能を実装。OAuth2を利用し、Next.jsのAPIルートで。Done条件: 成功ログイン時にJWT発行。」
- **ユーザーコメント（抜粋）:** 「#23: バグを直して」
- **問題点:** 対象範囲や再現条件が不明
- **改善案:** 「#23: @file(auth.ts) の関数 loginHandler で、エラー 'invalid token' の再現ログを解析し、原因と修正案を提示してください。」
（この形式を繰り返す）
## 即効の一手
- 具体的な修正プロンプトを3〜5点
## 高インパクト施策（恒常改善）
- .cursorrules導入、TDD活用、Index同期ルール化など3〜5点
## そのまま使える次回プロンプト
目的:
- <TARGET_GOAL>
- Done定義: <DONE_CRITERIA>（検証: <TEST_CMD>）
前提と制約:
- <HARD_CONSTRAINTS>
- 品質/性能: <QA_POLICY>, <PERF_BUDGET>
- 影響範囲: <AFFECTED_FILES>（<PROTECTED_REGION_COMMENT> は変更禁止）
コンテキスト:
- 対象: @file(<PATH>) / @folder(<dir>) / @Symbols(<symbol>)
- 入出力例: <INPUT_EXAMPLE> → <OUTPUT_EXAMPLE>
- 実行環境: <RUNTIME_ENV>
進め方:
1) 設計案提示（代替案あり）
2) 実装（小コミット/理由コメント）
3) テスト作成・修正 → <TEST_CMD> がPassするまで（必要ならYOLO可）
4) 影響範囲レビューと軽微リファクタ（保護領域は触れない）
検証/報告:
- 変更点、理由、残リスク、不明点
- テスト結果、ログ要約、次のTODO
各評価項目の詳細解説
1. 目的志向（Done定義の明確さ）
これは最も重要な評価軸です。「何が完成したら終わりか」が不明確だと、AIもゴールを見失います。
悪い例：
ユーザー認証を実装して
良い例：
ユーザー認証機能を実装
- Done定義：メールアドレスとパスワードでログイン可能
- 成功時：JWTトークンを発行し、/dashboardへリダイレクト
- 失敗時：適切なエラーメッセージを表示
- テスト：`npm run test:auth`がパスすること
2. 制約の明示（技術的/ビジネス的）
制約条件を明示することで、AIの探索空間を適切に狭め、望まない実装を防げます。
実例：
# 技術的制約
- 使用ライブラリ：NextAuth.js v4（v5は使わない）
- データベース：既存のPostgreSQLスキーマを変更しない
- レスポンスタイム：認証処理は500ms以内
# ビジネス的制約
- GDPR準拠：ユーザーデータのログ出力禁止
- 多要素認証：将来的な拡張を考慮した設計
3. 文脈共有（ファイル、入出力例、ログ等）
AIに「今どこにいるか」を正確に伝えることが重要です。Cursorの@機能を活用しましょう。
効果的な文脈共有：
現在のエラー状況：
@file(logs/error.log) の最新50行を確認
@file(src/auth/login.ts) の42行目でTypeError発生
期待される入力：{ email: "test@example.com", password: "secure123" }
実際のエラー：Cannot read property 'id' of undefined
4. Cursor特有の活用
Cursorには強力な機能があります。これらを活用しないのはもったいない。
- @file/@folder: 特定のファイルやフォルダを文脈に含める
- @Symbols: 関数やクラスの定義を参照
- YOLO Mode: 確認なしで連続実行（慎重に使用）
- .cursorrules: プロジェクト固有のルールを定義
- Index同期: コードベース全体の理解を深める
5. 段階的進行
複雑なタスクは必ず段階的に進めます。一度に全部やろうとすると失敗します。
段階的アプローチの例：
Step 1: 認証フローの設計案を3つ提示してください
Step 2: 選択した設計でスケルトンコードを実装
Step 3: 基本的な認証ロジックを実装
Step 4: エラーハンドリングを追加
Step 5: テストケースを作成し、全てパスすることを確認
L1からL5への成長パス
L1: 初心者レベル
- 「バグを直して」「機能を追加」といった漠然とした指示
- 文脈情報がほぼない
- 検証方法が不明
L2: 基礎レベル
- 基本的な要件は伝えられる
- いくつかのファイルを
@で指定 - 簡単なテスト条件を含む
L3: 中級レベル
- Done定義が明確
- 技術的制約を明示
- 段階的な進行を意識
L4: 上級レベル
- 包括的な文脈共有
- Cursor機能を効果的に活用
- セキュリティとパフォーマンスを考慮
L5: エキスパートレベル
- 全ての評価軸で高得点
- プロジェクト全体を俯瞰した指示
- 他のメンバーの手本となるプロンプト
実際の評価レポート例
以下は、実際のプロンプトを評価したレポートです：
総評
文脈共有とCursor機能の活用は良好だが、Done定義が曖昧で段階的進行が不足。セキュリティ配慮も改善の余地あり。
成熟度レベル
- L2（基本的な要素は含まれているが、品質向上の余地が大きい）
スコア表
| 指標 | 点数 | 根拠 |
|---|---|---|
| 目的志向 | 3 | 大まかな目的は示されているが、完了条件が不明確 |
| 制約の具体性 | 4 | 使用技術は明示されているが、パフォーマンス要件なし |
| 文脈共有 | 7 | @fileを効果的に使用、関連ファイルを適切に指定 |
| Cursor機能活用 | 6 | @file活用は良好、.cursorrulesやIndex同期は未使用 |
| 段階的進行 | 2 | 一度に全体実装を要求、段階的アプローチなし |
| デバッグ反復 | 3 | エラー時の対処方法が不明確 |
| リファクタ保護 | 5 | 既存コードへの影響は考慮されているが、保護範囲が曖昧 |
| 検証/テスト | 4 | テストの存在は意識しているが、具体的な検証手順なし |
| セキュリティ/プライバシー | 3 | 認証は含むが、その他のセキュリティ考慮なし |
| Planner/Executor分担 | 2 | 設計と実装の分離なし |
| スコープ管理 | 5 | 対象機能は明確だが、将来拡張への配慮不足 |
強み
- @fileによる的確なファイル参照
- 使用するフレームワーク（Next.js）の明示
- 基本的な機能要件の記述
- 既存コードとの整合性への意識
改善点（コメントと改善案セット）
-
ユーザーコメント（抜粋）: 「ユーザー管理画面を作成してください」
-
問題点: 画面の具体的な要件、完成基準が不明
-
改善案: 「ユーザー管理画面（CRUD機能）を実装。Done定義：一覧表示、新規作成、編集、削除が動作し、@file(tests/admin/users.test.ts)がパスすること」
-
ユーザーコメント（抜粋）: 「Next.jsのApp Routerで実装」
-
問題点: ルーティング構造、ページ構成が不明確
-
改善案: 「/admin/users/配下に、page.tsx（一覧）、[id]/page.tsx（詳細）、new/page.tsx（新規）を作成。@file(app/layout.tsx)のレイアウトを継承」
-
ユーザーコメント（抜粋）: 「適切にエラーハンドリングも」
-
問題点: 「適切」の基準が曖昧
-
改善案: 「エラーハンドリング：400系はユーザー向けメッセージ表示、500系はエラー画面遷移。全エラーは@file(utils/logger.ts)でログ記録」
即効の一手
- Done定義を追加：「管理者がユーザーの有効/無効を切り替えられること」
- テストコマンド明示：
npm run test:admin && npm run e2e:admin - 段階分割：「Step1: UIコンポーネント作成 → Step2: API実装 → Step3: 統合」
- パフォーマンス基準：「ユーザー一覧は1000件まで1秒以内に表示」
高インパクト施策（恒常改善）
- .cursorrulesに管理画面の共通UIパターンを定義
- 管理画面用の共通テストユーティリティを作成
- セキュリティチェックリストをプロジェクトに追加
- コンポーネントライブラリ（shadcn/ui等）の導入検討
そのまま使える次回プロンプト
目的:
- ユーザー管理画面（CRUD機能）の実装
- Done定義: 以下の機能が全て動作すること
- ユーザー一覧表示（ページネーション付き）
- ユーザー詳細表示
- ユーザー作成/編集（バリデーション付き）
- ユーザー削除（確認ダイアログ付き）
- 検証: npm run test:admin:users がパス
前提と制約:
- 技術スタック: Next.js 14 App Router, Prisma, TailwindCSS
- 品質/性能: 一覧表示は1000件まで1秒以内、エラー率1%未満
- 影響範囲: @folder(app/admin/users/)内で完結（@file(app/layout.tsx)は変更禁止）
コンテキスト:
- 対象: @folder(app/admin/users/)を新規作成
- 参考実装: @folder(app/admin/products/)の構造を踏襲
- データモデル: @file(prisma/schema.prisma)のUserモデル使用
- 入出力例:
- GET /api/admin/users → [{id, email, name, role, createdAt}...]
- POST /api/admin/users → {id, email, name, role}
進め方:
1) UIコンポーネントの設計案提示（テーブル vs カード形式）
2) 基本的なCRUD APIの実装（@folder(app/api/admin/users/)）
3) フロントエンド実装（React Server Components優先）
4) エラーハンドリングとローディング状態の実装
5) E2Eテスト作成（Playwright使用）
検証/報告:
- 実装したファイル一覧とその役割
- セキュリティ考慮点（認可、バリデーション、ログ）
- パフォーマンステスト結果
- 今後の拡張ポイント（ロール管理、一括操作等）
まとめと個人的なコツ
段階的導入のすすめ：
わりと仰々しいプロンプトとしてを公開しましたが、なんだかんだ最初から完璧を目指さず、まずは「目的志向」と「文脈共有」から始めるとかがいいと思います。
この2つだけでも、AIの出力品質は劇的に向上します。
評価の習慣化：
定期でみんなでプロンプト（指示内容）を振り返る時間を設けることをお勧めします。特に失敗したケースを分析することで、急速に改善できます。
あと、私のプロンプトは完全に不完全（言いたいだけ）なので、ぜひ「この観点を教育に追加しよう」という感じで強化・精査してってもらいたいです。
最後に、チームの成熟度やプロジェクトの特性に合わせて、評価軸をカスタマイズしてください。大切なのは、「なんとなく」から「意図的に」プロンプトを書く文化を作ることです。
AIとの協働は、もはや特別なスキルではなく、エンジニアの基礎スキルになりつつあります。このフレームワークが、皆さんのAIペアプログラミングをより生産的で楽しいものにする一助となれば幸いです。
いえらぶでは一緒に最速でサービス開発する仲間を募集しています
AIを活用しまくっているのは、つまるところ業界に対して1つでも多く・早くプロダクトを提供するのが目的です。共感してくれる方を広く募集しています。
カジュアル面談しましょう
DMいつでもお待ちしております。採用拘わらず、AIについてでもマネジメントについてでも、何でもお話ししたいです。
新卒採用サイト
大学生向けインターンシップ「いえらぶAIブートキャンプ」募集ページ