GitHub Actions×Codex CLIでPR自動レビュー実装

「レビュー待ちのPRが増えて、開発が止まりがち」「夜中にcronが走って通知が荒れる」みたいな悩みを抱えている人に向けて書きました。この記事を読むと、GitHub ActionsとCodex CLIを使ってPRレビューを自動化しつつ、2026年の新仕様であるdeployment: falseとIANA timezone対応cronまで一気に設定できます。僕は福祉事業のIT全般と、AI×SaaSの開発支援を並行していて、レビュー運用を整えるだけでチームの手戻りがかなり減る現場を何度も見てきました。

GitHub Actions×Codex CLIでPRレビューを自動化する意味

PRレビューは、イメージとしては健康診断に近いです。毎回フル精密検査を人間だけで回すと、どうしても時間が足りなくなりますよね。だからこそ、最初のスクリーニングをAIに任せて、人は「仕様の妥当性」や「プロダクト判断」に集中する構造が強いです。

結論として、AIレビューは人レビューの代替ではなく、レビュー品質を底上げする前処理として使うのが最も再現性があります。

• AIレビューの担当 — 差分の見落とし、テスト不足、命名や境界条件の粗さを早く拾います
• 人レビューの担当 — 仕様意図、事業優先度、運用との整合性を判断します
• CIの担当 — ビルド・Lint・単体テストの合否を機械的に担保します

僕の現場でも、レビュー自動化を入れる前は「レビュー待ちで半日止まる」が普通でした。仕組み化後は、まずAIが一次レビューを返し、人が最終判断する流れに変えたことで、PRの滞留時間が目に見えて短くなりました。つまり、レビュー自動化は速さだけではなく、チームの集中力を守る投資なんです。

2026年版で押さえる2つの仕様変更：deployment:falseとIANA timezone cron

2026年3月19日のGitHub Actionsアップデートで、運用に効く変更が2つ入りました。1つ目は、環境を参照しても自動デプロイを作らないdeployment: falseです。2つ目は、scheduleでIANA timezoneを指定できるようになった点です。公式の変更はGitHub Changelog（2026-03-19）で確認できます。

注意点として、カスタムのdeployment protection ruleを使っている環境では、deployment: falseと両立しないケースがあります。この点はGitHub Docs（Control deployments）で先に確認しておくのがおすすめです。cronのtimezone仕様はEvents that trigger workflowsに例付きで載っています。

設計編：まず決めるべきレビュー方針とプロンプト

実装の前に、何をAIに判断させるかを先に決めます。ここが曖昧だと、コメント量は増えるのに価値が薄い状態になりやすいです。僕が使っているのは「必須指摘」と「任意改善」を分ける設計です。つまり、マージ阻害する論点と、あとで直せる改善を分離します。

1. 必須指摘を定義します（セキュリティ、壊れる変更、テスト不足）
2. 任意改善を定義します（命名、可読性、リファクタ候補）
3. 出力フォーマットを固定します（箇条書き、再現手順付き）
4. レビュー対象範囲を明示します（base..headの差分のみ）

プロンプトは長すぎるより、判定基準が明確な短文のほうが安定します。イメージとしては、優秀な新メンバーにレビュー基準書を最初に渡す感覚です。「何を重く見るか」を先に言語化するのが、精度より先にやるべきことです。

設計で迷う場合は、まず「must-fix / optional / test cases」の3分類だけに絞って、1リポジトリで2週間試すのがおすすめです。最初から全PRへ広げず、コメント品質を見ながら調整すると失敗しにくいです。

実装編：そのまま使えるGitHub Actionsワークフロー

ここからは実装です。ポイントは3つだけです。1つ目がenvironment.deployment: false、2つ目がschedule.timezone、3つ目がopenai/codex-action@v1で安全設定を明示することです。公式アクションはopenai/codex-action、セキュリティ推奨はsecurity.mdを確認してください。

name: codex-pr-review

on:
  pull_request:
    types: [opened, reopened, synchronize, ready_for_review]
  schedule:
    - cron: "30 9 * * 1-5"
      timezone: "Asia/Tokyo"
  workflow_dispatch:

permissions:
  contents: read
  pull-requests: write

jobs:
  collect-open-prs:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    outputs:
      numbers: ${{ steps.collect.outputs.numbers }}
    steps:
      - id: collect
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          numbers="$(gh pr list --state open --limit 20 --json number --jq '[.[].number]')"
          echo "numbers=$numbers" >> "$GITHUB_OUTPUT"

  review-pr-event:
    if: github.event_name == 'pull_request' && github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    environment:
      name: ai-review
      deployment: false
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
      - name: Fetch base/head refs safely
        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"
      - id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: workspace-write
          safety-strategy: drop-sudo
          prompt: |
            Review ONLY this PR diff.
            Output in Japanese with:
            1) must-fix
            2) optional improvements
            3) test cases to add

  review-scheduled:
    if: github.event_name == 'schedule'
    needs: collect-open-prs
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        pr: ${{ fromJson(needs.collect-open-prs.outputs.numbers) }}
    environment:
      name: ai-review
      deployment: false
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ matrix.pr }}/merge
      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: workspace-write
          safety-strategy: drop-sudo
          prompt: "Re-review PR #${{ matrix.pr }} and focus on unresolved issues."

この構成にすると、PR発生時レビューと、平日朝の定期再レビューを同じワークフローで回せます。まずはlimit: 5くらいから始めると、API利用量の見積もりもしやすいです。

運用編：詰まりやすいポイントとFAQ

実装後に詰まりやすい論点を、短くFAQでまとめます。ここを先に知っておくと、導入直後のトラブルがかなり減ります。

Q1. schedule実行でPR情報が取れないのはなぜですか？

scheduleイベントにはgithub.event.pull_requestが入りません。だから先にgh pr listでPR番号を集めて、matrixで回す設計が必要です。

Q2. prompt injectionはどう防げばいいですか？

PR本文やブランチ名などの未検証入力を、シェルに直接埋め込まないことです。GitHub式展開は先に解釈されるので、env経由にしてクォートする運用に統一すると安全です。

Q3. read-onlyなら安全ですよね？

そこは誤解されやすいです。権限設計が甘いと秘密情報露出のリスクは残ります。Codex Actionではsafety-strategy: drop-sudoかunprivileged-userを明示する運用がおすすめです。

ちなみに記事運用でも、比較→手順→失敗回避の構成は再現性が高くて、実データで358PV・161engのように反応が伸びた週がありました。開発運用でも同じで、構造化して伝えるとチームの再現性が上がります。

この設定を後回しにすると起きやすい3つの損失

PR自動レビューを知らないままだと、チームの負債が静かに積み上がる可能性があります。危機感を煽りたいわけではなく、早めに気づけると楽になるという話です。

• レビュー待ちの慢性化 — 朝イチで見るPRが毎日増え、実装時間を圧迫します
• 指摘品質のブレ — レビュアー依存が強まり、同じミスが再発しやすくなります
• 時刻ズレ運用 — UTC運用のままだと通知と実働時間がズレ、改善サイクルが遅れます

つまり、放置のコストは「技術負債」より先に「時間負債」として表面化しやすいです。

この記事を書いている理由

僕自身、SESでの実装、非IT職種の教育設計、そして今の福祉領域×AI開発という流れを通して、「良い仕組みがないと、良い人が疲弊する」場面を何度も見てきました。550名以上の面談でも、伸びる人ほど気合いではなく仕組みを作っていました。

だからこそ、PRレビューも根性論ではなく、自動化と人の判断を分けて回す形を伝えたいんです。僕が現場で試して、失敗して、改善してきたやり方だから、同じ悩みの人にそのまま渡せると思っています。

次のアクション

まずは小さく始めるのが最短です。1リポジトリ、平日1回のschedule、PR5本まで。この設定で2週間回すだけでも、レビューの詰まり具合はかなり見えるようになりますよ。