Codexにレビューをおまかせ！4つのプリセットをどう使い分けるか
こんにちは、とまだです。
コードを書いた後、「これで大丈夫かな?」と不安になることがあります。特に、コミットする前やPRを出す前は、致命的なバグがないか気になります。
そんなとき、Codexの /review コマンドが役立ちます。このコマンドを使えば、AIが素早くコードをチェックしてくれます。さらに、見落としがちな問題点も指摘してくれます。
忙しい人のために要約
この記事では、Codexの /review コマンドの4つのプリセットと、その内部の仕組みを解説します。
それぞれのプリセットの使い方を知ることで、効率的なコードレビューが可能になります。
-
/reviewには4つのレビュープリセットがある - ブランチ間の差分をレビューする「PR Style」が便利
- コミット前に未コミット変更をチェックできる
- 過去のコミットも後からレビュー可能
- カスタム指示でプロジェクト固有のレビューもできる
/reviewコマンドの4つのプリセット
Codexの /review コマンドを実行すると、以下の4つのプリセットから選択できます。
Select a review preset
› 1. Review against a base branch (PR Style)
2. Review uncommitted changes
3. Review a commit
4. Custom review instructions
それぞれ、レビューする対象や使うタイミングが異なります。ですが、どれも開発のワークフローに組み込むと、コードの品質を高められます。
1. PR Style - ブランチ間の差分をレビュー
選択肢の 1. Review against a base branch (PR Style) に対応するプリセットです。
このプリセットは、特定のブランチと現在のブランチの差分を見て、変更内容をレビューしてくれます。
通常は main ブランチや develop ブランチを対象として使うことが多いです。
このプリセットの便利なところは、GitHub Pull Requestを作成していない段階で使えることです。つまり、ローカルでブランチを切って開発している段階から、AIにレビューしてもらえるわけです。
そのため、ブランチを切って開発するのが基本的にはおすすめです。レビューの恩恵を最大限に受けられるからです。
2. 未コミット変更のレビュー
選択肢の 2. Review uncommitted changes に対応するプリセットです。
このプリセットは、コミットしていない変更内容をレビューしてくれます。つまり、コミットする前に致命的な問題がないかをチェックできます。
これを習慣にしておくと、コミット一つ一つの品質が保証され、各コミットがセーブポイントとしての価値を持つようになります。
後から問題が見つかったときも、どのコミットで問題が混入したのかを特定しやすくなるため、デバッグが楽になります。
コミットの頻度やタイミングについては、別な記事で詳しく解説しています。
Gitコミットの頻度はどれくらい？AIに任せる場合はどうするべきか
3. 過去のコミットをレビュー
選択肢の 3. Review a commit に対応するプリセットです。
このプリセットは、過去にコミットした変更について、改めて問題がなかったかをレビューしてくれます。
特に便利なのが、「AIによる変更はまずコミット」→「その後にコミット内容をレビュー」という流れです。Review uncommitted changesでの指摘が万が一誤っていた場合を考えると、この流れが安全です。
コミット前に指摘を反映すると、一度作られた実装が壊れるリスクがあります。特に、慣れないうちは指摘が正しいかどうかの判断も付きにくいです。そのため、そういったリスクを減らすために、コミット後にレビューするという選択肢があります。
もしAIが意図せずコードを壊してしまった場合は、rewindコマンドで一発復旧できます。
Claude Codeのチェックポイント機能（rewind）とは？コードを安全に巻き戻す方法
4. カスタム指示でのレビュー
選択肢の 4. Custom review instructions に対応するプリセットです。
このプリセットは、レビュー範囲を好きに指定できます。たとえば、私はたまに以下のような形で使っています。
/review プロジェクト全体でリファクタできる箇所の有無
直接プロンプトを与えるのとそこまで変わらないかもしれませんが、/review の内部ではレビュー用に最適化されたプロンプトが含まれているため、意図的に /review コマンドと組み合わせて使っています。
また、プロジェクト特有のコーディング規約やお作法がある場合も便利です。作成済みドキュメントをもとにレビューして欲しいときに活用できます。
/review @.docs/xxx.md に則り、未コミットの変更内容をレビューして
特定のドキュメントを参照しながらレビューしてもらうこともできます。
プロジェクト全体で共通のコーディング規約を設定したい場合は、グローバルルールファイルの活用も便利です。
【コピペOK】技術的負債を作らないためのルールを設定しよう（Claude Code, Codex, Cursor対応）
/reviewコマンドの内部プロンプト
/review コマンドの中身は公開されています。実際に、Codexのリポジトリを調査していたら見つけました。
以下のURLで確認できます。
バグとして報告すべき基準
レビューでは、報告すべき問題と報告すべきでない問題が明確に定義されています。
まず、以下のような問題は、バグとして報告されます。
- コードの正確性やセキュリティに影響
- 問題が具体的で対処可能
- そのコミットで導入された問題
- 作者が知れば修正したいと思う問題
一方で、以下のような問題は報告されません。
- 些細なスタイルの問題（意味を損なわない限り）
- 単なる推測に基づく問題
- 作者の意図的な変更である可能性が高いもの
明確な基準があるため、有用なレビューコメントだけが届くようになっています。
コメントの作り方
レビューコメントには、以下のようなルールがあります。
- なぜバグなのかを明確に説明する
- 重要度を適切に伝える（過大評価しない）
- 簡潔にする（本文は最大1段落）
- コード例は3行以内に収める
- 事実ベースのトーンで、非難的にならない
- 過度な称賛や感謝の言葉は避ける
これらのルールに従うと、開発者にとって価値のあるフィードバックになります。特に、事実ベースのトーンを保つと、受け取る側も改善に集中できます。
AI時代におけるレビュー力の重要性については、別な記事で詳しく解説しています。
AI時代にエンジニアに求められるスキルとは？実装者からテックリードへの役割変化
優先度の付け方
各バグには、以下のような優先度が付けられます。
- [P0] すぐに修正すべき
- [P1] 緊急（次のサイクルで対処）
- [P2] 通常（いずれ修正すべき）
- [P3] 低（あれば良い程度）
この優先度により、どの問題から対処すべきかが分かりやすくなり、チーム全体で改善の優先順位を共有できます。
まとめ
Codexの /review コマンドには4つのプリセットがあり、それぞれ異なる場面で活用できます。
PR Styleを使えば、ローカル開発の段階からブランチ間の差分をレビューできます。未コミット変更のレビューでコミット前に問題を発見し、過去のコミットレビューならAIが生成したコードを安全に確認できます。カスタム指示を使えば、プロジェクト固有のルールに基づくレビューも可能です。
開発のワークフローに合わせて、これらのプリセットを使い分けてみましょう。
Xをフォローいただけると嬉しいです！
AI駆動開発（特に Claude Code）のノウハウや Tips をよく発信しています！
Discussion