Codex コードレビューの使い方とGitHub自動レビュー設定

Codex のコードレビューとは何か

Codex のコードレビューは、プルリクエストに対して「もう一段の高シグナルなレビュー」をかけるための機能だ。プルリクエストの差分を読み込み、リポジトリに置かれた規約を踏まえたうえで、深刻な問題に焦点を当てた指摘を標準的な GitHub のコードレビューとして投稿する。レビュー結果は通常のレビューコメントと同じ形式で表示されるため、既存のレビュー運用にそのまま溶け込む点が特徴だ。人間のレビュアーが本格的に読み始める前の一次フィルターとして使うことで、明らかな見落としや危険な変更を早い段階で拾い上げられる。公式の解説では、回帰・テスト不足・ドキュメントの欠落といった、レビューで見落としやすい論点をプルリクエスト上に直接示すと説明されている（参照: Review GitHub pull requests | Codex use cases）。

この機能の背景にあるのは、コーディングエージェントとしての Codex が「コードを書く」だけでなく「コードを読んで評価する」役割まで担えるようになったことだ。差分を理解し、その変更が既存の振る舞いを壊さないか、テストが伴っているか、ドキュメントとの整合は取れているかを判断する。生成だけでなくレビューまでを一つのエージェントが扱えると、変更を出してから本番に入るまでの間に挟まる確認のコストが下がる。

通常のレビュー依頼と何が違うか

人間どうしのレビューでは、レビュアーがプルリクエストを開き、差分を上から下まで追い、気づいた点をコメントしていく。時間がかかるうえ、レビュアーの集中力や経験によって拾える問題の量が変わる。Codex のコードレビューは、この一次パスを機械的に安定させる位置づけだ。差分の全体を一定の基準で読み、優先度の高い問題だけを抽出して返すため、レビュアーは Codex の指摘を起点に「本当に重要な論点」へ集中できる。Codex はあくまで一次レビューであり、最終的な承認判断は人間が握る前提で使うのが健全な運用になる。

GitHub でコードレビューを有効にする手順

GitHub 上でコードレビューを使うには、まずリポジトリを Codex のクラウド側と連携させ、設定でコードレビューを有効化する必要がある。手順は次のとおりだ。

1. 対象リポジトリについて Codex のクラウド連携をセットアップする。リポジトリと Codex をつなぎ、差分を読み取れる状態にしておく。
2. Codex のコードレビュー設定画面（https://chatgpt.com/codex/settings/code-review)を開く。
3. 対象リポジトリの「Code review」をオンに切り替える。
4. プルリクエストへの依頼方法を決める。コメントで都度依頼する運用にするか、すべての新規プルリクエストをレビュー対象にするかを選ぶ。

この設定を済ませると、Codex がプルリクエストの差分を読み取れるようになり、レビュー依頼に反応するようになる。設定が反映されているかどうかは、テスト用の小さなプルリクエストでレビューを依頼し、Codex が 👀 のリアクションを付けるかどうかで確認できる（参照: Code review in GitHub | OpenAI Developers）。

@codex review でレビューを依頼する

個別のプルリクエストでレビューを受けたいときは、そのプルリクエストのコメント欄に @codex review と書き込む。Codex は依頼を受け取ると 👀 のリアクションでまず反応し、差分の読み込みを始める。読み終えると、深刻度の高い問題を行単位の指摘として投稿する。特定の観点に絞りたいときは、依頼コメントに文脈を足して @codex review for security regressions のように書くと、その回のレビューでセキュリティ上の回帰に重点を置いた読み方になる。一度きりの観点指定はこのインラインの書き方が手軽で、リポジトリ全体のルールには触れずにその場の関心事だけを伝えられる。

すべての PR を自動でレビューする設定

毎回コメントで依頼するのが手間なら、設定画面で「Automatic reviews」を有効にする。これを入れておくと、新しく作られたプルリクエストに対して Codex が依頼を待たずにレビューを返すようになる。レビュー基準そのものは依頼型と変わらず、対象のプルリクエストが増えるだけだ。チームで運用する場合、すべてのプルリクエストに一次レビューが必ず入る状態を作れるため、レビュー漏れを構造的に減らせる。反対に、レビューを受けたいものだけを選びたいチームでは、自動を切って @codex review の依頼型に寄せたほうが指摘の量を制御しやすい。

P0 / P1 に絞った指摘の読み方

Codex のコードレビューは、見つけた問題のうち深刻度が P0 と P1 のものだけを指摘として残す。軽微なスタイルの揺れや好みの分かれる書き方まで全部を並べると、本当に直すべき問題が埋もれてしまう。そこで Codex はあえて高優先度の問題に絞り、レビュー欄が高リスクの論点で構成されるようにしている。P0 はそのまま放置すれば深刻な不具合や障害につながりうる問題、P1 はそれに次いで早期の対応が望ましい問題、という温度感で受け取るとよい。

実際の指摘は、回帰の可能性・テストの欠落・ドキュメントとの不整合といった、レビューで取りこぼしやすい領域に集中する傾向がある。たとえば既存の関数のシグネチャを変えたのに呼び出し側を直していない、新しい分岐を足したのにテストが付いていない、公開 API の挙動を変えたのに説明が更新されていない、といった点だ。Codex の指摘を最終結論として鵜呑みにするのではなく、「ここは確認したほうがよい」というチェックリストとして読み、人間が裏付けを取ってから対応を判断するのが安全な使い方になる。指摘の優先度フィルターについては公式の解説でも明示されている（参照: Review GitHub pull requests | Codex use cases）。

AGENTS.md でレビュー観点を指定する

Codex のレビューは、リポジトリに置いた AGENTS.md に書かれた方針を踏まえて行われる。レビューの基準をチーム固有のものにしたいときは、AGENTS.md に Review guidelines のセクションを設け、守らせたい観点を箇条書きで書いておく。Codex は変更が入ったファイルに最も近い場所の AGENTS.md を優先して読み込むため、ディレクトリごとに異なるレビュー基準を持たせることもできる。

Review guidelines セクションの書き方は次のように素朴で構わない。

## Review guidelines
- 個人情報をログに出力しない
- すべてのルートに認証ミドルウェアが掛かっていることを確認する
- 外部入力を扱う関数には必ずバリデーションを書く

このように観点を明文化しておくと、Codex のレビューがチームのルールに沿った指摘を返すようになり、レビュアーごとの基準のばらつきを抑えられる。プロジェクトのルートに全体共通の AGENTS.md を置き、特定のモジュールにだけ厳しめの基準を課したい場合はそのディレクトリにも AGENTS.md を追加する、という階層構成にすると、大きなリポジトリでもレビュー基準を細かく制御できる。AGENTS.md の適用ルールは GitHub 連携の公式ドキュメントに記載されている（参照: Code review in GitHub | OpenAI Developers）。

指摘を修正までつなげる @codex fix

Codex のコードレビューが回帰や潜在的な問題を指摘したとき、その指摘をそのまま修正につなげられる。プルリクエストのコメントで @codex fix the P1 issue のように修正を依頼すると、Codex はクラウド側で修正のための新しいタスクを起動する。タスクは指摘された問題を直し、権限が与えられていればその結果をプルリクエストへ反映する。レビューで問題を見つけてから修正案を出すまでが一つの流れの中で完結するため、指摘を読んで別の場所で直して再度プッシュする、という往復が減る。

ただし修正を任せきりにするのは禁物だ。Codex が出した修正も差分の一つであり、その変更が別の問題を生んでいないかを人間が確認する必要がある。修正後のプルリクエストに対して改めて @codex review を掛け直し、新たな指摘が出ないかを見てから承認に進むと、レビューと修正のループを安全に回せる。修正依頼の動作は GitHub 連携の公式ドキュメントで説明されている（参照: Code review in GitHub | OpenAI Developers）。

Codex アプリ・CLI のレビューペイン

コードレビューは GitHub 上だけのものではない。手元の Codex アプリや CLI でも /review でレビューペインを開き、まだプルリクエストにする前の変更を対象にレビューを掛けられる。レビューペインは Codex が編集した箇所だけでなく、Git リポジトリの状態そのものを反映するため、自分で手を加えた変更も含めてまとめて確認できる。差分はファイルごとに折りたためる形で表示され、特定の行に + ボタンからインラインコメントを残したり、ファイル・ハンク・差分全体の単位でステージング・アンステージ・取り消しを行ったりできる。

手元でレビューを回せると、プルリクエストを出す前に一次チェックを済ませられる。プッシュしてからレビューが返ってくるのを待つのではなく、コミット前の段階で問題を潰しておけるため、レビューの往復が一段減る。なお、手元でプルリクエストのレビューまで扱う場合は、対象が Git リポジトリであることに加えて GitHub CLI(gh)が gh auth login で認証済みである必要がある（参照: Review | Codex app | OpenAI Developers）。

レビュー対象のスコープを切り替える

レビューペインでは、どの範囲を見るかをスコープとして切り替えられる。既定では未コミットの変更が対象になるが、ベースブランチとの差分（ブランチ全体の変更)、直近の一手分の変更、ステージ済みと未ステージの変更、といった単位に切り替えられる。プルリクエスト全体をまとめて見たいときはブランチ差分、いま書いたばかりの一手だけを確認したいときは直近の変更、という具合にスコープを使い分けると、見たい粒度でレビューを掛けられる。レビューペインから直接エディタで該当ファイルを開けるため、指摘を見ながらその場で直す動線も短い。

Codex のコードレビューは、GitHub 上での一次レビューと手元での事前チェックという二つの入口を持つ。@codex review でプルリクエストに高シグナルな指摘を呼び込み、AGENTS.md の Review guidelines でチームの基準を学習させ、@codex fix で修正までつなげる——この一連の流れを押さえておけば、レビューにかかる人手の負担を保ちながら、見落としを構造的に減らせる。機能は継続的に更新されているため、公式ドキュメントを定期的に確認しながら、自チームのレビュー運用に合った設定を育てていくとよい。