CodexをGitHub Actionsで使う方法｜CI/CDにAIレビューを組み込む手順

本記事を読めば、CodexをGitHub Actionsで実行し、PRレビューや反復タスクをCI/CDに組み込んで品質確認を自動化できるようになります。

AIzen株式会社は、AIエージェントを活用した開発支援やCI/CD改善を行う中で、AIレビューは「実行できること」より「安全な権限で継続運用できること」が重要だと考えています。

本記事では、openai/codex-actionとGitHub Secretsを使った実務手順を解説します。

GitHub ActionsでCodexを実行する仕組み

CodexはGitHub Actions上で openai/codex-action を使って実行できます。OpenAI公式ドキュメントでは、Codex CLIのインストールやResponses APIへの安全なプロキシ設定をAction側が扱い、PRレビュー結果を後続ステップでコメント投稿する例が示されています。CIに組み込む際は、Codexに何を読ませ、どの権限で、どこへ結果を返すかを明確にすることが重要です。

codex execの自動実行

GitHub ActionsでCodexを使う基本は、workflowの中でCodexにプロンプトを渡し、codex exec 相当の処理を非対話で実行することです。openai/codex-action@v1 では、prompt または prompt-file、output-file、codex-args、sandbox などの入力を使って動作を調整できます。

たとえば、.github/codex/prompts/review.md にレビュー観点を書いておき、PR作成時にそのプロンプトでCodexを実行します。最終メッセージをファイルやAction outputとして受け取り、後続ジョブでPRコメントに変換します。これにより、人が毎回同じレビュー観点を入力しなくても、CI上で標準化されたAIレビューを実行できます。

PRレビューと品質チェック

PRレビューにCodexを使う場合、静的解析やユニットテストの置き換えではなく、補助的なレビュー担当として扱うのが現実的です。Codexには、差分の意図と実装の整合、テスト不足、セキュリティ上の注意点、命名や設計の違和感などを確認させます。既存のlint、型チェック、テストはそのままCIで実行し、Codexは人間レビュー前の追加視点として使います。

AIレビューを入れるときは、レビュー観点をAGENTS.mdやprompt-fileに固定します。たとえば「破壊的変更」「権限まわり」「入力検証」「例外処理」「テスト不足」を必ず見る、といった形です。AIレビューの品質は、モデルだけでなく、リポジトリごとの指示書とCI権限設計で決まります。

反復タスクのCI組み込み

CodexはPRレビューだけでなく、依存関係更新時の影響要約、テスト失敗ログの原因候補整理、ドキュメント更新漏れの確認などにも使えます。

ただし、CIで自動実行するタスクは範囲を絞るべきです。対象を限定したほうが、結果を評価しやすくなります。

GitHub ActionsでCodexを設定する手順

GitHub ActionsでCodexを動かすには、APIキーの登録、workflowファイルの作成、checkoutと権限の設定が必要です。OpenAI公式のサンプルworkflowでも、actions/checkout@v5 の後に openai/codex-action@v1 を実行し、PRへ結果を投稿する流れが示されています。設定では、SecretsとGITHUB_TOKENの権限を分けて考えます。

OPENAI_API_KEYのSecrets登録

openai/codex-action を使うには、選択したプロバイダーのAPIキーをGitHub Actions secretとして登録します。OpenAIを使う場合は OPENAI_API_KEY、Azure OpenAIを使う場合は AZURE_OPENAI_API_KEY などを使う構成が公式READMEで説明されています。APIキーはworkflowファイルに直接書かず、必ずSecrets経由で渡します。

Repository Secretsに登録する場合は、対象リポジトリだけで使うのか、Organization Secretsとして複数リポジトリに配布するのかを決めます。最初のPoCでは、対象リポジトリのRepository Secretに限定し、利用量とログを確認してから広げるのが安全です。

workflowファイルの基本構成

基本構成は、PRイベントで起動し、checkoutし、Codexを実行し、必要に応じて結果をPRコメントへ投稿する流れです。OpenAI公式ドキュメントの例では、pull_request で起動し、openai/codex-action@v1 に openai-api-key と prompt-file を渡しています。

実務では、workflow、prompt-file、Codex実行ジョブ、コメント投稿ジョブを分けると管理しやすくなります。Codexに必要な権限と、PRへコメントする権限を分けると、レビューしやすくなります。

checkoutと実行権限の設定

Codexがリポジトリ内容を読めるようにするには、actions/checkout が必要です。OpenAI公式READMEでも、Codexがリポジトリ内容へアクセスできるように、Actionはcheckout後に実行することが推奨されています。PRレビューでは、対象PRのmerge refやhead refをどうcheckoutするかも重要です。

また、GITHUB_TOKEN の権限は最小化します。GitHub公式ドキュメントでは、permissions キーでworkflow全体またはjob単位の権限を制御し、必要最小限のアクセスを付与することが推奨されています。Codex実行ジョブは読み取り中心、コメント投稿ジョブは必要な書き込み権限だけに限定します。

PRレビュー自動化の作り方

PRレビュー自動化では、起動イベント、レビュー結果の出力、PRコメント投稿、リポジトリ固有の指示書を組み合わせます。指摘品質を見ながらプロンプトと対象イベントを調整します。

pull_requestイベントの指定

PRレビューでは、pull_request イベントを使うのが基本です。opened、synchronize、reopened を指定すると、新規作成、更新、再オープン時に実行できます。必要に応じてpathsやブランチ条件で絞ります。

pull_request_target はSecretsや書き込み権限を扱える場面がありますが、外部からのPRコードと組み合わせると危険な構成になり得ます。AIレビューでSecretsを使う場合は、GitHub公式ドキュメントを確認し、fork PRで秘密情報が露出しない構成にします。迷う場合は、まず内部リポジトリや信頼できるブランチに限定してPoCを行うのが安全です。

レビュー結果の投稿設定

Codexの結果をPRへ投稿するには、Action outputや output-file を使って最終メッセージを受け取り、actions/github-script やGitHub CLIでコメントします。

コメント投稿には、issues: write や pull-requests: write などの権限が必要です。リポジトリ設定やOrganization policyによっては投稿できないこともあります。投稿に失敗した場合は、GITHUB_TOKENのpermissions、イベント種別、fork PRかどうか、ブランチ保護設定を順に確認します。

AGENTS.mdとの組み合わせ

AGENTS.mdは、Codexにリポジトリ固有の開発ルールを伝えるために有効です。レビュー観点、テストコマンド、禁止したい変更、ファイル構成、ドメイン知識をAGENTS.mdに書いておくと、AIレビューの指摘がプロジェクトに合いやすくなります。prompt-fileにはPRレビューの目的を書き、AGENTS.mdには継続的に参照すべき開発ルールを書く分担がよいです。

AGENTS.mdには、セキュリティ上必ず見る観点、実行すべきテスト、触ってはいけない生成ファイル、API互換性やDB migrationの注意点を書きます。これにより、Codexレビューがリポジトリの文脈に沿った内容になります。

CI運用時の注意点

CodexをCIに入れると、レビュー前の確認が増える一方で、runner権限、Secrets、OS差分、投稿権限の管理が必要になります。特にAIエージェントはコードを読み、コマンド実行やファイル出力を行う可能性があるため、通常のCIジョブ以上に権限境界を意識します。

Linux・macOS runnerの選定

OpenAI公式READMEでは、Linux/macOSではsafety-strategyの全オプションがサポートされる旨が説明されています。GitHub-hosted Linux runnerでは、Codexのサンドボックス実行に関わる設定もAction側で調整されるとされています。一般的なPoCでは、まず ubuntu-latest などLinux runnerから始めるのが扱いやすいです。

AIレビューだけならLinuxで十分なケースが多いため、実行目的に合わせてrunnerを選びます。

Windows runner利用時の確認

Windows runnerを使う場合は、Codex CLIやActionのサポート状況、サンドボックス、パス表記、シェルの違いを確認します。Windows対応の扱いは、公式ドキュメントとAction READMEを確認した上で設計してください。

Windows固有の検証が必要なリポジトリでは、CodexレビューはLinuxで実行し、Windowsビルドは別jobで行う分離も考えられます。

PRコメント投稿権限の確認

PRコメント投稿で詰まりやすいのは、GITHUB_TOKENの権限不足です。GitHub公式ドキュメントでは、permissions キーで contents: read、issues: write などを明示できるとされています。

また、外部forkからのPRではSecretsやwrite権限の扱いが制限されることがあります。外部PRではCodexレビューをスキップする、結果をartifactに保存するだけにするなど、条件分岐を入れます。Secretsを使うAIレビューでは、イベント種別と権限を必ずセットで確認することが重要です。

弊社エンジニアからのコメント：

CodexのGitHub Actions導入では、最初からPRコメント投稿まで自動化するより、まずartifactやjob summaryにレビュー結果を出すだけのPoCが安定します。

指摘品質と実行時間を見たうえで、コメント投稿権限を追加すると安全です。特にfork PRを受けるリポジトリでは、Secretsの扱いとpull_request_targetの使い方を慎重に確認してください。

CI/CD改善の進め方

CodexをGitHub Actionsへ組み込む目的は、AIレビューを増やすことではなく、開発チームのレビュー品質とCI/CDの流れを改善することです。導入時は、対象リポジトリ、評価指標、相談範囲を決めて小さく始めます。

PoC対象リポジトリの選定

PoCは、変更頻度が高く、レビュー観点がある程度決まっているリポジトリから始めます。認証や決済など高リスク領域から始めるより、社内ツール、管理画面、ドキュメント多めのリポジトリなど、影響範囲を管理しやすい対象が向いています。

選定基準は、PR数が一定以上あること、既存CIが整っていること、AGENTS.mdに開発ルールを整理しやすいこと、Secretsや外部PRの扱いが複雑すぎないことです。最初の1〜2週間でレビュー結果を蓄積し、プロンプトや対象イベントを調整します。

レビュー指摘の品質評価

AIレビューの品質は、指摘数ではなく、採用された指摘、不要だった指摘、見逃した観点で評価します。レビューコメントごとに「対応した」「不要だった」「誤りだった」を軽く分類すると、プロンプト改善の材料になります。

また、Codexは定型的な品質観点を担い、人間は仕様判断、プロダクト影響、設計方針を確認する、といった分担が現実的です。

CI/CD改善支援に相談する範囲

CodexのGitHub Actions導入で相談すべき範囲は、workflow作成だけではありません。APIキー管理、GitHub権限設計、AGENTS.md整備、レビュー観点のプロンプト化、既存CIとの役割分担、運用後の評価指標まで含めると、継続的に使える仕組みになります。

AIzen株式会社では、AIレビューの導入支援に加えて、CI/CDの設計、セキュリティ観点の権限整理、社内開発プロセスへのAIエージェント組み込みまで支援しています。単発のAction追加ではなく、チームのレビュー運用に合う形で設計することが重要です。

まとめ

CodexをGitHub Actionsで使うと、PRレビューや反復タスクをCI/CDに組み込み、レビュー前の確認を自動化できます。要点は次の3つです。

• openai/codex-action@v1、GitHub Secrets、prompt-fileを組み合わせ、Codex実行とコメント投稿を分けて設計する
• GITHUB_TOKENのpermissions、fork PR、runner OS、Secretsの扱いを確認し、最小権限で運用する
• PoCでは小さな対象から始め、指摘品質と実行時間を評価しながらAGENTS.mdとプロンプトを改善する

AIzen株式会社では、Codexを使ったAIレビューのCI/CD組み込み、GitHub Actions設計、AGENTS.md整備、レビュー品質評価まで一貫して支援しています。AIレビューを開発フローに安全に入れたい場合は、現状のCI構成の確認から無料でご相談ください。