【備忘録】Codex appのAutomationsを試す前に整理したこと

Posted at 2026-05-05

はじめに

Codex appを触っていると、Automationsという機能があります。

名前の通り、Codexに定期的な作業をお願いできる機能ですが、最初に触ろうとしたときに、いくつか疑問が出てきました。

PCを閉じていても動くのか
ローカルのファイルはどう扱われるのか
WorktreeとLocal実行はどう使い分けるのか
いきなり自動修正させても大丈夫なのか

この記事では、Codex appのAutomationsについて、まず試す前に理解しておきたかったことを備忘録としてまとめます。

特に「PCを閉じても動くのか？」「ローカルのファイルはどう扱われるのか？」が個人的に気になったので、そのあたりを中心に整理しています。

※ 本記事は2026年5月時点でCodex appの公式ドキュメントを確認した内容をもとに整理しています。今後、機能や仕様が変更される可能性があります。
※ Codexにはweb（クラウド）版もありますが、本記事はCodex app（デスクトップアプリ）のAutomationsに絞った内容です。

Automationsとは：通常スレッドとの違いから理解する

Automationsは、Codexに繰り返しタスクをバックグラウンドで実行してもらうための機能です。

通常のCodexスレッドは、その場で依頼して、会話しながら作業を進める使い方です。一方でAutomationsは、ある程度パターンが決まった作業をスケジュールに乗せる使い方に向いています。

たとえば、毎朝issueを確認する、CI失敗を要約する、前日の変更内容を整理する、といった作業です。実行結果は「Triage」と呼ばれる受信箱のような場所に溜まり、後からまとめて確認できる仕組みになっています。報告すべき内容がない場合は、そのrunは自動的にアーカイブされる仕様です。

使い方	向いていること	例
通常スレッド	試行錯誤しながら進める作業	実装相談、バグ調査、記事構成の相談
Automations	決まった確認を繰り返す作業	issue確認、CI失敗の要約、変更内容の整理

Standalone automationとThread automationの2種類

公式ドキュメントを読んでいて整理しておきたかったのが、Automationsには2種類ある、という点です。

種類	作り方のイメージ	特徴
Standalone automation	Automationsペイン側から、独立した定期タスクとして作成する	毎回フレッシュなrunとして実行され、結果はTriageに出る
Thread automation	通常スレッド内でCodexに「このスレッドに紐づけて定期実行して」と依頼して作成する	そのスレッドの文脈を保ったまま、定期的に再開する

画面上で「Standalone / Thread」を直接切り替えるトグルがあるわけではない 点に注意が必要です。公式ドキュメントには次のように書かれています。

You can create and update automations from a regular Codex thread. Describe the task, the schedule, and whether the automation should stay attached to the current thread or start fresh runs.

つまり、Automationは通常スレッド内でCodexに依頼する形でも作れて、その際に「このスレッドに紐づけるか」「フレッシュなrunとして開始するか」を伝えると、Codex側が適切なタイプを選んでくれる、というイメージです。少なくとも公式ドキュメント上は、既存automationを後からUIで相互に切り替える操作としてではなく、作成・更新時に「このスレッドに紐づけるか」「フレッシュなrunとして開始するか」をCodexに伝えるもの として説明されています。

最初に試すなら、毎回独立して動くStandalone automationの方がイメージしやすいです。Thread automationは公式ドキュメントで「heartbeat-style recurring wake-up calls」と表現されており、同じスレッドに定期的に戻ってきて続きを進める、というイメージです。

公式では、Thread automationの使いどころとして、PRのステータスをチェックして新しいレビューフィードバックに対応するような継続ワークフローや、進行中のリサーチ・トリアージタスクを同じスレッドで続けたいケースが挙げられています。

PCを閉じても動くのか

個人的に一番気になったのが、「PCを閉じても動くのか？」という点です。

結論から言うと、project-scoped automationについては、PCを閉じてスリープしている状態では動かない前提で考えた方がよさそうです。
Codex appが起動していて、対象プロジェクトがローカルディスク上で利用できる必要があります。

公式ドキュメントには、次のように明記されています。

For project-scoped automations, the app needs to be running, and the selected project needs to be available on disk.

つまり、project-scopedなAutomationsについては Codex appが起動していて、対象プロジェクトがローカルディスク上で利用できる状態 が前提になります。

そのため、Codex appのproject-scoped automationは、「完全にクラウド側で勝手に動き続けるcron」とは少し違うものとして理解したほうが安全です。OpenAI Academyの公式ガイドでも、automationsは「ノートPCが起きていてCodexが動いている状態で最も安定して使える」（automations work best when your laptop is awake and Codex is running）という趣旨で説明されています。

免責事項: 筆者は設定を未確認。

ちなみに、長時間タスクのために、Codex appの設定には「Prevent sleep while running（実行中はスリープを防ぐ）」というトグルが用意されています。実行中にPCがスリープしてしまうと、Codexの動作も止まってしまうため、長めのタスクを動かす場合はこのトグルをONにしておくのが無難です。

なお、OpenAIは将来的にクラウドベースのトリガーをサポートする方針を公表しており、「コンピュータが起動していなくてもCodexがバックグラウンドで継続的に動けるようにする」と言及されています。今後この前提が変わる可能性はありますが、少なくとも現時点ではproject-scoped automationについてはローカル動作が基本、と理解しておくのが安全です。

Local / Worktree / sandboxの考え方

Gitリポジトリを対象にする場合、AutomationをLocalで実行するか、専用のbackground worktreeで実行するかを選べます。公式ドキュメントには「each automation can run either in your local project or on a dedicated background worktree」と説明されており、Automationごとに作成・設定時に選ぶ形になります。

実行方法	特徴	最初に試すときの印象
Worktree	Automation用の作業場所が分かれる	変更を作業中ファイルから分離できる、最初に試すなら無難
Local	メインのチェックアウトで直接動く	編集中のファイルを変更する可能性があることに留意

非Gitプロジェクトの場合は、worktreeが使えないため、プロジェクトディレクトリで直接動きます。これも知っておくと、最初の挙動でハマりにくいです。

公式の説明をそのまま借りると、「Worktreeは未完了のローカル作業からAutomationの変更を分離したいときに使う」「Localはメインのチェックアウトで直接動かしたいときに使うが、編集中のファイルを変更する可能性があることに留意する」という整理になります。迷ったらWorktreeで試して、必要に応じてLocalに切り替える、という順序が無難です。

sandboxとapproval policy

Automationsは無人で動く前提になるため、sandbox（実行範囲の制限）とapproval policy（承認ポリシー）の設定も重要です。

公式ドキュメントによると、sandbox modeには3段階あります。

sandbox mode	動作
`read-only`	ファイル変更・ネットワーク・他アプリ操作を伴うツール呼び出しは失敗する
`workspace-write`	ワークスペース外への変更・ネットワーク・他アプリ操作を伴うものは失敗する
`danger-full-access`（full access）	Codexが確認なしにファイル変更・コマンド実行・ネットワークアクセスを行える

Automationsは無人で動くため、read-onlyのままだとファイル変更やネットワークアクセスを伴うtool callが失敗しやすい点には注意が必要です。公式ドキュメントでも「read-onlyのときはworkspace writeへの変更を検討するとよい」と案内されています。

公式ドキュメントでは、Full access（danger-full-access + never）との対比として、sandbox_mode = "workspace-write" + approval_policy = "on-request" が、よりリスクの低いローカル自動化のプリセットとして紹介されています。「公式推奨」というよりは、「Full accessよりリスクが低い側のプリセット」と理解しておくのがちょうどよいです。

そしてもう1つ重要なのが、Automationsは組織ポリシーが許す限り approval_policy = "never" で動く、という点です。これは「無人で動くために、デフォルトでは承認を求めない」という設計だと理解しておくと、Automationsの性格が掴みやすくなります。

最初から広い権限を与えるより、まずは「確認するだけ」「要約するだけ」「差分案を出すだけ」のタスクから始めるのが無難です。

向いているタスクとサンプルプロンプト

最初から自動修正まで任せるより、まずは読み取り中心のタスクから始めるのが扱いやすいです。

「毎回自分が見に行っていた情報を、先にCodexに見ておいてもらう」くらいの使い方がちょうどよいと感じました。

以下、最初に試しやすそうなタスクのサンプルプロンプトです。

前日の変更を要約する

このプロジェクトで、直近24時間の変更内容を確認してください。

以下を日本語で箇条書きにしてください。

- 重要な変更
- 未完了に見える作業
- 次に確認すべき点

コード変更は行わず、レポートだけ作成してください。

READMEと実装のズレを確認する

このリポジトリのREADMEと主要なドキュメントを確認してください。

現在の実装やファイル構成とズレていそうな記述があれば、修正候補をまとめてください。

まずはファイルを変更せず、差分案だけ提示してください。

CI失敗やテスト失敗を整理する

このプロジェクトのテストとlintの実行方法を確認し、可能であれば実行してください。

失敗した場合は、以下をまとめてください。

- 失敗箇所
- 原因候補
- 修正案
- 人間が確認すべき点

勝手に大きな修正はせず、必要な変更案を提示してください。

いずれも「変更しないで報告だけしてもらう」型のプロンプトです。最初はこのくらいのスコープにしておくと、Triageに溜まる結果も確認しやすくなります。

Skills / AGENTS.mdとどう組み合わせるか

Automationsだけで全部を頑張るより、SkillsやAGENTS.mdと組み合わせると整理しやすくなります。

公式のbest practicesでも「skills define the method, automations define the schedule（Skillsはやり方を定義し、Automationsはスケジュールを定義する）」という整理が示されており、ざっくり次のように分けて考えると理解しやすいです。

要素	役割
Automations	いつ実行するか
Skills	どう実行するか
AGENTS.md	このリポジトリで守ってほしい前提

たとえば、毎週READMEを点検するAutomationを作る場合、確認観点や出力形式はSkillやAGENTS.md側に寄せておくと、プロンプトが長くなりすぎずに済みます。Automationsの中では $skill-name のような形でSkillを明示的に呼び出すこともできます。

逆に言うと、Automationsのプロンプトに毎回長い手順を書き込むより、再利用しそうな手順はSkillに、リポジトリ固有のルールはAGENTS.mdに、と寄せていく方が、後から見返したときに整理しやすいです。AGENTS.mdは、リポジトリ構成や実行・テスト・lintコマンド、コーディング規約、制約事項といった「Codexに最初に伝えておきたい前提」をまとめておく場所として使えます。

試す前のチェックリストと注意点

最後に、実際に試す前のチェックポイントをまとめます。

対象プロジェクトはGit管理されているか（worktreeが使えるか）
Codex appを起動した状態で実行されることを理解しているか
LocalかWorktreeかを決めたか（迷ったらWorktreeが無難）
最初はファイル変更なしのプロンプトにしたか
実行頻度を高くしすぎていないか
sandbox modeを広げすぎていないか（特にfull accessは慎重に）
結果がTriageにどう出るか確認したか
不要なrunやworktreeが増えていないか定期的にチェックしているか

特にworktreeを選んだ場合は、頻繁にスケジュール実行すると数が増えていきやすいので、不要なrunはアーカイブする運用にしておくと管理が楽になります。公式ドキュメントによると、Codex-managed worktreeはデフォルトで直近15個まで保持され、関連するスレッドをアーカイブした場合や上限を超えた場合に自動削除されます。この上限はSettingsで変更したり、自動削除をオフにすることもできます。

Automationsは便利ですが、無人で動く前提の機能です。最初は「読むだけ」「まとめるだけ」「差分案を出すだけ」くらいの小さなタスクから始めるのが扱いやすいと思います。