Codex Automations を触り始めると、最初に迷うのは「何ができるか」ではありません。
何を定期実行してよくて、どこで人間が止めるべきか です。
単発の対話なら、少し雑な指示でもやり直せます。ですが automation は違います。毎日または毎週バックグラウンドで回るので、曖昧なプロンプト、強すぎる権限、dirty な作業ツリーとの衝突が、そのまま事故になります。
この記事では、Codex Automations を「便利な定期実行機能」としてではなく、安全に運用設計された AI 作業レーン として整理します。Codex 自体の向き不向きを先に押さえたいなら Claude Code vs Codex CLI 比較、社内ルールまで含めて整理したいなら AIコーディングツールの社内ガイドライン、外部接続の統制まで広げるなら MCP エンタープライズ運用ガイド も前提になります。
先に結論
私の結論はシンプルです。Codex Automations は、反復的だがゼロリスクではない作業 に強いです。
たとえば、次のような仕事です。
- SEO レポートや changelog の要約
- 特定ディレクトリの更新監視
- 軽い文章更新の下書き
- issue / PR / docs の棚卸し
- 既存ルールに沿った定期メンテナンス
逆に、次のような仕事は最初から automation に寄せない方がよいです。
- 本番反映を伴う変更
- 依存関係追加やマイグレーション
- 外部 API への書き込みを含む処理
- 仕様がまだ固まっていない新機能実装
- レビュー抜きで merge まで進める運用
Codex の公式ドキュメントでも、automations はバックグラウンドで動き、結果は inbox に入り、Git リポジトリでは local project と dedicated background worktree を選べると明記されています。さらに、最初は通常スレッドで手動検証し、diff が reviewable か確認してからスケジュールしろ、という順番もはっきり書かれています。ここはかなり重要です。
Codex Automations とは何か
Codex Automations は、Codex app の中で recurring task をバックグラウンド実行する仕組みです。2026年4月8日時点の OpenAI 公式 docs では、次の性質が明示されています。
- Codex app 上でバックグラウンド実行される
- 結果は inbox に findings として積まれる
- Git リポジトリでは local 実行か worktree 実行を選べる
- デフォルト sandbox 設定を引き継ぐ
skillsを組み合わせて再利用性を上げられる
ここで見るべきなのは、単なる cron ではないことです。
ファイルを読み、書き、コマンドを実行し、差分まで作る AI エージェントを定期実行する ので、運用の主語は「通知」ではなく「変更管理」になります。
この意味では、Codex Automations は Claude Code の Auto-Fix と同じく、AI を unattended に近い形で回す領域に入ります。ただし Auto-Fix が CI 起点の修正フローに寄っているのに対して、Codex Automations はもっと広く、ドキュメント更新、要約、定期棚卸し、PR 下書きのような横断業務に向きます。
何を自動化すると一番うまくいくか
私は、automation 候補を次の 3 条件で絞るのが一番壊れにくいと考えています。
- 入力が比較的安定している
- 成果物の良し悪しを review で判定できる
- 失敗してもロールバックしやすい
向いている仕事
たとえば、このサイト運用なら次が向いています。
data/seo/を読んで日次の学びをまとめる- 直近コミットから指定ディレクトリの更新要約を作る
- 既存記事のリンク切れやメタ不足を棚卸しする
- issue コメントやレビュー指摘を下書きする
これらは、入力ソースがある程度固定され、差分を人間が見れば良し悪しを判定しやすいです。
向かない仕事
一方で、次は危険です。
- 毎週ライブラリを更新して自動で merge する
- 外部サービスに書き込みながら複数系を同期する
- PR 作成から merge までを全自動にする
- まだ search intent が固まっていない記事を勝手に量産する
こういう仕事は、variation が多い割に失敗コストが高いです。
AI ワークフローを広げる前に、まず マルチエージェントオーケストレーション 4パターン解説 で「どの作業を分離し、どこにレビュー境界を置くか」を整理した方がいいです。
worktree を前提に考えた方がいい理由
ここはかなり強く言います。
Git 管理下の automation は、原則 worktree 前提で考えた方がよいです。
OpenAI の Codex docs でも、automations は dedicated background worktree で動かせるとされており、ongoing work と衝突させないために worktree を使う価値が明確に説明されています。Worktrees の docs でも、Codex は同一プロジェクト内で independent tasks を parallel に動かせること、background work を foreground から切り離せること、必要になったら local へ handoff できることが整理されています。
実務上の利点は次の通りです。
- 手元で編集中の変更とぶつからない
- automation ごとにブランチ境界を切りやすい
- review 対象をその automation の差分に寄せやすい
- 「壊したら捨てる」がしやすい
逆に local 実行は、作業ツリーが clean で、かつその automation が小さい変更しかしない場合だけに絞るべきです。たとえば typo 修正や軽いレポート生成なら local でも回せますが、記事執筆や複数ファイル更新は worktree の方が安全です。
実際にどうプロンプトを書くか
automation は、通常スレッド以上に 曖昧さを嫌う べきです。
私が最低限入れるのは次の 6 点です。
- 何を読むか
- 何を更新してよいか
- 何を更新してはいけないか
- どのコマンドで検証するか
- dirty なときの扱い
- 最終出力に何を報告するか
このサイトで回すなら、たとえば次のように書けます。
data/seo/keyword-plan.md と既存記事を確認し、主戦場テーマから重複しない記事候補を1本だけ選ぶ。
dirty なら checkout / pull / reset はしない。
Git は main 直コミット禁止。記事用 branch で作業する。
本文を書いたら pnpm seo:update-llms と pnpm run build を実行する。
最後に keyword-plan を更新し、テーマ・重複チェック結果・build結果を報告する。このレベルまで具体化すると、automation はかなり安定します。逆に「いい感じに記事を書いて公開して」ではほぼ崩れます。
より上流では、モデル性能より 制御面の設計 が効きます。
sandbox と rules は「便利機能」ではなく必須設定
Codex docs では、automations は unattended に動く前提で、default sandbox settings を使うと明記されています。さらに、workspace-write でも network や workspace 外書き込みは失敗し、full access は background automations では risk が高いので注意せよ、とかなりストレートに書かれています。
私の判断基準は次です。
- 基本は
workspace-write - full access は原則使わない
- 例外的に必要なコマンドだけ rules で allowlist する
- 外部接続があるなら read/write を分ける
この線引きは、個人開発でも組織導入でも変わりません。
違うのは、組織ではそこに監査と承認者が追加されることだけです。ルール整備まで含めるなら AIコーディングツールの社内ガイドライン を先に作っておくべきです。
私なら最初に禁止するもの
git pushの自動実行- deploy 系コマンド
- package manager による依存追加
- write 権限付きの外部 SaaS 操作
- 秘密情報や個人情報に触る処理
automation は unattended に近いからこそ、「できる」より「止める」を先に設計した方が失敗しません。
skills を組み合わせると再利用性が上がる
OpenAI の automations docs では、$skill-name で skill を明示的にトリガーできることが案内されています。これは単なる便利機能ではなく、プロンプトの長文化を防ぐための仕組み として使うべきです。
たとえば、
- SEO 分析の読み方
- PR レビュー時の観点
- 記事執筆時の frontmatter ルール
- チーム固有の報告フォーマット
のような再利用ルールは skill に寄せる。
その上で automation 本体には、「今回何をやるか」だけを書く。こうすると保守しやすいです。
逆に、毎回違う前提まで skill に押し込むと、今度は skill 側が肥大化します。
ここは AGENTS.md や rules と同じで、恒常ルールだけを分離する のが基本です。
review を前提にして初めて回る
Codex の review docs は、この点もかなり明快です。review pane は Git 状態を基準に diff を見せ、inline comment を付けられ、stage / revert まで行えます。つまり Codex app 側は、「AI が変更を作る」だけでなく「その差分を人間が絞り込む」前提で作られています。
ここから逆算すると、automation の正しい完成形は「全自動」ではありません。
- 定期実行で草稿や差分を作る
- inbox / triage で拾う
- review pane で見る
- 必要なら inline comment で修正させる
- stage / revert してから commit / PR に進む
私はこの流れを 自動化された下働き + 人間レビュー と捉えています。
merge まで自動にしたくなる気持ちは分かりますが、少なくとも主戦場の記事運用やコード変更では、まだそこまで寄せる必要はありません。
このサイト運用ならどう使うか
このサイトで Codex Automations を使うなら、私は次の 3 レーンに分けます。
1. 観測レーン
- GSC や keyword-plan の変化要約
- 既存記事の重複候補の検出
- 直近更新から内部リンク候補を抽出
これは read-heavy で、最も automation 向きです。
2. 草稿レーン
- 記事候補の選定
- frontmatter 付きの下書き生成
- learnings.md の追記案作成
ここは worktree 前提なら十分回せます。ただし build と llms 更新までは行っても、公開判断は人間が持つべきです。
3. 危険レーン
- 既存ハブ記事の大規模改稿
- サイト構造変更
- MCP や外部 API を伴う書き込み
ここは定期 automation にしません。必要なときだけ明示的に走らせるか、通常スレッドで扱います。
まとめ
Codex Automations は、AI エージェントを「定期的に働かせる」ための強い仕組みです。
ただし、価値が出るかどうかはモデルより 設計の切り方 で決まります。
私なら、次の順番で導入します。
- まずは通常スレッドで手動検証する
- review しやすい小さな反復作業だけ automation にする
- Git 管理下では worktree を原則にする
- sandbox は
workspace-writeを基準にする - rules と skills で恒常ルールを分離する
- 最後まで人間レビューを残す
この順番を飛ばして「便利そうだから全部自動化する」に行くと、かなりの確率で壊れます。
逆に、作業の種類、権限、review 境界を先に決めれば、Codex Automations はかなり実務的です。