GitHub ActionsでCodexを動かすには?始め方や活用法も解説
GitHub ActionsでCodexを動かすにはどうすればいいんだろう?
設定とか難しそうだけど、初心者でも使えるのかな…
Codexを使い始め、GitHub Actionsでも使えるのか気になっている人は多いですよね。
ただ、いざ使おうにもどう繋げばいいのかわからない人もいるはず。
そこでこの記事では、必要なものやつなぐことで変わることも交え、GitHub ActionsでCodexを動かす手順を解説します。トラブル時の対処法やセキュリティ面の注意点も紹介するので、ぜひ参考にしてください。
前提となるCodexとGitHubを連携する方法を詳しく知りたい人は、次の記事を参考にしてください。

- CodexとGitHub Actionsを連携するにはOpenAI APIキーとLinux/macOSランナーが必要
- codex-actionを利用することでIssue対応やPRレビューなどを自動化できる
- サンドボックスや安全戦略を適切に設定することで誤操作や意図しない変更を防げる
『ClaudeCodeに興味はあるけど、どうやって使えばいいんだろう…』
そんな方へ、
- ClaudeCodeに作業や仕事を任せる方法
- ClaudeCodeを使いこなすたった1つのコツ
- 業務効率化や収入獲得に活かすClaudeCodeの実演
を、無料のオンラインセミナーで凝縮してお伝えします!
パソコンはもちろん、スマホから気軽に参加OK。この時間が、あなたを変える大きなきっかけになりますよ。
GitHub ActionsでCodexを動かすと何が変わる?

GitHub ActionsでCodexを動かすと、Issueへの対応やプルリクエスト(PR)レビューといった手作業をAIに任せられるようになります。
通常、Issueの内容を確認し、関連するコードを修正してPRを作成するまでには数十分から数時間かかります。CodexをGitHub Actionsと連携すれば、Issueの作成をきっかけにAIがリポジトリを分析し、修正案の作成やPRの生成まで自動で実行できます。
たとえば「バリデーションを追加してほしい」というIssueを作成するだけで、Codexがリポジトリの構造を読み取り、対象ファイルを特定して修正案を含むPRを作成できます。
開発者は、生成されたコードを確認して承認・修正するだけで済むため、定型的な作業にかかる時間を大幅に削減可能です。
また、PRが作成されたタイミングでCodexによるコードレビューを自動実行することも可能です。バグの可能性や改善点、命名規則のばらつきなどをチェックできるため、レビュー品質の向上にもつながります。
このように、GitHub ActionsとCodexの連携することで、開発プロセスの自動化が進み、チーム全体の開発効率とコード品質の向上が期待できます。
GitHub ActionsでCodexを動かすのに必要なもの

GitHub ActionsでCodexを動かすには、事前にいくつか準備が欠かせません。ここからは最低限そろえておきたいものを2つにまとめて解説します。
1.OpenAI APIキー
Codexを利用するには、OpenAI APIキーが必要です。APIキーはOpenAIのプラットフォーム画面から発行できます。
OpenAI Platformにログインし「API keys」メニューから新しいAPIキーを作成してください。APIキーは作成時に一度しか表示されないため、必ず安全な場所に保存してください。
なお、OpenAI APIはトークン単位の従量課金制です。GitHub Actionsの実行回数や処理内容によって利用料金が変動するため、あらかじめ利用上限を設定しておくと安心です。
APIキーを発行したら、GitHub Secretsへ登録します。具体的な手順は、後述する「APIキーをGitHub Secretsに登録する」で詳しく説明します。
2.Linux/macOSランナー
Codexを利用するGitHub Actionsのワークフローでは、LinuxまたはmacOSランナーを使用します。
ワークフローファイル内の`runs-on`で実行環境を指定し、一般的には`ubuntu-latest`または`macos-latest`を選択します。
GitHubが提供するホステッドランナー(GitHub側で用意されたサーバー)を使えば、自分でサーバーを構築・管理する必要はありません。無料利用枠も用意されているため、個人開発や小規模なチームでも手軽に導入可能です。
一方、セルフホステッドランナーを使う場合は、Node.jsやGitなどCodexの実行に必要なツールをあらかじめインストールしておく必要があります。環境構築や保守も自身で行う必要があるため、運用コストも考慮して選択しましょう。
LinuxでCodexを使う方法を詳しく知りたい人は、次の記事を参考にしてください。

GitHub ActionsでCodexは使うべき?

結論として、繰り返し発生する定型作業が多い開発チームには、GitHub ActionsとCodexの導入がおすすめです。
たとえば、日常的にIssueが作成され、軽微なバグ修正やドキュメント更新、リファクタリングなどが頻繁に発生するプロジェクトでは1件ずつ手作業で対応すると多くの時間がかかります。Codexを活用すれば、こうした定型的な作業を自動化できるため、開発者は設計や新機能の実装など、より重要な業務に集中できます。
一方、次のようなケースではCodexの導入効果を感じにくい場合もあります。
- リポジトリの更新頻度が低く自動化できる作業が少ない
- セキュリティポリシーにより外部APIへのコードを送信できない
- AIが生成したコードをレビューする担当者がいない
また、Codexが生成したコードは、そのまま本番環境へ反映するのではなく、必ず人が内容を確認することが重要です。AIは作業を効率化できますが、コードの正確性や要件への適合性を保証するものではありません。
そのため、「AIだけで開発を完結させる」のではなく、AIがコードを作成し、人がレビュー・承認するという運用を前提に導入すると、安全かつ効果的に活用できます。
導入前にチームの作業内容を棚卸しし、Codexで効率化できる範囲を確認するのが判断のポイントです。
Codexの使い方を詳しく知りたい人は、次の記事を参考にしてください。

GitHub ActionsでCodexを動かす手順

GitHub ActionsでCodexを利用するまでの流れは、全部で9ステップあります。
ここからはCodexを動かすまでの手順を、9つにまとめて解説します。
1.APIキーをGitHub Secretsに登録する
まず、OpenAI APIキーをGitHub Secretsへ登録します。APIキーをワークフローファイルへ直接書くと第三者に漏れるリスクがあるため、必ずSecretsを使ってください。
手順は次のとおりです。
- GitHubのリポジトリを開く
- 「Settings」タブをクリックする
- 左メニューから「Secrets and variables」→「Actions」を選ぶ
- 「New repository secret」ボタンを押す
- Nameに`OPENAI_API_KEY`と入力する
- Secretの欄にAPIキーを貼り付けて「Add secret」を押す
登録後は、ワークフロー内で`${{ secrets.OPENAI_API_KEY }}`として参照できます。Secretsの値は画面上に表示されないため、安全に管理できます。
CodexでのAPI利用について詳しく知りたい人は、次の記事を参考にしてください。

2.プロンプトファイルを用意する
次に、Codexへの指示内容を与えるためのプロンプトファイルを作成します。
Codexでは、リポジトリのルートに配置したAGENTS.mdを参照し、プロジェクト固有のルールやコーディング方針に沿ってコードを生成できます。
たとえば、次のような内容を記載します。
“`
コーディング規約
・変数名はキャメルケースを使用する
・関数には必ずJSDocコメントを付ける
・console.logはデバッグ用途以外で残さない
禁止事項
・外部ライブラリは事前承認なしで追加しない
・テストを伴わないコード変更は行わない
使用技術
・TypeScript 5.x
・React 18
・Node.js 20
“`
AGENTS.mdを用意しておくことで、プロジェクトのルールに沿ったコードを生成しやすくなります。
3.ワークフローファイルを作成する
続いて、GitHub Actionsのワークフローを作成します。
.github/workflows/ディレクトリに、codex.ymlなど任意の名前でYAMLファイルを作成してください。
基本的な構成は次のとおりです。
```yaml
name: Codex Automation
on:
issues:
types: [opened, labeled]
pull_request:
types: [opened, synchronize]
jobs:
codex-run:
runs-on: ubuntu-latest
steps:
uses: actions/checkout@v4
```
onではワークフローを実行するタイミングを指定します。Issueの作成時やPRの更新時など、用途に応じて設定しましょう。
4.’codex-action’を呼び出す
ワークフローファイルのsteps内に、codex-actionを呼び出す記述を追加します。codex-actionはOpenAIが公開しているGitHub Actions用のアクションです。
```yaml
uses: openai/codex-action@v1
with:
api_key: ${{ secrets.OPENAI_API_KEY }}
prompt
このIssueの内容を分析し、修正案をPRとして提出してください。
```
`with`セクションで、APIキーとプロンプトを指定します。プロンプトを直接記載する方法のほか、AGENTS.mdを併用してプロジェクトのルールを反映させることもできます。
codex-actionのバージョンは`@v1`のようにメジャーバージョンを指定すると、互換性を維持したアップデートを受けられます。動作を固定したい場合は`@v1.x.x`のようにバージョンを明示すると安心です。
5.サンドボックスを設定する
続いて、Codexがアクセスできる範囲を制限するために、サンドボックスの設定を行います。
サンドボックスとは、Codexがアクセスできるファイルやネットワークを限定する仕組みです。
```yaml
with:
sandbox: true
allowed_paths:
src/
tests/
```
上記では、`src/`と`tests/`ディレクトリ内のファイルのみ読み書きを許可しています。
設定ファイルやインフラ関連のディレクトリを除外することで、意図しない変更を未然に防止できます。
サンドボックスを無効にすると、Codexはリポジトリ全体にアクセス可能です。本番環境に影響するファイルを誤って書き換えるリスクがあるため、基本的には有効にして運用しましょう。
CodexのSandboxについて詳しく知りたい人は、次の記事を参考にしてください。

6.安全戦略を設定する
安全戦略は、Codexの動作モードを制御する設定です。次の3段階から選べます。
| 安全戦略 | 動作内容 | おすすめの場面 |
|---|---|---|
| suggest | 提案のみ、ファイル変更なし | 初期導入・動作確認 |
| auto-edit | ファイル変更を行う | 日常的なコード修正 |
| full-auto | ファイル変更とコマンド実行を行う | 十分に検証した自動化環境 |
設定例は次のとおりです。
```yaml
with:
safety_strategy: auto-edit
```
初めて導入する場合は`suggest`モードで動作を確認し、問題がなければ`auto-edit`へ移行すると安心です。`full-auto`は影響範囲が大きいため、十分にテストした後に使ってください。
Codexのおすすめ設定を詳しく知りたい人は、次の記事を参考にしてください。
7.実行権限を制限する
ワークフローの実行権限を制限すると、Codexがリポジトリに対して行える操作を明示的に管理できます。
```yaml
permissions:
contents: write
pull-requests: write
issues: read
```
この例では、コードの更新とPRの作成を許可しつつ、Issueの内容は読み取りのみに制限しています。
不要な権限を付与しないことで、誤操作やセキュリティリスクを低減できます。GitHub Actionsでは「最小権限の原則」を意識して設定することが重要です。
Codexの利用制限について詳しく知りたい人は、次の記事を参考にしてください。

8.実行結果をPRにコメントさせる
Codexの実行結果をPRのコメントとして自動投稿する設定を追加すると、レビュアーが変更内容を確認しやすくなります。
```yaml
uses: actions/github-script@v7
with:
script:
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: 'Codexの分析が完了しました。修正案を確認してください。'
})
```
actions/github-scriptを利用すると、GitHub APIを呼び出してコメントを投稿できます。
コメントには、修正内容の要約や変更ファイル一覧などを含めると、レビューの効率がさらに向上します。
9.動作確認する
最後に、設定したワークフローが正しく動作するか確認します。
- テスト用の新しいIssueを作成する
- Codexへの指示をIssue本文に記載する
- Issueを保存し「Actions」タブを開く
- ワークフローが実行されているか確認する
- 実行ログでエラーがないかチェックする
- PRやレビュー結果が自動作成されていれば成功
ワークフローが実行されない場合は、`on`で設定したトリガーや、Issueのラベル条件などを確認してください。
初回はコメントの追加やタイポ修正など、影響範囲の小さいタスクで動作確認を行うと、問題を切り分けやすくなります。
GitHub ActionsでCodexが動かない時の対処法

GitHub ActionsでCodexが期待どおりに動作しない場合は、まずエラーログを確認しましょう。
GitHubのActionsタブから対象のワークフローを開くと、各ステップの実行ログを確認できます。ログにはエラーの原因が記録されていることが多いため、問題の切り分けに役立ちます。
よくあるエラーと対処法を次の表にまとめました。
| エラーの症状 | 主な原因 | 対処法 |
|---|---|---|
| ワークフローが実行されない | トリガー条件の設定ミス | onセクションのイベントや条件を確認する |
| APIキーに関するエラーが表示される | GitHub Secretsの設定ミス | OPENAI_API_KEYの名前や値を再確認する |
| 権限エラーが発生する | 権限設定が不足している | permissionsに必要な権限を追加する |
| ワークフローがタイムアウトする | プロンプトや処理内容が複雑すぎる | プロンプトを簡潔にし、処理を分割する |
| ランナーエラーが発生する | 実行環境の設定ミス | runs-onにubuntu-latestまたはmacos-latestを指定するに変更する |
エラーメッセージをそのまま検索すると、GitHubのコミュニティやStack Overflowで解決策が見つかるケースも多くあります。
それでも原因が特定できない場合は、ワークフローファイルを最小構成(checkout+codex-actionのみ)に戻し、1つずつ設定を追加しながら動作を確認していく方法がおすすめです。設定を段階的に追加することで、問題の原因を特定しやすくなります。
GitHub ActionsでCodexが動かす際の注意点

GitHub ActionsでCodexを運用する際は、コストとセキュリティの両面に注意が必要です。
まず、コスト面について確認すべきポイントは次のとおりです。
- OpenAI APIはトークン単位の従量課金で利用料金が発生する
- ワークフローの実行回数が増えるほどAPI利用料金も高くなる
- OpenAIの管理画面で利用上限(Usage Limits)を設定しておくと安心
次に、セキュリティ面の注意点です。
- APIキーは必ずGitHub Secretsに格納し、ワークフローファイルに直接記載しない
- フォーク元のリポジトリからのPRでワークフローを実行する場合は、イベントの設定を慎重に行う
- Codexが生成したコードは必ず人の目でレビューしてからマージする
とくに、外部のコントリビューターがフォークしたリポジトリからPRを送る場合は注意が必要です。
意図しないプロンプトでCodexが操作されるリスクがあります。
たとえば、通常のpull_requestイベントでは、フォーク元のプルリクエストからGitHub Secretsへアクセスできません。一方、pull_request_targetイベントではSecretsへアクセスできるため、設定を誤ると機密情報が漏えいするリスクがあります。
そのため、pull_request_targetを利用する際は、実行条件や対象ブランチを十分に検討したうえで設定しましょう。
また、APIコストを把握するためには、1回のワークフローで消費するトークン数を計測し、月間の実行回数をもとに概算費用を試算しておくことをおすすめします。
運用開始後も定期的に利用状況を確認し、必要に応じてワークフローやプロンプトを見直すことで、コストを抑えながら効率的に運用できます。
GitHub ActionsでCodexが動かす時によく抱く疑問

ここからはGitHub ActionsでCodexを利用する際によくある疑問を、2つにまとめて解説します。
プライベートリポジトリで動く?
プライベートリポジトリでもCodexを利用できます。GitHub Actionsは、パブリック・プライベートを問わず利用可能です。
ただし、プライベートリポジトリではGitHub Actions利用時間にプランごとの上限があります。無料利用枠を超えると追加料金が発生するため、ワークフローの実行回数が多い場合は利用状況を定期的に確認しましょう。
また、GitHub Actionsの実行環境とは別に、Codexを利用する際にはOpenAI APIの利用料金も発生します。GitHub ActionsとOpenAI APIの両方のコストを考慮して運用することが大切です。
なお、プライベートリポジトリであっても、Codexが処理を行うために必要なコードはOpenAI APIへ送信されます。次の「コードや個人情報はどう扱われる?」も必ず確認してください。
コードや個人情報はどう扱われる?
Codexを使うと、処理対象となるコードがOpenAIのAPIサーバーに送信されます。
OpenAI APIでは、API経由で送信されたデータはデフォルトでモデルの学習には利用されません。ただし、機密情報や個人情報を不用意に送信しないよう、事前にリポジトリの内容を確認することが重要です。
運用時は、次のような対策を講じてください。
- APIキーやパスワードなどの認証情報をコードへハードコーディングしない
- `.env`ファイルや設定ファイルをサンドボックスの対象外にするなど、アクセス範囲を適切に制限する
- 個人情報を含むテストデータはダミーデータに置き換える
また、社内のセキュリティポリシーで外部APIへのコード送信が禁止されている場合は、導入前に情報システム部門やセキュリティ担当者へ確認しておくと安心です。
まとめ
本記事では、GitHub ActionsでCodexを動かす手順と活用法を解説しました。
GitHub ActionsとCodexを連携することで、Issue対応やPRレビュー、コード修正の提案など、繰り返し発生する開発業務を自動化できます。一方で、安全に運用するためには、APIキーの適切な管理やサンドボックス・権限設定、人によるコードレビューを組み合わせることが重要です。
まずは`suggest`モードで動作確認を行い、IssueやPRレビューの自動化から試してみましょう。
