Codex AutomationでPRが出ない時の切り分け方¶

対象 / ポイント

対象: Codex Automationに定期的な調査、修正、PR作成を任せたいが、予定時刻を過ぎてもPRが出ず、どこから確認すべきか迷っている開発者。

ポイント:

PR未作成は、未起動、実行中停止、PR作成後の失敗に分ける。
最初に見るのはCIではなく、スケジュールと実行履歴である。
作業場所、権限、PR状態を分けると、人間待ちと自動化失敗を混同しない。

公開日: 2026-06-27

朝の定期PRが出ていない時、最初にCIを開くと遠回りになる。 CIはPRが作られた後に動く検査であり、Automationが起動していなければ失敗ログも残らない。

この記事の問いは、Codex Automationが予定時刻を過ぎてもPRを出さない時、どの順番で原因を切り分けるかである。 OpenAIはCodex Automationsを、スケジュールに沿ってバックグラウンド実行できる仕組みとして説明している。¹ だから確認も、生成された記事やCIからではなく、まず「予定された実行が始まったか」から始める。

症状を3つに分ける¶

PRが無いという症状は、1つの失敗ではない。少なくとも、未起動、実行中停止、PR作成後の失敗に分かれる。

状態	何が起きているか	最初に見るもの
未起動	予定時刻を過ぎてもAutomationが始まっていない	スケジュール、実行履歴、タイムゾーン
実行中停止	Automationは始まったがPRまで到達していない	実行ログ、作業場所、権限、成果物
PR作成後の失敗	PRはあるがCIやレビューで止まっている	PR状態、CIログ、レビュー方針

この分解だけで、調べる順番が変わる。 PRが存在しないなら、CIより前の層を見る。 PRが存在するなら、そこから初めてCIやレビュー状態を見る。

シナリオ: PRが無い朝に5分で見る¶

たとえば、毎朝9時にPRを作るAutomationが9時5分になっても何も出していないとする。この時の問いは、「なぜ記事が書けなかったか」ではない。ここで問いを変える。 どの状態遷移が起きなかったかである。

5分で見るなら、この順番で足りる。この5分は性能基準ではなく、最初の切り分けを短時間に固定するための目安だ。

実行履歴が増えていないなら、スケジュールとタイムゾーンを見る。
実行履歴がありPRが無いなら、ログ、作業場所、権限を見る。
PRがdraftなら、未完了の自動チェックや編集条件を見る。
PRがreadyなら、人間レビューとCIを見る。

このシナリオを先に固定すると、調査の入口を間違えにくい。 CI画面を開くのは、PRが存在すると確認した後でよい。

スケジュールと実行履歴を見る¶

最初に確認するのは、Automationが予定時刻に始まったかどうかだ。予定時刻、タイムゾーン、繰り返し設定、最後の実行時刻をそろえて見る。

たとえば「毎朝9時にPRを作る」設定なら、9時を過ぎた時点で次の順に確認する。

スケジュールが有効な状態か。
予定時刻とタイムゾーンが意図通りか。
最後の実行履歴が予定時刻以降に増えているか。
実行が失敗している場合、エラーがどの段階で出ているか。

ここで実行履歴が無いなら、記事本文やPR本文を直しても前に進まない。問題は生成品質ではなく、Automationが始まる前の層にある。

作業場所と対象リポジトリを確認する¶

Automationが始まっているのにPRが無い時は、次に作業場所を見る。 Codex AutomationsはGitリポジトリではローカルプロジェクトまたはworktreeで実行できる。¹ OpenAIのworktree説明でも、worktreeは同じリポジトリの別checkoutとして扱われる。²

このため、Automationが正しく動いていても、期待と違う場所で作業しているとPRが見つからない。確認すべき点は次の通りだ。

対象リポジトリが正しいか。
対象ブランチまたはworktreeが意図通りか。
PRを作る権限があるか。
生成物が無視ファイルや一時ディレクトリにだけ残っていないか。
途中でコミット、push、PR作成のどこかが失敗していないか。

ここは「Codexが賢いか」ではなく、「どのGit作業場所で何をしたか」の問題だ。作業場所がずれると、成功した作業も期待したPRとして見えない。

PRが無い時にCIを見ない¶

CIは下流の検査だ。 PRが作られていない時点では、CIの失敗は主因になりにくい。

見る順番は単純でよい。実行が無ければスケジュールを見る。実行があってPRが無ければ、ログ、権限、作業場所、成果物を見る。 PRがあって初めて、CIとレビュー状態を見る。

この順番を逆にすると、目立つ画面だけを追うことになる。 CIが赤い時でも、原因がコードとは限らない。 CIサービス側の利用上限、支払い、権限、workflow設定でジョブ自体が始まらないこともある。

人間レビュー待ちと自動化失敗を分ける¶

PRが作られているなら、それは「何も起きていない」状態ではない。次に見るのは、そのPRが人間レビュー待ちなのか、自動チェック待ちなのかである。

運用によっては、Automationがまずdraft PRを作り、一定の条件を満たしたらレビュー可能なPRに変える。この方針自体は自然だが、状態名だけでは読者に伝わらない。 PR本文やダッシュボードには、誰が次に動くのかを書く必要がある。

PRの状態	読み方	次の一手
PRなし	Automationが未起動か、PR作成前に止まった	実行履歴とログを見る
draft PR	自動チェックまたは執筆途中の候補	チェック結果と未完了条件を見る
ready PR	人間がレビューできる候補	差分、根拠、CI状態を見る
CI失敗	PR作成後の検査で止まった	ログを見てコード起因か環境起因か分ける

大事なのは、PRの状態に主語を付けることだ。 Automationが止めたのか、CIが止めたのか、人間が判断する段階なのか。ここが分かれば、待つべき相手を間違えない。

最小チェックリスト¶

毎回の確認は、長い調査にしない。次の5項目だけを固定すれば、ほとんどの混乱は避けられる。

順番	確認するもの	分かること
1	スケジュール	予定時刻とタイムゾーンが合っているか
2	実行履歴	Automationが始まったか
3	作業場所	正しいrepo、branch、worktreeで動いたか
4	権限と成果物	commit、push、PR作成まで進めたか
5	PRとCI	人間レビュー待ちか、CI失敗か

この表は、特定のブログや社内フローに依存しない。 Codex Automationに限らず、スケジュール実行でPRを作るエージェント運用なら同じ順番で使える。

まとめ¶

Codex AutomationでPRが出ない時は、まず症状を分ける。 未起動、実行中停止、PR作成後の失敗のどれかを決める。

その上で、スケジュール、実行履歴、作業場所、権限、PRとCIの順に見る。この順番なら、人間レビュー待ちと自動化失敗を混同しない。自動化を信頼するには、出力だけでなく、止まった場所を説明できることが必要だ。