1. Codexが8月19日に発表したGitLab対応
OpenAIのリリースノートによると、GitLab対応は2026年8月19日にベータとして公開され、すべてのChatGPTプランで利用できます。GitLabプロジェクトをCodex cloudへ接続し、IssueやMRのコメントから@codexを使ってタスクを開始したり、MRのコードレビューを依頼したりできるようになりました。
GitHub向けに提供されてきたAIコードレビューを、GitLab中心のチームでも開発フローへ組み込める点が今回の変化です。一方、連携処理はCodex cloud上で実行されます。デスクトップアプリの「Create pull request」のようなGitHub向け操作は、このGitLabベータには含まれません。機能名だけで同等と判断せず、レビュー、修正、ブランチ更新のどこまで使うかを分けて考える必要があります。
2. GitLab連携でできる3つのこと
GitLab連携の役割は大きく3つです。第一に、MRコメントへ@codex reviewと書き、必要なときだけレビューを依頼できます。第二に、MR作成時、毎回のpush時、または実験的なSmart Triggerで自動レビューを動かせます。第三に、プロジェクト環境を構成すれば、IssueやMRを文脈にコード変更、コマンド実行、commit、MRブランチへのpushまで依頼できます。
| 使い方 | 起動方法 | 向いている場面 |
|---|---|---|
| 手動レビュー | MRで@codex review | 重要変更だけ追加確認したい |
| 自動レビュー | MR作成・push・Smart Trigger | 見落とし防止を標準化したい |
| 修正タスク | Issue/MRからCodexを起動 | 指摘から修正までつなげたい |
公式ドキュメントでは、手動レビューは既定でP0・P1・P2の指摘を含み、自動レビューは重大度の高いP0・P1に絞ると説明されています。レビュー件数を増やすより、重大な不具合を早い段階で見つける補助として設計されています。Codexの基本的な特徴はCodexの導入解説、利用状況の測り方はAIエージェント定着KPIの記事も参考になります。
3. MRレビューを導入する5手順
導入は、いきなり全MRを自動レビューするのではなく、対象プロジェクトとレビュー範囲を限定して進めます。次の5段階にすると、接続トラブルと不要な指摘を切り分けやすくなります。
- Step 01GitLabアカウントを接続
- Step 02プロジェクト環境を作成
- Step 03Webhookを有効化
- Step 04レビュー規則を記載
- Step 05手動MRで精度を検証
接続と権限を確認してから、代表的なMRでレビュー品質を評価します。
GitLab.comではアカウント接続後、Codex CloudのSettingsから対象プロジェクトの環境を作成します。GitLabイベントからCodexを起動するには「Enable Codex activity from GitLab」を有効にし、プロジェクトWebhookを設定します。Webhook作成にはMaintainer、Owner、管理者、またはWebhookを管理できるカスタムロールが必要です。
最初の検証では、過去に不具合が見つかった小規模MRを1〜3件使います。人のレビュー結果とCodexの指摘を比べ、重大な見落とし、誤検知、同じ指摘の重複を記録してください。いきなり「Review all MRs」にせず、「Review my MRs」または手動コメントから始めると、開発者の確認負荷を測りやすくなります。
4. AGENTS.mdでレビュー基準を固定する
Codexはリポジトリ内のAGENTS.mdを探し、変更ファイルに適用されるコードレビュー規則を読みます。たとえば「顧客データをログへ出さない」「請求確定後の金額を再計算しない」「公開APIの互換性を壊さない」など、一般的な静的解析では判定しにくい業務固有の制約を短く記載します。
## Code Review Rules
### 顧客データ
- 個人情報をアプリケーションログへ出力しない。
安全な方法: 識別子をマスキングし、調査用IDだけを残す。
### 互換性
- 公開APIの既存レスポンス項目を削除しない。
変更が必要な場合はバージョンを分ける。OpenAIは、まず2〜3個の簡潔な規則から始め、フォーマットやlintのような機械判定はCIへ残すことを推奨しています。ルートのAGENTS.mdには全体規則を、特定サービスの配下にはその業務だけの規則を置きます。これにより、AIレビューへ社内知識を渡しつつ、関係ない変更へのノイズを抑えられます。チーム内で手順を再利用する考え方はCodex Pluginsの記事とも共通します。
5. 権限・Webhook・レビュー品質の注意点
Self-ManagedまたはDedicated GitLabでは、ワークスペース管理者による接続テンプレートとサービスアカウント設定が必要です。Codexにコード変更やpushを任せる場合はプロジェクト環境も必要になります。公式資料では、署名付きのプロジェクト・グループWebhookにGitLab 19.0以降が必要とされています。自社環境のバージョンが古い場合は、接続作業より先に互換性を確認してください。
| 確認項目 | 安全な初期設定 | 確認する証拠 |
|---|---|---|
| 対象範囲 | 選択したプロジェクトだけ許可 | Connectorの対象一覧 |
| サービスアカウント | 必要最小限のDeveloper権限 | 所属グループ・期限・監査ログ |
| Webhook | 代表プロジェクト1件で開始 | イベント履歴と署名設定 |
| レビュー品質 | 人の承認を必須にする | 見落とし・誤検知・採用率 |
また、GitLab側が大きすぎるdiffや折りたたまれたdiffをCodexへ渡さない場合、レビューを完了できないことがあります。AIレビューが付いたことを「全変更を確認済み」の印にせず、対象diffと実行結果を毎回確認してください。MIRAINAの視点では、導入効果はレビュー数ではなく、重大な指摘の採用率、レビュー待ち時間、リリース後の不具合件数で測るべきです。Codexのレビューは、テスト、CI、ブランチ保護、人の承認を置き換えるものではありません。
6. まとめ
CodexのGitLab連携により、GitLabのIssueやMRからタスクを開始し、手動・自動のコードレビューを同じ開発フローへ組み込めるようになりました。特にAGENTS.mdで業務固有のレビュー規則を渡せる点は、担当者ごとに揺れやすい確認基準をそろえる助けになります。
一方で、現在はベータです。最初は対象プロジェクトを限定し、Webhookとサービスアカウントの権限を確認した上で、代表的なMRを手動レビューしてください。人のレビューと比較して有効な指摘が安定してから、自動レビューの対象を広げるのが安全です。



