Claude Code と Codex のコードレビュー手順：ローカル変更から PR までの閉ループ

Claude Code と Codex はどちらもコードを書けますが、同じ場所を同時に編集させるより、役割を分けた方が安定します。Claude Code が実装し、Codex が独立した視点でレビューする、という形です。

ここでは、ローカル変更、Codex レビュー、Claude Code による修正、PR 前チェックまでの実用的な流れをまとめます。

まず 2 つのツールの役割を決める

Claude Code は主作業台として、会話の流れに沿った編集、リファクタ、テスト追加に向いています。Codex は diff を別視点で見て、回帰、テスト不足、セキュリティリスク、設計上の見落としを探す役に向いています。

2 つの Agent に同じファイルを同時編集させないことが大事です。

最小構成の流れ

1
2
3
4
5
6


Claude Code が実装
  -> ローカルテスト
  -> Codex が diff をレビュー
  -> Claude Code が確認済み指摘を修正
  -> 必要なら Codex が再レビュー
  -> 人間が PR を確認

この分離により、実装時の会話バイアスから離れたレビューができます。

Claude Code から Codex を呼ぶ

プラグインや slash command がある場合は、まず通常レビューを使います。

1

/codex:review

高リスク変更では次を使います。

1

/codex:adversarial-review

プラグインがなくても、同じリポジトリで Codex を開き、現在の diff をレビューさせれば十分です。

ローカル変更レビュー

レビュー前に diff を確認します。

1
2
3


git status --short
git diff --stat
git diff

Codex への依頼例：

1

Review the current uncommitted diff. Focus on correctness, regressions, missing tests, security risks, and behavior changes. Do not rewrite the code; report findings with file and line references when possible.

「編集」ではなく「レビュー」に固定するのがポイントです。

PR 前レビュー

PR 前には次の観点を確認させます。

1

Review this branch before PR. Check whether the change matches the stated goal, whether tests cover the risky paths, and whether the PR description should mention migration, config, compatibility, or rollout risks.

良い出力は、実際の指摘、テスト不足、互換性リスク、未解決質問、PR 要約を分けて書きます。

挑戦的レビューを使う場面

次の変更では強めのレビューが有効です。

認証と認可;
決済や請求;
データ移行;
セキュリティ関連コード;
並行処理やバックグラウンドジョブ;
共通ライブラリ;
本番設定;
公開 API の挙動。

小さな変更すべてに使う必要はありません。

Claude Code にレビュー指摘を直させる

Codex の指摘は、人間が確認してから修正します。

1

Please address the confirmed Codex review findings. Do not refactor unrelated code. Keep the patch scoped and rerun the relevant checks.

修正後にテストし、必要なら Codex に再レビューさせます。

レビューリストをプロジェクトに置く

チームではチェックリストをリポジトリに置きます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


## High-risk areas

- Authentication and authorization
- Input validation
- Data migration
- Background jobs
- External API calls
- Error handling and retries

## Required verification

- Relevant unit tests
- Integration or smoke tests when behavior changes
- Manual check for UI changes
- Rollback or migration notes when needed

## Code review

- Findings first
- File and line references
- No speculative rewrites
- Mention missing tests separately

実装とレビューが同じ基準を参照できます。

自動 gate は慎重に

Codex の指摘で自動的に停止や merge をブロックする仕組みは便利ですが、ループや誤検知も起こります。

最初は狭いルールだけにします。

secret の混入;
変更モジュールのテスト不足;
危険な shell コマンド;
rollback のない migration;
セキュリティ敏感ファイルの未レビュー変更。

広い判断には人間を残します。

実用的なチーム手順

Claude Code が実装する。
開発者がローカルテストを実行する。
Codex が未コミット diff をレビューする。
人間が指摘を確認する。
Claude Code が確認済み指摘を修正する。
テストを再実行する。
Codex が PR 要約を補助する。
人間 reviewer が最終判断する。

よくある間違い

間違い 1：2 つの Agent が同時に編集する

競合と責任不明を生みます。1 つが書き、1 つがレビューします。

間違い 2：レビュー指示が曖昧

correctness、regression、tests、security、行参照を明示します。

間違い 3：テストを見ない

多くの問題はテスト不足です。Codex にテストギャップも見てもらいます。

間違い 4：AI review を最終判断にする

AI は有用ですが、意図を誤解することがあります。

間違い 5：ルールを残さない

チャットだけにあるルールは忘れられます。リポジトリに残します。

FAQ

どちらがコードレビュー向きですか？

Claude Code は実装、Codex は独立レビューに向きます。

Codex review は自動でコードを直しますか？

読み取り専用レビューを依頼すれば、直さない運用にできます。

すべての PR に adversarial review は必要ですか？

不要です。高リスク変更に使います。

review gate はデフォルトで有効にすべきですか？

通常は report-only から始めるべきです。

チェックリストはどこに置きますか？

リポジトリ内のレビュー文書や Agent instruction に置きます。

AI review の結果は PR にどう書きますか？

確認済み指摘、修正内容、残リスク、実行テストだけを整理します。

まとめ

Claude Code と Codex の良い組み合わせは、2 つの Agent に同時編集させることではありません。実装、独立レビュー、確認済み修正、再チェック、人間の最終判断という流れにすると、制御を失わずにレビュー品質を上げられます。