コードレビュープロンプト集：LLM を「よいシニアレビュアー」にするテンプレート

AI に「コードをレビューして」とだけ依頼すると、一般的なコメントしか返ってきません。「見てほしい視点」をその都度含めると、LLM が「優れたシニアレビュアー」に変わります。

型 1：PR レビュー

以下の PR をコードレビューしてください。

[リポジトリの背景]
[言語・フレームワーク・規模]

[PR の意図]
[何をしたいのか]

[変更ディフ]

レビュー視点（各項目、見つからなければ「問題なし」と記載）：
1. セキュリティ脆弱性（SQL インジェクション・XSS・認証認可）
2. パフォーマンス問題（N+1 クエリ・不要なループ・同期と非同期が逆になっていないか）
3. コードの抽象レベル（不要なクラス分解、DRY 違反）
4. テスト・エッジケース・エラーハンドリング
5. 命名・ドキュメント・可読性

出力形式：
- 見つかった点を「ファイル：行：指摘：修正案」の並びで記述
- 例示コードを必ず 1 〜 2 つ付ける
- 「見落としやすい点」を 1 つ以上含める

型 2：設計チェック

以下の設計ドキュメントをレビューしてください。

[システムの背景と要件]
[設計ドキュメント]

チェック視点：
1. 要件に対してオーバースペックになっていないか（YAGNI）
2. スケールと可用性の設計は規模に合うか
3. 障害ポイントと、その復旧手順は明らかか
4. データ一貫性とトランザクションの境界設計
5. 外部 API の障害時の振る舞い
6. テスト可能性（モック可能か、E2E だけで検証可能か）
7. 今やらないと「とても高い代償」を支払うことになる設計上の起点

複数の代替案を提示し、それぞれのトレードオフを 1 行でも説明してください。

型 3：セキュリティレビュー

以下のコードを OWASP Top 10 の視点でセキュリティレビューしてください。

[コード]

含める項目：
- 検出レベル（高 / 中 / 低）
- その脆弱性がもたらす具体的な被害
- 修正例（コード）
- 関連する CWE 番号
- 人間が誤検出しそうなケースの警告

型 4：テスト設計

以下の関数・クラスに対して、テストケースを設計してください。

[関数・クラスのコード]

ケースの考え方：
1. 正常系（3 ケース以上、入力の幅をカバー）
2. 境界値（最小 / 最大 / ちょうどゼロ / その上下）
3. 異常系（null / undefined / 型違い / タイムアウト / 例外）
4. 悪意ある入力（XSS・SQL・長さ超過）
5. 同期タイミング・並列・リトライが絡むケース

出力してほしいもの：
- テストケース一覧（名前・入力・期待出力）
- jest や vitest でそのまま走らせる TS コード
- コードカバレッジで何 % をカバーできる見込み

チームで使う際のポイント

• コードベースの規約や言語の「背景」を事前に読ませた上でレビューさせる。Cursor や Claude Code でも同じテンプレが使える
• 顧客コードと社内コードを分け、顧客コードは必ず学習除外設定や企業プランを使う
• AI の指摘は「すべて鵜呑みにする」ものとは捉えず、「人間レビュアーを支援する補助」として扱う

同一の PR を 5 ツールでレビューさせた実測ベンチは コードレビュー AI ベンチ：同一 PR を 5 ツールに渡した結果、エンジニア全体の AI 使い分けは エンジニアの AI 使い分け完全マップ を参照してください。

※ テンプレは出発点として使い、チームのコードベースに合わせて調整してください。