コードレビュー観点を抜け漏れなく整理するプロンプトテンプレート 指摘の粒度をそろえる書き方
このプロンプトは、AIにコードレビューを頼むときに「何を見て、どう返すか」を先に固定し、指摘の抜け漏れを減らすためのものです。対象は、ChatGPT、Claude、Geminiなどの汎用LLMを使って、PRレビューや差分確認を早く回したいエンジニアです。
結論から言うと、コードレビュー用プロンプトで効くのは「レビュー観点の列挙」だけではありません。対象コード、変更目的、見てほしい観点、出力形式、指摘の優先度をセットで渡したほうが、実務で使える返答に近づきます。
- 何に使うか: PRレビュー、差分確認、セルフレビュー、レビュー観点の洗い出し
- 向いている人: 実装者、レビュアー、テックリード、レビュー観点を標準化したいチーム
- 狙う出力形式: 箇条書き、JSON、優先度付きレビューコメント
- 特に効く場面: バグ混入が怖い変更、複数ファイルの横断修正、観点が人によってぶれやすい案件
ここがポイント: AIに「レビューして」とだけ投げると、表面的な指摘に寄りやすくなります。差分の目的と、優先して見る観点を最初に固定したほうが、指摘の質が安定します。
どんな場面で使いやすいか
コードレビュー支援でAIが役立つのは、単にミス探しをするときだけではありません。むしろ、レビュー担当者の頭の中にある観点を外に出し、毎回の確認手順をそろえる場面で効きます。
たとえば次のようなケースです。
- APIの条件分岐を変更し、例外処理や戻り値の互換性が気になる
- フロントエンドの改修で、表示崩れより副作用や状態管理を優先して見たい
- バッチ処理の修正で、性能、再実行性、ログ、失敗時の挙動をまとめて確認したい
- 新人のセルフレビューで、命名や可読性だけでなく、仕様漏れや境界条件まで見たい
レビュー観点を明示したプロンプトにすると、AIは「気づいたことを雑に並べる役」ではなく、指定したチェックリストに沿って差分を点検する役になりやすいです。ここが実務上の大きな違いです。
コピペ用プロンプトテンプレート
まずは汎用LLMで使いやすい形から載せます。コード差分を貼る前提のテンプレートです。
あなたは{言語/フレームワーク}に詳しいシニアエンジニアです。
以下の変更内容を、コードレビュー担当として確認してください。
# レビューの目的
- 目的: {この変更で達成したいこと}
- 背景: {関連する仕様、障害、要件}
- 変更範囲: {対象ファイル、モジュール、レイヤー}
- 想定読者: {実装者向け / レビュアー向け / PMにも共有 など}
# 優先して見る観点
1. 仕様の取り違えや要件漏れ
2. バグになりうる条件分岐、例外処理、null/空配列/境界値の扱い
3. 既存API・DB・外部依存との互換性
4. 性能・N+1・不要な再計算・不要な通信
5. セキュリティ、権限、入力値検証、ログ漏えい
6. 可読性、命名、責務分割、重複
7. テスト不足、確認観点の漏れ
# レビュー方針
- 良い点も必要なら短く触れる
- 重要度を `critical` / `major` / `minor` / `nit` で付ける
- 推測だけで断定しない
- 情報不足なら「追加で必要な情報」として分けて書く
- 問題がない項目は「大きな懸念なし」と明記してよい
# 出力形式
次のJSONで返してください。
{
"summary": "変更全体の短い要約",
"findings": [
{
"severity": "critical | major | minor | nit",
"category": "仕様 | バグ | 性能 | セキュリティ | 可読性 | テスト | その他",
"file": "対象ファイル名またはunknown",
"reason": "なぜ問題か",
"suggestion": "どう直すとよいか"
}
],
"missing_information": [
"追加で確認したいこと"
],
"test_checkpoints": [
"レビュー後に確認したいテスト観点"
]
}
# 変更差分
```diff
{ここに差分を貼る}
このテンプレートの肝は、レビュー観点を7つに固定したことよりも、**出力形式まで先に決めていること**です。JSONで返させると、レビューコメントの整理、チケット化、再チェックがしやすくなります。
## 入力時に変える部分と、固定しやすい部分
テンプレートを毎回ゼロから書く必要はありません。変える箇所だけを切り分けると運用しやすくなります。
### 毎回変える部分
- `{言語/フレームワーク}`: `TypeScript + React`、`Python + FastAPI` など
- `{この変更で達成したいこと}`: 変更目的。ここが曖昧だとレビューもぶれます
- `{関連する仕様、障害、要件}`: チケット要約、バグ再現条件、受け入れ条件
- `{対象ファイル、モジュール、レイヤー}`: API層だけか、DBマイグレーション込みかを明示
- `{ここに差分を貼る}`: diff、PR説明、関連コードの抜粋
### 固定しやすい部分
- レビュー観点の基本セット
- 重要度のラベル
- 出力形式
- 「情報不足なら分けて書く」というルール
チームで使うなら、固定部分を共通テンプレートにして、案件ごとの可変部分だけ埋める形が扱いやすいです。
## NG例と改善例
AIレビューが浅くなる原因は、モデル性能より**指示の欠け方**にあることが多いです。
### NG例
```text
このコードをレビューして。問題があれば教えて。
この書き方だと、次の問題が起きやすくなります。
- 何のための変更か分からない
- バグ、性能、セキュリティのどれを優先するか不明
- 出力の粒度が毎回変わる
- 「問題なし」で終わる基準も曖昧
改善例
この差分をコードレビューしてください。
目的は「CSVエクスポート時に空データでも500エラーを出さず、空ファイルではなくヘッダーだけ返す」ことです。
優先して見てほしい点:
- 例外処理
- 既存APIの戻り値互換性
- 空配列、null、0件データ時の挙動
- テスト不足
出力は以下の形式にしてください。
- 重要度: critical / major / minor / nit
- 各指摘に「なぜ問題か」と「修正案」を付ける
- 情報不足なら別枠で列挙する
差分:
{差分}
改善例では、AIに高度な推理を求めているわけではありません。レビューの前提条件を先に渡しているだけです。これだけで、指摘の方向がかなりそろいます。
出力を安定させるコツ
2026年4月時点で公開されている公式ドキュメントでも、OpenAI、Anthropic、Googleはいずれも、明確で具体的な指示、区切りの明示、出力形式の指定を重視しています。実務のコードレビューでも、この考え方はそのまま使えます。詳しくは OpenAIのPromptingガイド、AnthropicのPrompt Engineering Overview、GoogleのPrompt design strategies が参考になります。
1. 差分だけでなく「変更目的」を入れる
同じコードでも、目的がバグ修正なのか、性能改善なのか、リファクタリングなのかで見るべき点は変わります。目的がないと、AIは一般論に寄りやすくなります。
2. 観点を詰め込みすぎない
毎回20項目を指定すると、出力が薄くなることがあります。まずは次の4つを主軸にすると扱いやすいです。
- 仕様・境界条件
- 互換性・副作用
- 性能
- テスト不足
必要な案件だけ、セキュリティや可読性を強める形で足します。
3. 出力形式を固定する
箇条書きでも動きますが、再利用しやすさを考えるならJSONが便利です。後でPRコメント化したり、Issueに移したりしやすくなります。
4. 情報不足を認めさせる
AIは、手がかりが足りない場面でも何か言おうとしがちです。そこで「不明なら missing_information に分ける」と先に指定すると、無理な断定を減らせます。
5. モデルごとの違いは“調整量”として考える
モデル名を固定せず、汎用LLM向けに書いておくと使い回しやすいです。そのうえで傾向としては次の調整が効きます。
- ChatGPT系: 出力形式と項目定義を細かく書くと安定しやすい
- Claude系: 背景や評価基準を少し厚めに渡すとレビューの文脈が通りやすい
- Gemini系: セクション分けや区切りを明確にすると整理された返答になりやすい
ここは性能比較ではなく、プロンプトの書き方の相性として考えるのが実務向きです。
用途別の短い応用テンプレート
同じ骨組みで、用途を少し変えるだけでも使い道が広がります。
PRレビュー用
次のPR差分をレビューしてください。
目的: {PRの目的}
優先観点: 仕様漏れ、境界条件、既存挙動との互換性、テスト不足
出力: 箇条書き。各項目に severity と fix案を付ける
差分: {diff}
セルフレビュー用
私はこのコードの実装者です。セルフレビュー観点を洗い出してください。
目的: {変更目的}
特に不安な点: {不安点}
出力: 「自分で確認すべき項目」のチェックリスト形式
コード/差分: {code_or_diff}
テックリードの観点整理用
この変更をレビューする際の観点を、チームレビュー用チェックリストとして整理してください。
対象: {システム/レイヤー}
変更内容: {変更要約}
出力: 1. 事前確認 2. 差分確認 3. マージ前確認 の3部構成
使う前に見直したいチェックリスト
最後に、投げる前の確認項目です。ここを外すと、テンプレートが良くても出力は安定しません。
- 変更目的を1文で書けているか
- 差分だけで分からない仕様を補足したか
- どの観点を優先するか絞れているか
- 出力形式を指定したか
- 情報不足時の扱いを決めたか
- AIの指摘をそのまま採用せず、最終判断を人が行う前提になっているか
コードレビュー支援のプロンプトは、長く書けば良いわけではありません。見るべき論点を先に定義し、返し方を固定することが効きます。次に改善するなら、あなたのチームで頻出する事故パターンを1つ足してください。たとえば「権限漏れ」「N+1」「例外時のログ不足」などです。そこから、レビューの再現性が一段上がります。