CodexでGitLabのマージリクエスト（MR）をレビューする手順は、OpenAIの開発者向け資料に載っています。アカウントの接続、Webhook、レビューの設定をそろえ、MRのコメントに@codex reviewと書く流れです。一方、GitLabの接続を説明したOpenAIのヘルプセンターの記事（以下、接続のヘルプ記事）は、GitLabのクラウドレビューは利用できないと書いています。どちらが現状に合うのかを、編集部は実際の環境で確かめていません。この記事では、資料の食い違い、GitLab.comと自社運用のGitLabの準備の違い、依頼の方法、指摘の直し方、反応がない時の確認順を説明します。

この記事は、OpenAIの公式資料とGitLabの公式資料に基づく解説です。参照したのは、OpenAIのReview GitLab merge requests with Codex、Code review、Pricing、Cloud environments、Codex Cloud (Legacy)、Authentication、Changelog、ヘルプセンターのGitLabの2記事と、GitLabのWebhooksです。いずれも2026年11月2日に確認しました。GitLabでの実測はしていません。コメントやルールの例のうち、公式の例でないものは編集部が用意した教材です。

GitLabでCodexを使う入口：OpenAIの3つの機能を分けて考える

OpenAIのGitLab向けの機能には、役割の違うものが3つあります。ここを分けないと、「接続したのにレビューが来ない」という状態になります。

機能できること状態
MRへのクラウドレビュー（この記事の中心）@codex reviewや自動レビューで、指摘をMRに投稿する開発者向け資料ではベータ版。接続のヘルプ記事は利用できないと書く（下で説明）
GitLabプラグインChatGPTやCodexから、プロジェクト、差分、MR、パイプラインを読み、許可された操作をするベータ版
Code ReviewプラグインデスクトップアプリとWebでMRを開き、変更と指摘を読み、Codexに質問するプレビュー

手元の差分を/reviewで見てもらう方法や、指摘の採否の決め方はコードレビューの解説にまとめています。この記事は、GitLabのMRに結果を返す部分を扱います。

クラウドレビューを使えるかは、公式資料の記述が分かれている

確認した時点で、OpenAIの資料には次の食い違いがあります。先に知っておくと、試す時の混乱を減らせます。

論点開発者向けのGitLabの資料接続のヘルプ記事
クラウドレビュー@codex reviewと自動レビューの設定手順を説明しているGitLabのクラウドコードレビューは利用できないと書いている
対象のプランGitLabの対応は、すべてのChatGPTプランで利用できると書いているプラグインの節で、プランとワークスペースの設定によって変わることがあると書いている

それぞれの根拠も並べておきます。開発者向け資料の記述を支えるものは3つあります。Code reviewの資料にある案内、管理者向けのヘルプの「Codexのコードレビューを使うならGitLabのイベントの受け取りを設定する」という記述、公式の変更履歴にある2026年8月19日の項目（GitLab対応をベータ版として案内）です。一方、接続のヘルプ記事は更新日が「4日前」と表示されており、管理者向けのヘルプの「13日前」より新しい記事です（どちらも2026年11月2日の表示）。どちらが正しいかを、編集部は判定していません。

2つの資料で共通しているのは、GitLabを接続しただけではレビューは始まらないという点です。編集部では、本格的に広げる前に、代表的なMRを1つ選んで試すことをすすめます。

GitLabの作業はLegacyのクラウドチャットで動くと書かれている

開発者向け資料によると、MRのコメントから修正やタスクを頼むと、Legacyのクラウドチャットが始まります。Cloud environmentsの資料には、Codex Cloud (Legacy)は廃止の予定だと書かれています。同じ資料では、現行のクラウド環境で未対応の項目にGitLabが挙がっています（ロードマップにあるとの記載です）。Legacyの資料で対象として挙げられているサービスにも、GitLabの名前はありません。現行のクラウド環境の案内だけを読むと、GitLabの資料の手順と矛盾しているように見えます。環境を作る時は、GitLabの資料の手順に沿って進めます。

GitLabのレビューに必要なプランと権限

自分のプランで使えるかは、次の表で確かめます。確定できない点は、確定できないと書いています。

項目資料の記述
ChatGPTのプラン開発者向け資料と変更履歴は、すべてのChatGPTプランと書く。料金ページにはGitLabの行がなく、Plusのカードにクラウド連携の記載があり、FreeとGoのカードには記載がない。FreeとGoで使えるかは確定できなかった
サインインの方法認証の資料によると、Codex CloudにはChatGPTでのサインインが必要。料金ページのAPIキーの欄にも、クラウドの機能はないと書かれている
ワークスペースの管理者管理者はGitLabの接続を無効にでき、プラグインの利用範囲も制御する。自社運用のGitLabでは、管理者の設定が前提になる
GitLabのプランGitLabの資料では、プロジェクトのWebhookはFree以上、グループのWebhookはPremium以上。変更履歴によると、自社運用のGitLabでWebhookを使うには19.0以降が必要

GitLabのレビューに必要な3つの準備

全員に必要なのは次の3つです。自社運用のGitLabでは、これにサービスアカウントが加わります。

準備役割GitLab.com自社運用（Self-Managed、Dedicated）
アカウントの接続GitLabのユーザーをCodexにつなぐ通常の接続手順管理者がアプリのテンプレートを公開してから、各レビュー担当者が接続
WebhookMRとコメントのイベントをCodexへ届けるプロジェクトの環境が必須プロジェクトの環境か、グループのWebhook
レビューの設定対象の作成者と動く条件を決めるCodexのレビュー設定Codexのレビュー設定

プロジェクトの環境とは、Codex Cloudの中で、そのプロジェクトのコードを動かすための設定です。プロジェクト固有のレビュールールを使うなら、リポジトリにAGENTS.mdも置きます。なお、このベータ版には、デスクトップアプリのCreate pull requestのようなGitHub向けのリポジトリ操作は含まれません。

GitLabのレビューに必要な3つの準備。アカウントはGitLabのユーザーをCodexにつなぐ。WebhookはMRとコメントのイベントを届ける。レビュー設定は対象の作成者と動く条件を決める。自社運用ではサービスアカウントも必要。
図：GitLabのレビューに必要な3つの準備。アカウントはGitLabのユーザーをCodexにつなぐ。WebhookはMRとコメントのイベントを届ける。レビュー設定は対象の作成者と動く条件を決める。自社運用ではサービスアカウントも必要。編集部の説明図です。製品の画面ではありません。画像を開くと拡大できます。

GitLab.comでレビューを準備する手順

  1. ヘルプセンターの手順に沿って、ChatGPTのプラグインの一覧からGitLabを入れ、Connectで接続します。GitLabの認可画面が出たら許可します。接続したGitLabユーザーが閲覧できるプロジェクトだけが対象です。
  2. Codexでも、GitLabのアカウントを接続します。
  3. Codex Cloud > Settings > EnvironmentsでGitLabのプロジェクトを選び、プロジェクトの環境を作ります。GitLab.comでは、レビューを有効にするためにこの環境が必要です。
  4. 環境を作る時にEnable Codex activity from GitLabをオンにします。これでプロジェクトのWebhookが入ります。Webhookの作成には、プロジェクトのMaintainerかOwner、管理者、またはWebhookを管理できるカスタムロールが必要です。
  5. Codexのレビュー設定でリポジトリを選び、ポリシーを決めます。自動レビューを使う時は、Review codeのAutomatic reviewをオンにして、Reviewで対象の作成者を、Triggerで動くタイミングを選びます。

自社運用のGitLabでレビューを準備する手順

Self-ManagedとDedicatedは、管理者の作業が増えます。流れは次のとおりです。

  1. ワークスペースの管理者が、管理者向けのヘルプに沿ってGitLabのアプリのテンプレートを設定して公開します。GitLabにOAuthアプリケーションを作る権限（グループのOwnerかインスタンスの管理者）も要ります。
  2. 各レビュー担当者が接続します。
  3. 管理者がCodex Cloud > Settings > Connectorsでサービスアカウントを用意します。
  4. プロジェクトの環境かグループのWebhookを設定し、GitLabのイベントをCodexで受け取れるようにします。
  5. Codexのレビュー設定で、ポリシーを選びます。

サービスアカウントの2つの作り方

方法操作確かめること
Codexに作らせるSet up service account > Create a service account作業する管理者にGitLabインスタンスの管理者権限が要る。Selected groupsかSelected projects onlyで範囲を選ぶ。apiスコープのトークンが作られる
既存のアカウントを使うUse an existing service accountにトークンを貼る対象のグループやプロジェクトにDeveloper権限。トークンはapiスコープで、期限は30日以上先。保存後は再表示されない

有効なトークンがないと、CodexはGitLabのイベントに応答できません。編集部では、トークンの期限を担当者の予定に入れておくことをすすめます。

グループのWebhookとプロジェクトの環境の違い

グループのWebhookは、グループ全体でレビューを有効にする方法で、自社運用のGitLabで使えます。ワークスペースの管理者がEnvironments > GitLab activity > Manage groupsから設定します。条件は2つです。接続したユーザーがグループのOwnerであることと、GitLabがPremiumかUltimateの19.0以降であることです。

グループのWebhookだけでは、レビューしかできません。次の場合はプロジェクトの環境を作ります。

  • ファイルの編集、コマンドの実行、MRのブランチへのプッシュまで頼む
  • レビューが、プロジェクト固有のシークレット、ネットワークアクセス、セットアップのコマンドに依存する

署名付きのWebhookはGitLab 19.0以降が必要です。Self-Managedの19.0では、webhook_signing_tokenの機能フラグが有効かも確かめます。

マージリクエストでCodexのレビューを依頼する

まず、レビューの対象と結果の行き先を押さえます。

項目開発者向け資料の記述
何を見るかMRの差分。比較の基点の詳しい説明は資料にない
どこで動くかCodex Cloud。プロジェクトの環境があれば、それを使う
結果の行き先MRのディスカッションとノート
できない場合GitLabが、畳まれた差分や大きすぎる差分を省くと、レビューを完了できない（変更履歴）

手動で頼む時は、MRのコメントに次のように書きます。

@codex review

Codexが👀で反応し、レビューを投稿します。結果はチームメンバーの指摘と同じ場所で読めます。特に見てほしい点がある時は、資料の例のように続けて書きます。

@codex review for issues in the database migration

自動レビューを選ぶ時の違い

自動レビューは、Codexの設定でAutomatic reviewsをオンにし、リポジトリのポリシーとトリガーを選びます。コメントなしで、条件に合うMRをレビューします。P0、P1、P2は指摘の区分で、それぞれの定義はこの資料には書かれていません。

比べる点手動（@codex review）自動
既定で含まれる指摘P0、P1、P2P0、P1
動くタイミングコメントした時On MR open、On every push、Smart Trigger (Experimental)から選ぶ
向いている場面（編集部の整理）試す段階、特定の観点を見てほしい時運用が固まり、対象のMRを絞れた後

編集部では、まず手動で指摘の質を確かめ、自動にする時もOn MR openから始めることをすすめます。On every pushはプッシュのたびに動くので、確認する量が増えます。料金ページによると、Code Reviewの利用枠を使うのはGitHub経由のレビューだけです。それ以外のレビューは、通常の利用枠を使います。利用枠があとどれだけ残っているかの確かめ方は、利用上限の解説にあります。

AGENTS.mdでGitLabのレビュールールを決める

開発者向け資料によると、CodexはAGENTS.mdを探し、該当するコードレビューのルールに従います。## Code Review Rulesの節は、ルールの対象に最も近いファイルに書いてください。置き場所は、リポジトリ全体のルールならルート、サービス固有のルールならそのサービスのフォルダです。変更された各ファイルについて、Codexはルートに書かれたルールと、そのファイルに当てはまる個別のルールを使います。

次は編集部の教材です。請求処理を想定しています。

## Code Review Rules

### 請求金額

- 金額の計算に浮動小数点の型を新しく使わない。
  安全な方法: 最小の通貨単位の整数で計算する。

開発者向け資料は、最初は2、3個の短いルールから始めるよう勧めています。良いルールの条件は次のとおりです。

  • リポジトリ固有で、影響の大きい動作を書く（互換性、データの境界、危険な副作用）
  • 安全な方法や例外も書く
  • 変わりやすい関数名より、守りたい結果を書き、対象のコードの近くに置く
  • 整形やリントのような機械的な確認は、CIに任せる

資料は、このルールがテスト、ブランチの保護、必須の承認の代わりにはならないと書いています。Codexの指摘がなくても、これらは外さないようにします。ルールの書き方全体はAGENTS.mdの解説を参照してください。

Codexの指摘をGitLabのマージリクエストで直す

指摘を直してもらう時も、MRのコメントで頼みます。資料の例は次のとおりです。

@codex fix the P1 issue

@codexの後にreview以外の言葉を続けると、MRの内容を踏まえたLegacyのクラウドチャットが始まります。たとえば次のように頼めます。

@codex fix the CI failures

どちらもプロジェクトの環境が必要です。グループのWebhookだけではレビューしかできません。Codexに権限がある時は、Codexが修正をMRのブランチへプッシュできます。編集部では、プッシュされた差分を人が読み、パイプラインの結果を確かめてから、指摘を解決済みにすることをすすめます。

GitLabプラグイン側では、設定によってMRの承認やマージまで行えます。接続のヘルプ記事によると、管理者がConfigure actionsで操作を選び、Configure approvalsで確認のタイミングを決めます。GitLab側で設定した権限の制限は、そのまま適用されます。承認とマージは人が行うと決めているチームは、ここも確かめておきます（編集部のすすめ）。

CodexがGitLabで反応しない時の確認順

開発者向け資料の確認項目を、編集部が順番に並べました。

確かめる順見る場所確かめること
1. 対象のアプリと環境Codexの設定GitLab.com用か自社運用用か、正しいGitLabのアプリを選んでいるか。プロジェクト固有の設定なら、対象のプロジェクトの環境があるか
2. Webhookの配信GitLabのWebhooks > Recent eventsMRとノートの配信が成功しているか。GitLabの資料によると、ここに出るのは直近2日分
3. レビューの設定Codexのレビュー設定Code reviewかAutomatic reviewsが有効か。MRがポリシーとトリガーに合っているか
4. Webhookの条件（自社運用）GitLabの設定署名付きか。SSLの検証が有効か。19.0以降か。19.0ならwebhook_signing_tokenの機能フラグが有効か。失敗で自動的に無効になったフックを直したか
5. トークン（自社運用）Connectors既存のトークンが有効でapiスコープを持つか。Codexが作ったサービスアカウントなら、設定が完了していて、対象のグループやプロジェクトが有効になっているか
6. サービスアカウントの権限（自社運用）GitLabのメンバー設定接続したユーザーだけでなく、サービスアカウントにもDeveloper権限があるか。イベントの受け取りとサービスアカウントの権限は別の設定
7. 差分の大きさMRの画面差分が畳まれていないか、大きすぎないか（変更履歴）
8. もう一度依頼MRのコメント@codex reviewと書く

プロジェクトが見えない時は、接続したGitLabのアカウントと、GitLab.comか自社運用かのアプリの選択を確かめます。外部との通信を遮断しているGitLabについて、接続のヘルプ記事は「クラウドコードレビューは利用できない」とだけ答えています。ここまで確かめても反応がなければ、上で書いた資料の食い違いのとおり、クラウドレビューがまだ使えない可能性もあります。OpenAIのサポートに確認してください（編集部のすすめ）。

まとめ：GitLabは3つの準備をそろえ、代表的なMRで手動から試す

CodexでGitLabのMRをレビューするには、アカウントの接続、Webhook、Codex側のレビュー設定をそろえます。自社運用のGitLabでは、サービスアカウントも用意します。接続だけではレビューは始まりません。クラウドレビューを使えるかどうかの公式資料の記述が分かれているので、代表的なMRで@codex reviewを試して反応を確かめ、指摘の質を見てから自動レビューやルールを広げます。

Codexの全体像から確かめたい場合は、Codexとは？使い方と仕事でできることを読んでください。開発チームのレビューの決まりや権限を整理したい場合は、法人向けのご相談も受け付けています。