CodexとGitHubを連携すると、プルリクエスト（PR）のコメントに@codex reviewと書いてレビューを頼んだり、設定に応じて自動でレビューさせたり、指摘の修正を同じPRで頼んだりできます。ただ、OpenAIの資料はこの流れを6ページ以上に分けて説明していて、どの入口に何が要るか、チームの誰が何を設定するかが一度に見えません。この記事では、入口ごとの違いと設定の分担を表にまとめ、頼み方と注意点を説明します。
この記事は、OpenAIの開発者向けの公式資料（GitHub連携、Code review、Security Review、Codex Cloud、Pricingなど）と、OpenAIヘルプセンターの3つの記事に基づく解説です。いずれも2026年11月5日に確認しました。編集部は、GitHubのリポジトリで接続・@codex review・自動レビュー・@codex fixを試しておらず、この記事に実測の結果は含みません。表の切り方と、AGENTS.mdのルールの例は編集部が用意したものです。
なお、Googleで「Codex GitHub」と調べると上位に出るopenai/codexは、Codex CLIのソースコードを公開しているリポジトリです。この記事で扱う「GitHubとの連携」とは別物です。GitLabのマージリクエストで同じことをしたい場合は、GitLabでレビューする方法を見てください。GitHubの資料には、GitLab版で必要なWebhookやサービスアカウントの準備は出てきません。
CodexとGitHubの連携でできること：入口ごとの違い
GitHubに関係するCodexの入口を、この記事では8つに分けました。始める場所、要るもの、結果が出る場所、使う利用枠が入口ごとに違うので、まず全体を表にします。行の分け方は編集部の整理で、各行に根拠の公式資料を付けました。資料に書かれていない欄は「記載なし」としています。
| 入口 | 始める場所 | 要るもの（プラン・サインイン・環境） | 結果が出る場所 | 使う利用枠 | 根拠 | 詳しい説明 |
|---|---|---|---|---|---|---|
@codex review | PRのコメント | Plus・Pro・Business・Enterprise/Edu。ChatGPTでサインイン（APIキーは不可）。接続したリポジトリでコードレビューを有効にする。環境の要否は資料で割れる（下の表） | PRのレビュー（指摘はP0とP1だけ） | Code Reviewの利用枠 | GitHub Pricing Authentication | この記事 |
| 自動レビュー | Review triggerで選んだタイミング | 上の行と同じ。Automatic reviewをオンにする（リポジトリの設定にはpushかadminの権限） | PRのレビュー。Code Reviewプラグインにも出る | Code Reviewの利用枠 | GitHub Code review Pricing | この記事 |
@codex fixなど | PRのコメント | Plus・Pro・Business・Enterprise/Edu。ChatGPTでサインイン（APIキーは不可）。そのほかの前提は記載なし | Legacyのクラウドチャット。権限があればPRのブランチへ修正をプッシュ | 記載なし | GitHub Pricing | この記事 |
| Security Review | PRのコメントか自動 | Pro・Business・Enterprise・Edu（Plusは不可）。Codex cloudの設定と接続したリポジトリ（自動にはpushかadminの権限） | PRに閾値以上の指摘。全体はSecurity Report | 含まれる利用枠かChatGPTのクレジット | Security Review | この記事 |
| Cloudの作業 | ChatGPTのWeb・アプリ・スマホ | Plus・Pro・Business・Enterprise/Edu。ChatGPTでサインイン（APIキーは不可）。公開した環境 | 作業の画面からコミットかPR | プランの上限（手元より多く使うことがある） | Codex Cloud Pricing | Codex Cloudの記事 |
ローカルの/review | CLI・アプリ・IDE拡張 | Plus・Pro・Business・Enterprise/EduかAPIキー | 手元の画面 | プランの上限。APIキーならAPIの料金 | Code review Pricing | コードレビューの記事 |
| GitHub Actions | GitHubのワークフロー | APIキー（GitHubのシークレットに保存）。Pricingではcodex execはAPIキーでも可 | ワークフローの結果（PRへの投稿もワークフローで設定） | APIの料金 | GitHub Action Pricing | GitHub Actionsの記事 |
| Code Reviewプラグイン | デスクトップアプリ・Web | PRを見られるリポジトリのアカウント。PricingのPluginsの行はPlus・Pro・Business・Enterprise/Edu（APIキーは一部） | アプリの画面（チャットでの確認は投稿しない） | 記載なし（Pricingでは、GitHub以外で動かすレビューはふつうの上限） | Code review ヘルプ Pricing | この記事では扱わない |
Pricingの説明では、Code Reviewの利用枠を使うのはGitHub上でCodexがレビューした時だけで、手元やGitHub以外でのレビューはふつうの上限から引かれます。上限の確かめ方は上限の記事にあります。
この記事が中心に扱うのは、表の上の4行です。Cloudの作業・ローカルの/review・GitHub Actionsは右端の記事で説明しています。Code Reviewプラグインはアプリの中でPRを読み、レビューするための機能で、この記事では扱いません。
GitHubとの連携を使う前の条件：プラン・サインイン・リポジトリ
使い始める前に、まず次の3点を確かめます。
- プラン：入口ごとの対象プランは上の表のとおりです。FreeとGoはPricingの機能の表に載っていないため、ここでは使えるとも使えないとも書きません（料金は料金の記事）。
- サインイン：Authenticationによると、Codex cloudにはChatGPTでのサインインが必要です。メールアドレスとパスワードでログインしている場合は、多要素認証（MFA）の設定も必要です。条件の細かい違いはCodex Cloudの記事にあります。
- リポジトリ：対象はGitHubのリポジトリです。Cloud environmentsは、現在のクラウド環境で使えない項目として、GitLabと自社運用のGitHub Enterprise Serverを挙げています（ロードマップにあるとの記載です）。これはクラウド環境の制限として書かれたもので、連携のすべてに当てはまるとは書かれていません。
GitHubの接続と設定の層：誰が何を決めるか
チームで使い始める時に迷いやすいのは、設定が何層にも分かれている点です。次の表は、公式資料に出てくる設定を、操作する人と効く範囲で並べたものです（表の切り方は編集部の整理です）。
| 設定 | 誰が操作するか | 誰のPRに効くか | 根拠 |
|---|---|---|---|
| GitHubの接続 | 使う人それぞれ。Cloudの環境を作る時などに、求められたら接続する。GitHubに入るアプリはChatGPT Codex connector | 記載なし（ヘルプセンターの「各ユーザーは自分のGitHub接続を使う」は、Cloudのタスクについての記述） | Codex Cloud Code review ヘルプセンター |
| リポジトリの設定 | そのリポジトリでGitHubのpushかadminの権限を持つ人 | 記載なし（Review code の Automatic review） | GitHub |
| 個人の設定 | 本人 | 自分のPR（Personal preferences の Automatic review）。コードレビューが有効なリポジトリに適用 | GitHub |
| Review trigger | 本人（Personal preferencesの中で選ぶ） | 自動レビューがいつ動くか（選択肢の記載なし） | GitHub |
| Security Review | リポジトリの設定を変えられる人 | Reviewで選んだPR（Follow personal preferences・All PRs・Team PRs）。Triggerは動くタイミング | Security Review |
GitHubの資料によると、自動レビューを設定するには、接続したリポジトリと、その設定を変えるためのGitHubのpushかadminの権限が要ります。設定の画面はCodexのコードレビューの設定です。一方、リポジトリの設定がどのPRに効くかは、Code Reviewの節には書かれていません。Security Reviewの資料には、リポジトリの設定は共有で他の人のPRにも効くこと、Team PRs（使える場合）はGitHubのチームではなくChatGPTのワークスペースのメンバーのPRを指すこと、GitHubを接続した人が増えてもレビューが人数分に増えないことが書かれています。これはSecurity Reviewの節の記述で、Code Reviewにも当てはまるとは書かれていません。
クラウド環境が要るかは、公式資料の記述が分かれている
PRのレビューを始める前に、Codexのクラウド環境（Codexがリポジトリのコードを動かすための設定）を用意する必要があるのか。2026年11月5日の時点で、資料の書き方は次のように分かれています。
| 資料 | 書かれていること |
|---|---|
| Code review | クラウドのレビューは、クラウド環境を作ったり管理したりしなくてよい |
| GitHubの資料 | 前提は「Codexに接続したGitHubのリポジトリ」。旧来の連携の設定はCodex Cloud (Legacy)を見るよう案内している |
| Security Review | 前提は「GitHubのリポジトリを接続したCodex cloudの設定」で、リンク先は現在のCodex Cloud |
| Codex Cloud (Legacy) | LegacyはCode ReviewとGitHub連携のための環境に引き続き対応している |
| Cloud environments | Legacyの仕組みは廃止する予定 |
| ヘルプセンター | 「Codex Cloud の使い方」は、移行期間中、コードレビュー・セキュリティレビュー・既存のLinearとGitHubの連携の流れが、引き続きCodex Cloud（レガシー）を使うと書いている（更新日の表示は「4日前」） |
どの記述が今の動きに合うかを、編集部は判定していません。資料どうしで食い違うように見える時は、レビューを広げる前に、代表的なPRを1つ選んで手動で頼み、どこで結果が返るかを確かめる進め方が安全です。また、Pricingの機能名は「GitHub issue and PR delegation with @codex」ですが、GitHubの資料が説明しているのはPRのコメントからの依頼だけです。IssueのコメントからCodexを動かす手順は今回確認した資料に書かれていないため、この記事では扱いません。
GitHubのPRで@codex reviewを頼む
GitHubの資料にある手動の頼み方は、次の2段階です。
- PRのコメントに
@codex reviewと書いて投稿する。 - Codexが👀で反応し、レビューを投稿するのを待つ。
レビューは、チームメンバーと同じように、通常のGitHubのコードレビューとしてPRに付きます。資料によると、GitHubではP0とP1の指摘だけが出て、レビューのコメントは優先度の高いリスクに絞られます。そのため、指摘がないからといって、優先度の低い問題までないとは限りません。
特に見てほしい点がある時は、資料の例のように、続けて書けます。
@codex review for issues in the database migrationこの書き方は、その1回だけの観点です。毎回同じ観点で見てほしい場合は、後で説明するAGENTS.mdのルールに書きます。
自動レビューを有効にする
PRのたびにコメントを書かずにレビューさせる設定について、GitHubの資料は2つの節で説明しています。設定の画面はどちらもCodexのコードレビューの設定です。
- Set up Codex code review：自動レビューを設定するには、接続したリポジトリと、その設定を変えるためのGitHubのpushかadminの権限が要る。リポジトリをCodexに接続し、設定の画面でリポジトリを選んで、Review codeのAutomatic reviewをオンにする。
- Enable automatic reviews：自分のPRで自動レビューを使うには、Personal preferencesのAutomatic reviewをオンにし、Review triggerでいつ動くかを選ぶ。コードレビューが有効なリポジトリに適用され、
@codex reviewのコメントは要らない。
リポジトリの設定がどのPRに効くか、2つの設定のどちらが必須かは、資料には書かれていません。反応しない時の確認順（下の節）では、両方を確かめるよう案内しています。Review triggerの選択肢の一覧も資料にはありません。Security Reviewの資料にある「On PR open」などは、Security ReviewのTriggerの項目なので、ここに当てはめないでください。
名前の似た機能にも注意が要ります。PRのAutomatic review（自動のコードレビュー）と、手元のCodexで承認の判断を自動の審査に任せるAuto-review（Approve for me）は別の機能です。
AGENTS.mdでレビューのルールを書く
Codexは、リポジトリのAGENTS.mdにある## Code Review Rulesの見出しの下のルールに従います。ルールは関わるコードに一番近いAGENTS.mdに書き、全体のルールはルートに置きます。変更されたファイルごとに、ルートと、そのファイルに近いAGENTS.mdのルールが使われます。
次の例は、編集部が用意した教材で、実際のリポジトリのルールではありません。
## Code Review Rules
### 会員の個人情報
- ログに会員のメールアドレスや電話番号をそのまま出す変更は指摘する。
安全な方法：ログには会員IDだけを出す。中身の確認は管理画面で行う。資料は、そのリポジトリ固有の影響の大きい振る舞いに絞り、安全な方法や例外も書き、書式やLintのような機械的なチェックはCIに任せるよう勧めています。
最初は2〜3個の短いルールから始め、代表的なPRで指摘を見ながら直します。ルールはCodexへの指示で、テストやブランチの保護、必須の承認の代わりにはならないと資料は書いています。AGENTS.mdそのものの書き方と置き場所の考え方はAGENTS.mdの記事で説明しています。
指摘の修正とほかの作業をPRのコメントで頼む
レビューの後、同じPRに次のようなコメントを書くと、指摘の修正を頼めます。
@codex fix the P1 issueGitHubの資料によると、このときCodexはPRを文脈としてLegacyのクラウドチャットを始め、権限があれば修正をPRのブランチにプッシュします。review以外の内容で@codexに頼んだ場合（たとえば@codex fix the CI failures）も同じです。ここでいうLegacyは、現在のCodex Cloudとは別の旧来の仕組み（Codex Cloud (Legacy)）で、Cloud environmentsの資料は廃止の予定だと書いています。
PRを最初から作らせたい場合は、PRのコメントからではなく、Codex Cloudで作業を頼み、変更とテストの結果を確かめてから、コミットするかPRを開きます（Codex Cloud）。手順と、今のCloudとLegacyの違いはCodex Cloudの記事にまとめています。
Security Review：GitHubの公開リポジトリとプランの注意
Security Reviewは、PRのセキュリティ上の問題を、通常のコードレビューより深く調べる追加のレビューです。Security Reviewの資料から、導入前に知っておきたい点をまとめます。
| 項目 | 資料の記述 |
|---|---|
| 提供の状態 | research preview（研究段階の公開） |
| 使えるプラン | Enterprise・Business・Edu・Pro。Plusでは使えない |
| 使う枠 | プランに含まれるCodexの利用枠か、ChatGPTのクレジット |
| 手動の頼み方 | PRのコメントに@codex security review |
| 結果の見え方 | PRに投稿された指摘は、そのPRの公開範囲を引き継ぐ。公開リポジトリや、ワークスペース外の人が開いたPRでも、PRを見られる人なら誰でも見られる |
| 報告の閾値（既定） | 自動はHighとCritical、手動はMedium・High・Critical。自動と手動で別々に変えられる |
| 指摘がない時 | 閾値に届く問題がなければ、PRには何も投稿されない。空の結果を「問題なし」と読む前に、タスクの状態と全体のレポートを確かめる |
公開リポジトリでは、結果の見え方に特に注意が要ります。深刻度や攻撃の経路を含む全体のレポートは、Codexの関連タスクのSecurity Reportタブに残ります。設定はリポジトリごとにReview security vulnerabilitiesのAuto security reviewで行い、TriggerをWhenever code review runsにするとCode Reviewと一緒に動きます。
Security Reviewでは、コードレビューと同じ指摘が出ることもあります。リポジトリ全体をスキャンするCodex Securityは別の製品で、Codex Securityの資料で説明されています。
GitHubでCodexが反応しない時の確認順
@codex reviewを書いても反応がない時、GitHubの資料は次の4点を確かめるよう案内しています。
- Codexのコードレビューの設定で、そのリポジトリのコードレビューをオンにしたか。
- PRが、Codexに接続したGitHubのリポジトリのものか。
- コメントが正確に
@codex reviewになっているか。 - 自動レビューなら、リポジトリの設定のAutomatic reviewと、Personal preferencesを確かめ、PRのイベントがReview triggerの設定に合っているか。
リポジトリが見つからない時のために、ヘルプセンターのGitHubをChatGPTに接続する記事にある説明も表にしました。この記事はChatGPTからGitHubを使う時の説明で、Codexのレビューに限った記事ではありません。同じ記事によると、ChatGPTのチャットから使うGitHubの接続はリポジトリを読むためのもので、コードの編集やGitHubへのプッシュはCodexの役割です。列名の「起こり得ること」は、編集部が資料から整理したもので、実際に起きた事例の集計ではありません。
| 起こり得ること | ヘルプ記事の記述 |
|---|---|
| リポジトリが一覧に出ない | ヘルプ記事によると、通常、リポジトリがChatGPTで使えるようになるまで約5分かかる。非公開や新しいリポジトリは、GitHubアプリが正しいアカウントか組織に入り、アクセスが許可されるまで表示されないことがある |
| 接続済みなのにリポジトリがない | ヘルプ記事は、再接続する前に、GitHubアプリのリポジトリの設定でそのリポジトリが選ばれ、許可されているかを確かめるよう案内している |
| 組織のリポジトリだけ出ない | ヘルプ記事によると、組織によっては、ChatGPTのアプリや特定のリポジトリに組織の管理者の承認が要る場合がある |
| IP許可リストを使っている | ヘルプ記事によると、GitHub Enterpriseや組織でIP許可リストを有効にしている場合は、OpenAIの送信元IPを許可リストに追加する |
Codexのアプリやローカルの作業が止まった時の確認順は、Codexのエラー・動かない時の記事にまとめています。
まとめ：GitHubとの連携は入口を決め、設定の担当を分けてから試す
CodexとGitHubの連携は、PRのコメントで頼む@codex reviewから始めるのが分かりやすい入口です。自動レビュー、AGENTS.mdのルール、@codex fix、Security Reviewと広げるほど、設定の層と使う枠が増えます。
チームで導入する時は、次の3つを先に決めておくと迷いにくくなります。
- リポジトリの設定を誰が持つか（pushかadminの権限がある人）
- 自動レビューを誰の設定で有効にするか（リポジトリの設定を持つ人と、各自のPersonal preferences）
- 公開リポジトリでSecurity Reviewを使うか（指摘がPRと同じ範囲に公開される）
どの入口が自社の開発の流れに合うか、レビューのルールをどう書き始めるかを相談したい場合は、Codexの導入相談からお問い合わせください。ChatGPTやCodexの使い方の全体像はCodexの使い方ガイドにまとめています。
