ストーリー

コードレビュープロンプトの構成

チェック観点の設計

観点の優先順位と詳細

1. セキュリティ [CRITICAL/HIGH]
   □ SQLインジェクション
   □ XSS（クロスサイトスクリプティング）
   □ CSRF対策
   □ 認証・認可の不備
   □ 機密情報のハードコード（API キー、パスワード）
   □ 不適切なCORS設定

2. バグ・ロジックエラー [HIGH]
   □ null/undefined参照
   □ 境界値エラー（off-by-one等）
   □ 非同期処理の競合（race condition）
   □ エラーハンドリングの不備
   □ 型の不一致

3. パフォーマンス [MEDIUM]
   □ N+1クエリ問題
   □ 不要な再レンダリング（React）
   □ メモリリーク
   □ 不効率なアルゴリズム（O(n^2)等）
   □ 不要なデータ取得

4. 保守性・可読性 [LOW]
   □ 命名規則違反
   □ 関数が長すぎる（50行超）
   □ マジックナンバー
   □ DRY原則違反
   □ コメント不足/過剰

プロンプトテンプレート

完全版テンプレート

あなたはNetShop社のシニアソフトウェアエンジニアです。
提出されたコードを以下の観点でレビューしてください。

## メタ情報
- 言語: {{language}}
- フレームワーク: {{framework}}
- ファイルパス: {{filepath}}
- PR説明: {{pr_description}}

## チェック観点（優先順位順）
1. CRITICAL: セキュリティリスク（OWASP Top 10）
2. HIGH: バグ・ロジックエラー
3. MEDIUM: パフォーマンス問題
4. LOW: 保守性・可読性

## 出力形式

### 判定
APPROVE / REQUEST_CHANGES / COMMENT

### サマリー
（全体の評価を2-3文で）

### 指摘一覧
| # | 行 | 重要度 | 観点 | 指摘内容 | 修正案 |
|---|-----|--------|------|---------|--------|

### 良い点
- （最低1つ）

### 修正後コード
（CRITICAL/HIGHの指摘がある場合のみ）

## ルール
- CRITICALが1つでもあれば REQUEST_CHANGES
- HIGHのみなら REQUEST_CHANGES
- MEDIUM以下のみなら COMMENT
- 指摘がなければ APPROVE + 「LGTM」
- 指摘は最大15件（超える場合は重要度上位を選出）

言語別の特化チェック

TypeScript特化

TypeScript追加チェック:
- any型の使用 → unknown + 型ガードを推奨
- 非null表明演算子(!)の多用 → Optional chaining(?.)を推奨
- enum vs union type → 適切な使い分け
- 戻り値の型が未指定 → 明示的な型注釈を推奨
- as による型アサーション → 型ガード関数を推奨

React特化

React追加チェック:
- useEffectの依存配列漏れ
- useMemo/useCallbackの過不足
- propsの型定義（interface vs type）
- コンポーネントの責務分離
- key属性のindexキー使用

SQL/Prisma特化

DB追加チェック:
- 生SQLの使用（Prismaを推奨）
- トランザクション未使用（複数更新時）
- SELECT * の使用（必要なカラムのみ指定）
- インデックスが効かないWHERE条件
- N+1クエリ（includeの使用を推奨）

実践例

入力コード

// filepath: src/api/users.ts
app.get('/users/:id', async (req, res) => {
  const user = await db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)
  const orders = await db.query(`SELECT * FROM orders WHERE user_id = ${req.params.id}`)
  res.json({ user: user[0], orders })
})

期待されるレビュー出力

### 判定
REQUEST_CHANGES

### サマリー
SQLインジェクションの脆弱性があり、即座の修正が必要です。
パフォーマンスとエラーハンドリングの改善も推奨します。

### 指摘一覧
| # | 行 | 重要度 | 観点 | 指摘内容 | 修正案 |
|---|-----|--------|------|---------|--------|
| 1 | 3 | CRITICAL | セキュリティ | 文字列補間によるSQLインジェクション | パラメータ化クエリまたはPrismaを使用 |
| 2 | 4 | CRITICAL | セキュリティ | 同上（orders テーブルも同様） | 同上 |
| 3 | 3 | MEDIUM | パフォーマンス | SELECT * は不要なカラムも取得 | 必要なカラムのみ指定 |
| 4 | 3-4 | MEDIUM | パフォーマンス | 2回の独立クエリを直列実行 | Promise.allで並列実行 |
| 5 | 2 | HIGH | バグ | エラーハンドリングなし | try-catchで500エラー返却 |
| 6 | 3 | LOW | 保守性 | user[0]のnullチェックなし | 404レスポンスを追加 |

### 良い点
- エンドポイントのURL設計がRESTfulです

### 修正後コード
（Prismaを使用した修正版コードを提示）

レビュー品質を高めるコツ

まとめ

チェックリスト

• コードレビュープロンプトの全体構成を理解した
• 4つのチェック観点と優先順位を把握した
• 言語別の特化チェックを設計できる
• 実践例の指摘が適切かを判断できる

次のステップへ

次は「文書生成プロンプト」として、技術文書や議事録の自動生成テンプレートを構築しよう。

推定読了時間: 30分