Codex CLI × GitHub Actions PR自動レビュー完全ガイド｜openai/codex-action v1・3パターン自動化・コスト試算・Fork PR防御【2026年版】

OpenAI Codex CLI を GitHub Actions に組み込めば、Pull Request のレビュー・Issue から PR への自動化・依存更新やリリース準備の Cron 実行までを「コード化された開発自動化」として運用できます。2026 年 5 月時点で公式アクション openai/codex-action@v1 が安定版として提供され、@codex review を CI 側でセルフホストする運用が現実的な選択肢になりました。

しかし、検索上位の解説記事は「とりあえず動かしてみた」止まりで、3 つの自動化パターン（PR レビュー／Cron／Issue 駆動）を体系的に束ねた日本語ガイド と、コスト試算・Fork PR セキュリティ・失敗パターン までを一気通貫で扱った資料はほとんど存在しません。本記事ではその空白を埋めます。

本記事は、OpenAI 公式 GitHub Action ドキュメント・README・Pricing・Security ページを一次ソースに、Codex Action v1 の正確な仕様（inputs / outputs / safety-strategy / sandbox）と、現場で運用するための判断軸を整理した「実務ガイド」です。最小 YAML から始まり、10 種類のコピペテンプレ、月額試算 3 シナリオ、失敗 10 選、Claude Code Actions / Codex Cloud / PR-Agent との比較まで、22,000 字超で踏み込みます。

免責事項: Codex CLI・Codex Action の仕様と料金は頻繁に変動します。本記事は 2026 年 5 月時点の情報に基づくため、本番運用前に必ず OpenAI Codex 公式ドキュメント と openai/codex-action リポジトリ で最新仕様を確認してください。

1. Key Takeaways（30 秒サマリー）

• Codex Action（openai/codex-action@v1）は「Codex CLI を CI で安全に走らせる薄いラッパー」 であり、prompt-file / sandbox / safety-strategy / output-file の 4 入力を理解すれば 9 割の運用に対応できる。
• 3 つの代表パターン は PR 自動レビュー（pull_request トリガー）／Cron リリース準備（schedule トリガー）／Issue 駆動開発（labeled トリガー）。3 つを 1 つのリポジトリで重ねるのが 2026 年の標準。
• コストは「diff 行数 × 出力トークン単価」が支配的。OpenAI Pricing の credits を消費する従量課金で、シナリオを smoke / standard / deep に分けて段階化するのが現実的な制御策。
• セキュリティの肝は pull_request_target を安易に使わないこと。Fork からの PR では secrets を渡さず、Codex を 2 段階ジョブ（プレビュー → 承認後実行）に分離する。
• @codex review（Codex Cloud Reviews）と Codex Action は併用が現実解: 通常 PR は Codex Cloud で軽量レビュー、リリースブランチや security ラベルは Action で深いレビューに振り分ける。

2. Codex 自動化の全体像（CLI / Action / Cloud の 3 層モデル）

結論: Codex には「ローカル CLI」「GitHub Action」「Codex Cloud Reviews（@codex review）」の 3 つの実行面があり、それぞれが同じ AGENTS.md と Codex 設定を共有します。CI に組み込むなら Action、SaaS 的に最小設定で使うなら Codex Cloud、対話的に動かすなら CLI です。

2-1. 3 層モデルの整理

3 層とも基本仕様（プロンプト・サンドボックス・AGENTS.md）は共通です。Codex Action は単に「ローカル CLI を CI 用に薄く包んだもの」と捉えると理解が早くなります。Codex CLI 自体の機能は別記事 OpenAI Codex CLI 完全ガイド を参照してください。Codex Cloud との詳細な使い分けは Codex Cloud vs CLI ガイド で扱っています。

2-2. Codex Action の責任範囲

公式リポジトリ openai/codex-action の README によれば、Action は次の責任を負います。

1. Codex CLI のインストールと起動: @openai/codex を install し、codex exec を指定パーミッションで実行する
2. Responses API プロキシの提供: OpenAI API キーが指定されていればローカルプロキシを立て、CLI が外部にアクセスせず Action 内で完結
3. サンドボックスと特権の制御: sandbox 入力と safety-strategy（drop-sudo がデフォルト）で書き込み権限と sudo を制限
4. 出力の永続化: output-file で最終メッセージをファイルに保存し、後続ステップが PR コメント投稿等で利用

つまり Action は「Codex CLI を CI で安全に動かす」最小単位であり、PR コメント投稿や Slack 通知などは 後続ステップで自分で実装する 設計です。これにより柔軟性が高い一方、初期セットアップで戸惑いやすいポイントでもあります。

2-3. 「Action と Codex Cloud Reviews のどちらを先に試すか」の判断

社内の GitHub Actions ガバナンスが整っている、または Slack 通知や監査ログを CI 側で実装したい場合は Action、まずは最小設定で @codex review を試したい場合は Codex Cloud Reviews を先に有効化するのが定石です。Codex Cloud Reviews は Codex の GitHub 統合 で Automatic Reviews を有効化するだけで、新規 PR に Codex が自動でコメントするようになります。

3. 30 分で動かす最小構成

結論: GitHub Secrets に OPENAI_API_KEY を登録し、.github/workflows/codex-pr-review.yml を 1 ファイル追加するだけで、PR 自動レビューが稼働します。所要 30 分。

3-1. 事前準備（10 分）

1. OpenAI Platform（platform.openai.com）で API キーを発行し、Codex Action 専用の組織またはプロジェクトに紐付ける
2. リポジトリの Settings → Secrets and variables → Actions → New repository secret で OPENAI_API_KEY を登録
3. Settings → Actions → General → Workflow permissions で 「Read and write permissions」と「Allow GitHub Actions to create and approve pull requests」 の 2 つを必要に応じて有効化する（パターンによって異なる。詳細は後述）

3-2. 最小 YAML（コピペで動く）

.github/workflows/codex-pr-review.yml:

name: Codex PR Review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    branches: [main]

permissions:
  contents: read
  pull-requests: write

concurrency:
  # cancel-in-progress: true は連続 push のコスト削減に有効ですが、
  # 進行中のレビュー出力が破棄される可能性があります。重要 PR は false を検討。
  group: codex-pr-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Codex review
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          # sandbox を省略すると既定は workspace-write。
          # レビュー専用ワークフローでは必ず read-only を明示する。
          sandbox: read-only
          safety-strategy: drop-sudo
          output-file: codex-review.md
          prompt: |
            このリポジトリの直前のコミット差分をレビューしてください。
            出力フォーマット:
            - 概要（3 行以内）
            - 重大度別の指摘（P0 / P1 / P2）
            - 改善提案（コード片あれば短く示す）
            - 日本語で出力

      - name: Post review as PR comment
        if: success() && hashFiles('codex-review.md') != ''
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr comment "${{ github.event.pull_request.number }}" --body-file codex-review.md

重要な注意: sandbox 入力を省略すると公式の既定値（workspace-write）で起動します。レビュー目的のワークフローでは 明示的に sandbox: read-only を指定してください。指定し忘れると Codex がワークディレクトリに書き込める状態で動作します。

3-3. 動作確認のチェックリスト

• PR を開いたとき Actions タブに Codex PR Review ワークフローが現れる
• 数分以内に PR に Codex のコメントが投稿される
• Allow GitHub Actions to create and approve pull requests を切ったままだと、PR コメント投稿に失敗するケースがある
• OPENAI_API_KEY の請求が Codex Action 経由で計上されている（Platform の Usage ダッシュボードで確認）
• 失敗時は output-file の中身と Actions のログを併読する

ここまでで「動いた」状態を作ったら、次節以降の 3 パターンと 10 種テンプレで自分のチームのワークフローに合わせて拡張していきます。

4. パターン 1: PR 自動レビュー（完全 YAML）

結論: 通常 PR には pull_request トリガー + read-only サンドボックスで十分です。pull_request_target を使うべき場面は別途厳密に切り分けます。

4-1. レビュー粒度の設計

Codex に「全部レビュー」と頼むと出力が冗長になり、token 消費もコメントの可読性も悪化します。実用的には 3 段階の粒度を切り替えるのが推奨です。

ラベルや対象ブランチで粒度を切り替えるには、後述の 10 種カタログの「Slash command 起動」「ラベル分岐」を組み合わせます。

4-2. 完全 YAML（差分抽出+コメント投稿+失敗時通知）

name: Codex PR Review (full)

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    branches: [main, develop]

permissions:
  contents: read
  pull-requests: write

concurrency:
  group: codex-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}

      - name: Generate diff context
        id: diff
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          mkdir -p .codex
          git diff "$BASE_SHA"..."$HEAD_SHA" > .codex/pr.diff
          echo "diff_size=$(wc -c < .codex/pr.diff)" >> $GITHUB_OUTPUT

      - name: Skip large diffs
        if: steps.diff.outputs.diff_size > 200000
        run: echo "::notice::Diff > 200KB. Skipping Codex review."

      - name: Run Codex review
        if: steps.diff.outputs.diff_size <= 200000
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          model: gpt-5.3-codex
          sandbox: read-only
          safety-strategy: drop-sudo
          output-file: .codex/review.md
          prompt-file: .github/codex/prompts/pr-review.md

      - name: Post review
        if: steps.diff.outputs.diff_size <= 200000 && hashFiles('.codex/review.md') != ''
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: gh pr comment "${{ github.event.pull_request.number }}" --body-file .codex/review.md

      - name: Notify failure to Slack
        if: failure()
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {"text": "Codex PR review failed for PR #${{ github.event.pull_request.number }}"}
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

prompt-file をリポジトリにコミットすることで、レビュー観点をチームで共有し、差分管理できます。

4-3. プロンプトファイルの分割設計

.github/codex/prompts/pr-review.md:

# 役割
あなたはこのリポジトリのシニアレビュアーです。

# 対象
.codex/pr.diff の内容のみをレビューしてください。

# 出力フォーマット
## 概要（3 行以内）
## 重大度別の指摘
- P0（リリース停止級）
- P1（マージ前修正）
- P2（次回以降）
## 改善提案
（必要ならコード片を 5 行以内で示す）

# ルール
- 推測ではなくコード根拠を示す
- 日本語で出力

プロンプトを prompt-file でファイル化すると、チーム横断のレビュー基準を Git で版管理できるため、AGENTS.md の Review guidelines と合わせて運用するのが鉄則です。

4-4. ラベルや CODEOWNERS と連携する

paths-ignore で docs 配下を除外したり、if: contains(github.event.pull_request.labels.*.name, 'codex-deep') で codex-deep ラベル付き PR のみ深いレビューを動かすことで、コストを制御できます。Claude Code 側で同様の PR 自動化を組む場合は Claude Code PR 自動化ガイド も合わせて参照してください。

4-5. 大規模リポジトリで「ファイル単位レビュー」に分解する

差分が 1 ファイルあたり数千行になる大規模 PR では、Codex に「全部見せる」と入力 token が膨らみすぎます。実用解は次の 2 段階に分解する設計です。

1. 第 1 段階: 変更ファイル一覧と概要だけを Codex に渡し、「P0 / P1 がありそうなファイルを 3 つまで抽出してください」と問い合わせる
2. 第 2 段階: 抽出された 3 ファイルだけを差分付きで Codex に再投入し、詳細レビューを生成する

この 2 段階レビューは入力 token を 1/3 〜 1/5 に圧縮できるうえ、出力の焦点も鋭くなります。社内で標準化するときは 7-10 の Composite Action パターンに 2 段階を埋め込むのが定石です。

4-6. レビューを「品質ゲート」化するときの注意

PR をマージするための必須チェックとして Codex Review を入れる場合は、次の 3 点を必ず守ってください。

• 判定基準を Codex に決めさせない。Codex の出力はあくまでコメント。マージブロックは別の静的解析・テストカバレッジ・既存 CI に任せる
• 過去 PR のレビュー履歴をリプレイ可能にしておく。actions/upload-artifact@v4 で final-message を 90 日保管
• 誤検知を毎月集計。誤検知が 10% を超えたらプロンプトを見直す。チューニングしない Codex Review は数ヶ月で「ノイズ生成器」になる

5. パターン 2: Cron リリース準備（依存更新・Changelog 生成）

結論: schedule トリガーで毎週 Codex を回し、dependabot.yml で拾えない範囲（CHANGELOG / リリースノート / 軽微なリファクタ）を自動 PR 化します。レビューは人間が担当する前提です。

5-1. ユースケース

• 毎週月曜 09:00 JST に Codex が依存ライブラリの更新差分を読み、影響範囲を要約した PR を作成
• リリース直前に CHANGELOG.md を git log から再生成し、PR で提案
• セキュリティアドバイザリの自動取り込み（GitHub Advisory Database を入力に与える）

5-2. 完全 YAML（CHANGELOG 自動生成）

name: Codex Weekly Changelog

on:
  schedule:
    - cron: "0 0 * * 1"   # 毎週月曜 09:00 JST
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  changelog:
    runs-on: ubuntu-latest
    timeout-minutes: 25
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Collect git log since last release
        run: |
          LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
          if [ -z "$LAST_TAG" ]; then
            git log --pretty=format:'- %s (%h)' > .codex/commits.md
          else
            git log "$LAST_TAG"..HEAD --pretty=format:'- %s (%h)' > .codex/commits.md
          fi

      - name: Generate changelog
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          model: gpt-5.3-codex
          sandbox: workspace-write
          output-file: CHANGELOG.next.md
          prompt: |
            .codex/commits.md を読み、CHANGELOG.md の次バージョン候補を生成してください。
            セクション分け（Added / Changed / Fixed / Security）。
            破壊的変更は冒頭で BREAKING として警告。

      - name: Create PR
        uses: peter-evans/create-pull-request@v6
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          branch: codex/weekly-changelog
          title: "chore: weekly changelog draft"
          body: |
            Codex が生成した CHANGELOG ドラフトです。
            内容を確認し、`CHANGELOG.md` へマージしてください。
          add-paths: CHANGELOG.next.md

5-3. 運用のコツ

• sandbox: workspace-write を使うのは「Codex がファイルを書き換える」場面に限定する
• 生成 PR が乱立しないよう concurrency で同名グループを設定し、cancel-in-progress: true で旧 PR を上書きする（ただし 25 分タイムアウトの長尺ジョブを途中で切ると Codex の出力が失われるため、リリース直前の Cron は false 検討）
• gpt-5.3-codex で十分。大型モデル（GPT-5.5）に切り替えるのはレビュー精度に明確な不満が出てから

5-4. その他の Cron ユースケース

定期実行の Codex Action はリリース準備以外にも多くの応用があります。実際に運用で見かけるパターンを 4 つ紹介します。

1. 静的解析レポートの要約: 既存の eslint / semgrep / trivy の出力を Codex に渡し、開発者向け要約 + 優先度別の対応案を毎日 09:00 に Slack 投稿する
2. AGENTS.md の自己整合性チェック: AGENTS.md とコードベースの乖離（書いてあるが消えた依存、新規追加されたが未記載のディレクトリ）を週次で検知し、PR で提案
3. i18n ファイルの欠損補完: 翻訳キーが追加されたが他言語ファイルが未更新の差分を Codex が検知 → 暫定翻訳のドラフトを PR 化
4. README / CHANGELOG の言語間同期: 英語版 README を更新したら、日本語版を Codex が下書きして PR 化

これらはどれも「人手だと忘れがちだが、定期実行に乗せれば運用負荷ほぼゼロ」の典型例です。Cron で動かす Action はリポジトリ全体に書き込めるため、workspace-write + Allow GitHub Actions to create and approve pull requests を併用するのが現実的な構成です。

6. パターン 3: Issue 駆動開発（Issue → ブランチ → PR）

結論: codex ラベルが付いた Issue をトリガーに、Codex が同名ブランチを切って実装→PR まで自動化します。ただし「Codex に丸投げできるタスク」を Issue テンプレートで絞り込むのが成功条件です。

6-1. ユースケース

• 「外部 API のレスポンス型が変わった、3 ファイル分の修正」のような小規模で再現性の高い変更
• ドキュメント更新・コメント整形・型定義の追加など、レビュー観点が明確な変更
• 反対に、ビジネスロジックや UI 変更は人間が PR を立てるべき。Issue テンプレートで「Codex 可」「Codex 不可」を明示する

6-2. 完全 YAML（labeled トリガー）

name: Codex Issue To PR

on:
  issues:
    types: [labeled]

permissions:
  contents: write
  pull-requests: write
  issues: write

jobs:
  implement:
    if: github.event.label.name == 'codex'
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Prepare branch
        env:
          ISSUE_NUMBER: ${{ github.event.issue.number }}
        run: |
          BRANCH="codex/issue-${ISSUE_NUMBER}"
          git checkout -b "$BRANCH"
          mkdir -p .codex
          cat <<'EOF' > .codex/issue.md
          ${{ github.event.issue.body }}
          EOF

      - name: Run Codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          model: gpt-5.3-codex
          sandbox: workspace-write
          safety-strategy: drop-sudo
          output-file: .codex/result.md
          prompt: |
            .codex/issue.md の要件に基づいて、最小の変更で実装してください。
            テストが必要なら一緒に追加。
            完了後に変更要約を出力。

      - name: Commit
        env:
          ISSUE_NUMBER: ${{ github.event.issue.number }}
        run: |
          git config user.name "codex-bot"
          git config user.email "codex-bot@users.noreply.github.com"
          git add -A
          git commit -m "feat: implement issue #${ISSUE_NUMBER} via Codex"
          git push origin "codex/issue-${ISSUE_NUMBER}"

      - name: Open PR
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_NUMBER: ${{ github.event.issue.number }}
        run: |
          gh pr create \
            --base main \
            --head "codex/issue-${ISSUE_NUMBER}" \
            --title "Codex draft: ${{ github.event.issue.title }}" \
            --body-file .codex/result.md \
            --label codex-generated \
            --draft

6-3. レビューゲートをどう設計するか

Codex に Issue 駆動で書かせた PR は 必ず draft で開く のが鉄則です。さらに CODEOWNERS で codex-generated ラベルが付いた PR には必ず人間 reviewer を 1 人以上必須化するブランチ保護ルールを設定します。Issue 駆動の自動化は強力ですが、ビジネスロジックや破壊的変更が紛れ込むリスクが残るため、Git 運用の知識が前提です。Claude Code で同等の運用を組む方法は Claude Code Git ワークフロー でも扱っています。

6-4. Issue テンプレートで「Codex に丸投げできるタスク」を明示する

Issue 駆動を成功させる最大の鍵は、ワークフローではなく Issue 側のテンプレート設計 です。Codex に書かせるべき Issue と書かせるべきでない Issue を、起票時点で分離できる仕組みを用意します。

# Codex で対応するタスク（テンプレート）

## チェックリスト
- [ ] 変更ファイル数が 5 以下
- [ ] テストを追加 / 更新できるスコープ
- [ ] 既存パターンの繰り返しで実装できる
- [ ] UI / UX の意思決定を伴わない
- [ ] 破壊的変更を含まない

すべてチェックできる場合のみ `codex` ラベルを付けてください。

このテンプレートを .github/ISSUE_TEMPLATE/codex-task.md として配置し、codex ラベルが付くトリガーで Action を回します。チェック未完了の Issue は ChatOps コマンドで人間に差し戻すフローも併用すると、誤起動を最小化できます。

7. YAML テンプレ 10 種カタログ

ここから先は「自分のリポジトリの事情に合わせて差分だけ書き換える」用の 10 種カタログです。すべて openai/codex-action@v1 を前提にしています。

7-1. T1: 差分のみレビュー（軽量）

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    sandbox: read-only
    safety-strategy: drop-sudo
    model: gpt-5.4-mini
    prompt: |
      .codex/pr.diff のみを対象に、P0 / P1 だけ箇条書きで返してください。
      1,000 文字以内。

gpt-5.4-mini を選び、出力を 1,000 文字に絞ることで、PR が多いリポジトリでもコストが暴れません。

7-2. T2: モノレポ用（変更パッケージのみ）

- name: Detect changed packages
  id: changed
  run: |
    git diff --name-only ${{ github.event.pull_request.base.sha }}...HEAD \
      | grep -oE '^packages/[^/]+' | sort -u > .codex/packages.txt
- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    sandbox: read-only
    prompt: |
      .codex/packages.txt のディレクトリだけを対象にレビュー。
      他のパッケージは無視。

7-3. T3: Slash command で起動（/codex review）

on:
  issue_comment:
    types: [created]

jobs:
  codex-on-demand:
    if: |
      github.event.issue.pull_request &&
      startsWith(github.event.comment.body, '/codex review')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          # allow-users は GitHub username のカンマ区切り。
          # team 単位で絞りたい場合は別途 if: で GitHub Team API を判定するか、
          # 個人 username を列挙する。'*' で全員許可。
          allow-users: "alice,bob,carol"
          sandbox: read-only
          prompt: "/codex review コマンドの直後の指示に従ってください"

allow-users は 個別の GitHub username をカンマ区切りで列挙 する入力です。team slug や organization 名は受け付けません。team 単位で絞り込みたい場合は、if: 条件で GitHub Team Members API を別途呼ぶ追加ステップを設計してください。組織横断の全員に解放したいケースのみ '*' を使います。

7-4. T4: ラベル別の粒度切替

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    model: ${{ contains(github.event.pull_request.labels.*.name, 'codex-deep') && 'gpt-5.5' || 'gpt-5.3-codex' }}
    sandbox: read-only
    prompt-file: ${{ contains(github.event.pull_request.labels.*.name, 'codex-deep') && '.github/codex/prompts/deep.md' || '.github/codex/prompts/smoke.md' }}

7-5. T5: 失敗時 retry（指数バックオフ）

openai/codex-action@v1 自体には現状リトライ入力がありません。一時的な 429 / 5xx に備えるなら、codex CLI を直叩きする形で nick-fields/retry@v3 の command: に乗せます。

- name: Codex review (with retry)
  uses: nick-fields/retry@v3
  with:
    max_attempts: 3
    timeout_minutes: 10
    retry_wait_seconds: 60
    command: |
      npx -y @openai/codex@latest exec \
        --sandbox read-only \
        --ask-for-approval never \
        "$(cat .github/codex/prompts/pr-review.md)"
  env:
    OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

注意: gh workflow run でワークフロー自体を再キックする構成は、同一 PR 番号で複数ワークフローが並列起動し得るため、冪等性の観点で推奨しません。Action として呼び出した Codex 内部のリトライは v1 にはないので、CLI 直叩きに切り替えるか、continue-on-error: true + 2 段階目の if: failure() ステップで再実行する設計が現実解です。

7-6. T6: Timeout 対策（大きな PR をスキップ）

- name: Skip too-large PR
  id: gate
  run: |
    SIZE=$(git diff --shortstat ${{ github.event.pull_request.base.sha }}...HEAD | awk '{print $4+$6}')
    echo "lines=$SIZE" >> $GITHUB_OUTPUT
- if: steps.gate.outputs.lines > 2000
  run: echo "::notice::Skip Codex: PR > 2000 行"
- if: steps.gate.outputs.lines <= 2000
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}

7-7. T7: 機密リポジトリ用 sandbox 強化

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    sandbox: read-only
    safety-strategy: unprivileged-user
    # codex-user は safety-strategy: unprivileged-user を指定したときに
    # 実行ユーザー名を渡す別 input（公式 action.yml 準拠）。
    codex-user: codex
    codex-args: |
      ["--ask-for-approval", "never"]

safety-strategy: unprivileged-user + codex-user: codex の組み合わせで root を降格し、sandbox: read-only でファイル書き込みも封じます。注意: 公式 action.yml の入力名は codex-user であって unprivileged-user ではありません。unprivileged-user という値は safety-strategy の選択肢として現れる文字列なので、入力名と混同しないよう注意してください。

7-8. T8: Slack 通知連動

- name: Codex review
  id: codex
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    output-file: .codex/review.md
- name: Notify Slack
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {"text": "${{ steps.codex.outputs.final-message }}"}
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

final-message 出力をそのまま Slack に流すと長文になりがちなので、本番では先頭 1,000 文字に切り詰める処理を入れます。

7-9. T9: Token 削減版（diff 圧縮 + 出力制限）

- name: Compact diff
  run: |
    git diff --diff-filter=AM --no-color --unified=1 \
      ${{ github.event.pull_request.base.sha }}...HEAD > .codex/pr.diff
- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    model: gpt-5.4-mini
    prompt: |
      diff を読み、P0 だけ 500 文字以内で。

--unified=1 でコンテキスト行を最小化し、出力を 500 文字に制限することで、入力・出力の両側で token を絞ります。

7-10. T10: Composite Action 化（社内標準テンプレ）

.github/actions/codex-review/action.yml:

name: Codex review (internal)
description: Internal standard Codex review wrapper
inputs:
  pr_number:
    required: true
  level:
    default: standard
runs:
  using: composite
  steps:
    - uses: openai/codex-action@v1
      with:
        openai-api-key: ${{ env.OPENAI_API_KEY }}
        model: gpt-5.3-codex
        sandbox: read-only
        prompt-file: .github/codex/prompts/${{ inputs.level }}.md

社内の全リポジトリでこの composite action を呼ぶことで、レビュー観点の差分を最小化できます。

8. inputs / outputs リファレンス（v1 基準）

結論: 主要 inputs は prompt / prompt-file / openai-api-key / sandbox / safety-strategy / model / codex-args / codex-version / output-file / output-schema-file / allow-users / allow-bots / unprivileged-user。outputs は final-message の 1 つです（openai/codex-action README 参照）。

8-1. 重要 inputs

prompt と prompt-file は どちらか一方 を指定します。本番では prompt-file をリポジトリで版管理する運用が推奨されます。

model 入力に渡すのは API 用のモデル ID 文字列 です。Pricing ページに並ぶ表示名（"GPT-5.5"）と API のモデル ID（例: gpt-5.5-2026-xx）は揃わないことがあるため、model の値は OpenAI Platform の Models ページで最新の正確な ID を確認してから指定してください。本記事中のコード例（gpt-5.3-codex など）は説明用の表記であり、本番投入前に最新 ID で置換してください。

8-2. outputs

• final-message: Codex セッションの最終メッセージ。後続ステップで PR コメント・Slack 通知などに流用できる

output-schema-file で JSON Schema を指定すると final-message が JSON 形式になり、後続ステップで jq を用いて構造化処理ができます。レビュー結果を「P0 / P1 / P2」配列にして集計したい場合に有効です。

8-3. codex-args で渡せる主な CLI フラグ

codex-args は JSON 配列が安全です。シェル文字列で渡すとクォートの解釈で事故が起きやすくなります。CLI フラグの最新仕様は Codex CLI Reference で必ず確認してください。バージョン更新で挙動が変わる例があるため、本番では codex-version で CLI バージョンを pin することが推奨されます。

9. sandbox / safety-strategy の選択フレーム

結論: 「レビューだけ→read-only」「Codex に書かせる→workspace-write」「絶対禁止→danger-full-access」、特権は Linux/macOS は drop-sudo をデフォルトに、機密リポは unprivileged-user、Windows のみ unsafe を選びます。

9-1. sandbox 3 種の使い分け

公式の Sandboxing ページ によると、3 種類は以下の責任範囲を持ちます。

danger-full-access を CI で常用してはいけません。ネットワーク経由で API key を持ち出されるリスクと、ファイルシステム破壊のリスクを同時に抱え込みます。

9-2. safety-strategy 4 種の使い分け

Linux のセルフホストランナーで safety-strategy: unsafe を指定すると Codex がランナー上の secret を読み取れる状態で動いてしまいます。社内ガバナンス的にも CI セキュリティ的にも、Linux/macOS では drop-sudo 以上を維持してください。

9-3. 意思決定フロー（簡易フローチャート）

1. Codex に書き換えさせるか？ → No → read-only
2. 書き換えるが workspace 内のみ？ → Yes → workspace-write
3. それ以外（ホスト全体に触りたい） → 設計を見直す（恐らく不要）
4. ホスト OS は Windows か？ → Yes → safety-strategy: unsafe、No → drop-sudo または unprivileged-user

9-4. sandbox と safety-strategy は「掛け算」で考える

sandbox と safety-strategy は独立した 2 軸の制御で、組み合わせることで実効的な権限が決まります。代表的な組み合わせは次の通りです。

「sandbox は強くしたが safety-strategy が緩い」「逆に safety-strategy は強いが sandbox が danger」のような片肺の設定は、実効的な防御を作れません。設定 PR のレビュー観点として「両軸を同時に評価する」ことをチェックリスト化してください。

10. セキュリティ設計（GITHUB_TOKEN 最小権限・Fork PR 攻撃面）

結論: GITHUB_TOKEN は必要最小に絞り、Fork からの PR では secrets を一切渡さない 2 段階ジョブにします。pull_request_target を安易に使うのは禁物です。

10-1. GITHUB_TOKEN 最小権限テーブル

ワークフロー全体で permissions: ブロックを トップレベルに 1 回だけ書く とジョブ単位で個別に上書きしやすくなります。Allow GitHub Actions to create and approve pull requests のリポジトリ設定も合わせて確認してください。

10-2. Fork PR の攻撃面マトリクス

Fork からの PR は内部リポジトリと同じ権限で動くと OPENAI_API_KEY を含む secrets を奪われる リスクが生じます。Codex Action の公式ドキュメントでも「信頼できるトリガーのみ許可し、prompt は sanitize する」と明記されています（GitHub Action ドキュメント）。

重要: pull_request トリガーは Fork PR でもワークフローを起動できますが、Fork からの起動では secrets が供給されません。OPENAI_API_KEY が空のため Codex Action は起動直後に失敗し、結果として Fork PR は黙って自動レビュー対象外 になります。これは安全側の挙動ですが、「Fork PR にも自動レビューを付けたい」場合は、内部リポジトリにミラー PR を立てる運用か、pull_request_target を厳格な制御つきで使う設計に切り替える必要があります。

pull_request_target を使う場合の必須対策:

1. actions/checkout を ref: ${{ github.event.pull_request.base.sha }} で base 側に限定する（Fork コードを実行しない）
2. Codex には sandbox: read-only を強制し、書き込みを許さない
3. allow-users / allow-bots で起動者を絞り、組織外のユーザーには動かさない
4. プロンプトには PR タイトル・本文を 直接埋め込まない（プロンプトインジェクション対策）

10-2-1. pull_request_target で安全に diff だけを Codex に渡すサンプル

base をチェックアウトしたうえで diff だけを取得し、Codex には Fork 側のコードを実行させない構成です。

on:
  pull_request_target:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout base only
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.base.sha }}

      - name: Fetch diff via gh CLI
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          mkdir -p .codex
          gh pr diff ${{ github.event.pull_request.number }} > .codex/pr.diff

      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: read-only
          safety-strategy: drop-sudo
          allow-users: "alice,bob"
          prompt: ".codex/pr.diff のみをレビューしてください"

10-3. プロンプトインジェクション対策

PR タイトルや Issue 本文をそのまま prompt に展開すると、攻撃者が悪意あるプロンプトを仕込むことができます。対策は以下の通り。

• 動的入力は ファイル経由で渡す（prompt-file の参照先で囲み記号で隔離）
• システムプロンプトで「ユーザー入力は信頼しない」「秘密情報を出力しない」を明記
• レビュー粒度を低い権限から段階的に上げる（safety-strategy: unprivileged-user、--no-shell の併用）

詳細は Codex の Security ページ と Agent approvals & security を必ず参照してください。

10-4. 監査ログの設計

Codex Action の output-file をリポジトリではなく アーティファクトとして保管 し、保管期間を社内方針に合わせて 30 日 / 90 日で設定します。actions/upload-artifact@v4 を併用するのが定石です。コンプライアンス上の証跡が必要な業種では、final-message を CloudWatch Logs や S3 にも送信する追加ステップを入れます。

10-5. Secrets スコープの 3 段階分離

OPENAI_API_KEY を「リポジトリ Secret」「Environment Secret」「Organization Secret」のどこに置くかで、漏洩時の影響範囲が大きく変わります。Codex Action ではキーが ChatGPT のサブスク枠ではなく従量課金に紐づくため、流出は即座に金銭被害につながります。次の 3 段階で分離するのが鉄則です。

1. Organization Secret + 限定リポジトリ: 本番運用するリポジトリのみキーへのアクセスを許可
2. Environment Secret + 承認制: production Environment に紐付け、Action 起動時に承認ステップを挟む
3. Repository Secret: 検証用・サンドボックス用のキーのみ。Monthly budget alerts を低めに設定

加えて、OpenAI Platform の Usage ダッシュボードを定期的にチェックし、想定外の急増があれば即座にキーをローテートする運用を組み込んでください。

10-6. CodeQL / Secret scanning との併用

Codex Action 自体は静的解析を完全に置き換えるものではありません。CodeQL（GitHub Advanced Security）や Secret scanning は Codex Action よりも先行 して動かし、Codex には静的解析が拾えない「設計上の問題」「ビジネスロジックの矛盾」「テスト不足」を担当させます。「静的解析の代替」ではなく「静的解析の補完」として位置づけるのが、コスト・品質の両面で最も合理的です。

11. コスト試算 3 シナリオ

結論: Codex Pricing は 2026-04-02 から token ベース（公式 Pricing ページ）。PR 1 件あたりの token を推定すれば月額が予測できます。

11-1. 単価（Business / 新 Enterprise・2026 年 5 月時点）

公式 Pricing ページの credits per 1M tokens は以下です。

credits の換金レート・最新数値は契約ごとに異なるため、月次の実コストは Platform の Usage ダッシュボードで必ず突き合わせてください。本記事の試算は「単価感」を掴むためのものです。

11-2. PR 1 件あたりの token 推定

平均的な PR レビューは「diff 4 KB（≒入力 1,200 tokens）+ コンテキスト 1,800 tokens + 出力 800 tokens」程度です。差分の大きさで上下しますが、smoke 粒度なら入出力合計で 4,000 tokens 前後が目安です。

11-3. シナリオ別の月額試算

実コスト換算は契約とレートにより変動するため、本節では「相対比較」を提示します。

シナリオ A: 月 50 PR × standard × GPT-5.3-Codex

• 入力: 50 × 3,500 = 175,000 tokens → 43.75 × 0.175 = 約 7.7 credits
• 出力: 50 × 1,200 = 60,000 tokens → 350 × 0.060 = 21 credits
• 合計 約 28.7 credits / 月

シナリオ B: 月 200 PR × standard × GPT-5.5

• 入力: 200 × 3,500 = 700,000 tokens → 125 × 0.700 = 87.5 credits
• 出力: 200 × 1,200 = 240,000 tokens → 750 × 0.240 = 180 credits
• 合計 約 267.5 credits / 月

シナリオ C: 月 50 PR × smoke × GPT-5.4-mini（コスト最重視）

• 入力: 50 × 2,000 = 100,000 tokens → 18.75 × 0.100 = 約 1.9 credits
• 出力: 50 × 500 = 25,000 tokens → 113 × 0.025 = 約 2.8 credits
• 合計 約 4.7 credits / 月

3 シナリオを並べると、深いレビューを GPT-5.5 で大量に回すと一気に跳ねる ことが分かります。実務では「smoke は GPT-5.4-mini、deep ラベル付き PR のみ GPT-5.5」のハイブリッドが現実的です。

11-4. コスト暴走を防ぐ 5 つの設計

1. diff サイズで gate（200 KB / 2,000 行を超えたら自動スキップ）
2. ドキュメント差分のみの PR は paths-ignore で除外
3. モデルを「smoke=mini / standard=Codex / deep=GPT-5.5」と段階化
4. concurrency で同一 PR の連続トリガーをキャンセル
5. Monthly budget alerts を OpenAI Platform で設定

Codex のレートカード と Pricing ページは四半期で更新されます。本番運用前に最新の単価を必ず再確認してください。

11-5. 認証経路と課金の現状

公式 openai/codex-action@v1 の action.yml で定義されている認証関連の入力は openai-api-key と responses-api-endpoint（Azure OpenAI など API エンドポイントの差し替え）の 2 つです。2026 年 5 月時点で、Codex Action 自体は OpenAI API キーによる従量課金が公式に案内されている唯一の運用形態 です。ChatGPT サブスクリプションのタスク枠で運用したい場合は、Codex Action ではなく Codex Cloud Reviews（@codex review）に処理を寄せるのが現実解になります（13 章で詳述）。

responses-api-endpoint を使う構成は Azure OpenAI で Codex Action を回したいケース等に有効ですが、これは認証経路（プロキシ）の代替であって、サブスク課金とは別概念です。

11-6. 「Codex Action 単独」と「Codex Cloud 併用」のコスト比較

13 章で扱う Codex Cloud との併用前提でコストを再設計すると、次のような差分が出ます。

「Cloud + Action 併用」は導入難度が中程度ですが、コストの再現性と運用の手戻りの少なさで最も評価が高い構成です。リポジトリ数が増えると差は更に開きます。

12. 失敗パターン 10 選と対策

ここでは現場で実際に起こりやすい落とし穴を 10 個に絞ります。多くは Codex Action 固有ではなく「CI + AI エージェント」の運用一般に関する罠です。

F1: pull_request_target を安易に使い、Fork から secrets 漏洩

対策: 既定は pull_request。pull_request_target を使うなら 10-2 のチェックリストを全部満たす。

F2: prompt に PR タイトルや Issue 本文を直接展開

対策: 動的入力は prompt-file を経由し、テキストは「区切り記号で隔離 + サニタイズ」してから渡す。

F3: bubblewrap が GitHub Actions ランナーで動かない

カスタムサンドボックスを併用したケースで発生。対策: GitHub-hosted ランナーの制約（unshare 不可、unprivileged user namespace 制限）に注意し、Codex Action 標準の safety-strategy: drop-sudo を使う。

F4: drop-sudo だけだとファイル書き込み権限がない

対策: 書き込みが必要なら workspace-write sandbox を併用。drop-sudo は sudo を落とすだけで、sandbox とは独立した制御。

F5: Diff が巨大で Token 上限に達し fail

対策: 7-6 の T6 を導入し、200 KB / 2,000 行で gate。大規模 PR は「ファイル単位分割レビュー」に切り替える。

F6: 並列 PR で concurrency が無く、コスト 2 倍

対策: concurrency: { group: codex-${{ github.event.pull_request.number }}, cancel-in-progress: true } を必ず設定。

F7: codex-version pin なしで挙動変化

対策: codex-version: 0.130.0 のようにバージョン pin。CHANGELOG を週次でウォッチ。

F8: Fork からの workflow_run で secrets 参照できず fail loop

対策: Fork PR には pull_request を使う。workflow_run トリガーは「内部 PR のレビュー」専用にする。

F9: LLM 出力の Markdown が壊れて PR コメントが崩れる

対策: output-schema-file で構造化出力 → jq で整形して投稿。または final-message を tr で正規化。

F10: safety-strategy: unsafe を Linux で誤指定

対策: 既定の drop-sudo のままにする。unsafe は Windows ランナーのみ。設定レビューの PR は CODEOWNERS で security チームに必須レビューを設定。

これら 10 パターンはどれも「設計の段階で防げる」もので、起きてから対処すると影響が広がります。10-2 のセキュリティチェックリストと合わせて、ワークフロー新設時のレビュー観点として組み込んでください。

12-1. 失敗から学ぶ「最初の 1 ヶ月」設計

Codex Action を本番に乗せる前の 1 ヶ月で踏みやすい代表的な落とし穴を、時系列で並べると次のようになります。1 つひとつは小さいですが、放置すると複合的に効いてコスト爆発と監査リスクを同時に招きます。

「動かしてみる」と「運用に乗る」の間には常にこの 4 週間ぶんの調整があると割り切り、最初から budget alert と Slack 通知を仕込んでおくのが安全です。

13. Codex Cloud（@codex review）との使い分け

結論: Codex Cloud Reviews は「最小設定で全 PR を軽くカバー」、Codex Action は「重要 PR を深く・カスタムに」。両方を併用するのが 2026 年の標準解です。

13-1. Codex Cloud Reviews の特徴

Codex の GitHub 統合 によると、Codex Cloud Reviews は次の特徴があります。

• PR コメントに @codex review で起動、設定で全 PR を Automatic Reviews に
• AGENTS.md の Review guidelines を読んでレビュー観点を統一
• P0 / P1 のみコメントする「ノイズ最小」の方針
• @codex fix the P1 issue のように修正指示も可能
• 課金は ChatGPT サブスクリプションのタスク枠を消費

CLI を経由せず、リポジトリ設定だけで動くため、まず試すならこちらが圧倒的に早く立ち上がります。Codex Cloud と CLI の詳細な使い分けは Codex Cloud vs CLI 完全ガイド を参照してください。

13-2. Action と Cloud の使い分けフレーム

13-3. 併用パターン

1. 全 PR: Codex Cloud で軽量レビュー（自動）
2. release ブランチ / security ラベル PR: Action で深いレビュー（GPT-5.5）
3. Cron / Issue 駆動: Action のみ

このように 3 層で組むと、コストと品質のバランスが取れます。

14. Codex Action vs Claude Code Actions vs PR-Agent 比較

結論: GitHub 統合の深さと AGENTS.md 共通仕様の活用で Codex Action が有利、Anthropic Max プラン契約者は Claude Code Actions のコスト面が有利になりやすく、OSS ベースで自前運用したいなら PR-Agent が有力です。

14-1. 機能比較

14-2. 運用比較表（手動レビューを基準とした相対比較）

14-3. 選び方の指針

• GPT-5 系を CI でも使いたい / Codex Cloud と統一したい: Codex Action
• Claude Code を既に Max プランで開発に使っており、CI コストを既存プランに寄せたい: Claude Code Actions（Claude Code PR 自動化ガイド と Claude Code テスト自動化 も合わせて参照）
• モデルを切り替えながら OSS で自前運用したい: PR-Agent
• どれを使うか迷う: Claude Code vs Codex 比較 で前提情報を整理

14-4. 「両方使うチーム」の標準構成

実際の現場では「Codex Action と Claude Code Actions のどちらかに統一する」ではなく、両方を使い分ける のが 2026 年の標準解になりつつあります。役割分担の典型例は次の通りです。

両方を使う場合の最大のハードルは「どちらのコメントを優先するか」の運用ルールです。実務では「Codex は P0 / P1 のみコメント、Claude は設計レビューのみコメント」のように 役割を分離 し、コメントの prefix（[codex] / [claude]）で識別できるようにします。

14-5. 比較のときに見落とされやすい観点

• 多言語対応: Codex Action と Claude Code Actions はどちらも日本語プロンプトに対応するが、PR-Agent はモデルに依存する
• オンプレ運用: 完全オンプレ要求がある場合、Codex / Claude のいずれも API 経由が前提。PR-Agent も OSS だが LLM 側はクラウド前提
• 長期メンテナンス: メジャーバージョン跨ぎの API 変更頻度は Codex Action（v0 → v1）で発生済み。Pin と CHANGELOG 監視が必須

15. AGENTS.md Review guidelines テンプレ 3 種

結論: AGENTS.md にレビュー観点を書くと、Codex Action / Codex Cloud Reviews / Codex CLI のすべてが同じ基準でレビューします。

15-1. スタートアップ向け（軽量）

## Review guidelines

- 出力は日本語、3 行以内の概要 + 重大度別の指摘
- P0（リリース停止級）と P1（マージ前修正）のみコメント
- セキュリティに関する指摘は最優先
- スタイル違反はリンタに任せる

15-2. SaaS 開発向け（標準）

## Review guidelines

### スコープ
- ビジネスロジック・テスト・型定義のみレビュー
- 自動生成ファイル（schema.ts 等）は無視

### 観点
1. 例外設計（catch 漏れ / 二重 throw）
2. SQL injection / SSRF / XSS
3. 型の `any` 使用
4. テストカバレッジが下がっていないか

### 出力
- P0 / P1 を最大 5 件まで
- 改善コード片は 10 行以内

15-3. エンタープライズ向け（深い）

## Review guidelines

### コンプライアンス
- 個人情報処理に関する変更は必ずフラグを立てる
- ログ出力に PII が含まれていないか確認
- DB マイグレーションは破壊的変更を P0 として扱う

### アーキテクチャ
- 既存パターンからの逸脱を指摘
- レイヤー違反（DB アクセスがプレゼンテーション層）を P1
- 公開 API のシグネチャ変更は P0

### 監査
- 変更要約を 200 文字以内で出力
- 出力末尾に「審査者用ハッシュ」（commit + reviewer の SHA1）を付与

AGENTS.md のフォーマットは agents.md コミュニティ仕様 に準拠しており、Codex 以外の AI コーディングツールでも参照されます。

15-4. プロンプトの差分管理と KPI

Review guidelines は AGENTS.md にコミットして版管理し、四半期に一度は KPI と照合して更新するのが理想です。KPI の例は次の 4 つです。

1. 指摘採用率: Codex が出した指摘のうち、実際に開発者が修正に取り入れた割合（目標: 60% 以上）
2. 誤検知率: 「これは関係ない」と判断された指摘の割合（目標: 10% 未満）
3. PR レビュー所要時間: 人間 reviewer が PR に着手するまでの時間短縮（目標: 30% 削減）
4. 重大バグの検知件数: Codex が P0 として検知し、リリース前に修正できた件数

KPI を運用に組み込むことで、Review guidelines の改善ループ（誤検知が多い → 観点を絞る → 採用率が上がる）を回せます。AGENTS.md の差分は単なる設定変更ではなく「レビュー基準の進化」として扱い、PR ごとにメンテナーが必ずレビューする運用を組んでください。

16. 組織導入チェックリスト

導入承認を社内で取るときに、最低限カバーしておくべき項目です。

• OpenAI API key を専用組織 / プロジェクトで発行し、Codex Action 専用 secret に登録
• Monthly budget alerts を OpenAI Platform で設定（500 USD / 1,000 USD など）
• GitHub Actions 側で Allow GitHub Actions to create and approve pull requests の可否を方針化
• pull_request_target の利用は security チームの承認制
• AGENTS.md の Review guidelines をリポジトリオーナーが管理
• codex-generated ラベル PR は CODEOWNERS で人間レビュー必須
• Codex 出力は actions/upload-artifact@v4 で 90 日保管
• 半期に 1 回、codex-version と Pricing の差分を棚卸し
• Codex Action の YAML レビューを Internal Developer Platform（IDP）チームに集約

組織導入の戦略設計や、CAIO 代行的に伴走支援が必要な場合は koromo の AI 戦略・CAIO 代行サービス もご検討ください。

17. FAQ

18. まとめ

OpenAI Codex を GitHub Actions に組み込むと、PR 自動レビュー・Cron リリース準備・Issue 駆動開発の 3 つを「コード化された開発自動化」として運用できます。重要なのは次の 5 点です。

1. Codex Action は「Codex CLI を CI で安全に走らせる薄いラッパー」。prompt-file / sandbox / safety-strategy / output-file の 4 入力を押さえれば 9 割の運用は組める
2. 3 つのパターン（PR レビュー / Cron / Issue 駆動）を 1 リポジトリで重ねる のが 2026 年の標準。AGENTS.md と prompt-file をリポジトリで版管理する
3. セキュリティの肝は pull_request_target を安易に使わないこと。Fork からの PR では secrets を渡さない 2 段階ジョブで設計する
4. コストは「diff 行数 × 出力 token 単価」が支配的。smoke は mini、deep は GPT-5.5 のハイブリッドが実務的
5. Codex Cloud Reviews（@codex review）と Codex Action は併用が現実解。軽量な Codex Cloud + 深い Action で 2 段階に分ける

導入で迷う場合は、まず OpenAI Codex CLI 完全ガイド で CLI 自体の基礎を押さえ、Codex Cloud vs CLI ガイド で Codex Cloud の選択肢を理解し、Claude Code vs Codex で他選択肢との位置関係を整理してから、本記事の 3-2 の最小 YAML から動かしてみるのがおすすめの順序です。

組織として Codex Action を CI に組み込むときの ガバナンス設計・コスト管理・PoC 設計 にお悩みの場合は、koromo の AI 戦略・CAIO 代行サービス または プロダクト開発支援 でご相談を承っています。PoC から全社展開まで、生成 AI を「導入したのに使われない」状態にしない伴走支援を提供しています。