CodexでPR確認だけに寄せる自動化の始め方¶

対象 / ポイント

対象: Codexで定例作業を減らしたいが、自動マージや本番反映までは任せたくない初心者。

ポイント:

最初のゴールは「PRを作る」までに絞る
Codexの実行権限、レビュー条件、失敗時の停止条件を先に決める
マージ判断を人間に残すと、便利さと安全性を両立しやすい

毎朝の依存更新、記事の下書き、軽いリファクタを人が同じ手順で繰り返しているなら、Codexに任せる余地があります。ただし、最初から「変更して、テストして、マージして、公開する」まで任せる必要はありません。この記事の問いは、Codexに作業を渡しつつ、最後の判断をPRレビューに残すにはどう設計するかです。

Codexの公式ドキュメントでは、アプリのAutomationsがスケジュールで実行され、結果をTriageに返せること、Gitリポジトリではローカルプロジェクトまたは専用worktreeで実行できることが説明されている¹。これは「定例作業をPR候補として持ってくる」使い方と相性が良い仕組みだ。

最初の境界線は「PRまで」¶

最初に決めるべき境界線は、Codexが作るのはPRまで、マージは人間が決めるという線引きだ。

たとえば、ドキュメントのリンク切れ修正を毎朝チェックする運用なら、Codexには「検出、修正、テスト、PR作成」までを任せる。人間はPRの差分、CI、説明文、影響範囲だけを見る。作業の大半は自動化されるが、公開判断は人間のレビュー画面に残る。

この境界線があると、初心者でも運用を始めやすい。失敗しても、壊れる場所はmainブランチではなくPR上だ。レビューで止める、修正を依頼する、PRを閉じるという既存のGitHub作法をそのまま使える。

次に必要なのは、Codexに渡す依頼文を「作業」ではなく「PRの受け入れ条件」として書くことだ。

依頼文には受け入れ条件を書く¶

Codexへの依頼文は、やってほしい作業よりも、通過すべき条件を具体化したほうが安定する。

「記事を直して」だけでは、どこまで直すかが曖昧だ。「対象ファイルだけを編集する」「JP/ENペアを維持する」「品質スコアが80点未満ならPRを作らない」と書くと、Codexは作業を止める条件を持てる。自動化は、成功条件より停止条件のほうが事故を防ぐ。

初心者向けの依頼文は、次の3点を含めると扱いやすい。

対象範囲: 編集してよいディレクトリ、ファイル、候補数
検証条件: 実行してよいテスト、品質ゲート、CI確認
停止条件: 重複、根拠不足、権限不足、競合時のスキップ

CodexのGitHub連携では、PR上で@codex reviewを依頼でき、CodexはリポジトリのAGENTS.mdにあるレビュー指針も参照する²。つまり、自動化の依頼文だけでなく、リポジトリ側のルールにも「何を重く見るか」を残せる。

ここまで決めると、Codexは「作業者」ではなく「PR候補を作るオペレーター」に近づく。

権限は便利さより先に絞る¶

PR確認型の自動化では、権限を狭く始めるほうが運用しやすい。

CodexのAutomationsは既定のsandbox設定を使い、read-onlyではファイル変更やネットワーク利用などが失敗し、full accessではリスクが上がると説明されている¹。また、Codex CLIの承認とsandbox設定では、workspace-writeとon-requestの組み合わせが、ワークスペース内の編集を許しつつ、外部編集やネットワークアクセスには承認を求める構成として示されている³。

初心者は、まず次のような運用から始めると判断しやすい。

編集先を限定する: docs/blog/など、被害範囲が読みやすい場所から始める
外部操作を限定する: GitHub操作、ネットワーク、シークレット利用を明示する
破壊的操作を禁止する: 履歴改変、強制push、不要な削除を依頼文で避ける

権限を広げるのは、成功パターンが数回続いてからで十分だ。最初の目的は速度ではなく、失敗したときに止められる形を作ることだ。

レビューでは差分より「止め方」を見る¶

PRレビューでは、コードの良し悪しだけでなく、Codexが正しく止まれる設計になっているかを見る。

たとえば、候補が重複していたのにPRを作っていないか、品質ゲートが失敗したのにログだけ成功扱いになっていないか、CI失敗を確認せず完了扱いにしていないかを見る。この観点は、通常の人間PRよりも自動化PRで重要だ。自動化は一度通ると、同じ失敗を翌日も繰り返すからだ。

レビュー観点は3つに絞ると続けやすい。

入力: その日の候補、対象ファイル、参照ソースが妥当か
処理: 品質ゲート、競合チェック、CI確認が実行されているか
出力: PR本文、ログ、スキップ理由が次回判断に使えるか

Codexのコードレビュー機能は、GitHub PRのdiffを読み、リポジトリのガイダンスに沿って重大な問題に集中したレビューを投稿すると説明されている²。人間レビューとCodexレビューを重ねる場合も、役割を分けると読みやすい。

人間は「マージしてよいか」を決め、Codexは「見落としやすいリスクをもう一度見る」係にする。

まとめ：PRを止める場所にする¶

Codex自動化の初心者が最初に作るべきものは、完全自動の公開ラインではない。毎日同じ入力を見て、必要なら変更し、条件を満たしたときだけPRを出す小さな仕組みだ。

その仕組みでは、PRが単なる通過点ではなく停止場所になる。品質が足りない、根拠が弱い、既存記事と重複する、CIが落ちる。こうした状態をPR前後で止められるなら、Codexは危険な自動マージ装置ではなく、レビュー待ちの作業候補を整える道具になる。

次に改善するなら、成功したPRとスキップした候補をログに残す。自動化の品質は、成功した日の差分だけでなく、止められた日の理由で上がる。