Codex でコードレビュー：AI に PR を見てもらい、勝手にコードを変えさせない方法

800 行の PR が届き、タイトルは fix、description は「いくつか直しました」の一言だけ。diff を見ても、どこが重要な変更なのか判断しづらく、変更ファイルを 1 行ずつ全部読む気にもなれません。誰かが PR comment に @codex review for auth bypass and PII logging と書くと、数分後に logger.info(user.email) を指す inline comment が出てきます。

ここで決めるべきことは、Codex に自動で fix させるのか、自分で直すのか、それともまず業務側にこのログが許容されるか確認するのか、です。この記事では、起動条件、Review guidelines の書き方、P0/P1 の意味、処理フロー、人が確認すべき境界を整理します。

@codex review は万能の呪文ではない

@codex review は、AI にコードを自動で書き換えさせるスイッチではありません。Codex に PR diff を読ませ、あなたのルールに沿って review comments を出してもらう依頼です。起動するか、起動後に何を見るか、review 結果をどう扱うかは、前提設定と人の判断に依存します。

GitHub Cloud の起動条件と設定

Codex で code review を使う前提は、repository に Codex Cloud が設定されていて、あなたが code review settings にアクセスできることです。起動方法は 2 つあります。PR comment に @codex review と書く方法と、settings で Automatic reviews を有効にし、新しい PR が opened for review になったとき自動で review を投稿させる方法です。

起動後、Codex は PR diff を読み、repository guidance、つまり AGENTS.md に書かれた Review guidelines に従い、標準的な GitHub code review として inline comments を投稿します。@codex review は approval ではありません。Automatic reviews も自動承認ではありません。auth、payment、data migration のような敏感な変更は、引き続き人が確認します。

PR trigger と CI workflow に branch protection rules を組み合わせれば、AI review をチェックの 1 つとして扱えます。PR trigger の設定については、以前の記事 GitHub Actions PR trigger の基本 を参照してください。

P0/P1 に絞る。流水帳にはしない

Codex はデフォルトで P0/P1 優先度の問題だけをマークします。P0 は security regressions、auth bypass、data loss のようなブロッキングな問題です。P1 は performance、concurrency、logging sensitive data のような、修正すべき問題です。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

この絞り込みは、review comments の爆発を避け、シグナルを高く保ち、低価値なノイズを減らすためです。AGENTS.md の Review guidelines セクションでデフォルトルールを上書きできます。たとえば auth bypass、PII logging、concurrency だけを見るようにし、code style は Prettier に任せ、minor performance はホットパス以外では扱わない、と書けます。次の節では Review guidelines の具体的な書き方を見ます。

Review guidelines は AGENTS.md に書く。PR comment で毎回繰り返さない

Review guidelines は、Codex review の注目点と優先度を決めます。これは repository の AGENTS.md に書くべきで、PR comment に毎回同じことを繰り返すものではありません。

AGENTS.md の階層読み取りと Review guidelines の書き方

Codex は作業を始める前に AGENTS.md を読みます。読み取り順は Git root から現在の作業ディレクトリに向かって階層的に進み、近いディレクトリの指示ほど具体的です。たとえば auth/ ディレクトリ配下の AGENTS.md は、全体ルールを上書きして auth 関連のリスクだけに注目できます。

典型的な Review guidelines セクションは次のようになります。

## Review guidelines

次のリスクだけに注目する:
1. Security regressions(auth bypass、path traversal)
2. PII logging(user.email、phone number)
3. Concurrency issues(race condition、deadlock)

注目しない:
- Code style(Prettier で自動化)
- Minor performance(ホットパス以外)

この書き方の利点は、すべての PR が同じルールを共有でき、毎回 comment で説明しなくて済むことです。changed file に近い AGENTS.md ほど、より具体的なルールも書けます。

注意点として、instruction file の長さは project_doc_max_bytes に制限されます。デフォルトは 32 KiB で、長すぎるファイルは切り詰められる可能性があります。Project rules、Review guidelines、Coding style を含む AGENTS.md の完全な書き方は、Codex 実践ガイドの別記事で扱います。この記事では Review guidelines の構造と優先度制御だけに絞ります。

Codex app review pane で diff を見てから決める

Codex app の review pane は、AI の変更提案だけを表示する場所ではありません。Git repository の状態全体を反映します。デフォルトでは uncommitted changes に注目し、all branch changes や last turn changes に切り替えることもできます。

Inline comments と PR context

Review pane の inline comments は diff の行に直接付くため、その正確なフィードバックをもとに次の行動を決められます。Codex に fix させるのか、自分で直すのか、false positive として扱うのか、です。/review を実行すると、結果は review pane の inline comments として表示されます。

Codex が GitHub access を持ち、現在のプロジェクトが PR branch 上にある場合、app は PR context を表示できます。reviewer feedback、changed files、PR description などです。前提として GitHub CLI がインストールされ、gh auth login で認証済みである必要があります。これがない場合、PR details は表示されず、ローカル diff だけが見えることがあります。

粒度を制御する：file や hunk 単位で stage/revert する

Review pane では entire diff、file、hunk 単位で stage、unstage、revert できます。finding を見た瞬間に commit 全体を revert するのはおすすめしません。特に複数ファイルにまたがる変更では危険です。hunk 単位で扱えば、安全な変更は残し、リスクのある部分だけを戻せます。

review findings を処理する：@codex fix の後も diff、CI、テストを見る

P0/P1 が見つかっても、すぐ @codex fix に丸投げして終わりにしないでください。その finding が本当に正しいか、修正案が妥当か、敏感な変更としてチーム確認が必要かを判断する必要があります。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

Review findings triage 判断表

findings を処理する実行フロー

finding が本物か確認する: inline comment が指している diff 行を見て、問題が実際に存在するか確認します。

修正境界を判断する: auth、payment、data migration は敏感な変更です。必ず人が確認します。style や minor perf は無視するか toolchain に任せられます。

処理方法を選ぶ:

• Codex に fix させる: PR comment に @codex fix the P1 issue と書くと、Codex は PR context に基づいて cloud task を開始します
• 自分で直す: 手動でコードを編集し、ローカルテスト後に push します
• テスト追加を求める: follow-up issue を開くか、comment で説明します
• false positive とする: comment で理由を説明し、次回同じ誤検知が出ないようにします

diff と CI を見る: @codex fix に PR branch へ push する権限があっても、diff、CI 結果、テストカバレッジは確認します。Codex の fix は自動 merge でも、CI pass でも、人間 reviewer の approve でもありません。

敏感な変更は人が確認する: auth bypass、payment flow、data migration は安全境界に関わります。チーム reviewer が確認してください。人のチェックを飛ばしてはいけません。

やってはいけないこと

• 自動 push/merge しない: @codex fix は AI にコード変更を依頼するだけで、merge 許可ではありません
• CI チェックを飛ばさない: Codex が問題を直しても、CI を実行して他のテストを壊していないか確認します
• 人間 reviewer の意見を無視しない: AI review は 2 つ目のチェックであり、チーム reviewer の代替ではありません
• Codex に過大な権限を与えない: main branch push、force push、敏感ディレクトリへの write access は制限すべきです

敏感な変更の安全境界と権限制御は、Codex 実践ガイドの後続記事（安全権限と Secrets 管理）で詳しく扱います。CI workflow のベストプラクティスについては、以前の GitHub Actions CI pipeline を参照してください。

commit message と PR description：AI に文案を書かせても、規約を作り話にしない

@codex generate commit message や @codex generate PR description を使うと、Codex は diff と PR context から文案を作れます。生成後は人が確認し、そのまま commit しないでください。commit message は Conventional Commits に従うべきで、その場で独自形式を作らないほうが安全です。

Conventional Commits の規約と commit message テンプレート

Conventional Commits の形式は <type>[optional scope]: <description> です。よく使う type は、PATCH 版に対応する fix、MINOR 版に対応する feat、破壊的変更を表す BREAKING CHANGE footer または ! です。

例:

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

fix(auth): prevent bypass in login flow

- Add session validation before auth redirect
- Reject expired tokens within 5 minutes

Refs: #123

Conventional Commits を使う理由は、広く採用されている標準だからです。semantic-release、auto-changelog、commitlint などの toolchain は、この形式を使って changelog を自動生成し、バージョン番号を判断します。独自規約を作ると toolchain が効かなくなり、チーム協作のコストが上がります。

PR description テンプレート

PR description には、少なくとも 5 つの部分を含めます。

1. 背景: なぜこの変更をするのか（ユーザーフィードバック、性能問題、セキュリティリスク）
2. 変更範囲: 影響するモジュール（auth、payment、logging）
3. テスト: 検証済みのシナリオ（ローカルテスト、CI カバレッジ、手動確認）
4. リスク: 既知の境界条件（並行処理、大量トラフィック時の挙動）
5. ロールバック: 素早く戻す方法（revert commit、feature flag、config toggle）

Codex が生成したら、この 5 つがそろっているか、説明が正確か、リスクとロールバックが漏れていないか確認します。特に敏感な変更では、生成文をそのまま commit しないでください。

commit message と PR description の生成方針は、PR comment に具体的な指示として書けます。たとえば @codex generate commit message following Conventional Commits と書けば、AI に標準形式に従わせられます。

まとめ

Codex review は 2 つ目の高シグナルなチェックであり、merge 許可ではありません。@codex review は AI に diff を読ませ、inline comments を投稿してもらう依頼です。Automatic reviews は起動手順を自動化するだけで、approval や merge ではありません。

基本フロー:

1. AGENTS.md の Review guidelines では、auth bypass、PII logging、concurrency など 1〜2 個のリスクに絞ります。大きく広げすぎないこと
2. P0/P1 はデフォルトの注目点で、review comments の爆発を防ぎます。P0 は修正必須、P1 は処理方法を判断します
3. finding が出たら、inline comment が指す diff 行を見て、本当に問題か確認します。auth、payment、data migration のような敏感な変更は人が確認します
4. @codex fix の後も、diff、CI 結果、テストカバレッジ、人の判断を確認します。自動 push/merge、CI 飛ばし、人間 reviewer の無視はしません
5. commit message は Conventional Commits に従います。独自形式を作らないでください。toolchain は標準形式を前提に changelog 生成とバージョン判断を行います

行動案:

• repository に AGENTS.md を追加し、1〜2 個のリスクだけに絞った Review guidelines を書く
• 次の PR で @codex review を試し、inline comments が自分のルールに合っているか見る
• 敏感な変更では、Codex 実践ガイドの後続記事（安全権限と Secrets 管理、改坏代码と検証の振り返り）で境界を理解してから @codex fix を使うか決める

関連記事

• GitHub Actions PR trigger の基本: PR trigger と branch protection rules の設定
• GitHub Actions CI pipeline のベストプラクティス: CI フローにおけるチェックと人間 reviewer の役割
• AI coding assistant 比較: Claude Code vs Cursor vs Copilot: AI coding tool の選び方