3行まとめ
非対話実行は調査と差分作成から始めます。
read-only、workspace-write、full accessを分けます。
write、push、外部投稿は人間レビューへ戻します。
CIでは、動くことより止まる条件を先に決めます。
- Codex CLIをCIで使うなら、最初に任せるのは無人マージではなく、
codex execによるread-only調査、差分案、検証ログ作成です。 read-only、workspace-write、danger-full-accessを同じ「自動実行」として扱わず、sandbox、CI token、secret、外部通信、PR権限を別々に制限します。- 成功条件は「Codexが修正できた」ではなく、差分、実行コマンド、失敗条件、未検証範囲、人間レビューへ戻す材料が残ることです。
本文の事実確認には、OpenAIのCodex CLI関連ドキュメント、openai/codex GitHub README、npm公開メタデータ、GitHub Actions公式ドキュメントを使っています。Xで伸びていたCodex自動化やAGENTS.md関連の投稿は需要シグナルとして扱い、本文の根拠にはしていません。2026年5月31日時点で npm view @openai/codex version dist-tags --json を確認し、latest は 0.135.0 でした。
この記事でわかること
execで任せる仕事を決められます。
sandboxとCI権限を分けられます。
失敗時に進めない条件を作れます。
PRレビューへ戻す流れを作れます。
自動化の目的を、無人マージではなくレビュー可能な差分作成に置きます。
codex execをCIで使うときに任せる範囲- sandboxをread-only、workspace-write、danger-full-accessに分ける見方
- GitHub Actionsでsecretやtoken権限を広げすぎない考え方
- AGENTS.mdとプロンプトを自動実行向けに固定する方法
- 失敗時に止める条件と、人間レビューへ戻す判断基準
前提知識
| 項目 | 内容 | 見方 |
|---|---|---|
| npm | `@openai/codex` 0.135.0を確認しました。 | |
| exec | 非対話実行用の `codex exec` が案内されています。 | |
| sandbox | read-only、workspace-write、danger-full-accessを分けます。 | |
| AGENTS.md | リポジトリ内の作業指示として使います。 |
ツール更新が速いため、導入時には公式情報を再確認します。
Codex CLIは、ローカル環境でコードを読み、編集し、コマンド実行を支援するCLI型のコーディングエージェントです。openai/codexのREADMEでは、npm、Homebrew、GitHub Releasesから導入できること、Rust実装が現在のCodex CLIとして案内されていること、codex execで非対話実行できること、sandbox方針を選べることが説明されています。
ここでいうCI利用は、GitHub ActionsなどでCodex CLIを動かし、Issue、テスト失敗、依存更新、ドキュメント更新、軽微な修正の候補を作る運用です。重要なのは、CIで動かすことと、CIに本番権限を渡すことを分けることです。
interactive利用とexec利用の違い
ローカルのinteractive利用では、Codexの提案を見ながら承認できます。一方、codex execは非対話でタスクを走らせるため、途中判断を人間が細かく挟みにくくなります。だからこそ、事前にプロンプト、sandbox、CI token、対象branch、停止条件を固定する必要があります。
条件
CIで最初に使うなら、調査、要約、テスト失敗の原因整理、差分案の作成までに絞ります。push、release、外部API POST、Issue/PRへの自動投稿は別段階にします。
注意点
非対話実行は便利ですが、曖昧な依頼を渡すと、意図しないファイル変更や長時間実行につながります。対象path、実行してよいコマンド、触ってはいけない設定、失敗時の報告形式を短く固定してください。
codex execは何を自動化するのか
- 1調査
差分、ログ、テスト失敗を読むだけにします。
- 2計画
変更方針とリスクを出します。
- 3差分
workspace内の修正案を作ります。
- 4検証
lint、typecheck、testを実行します。
最初からpushや外部投稿まで任せないほうが安全です。
openai/codexのREADMEでは、codex exec PROMPTでCodexを非対話的に実行でき、promptをstdinから渡せることが説明されています。出力はターミナルへ表示され、必要に応じて環境変数でログを詳しくできます。
CIでの使いどころは、次のような作業です。
| 目的 | 任せやすい範囲 | まだ人間に戻す範囲 |
|---|---|---|
| テスト失敗の調査 | 失敗ログ、関連ファイル、疑わしい原因の整理 | 修正方針の採用、マージ判断 |
| ドキュメント更新 | README、CHANGELOG、手順書の差分案 | 公開文言、契約・価格・法務表現 |
| 依存更新候補 | npm outdated、changelog、影響範囲整理 | major update、lockfile採用、release判断 |
| 軽微な修正 | lint、typecheck、testを通る小さな差分 | API変更、DB変更、認証・決済周辺 |
execで最初に避けたいこと
いきなり「Issueを見て修正してpushして」と頼むと、調査、実装、検証、投稿、権限の境界が混ざります。CIではまず、次のように分けるほうが安全です。
このジョブでは調査と差分作成だけをしてください。
許可する作業:
- src/ と tests/ の関連ファイルを読む
- npm test の失敗ログを読む
- 必要なら workspace 内の修正案を作る
禁止:
- git push
- release tag 作成
- 外部APIへのPOST
- secretや.envの表示
最後に、変更ファイル、実行コマンド、失敗したコマンド、未検証範囲を報告してください。評価基準
CIでの合格は、Codexが自信ありげに完了報告することではありません。git diff、テスト結果、失敗ログ、未検証範囲、レビュー観点が残っていることを合格条件にします。
CIに入れる前に決める境界
| 項目 | 内容 | 見方 |
|---|---|---|
| 対象 | repo、branch、path、issue種別を絞ります。 | |
| 権限 | read、write、PR作成、pushを分けます。 | |
| secret | 入力、ログ、差分に出さない方針を決めます。 | |
| 成果物 | ログ、patch、PR、コメントのどれを残すか決めます。 |
境界が曖昧なままCIへ入れると、失敗時に止めにくくなります。
Codex CLIをCIに入れる前に、少なくとも次の境界を決めます。
| 境界 | 決めること | 例 |
|---|---|---|
| 対象 | どのrepo、branch、path、Issue種別を扱うか | src/とtests/だけ |
| 権限 | read、write、PR作成、pushをどう分けるか | 最初はworkspace差分まで |
| secret | どの環境変数を渡すか | OPENAI_API_KEY以外は渡さない |
| 成果物 | 何を残すか | patch、ログ、PR本文、artifact |
| 停止条件 | 何が起きたら失敗にするか | test失敗、差分過大、secret検出 |
CI tokenの権限を最小化する
GitHub Actionsでは、workflowごとにpermissionsを明示できます。Codexが差分を作るだけなら、最初から広いcontents writeを渡す必要はありません。PR作成まで行う場合でも、pull-requestsやcontentsの権限を必要最小限にし、外部PRやfork由来のイベントではsecretを渡さない設計にします。
確認項目
permissionsをworkflow内で明示しているか- 外部PRでsecretを使うjobが走らないか
- push権限とPR作成権限を分けているか
- Codexの出力ログにsecretやtokenが出ないか
- artifactに
.envや秘密情報が混ざらないか
sandboxは3段階で考える
調査、要約、計画に使います。
差分作成まで許可します。
隔離済み環境以外では避けます。
CIではworkspace-writeでも、tokenや外部通信を別に絞る必要があります。
openai/codexのREADMEでは、sandbox方針として read-only、workspace-write、danger-full-access が例示されています。名前の通り、危険度が違います。
| sandbox | CIでの扱い | 向いている作業 |
|---|---|---|
read-only | 最初の標準 | 調査、要約、原因分析、計画 |
workspace-write | 差分作成時だけ | lint修正、テスト修正、README更新 |
danger-full-access | 原則避ける | 既に隔離されたコンテナ内の検証など |
workspace-writeでも安全ではない
workspace-writeは、現在のworkspace内の変更を許す方針です。しかし、CI tokenやsecretを広く渡していれば、workspace外の被害が起こる可能性があります。sandboxとCI権限は別物として扱います。
注意点
自動実行で danger-full-access を使うなら、少なくとも使い捨て環境、最小secret、外部通信の制御、実行時間制限、成果物の監査が必要です。通常のリポジトリCIで最初に選ぶ設定ではありません。
GitHub Actionsでは権限を分ける
| 項目 | 内容 | 見方 |
|---|---|---|
| pull_request | 外部PRではsecretを渡さない設計にします。 | |
| workflow_dispatch | 手動承認つきの検証入口にします。 | |
| schedule | 定期調査や依存更新候補の洗い出しに使います。 | |
| permissions | contents、pull-requests、issuesを必要最小限にします。 |
CIのイベント種別と権限を分けると、事故時の影響範囲を狭められます。
GitHub Actionsに入れる場合、イベント種別ごとに危険度が違います。
| イベント | 最初の使い方 | 注意点 |
|---|---|---|
workflow_dispatch | 手動実行で検証する | 誰が実行できるかを確認する |
schedule | 定期調査や依存更新候補の洗い出し | 無人でwriteしない |
pull_request | テスト失敗の原因整理 | forkや外部PRではsecretを渡さない |
issues | Issue分類や実装計画作成 | 自動実装へ直結させない |
最初はartifactで戻す
最初のCI実装では、Codexが作った差分をそのままpushするより、patchやMarkdownレポートをartifactとして残すのが安全です。人間が差分を見てからPR化する流れにすると、権限を狭く保てます。
条件
PR作成まで自動化する場合でも、保護branchへの直接push、release tag作成、deploy、外部API POSTは別承認にします。CI上のbot権限でできることを増やすほど、停止条件と監査ログが重要になります。
AGENTS.mdとプロンプトを固定する
触ってよいpathと触らないpathを書きます。
必須コマンドと失敗時の扱いを書きます。
差分、未検証、失敗理由を必ず出します。
secret、push、外部投稿を禁止または承認制にします。
CIで使う指示は短く、テスト可能な条件にします。
CIでCodex CLIを動かすなら、毎回のプロンプトだけに依存しないほうが安定します。リポジトリにAGENTS.mdを置き、作業範囲、禁止操作、テスト手順、レビュー基準を短く固定します。
AGENTS.mdには、次のような項目を入れます。
- 触ってよいpath、触らないpath
- 必須テストコマンド
- 失敗時に報告する項目
- secretや
.envの扱い - push、release、外部投稿の禁止
- 変更を小さく保つルール
CI向けプロンプトは短くする
CIのpromptは長い作文ではなく、作業対象と停止条件を明示するために使います。
目的: npm test の失敗原因を調査し、必要なら最小差分で修正案を作る。
対象: src/ と tests/ のみ。
禁止: git push、release、外部API POST、secret表示。
検証: npm test を実行し、失敗したら理由を報告して止まる。
出力: 変更ファイル、実行コマンド、未検証範囲、レビュー観点。評価基準
CI向け指示は、レビュー担当者が「この範囲なら任せてよい」と判断できる短さにします。毎回変わる長いプロンプトより、AGENTS.mdと固定テンプレートの組み合わせが扱いやすいです。
失敗時に止める条件
失敗ログを残してPRへ進めません。
変更ファイル数や行数で止めます。
ログと差分を公開しません。
承認なしに昇格しません。
止まる条件があると、CIの自動実行をレビューしやすくなります。
自動実行で一番危ないのは、失敗しているのに「修正を続ければ何とかなる」と走り続けることです。停止条件を先に決めます。
| 停止条件 | 止める理由 | 残す情報 |
|---|---|---|
| テストが通らない | 変更の正しさを確認できない | 失敗コマンド、ログ、疑わしい箇所 |
| 差分が大きすぎる | レビュー不能になる | 変更ファイル数、行数、理由 |
| secret疑い | 情報漏えいの可能性 | ファイル名、検出理由、公開しないログ |
| 外部通信要求 | 想定外の副作用がある | どの接続先が必要だったか |
| 権限昇格要求 | 設計範囲を超える | 必要権限、代替案 |
完了扱いにしない報告
Codexが「完了しました」と出しても、CI側の合格条件が満たされなければ失敗にします。たとえば、npm testが落ちている、差分が禁止pathを触っている、PR本文に未検証範囲がない、といった場合です。
確認項目
完了条件は、git diff --check、lint、typecheck、test、禁止pathチェック、secret scan、PR本文テンプレートのように、できるだけ機械的に確認できる形にします。
最小ワークフロー例
- 1checkout
対象branchを取得します。
- 2codex exec
限定プロンプトで差分を作ります。
- 3test
lint、typecheck、testを走らせます。
- 4review
PRまたはartifactとして人間が確認します。
自動実行の成功は、レビュー可能な差分と検証ログが残ることです。
次は、最初に試すためのGitHub Actions風の例です。ここでは直接pushせず、Codexの実行結果と差分をartifactとして残す想定にしています。
name: codex-triage
on:
workflow_dispatch:
permissions:
contents: read
jobs:
codex-triage:
runs-on: ubuntu-latest
timeout-minutes: 20
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm install -g @openai/codex@0.135.0
- name: Run Codex in non-interactive mode
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
codex exec --sandbox workspace-write \
"npm test の失敗を調査し、必要なら src/ と tests/ だけ最小修正してください。git push は禁止です。最後に変更ファイル、実行コマンド、未検証範囲を報告してください。" \
| tee codex-report.txt
- run: npm test
- run: git diff --check
- uses: actions/upload-artifact@v4
with:
name: codex-output
path: |
codex-report.txt
.この例は、そのまま本番運用の完成形ではありません。artifactにworkspace全体を入れると不要なファイルまで含まれる可能性があるため、実際にはpatch、report、テストログなどに絞るほうがよいです。
PR作成へ進める条件
次の条件を満たしてからPR作成へ進めます。
- 対象pathだけを変更している
- lint、typecheck、testが通っている
- secret scanに引っかかっていない
- 差分がレビューできるサイズに収まっている
- PR本文に実行コマンドと未検証範囲がある
注意点
PRを自動作成する場合も、マージは人間に残します。CI botがPRを作ることと、保護branchへ直接書き込むことは別の権限です。
セキュリティ・コスト注意
| 項目 | 内容 | 見方 |
|---|---|---|
| secret | env、ログ、patch、artifactへの混入を防ぎます。 | |
| token | CI tokenの権限を最小化します。 | |
| cost | 長時間実行、再試行、巨大diffを制限します。 | |
| audit | 誰が、いつ、何を承認したか残します。 |
自動化は実行権限だけでなく、ログと費用の境界も必要です。
Codex CLIをCIで使うときは、secret、ログ、モデル利用量、外部通信、実行時間をまとめて管理します。
secretを渡しすぎない
CIでは、OPENAI_API_KEY以外のsecretを渡さない構成から始めます。GitHub tokenも必要最小限にし、外部PRやfork由来のイベントではsecretを使うjobを走らせないようにします。
ログを公開しすぎない
Codexの出力、テストログ、差分、artifactには、パス、環境変数名、内部URL、失敗内容が入ります。公開リポジトリでは特に、ログ公開範囲を確認してください。
コストは失敗時に増える
自動実行は、人間が止めない限り再試行や探索を続ける設計になりがちです。timeout、最大step数、対象ファイル数、実行頻度を制限し、失敗時は調査レポートで止めます。
評価基準
月額やtoken単価だけでなく、CI実行回数、失敗時の再試行、長いdiff、ログ読解、レビュー工数まで含めて見積もります。
実務で使うなら
- 1日目
read-only調査だけをexecで試します。
- 2日目
AGENTS.mdと停止条件を整えます。
- 3日目
workspace-writeで差分作成を試します。
- 5日目
PR作成と人間レビューへつなげます。
直接マージより、レビュー可能な差分作成から始めます。
最初の1週間は、次の順序で十分です。
codex execでread-only調査だけを実行する- AGENTS.mdに対象path、禁止操作、テスト手順を書く
workspace-writeで差分作成まで試す- lint、typecheck、test、secret scanを必須にする
- artifactまたはPRで人間レビューへ戻す
- 小さいIssueだけを対象にする
対象タスクを狭める
CIに向いているのは、範囲が小さく、合格条件が明確なタスクです。たとえば、lint修正、テスト失敗の原因整理、README更新、依存更新候補の分類、型エラーの小修正です。
認証、決済、DB migration、権限設計、本番deploy、セキュリティ修正は、最初から自動実行へ入れないほうがよいです。どうしても扱うなら、調査と修正案までに限定し、人間承認を必須にします。
FAQ
隔離済み環境以外では避けます。
外部PRやログへ渡さない設計にします。
最初は人間レビュー必須にします。
再試行より先に停止理由を残します。
迷ったら、権限を狭めてレビューへ戻します。
danger-full-accessをCIで使ってよいですか
原則として最初の選択肢ではありません。使い捨ての隔離環境、最小secret、外部通信制御、短いtimeout、監査ログがある場合だけ検討します。通常はread-onlyかworkspace-writeから始めます。
CodexにPR作成まで任せてよいですか
PR作成までは段階的に検討できます。ただし、直接pushや自動マージとは分けます。PR本文に実行コマンド、テスト結果、未検証範囲、レビュー観点が入っていることを必須にします。
AGENTS.mdがあれば安全ですか
いいえ。AGENTS.mdは作業指示であり、権限境界そのものではありません。sandbox、CI token、branch protection、secret管理、レビュー、テストゲートと組み合わせます。
失敗したら自動で何度も再実行すべきですか
最初は避けます。失敗ログを残して止め、同じ失敗を繰り返す前に人間が原因を確認します。再実行は、依存インストールの一時失敗など、明確に再試行可能なものに限定します。
参照した主な情報源
- openai/codex GitHub README
- openai/codex codex-rs README
- Codex CLI Getting Started – OpenAI Help Center
- Codex AGENTS.md guide
- Codex permissions
- Codex config basic
- Codex config advanced
- Codex config reference
- GitHub Actions: Use secrets in GitHub Actions
- GitHub Actions workflow syntax
次に読むなら
更新履歴
- 2026年5月31日
@openai/codex 0.135.0、openai/codex README、Codex関連公式情報を確認して初版を作成しました。
導入時には利用するCLIバージョンと公式ドキュメントを再確認します。
- 2026年5月31日：
@openai/codex0.135.0、openai/codex README、Codex関連公式情報、GitHub Actions公式情報を確認して初版を作成。