コードレビューがボトルネックになっていませんか。PRが溜まり、レビュー待ちの間にコンテキストが失われ、マージ後に回帰バグが見つかる。この悪循環を断ち切る手段として、OpenAIが公式に提供するGitHub Action「codex-action」が注目されています。

この記事でわかること

  • codex-actionの概要と、従来のLintツールとの違い
  • GitHub Actionsワークフローへの組み込み手順
  • セキュリティ設定の選び方
  • 実際の運用事例と効果

codex-actionとは

codex-actionは、OpenAIのCodex CLIをGitHub Actionsワークフローから実行するための公式アクションです。PRの作成やコミットのプッシュをトリガーに、Codexがリポジトリのコードを読み、変更点のレビュー結果を返します。

従来の静的解析ツール(ESLint、Pylintなど)は、あらかじめ定義されたルールに基づいて問題を検出します。codex-actionはこれとは異なり、コードの文脈を理解したうえで回帰リスクの指摘、セキュリティ上の懸念、設計上の改善提案まで行います。ルールファイルの保守が不要な点も大きな違いです。

内部的には、アクションがCodex CLIをインストールし、Responses APIへの安全なプロキシを構成したうえでcodex execを実行します。レビュー結果はfinal-messageという出力として後続のステップに渡せるため、PRコメントへの投稿やSlack通知など、自由にワークフローを構築できます。

前提条件

導入に必要なものは3つです。

  • OpenAI APIキーOpenAIのダッシュボードから取得し、GitHubリポジトリのSettings > SecretsOPENAI_API_KEYとして登録します
  • GitHubリポジトリ — パブリック・プライベートどちらでも使えます
  • GitHub Actionsが有効 — 無料枠でも動作します。ランナーはLinuxまたはmacOSを推奨します

Azure OpenAIを利用している場合は、responses-api-endpointにAzureのエンドポイントURLを指定することで同様に動作します。

PRレビューを自動化するワークフロー

以下は、PRが作成されるたびにCodexが差分をレビューし、結果をPRコメントとして投稿するワークフローの例です。

name: Codex Code Review
on:
  pull_request:
    types: [opened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge

      - name: Pre-fetch base and head refs
        env:
          PR_BASE_REF: ${{ github.event.pull_request.base.ref }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        run: |
          git fetch --no-tags origin \
            "$PR_BASE_REF" \
            "+refs/pull/$PR_NUMBER/head"

      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: |
            Review ONLY the changes in PR #${{ github.event.pull_request.number }}.
            git log --oneline ${{ github.event.pull_request.base.sha }}...${{ github.event.pull_request.head.sha }}
            Suggest improvements, potential bugs, or issues.

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Post review comment
        uses: actions/github-script@v7
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });

このYAMLファイルを.github/workflows/codex-review.ymlとして保存すれば、次のPRから自動レビューが始まります。

safety-strategyの選び方

codex-actionには、Codexに与える権限を制御するsafety-strategyパラメータがあります。用途に応じて正しく設定する必要があります。

drop-sudoはデフォルト設定です。ランナーのsudo権限を剥奪してからCodexを実行します。GitHub提供のランナーではこの設定が最も安全です。APIキーへのアクセスも制限されるため、パブリックリポジトリでも安心して使えます。

read-onlyはCodexにファイルの読み取りだけを許可します。コードを変更させたくない純粋なレビュー用途に向いています。

unprivileged-userはセルフホストランナー向けです。事前に作成した権限の低いユーザーアカウントでCodexを実行します。

unsafeはすべての制限を外します。Windowsランナーではこの設定のみサポートされています。信頼できるプロンプトでのみ使ってください。

mainブランチのコミット監視という使い方

PRレビューだけでなく、mainブランチへのプッシュをトリガーにした運用も効果的です。OpenClawプロジェクトのメンテナーであるPeter Steinberger氏は、mainブランチの各コミットに対してCodexインスタンスを起動し、回帰やセキュリティ問題を自動検出する仕組みを構築しました(参考)。導入からわずか10分で実際のバグを1件検出したと報告しています。

この方式では、ワークフローのトリガーをon: pushに変更し、プロンプトで対象コミットの差分を指定します。PRレビューと併用すれば、レビューをすり抜けた問題もmainブランチで捕捉できます。

Codex Securityとの違い

OpenAIは2026年3月に「Codex Security」もリサーチプレビューとして公開しています。こちらはリポジトリ全体の脅威モデルを構築し、脆弱性を体系的に洗い出すセキュリティ特化のエージェントです。30日間のベータ期間中に120万件以上のコミットをスキャンし、792件のクリティカルな問題と10,561件の高深刻度の問題を検出しました(参考)。GnuTLSやOpenSSH、Chromiumなど著名OSSの脆弱性も発見し、14件のCVEが割り当てられています。

codex-actionとCodex Securityは目的が異なります。codex-actionはCI上で差分ベースのレビューを高速に回すためのツールです。Codex Securityはリポジトリ全体を深く分析し、既知・未知の脆弱性を網羅的に検出します。日常のPRレビューにはcodex-action、定期的なセキュリティ監査にはCodex Securityという使い分けが現実的です。

導入時の注意点

Codexのデフォルトサンドボックスはネットワークアクセスを遮断します。依存パッケージのインストールが必要な場合は、codex-actionのステップより前に済ませてください。

プロンプトの設計も重要です。レビュー対象を明確に絞らないと、変更と無関係なファイルにまでコメントが付きます。git diffgit logの範囲指定をプロンプトに含めると精度が上がります。

APIコストも計画に入れましょう。コミットの頻度が高いリポジトリでは、modelパラメータで軽量モデルを指定したり、特定のファイルパターンだけをレビュー対象にするなどの工夫が有効です。

まとめ

AIによるコードレビューの自動化は、もう実験段階ではありません。.github/workflowsにYAMLファイルを1つ追加するだけで、すべてのPRとコミットにAIの目が入ります。まずは小規模なリポジトリで試し、プロンプトを調整しながら本番のプロジェクトに展開してみてください。