Codexでコードレビューする方法と注意点

Codex でできるコードレビューは3種類

• GitHub のPRレビュー：PRにコメントで依頼するか、自動レビューを有効にすると、Codex がチームメイトと同じ形でPRにレビューを投稿します。
• 手元の /review：CLI、IDE 拡張、デスクトップアプリで /review を実行し、コミット前やPR作成前の変更をレビューします。
• セキュリティレビュー：リサーチプレビューの機能で、@codex security review とコメントすると、通常のレビューより深くセキュリティ上のリスクを調べます。

手元の /review でプッシュ前に直し、PRでは GitHub のレビューで最終確認する、という二段構えにすると、レビューの往復が減ります。

GitHub で Codex にPRをレビューさせる手順

1. Codex と GitHub を連携する：Codex に GitHub を接続し、レビューさせたいリポジトリへのアクセスを許可します。
2. リポジトリのレビューを有効にする：Codex の設定でリポジトリを選び、Review code の Automatic review をオンにします。
3. PR でレビューを依頼する：プルリクエストに @codex review とコメントします。
4. すべての PR を自動でレビューする：Personal preferences の Automatic review をオンにし、Review trigger でレビューを始めるイベントを選びます。
5. AGENTS.md にレビュールールを書く：AGENTS.md に ## Code Review Rules の節を作り、チームのレビュー観点を書きます。

@codex review とコメントすると、Codex は作業中に 👀 のリアクションを付け、終わるとレビューを投稿します。1回のレビューに焦点を絞りたいときは、@codex review for issues in the database migration のように依頼内容を続けて書けます。

「@codex するだけ」では動かないときの確認点

コメントしても反応がない場合、原因の多くは設定の不足です。次の順に確認してください。

• Codex に GitHub が接続され、対象のリポジトリへのアクセスが許可されているか。
• Codex の設定で、そのリポジトリの Review code にある Automatic review がオンになっているか。
• 自動レビューを使う場合、Personal preferences の Automatic review もオンになっていて、Review trigger がPRのイベントと合っているか。
• 自動レビューの設定を変える人に、そのリポジトリの GitHub でのプッシュ権限または管理者権限があるか。
• コメントが @codex review と正確に書かれているか。

Codex のレビューの特性：P0 と P1 だけを指摘する

Codex は GitHub の標準的なPRレビューとして結果を投稿します。各コメントは差分の該当行に付き、問題の説明とともに、[P1] Approving MCP tools never notifies the server のような優先度ラベルがタイトルに入ります。

GitHub 上の Codex は、P0 と P1 の問題だけを指摘します。コメントが最優先のリスクに絞られるのでノイズは少なくなりますが、指摘がないことは「深刻な問題が見つからなかった」という意味で、「問題がない」という意味ではありません。中程度以下の問題、たとえば保守性やテスト不足の指摘は、そもそも報告の対象外です。

指摘を直したいときは、PRに @codex fix the P1 issue のようにタスクをコメントします。Codex はPRを文脈としてタスクを始め、権限があればブランチに修正をプッシュします。プッシュされたコミットも、ほかの変更と同じようにレビューしてください。

Codex CLI・IDE 拡張の /review の使い方

Codex CLI で /review と入力するとレビューのメニューが開きます。選べるのは次の4つです。

• ベースブランチとの比較（PR スタイル）：PRを作る前に、ブランチ全体をレビューします。
• 未コミットの変更：今作業している変更をレビューします。
• コミット単位：1つのコミットの変更をレビューします。
• カスタムのレビュー指示：エッジケースやセキュリティなど、見てほしい観点を指定してレビューさせます。

Codex は優先度を付けて指摘を報告し、作業ツリーは変更しません。そのため、コミットやPR作成の前に問題を直せます。レビューは振る舞いの変更とテストの不足を中心に見ます。終わったら /diff で実際の変更を確かめ、修正を頼むときは通常のサンドボックスと承認の設定が適用されます。

/review は Git リポジトリの中でだけ表示されます。既定ではセッションの現在のモデルを使いますが、config.toml に review_model を設定すると、変更を書いたモデルとは別のモデルでレビューできます。

IDE 拡張とデスクトップアプリでのレビュー

VS Code などの IDE 拡張では、コンポーザーに /review と入力します。既定では現在のチャットでレビューが進み、設定の chatgpt.reviewDelivery を detached にすると、別のレビュー用チャットで実行されます。デスクトップアプリでも、コンポーザーの /review か、ローカルの Git 変更を表示するレビューペインから使えます。

AGENTS.md にレビュー観点を書く

Codex はリポジトリ内の AGENTS.md を探し、変更された各ファイルに当てはまるレビュールールを適用します。ルールを書くのは、対象のコードに最も近い AGENTS.md の ## Code Review Rules の節です。### の見出しで関連するルールをまとめ、一つひとつをコードで確かめられる短い文にします。

## Code Review Rules

### 金額
- 金額は浮動小数点ではなく整数（最小通貨単位）で保存する。
- 表示用に整形するときだけ、10進数の文字列に変換してよい。

### データアクセス
- すべての API ハンドラーで、クエリを呼び出し元のワークスペースに絞り込む。
- トークンやリクエスト本文全体をログに出力しない。

OpenAI は、最初は2〜3個の簡潔なルールから始め、安全な書き方や許される例外を明記し、変わりうる関数名ではなく結果で書くことを勧めています。フォーマットや lint は、毎回確実に検出される CI に任せましょう。

入れ子の AGENTS.md の適用範囲

リポジトリ全体のルールはルートの AGENTS.md に、サービス固有のルールは services/billing/AGENTS.md のような入れ子のファイルに書きます。変更されたファイルごとに、ルートのルールと、そのファイルに近い階層のルールが適用されます。billing サービスの変更には両方が、それ以外の変更にはルートのルールだけが適用されます。

ルールはレビューの指針であり、テストやブランチ保護、必須の承認の代わりにはなりません。マージのたびに必ず守るべきことは CI のチェックにしてください。

料金と使用制限

Codex は ChatGPT の Free、Go、Plus、Pro、Business、Edu、Enterprise に含まれています。OpenAI の料金ページでは、Plus（月$20）のクラウド連携機能として、Web、CLI、IDE、iOS の Codex とあわせて自動コードレビューが挙げられています。Business は2人以上で、年払いなら1ユーザーあたり月$20、月払いなら月$25です。

Codex の Code Review の使用量が計上されるのは、PRで @codex とタグ付けしたときや自動レビューを有効にしたときなど、GitHub 経由でレビューした場合だけです。手元で /review を実行したレビューは、Codex 全体の使用制限にカウントされます。API キーで Codex を使う場合はクラウド機能がないため、GitHub でのコードレビューは使えません。

使用制限はモデル、タスクの大きさ、ローカルかクラウドかによって変わり、クラウドのタスクのほうが多く消費します。Plus と Pro は上限に達したあとに追加クレジットを購入でき、柔軟な料金体系の Business、Edu、Enterprise のワークスペースはワークスペース用のクレジットを購入できます。

Codex のレビューを使うときの注意点

• 深刻な問題しか報告されない：P0 と P1 に絞るぶん、中程度以下の問題は残ります。保守性やテスト不足は人のレビューで補う必要があります。
• 書いたモデル自身のレビューになる：Codex が書いた変更を Codex がレビューすると、同じ見落としをしがちです。別のモデルのレビュアーなら気づける可能性があります。
• 依頼がないとレビューされない：自動レビューを有効にしていなければ、誰かがコメントするまで PR はレビューされません。
• 人と複数のエージェントが混在するチーム：Claude Code や Cursor で書かれたPRも含めて、すべてを同じ基準で見たい場合は、独立したレビュアーが向いています。

Claude Code にも、手元のレビューコマンドと GitHub のPRレビューという似た仕組みがあります。詳しくは Claude Code でコードレビューする方法 で説明しています。

別のレビュアーと組み合わせるクロスレビュー

実用的な分担は、変更が手元にあるうちに CLI の /review で直し、PRでは独立したレビュアーに確認させる方法です。HeyDeer は、指摘ごとに該当行へインラインコメントを付けたPRレビューとして結果を投稿し、すべての指摘に緊急・高・中・低の深刻度を付けます。Codex の P1 の基準に届かない問題も、ここで拾えます。

HeyDeer も同じ AGENTS.md を読むので、Codex 向けに書いたルールがそのまま使えます。何を指摘しないか、どの種類の問題をどの深刻度で扱うかといったレビューにだけ必要な指示は REVIEW.md に書きます。投稿前には別のモデルが各指摘をコードと照合して検証し、リポジトリのレビューの言語を日本語にすれば、指摘事項もすべて日本語で届きます。

直したい指摘を選ぶと、HeyDeer は元のブランチに向けた修正PRを作り、続くレビューで結果を確認します（HeyDeer で修正）。ルールの書き方は HeyDeer がレビュールールを適用する仕組み を、ツール全体の比較は 適合率で選ぶAIコードレビューツールの比較 を、AIレビューの基本は AIコードレビューとは をご覧ください。

参考資料

1. OpenAI Codex docs: GitHub integration and code review
2. OpenAI Codex docs: code review
3. OpenAI Codex docs: Codex CLI
4. OpenAI Codex docs: CLI slash commands
5. OpenAI Codex docs: pricing