はじめに
多くのエンジニアがコードを書く時、デバックする時、そしてチームの他のメンバーが作成したプルリクエストをレビューする時にAIエージェントを使用していると思います。
様々なプロンプトを試してみた結果、最近割と良く使うプロンプトが安定してきたため、共有させていただければと思います。
AIエージェントによるコードのレビューはあくまで補助であり、最終的には人間が責任を持って判断する必要があります。
このプロンプトを使用する流れ
- ローカルでAIエージェント（私はcursorを使用しています）を立ち上げ、プルリクが作成されたリモートブランチにチェックアウトします
- AIチャットをエージェントモードで開き、以下のプロンプトをコピペして実行します。
（以下のプロンプトは、対象のブランチ→mainブランチへ向けてマージする想定です）
あなたはシニアエンジニアとして、**このブランチを main にマージして良いか**を判断するための **徹底コードレビュー**を行ってください。
対象は「このブランチの差分（git diff / PR diff）」です。推測ではなく、差分と周辺コードを根拠に結論を出してください。
## 目的
1. **マージ前に潰すべき不具合・脆弱性・事故要因を漏れなく洗い出す**
2. そのうち **優先度が高いものだけ**を **必要最低限の差分**で修正する（リファクタ禁止）
## 進め方（必須）
* まず差分全体を読み、影響範囲（API/DB/認証/権限/フロント/インフラ/CI など）を短く整理する
* 次に問題点を列挙し、**優先度順（P0/P1/P2）**に並べる
* 各問題点に以下を必ず付ける
* **根拠**（該当ファイル・行・関数・条件など）
* **再現/失敗シナリオ**（どう壊れるか）
* **影響**（ユーザー影響・データ破壊・セキュリティ・運用事故など）
* **推奨対応**（最小変更で）
* 最後に、**P0/P1のみ**を対象に、実際の修正を行う
* 修正は「挙動を変えない」ことを最優先（必要な場合のみ挙動変更）
* 変更は最小限。命名変更・構造整理・ついでの改善は禁止
* 可能ならテスト（既存テストの追加/修正）も最小で追加
## 優先度の定義
* **P0**: 本番障害、データ不整合/破壊、重大なセキュリティ問題、認証/権限の破綻、ビルド/デプロイ不能
* **P1**: 主要機能の不具合、例外/エッジケースでのクラッシュ、性能劣化が顕著、運用上の事故要因
* **P2**: 低頻度の不具合、可読性/保守性、軽微な改善（今回は修正しない）
## 出力フォーマット
### A. 影響範囲サマリ（箇条書き）
* ...
### B. リスク一覧（優先度順）
1. [P0] タイトル
* 根拠:
* シナリオ:
* 影響:
* 推奨対応:
2. ...
### C. 変更方針（P0/P1のみ）
* ...
### D. 修正パッチ
* 変更したファイル一覧
* 具体的な差分（編集結果）
* 追加/修正したテストと実行方法
### E. マージ判定
* ✅マージ可 / ❌マージ不可（理由）
* 追加で必要な確認事項（あれば）
おわりに
同様のプロンプトを複数回実行すると、一度目の実行では発見できなかったバグに気づけることもあるので、数回試していただくと安心です。
AIのプロンプトに関してまとめた記事がありますので、ぜひこちらも合わせて参考にしていただけると幸いです。