Codexのスケジュール機能の使い方｜繰り返す調査を予定に入れ、時刻と成果を確かめる

Codexで繰り返す調査を予定に入れるには、ChatGPTデスクトップアプリならScheduled（スケジュール）の画面から、Web版ならChatかChatGPT Workから登録します。Codex CLIとIDE拡張には管理画面がありません。普通のチャットで依頼文を試してから、実行場所と権限を決めて登録し、最初の数回は時刻と結果を確かめます。この記事では、登録の種類の選び方、依頼文の書き方、時刻のずれの報告、止まる条件を説明します。

この記事は、OpenAIの公式資料に基づく解説です。参照したのはScheduled tasks、Best practices、Worktrees、Pricing、Sandbox、Agent approvals & security、ChatGPT desktop app commands、ChatGPT Work admin FAQで、いずれも2026年11月3日に確認しました。時刻のずれについては、公式資料に記載がないため、利用者がGitHubに投稿した報告を、報告であると明記して紹介します。依頼文の例と表の整理は編集部がまとめたものです。編集部のCodexでの実測はしていません。

Codexのスケジュールはどこで登録するか

予定の機能は、公式資料のScheduled tasksにまとまっています。資料のURLと、アプリを開くリンク（codex://automations）にはautomationsの語があり、検索ではCodex Automationsと呼ばれることもあります。登録と管理ができるのは、次の表のとおりデスクトップアプリとWeb版です。

料金ページの機能表のLocal featuresの節では、プロジェクトと単独の予定はPlus、Pro、Business、Enterprise、APIキーで利用できると書かれています。表にFreeとGoの列はありません。Enterpriseなどの管理された環境では、管理者の設定で使えない場合があります。

GmailやSlack、GitHubの出来事をきっかけに動かす方法は、対象のプランのWeb版とモバイルだけで使えます。デスクトップアプリ、CLI、IDE拡張では使えず、時刻の予定と組み合わせることもできません。この記事では時刻で動かす調査を扱います。

スクリプトやCIからcodex execを呼ぶ方法は別の仕組みです。こちらはcodex execの解説で説明しています。

スケジュールは単独タスクとチャット内のどちらで登録するか

登録の種類は2つあります。違いは、毎回新しいチャットで始めるか、同じチャットに戻るかです。

迷ったら、調査の答えが前回の内容に左右されるかで決めます。「直近7日間のコミットをまとめる」のように毎回完結するなら単独のタスクです。「前回の指摘が直ったかを見る」のように前の話を引き継ぐならチャットの中のタスクが合います。公式資料も、文脈を失わずに調査や仕分けを続ける用途をチャットの中のタスクの例に挙げています。

デスクトップアプリではScheduledの画面から登録でき、チャットで頼むこともできます。チャットで頼む場合は、仕事の内容、実行する時、同じチャットに戻るのか新しいチャットにするのかを伝えます。

スケジュールの実行場所は手元とWorktreeのどちらにするか

デスクトップアプリでGitリポジトリを選ぶと、作業中のプロジェクトで動かすか、新しいWorktreeで動かすかを選べます。Gitで管理していないフォルダでは、そのフォルダで直接動きます。

調査の途中でファイルを書く可能性があるなら、編集中の変更と混ざらないWorktreeを選びます。ファイルを変えない調査でも、途中の状態を読みたくないならWorktreeが安全です（編集部の整理です）。

Worktreeを選ぶ時は、片付けの決まりも確認します。Worktreesの資料によると、CodexはWorktreeを既定で直近の15個まで残します。チャットをアーカイブするとそのWorktreeが消え、上限を超えると古いものが消えます。消す前に作業の控えを保存します。ピン留めしたチャットや実行中のチャットのWorktreeは自動では消えません。残したい回だけピン留めし、不要な回はアーカイブします。詳しくはWorktreeの解説にまとめています。

スケジュールに入れる依頼文は何を書くか

公式資料は、登録前に普通のチャットで依頼文を試すよう案内しています。確かめるのは、依頼が明確で範囲が合っているか、モデルと設定とツールが想定どおりに動くか、結果を確認できる形で出るかの3点です。

チャットの中のタスクについては、毎回やること、報告すべきことがあるかの判断、止まる時や尋ねる時の条件を書くよう案内しています。編集部は、単独のタスクでも同じ3点を書くことをおすすめします。人が見ていない間に動くからです。次の例は、説明用に編集部が作ったものです。

直近7日間にmainへ入ったコミットを調べ、公開APIに影響する変更だけを報告してください。

範囲：
- 対象はsrc/api/とdocs/api/だけ
- ファイルは変更しない

報告の条件：
- 引数、戻り値、エラーの形が変わったコミットがあれば、項目ごとに書く
- なければ「該当なし」と、調べた期間と確認したコミット数だけを書く

形式：
- 変更内容、コミットのID、影響しそうな呼び出し元、根拠にした差分の行、調べた日時

止まる条件：
- 履歴を取得できない時は推測で書かず、失敗したコマンドとエラーを書いて終える

手順が長くなる場合は、スキルに分けます。公式のBest practicesは「スキルが方法を決め、スケジュールが時刻を決める」と説明し、指示をまだ何度も足している作業は先にスキルにするよう勧めています。デスクトップアプリでは、依頼文に$skill-nameと書いて特定のスキルを呼び出せます。

スケジュールの時刻は登録後にどう確かめるか

ここは注意が必要です。公式資料のScheduled tasksには、時刻をどのタイムゾーンで解釈するかが書かれていません。書かれているのは、細かい周期はRRULEという形式で編集できることと、RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0という例だけです。

一方で、Codexの公式GitHubリポジトリには、デスクトップアプリの予定が指定した時刻とずれるという報告（#26633）が2026年6月から出ており、2026年11月3日の確認時点で未解決です。2026年11月1日（UTC）のコメントは、版26.1027.51404のmacOS、タイムゾーンAsia/Taipei（UTC+8）で次の結果を示しています。

投稿者の分析では、毎日か毎週の単純な規則は手元の時刻として扱われ、それ以外の多くはUTCとして扱われています。同じ分析に沿えば、公式資料の毎月の例も手元の時刻にならず、日本では9時でなく18時に動く可能性があります。日本の環境の報告もあります。2026年8月のコメントでは、Asia/Tokyoのデスクトップアプリで、RDATEという形で保存された07:45の予定が16:45に動いたと書かれています。これらは利用者の報告で、OpenAIが認めた仕様の説明ではありません。編集部も再現していません。ただ、登録後に確かめる理由としては十分です。

確かめる手順は次のとおりです（編集部の整理です）。

1. 登録後に、一覧の時刻と詳細の次回の実行時刻（報告ではNext runと表示）を見比べます。一覧は正しく、詳細だけ違う時刻を示すという別の報告（#28693）もあります。チャットで頼んで登録した場合は、登録できたという返事だけで済ませず、画面の時刻を読みます。
2. 最初の実行が本当に動いた時刻を、Scheduledの実行結果で確かめます。実行時刻がどう表示されるかは公式資料に書かれていないので、見当たらなければ、チャットの開始時刻や依頼文で書かせた「調べた日時」と照らします。表示だけでは、どちらが正しいかを判断できません。
3. 時刻を守る必要がある作業は、最初の数回を人が見られる時間に合わせ、ずれがないと分かってから本来の時刻に移します。
4. 規則は、毎日か毎週の単純な形から試します。先ほどの報告で正しく計算された形だからです。ただし古い版では、毎週の規則でもずれたという報告が#26633の本文にあるので、安全な形だと決めつけず、上の確認は省きません。DTSTART;TZID=を足しても直らなかったという報告もあります。

ずれを補うためにUTCへ換算した時刻を登録する方法も報告されています。ただし、単純な形は手元の時刻で扱われるという報告もあるので、換算するとかえってずれる場合があります。投稿者自身も、不具合が直ると予定がその分ずれると注意しています。換算して登録した場合は、そのことをチームのメモに残しておきます。

スケジュールの成果はどこで確かめるか

デスクトップアプリのScheduledは受信箱として働きます。発見があった回がここに現れ、確認が必要な回には未読の印が付きます。単独のタスクは回ごとにチャットを作り、Scheduledに結果を出します。チャットの中のタスクは元のチャットへ戻ります。発見のなかった回がどう表示されるかは資料に書かれていないので、最初の数回で確かめます。

公式資料は、最初の数回の結果を読み、依頼文や周期を調整するよう案内しています。編集部なら、次の表で確かめます。

報告を正しいものとして扱う前に、少なくとも1件は根拠を自分で開きます。結果を手元で続けて扱う時は、WorktreeのチャットをヘッダーのHand offで手元へ移せます。コード変更を受け入れる前の確認はコードレビューの解説を参考にしてください。

スケジュールが動かない、止まる時は何を見るか

この節はデスクトップアプリの場合です。スケジュールのタスクは人が見ていない間に、既定のサンドボックス設定で動きます。組織のポリシーが許せばapproval_policy = "never"で動くため、途中で承認を求められない前提で権限を決めます。権限による失敗の条件は、サンドボックスの資料とScheduled tasksの資料が示しています。

たとえば、先ほどの例でリモートの最新をgit fetchする場合、ネットワークが要るので、workspace-writeのままでは失敗する見込みです。調査に必要な範囲を、登録前のチャットで確かめておきます。Web検索はコマンドの通信とは別の設定で、公式資料によると既定ではOpenAIが保持する索引の結果を返します。最新のページを読む調査かどうかも、最初の回の報告で確かめます。

止める時と再開する時

Scheduledには有効、一時停止、完了の状態が表示されると資料にあります。一方で、確認した資料には、止める操作や再開する操作の手順、再開した後の次回の時刻、止めていた間の回の扱い、失敗した回の再試行の決まりは書かれていません。そこで編集部は、次の手順をおすすめします。

1. 止めたい時は画面で状態を変え、一時停止になったことを読み直します。チャットから更新を頼んだ場合も同じです。
2. 再開した時は、次回の時刻を読み直し、再開後の最初の実行が予定の時刻に動いたかを確かめます。
3. 止めていた間の調査が必要なら、再開の後に任せきりにせず、依頼文の期間を広げて別に1回頼みます。

#26633には、更新や一時停止と再開をしても、ずれた時刻の実行がすぐには止まらなかったという利用者の報告（2026年7月）もあります。止めた直後の時間帯は実行結果を見ておくと安心です。

動かないことに気づける形にしておくことも大切です。別の報告（#50997）は、チャットの中の定期実行で、保存された次回の時刻から2分の観察の間に開始を確認できず、記録も見つからなかったと書いています。報告者は原因を特定しておらず、PCが起動していたかも確かめられていないとしています。大事な調査は、週に一度は実行結果の一覧を見ます。

回数が多いほど使用量も増えます。OpenAIのChatGPT Workの管理者向けFAQは、定期的な作業を使用量の差が出やすい例に挙げています。最初は週1回などの低い頻度から始めると、結果を読む余裕もできます。

まとめ：スケジュールは試してから登録し、時刻と結果を読み直す

Codexのスケジュールは、デスクトップアプリのScheduledか、Web版のChatかChatGPT Workから登録します。毎回完結する調査は単独のタスク、前の話を引き継ぐ調査はチャットの中のタスクにします。依頼文には、範囲、報告の条件、根拠、止まる条件を書きます。登録したら、一覧と詳細の時刻、最初の実行の時刻、報告の根拠を確かめてください。止めた後や再開した後も同じです。時刻の解釈は公式資料に書かれておらず、ずれの報告も出ているので、ここは必ず自分の環境で見てください。

Codexの全体像から確かめたい場合は、Codexとは？使い方と仕事でできることを読んでください。チームの定期業務をどこまでCodexに任せるかを整理したい場合は、法人向けのご相談も受け付けています。