CodexのGitHub連携 PRレビュー自動化の設定手順とレビュー基準の作り方

レビュー待ちでプルリクエストが滞る、指摘が人によってばらつく。開発チームの規模が大きくなるほど、こうした詰まりは目立ってきます。

CodexのGitHub連携は、この一次チェックを引き受ける仕組みです。プルリクエストの差分を読み、重大度の高い箇所に絞ってコメントを返します。GitHub Actionsの追加設定は必要ありません。

ここでは公式ドキュメントにもとづき、連携の設定手順から依頼方法、指摘内容を自社基準に合わせるやり方、そして公式連携が使えない場合の代替まで整理します。

確認したいポイント	結論	詳細
GitHub連携で何ができる？	PRの差分を自動でレビューできる	重大度の高い指摘に絞ってGitHub上にコメントが投稿される。修正や他の作業を依頼することもできる
設定手順は？	接続してレビューを有効にする	Codex cloudでリポジトリを接続し、設定画面でCode reviewをオンにする。GitHub Actionsの追加は不要
指摘の内容は変えられる？	AGENTS.mdにルールを書く	Code Review Rulesという見出しで観点を書くと、リポジトリ固有の基準に沿った指摘が返るようになる
動かないときは？	接続と設定と表記を順に確認	Code reviewが有効か、Codex cloudが設定済みか、記法が正確かを確認すると原因が絞り込める

この記事でわかること

• GitHub連携でCodexに任せられる範囲と、任せられない範囲
• Codex cloudの接続からレビュー有効化までの具体的な手順
• 手動依頼と自動レビューの使い分け、観点を指定した依頼の書き方
• AGENTS.mdにレビュー基準を書いて、指摘の質をそろえる方法
• 公式連携が使えない環境でGitHub Actionを使う場合の権限設計

▼ 開発フローへのAI組み込みを検討中の方へ レビューを自動化しても、どこまで任せてどこから人が見るかが決まっていなければ運用は回りません。 ネクストスケールでは、開発フローの整理から仕組みの定着まで一貫して支援しています。 ▶ 無料相談はこちら（株式会社ネクストスケール）

CodexのGitHub連携でできることはPRレビューと作業依頼

まず、何をどこまで任せられるのかを押さえておきます。ここを誤解したまま導入すると、期待とのずれが生まれます。

PRの差分をレビューして指摘を返す

中心となる機能は、プルリクエストの差分に対するレビューです。 Codexは変更内容を読み、リポジトリ側の方針に従ったうえで、通常のコードレビューと同じ形でGitHub上にコメントを投稿します。

コードを貼り付けて相談する使い方と違うのは、リポジトリ全体を踏まえたうえで差分を見る点です。変更の前後関係や既存の実装との整合まで含めて確認できます。

レビュー依頼が投げられると、まず絵文字による反応が付き、そのあと結果が投稿されます。反応があれば処理は始まっているので、しばらく待てば結果が返ります。

指摘がP0とP1に絞られる理由

GitHub上でCodexが指摘するのは、重大度の高いものに限られます。公式ドキュメントでは、優先度の高いリスクに集中させるためにP0とP1相当の問題だけを挙げる、と説明されています。

この設計は実務では利点になります。細かな指摘が大量に並ぶと、本当に見るべき箇所が埋もれるためです。書式や命名の揺れといった機械的に判定できる項目は、静的解析の側に任せる前提になっています。

裏を返せば、コード全体の品質を保証するものではありません。差分から読み取れる高リスク箇所を拾う仕組みとして扱うのが正しい位置づけです。

レビュー以外の作業も頼める

コメント欄でCodexに触れる形で依頼できるのは、レビューだけではありません。レビュー以外の指示を書くと、そのプルリクエストを文脈としたクラウド上の作業が始まります。

たとえばビルドの失敗を直してほしい、といった依頼が可能です。権限が与えられていれば、修正をブランチへ反映するところまで行えます。

デスクトップアプリという提供形態そのものについてはCodex appとは、エージェント型ツール全般の考え方はAIエージェントとは何かで扱っています。

関連記事：Claude Codeの連携方法まとめ｜MCP・GitHub・Slack連携の設定手順と注意点を解説

GitHub連携の設定手順は3ステップで完了する

設定は難しくありません。つまずくとすれば、前提条件の確認漏れです。

事前に必要なもの

公式ドキュメントが挙げている前提は次の3点です。

• レビュー対象のリポジトリについて、Codex cloudが設定済みであること
• レビュー設定の画面にアクセスできる権限があること
• リポジトリ固有の基準に沿わせたい場合は、AGENTS.mdが用意されていること

自動レビューまで設定する場合は、GitHub側でそのリポジトリに対する書き込みまたは管理者の権限が必要です。 権限が足りないと設定画面まで進めないため、先に確認しておくと手戻りがありません。

Codex cloudとリポジトリを接続する

最初にCodex cloudの設定から対象のリポジトリを接続します。初回はGitHub側で連携を承認する操作が入ります。

組織のリポジトリを扱う場合、管理者の承認が必要になることがあります。また、アクセス範囲を限定する設定になっていると対象が一覧に出てこないため、その場合はGitHub側で対象リポジトリを追加してください。

設定画面でCode reviewを有効にする

接続が済んだら、Codexの設定画面でレビュー機能を有効にします。この切り替えはリポジトリごとに行えるため、まずは影響の小さいリポジトリから試すという進め方ができます。

ここまでで準備は完了です。GitHub Actionsのワークフローを追加する必要はありません。既存のCI設定に手を入れずに始められる点は、導入のハードルを下げる要素になります。

設定画面の項目と最新の手順はCodex公式ドキュメントのGitHub連携ページに掲載されています。更新が続く領域のため、導入時は一次情報を確認してください。

▼ 情報システム部門との調整でお困りの方へ 外部サービスにリポジトリを接続する判断は、開発チームだけでは決められないことがほとんどです。 承認を得るための整理資料づくりから、ご相談いただけます。 ▶ 無料相談はこちら（株式会社ネクストスケール）

関連記事：Claudeのプロジェクト機能の使い方｜作成手順・ナレッジ設定・活用例をわかりやすく解説

レビューの依頼方法は手動と自動の2通りある

依頼の仕方は2つあり、どちらを選ぶかでレビューの走る量が大きく変わります。

コメントで依頼する

手動で頼む場合は、プルリクエストのコメント欄に次のように書きます。

@codex review

表記は正確に合わせる必要があります。 言い回しを変えると別の依頼として解釈され、レビューではなく通常の作業として処理されることがあります。

依頼後は絵文字の反応を待ち、そのあと結果が投稿されるのを確認します。修正を反映したあとで再度レビューしてほしいときは、同じコメントをもう一度書けば再実行されます。

観点を指定して依頼する

一度きりの観点を足したいときは、依頼文に続けて書けます。データベースの移行部分を重点的に見てほしい、権限まわりの抜けを確認してほしい、といった指定です。

変更の性質に応じて観点を切り替えられるため、リスクの高い箇所を含むプルリクエストほど効果があります。 毎回同じ観点を書いているなら、後述するルールとして残したほうが手間は減ります。

自動レビューを有効にする

すべてのプルリクエストを対象にしたい場合は、設定画面で自動レビューを有効にします。有効にすると、レビュー用にプルリクエストが開かれるたびに、依頼のコメントなしでレビューが投稿されます。

ただし、対象が広がるぶん投稿数も増えます。チームの規模や、依存関係の更新のような自動生成されるプルリクエストの量を踏まえて、有効にするか判断してください。 最初は手動から始め、必要に応じて切り替える形が無難です。

生成量が増える前提で開発を回す進め方についてはバイブコーディングの進め方でも触れています。

関連記事：Claude CodeとCursorの違いを比較｜料金・機能・使い分けと併用方法を解説

レビュー基準はAGENTS.mdに書いて共有する

初期状態でも一般的な観点でのレビューは返りますが、自社固有の事情までは反映されません。ここを埋めるのがレビュールールの記述です。

Code Review Rulesの書き方

Codexはリポジトリ内のAGENTS.mdを探し、そこに書かれたレビュー用のルールに従います。 記述する際は、専用の見出しを立てて内容をまとめます。

## Code Review Rules

関連する観点をまとめたいときは、さらに小見出しで区切ります。レビュアーが口頭で毎回説明しているような内容を、2つか3つ書くところから始めるのが公式の勧めです。

良いルールの4つの条件

公式ドキュメントが挙げている条件は次のとおりです。

• 影響の大きい、そのリポジトリ固有の挙動に絞る。互換性の制約やデータの境界、危険な副作用を、なぜ問題なのかとあわせて書く
• 安全な進め方や例外を書き添える。本当の問題と、想定どおりの挙動を区別できる材料を渡す
• 範囲を絞り、長く使える形で書く。変わりやすい関数名ではなく結果で書き、ルールは対象のコードの近くに置く
• 機械的なチェックはCIに残す。書式や静的解析のような判定が一意に決まるものは、レビュー基準に混ぜない

最後の条件は見落とされがちです。 形式的なチェックまでレビュー基準に含めると指摘が増えすぎ、本当に見たい観点が埋もれます。

ルールの置き場所と階層

リポジトリ全体に効かせたいルールは直下のAGENTS.mdに、特定のサービスだけの決まりはそのディレクトリ配下のファイルに書きます。

Codexは、変更されたファイルに関係する範囲のルールを適用します。関係のない変更にまで、特定サービス向けの前提が持ち込まれることはありません。

運用の始め方としては、代表的なプルリクエストを1つ選んでレビューを走らせ、返ってきた指摘を見ながら調整するのが確実です。雑音になっているルールは、絞り込むか削除します。

AGENTS.mdの基本的な書き方はCodexの使い方で扱っています。なお、レビュー基準はテストやブランチ保護、必須の承認を置き換えるものではない点も、公式が明記しています。

▼ レビュー品質のばらつきに悩んでいる方へ 属人的なレビュー観点は、担当者が変わるたびに揺れます。基準をファイルとして残す設計が有効です。 自社の開発規約をルール化するところから、お手伝いします。 ▶ 無料相談はこちら（株式会社ネクストスケール）

指摘への対応とセキュリティ観点のレビュー

レビューが返ってきたあと、どう扱うかまで決めておくと運用が回ります。

修正まで任せる

指摘された内容の修正も、同じプルリクエスト上で依頼できます。コメントで対象を指定して頼むと、そのプルリクエストを文脈としたクラウド上の作業が始まります。

権限が与えられていれば、修正内容をブランチへ反映するところまで行われます。 指摘を読んで、直して、また確認するという往復が1つの画面で完結します。

ただし、すべての指摘を機械的に直させるのは避けてください。想定どおりの挙動を問題として挙げている場合もあるため、判断は人が行う前提を崩さないことが重要です。

セキュリティ観点のレビュー

通常のレビューとは別に、セキュリティに重点を置いたレビューも用意されています。差分に加えてリポジトリの文脈や設定された脅威モデルを踏まえ、より踏み込んで確認します。

設定画面から、どのプルリクエストを対象にするか、いつ実行するかを選べます。通常のレビューと同時に走らせる指定も可能です。なお、この機能は研究プレビューとして提供されている段階です。

生成AIを開発工程に組み込む際の情報管理の考え方は生成AI利用時のセキュリティ対策で整理しています。

レビューは承認ではない

押さえておきたいのは、Codexがレビューを投稿することと、変更を承認することは別だという点です。自動レビューを有効にしても、それ自体が自動承認になるわけではありません。

マージの判断は人が持ち続ける前提で設計してください。 ブランチ保護や必要な承認数の設定は、これまでどおり運用します。

公式連携が使えない場合はGitHub Actionという選択肢がある

自社運用のGitHub Enterpriseを使っている、実行環境を自分たちで管理したい。そうした事情がある場合は、CIの中でCodexを動かす方法があります。

専用のアクションでできること

公式から提供されているGitHub Action（openai/codex-action）を使うと、ワークフローの中でCodexを実行できます。内部でCLIを導入し、指定した権限のもとで処理を走らせる仕組みです。

想定されている用途として挙げられているのは次のような場面です。

• CLIの管理を自分たちで行わずに、プルリクエストへの指摘を自動化したい
• CIの一部として、Codexによる品質チェックを通過条件にしたい
• レビューやリリース準備、移行作業といった定型処理をワークフローから実行したい

指示はワークフローに直接書くほか、リポジトリ内のファイルとして用意して参照させることもできます。チームで内容を管理したい場合は後者が向きます。

権限の絞り方

この方式では、実行環境における権限の設計が重要になります。既定では管理者権限を落としたうえでCodexが動く設定になっており、これによりAPIキーが読み取られるのを防いでいます。

さらに、専用の利用者として実行する指定、ファイルの変更やネットワーク利用を止める指定、サンドボックスの範囲を絞る指定なども用意されています。作業が成立する範囲で、最も狭い設定を選ぶのが原則です。

誰がワークフローを起動できるかも制御できます。既定では書き込み権限を持つ利用者に限定されるため、必要に応じて追加する形になります。

セキュリティ上の確認事項

公式が挙げている確認項目のうち、社内で決めておきたいのは次の点です。

• 起動できる利用者を限定し、誰でも実行できる状態にしない
• プルリクエストの本文やコミットメッセージから指示を組み立てる場合、内容を検査する
• APIキーを保護する設定を外さない。共有の実行環境で無防備な設定にしない
• Codexの実行は処理の最後に置き、後続の工程が影響を受けないようにする

2つ目は特に注意が必要です。外部から書き込める内容をそのまま指示に混ぜると、意図しない操作を引き起こす経路になり得ます。 隠し文字やコメントの形で埋め込まれる可能性も踏まえて確認してください。

設定項目の詳細は公式のGitHub Actionのドキュメントにまとまっています。

▼ 自社環境に合わせた構成を検討したい方へ 公式連携とCI方式のどちらが適しているかは、リポジトリの管理形態とセキュリティ要件で決まります。 要件の整理から構成案の作成まで、あわせてご相談ください。 ▶ 無料相談はこちら（株式会社ネクストスケール）

動かないときの確認と社内展開の進め方

設定したのに反応がない、という状況は起こります。確認の順序を知っておくと、原因の切り分けが早く済みます。

レビューが返ってこないときの確認

公式が挙げている確認項目は4つです。

• 対象のリポジトリでレビュー機能が有効になっているか
• そのリポジトリでCodex cloudの設定が完了しているか
• 依頼のコメントが、決められた表記どおりになっているか
• 自動レビューの場合、設定が有効で、対象とする条件に合致しているか

あわせて、GitHub側のアプリケーション設定で対象リポジトリへのアクセスが許可されているかも確認してください。組織で範囲を限定している場合、ここで止まっていることがあります。

公開リポジトリでの注意

公開しているリポジトリでは、外部の利用者からもコメント経由でレビューを起動できてしまう可能性があります。意図しない実行を避けたい場合は、対象を限定して導入するのが安全です。

実行の条件を細かく制御したい要件があるなら、前述したCIでの実行方式を検討する余地があります。誰がどの条件で起動できるかを、自分たちの側で決められるためです。

チームへの広げ方

独立行政法人情報処理推進機構のDX動向2025では、日本企業の85.1%でDXを推進する人材が不足していると報告されています。レビュー体制の負荷は、人員の制約と直結する課題です。

導入の順序としては、まず1つのリポジトリで手動依頼から始め、返ってくる指摘の質を見ながらレビュールールを整えます。そのうえで自動レビューに切り替え、対象を広げていくのが手戻りの少ない進め方です。

効果を測る指標も先に決めておきます。レビュー開始までの待ち時間、差し戻しの回数、マージまでの日数といった、導入前後で比較できる数字を置いておくと判断がぶれません。

組織全体の底上げは法人向け生成AI研修、他社ツールとの比較検討はClaude Codeのインストール方法、外部ツールとの連携規格はMCP（Model Context Protocol）とは、コードベースの解析を効率化する具体例はSerena MCPの導入方法でそれぞれ扱っています。

まとめ

CodexのGitHub連携は、プルリクエストの差分を読んで重大度の高い指摘を返す仕組みです。Codex cloudでリポジトリを接続し、設定画面でレビューを有効にすれば使い始められます。GitHub Actionsの追加は必要ありません。

依頼はコメントによる手動と、プルリクエストごとの自動の2通りです。指摘の内容を自社の事情に合わせたい場合は、AGENTS.mdにレビュー用のルールを書きます。影響の大きい観点に絞り、機械的なチェックはCIに残すのがこつです。

自社運用の環境などで公式連携が使えない場合は、CIの中でCodexを動かす方式があります。いずれの形でも、レビューの投稿と承認は別であり、マージの判断は人が持ち続ける前提で設計してください。

▼ AI開発環境の整備をご検討中の方へ レビューの自動化は、開発フロー全体をどう組み替えるかという設計と一体で考える必要があります。 現状の課題整理から運用の立ち上げまで、まずは無料相談でお聞かせください。 ▶ 無料相談はこちら（株式会社ネクストスケール）