Codexで定期実行を作る前に決めること

3行まとめ

Goal

通知か変更か。

Thread

同じ文脈で続ける。

Standalone

毎回fresh run。

Worktree

local作業を分離。

Skill

手順を固定。

定期実行は、便利さより止め方と確認方法を先に決めます。

• CodexのAutomationsは、定期的な確認、報告、修正をbackgroundで回せますが、最初に「通知だけか、変更まで行うか」を分けます。
• 継続中の会話に戻るならthread automation、毎回独立した巡回ならstandalone automationが向きます。
• Git repositoryではworktree、sandbox、rules、skillsを組み合わせ、普段のlocal作業と定期実行の変更を混ぜない設計にします。

この記事では、OpenAI公式のCodex app Automations、Codex app features、Worktrees、Agent approvals & security、Skills関連docsを確認し、2026年6月1日時点の情報として整理しています。画面名、選択肢、権限設定は変わり得るため、作成前に最新docsと手元のCodex app設定を確認してください。

この記事でわかること

Type

threadかstandalone。

Scope

対象projectとrepo。

Permission

sandboxとrules。

Evidence

報告と成果物。

作る前に判断軸を持つと、定期実行が散らかりにくくなります。

• Codex Automationsを作る前に決める順番
• thread automationとstandalone automationの使い分け
• Git repositoryでworktreeを使う理由
• local checkoutへ直接触らせる場合の注意点
• sandbox、network、rulesを先に決める考え方
• skillsで定期実行の手順を固定する方法
• 導入初週に見るべき失敗条件

Codexの定期実行は、PRの状態確認、依存更新の調査、障害ログの確認、ドキュメント更新、週次レポート作成のような繰り返し作業と相性があります。ただし、繰り返し動くものほど、1回の手作業より影響が積み上がります。

だから最初に決めるべきなのは、実行頻度ではありません。何を見て、何を変えてよく、何を人間へ戻すかです。ここが曖昧なまま「毎朝9時に見て」と頼むと、通知が増えるだけのautomationや、意図しないfile変更を作るautomationになりがちです。

チームでCodex活用を広げる全体像は、公開済み記事のCodex活用をチームに広げる順番でも整理しています。この記事では、その中でも定期実行だけに絞ります。

前提知識

項目	内容	見方
Automations		作成と管理。
Features		app全体の位置づけ。
Worktrees		background分離。
Security		sandboxとnetwork。
Skills		手順の再利用。

画面や選択肢は更新されるため、作成前に最新docsも確認します。

OpenAI公式のAutomations docsでは、Codexがbackgroundでrecurring taskを実行し、発見事項をinboxに追加するか、報告することがなければtaskを自動的にarchiveするものとして説明されています。project-scoped automationsでは、Codex appが動いていて、選択したprojectがdisk上で利用できる必要があります。

Git repositoryでは、automationをlocal projectで走らせるか、新しいworktreeで走らせるかを選べます。worktreeは未完了のlocal作業からautomationの変更を分けるための選択肢です。non-version-controlled projectでは、automationはproject directoryで直接動きます。

公式情報で確認する範囲

確認先	見ること
Codex app Automations	recurring task、Triage、thread automation、standalone automation
Codex app features	app内のproject、skills、modes、Git機能
Worktrees	LocalとWorktreeの違い、Handoff、background作業
Agent approvals & security	sandbox、network access、rules
Skills	automationで再利用する作業手順

注意点

Automationsは「作ると便利」ではなく、「繰り返しても壊れにくい作業だけを任せる」機能として扱います。特に、file変更、外部通信、Git操作、アプリ操作、secretを含む作業は、最初から広い権限で動かさないほうが安全です。

また、automationは人間の確認を消すものではありません。定期実行が作った報告や差分を、誰が見て、いつ止めるかまで含めて設計します。

まず定期実行の目的を分ける

1. 1Observe

   確認だけ。

2. 2Report

   結果をまとめる。

3. 3Change

   fileを直す。

4. 4Escalate

   人間へ戻す。

目的が曖昧なautomationほど、不要な変更や通知が増えます。

最初に、automationの目的を4つへ分けます。

目的	例	初期設定
Observe	PR状態、CI結果、依存更新候補を見る	read-only中心
Report	差分、失敗ログ、週次状況をまとめる	file変更なし
Change	docs、テスト、軽微な修正を作る	worktree推奨
Escalate	人間へ判断を戻す	明確な条件を書く

この分類をせずにscheduleだけ決めると、automationが何を成功と見なすのか曖昧になります。たとえば「毎朝依存関係を見て」だけだと、更新候補を報告するのか、PRを作るのか、lockfileを変えるのかが決まりません。

通知だけか、変更まで行うか

通知だけのautomationは、始めやすいです。たとえば「毎朝、昨日から失敗しているCI jobをまとめる」「毎週、open PRでreview待ちのものを分類する」のような作業です。file変更を伴わないため、最初の試行に向いています。

変更まで行うautomationは、別物です。docsの更新、テスト追加、依存更新、軽微な修正を作るなら、対象file、branch、test、push可否、人間reviewの条件を決めます。

変更を許す前に見ること

変更ありのautomationでは、次の4つを先に決めます。

項目	決めること
対象	触ってよいdirectoryやfile
禁止	secret、deploy、migration、外部POSTなど
検証	必須commandと失敗時の報告
終了	PR作成、diff提示、報告だけのどれか

この4つが書けない作業は、まだautomationにしないほうがよいです。

1回ごとに独立するか、同じ文脈で続くか

次に、毎回新しいtaskとして走らせるか、同じconversationへ戻るかを決めます。これはautomation typeの選択に直結します。

継続中のdeploy監視、長い調査、PR feedbackの追跡のように、前回の文脈が重要なら同じthreadに戻る設計が向いています。週次レポート、毎朝のPR一覧、毎日1回の依存候補確認のように、毎回独立した結果でよいならfresh runが向きます。

thread automationとstandalone automationを分ける

項目	内容	見方
Thread		同じ会話へ戻る。
Standalone		fresh runで開始。
Triage		結果を受け取る。
Cron		custom cadence。

継続中の調査と独立した巡回は、同じ定期実行にしません。

OpenAI公式docsでは、thread automationは現在のthreadに紐づくheartbeat-style recurring wake-up callとして説明されています。minute-based interval、daily、weekly scheduleを使い、同じ会話へ戻る作業に向きます。

standalone automationは、scheduleに沿ってfresh runを開始し、結果をTriageへ報告するものとして説明されています。毎回独立してよい巡回や、複数projectを対象にする作業に向きます。

同じ会話へ戻る作業

thread automationは、同じ文脈を保つことに価値がある作業に使います。

作業	thread automationが向く理由
長いcommandの完了待ち	前回のcommandや失敗理由を覚えておきたい
PR feedback対応	同じPRの履歴が必要
researchの継続	調査メモを引き継ぎたい
deploy監視	状態変化を同じ場所へ蓄積したい

たとえば「このPRのreviewが返るまで30分ごとに見て、P1だけ修正案を出す」はthread automationに向きます。文脈が分断されると、前回どこまで対応したかが見えにくくなるためです。

毎回fresh runにする作業

standalone automationは、毎回新しい結果でよい作業に向きます。

作業	standaloneが向く理由
週次レポート	毎回対象期間が変わる
毎朝のPR棚卸し	その時点の状態だけでよい
dependency候補確認	過去文脈より現在状態が重要
複数project巡回	1つのthreadに混ぜないほうがよい

custom cadenceが必要なら、公式docsではcustom scheduleにcron syntaxを入力できることが説明されています。最初は複雑なcronにせず、dailyやweeklyで始め、必要になってから細かくします。

worktreeでlocal作業を守る

Git repo

background worktree。

Local

main checkoutへ直接。

Non-git

project directory。

Handoff

必要なら移動。

変更を作るautomationは、普段の作業場所から分けて始めるのが無難です。

Codex app featuresとWorktrees docsでは、Git repositoryでautomationがdedicated background worktreeを使えることが説明されています。これはかなり重要です。定期実行が自分の作業中のcheckoutへ直接変更を入れると、未完了のdiffとautomationのdiffが混ざります。

Git repositoryのautomation

Git repositoryでは、変更が出るautomationほどworktreeから始めます。worktreeはlocal checkoutとは別のcheckoutで、背景作業を分離できます。

たとえば、次のような作業です。

作業	worktree向きの理由
docs更新	localの執筆中差分と混ぜない
test追加	実験的な修正を分離できる
dependency調査	lockfile変更を隔離できる
PR feedback対応	branchとして確認しやすい

Worktrees docsでは、worktreeで作った変更をbranchにし、commit、push、pull request作成へ進められることも説明されています。automationが変更を作るなら、最終的にbranchやPRで人間が確認できる形に寄せます。

localへ直接触らせる場合

local modeが悪いわけではありません。確認だけ、報告だけ、または自分が見ながら進める短い作業ならlocalでも十分です。ただし、automationはbackgroundで動くため、自分が編集中のfileへ触る可能性があります。

localで走らせるなら、対象fileを狭くし、変更が出る場合は必ずdiff確認を前提にします。作業中のbranchで大きなrefactorをしているときは、local automationを避けます。

non-version-controlled projectの扱い

公式docsでは、non-version-controlled projectのautomationはproject directoryで直接動くと説明されています。Git管理されていないdirectoryでは、worktreeで分けられません。

この場合は、変更ありのautomationを避けるか、事前にbackup、出力directory、dry run、手動確認を強くします。少なくとも、元fileを直接書き換える作業を初期値にしないほうがよいです。

sandboxとrulesを先に決める

項目	内容	見方
Read-only		調査と報告中心。
Workspace		限定したfile変更。
Network		必要domainだけ。
Rules		commandを制御。

backgroundで動くものほど、広い権限を初期値にしないほうが扱いやすいです。

Automations docsでは、automationがdefault sandbox settingsを使うこと、read-only modeではfile変更、network access、computer上のapps操作が必要なtool callは失敗すること、full accessはbackground automationで elevated risk になることが説明されています。

つまり、automationを作る前にsandboxを決める必要があります。scheduleやpromptより、権限の初期値が大事です。

read-onlyで足りる作業

最初のautomationはread-onlyで足りる作業にします。PR一覧をまとめる、CIの失敗を分類する、docs更新候補を報告する、依存更新候補を列挙する、といったものです。

read-onlyで足りるなら、変更や外部送信の事故をかなり減らせます。結果を見て、人間が「次回からdocsだけ直してよい」と判断してから、権限を増やします。

read-onlyで見る指標

read-only段階では、次を見ます。

指標	良い状態
報告の粒度	次に何をすればよいか分かる
誤検知	人間の確認負荷が小さい
対象範囲	見てほしいprojectだけを見ている
終了条件	報告なしなら静かに終わる

ここで報告品質が低い場合、変更権限を足してもよくなりません。prompt、skill、対象範囲を直します。

full accessの扱い

full accessが必要なautomationは、最初から定期化しないほうが安全です。必要な場合も、対象project、command、network、file pathを絞ります。

Agent approvals & security docsでは、network accessやdomain policy、rulesでcommandを制御する考え方が説明されています。Codexに外部通信を許可する設計は、公開済み記事のCodexにインターネットアクセスを許可する前にでも整理しています。

定期実行では、1回だけの許可より慎重にします。毎日動くautomationが広いnetwork accessを持つと、設定ミスの影響も毎日発生します。

skillsで作業手順を固定する

Inputs

必要情報。

Steps

確認順。

Tools

使うplugin。

Output

報告形式。

毎回promptを育てるより、skillに作業契約を寄せると共有しやすくなります。

Automations docsでは、automationがCodexで使えるpluginsやskillsを利用でき、複雑な作業ではskillsを組み合わせられることが説明されています。さらに、automation内で$skill-nameを使ってskillを明示的に呼び出せることも説明されています。

これは、定期実行を安定させる上で重要です。毎回長いpromptへ手順を書くより、skillへ入力、確認順、使うtools、出力形式を寄せるほうが管理しやすくなります。

promptだけにしない

promptだけでautomationを作ると、少しずつ例外が増えます。「このrepositoryではこう」「このPRではこう」「失敗したらこう」がpromptに積み重なり、誰も全体を読まなくなります。

skillに移すべきなのは、次のようなものです。

skillへ寄せるもの	例
入力	対象repository、branch、PR URL、期間
手順	取得、分類、検証、報告
tools	GitHub plugin、shell、browser、社内CLI
出力	summary、risks、not run、next action
禁止	secret表示、deploy、広いrefactor

CodexのSkills、Plugins、Subagents、MCPの役割分担は、公開済み記事のCodexのSkills・Plugins・Subagents・MCPをチームで使う前にでも整理しています。

teamで共有する

automationが個人のpromptだけに依存していると、担当者が変わったときに再現できません。チームで使う定期実行は、skill、AGENTS.md、rules、project設定を組み合わせて残します。

AGENTS.mdにrepo固有の作業契約を置く考え方は、公開済み記事のチーム向けAGENTS.mdテンプレートが参考になります。automationのpromptは「いつ、どのskillを、どの範囲で起動するか」に寄せ、細かい作業契約はrepo側やskill側へ逃がします。

導入初週の進め方

1. 1日目

   通知だけで作る。

2. 2日目

   thread型を試す。

3. 3日目

   standalone型を試す。

4. 5日目

   worktreeで変更を試す。

5. 7日目

   継続条件を決める。

最初の1週間は、成功率より過剰通知と不要変更の少なさを見ます。

Codex Automationsは、最初の1週間で小さく試すのがよいです。いきなり複数projectで変更ありの定期実行を作ると、問題が起きたときに原因を切り分けにくくなります。

日	やること	見ること
1日目	read-onlyのstandalone automationを1つ作る	報告が静かで有用か
2日目	thread automationで長い確認を追う	文脈が残る価値があるか
3日目	Git repositoryでworktree実行を試す	local作業と混ざらないか
4日目	skillを1つ使う	promptが短くなるか
5日目	変更ありを小さく試す	diffが狭いか
7日目	残すautomationを決める	通知量、誤検知、停止条件

初週に増やしすぎないのがコツです。automationは、1つでも運用に残ると毎日動きます。数を増やす前に、既存のautomationが本当に判断を助けているかを見ます。

継続判断の基準

1週間後は、次の4つで判断します。

判断	継続条件
価値	人間の確認時間が減った
静かさ	報告なしの回は騒がない
安全性	権限と対象範囲が狭い
保守性	promptではなくskillやrepo設定に寄せられる

この4つを満たさないautomationは、停止するか、read-onlyに戻します。定期実行は増やすより、減らせる状態を保つほうが強いです。

FAQ

Thread?

文脈を残す時。

Standalone?

毎回独立の時。

Worktree?

変更を分けたい時。

Skill?

手順を再利用する時。

迷ったら、何を守りたいautomationかへ戻ります。

thread automationはいつ使いますか

同じ会話の文脈を残したいときです。deploy待ち、PR feedback対応、長い調査、継続的なtriageのように、前回の判断が次回に効く作業に向いています。

standalone automationはいつ使いますか

毎回独立した結果でよい作業です。毎朝のPR棚卸し、週次レポート、依存更新候補の確認、複数projectの巡回などに向きます。

worktreeは必ず使うべきですか

Git repositoryで変更が出るautomationなら、まずworktreeを検討します。確認だけならlocalでも足りますが、backgroundでfile変更が発生するならlocal作業と分けるほうが安全です。

full accessで定期実行してよいですか

最初の選択肢にはしません。必要な場合でも、対象path、command、network、終了条件を限定します。background automationは人が見ていない時間に動くため、広い権限の影響が見えにくくなります。

skillsは必須ですか

必須ではありません。ただし、チームで繰り返すautomationや、pluginを使う作業、報告形式を揃えたい作業ではskill化したほうが保守しやすくなります。

次に読むなら

参照した主な情報源

• https://developers.openai.com/codex/app/automations
• https://developers.openai.com/codex/app/features
• https://developers.openai.com/codex/app/worktrees
• https://developers.openai.com/codex/agent-approvals-security
• https://developers.openai.com/codex/config/skills

更新履歴

1. 2026年6月1日

   OpenAI公式Codex docsを確認して初版を作成しました。

作成時には最新のCodex app docsとsandbox設定を確認してください。

• 2026年6月1日: OpenAI公式Codex docsを確認し、Automationsを作る前の目的、thread/standalone、worktree、sandbox、rules、skillsの分け方として初版を作成しました。