Codexへのコードレビュー依頼：バグを探すプロンプトと検証項目

要約： よいコードレビュー依頼は比較する変更と探す問題を伝えます。指摘が出た事実だけでバグが確定するわけではないため、根拠と再現条件を併せて確認してください。

1. 「レビューして」に比較対象を加える

開始時は一ファイルを読むのか、未コミットの変更を見るのか、基準ブランチと現在の変更を比較するのか指定してください。範囲が違えば含むコードと判断基準も異なります。終了後は使用した比較範囲を結果で確認するとよいでしょう。

OpenAIの公式コードレビュー文書は、Gitチェックアウトの変更を確認する/reviewとpull requestを扱うCode Reviewの流れを区別します。ローカル/reviewは優先順位のある指摘を報告し、作業ファイルを変更しない確認の流れと説明されています。具体的な選択項目は自分のアプリ、CLI、IDEで確認してください。

2. スタイルより実際の動作を先に尋ねる

インデントや変数名まで全て評価すると、重大な欠陥が軽い好みの問題に混ざる場合があります。架空のカート修正なら「数量0で削除されるか」「古い価格で決済が進む可能性があるか」のように動作を基準に範囲を定めてみてください。

既存の問題と今回の変更が新たに作った問題も分ける必要があります。変更行の近くで見つけたからと、その修正が原因とは断定できません。発生条件、コードの根拠、利用者への影響、今回の変更との関係を結果に求めると判断しやすくなります。

3. すぐ応用できるレビュープロンプト

현재 브랜치의 장바구니 변경을 지정한 기준 브랜치와 비교해 주세요.
이번 변경으로 생길 수 있는 동작 오류와 회귀를 우선 검토해 주세요.
특히 수량 0, 중복 클릭, 응답 실패 상황을 살펴봐 주세요.
이 요청에서는 코드를 수정하거나 PR 댓글을 게시하지 마세요.
각 지적에 파일 위치, 발생 조건, 근거, 예상 영향을 포함해 주세요.
확인된 사실과 추가 검증이 필요한 가능성을 구분해 주세요.
검토 범위와 직접 확인하지 못한 부분도 알려 주세요.

基準ブランチは実際のリポジトリの名前で指定する必要があります。mainを使うか不明なのに例をそのまま入れないでください。リポジトリが未把握なら、先に利用可能なブランチと現在の変更を説明させ、範囲を定められます。これは実際のレビュー結果ではなく依頼のテンプレートです。

4. 一つの指摘を検証可能な作業にする

例えば「重複クリックで商品が二度追加される可能性がある」と指摘されたら、どの状態で可能か先に質問します。ボタンが既に無効化されるか、サーバーが重複要求を処理するか、再現に必要なタイミングは何かを調べられます。周辺コードを読まない推測か、具体的な経路があるか分けてください。

중복 추가 지적의 재현 조건을 확인해 주세요.
관련 호출부와 중복 방지 처리가 있는지 살펴보고
현재 코드에서 가능한 경로와 아직 확인하지 못한 조건을 설명해 주세요.
결함이 확인되면 최소 수정안과 필요한 검증을 제안해 주세요.

レビューと修正は目的が異なります。問題確認後に修正を任せると不要な変更を減らせます。複数指摘の一部が誤った仮定と分かったら、その事実を後続依頼に入れ、同じ推測を繰り返さないようにしてください。

5. レビュー後のチェックリスト

• 比較範囲： 希望したブランチや変更集合か確認します。
• コードの根拠： 現在のファイルの位置が指摘と一致するか見ます。
• 再現条件： 正常入力とエラー入力を分け、実際に可能か確認します。
• 検証結果： 実行したテストと未確認の動作を分けます。
• 最新状態： レビュー後にコードが変わった場合、以前の指摘がまだ適用されるか確認します。

PRコメントとして共有するときもコード位置と根拠を再確認してください。公式文書は会話での確認と実際のコメント投稿、承認・マージを別と案内しています。共有する指摘を先に草案へ整理すれば、未確認の可能性が確定した欠陥として伝わることを減らせます。

6. /review前に変更範囲を読む

ローカルレビューでは先にリポジトリ状態を読むと、誤った対象の確認を減らせます。次はGitで現在の変更とブランチを見るコマンドです。他の人の作業中の変更があれば範囲に含めるか分けてください。今見える全変更がCodexの作成したものとは限りません。

git status --short
git diff --stat
git diff --cached --stat
git branch --list

公式CLI文書の/reviewは、基準ブランチ、未コミットの変更、特定コミット、直接指定した基準を選ぶ流れです。CLIの未コミット変更にはstaged・unstaged・untrackedファイルが含まれます。そのためstaging済みファイルが外れる、または新ファイルが確認されないと断定してはいけません。画面の範囲を読み、結果にも選んだ範囲を残してください。

見たい対象	選択基準	特に注意する点
現在修正中の作業	未コミットの変更	他の作業者の変更を含むか
機能ブランチ全体	実際の基準ブランチと比較	基準が最新で意図した対象か
一つの修正のまとまり	特定コミット	前後コミットの文脈も必要か
特定のリスクの調査	関連経路とレビュー基準を明記	呼び出し側を省いて結論を出さないか

基準ブランチが不明なら名前を推測せず、一覧とチームの作業方法を先に読んでください。対象を決めてから/reviewを実行すればよいでしょう。結果の前に範囲を確認すると、指摘が予想より多い・少ない理由を把握しやすくなります。

7. 数量0の不具合を架空コードで確認する

次は練習用の架空コードです。カート方針が「数量0なら項目削除」と仮定します。実際の実行コードや発見した欠陥ではありません。製品の数量方針が異なれば結論も変わるため、要件と併せて読む必要があります。

function normalizeItem(input) {
  return {
    productId: input.productId,
    quantity: input.quantity || 1
  };
}

この例で||は0を既定値1に変え得ます。コードから値変換を説明できますが、実際にカートが誤保存されると結論づけるには関数の呼び出し時点を確認する必要があります。数量0の要求が削除専用経路で処理され、この関数へ入らなければ削除動作に影響しない場合があります。この区別が推測と欠陥を分ける要点です。

가정한 요구사항: 수량 0 요청은 항목을 삭제합니다.
normalizeItem의 기본값 처리와 실제 호출 경로를 함께 검토하세요.
0이 1로 바뀌는 경로가 삭제 요청에서 도달 가능한지 확인하세요.
다른 계층에서 0을 처리한다면 해당 근거를 제시하세요.
도달 여부를 확인할 수 없다면 결함으로 확정하지 말고 필요한 자료를 적으세요.

期待する指摘の形式も定められます。「既定値演算子が悪い」ではなく「数量0の削除要求がこの関数に入る経路では1に正規化され、項目が残り得る」と条件を書きます。修正案は0、省略、負数、正常な正数を区別する必要があります。||を別演算子に変えるだけで数量方針全体が実装されるわけではありません。

8. 指摘を事実・仮定・検証計画に分ける

レビュー文は根拠の水準が異なります。「この関数は0を1に変える」は例の動作解釈、「削除要求がこの関数に入る」は呼び出し経路の確認です。「利用者の商品が残る」は製品全体の結果なので保存と応答の経路まで必要です。根拠の水準を分けると追加資料が必要な段階が分かります。

項目	よい報告の内容
発生条件	数量0の要求が正規化関数を通る場合
コードの根拠	該当ファイル・関数と呼び出し経路
期待動作	現在の要件の削除処理
確認方法	0の要求後の保存結果または応答を確認
残った条件	他の層の削除処理の有無など

리뷰 지적을 다음 항목으로 다시 정리해 주세요.
발생 입력, 기대 동작, 코드 근거, 사용자 영향, 이번 변경과의 관계.
직접 실행한 재현이 있으면 명령과 결과를 적으세요.
실행하지 않았다면 코드 해석과 검증 계획으로 표시하세요.
호출부나 요구사항이 부족한 지적은 필요한 자료를 구체적으로 남기세요.

優先度も影響に合わせて判断します。正常注文を阻む、データを誤保存する問題は変数名の好みより先に見る必要があります。ただし大きな影響の言葉で書かれたからと重大欠陥が確定するわけではありません。再現可能性、実際の使用経路、影響する入力を併せて調べてください。小さなリファクタリングに運用全体の障害を推測する報告なら、つながる根拠を求め直すとよいでしょう。

指摘が誤っていたら「既に処理している」で終えず、その仮定を否定する経路と検証を記録します。例えば削除要求を別処理し関数を呼ばないならコードとテストを結び付けてください。次回同じ誤解を繰り返さないよう、要件や呼び出し構成の説明を補うこともできます。

9. 修正後の再確認とPR共有まで進める

欠陥を確認したら必要部分だけ直し、関連検証を実行します。数量の例では0だけでなく省略と正常な正数も見ると、既定値変更の副作用を見つけられます。期待値を現在のコードに合わせる前に製品方針を再確認してください。変更後は以前のレビュー位置と説明が最新ファイルに合うかも調べます。

확인된 수량 0 결함을 최소 범위로 수정해 주세요.
값 누락·0·정상 양수 입력의 기존 정책을 구분해 주세요.
관련 테스트를 실행하고 변경된 동작과 보존한 동작을 보고하세요.
수정 후 동일 경로를 다시 검토해 새 문제나 빠진 조건을 찾아 주세요.
아직 확인하지 못한 통합 동작은 별도로 표시하세요.

PRに共有する際は指摘をそのまま貼るより、検証した事実を中心に草案を作ってください。よいコメントは発生入力、期待結果、現コードで異なる結果になる理由、確認する検証を短く結び付けます。未実行の再現を「確認しました」と書いてはいけません。次のテンプレートは検証の程度に合わせて変更できます。

수량 0 요청이 이 정규화 경로를 거치면 기본값 1로 바뀔 수 있습니다.
현재 요구사항은 0에서 삭제하는 동작이므로 호출 경로를 확인해 주세요.
[검증한 근거 또는 아직 필요한 검증]을 기준으로
0과 값 누락을 구분하는 처리 및 관련 사례 추가를 제안합니다.

公式Code Review案内では、会話中の確認と実際のコメント投稿・レビュー提出は区別されます。草案を読み、ファイル位置と最新diffの一致を確認して共有してください。レビュー後に修正コミットが追加されれば過去結果をそのまま最終判断にせず、変更範囲を読み直します。指摘数より実際の変更の理解と、確認できる欠陥からの解決が重要です。

10. よくある質問

指摘がなければ安全なコードですか？ 確認範囲で問題が見つからなかった意味です。全環境・入力の動作を証明した結果とは解釈しないでください。

Codexレビューだけで人の確認を代替できますか？ 変更の理解や見落とした事例探しに使い、サービス要件と運用の文脈を知る担当者が最終判断できる必要があります。

テスト成功でもレビューは必要ですか？ テストは記載された事例を確認します。不足事例や変更目的とコードの不一致を調べるレビューは別の問いに答えます。重要変更なら両結果を併せて読むとよいでしょう。

公式の出典と確認日： OpenAI公式文書：コードレビュー。2026年10月3日確認。コマンドと機能は現在の環境・権限を確認して使ってください。