AIコードレビューのプロンプト集｜観点別テンプレートと出力形式

AIにコードレビューを頼むときは、「前提情報（差分の範囲・規約・対象外）」「観点」「出力形式」の3つをプロンプトに書くと、指摘の質がそろいます。 「このコードをレビューして」の1行だけでは、AIは何を優先し、どこまで見ればよいかを自分で決めるしかありません。

この記事では、8つの観点ごとに、確認項目の表とそのまま使えるプロンプトを対にして載せました。指摘を「重要度・ファイルと行・理由・修正案」の表で返させる出力形式と、誤検知を減らす前提情報の書き方もテンプレートにしています。後半では、同じ内容をチャット・Claude Code・GitHub Copilot のどこに置くかを整理します。

確認環境：差分を取り出す git コマンドは git 2.43.0（Linux）で実行。設定ファイルの名前・置き場所・項目は、Claude Code と GitHub Copilot の公式ドキュメント（2026年10月5日に閲覧）で確認し、掲載した設定ファイルの先頭部分（YAML）とプロンプトのタグの対応は Python 3.11 で構文を確認しています。この記事はプロンプト集で、モデルの出力例は載せていません。

AIコードレビューの観点と渡す情報の早見表

1回のレビューで頼む観点は2〜3個までにすると、それぞれを深く見てもらいやすくなります。全部を見たいときは、「バグ・セキュリティ・例外処理」と「それ以外」のように、回を分けて頼みます。

土台になるプロンプト（前提情報＋出力形式）

観点が変わっても、前提情報と出力形式は共通です。先に土台を作り、<focus> の中だけを観点別プロンプトに差し替えて使います。

<role>
あなたは {{言語・フレームワークと版}} に詳しいレビュアーです。
</role>

<context>
変更の目的：{{何のための変更か。例：備品予約に割引コードを追加}}
差分の範囲：{{例：main ブランチとの差分。1つのプルリクエスト全体}}
差分に含まれないが関係するコード：{{例：呼び出し元の reservation_service.py を下に添付}}
</context>

<conventions>
{{チームの規約。例：例外は握りつぶさずログに残す／SQL は必ずプレースホルダーを使う}}
</conventions>

<out_of_scope>
- 自動生成ファイル、ロックファイル
- フォーマッターやリンターが検出する書式
- 今回の差分で変更していない行（変更の影響で問題になる場合を除く）
</out_of_scope>

<diff>
{{git diff の出力}}
</diff>

<focus>
{{観点別プロンプトをここに貼る。複数貼ってもよい}}
</focus>

<rules>
- 指摘は、差分の行を根拠として引用できるものだけにする
- 差分と添付から判断できないことは、指摘にせず「確認したいこと」に書く
- 同じ原因の指摘は1つにまとめる
- 指摘が無い観点は「指摘なし」と書く。無理に指摘を作らない
</rules>

<output_format>
1. 指摘の表（重要度の高い順）
| 重要度 | ファイル:行 | 観点 | 指摘 | 理由 | 修正案 |
重要度は次の3段階で付ける。
- 高：不具合・情報漏えい・データの不整合につながる。マージ前に直す
- 中：今は動くが、条件しだいで問題になる。直すか、理由を残す
- 低：読みやすさや好みの改善。対応は任意
2. 確認したいこと（差分からは判断できなかった点。箇条書き）
3. 総評（2文以内）
</output_format>

上の diff を、focus の観点でレビューし、output_format の形で出力してください。

前提情報の3点セット：差分の範囲・規約・対象外

誤検知（実際には問題のない指摘）の多くは、AIが前提を知らないことから生まれます。次の3つを書いておくと減らせます。

土台の <rules> に入れた「判断できないことは、指摘にせず『確認したいこと』に書く」も大切です。分からないことの行き先を用意しておくと、推測にもとづく指摘が表に混ざりにくくなります。

差分を取り出すコマンド

チャットに貼る差分は、git で取り出します。次のコマンドは、main ブランチから分かれた作業ブランチで実行した例です。

# 変更されたファイルの一覧と行数
git diff --stat main...HEAD

 package-lock.json  | 2 +-
 src/cart.py        | 5 +++--
 tests/test_cart.py | 2 ++
 3 files changed, 6 insertions(+), 3 deletions(-)

# ロックファイルを除いた差分
git diff main...HEAD -- . ':(exclude)package-lock.json'

diff --git a/src/cart.py b/src/cart.py
index 6e711fb..800532f 100644
--- a/src/cart.py
+++ b/src/cart.py
@@ -1,2 +1,3 @@
-def total(items):
-    return sum(i["price"] for i in items)
+def total(items, discount=0):
+    subtotal = sum(i["price"] * i["qty"] for i in items)
+    return subtotal - discount
diff --git a/tests/test_cart.py b/tests/test_cart.py
new file mode 100644
index 0000000..bdfc0fd
--- /dev/null
+++ b/tests/test_cart.py
@@ -0,0 +1,2 @@
+def test_total():
+    pass

変更の前後が少ないと、AIは周りの処理を知らないまま判断することになります。関数の途中だけが差分に出ているときは、-U で前後の行を増やすか、関数全体を別に添付すると、見えていないことによる指摘が減ります。

出力形式の指定：重要度3段階と表

指摘は、人が上から順に対応できる形で返してもらいます。土台のプロンプトでは、次の列を指定しています。

出力形式の指定例（表計算ソフトに貼りたいとき）:

指摘は CSV で出力する。1行目は見出しとする。
重要度,ファイル,行,観点,指摘,理由,修正案
値にカンマや改行を含むときは、ダブルクォートで囲む。

出力形式の指定例（プログラムで処理したいとき）:

<output_format>
次の JSON だけを出力する。前後に文章を付けない。
{
  "findings": [
    {
      "severity": "high | medium | low",
      "file": "ファイルのパス",
      "line": 行番号,
      "category": "bug | security | performance | readability | design | test | error-handling | naming",
      "issue": "指摘（1文）",
      "reason": "理由",
      "suggestion": "修正案"
    }
  ],
  "questions": ["差分からは判断できなかった点"],
  "summary": "総評（2文以内）"
}
指摘が無い場合は "findings": [] とする。
</output_format>

重要度の3段階は、チームで使っているラベルに合わせて言い換えてかまいません。大切なのは、段階の名前だけでなく「どういうものがその段階か」を書くことです。

観点別の確認項目とプロンプト

以下の各プロンプトを、土台の <focus> に貼って使います。{{ }} は自分の内容に書き換えてください。

1. バグ（正しさ）：変更の目的どおりに動くか

観点：バグ（正しさ）
- context の「変更の目的」を満たしているかを最初に確かめる
- 条件分岐の抜け、境界値（0件・1件・上限・空・null）での動きを確かめる
- 引数や戻り値を変えた関数は、添付した呼び出し元と合っているかを確かめる
- 問題がある場合は、問題が起きる具体的な入力値を1つ示す

2. セキュリティ：外から来た値の扱い、権限、秘密情報

観点：セキュリティ
- 利用者やほかのシステムから来る値が、SQL・コマンド・HTML・ファイルパスに渡る経路を差分からたどる
- 追加・変更したエンドポイントや処理に、認証と、本人のデータかどうかの確認があるかを確かめる
- パスワード・トークン・APIキー・個人を特定できる情報が、コード・ログ・エラー応答に出ていないかを確かめる
- 指摘には、値がどこから入り、どこで問題になるかの経路を書く

3. 性能：データが増えたときの動き

観点：性能
- 想定するデータ量は {{例：予約テーブル100万件、1回の一覧表示は50件}} とする
- ループの中のDB問い合わせ・API呼び出し・ファイル操作を挙げる
- 件数に比例して遅くなる処理を挙げ、どの件数から問題になりそうかの見立てを書く
- 速さの数値は推測で書かず、測り方（確かめるクエリやコマンド）を提案する

4. 可読性：あとから読む人に伝わるか

観点：可読性
- 初めて読む人がつまずきそうな箇所を、理由つきで挙げる
- 重要度は原則「低」とし、誤解から不具合につながりそうなものだけ「中」にする
- 書式（インデント、空白、改行）はフォーマッターに任せるので指摘しない
- 修正案は、直した後のコードを数行で示す

5. 設計：責務の分け方と変更のしやすさ

観点：設計
- このリポジトリの層の分け方は {{例：controller → service → repository}} とする
- 差分が、この分け方と依存の向きに合っているかを確かめる
- 既存の共通処理（添付した {{ファイル名}}）で置き換えられる箇所を挙げる
- 作り直しの提案は、今回の変更の範囲で直せるものと、別の変更に分けるものを分けて書く

6. テスト：変更がテストで守られているか

観点：テスト
- 差分で変更・追加された分岐を列挙し、それぞれを通るテストが差分の中にあるかを表にする
- 足りないテストケースを、入力と期待する結果の形で挙げる
- 結果を確かめていない（検証の文が無い）テストを挙げる
- テストコードの書き方は conventions に合わせる

7. 例外処理：うまくいかなかったときの動き

観点：例外処理
- 外部への呼び出し（DB、API、ファイル）ごとに、うまくいかなかった場合の動きを差分からたどる
- 例外を捕まえて何もしていない箇所、広い種類でまとめて捕まえている箇所を挙げる
- 例外のときに、接続・ファイル・ロック・トランザクションが残らないかを確かめる
- 修正案には、ログに残す項目と、呼び出し元へ返す内容を書く

8. 命名：名前から中身が分かるか

観点：命名
- 差分で追加・変更された変数・関数・クラス・テーブル・列の名前を対象にする
- 名前と実際の動きが食い違っているものを最優先で挙げる（重要度「中」）
- 既存の名前（{{例：Reservation、cancelReservation}}）と語の選び方がそろっているかを確かめる
- 修正案は、候補を2つまでと、選ぶ基準を書く

観点の組み合わせ方

チャット・Claude Code・GitHub Copilot での置き場所の違い

同じ「前提情報・観点・出力形式」でも、ツールによって書く場所が変わります。

チャットで使う場合

土台のプロンプトに差分を貼って送ります。リポジトリを読めないため、差分の外にある関係コード（呼び出し元、型の定義、テーブル定義）を自分で添付することが、指摘の正確さを左右します。秘密情報（パスワード、APIキー、個人を特定できる情報）は、貼る前にダミーの値へ置き換えます。

Claude Code で使う場合

Claude Code には、差分をレビューするスキル /code-review（/review は別名）と、ブランチの変更をセキュリティの観点で調べる /security-review が同梱されています。チームの観点と出力形式でそろえたいときは、自分たちのスキルを追加します。

スキルは .claude/skills/スキル名/SKILL.md に置きます。次の例を .claude/skills/team-review/SKILL.md として保存すると、/team-review で呼び出せます。

---
name: team-review
description: チームの観点と出力形式で、現在のブランチの差分をレビューする
disable-model-invocation: true
argument-hint: "[追加の指示]"
allowed-tools: Bash(git diff *) Bash(git log *) Read Grep Glob
---

## 差分
!`git diff main...HEAD -- . ':(exclude)package-lock.json'`

## 変更されたファイル
!`git diff --name-only main...HEAD`

## 依頼
上の差分をレビューしてください。追加の指示：$ARGUMENTS

- 観点：バグ、セキュリティ、例外処理、テストの順に確かめる
- 対象外：自動生成ファイル、書式、差分で変更していない行
- 差分だけで判断できないときは、関係するファイルを読んでから判断する
- 出力：| 重要度 | ファイル:行 | 観点 | 指摘 | 理由 | 修正案 | の表。
  重要度は 高・中・低 の3段階。指摘が無い観点は「指摘なし」と書く

観点を1つに絞った専門のレビュアーは、サブエージェントとして .claude/agents/ に置けます。先頭に name と description、必要なら使えるツールを書き、その下の本文がサブエージェントへの指示（システムプロンプト）になります。

---
name: security-reviewer
description: 差分をセキュリティの観点だけでレビューする。認証・入力の扱い・秘密情報を変更したときに使う
tools: Read, Glob, Grep
---

あなたはセキュリティの観点だけを見るレビュアーです。
外から来る値が SQL・コマンド・HTML・ファイルパスに渡る経路、認証と認可の確認、
秘密情報の扱いを確かめ、指摘を「重要度・ファイル:行・理由・修正案」の表で返してください。
差分から判断できないことは、指摘にせず「確認したいこと」として挙げてください。

毎回のレビューに共通する規約（命名、エラー処理、使うライブラリ）は、スキルではなく CLAUDE.md に書いておくと、レビュー以外の作業でも同じ規約が使われます。

GitHub Copilot コードレビューで使う場合

Copilot のコードレビューは、リポジトリのカスタム指示を読みます。リポジトリ全体に効かせる内容は .github/copilot-instructions.md に書きます。

# コードレビューの方針

## 観点の優先順位
1. バグ（変更の目的どおりに動くか、境界値）
2. セキュリティ（外から来た値の扱い、認証・認可、秘密情報）
3. 例外処理とテスト
4. 設計、性能、可読性、命名

## 規約
- SQL は必ずプレースホルダーを使う
- 例外を捕まえたら、ログに残すか、呼び出し元へ伝える
- 公開する関数には型ヒントを付ける

## 指摘の書き方
- 重要度（高・中・低）、理由、修正案を必ず書く
- 書式の指摘はしない（フォーマッターが担当する）
- 自動生成ファイルとロックファイルは対象外

特定のパスだけに効かせたい内容は、.github/instructions/ に 名前.instructions.md というファイルを作り、先頭の applyTo に対象のパスを glob 形式で書きます。

---
applyTo: "src/api/**/*.py"
---

# API 層のレビュー観点
- エンドポイントごとに、認証と、本人のデータかどうかの確認があること
- 入力値の検証をしてから service を呼ぶこと
- エラー応答に、内部の情報（スタックトレース、SQL）を含めないこと

excludeAgent を書くと、その指示を使わない相手を指定できます。指定できる値は "code-review" と "cloud-agent" です。次の例は、コードレビューでだけ使い、クラウドエージェントには使わせない指示です。

---
applyTo: "**/*.sql"
excludeAgent: "cloud-agent"
---

# SQL のレビュー観点（Copilot コードレビュー向け）
- 追加した検索条件と並び順に合うインデックスがあること
- 全件を更新・削除する文には、件数を確かめる手順がコメントにあること

押さえておきたい点は次の2つです。

• Copilot は、プルリクエストの変更側のブランチ（head ブランチ）にある指示ファイルを読みます。 指示ファイルを変えるプルリクエストでは、その変更後の内容でレビューされます。
• Copilot のレビューは、既定では必須の承認の数に数えられません。人のレビューと組み合わせて使う前提の仕組みです。

誤検知を減らすためのチェックリスト

AIの指摘は、受け入れる前に人が確かめます。理由の列を読んで、問題が起きる入力や条件が具体的に書かれているかを見ると、取り入れるかどうかを判断しやすくなります。

よくある質問

Q. 観点は1つずつ頼むのと、まとめて頼むのとどちらがよいですか？ A. 差分が小さければ、関係の近い観点を2〜3個まとめて頼むと効率的です。差分が大きいときや、セキュリティのように見落としを減らしたい観点は、単独で頼むと深く見てもらいやすくなります。

Q. 指摘が多すぎて読み切れません。 A. 対象外（書式、自動生成、変更していない行）を書き、重要度の基準を明記したうえで、「重要度が高と中のものだけ」「最大10件」のように出力形式で絞ります。可読性と命名は、別の回に分けるのも有効です。

Q. ChatGPT と Claude で、プロンプトを書き分ける必要はありますか？ A. この記事の土台は、どちらにもそのまま貼って使える書き方です。タグで区切る形が合わないと感じたら、タグを Markdown の見出しに置き換えてください。内容（前提情報・観点・出力形式）が同じであれば、区切りの形式はどちらでも伝わります。

Q. AIのレビューがあれば、人のレビューは省けますか？ A. AIは差分と渡された情報から読み取れる範囲を見ます。仕様として正しいか、チームの方針に合うかは、人が判断する部分です。AIには観点ごとの確認を任せ、人は目的と設計の判断に時間を使う、という分担がおすすめです。

まとめ

• プロンプトには「前提情報・観点・出力形式」の3つを書く。土台を1つ作り、観点だけを差し替える
• 前提情報は「差分の範囲・規約・対象外」の3点セット。見えていないことによる指摘と、書式の指摘を減らせる
• 出力は「重要度・ファイル:行・観点・指摘・理由・修正案」の表。重要度は3段階の基準まで書く
• 観点はバグ・セキュリティ・性能・可読性・設計・テスト・例外処理・命名の8つ。1回に頼むのは2〜3個まで
• 判断できないことは「確認したいこと」へ、指摘が無ければ「指摘なし」と書かせると、推測の指摘が混ざりにくい
• 置き場所はツールで違う。Claude Code は CLAUDE.md・スキル・サブエージェント、Copilot は .github/copilot-instructions.md と .github/instructions/ のファイル
• AIの指摘は人が確かめてから取り入れる。理由の列に具体的な条件が書かれているかを見る

参考・出典

• Claude Code Docs「Extend Claude with skills」 https://code.claude.com/docs/en/skills
• Claude Code Docs「Create custom subagents」 https://code.claude.com/docs/en/sub-agents
• Claude Code Docs「How Claude remembers your project」 https://code.claude.com/docs/en/memory
• Claude Code Docs「Commands」 https://code.claude.com/docs/en/commands
• GitHub Docs「Adding repository custom instructions for GitHub Copilot」 https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
• GitHub Docs「About GitHub Copilot code review」 https://docs.github.com/en/copilot/concepts/agents/code-review

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。