2026/06/08Codex

Skills活用AI活用導入・運用

Codexでコードレビューを自動化｜PR前チェックの実務

AI生成コードが増えてきて、レビューの負荷が無視できなくなっていませんか。生成スピードは上がったのに、それを人間が一行ずつ確認する工程がボトルネックになり、結局「誰もちゃんと見ていないコード」がマージされてしまう。小規模チームほどこの問題は深刻です。

結論から言うと、Codex（GPT-5.5）にコードレビューの「一次チェック」を任せ、人間は最終承認に集中する分業が現実的です。バグ・規約違反・セキュリティ観点の機械的なチェックはCodexが拾い、人間は設計判断と最終的なマージ可否に時間を使う。これでレビューの総量を減らせます。

株式会社Fyveは、AI業務効率化の受託開発と専属AI活用顧問サービスを提供しています。代表の田嶋自身、Codexを日々の開発で一次レビューに組み込んでいます。この記事では、私たちが実務で使っているCodexコードレビューのワークフローを、頼み方からCI連携、AI生成コードの承認ルールまで具体的に整理します。

Codexのコードレビューは「3つの場所」で動く

Codexのコードレビューは、コードがマージされるまでの異なる地点で使えます。OpenAIの公式ドキュメントでは、ターミナル（コミット前）、GitHubのプルリクエスト（PR）、CI/CDパイプラインの3か所が想定されています。

この3つは役割が違います。手元での素早い確認、チーム全体に見えるPRレビュー、機械的なゲートとしてのCI。どれか1つではなく、開発フローのどの段階で何を拾いたいかで使い分けるのが実務的です。

ターミナル（コミット前）: Codex CLIの /review コマンドで、手元の変更を即チェック。作業ツリーは変更しない
GitHub PR: PRのコメントで @codex review と書く、または自動レビューを有効化。差分を読んでGitHubの通常レビューとして指摘を投稿する
CI/CDパイプライン: openai/codex-action を使い、ワークフローの一部としてレビューを実行・ゲート化する

いずれも「人間レビューの置き換え」ではなく「人間レビューの前段にフィルタを1枚足す」発想で導入するのが失敗しにくいやり方です。

ターミナルでのコミット前レビュー（/review）

いちばん手軽なのが、Codex CLIの /review コマンドです。コミットやPRを作る前に、手元の差分をCodexに見てもらう使い方です。公式ドキュメントによると、このコマンドは作業ツリーを書き換えず、レビュー指摘だけを返します。

頼み方はシンプルです。Codex CLIを起動して、こう打ってください。

「/review でステージ前後の変更を見て、バグとエッジケースの観点で指摘して」 — 未コミットの変更（ステージ済み・未ステージ・未追跡）をまとめて確認
「/review でこのブランチをmainとの差分でレビューして、リスクの大きい順に出して」 — ベースブランチとのマージベースを取って差分をレビュー
「/review で直近のコミットを選んで、その変更セットだけ見て」 — 特定のSHAの変更だけを対象にする

カスタム指示も渡せます。たとえば「アクセシビリティの後退だけに絞ってレビューして」のように観点を限定すると、その観点でレビュアーが走ります。各レビューはトランスクリプト上で独立した1ターンとして残るので、コードを直しながら何度も回して指摘の変化を比較できます。

私たちが実務で重視しているのは、この /review を「コミット前のクセ」にすることです。人間がPRを開く前に一度Codexに通しておくと、明らかなバグやnullチェック漏れ、握りつぶした例外などが先に潰れます。PRレビュアーが本質的な設計の話に集中できるようになります。

GitHubのPRレビューを自動化する

チーム開発なら、PR段階でCodexを噛ませる構成が効きます。OpenAIの公式ドキュメントでは、2つのトリガー方法が用意されています。

自動レビュー: Codexの設定で自動レビューをオンにすると、新しいPRが開かれるたびに @codex review コメント不要でレビューが投稿される
オンデマンドレビュー: PRのコメントに @codex review と書くと、Codexが反応（👀）してレビューを投稿する。チームメンバーがレビューするのと同じ形でコメントが付く

Codexは差分を読み、リポジトリのガイダンスに従って、重大な問題に絞ったレビューをGitHubの標準的なレビューとして投稿します。ここで重要なのが「重大な問題に絞る」という挙動です。公式ドキュメントによると、GitHub上では既定でP0・P1の指摘だけが表示されます。コードスタイルやドキュメントの不足といった低重要度の項目を出したい場合は、後述のAGENTS.mdで明示的に格上げする必要があります。

運用のコツは、自動レビューをいきなり全PRに効かせないことです。最初はオンデマンド（@codex review）で試し、指摘の質とチームの受け止め方を見てから自動化に切り替えると、ノイズで疲弊せずに済みます。

CI/CDに組み込んでゲートにする

「レビューを通っていないコードはマージさせない」を機械的に担保したいなら、CIに組み込みます。OpenAIが提供する openai/codex-action（GitHub Action）を使うと、CI/CDジョブの中でCodexを実行できます。

このアクションは、Codex CLIをインストールし、APIキーを渡すとResponses APIのプロキシを起動して、指定した権限の下で codex exec を走らせる、という流れで動きます。これにより、PRやリリースに対するCodexのフィードバックをCLIを自分で管理せずに自動化したり、Codex主導の品質チェックを通過条件（ゲート）として課したりできます。

GitHub以外でも構築できます。Codex CLIのヘッドレスモードを使えば、GitHub Actionsだけでなく、GitLab CI/CD、Azure DevOps Pipelines、Jenkinsでも独自のコードレビューパイプラインを組めます。クラウドのホスト型レビューと同じプロセスを、自社のCIランナー上で再現する構成です。

ワークフローファイルに書く頼み方のイメージはこうです。「PRの差分をレビューし、P0/P1の指摘があればジョブを失敗させる」。これでレビュー指摘が出たPRは自動的に赤くなり、人間が確認するまでマージできない状態を作れます。実装の細かいパラメータは更新が早いので、最新の公式情報で確認してください。

AGENTS.mdでレビュー基準を揃える

Codexのレビュー品質を左右するのが AGENTS.md です。公式ドキュメントによると、Codexはリポジトリ内の AGENTS.md を探し、その中の「Review guidelines（レビュー基準）」セクションに従います。変更されたファイルにいちばん近い AGENTS.md が優先されるので、リポジトリのルートから個別パッケージまで段階的に基準を重ねられます。

ここに自社の規約を書いておくと、レビューが属人化しません。たとえば次のような項目を書きます。

命名規則・ディレクトリ構成のルール（「snake_caseとcamelCaseの混在はP1として扱う」）
禁止事項（「環境変数を直接ハードコードしない」「any型を新規追加しない」）
セキュリティ観点（「ユーザー入力を未検証でクエリに渡さない」）
重要度の格上げ指示（既定で隠れる低重要度の指摘を出したい場合）

AGENTS.md は単独で頑張らせず、pre-commitフック・リンター・型チェッカーといった仕組みと組み合わせるのが定石です。機械的に潰せる問題はそれらのツールで先に弾き、Codexには人間に近い文脈判断を任せる。役割を分けることで、レビュー全体が再発防止に向かって賢くなっていきます。

AI生成コードを人間がどう承認するか

Codexを一次レビューに使ううえで、いちばん大事なのは技術ではなく「承認の文化」です。AIがレビューし、AIが生成したコードを、最終的に誰が責任を持ってマージするのか。ここを曖昧にすると、レビューを自動化したのに品質が落ちる、という本末転倒が起きます。

私たちが実務で守っているのは、シンプルな原則です。

最終承認は必ず人間が行う: Codexの指摘がゼロでも、人間がマージボタンを押す。AIは「指摘を出す係」であって「承認する係」ではない
Codexの指摘は「採用・却下」を明示する: 全部を鵜呑みにせず、的外れな指摘は理由を添えて却下する。誤検知（フォールスポジティブ）は必ず出るという前提で運用する
生成コードほど人間の目を厚くする: AIが書いたコードは「動くが意図とずれている」ことがある。テストとレビューの両方で意図の一致を確認する
レビュー観点をAGENTS.mdに資産化する: 人間が何度も指摘していることは基準ファイルに書き、次回からCodexに拾わせる

GPT-5.5はコードレビューの精度・一貫性において推奨モデルとされていますが、それでも判断の最終責任は人間にあります。レビューの「量」を減らすためにCodexを入れる。減らした分の余力を、人間にしかできない設計判断と最終承認に振り向ける。この線引きを最初にチームで合意しておくことが、自動化を成功させる前提条件です。

小規模チームでの導入ステップ

開発を持つ小規模チームが無理なく始めるなら、段階を踏むのがおすすめです。いきなり全PR自動レビュー＋CIゲートまでやると、ノイズと運用負荷で続きません。

ステップ1: 各メンバーがコミット前に /review を回す習慣をつける。個人レベルで効果を体感する
ステップ2: AGENTS.md に自社のレビュー基準を3〜5項目だけ書く。最初から完璧を目指さない
ステップ3: 重要なリポジトリでオンデマンドの @codex review を試す。指摘の質を見ながら基準を育てる
ステップ4: 質が安定したら自動レビューをオンにする。さらにCIゲート化を検討する

このように小さく始めて、効いている手応えが出てから広げる。AI活用全般に言えることですが、ツールを入れること自体ではなく、チームのワークフローに馴染ませることが成果を分けます。

よくある質問

CodexのコードレビューはどのモデルでもCodexを使えますか

OpenAIの公式情報では、コードレビューの精度・一貫性が最も高いモデルとしてGPT-5.5が推奨されています。複雑なコーディングワークフロー向けの推奨モデルもGPT-5.5です。利用可能なモデルやプランは更新されるため、最新の公式情報で確認してください。

Codexのレビューは人間のレビューを完全に置き換えられますか

置き換えではなく一次チェックとして使うのが現実的です。Codexはバグ・エッジケース・規約違反などを機械的に拾うのは得意ですが、設計判断やビジネス文脈を踏まえた最終承認は人間の役割です。誤検知も出るため、指摘の採用・却下を人間が判断する前提で運用してください。

@codex review と自動レビューはどう違いますか

@codex review はPRコメントで都度トリガーするオンデマンド方式です。自動レビューはCodexの設定でオンにすると、新しいPRが開かれるたびにコメント不要でレビューが投稿されます。最初はオンデマンドで試し、質を確認してから自動レビューに切り替えるのが安全です。

レビュー基準を自社ルールに合わせられますか

リポジトリに AGENTS.md を置き、その中にレビュー基準を書くことで合わせられます。Codexは変更ファイルにいちばん近い AGENTS.md を優先します。既定ではP0・P1の重大な指摘のみ表示されるため、コードスタイル等の低重要度項目を出したい場合は基準ファイルで明示的に格上げしてください。

GitHub以外のCIでも使えますか

使えます。GitHubでは openai/codex-action が公式に提供されています。それ以外でも、Codex CLIのヘッドレスモードを使えばGitLab CI/CD、Azure DevOps Pipelines、Jenkinsなどで独自のレビューパイプラインを構築できます。

コミット前にローカルだけでレビューしたい場合は

Codex CLIの /review コマンドを使ってください。作業ツリーを書き換えず、未コミットの変更・ベースブランチとの差分・特定コミットのいずれかを対象にレビューできます。「バグとエッジケースに絞って」のように観点を指定して頼むこともできます。

小規模チームでも導入する価値はありますか

むしろ小規模チームほど効果が出やすい領域です。専任のレビュー担当を置けないチームでは、一次チェックを自動化することでレビュー負荷を大きく下げられます。コミット前の /review から小さく始め、徐々にPR・CIへ広げる進め方がおすすめです。

まとめ

Codex（GPT-5.5）のコードレビューは、ターミナル（コミット前）・GitHub PR・CI/CDの3か所で使える
コミット前は /review コマンドで手元の差分を即チェックできる（作業ツリーは変更しない）
PRは @codex review のオンデマンド、または自動レビューでトリガーする。既定ではP0・P1の重大な指摘のみ表示される
CI/CDには openai/codex-action で組み込み、レビュー指摘を通過ゲートにできる。GitLab・Azure DevOps・Jenkinsでも構築可能
AGENTS.md に自社のレビュー基準を書くと、レビューが属人化せず再現性が高まる
Codexは一次チェック係。最終承認は必ず人間が行い、誤検知を前提に指摘の採用・却下を判断する
小規模チームは /review から小さく始め、PR・CIへ段階的に広げると失敗しにくい

レビューの自動化は「人間が見なくていい」ためではなく、「人間が本質に集中する」ために導入します。この線引きが、AI生成コード時代のレビュー文化の核になります。

Codex CLIの全機能をまず把握したい方は、こちらの完全ガイドが入口になります。