Codexにコードレビューを任せる手順|差分・再現・合格条件の渡し方
Codexへコードレビューを頼むときに、差分、再現手順、重大度、誤検知の確認、修正後の終了条件をどう渡すか、テンプレート付きで解説します。
Codexへ「このコードをレビューして」とだけ頼むと、好みの話と不具合が混ざりやすくなります。何を実現する変更か、どの差分を見るか、どう再現するか、どこからを重大と扱うかを先に固定しましょう。
OpenAIの公式資料では、Codexはコードベースや依存関係をたどり、コードとテストを実行して挙動を検証できると説明されています。一方で、Codexのレビューは人による確認、テスト、ブランチ保護、必須承認の代わりにはなりません。この記事では、AIを追加のレビュアーとして使い、指摘を再現可能な証拠へ変える手順を整理します。
レビュー工程の全体像
最初から修正まで一度に頼まず、依頼、指摘、再検証、修正、終了判定を分けます。各工程の受け渡しを固定すると、未確認の指摘をそのまま採用する事故を減らせます。
| 工程 | Codexへ渡すもの | 受け取るもの | 次へ進む条件 |
|---|---|---|---|
| 1. 依頼 | 変更目的、比較対象、重点観点 | レビュー範囲の理解 | 対象差分が一致している |
| 2. 指摘 | 差分、関連仕様、実行可能なコマンド | 重大度、根拠、再現手順 | 指摘と好みが分離されている |
| 3. 再検証 | 指摘ごとの前提条件 | 実行結果、反証、判定 | 再現済みか条件付きかが明確 |
| 4. 修正 | 採用する指摘だけ | 最小限の修正差分 | 依頼外の変更がない |
| 5. 終了判定 | テスト、型検査、lintの正式コマンド | 結果、終了コード、未検証範囲 | 人が統合可否を判断できる |
実装依頼とレビュー依頼を分ける
コードを書いた同じ会話で「問題ないか」と頼むと、実装時の前提を引き継いだまま評価しやすくなります。少なくとも依頼文を分け、可能なら新しいスレッドで変更目的と差分を渡してください。
実装依頼は「何を作るか」が中心です。レビュー依頼は「どんな故障を探すか」「何を合格とするか」が中心になります。先に実装条件を整理したい場合は、AIに実装を頼むときの依頼文テンプレを使い、実装が終わってから次のようなレビュー専用依頼へ切り替えます。
この変更をコードレビューしてください。修正はまだ行わないでください。
目的:
- ログイン失敗時に利用者へ再入力を案内する
対象:
- base: main
- head: feature/login-error
- 主な変更: src/auth/ と tests/auth/
重点:
- エラー分類、秘密情報、既存の成功経路
出力:
- 重大度、根拠となるファイルと行、再現手順、最小の修正方針
- 問題がなければ「重大な指摘なし」と未検証範囲
「修正はまだ行わない」と書き、差分を固定します。結果を確認してから、採用する指摘だけを別工程で直します。
渡す差分を絞る
レビュー対象は、ファイル名の羅列より比較の起点と終点で示します。Git公式ドキュメントでは、git diff <commit> <commit>で2つのコミット間、git diff HEADで最新コミットと作業ツリーの差分を確認できます。レビュー前に自分でも次を実行し、意図しないファイルが混ざっていないかを見ます。
git status --short
git diff --stat main...HEAD
git diff main...HEAD
差分が大きいときは、「認証処理」「画面表示」「テスト」のように責任ごとに分けます。ただし、関連する型定義、呼び出し元、テストを読んでよいことは明記します。
複数のレビューを走らせるなら、AIを同時に何人も動かすときの分け方を参考に、「セキュリティ」「仕様」「テスト」のように観点を分離します。
再現手順を書く
期待値と実際の結果を比べられる手順を渡します。「たまに失敗する」ではなく、初期状態、入力、操作、期待結果、実際の結果を並べます。
前提:
- Node.jsと依存関係はプロジェクトの標準手順で準備済み
- テスト用の値だけを使い、実在する認証情報は使わない
再現:
1. npm test -- --runInBand
2. tests/auth/login.test.ts の「期限切れトークン」を実行
3. 期待: 401を返し、ログにトークンを残さない
4. 実際: ※不具合がある場合だけ、観測した出力を貼る
追加検証: npm run lint、npm run typecheck
コマンドは例です。対象リポジトリのpackage.jsonや開発手順にある正式なものへ置き換えます。失敗時は、終了コード、最初の原因、未実行の検証を分けて報告させます。
テスト依頼そのものを整理したい場合は、Codexへテストを依頼するときの書き方も参照してください。認証情報を含む差分では、レビューへ渡す前にAIコーディングで秘密情報を守る方法で対象外にすべき値を確認します。
重要度で指摘を並べる
指摘は件数ではなく影響で並べます。次のP0からP3は、この記事で使う依頼用の定義であり、すべての組織に共通する規格ではありません。チームに既存の基準があれば、そちらを優先してください。
| 重大度 | 判断基準 | 例 |
|---|---|---|
| P0 | 公開や統合を直ちに止める | データ消失、認証回避、秘密情報の露出 |
| P1 | 主要機能が壊れ、現実的な回避策がない | 正常な利用者がログインできない |
| P2 | 条件付きで誤動作するが影響が限定的 | 特定入力だけ表示や保存が失敗する |
| P3 | 保守性や読みやすさの改善候補 | 重複処理、分かりにくい命名 |
各指摘には「入力」「発生する問題」「影響」「検証方法」を求めます。好みだけの話は不具合と混ぜません。
OpenAI公式のGitHubコードレビュー機能は、GitHub上ではP0とP1だけを指摘すると案内しています。ローカルでP2やP3まで必要なら、上の独自定義を明示してください。指摘ゼロでも、未実行テストは残します。
誤検知を再検証する
Codexの指摘は、そのまま修正命令にしません。対象行を読み、入力や状態を再現し、既存テストと仕様を照合します。再現できなければ、情報不足、環境差、誤検知を分けます。
指摘P1を再検証してください。まだコードは変更しないでください。
1. 指摘が成立する前提条件を列挙する
2. 最小の再現テストまたは確認コマンドを示す
3. 実行結果と終了コードを示す
4. 反証になる既存テストや仕様も探す
5. 再現済み、条件付き、再現できず、のどれかで結論を出す
テストは、現在のコードで失敗することを確かめてから修正し、同じテストが成功する順序で進めます。本番データ、課金、削除を伴う再現は自動実行せず、テスト環境へ置き換えます。
修正後の終了条件
レビューの終了は「直しました」ではなく、差分と検証結果で判定します。採否と理由、変更ファイル、実行コマンド、未確認範囲を一覧にします。
修正後の終了条件:
- 採用したP0/P1が再現テストで解消している
- 関連する既存テストが成功している
- git diffで依頼外の変更がない
- git diff --checkが成功している
- 未修正のP2/P3と未検証範囲を報告している
- 本番反映、公開、削除、課金は行っていない
Git公式資料によると、git diff --checkは競合マーカーや空白エラーを警告し、問題があればゼロ以外で終了します。正しさを保証する検査ではないため、テスト、型検査、lintと組み合わせます。
最後に人が、目的と差分の一致、重大な指摘の再現証拠、未確認事項を判断します。Codexは追加レビュアーであり、統合や公開の責任まで移す道具ではありません。
GitHubでは、保護ブランチへ統合する前に承認レビューやステータスチェックを必須にできます。AIレビューの有無とは別に、リポジトリ側の保護設定を維持してください。
よくある質問
Codexのコードレビューだけでマージしてもよいですか
いいえ。Codexは追加の確認役として使い、テスト結果、未検証範囲、必須承認を人が確認します。OpenAIも、生成されたコードは統合や実行の前に人がレビューし検証することが重要だと案内しています。
レビュー対象の差分はどう指定しますか
PRならbaseブランチとheadブランチ、ローカルなら比較する2つのコミットやブランチを明記します。main...HEADのような三点リーダーは共通祖先からHEADまでの変更を見るため、意図する比較かをgit diff --statでも確認してください。
指摘がゼロなら問題なしと考えてよいですか
指摘ゼロは「今回の条件で重大な問題を見つけなかった」という結果です。実行できなかったテスト、見ていない環境、対象外のファイルを別に報告させ、未検証を合格と混同しないようにします。
P2やP3もレビューしてもらえますか
ローカルのレビュー依頼では、この記事の重大度定義と出力条件を明示して依頼できます。GitHub上のCodexコードレビューは、公式資料ではP0とP1に絞って指摘すると説明されています。
Codexの指摘をそのまま修正させてもよいですか
先に指摘の前提と再現結果を確認し、採用するものだけを修正工程へ渡します。指摘と修正を分けると、誤検知による不要な変更や依頼範囲の拡大を見つけやすくなります。
一次情報
以下はすべて2026-07-23に確認しました。
- OpenAI「Codex code review in GitHub」(確認日: 2026-07-23): https://developers.openai.com/codex/cloud/code-review
- OpenAI「Introducing upgrades to Codex」(確認日: 2026-07-23): https://openai.com/index/introducing-upgrades-to-codex/
- OpenAI「Introducing Codex」(確認日: 2026-07-23): https://openai.com/index/introducing-codex/
- Git「git-diff Documentation」(確認日: 2026-07-23): https://git-scm.com/docs/git-diff
- GitHub Docs「About protected branches」(確認日: 2026-07-23): https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
続き(結論と実データ)はnoteに置いています
ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。