はじめに

AIレビューの導入が進む中、「どこまでプロンプト次第で精度が変わるのか？」という疑問を感じた人は少なくないはず。
GitHub CopilotやCodeRabbit、CodiumAIといったツールを試してみても、出力内容にバラつきがあり、満足できる場合と物足りない場合がある。

この記事では、レビューアーとしてLLMベースのレビューを活用する際に、プロンプトの設計によって実際にどれだけコメントの内容や質が変わるかを、具体的なパターンと実例で比較しながら見ていく。

基本構造：プロンプトの要素を分解してみる

まず、AIレビューにおけるプロンプトは以下のような要素に分解できる。

  • 役割指定（systemプロンプト）
  • 前提情報（文脈説明やルール）
  • 入力対象（diffやコード全体）
  • 指示タスク（何をしてほしいか）

この4つが揃っていないと、AI側の出力は的を外すことがある。
とくに前提情報と指示タスクの不明確さが、レビューの精度低下につながりやすい。

パターン別：プロンプト改善の実例比較

ここからは、具体的なコードに対してプロンプトの書き方を変えたときの違いを見ていく。

ケース1：ループ構文の改善指摘（改善なしパターン）

変更対象コード 
for (let i = 0; i < data.length; i++) {
  total += data[i];
}
プロンプトA（シンプル） 
以下のコードをレビューしてください。
出力例 
@Reviewer: 処理内容は明確ですが、特に問題点は見受けられません。

このような出力は、一見問題がなさそうに見えてしまう。
しかし、プロンプトを以下のように変えると -

ケース1：改善ありプロンプト

プロンプトB（文脈強化） 
あなたはコードレビューの専門家です。
以下は既存コードの一部で、配列の集計処理を行っています。
効率性・可読性・バグの温床になりうる点を含め、改善点を指摘してください。
出力例 
@Reviewer: forループで配列を走査していますが、`reduce()`などの高階関数を使うことで可読性と意図の明示性が向上します。処理の副作用も明確になりやすいため、関数型構文への置き換えを検討する価値があります。

レビュー精度の差は明らかだ。
「ただレビューして」と言うのか、「こういう観点で見て」と伝えるのかで、AIの焦点がまったく変わってくる。

高階関数とは

高階関数とは、関数を引数に取ったり、関数を返す関数のこと。JavaScriptでは map, filter, reduce などが代表的。

ケース2：変更理由と整合性チェック

PRコードの一部 
function calculateTax(price) {
  return price * 1.08;
}
プロンプトC（変更理由なし） 
このコードをレビューしてください。
出力例 
@Reviewer: 税率がハードコーディングされています。将来的な変更に備え、定数化または外部設定とするのが望ましいです。
プロンプトD（背景付き） 
この変更は「消費税率を現行の8%に固定し、将来的に変更する計画はない」という社内方針に基づいています。
この意図を踏まえて、レビュー観点を挙げてください。
出力例 
@Reviewer: 方針により固定であるとのことですが、8%という値が直接埋め込まれていると、仕様変更時に全箇所の見直しが必要になります。記述意図を明示するためにも定数化し、コメントに背景を記すとより安全性が高まります。

背景を与えたことで、「それでもなお定数化を促す理由」が含まれた指摘に変わった。
AIに思考の余白を与えることで、より実務的な指摘が期待できる。

指摘の質を上げるためのテンプレート例

ここで、実務で使えるプロンプトテンプレートをいくつか共有する。

基本プロンプト（汎用）

あなたは熟練のコードレビューエンジニアです。
以下のコード変更に対して、構造・責務・保守性・拡張性の観点からレビューコメントを出力してください。
コメントは読み手が改善の意図を理解できるよう、説明を含めてください。

PR用プロンプト（背景あり）

このPRは、ログ出力のフォーマットを改善する目的で作成されています。
その背景を踏まえた上で、ロジック・命名・責務の妥当性について指摘してください。

機能追加用プロンプト（新規コード対象）

以下は新規に追加されたAPIのエントリポイントです。
セキュリティ、入力バリデーション、エラーハンドリング、ログ出力に関する観点で問題がないかレビューをお願いします。

プロンプト改善の設計視点

レビューアーとしてプロンプトの設計を行う場合、次のような観点での整理が効果的。

観点 内容
対象の粒度 関数単位、ファイル単位、PR単位など
背景の明示 なぜこのコードが書かれたのか
指摘の観点 バグ・スタイル・責務・拡張性などのカテゴリ化
トーンの指定 指摘の厳しさや敬語など
レビュー支援観点 
@Reviewer: プロンプトが漠然としすぎていると、AIは「静的に正しいか」しか見ない。  
意図や背景が書かれたプロンプトでないと、設計の妥当性には踏み込んでくれない。
LLMの限界と補い方

LLMは与えられた情報の中で最も妥当とされる出力を返すが、与え方次第でその判断基準は大きく変わる。
「レビューして」という曖昧な指示ではなく、「〇〇の意図に沿って見てほしい」というプロンプトを使うことで、出力の再現性と品質が向上する。

まとめ

AIによるレビューの精度は、「どんなプロンプトを与えるか」で大きく変わる。
ただ「コードを見て」ではなく、「こういう前提で見て」「こういう観点で評価して」と伝えることで、AIはより的確なレビューコメントを返してくれるようになる。

レビューアーの役割は、AIの結果を鵜呑みにすることではなく、「どういう視点で見てほしいかを明確に伝える力」を持つこと。
プロンプト設計は、単なる入力ではなく、レビュー文化そのものを支える設計行為と言っても過言ではない。

次にAIレビューを使うとき、「このプロンプト、本当にレビューになっているか？」と自問してみることから始めてみてほしい。