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