Claude Codeのコードレビュープロンプト：バグの根拠と再現条件を求める

要点： コードレビューを依頼するときは「問題をたくさん見つけて」より、どの変更をどの動作基準で確認するかを伝えてください。結果にはファイル位置、発生条件、利用者への影響、確認の根拠が必要です。以下のプロンプトと計算関数の例は執筆者が構成した確認練習用で、実際のリポジトリのレビュー結果ではありません。

1. 確認範囲と正常動作を先に定める

対象が現在の変更か、特定のファイルか、一つの機能の全体の流れかを先に書いてください。Gitを使う場合、比較基準も実際のリポジトリで定める必要があります。漠然と「全コードをレビューして」と頼むと、以前からの問題と今回の変更の問題、スタイルの好みが混ざることがあります。

正常動作は短い入出力の例で説明できます。検索機能なら「検索語が空のとき全一覧を表示するか、案内だけを表示するか」を明示してください。画面に求める結果を定めなければ、同じ実装も異なる基準で評価されます。既存の設計文書やテストがあれば、その位置も提供します。

2. 基本のコードレビュープロンプト例

이번 변경을 코드 리뷰해 줘. 파일은 아직 수정하지 마.
검토 범위: [실제 변경 파일 또는 비교 기준]
요구 동작: [입력과 기대 결과]
우선 확인: 잘못된 결과, 예외 처리, 기존 기능의 회귀.
스타일 선호만으로 문제를 만들지 마.
각 지적은 아래 형식으로 적어 줘.
- 파일과 위치
- 어떤 입력 또는 상태에서 발생하는지
- 사용자에게 어떤 영향이 있는지
- 코드·테스트·실행 결과 중 확인 근거
- 실제로 확인한 문제인지, 아직 확인할 가설인지
실행하지 않은 테스트는 실행했다고 쓰지 마.

レビューと修正は別の作業なので、まず指摘を読み、妥当な問題を選んでから修正を依頼できます。コードの見た目だけで判断しにくい問題は呼び出し経路と実際のデータ条件を確認する必要があります。この書式の目的は指摘を増やすことより、判断に必要な情報を集めることです。

3. 架空の例：割引金額の関数を確認する

商品金額と割引率を受け取り、最終金額を計算する関数を考えます。確認基準を「金額は0以上、割引率は0から100、不正な入力は明示的に処理する」と定めます。10,000ウォンを20%割り引くなら期待金額は8,000ウォンです。これは説明用に直接計算した値で、コードの実行結果ではありません。

• 正常範囲：10,000ウォン・20%で定めた期待値と一致するか。
• 境界値：割引0%と100%をどう処理するか。
• 不正な値：負数、空の値、数値でない値の処理方法。
• 接続する流れ：画面から受け取った文字列を数値に変換する位置。
• 表示規則：小数点と丸め処理をどこで扱うか。

関数だけ見れば問題がなくても、入力変換や画面表示で誤りが起きることがあります。逆に外部段階で検証済みの入力だけを受け取る関数なら、全ての防御ロジックを重複して入れる必要がない場合もあります。レビューには「この入力は実際に渡されるか」という条件確認を含めてください。

4. 指摘を事実・仮説・改善提案に分ける

「空の配列で例外が発生した」という実際の再現結果と、「空の配列なら例外が起きる可能性がある」というコードの解釈を区別する必要があります。実行ログがないのに前者と書かれていれば、どのコマンドと入力で確認したかを尋ねてください。実行できない環境なら、確認方法を提案として残せます。

AnthropicのClaude Codeの推奨作業方法も、検証基準を与え、結果を独立して確認する方針を説明しています。レビュー回答を正解の一覧として受け取るより、各指摘のコード経路と影響を照合してください。説明が具体的でも誤った仮定がある場合があります。

確認後は指摘ごとに「再現済み」「追加確認が必要」「現在の要求範囲外」などの状態を記録するとよいでしょう。根拠のない指摘を直すためにコードを複雑にするより、先に発生条件を確認して必要な変更を選んでください。

5. 修正後は同じ条件で再確認する

問題を修正したら、元の再現条件と正常条件を両方確認してください。不正な割引率だけを防ぎ、正常な20%入力まで失敗させると別の回帰が生じています。関連テストやコマンドは実際のプロジェクトの方法に従う必要があります。テスト名だけを生成した状態と、実行して成功した状態も区別します。

完了報告は「修正ファイル、問題の原因、実行した検証、残った確認事項」に整理できます。公式の作業例でもテストと変更の確認を段階的に扱っています。報告にない検証を読者が実施済みと推測しないよう、未実行項目も明記するよう依頼してください。

6. 変更レビューと要件レビューを区別する

現在の変更によるバグを探す作業と、計画の全要件が実装されたか確認する作業では質問が異なります。前者は変更前後のコード経路と回帰を中心に読み、後者は計画の項目を実装・検証の根拠と対応づけます。どちらかを明記すれば「機能はあるが要求条件が一つ不足する場合」も意味のある指摘に分類できます。

確認日時点の公式推奨文書には、現在のdiffを別のサブエージェントが確認する組み込みの/code-review機能も紹介されています。最初から全ての確認方法が同じだと考えるより、自分の目的が変更の誤り確認か、計画との照合かを先に定めてください。機能を呼び出した事実自体は、問題の再現や全要件の充足を証明しません。

7. 架空のコードで指摘の根拠を最後まで追う

先の割引例をもう少し具体化します。次のJavaScriptコードは練習用の架空コードで、実際のプロジェクトでの実行結果はありません。画面で「20%」を数値20に変換して渡す条件を仮定します。割引率を0.2で渡す別の設計なら判断が変わるため、先に入力の契約を定める必要があります。

function finalPrice(price, discountPercent) {
  return price * (1 - discountPercent);
}

定めた契約なら10,000と20を代入すると式は10,000 × (1 − 20)となり、−190,000です。要求した8,000と異なります。この値はコードの実行ログではなく、式に直接代入した計算です。指摘は「割引関数がおかしい」より「パーセント単位の20を受け取る契約で割合への変換がなく、正常入力も負数になる」と書くと、原因と条件が分かります。

修正した式でパーセント値を100で割っても、入力の拒否、小数点、通貨表示まで自動的に決まるわけではありません。例えば999ウォンの15%割引は算術上849.15ウォンです。実際の販売金額を丸めるか切り捨てるかはプロジェクトの要求に合わせて定める必要があります。レビュー担当者が好みで金額方針を変えないよう基準を提供します。

이 함수의 입력 계약은 할인 비율을 0~100 숫자로 받는 것입니다.
호출부에서 실제로 이 계약을 지키는지 먼저 추적해 줘.
10,000 / 20% 사례의 식과 기대값 차이를 설명해 줘.
실행 로그가 없으면 '정적 검토와 계산으로 판단'이라고 표시해 줘.
입력 검증·반올림 정책은 기존 문서에서 확인하고,
근거가 없으면 별도 결정 사항으로 남겨 줘.

8. 誤検出を減らす質問と指摘の分類

例えば「文字列入力なら失敗する可能性がある」という指摘があっても、呼び出し側で数値変換し範囲を検査しているなら、その入力が関数まで到達するか追加確認が必要です。未確認の経路を根拠に防御コードを積み重ねるより、呼び出し位置とデータ変換を追い、指摘を採用するか決めます。これは誤りを無視する手順ではなく、発生条件を確認する手順です。

리뷰 지적 2번을 다시 검토해 줘.
주장한 입력이 외부에서 해당 함수까지 오는 호출 경로를 제시해 줘.
중간 검증이 있다면 그 파일과 조건을 확인해 줘.
현재 코드로 발생할 수 없는 가정이면 지적을 철회하고 이유를 적어 줘.
검토 범위에서 호출부를 찾지 못했다면 '추가 확인 필요'로 남겨 줘.
같은 이유를 표현만 바꿔 여러 지적으로 나누지 마.

報告を読む際は影響の大きさと根拠の水準も別々に見ます。決済結果が誤る不具合は影響が大きいかもしれませんが、発生経路が未確認ならその状態も記載する必要があります。「重大」というラベルだけで再現済みの問題にしません。逆に再現が小さく簡単だからといって、利用者への影響まで小さいと判断しません。

9. 選んだ問題だけを修正し、結果を比較する

妥当な指摘を選んだら、修正依頼に維持する動作も含めます。割引関数なら単位変換の修正と画面全体の改修は別の範囲です。関連テストがあれば既存の実行手順に従い、なければ主要な入力の期待結果を明記して、確認方法から定められます。プロジェクトにないテストコマンドを作り、実行結果のように記載してはいけません。

채택한 지적: [번호와 원인]
수정 범위: 할인 비율 변환과 직접 관련된 코드.
유지 조건: 기존 화면·공개 함수 입력 형식 유지.
검증 기준: 정상 20%, 경계 0%와 100%, 기존 입력 거부 정책.
실제 프로젝트의 검증 명령을 근거 파일에서 찾아 사용해 줘.
완료 보고에는 변경 파일, 해결한 원인, 실행 명령과 결과,
실행하지 못한 항목·이유를 나눠 적어 줘.
검증 중 다른 문제가 나오면 이번 수정과 관련 여부를 구분해 줘.

最後にdiffを読み直し、依頼範囲外の変更が入っていないか確認します。「テスト成功」と表示されていれば、どのテストがどの環境で実行されたかを確認し、金額表示など別途残る項目を削除しません。一つのテストが成功したという観察は、そのテスト範囲の根拠です。サービス全体が全入力で正常という結論に広げません。

テストを実行していなくてもレビューできますか？

コードの条件と呼び出し経路を読む静的レビューは可能です。結果に未実行と記載し、どの入力で何を確認する必要があるか残してください。環境の問題で実行できない場合は「レビュー失敗」の一言より、静的に確認した項目と残った動作確認を分けると、次の担当者が引き継ぎやすくなります。

よくある質問とミスの解決

レビューで問題なしと言われたら終わりですか？ 確認した範囲と実行の有無を調べる必要があります。スタイルの指摘が多すぎる場合は？ 機能の誤りと要件違反を優先するよう基準を具体化してください。自動修正まで任せてもよいですか？ 選んだ指摘と修正範囲を明示し、修正後に同じ条件での検証結果を確認してください。

公式の出典と確認日

• Claude Codeのベストプラクティス
• 一般的なワークフロー

公式文書確認日：2026年10月3日。画面と提供条件は後に変わることがあります。