Codex Automations と長時間タスク: 定期トリガー、heartbeat、跨日作業の組み方

Codex に繰り返しの確認、PR の追跡、デプロイ後の見回り、跨日にまたがる対応を任せるなら、最初に考えるべきなのは「自動化できるか」ではありません。どの種類のタスクを、どういう境界で自動化するかです。Automations は Codex を永遠に動く常駐 agent にする仕組みではなく、適切なタイミングで戻ってきて、1 つのことをきちんとやらせるための仕組みです。

1. まず、このタスクは自動化に向いているかを見極める

1.1 standalone/project automation: 独立したバックグラウンドジョブ

standalone automation と project automation はどちらも独立したバックグラウンドジョブです。違いはスコープです。standalone は特定プロジェクトに結びつかず、project automation はプロジェクトパスに結びつきます。固定リポジトリを繰り返し見る用途なら後者が向いています。

この種の自動化は、トリガーのたびに新しい実行が始まります。完了すると結果は inbox や triage に入り、何もなければ自動で整理されます。典型例は、毎週の依存関係チェック、毎日の issue triage、デプロイ後に決まった時間で見る review comments などです。

重要な制約はローカル環境への依存です。Codex app が動くマシンは起動したままでなければならず、app も実行中である必要があり、プロジェクトパスも存在していなければなりません。マシンのスリープ、シャットダウン、app の終了で止まります。長期の無人ホスティング用途ではありません。

1.2 thread automation (heartbeat): 同じスレッドにぶら下がる定期起動

thread automation は、現在の会話スレッドにぶら下がる heartbeat-style の recurring wake-up calls です。核になるのはコンテキストの保持で、起動するたびに同じ会話を続け、新しい独立実行にはしません。

デプロイ後のログ確認、跨日タスクの追跡、継続的な triage に向いています。たとえば、10 分ごとにデプロイログを見て、エラーか成功が出た時だけ報告し、変化がなければ黙って待つ、という使い方です。こういう作業は文脈の継続が必要なので、standalone automation では合いません。

heartbeat は永続 daemon でも forever loop でもありません。起動 -> 確認 -> 報告 -> 待機、というリズムです。アプリを止めれば heartbeat も止まります。

1.3 種類の比較表

観点	standalone/project automation	thread automation (heartbeat)
実行場所	独立したバックグラウンドスレッド	現在の会話スレッド
文脈保持	毎回新しい文脈	現在のセッション文脈を保持
向いている場面	独立した反復作業、issue triage、依存関係チェック	長時間タスクの追跡、継続 triage、デプロイログ確認、跨日作業
依存条件	ローカル app / マシン / プロジェクトパスが必要	現在のスレッドに紐づく必要がある
結果の出方	inbox / triage、何もなければ自動整理	現在の会話ウィンドウ
停止方法	automation の状態を切る	app を一時停止または終了する

判断はこうです。まず、そのタスクは文脈保持が必要か。必要なら thread automation。次に、特定プロジェクトに紐づくか。紐づくなら project automation、そうでなければ standalone automation です。

2. どんなタスクが自動化に向いているかを見極める

すべての反復作業が Automations 向きとは限りません。まずタスクの性質を見ます。

2.1 Automations に向いているタスクの特徴

向いているタスクには 3 つの特徴があります。反復性が高い、ルールが明確、結果を検証できる、です。

反復性が高いタスクは、周期的に現れて、毎回だいたい同じ結果を求めます。毎週の依存関係チェック、毎朝の issue triage、デプロイ後の定時確認などがその例です。こうしたタスクは、確認範囲、判断基準、出力形式を前もって固定できます。

ルールが明確なタスクは prompt に落とし込みやすいです。たとえば、「package.json の依存バージョンを確認し、新しい版があるパッケージを列挙して、優先度を提案する」といったものです。判断基準が安定しているので、毎回言い直す必要がありません。

検証可能な出力も大事です。良い自動化結果は inbox / triage に戻り、何もなければ自動で整理され、見つかれば次の一手がはっきりします。それで初めて、ノイズではなく省力化になります。

2.2 Automations に向いていないタスクの特徴

向いていないタスクには 4 つの特徴があります。人間の判断が頻繁に必要、外部状態が速く変わる、prompt がまだ安定していない、長期の無人ホスティングが必要、です。

人間の判断が頻繁に必要なタスクは境界があいまいです。アーキテクチャ判断、複雑なバグ調査、場面依存のトレードオフなどは、毎回状況に応じた調整が必要なので、固定の automation には向きません。

外部状態が速く変わるタスクも注意が必要です。たとえば本番サービスのリアルタイム監視は、変化が速すぎるので、Automations より専用の監視ツールの方が向いています。

未検証の prompt をいきなり自動化するのも避けます。まず手動で数回回し、ルール・範囲・出力を安定させてから automation にします。

長期の無人ホスティングは project-scoped automation の守備範囲ではありません。ローカル app、マシン、プロジェクトパスに依存するからです。マシンが消えたら止まるので、クラウド托管の代わりにはなりません。

2.3 タスク適合表

タスク種別	向いているか	判断理由	推奨方法
毎週の依存更新チェック	はい	反復性が高く、ルールが明確で、検証可能	standalone automation または project automation
毎日の issue triage	はい	inbox に流せる、何もなければ整理できる、prompt が安定	standalone automation または thread heartbeat
デプロイ後の定期ログ確認	はい	同じスレッドで追跡でき、文脈保持が必要	thread automation
アーキテクチャ判断	いいえ	頻繁な人間判断が必要で、境界が曖昧	手動会話
複雑なバグ調査	いいえ	状況に応じた調整が必要	手動会話
リアルタイム監視	いいえ	外部状態の変化が速い	専用監視ツール
長期無人托管	いいえ	project-scoped automation はローカル環境依存	CI または cloud approach
未検証の自動化フロー	いいえ	prompt が不安定で手動の一貫性もない	まず手動で安定化

判断の流れはシンプルです。まず prompt が安定しているかを見て、次に文脈保持が必要かを考え、最後に長期のクラウド托管が要るかを判断します。

3. 最初の standalone/project automation を作る

3.1 作成フロー

1. まずタスクを明文化します。スコープ、入力、出力、成功条件、停止条件を定義します。
2. automation の種類を選びます。独立した反復作業は standalone、固定リポジトリの反復作業は project automation です。
3. 実行場所を選びます。Git リポジトリでは worktree を使い、現在の作業領域を荒らさないようにします。
4. 頻度を決めます。分単位のジョブは停止条件を明記し、無限に起こさないようにします。
5. 数回試運転します。出力が安定したら、本番の頻度に上げます。

3.2 worktree と local project の選び方

実行場所	分離度	向いているタスク	リスク
worktree	現在の作業ディレクトリから分離	ファイル編集、コード生成、PR 提案があり得るタスク	ミスしても worktree 内に閉じやすく、捨てやすい
local project	分離なし。現在のディレクトリで直接実行	読み取り専用チェック、レポート生成、triage	編集中のファイルに影響する可能性がある

Git リポジトリでは、修正型タスクは worktree を基本にします。local project は、読み取り専用、確認専用、レポート専用だと明示できる場合だけにします。

4. thread automation (heartbeat) を作る

4.1 作成フロー

1. 現在の会話がすでに長時間タスクを扱っていることを確認します。
2. その会話に thread automation を紐づけます。
3. 各 wakeup で何を見るか、いつ報告するか、いつ黙るかを書きます。
4. 成功、失敗、タイムアウト、最大ラウンド数などの停止条件を決めます。
5. まずは低頻度で回し、スパムしないことを確認してから本番の cadence にします。

4.2 heartbeat prompt テンプレート例

10 分ごとにデプロイログを確認し、次のケースだけ報告してください:

1. error, failed, exception を含むエラー信号が出た
2. deployed, success, completed を含む完了信号が出た
3. 30 分たっても完了していない

報告形式:
- 状態: [進行中 / 成功 / 失敗]
- 重要ログ抜粋: [最大 3 行]
- 次の一手: [あれば]

変化がなければ沈黙してください。

この prompt なら、確認範囲、出力境界、停止条件がはっきりします。毎回「確認完了」と繰り返す必要も、変化がない状態をノイズに変える必要もありません。

5. 安全設定: sandbox、approval policy、チーム運用

5.1 sandbox と approval policy の設定

Automations は既定で sandbox の中で動きます。sandbox は、触れるファイル、境界を越えられるか、追加承認が要るかを決めます。バックグラウンド自動化では、既定の境界は小さいほど安全です。

sandbox モード	権限範囲	向いている場面	リスク
read-only	読み取り専用、書き込みなし	純粋な確認・分析タスク	低
workspace-write	workspace 内は読み書き可、外部操作は承認が必要	日常自動化、ファイル編集、PR 提案	中
danger-full-access	システムへの制限なしアクセス	隔離環境や高信頼タスク	高

approval policy は、高リスク操作に進む時に承認を求めるかを決めます。

approval policy	挙動	用途
on-request	必要時により高い権限を求める	ある程度の自律性は欲しいが、人間の確認も残したい
never	完全自動で実行し、確認しない	automation script や非対話環境

既定は workspace-write + rules/allowlist が良いです。full access + unattended は広すぎます。

5.2 チーム運用の考え方

チームでは requirements.toml で sandbox と approval を固定して、うっかり権限を広げないようにできます。

[agent]
approval_policy = "never"
sandbox = "workspace-write"

目的は「何もできなくする」ことではありません。既定を狭くして、本当に必要な時だけ広げることです。

6. そのまま使える 3 つのテンプレート

6.1 毎週の依存関係巡回

• トリガー頻度: 週 1 回
• 実行場所: Git リポジトリなら worktree 優先
• 成功出力: 更新可能な依存と優先度の提案
• 停止条件: 更新対象がなければ 1 行で終える
• 権限境界: 読み取り専用、または軽いレポート書き込み

6.2 デプロイ後の heartbeat フォロー

• トリガー頻度: 10 分ごと、最大 30 分
• 実行場所: thread automation
• 成功出力: 成功、失敗、またはタイムアウトの要約
• 停止条件: 成功信号、失敗信号、タイムアウト
• 権限境界: ログの読み取りだけ、本番には触らない

6.3 毎日の issue / PR triage

• トリガー頻度: 1 日 1 回
• 実行場所: standalone automation または thread heartbeat
• 成功出力: 人間が見るべき項目を inbox に送る
• 停止条件: 新しい項目がなければ沈黙
• 権限境界: 既定は workspace-write。full access は避ける

7. 自動化が失敗したら最初に見る 6 項目

1. Codex app はまだ動いているか、マシンは起きているか。
2. project path はまだ存在するか、worktree は移動や削除されていないか。
3. sandbox が書き込みやネットワーク操作を止めていないか。
4. thread automation は本当に文脈保持が必要か。
5. worktree が溜まりすぎていないか。
6. prompt に「いつ止まるか、いつ報告するか」が書かれているか。

8. FAQ チェックリスト

8.1 Automations は定期ジョブですか、それとも常時動く agent ですか？

定期的または周期的に起こされるバックグラウンドジョブに近いです。起動するたびに確認・処理・報告を行い、その後は待機に戻ります。forever loop ではありません。

8.2 standalone/project と thread automation の違いは何ですか？

standalone/project automation は独立したバックグラウンド実行で、毎回新しく始まり、結果は inbox / triage に入ります。thread automation は同じスレッドの heartbeat で、現在の会話の文脈を保ちます。

8.3 どんなタスクが Automations に向いていて、どんなタスクが向いていませんか？

向いているのは、反復性が高く、ルールが明確で、検証可能なタスクです。向いていないのは、頻繁な人間判断が必要、外部状態の変化が速い、prompt が不安定、というタイプです。

8.4 worktree と local project はどう選べばいいですか？

編集の可能性があるタスクは worktree を優先します。local project は、読み取り専用やレポート系の作業だけに使うのが無難です。

8.5 アプリを閉じたら、PC をスリープさせたら、まだ動きますか？

いいえ。project-scoped automation はローカル app、マシン、プロジェクトパスに依存するので、アプリを閉じるかマシンが休止すると止まります。

8.6 Computer Use はいつ使うべきですか？

GUI を直接操作する必要があり、API や web インターフェースがない場合だけです。普通のコードで済むなら、たいていは不要です。

8.7 コストと頻度はどう制御しますか？

必要な分だけ頻度を上げ、/status で状態を確認し、各 automation に停止条件を書き、過密なポーリングを避けます。

9. まとめ

Computer Use、内蔵ブラウザ、Automations は、それぞれ違う層の問題を解きます。Automations は、安定していて、検証できて、繰り返し発生する作業を Codex にバックグラウンドで任せるためのものです。thread automation は跨日の長時間タスク追跡用、worktree と sandbox はリスク管理用です。

一番安全な順番はいつも同じです。まずタスクが自動化に向くかを見極める。次に実行場所と権限を決める。最後に頻度を調整する。人間が正しく回せる流れを先に安定させてから、Codex に少し長く回してもらうのがいちばん堅いです。