CodexでGitHubのコードレビューを始める手順と、導入するメリット

はじめに

コードを書いた後、自分で読み返してからレビューを依頼する。それでも、条件分岐の抜けや、既存処理への影響を見落とすことはあります。

そこで、レビューの一工程として取り入れたいのが、Codexによるコードレビューです。

この記事では、GitHubのプルリクエストにCodexのレビューを追加する手順と、チームで運用する際のポイントを紹介します。

ここで扱うのは、Gitで管理しているコードの変更を、GitHub上でレビューする方法です。

本記事は2026年11月5日に確認した公式ドキュメントをもとにしています。利用できる機能や設定画面は、契約・権限・更新によって異なる場合があります。

1. Codexのコードレビューでできること

Codexは、プルリクエストの差分や関連するコード、リポジトリ内の指示を参照し、GitHub上にレビューを投稿します。

公式ドキュメントでは、重大な問題に焦点を当てるレビューとして説明されています。OpenAI公式ドキュメント：GitHubのコードレビュー

例えば、レビューで確認したい観点には、次のようなものがあります。

• 条件分岐によって、一部のケースだけ誤動作しないか
• 空の値や想定外の入力で問題が起きないか
• 権限の確認が抜けていないか
• 既存の呼び出し元に影響する変更がないか

ただし、すべての不具合を検出できるわけではありません。テストや人によるレビューと組み合わせて利用します。

2. 導入前に用意するもの

以下を用意します。

• レビュー対象のGitHubリポジトリ
• Codexを利用できるアカウント
• Codexのコードレビュー設定へアクセスできる環境
• GitHub連携に必要な権限

自動レビューの設定には、公式ドキュメント上、対象リポジトリに対するpush権限または管理者権限が必要です。

会社のコードを扱う場合は、ソースコードを外部サービスで処理してよいか、組織のルールを確認します。接続時には、許可するリポジトリとアクセス範囲も確認してください。

3. GitHubリポジトリをCodexに接続する

CodexのGitHub連携画面から、対象リポジトリを接続します。

組織のリポジトリを使う場合は、GitHub側で管理者の承認が必要になることもあります。

接続後は、Codexのコードレビュー設定を開き、対象リポジトリでコードレビューを有効にします。

最初は、チームで内容を把握しやすい小さな変更を使い、手動でレビューを依頼すると確認しやすくなります。

4. プルリクエストからレビューを依頼する

GitHubでプルリクエストを作成し、コメント欄に次の内容を投稿します。

@codex review

Codexが反応し、レビュー処理の後に結果を投稿します。このコメントが、公式に案内されているレビューの依頼方法です。レビュー依頼の公式手順

プルリクエストの本文には、変更の背景も記載しておきます。

## 変更の目的
注文一覧で、検索結果が0件の場合にエラーになる問題を修正する。

## 期待する動作
該当する注文がない場合は、空の一覧を表示する。

## 確認内容
・検索結果が0件
・検索結果が1件
・検索条件が未入力

これはチーム内のレビューにも役立ちます。コードの差分だけでは分かりにくい「なぜ変更したか」を共有できるためです。

5. AGENTS.mdにチームの確認観点を書く

プロジェクト固有のルールを伝えたい場合は、リポジトリに AGENTS.md を配置します。

公式ドキュメントでは、## Code Review Rules セクションにレビューのルールを書く方法が案内されています。レビュー観点の設定方法

例えば、組織ごとのデータを扱うWebシステムなら、次のように記載します。

## Code Review Rules

### データのアクセス権限
- 組織にひもづくデータの取得・更新では、
  ログインユーザーの所属組織による制限を確認してください。
- 管理者向けの組織横断処理は、管理者権限が検証されている場合に限り許可します。

### APIの互換性
- 既存APIのレスポンス項目の削除や型変更は、
  呼び出し元への影響と移行方法を確認してください。

### ログ
- パスワード、認証トークン、APIキーを
  ログへ出力する変更を指摘してください。

リポジトリ全体に共通するルールはルートに、特定の機能にだけ適用するルールは、その配下の AGENTS.md に書けます。

すでにファイルがある場合は、内容を確認して追記します。

最初から大量に書くより、繰り返し指摘している重要な観点を2〜3個選ぶと、結果を評価しやすくなります。

なお、整形やLintなど機械的に判定できる項目は、CIで確認する方が適しています。

6. 運用が決まったら、自動レビューを有効にする

毎回コメントする運用が定着したら、自動レビューも検討します。

公式ドキュメントでは、コードレビュー設定の対象リポジトリと、個人設定の Automatic review を確認し、Review trigger で実行タイミングを選ぶ手順が案内されています。自動レビューの公式手順

設定後は、対象のプルリクエストでレビューが実行されるか確認します。

動かない場合は、次の点を確認してください。

• 対象リポジトリがCodexに接続されているか
• リポジトリでコードレビューが有効か
• 個人設定で自動レビューが有効か
• プルリクエストの操作が設定した実行条件に合っているか
• 利用枠や組織の制限に問題がないか

7. 導入することで期待できるメリット

人に依頼する前に、修正候補を確認できる

Codexの指摘を先に確認すると、人のレビューに入る前に問題を修正できる可能性があります。

人のレビューでは、仕様の妥当性や設計の意図など、チームで議論したい内容に時間を使いやすくなります。

一人で開発している場合も、別の観点を得られる

一人で書いていると、「この値は必ず入る」「この処理は一度しか呼ばれない」といった前提を見落としがちです。

AIの指摘をきっかけに、その前提がコードやテストで保証されているかを見直せます。

レビューの観点をチームに残せる

AGENTS.md に業務上の制約を書くことで、担当者の頭の中にあった確認事項を共有できます。

新しく参加したメンバーも、プロジェクトで何を重視しているかを理解しやすくなります。

指摘の理由を調べることが学習につながる

指摘されたコードについて、「どの入力で問題が起きるのか」「既存のテストで検出できるか」を調べると、実装への理解が深まります。

修正する場合も、提案をそのまま採用するのではなく、再現条件と期待する動作を確認することが大切です。

8. 指摘なしでも、そのままマージしない

Codexのレビュー結果は、マージを判断する材料の一つです。

指摘がなかったとしても、仕様への適合や安全性が保証されたわけではありません。反対に、指摘が既存の仕様に合わない場合もあります。

運用では、次の流れがおすすめです。

1. Codexの指摘と根拠を読む
2. 関連コードや仕様を確認する
3. 必要に応じてテストで再現する
4. 修正後にテストとレビューを行う
5. チームの承認ルールに従ってマージする

効果を確認する際は、コメント数だけでなく、採用した有効な指摘や、レビューの往復回数、確認にかかった時間も見ます。

おわりに

Codexのコードレビューは、既存のGitHubの開発フローに、変更内容を確認する機会を追加できます。

まずは一つのリポジトリで @codex review を試し、指摘を評価しながら AGENTS.md に確認観点を整える。その後、必要に応じて自動レビューへ広げると、チームに合った運用を作りやすくなります。