Codexのコードレビュー機能の使い方｜/reviewとGitHub連携

Codexのコードレビュー機能を使えば、Codexに任せた変更をその場でチェックできる。ただし呼び出し方は一つではなく、結論から言うと、Codexにはローカルの/reviewコマンドとGitHub連携の@codex reviewという2種類があり、呼び出し方も前提条件も異なる。

この記事では、OpenAIの公式ドキュメントに記載された文言をもとに、/reviewコマンドで自分の変更をその場で確認する方法と、GitHubのPull Requestを@codex reviewやAutomatic reviewsで自動レビューする設定を、実際に触る順番で整理する。仮の例として、個人で書いたコードは手元のcomposerで/reviewを使い、チームで運用するリポジトリではGitHub側のAutomatic reviewsを有効にしてPull Requestごとに自動でレビューを走らせる、という使い分けを想定しながら読み進めてほしい。

Codex自体の基本的な使い方はOpenAI Codex 使い方｜料金・始め方・Claude Codeとの違いで解説している。この記事は、その先にある「書いたコードをどうレビューするか」に絞った内容になる。

Codexのコードレビュー機能とは｜ローカル/reviewとGitHub連携の違い

Codexのコードレビュー機能とは、Codex自身やチームメンバーが加えた変更を診断し、優先度付きの指摘を返す仕組みであり、Codexのcomposer(入力欄)から呼び出す/reviewコマンドと、GitHub上のPull Requestを対象にする@codex review・Automatic reviewsという2つの経路がある。

ローカルのレビューについて公式ドキュメント(Code review)は「Codex reports prioritized findings without changing your working tree.」(Codexは作業ツリーを変更せずに、優先度付きの指摘を報告する)と説明しており、次のH2から詳しく取り上げる。一方でGitHub連携は、公式ドキュメント(Codex GitHub連携)が案内する別の設定画面から有効化する、独立した機能になる。呼び出し方も、有効化のために必要な権限も異なるため、まずはこの2系統を切り分けて理解しておくと、あとの手順で迷いにくい。

この記事のCodexはOpenAI Codexの提供形態の違い｜CLI・IDE・クラウド・アプリ比較で扱っているCLI・IDE拡張・クラウド・アプリのいずれの提供形態でも、composer(入力欄)を持つ画面であれば/reviewコマンドを使える前提で説明する。まず両者の違いを次の表で比較する。

/reviewコマンドの呼び出し方と2つのレビューモード

/reviewコマンドとは、Codexのcomposerに/reviewと入力して呼び出す、ローカルの変更を診断するための機能であり、実行すると「ベースブランチとの比較」と「未コミット変更のレビュー」の2つのモードを選べる。

公式ドキュメント(Code review)は「To ask Codex to review the changes, type /review in the composer.」(変更をレビューしてもらうには、composerに/reviewと入力する)と説明しており、この操作だけでレビューが始まる。

/reviewを実行すると、公式ドキュメントが挙げる次の2つのモードから選ぶ。1つ目は「Review against a base branch」(ベースブランチとの比較)で、Pull Requestを作る前に自分のブランチ全体の変更をまとめて確認したいときに向く。2つ目は「Review uncommitted changes」(未コミット変更のレビュー)で、コミットする前の、書きかけの差分をその場でチェックしたいときに使う。仮の例として、機能を追加している間はこまめに「未コミット変更のレビュー」を使い、Pull Requestを出す直前に「ベースブランチとの比較」でブランチ全体を見直す、という2段構えが考えられる。

レビューペインで確認できる内容と前提条件

レビューペインとは、/reviewを実行した結果としてCodexが優先度付きの指摘を表示する画面であり、作業ツリーそのものを書き換えることはなく、Gitリポジトリ内のプロジェクトであることを前提とする。

公式ドキュメント(Code review)は「Codex reports prioritized findings without changing your working tree.」(Codexは作業ツリーを変更せずに優先度付きの指摘を報告する)と、「The review pane requires a project inside a Git repository.」(レビューペインはGitリポジトリ内のプロジェクトを必要とする)の2点を明記している。Gitリポジトリでないフォルダでは、レビューペインを開く前にリポジトリの作成を促される。

つまりレビューペインは、Codexが直接ファイルを書き換える機能ではなく、あくまで「どこに問題がありそうか」を先に見せるための画面だと理解しておくと、レビュー結果をどう扱うか判断しやすくなる。

表示される内容についても公式ドキュメント(Code review)は「The pane shows changes made by Codex, changes you made yourself, and any other uncommitted changes in the repository.」(ペインには、Codexによる変更・自分自身が加えた変更・その他の未コミット変更が表示される)と説明しており、表示モードは「Default view options include Unstaged changes, with alternatives for Staged, Commit, Branch, or Last turn perspectives.」(既定の表示はUnstaged changesで、Staged・Commit・Branch・Last turnという視点にも切り替えられる)としている。仮の例として、Codexに複数回続けて修正させたあとは「Last turn」で直近の変更だけに絞って見直し、コミット前の最終確認では「Unstaged changes」に戻す、という使い分けが考えられる。

インラインコメントで指摘し、変更をstage/unstage/revertする

インラインコメントとは、レビューペイン上で差分の特定の行にカーソルを合わせて+ボタンを押すことで残せるフィードバックであり、変更は差分全体・ファイル単位・hunk単位のいずれかの粒度でstage(ステージ)・unstage(ステージ取り消し)・revert(取り消し)できる。

公式ドキュメント(Code review)は「Stage, unstage, or revert changes at multiple levels: entire diff, per file, or per hunk.」(変更は差分全体・ファイル単位・hunk単位という複数の粒度でstage・unstage・revertできる)と説明しており、行ごとにコメントを残す操作は「Leave feedback by hovering over lines and selecting the + button.」(行にカーソルを合わせて+ボタンを選ぶことでフィードバックを残せる)と案内されている。

さらに公式ドキュメントは「If you ask Codex to apply the fixes it finds, your normal sandbox and approval settings apply.」(Codexに見つかった修正の適用を依頼すると、通常のサンドボックスと承認設定が適用される)とも述べている。この「サンドボックス設定」がどこまでの操作を許可するかは、Codex CLIのconfig.toml完全ガイド｜設定の優先順位と書き方で扱っているapproval_policyとsandbox_modeの組み合わせで決まる。仮の例として、workspace-writeのサンドボックスであればレビューペインで指摘した修正をその場でCodexに適用させ、danger-full-accessでなければネットワークアクセスを伴う修正には別途承認が必要になる、という流れになる。

GitHubでCode reviewを有効にする設定手順

GitHub連携のCode reviewとは、Codex cloudの設定を済ませたGitHubリポジトリに対して、Pull Requestのレビューを任せられるようにする機能であり、有効化にはリポジトリへのGitHub push権限またはadmin権限が必要になる。

公式ドキュメント(Codex GitHub連携)は、有効化の手順を「Set up Codex cloud」「Go to Codex settings」「Turn on Code review for your repository」の3ステップで示し、これには「a connected GitHub repository and GitHub push or admin permission for its settings」(接続済みのGitHubリポジトリと、その設定に対するGitHub push権限またはadmin権限)が必要だと説明している。

チーム・組織単位でCodexを導入する場合の権限設計や移行計画はOpenAI Codex企業導入ガイド｜モデル・コスト・移行計画で扱っている内容とも関わるため、GitHub側の権限を誰に付与するかは個人のリポジトリで試す段階から決めておくと、後の展開がスムーズになる。Codex cloud自体の使い方はCodex Cloudの使い方｜導入手順・環境設定・料金プランを解説で確認できる。

@codex reviewでPull Requestを手動レビューする

@codex reviewとは、GitHub連携を有効にしたリポジトリのPull Requestコメントで使えるメンションであり、これを投稿するとそのPull Requestに対するレビューが1回実行される。

公式ドキュメント(Codex GitHub連携)は「In a pull request comment, mention @codex review.」(Pull Requestのコメントで@codex reviewとメンションする)と説明しており、コメントを投稿するタイミングで都度レビューを走らせたいときに向く操作になる。

レビュー結果はこのあとのH2で扱うとおりPull Request上にコメントとして返ってくるため、レビューを依頼したコメントとCodexからの返信を見比べれば、どのタイミングのレビューかを追いやすい。

Automatic reviewsで全Pull Requestを自動レビュー対象にする

Automatic reviewsとは、Codex設定の中でオンにすることで、そのリポジトリに作られるすべてのPull Requestを@codex reviewのメンションなしで自動的にレビュー対象にする機能である。

公式ドキュメント(Codex GitHub連携)は「If you want Codex to review every pull request automatically, turn on Automatic reviews in Codex settings.」(すべてのPull Requestを自動でレビューしたい場合は、Codex設定でAutomatic reviewsをオンにする)と説明している。

手動の@codex reviewが「気になったPull Requestだけ都度依頼する」運用に向くのに対し、Automatic reviewsは「レビュー依頼を忘れても一度はCodexの目を通す」運用に向く。仮の例として、小規模な個人リポジトリでは@codex reviewを都度使い、複数人が並行してPull Requestを出すリポジトリではAutomatic reviewsをオンにしておく、という切り分けが考えられる。

@codex security reviewでセキュリティに絞ったレビューを行う

@codex security reviewとは、通常のコードレビューではなく、セキュリティの観点に絞ってPull Requestを診断させるための専用メンションである。

公式ドキュメント(Codex GitHub連携)は、セキュリティに絞ったレビューの呼び出し方として「@codex security review」という表記を挙げている。通常の@codex reviewが一般的な指摘を対象にするのに対し、この呼び出し方はセキュリティの観点に絞って診断してほしいときに使う。なお公式ドキュメントはこのSecurity Reviewを「available in research preview」(research preview段階で提供中)と位置づけており、正式機能としては案内していない。

ここまでの手動・自動・セキュリティという3つのトリガーを整理すると、次の表のようになる。

レビュー結果はどう返るか｜P0/P1に絞る仕組み

Codexのレビュー結果とは、Pull Request上にコメントとして投稿される指摘であり、優先度の高いP0・P1に該当する問題だけに絞って表示される仕組みになっている。

公式ドキュメント(Codex GitHub連携)は「Codex posts a review on the pull request, just like a teammate would.」(Codexはチームメンバーと同じように、Pull Request上にレビューを投稿する)としたうえで、「In GitHub, Codex flags only P0 and P1 issues so review comments stay focused on high-priority risks.」(GitHub上ではCodexが優先度の高いP0とP1の問題だけを指摘するため、レビューコメントは優先度の高いリスクに絞られる)と説明している。

つまり、軽微なスタイルの好みや些細な指摘が大量に投稿されるわけではなく、優先度が高いと判断された指摘に絞って返ってくる設計になっている。どの水準をP0・P1とするかの具体的な基準までは、この記事で参照した公式ページには記載がなかったため、実際の判定基準は自分のリポジトリで受け取ったレビューを見ながら確認してほしい。

AGENTS.mdのCode Review Rulesでレビュー基準をカスタマイズし、限界を理解する

Code Review Rulesとは、AGENTS.mdファイルに追加する見出しであり、そのリポジトリ固有の重要な振る舞いについてCodexのレビュー基準をカスタマイズするための仕組みである。

公式ドキュメント(Codex GitHub連携)は「Customize what Codex reviews by adding code review rules to AGENTS.md files with a ## Code Review Rules section.」(AGENTS.mdファイルに##Code Review Rulesという見出しでレビュールールを追加することで、Codexが何をレビューするかをカスタマイズできる)と説明しており、その記述内容は「consequential, repository-specific behavior」(そのリポジトリ固有の、重要な振る舞い)に絞り、「the safe path or exception」(安全な方法や例外)まで含めることが望ましいとされている。AGENTS.mdそのものの書き方や優先順位はCodex CLIのAGENTS.md活用ガイド｜指示の優先順位と書き方で解説している。

一方で公式ドキュメントは「Code review rules guide Codex; they don’t replace tests, branch protections, or required approvals.」(コードレビュールールはCodexを導くものであり、テスト・ブランチ保護・必須の承認の代わりにはならない)とも明記している。つまりCode Review Rulesは既存のテストやブランチ保護ルールを置き換える仕組みではなく、それらと併用したうえでCodexのレビュー精度を上げるための補助的な設定だと理解しておく必要がある。Codexにレビュー以外の外部ツール連携をさせたい場合はCodex CLIのMCP連携ガイド｜サーバー追加とconfig.toml設定で扱っている設定が別途必要になる。

よくある質問(FAQ)

Q1. ローカルの/reviewコマンドとGitHubの@codex reviewはどちらを使えばよいか

Pull Requestを作る前に自分の変更をその場で確認したい場合はローカルの/reviewコマンド、チームで運用しているリポジトリのPull Request自体をレビュー対象にしたい場合はGitHub連携の@codex reviewやAutomatic reviewsが向く。両者は別々の機能であり、どちらか一方だけを選ぶ必要はない。

Q2. /reviewの「ベースブランチとの比較」と「未コミット変更のレビュー」はどう使い分けるか

書きかけの段階でのこまめな確認には「未コミット変更のレビュー」、Pull Requestを出す直前にブランチ全体を見直す場合には「ベースブランチとの比較」を使う、という使い分けが考えられる。

Q3. GitHub連携のCode reviewを有効にするには何が必要か

Codex cloudの設定を済ませ、Codex settingsから対象リポジトリのCode reviewをオンにする必要がある。この操作には、対象のGitHubリポジトリへのpush権限またはadmin権限が必要になる。

Q4. Automatic reviewsをオンにすると何が変わるか

@codex reviewのメンションを都度投稿しなくても、そのリポジトリに作られるすべてのPull Requestが自動的にレビュー対象になる。

Q5. セキュリティだけに絞ってレビューさせることはできるか

Pull Requestのコメントで@codex security reviewとメンションすると、セキュリティの観点に絞ったレビューを依頼できる。

Q6. Codexのコードレビューがあればテストやブランチ保護は不要になるか

不要にはならない。公式ドキュメントもコードレビュールールはテスト・ブランチ保護・必須の承認の代わりにはならないと明記しており、既存の仕組みと併用する前提の機能になる。

Q7. Codexのコードレビュー機能はどのプランで使えるか

この記事で参照した公式ページには、Codex cloudの設定とGitHubリポジトリへの権限という前提は記載されているが、利用できるプランの範囲までは明記されていなかった。プラン別の詳細はChatGPT料金プラン完全比較｜Free・Go・Plus・Pro・Businessの違いと選び方で確認したうえで、実際の設定画面で自分のアカウントに表示されるかどうかを確認してほしい。

Q8. レビューペインの表示モードはどう使い分ければよいか

普段の確認は既定のUnstaged changesのままでよく、Codexに続けて何度も修正させたあとの見直しにはLast turnで直近の変更だけに絞り、コミット単位で振り返りたいときはCommitやBranchに切り替える、という使い分けが考えられる。

まとめ

Codexのコードレビュー機能は、composerから呼び出すローカルの/reviewコマンドと、GitHub連携で使う@codex review・Automatic reviews・@codex security reviewという、性質の異なる2系統から成り立っている。ローカルのレビューは作業ツリーを変更せずに優先度付きの指摘を返し、GitHub連携のレビューはPull Request上にP0・P1に絞ったコメントを投稿する。

どちらもテストやブランチ保護を置き換えるものではなく、AGENTS.mdのCode Review Rulesで基準をカスタマイズしながら、既存のチェック体制に組み込んで使う機能だと理解しておくと、導入後の運用イメージを描きやすい。