スケジュール済みタスク¶
繰り返し実行するタスクをスケジュールして、バックグラウンドで実行します。アクティブ、一時停止中、完了済みのタスクと最近の実行結果は Scheduled で確認できます。より複雑な作業では、スケジュール済みタスクと スキル を組み合わせることができます。
ChatGPT デスクトップアプリでは、スケジュール済みタスクでローカルプロジェクトを操作し、プロジェクトディレクトリまたは分離された worktree で実行できます。スケジュール済みタスクでローカルファイルが必要な場合は、コンピューターの電源を入れたまま、アプリを実行しておいてください。
たとえば、テレメトリーエラーを評価して修正を提出するタスクや、最近のコードベースの変更に関するレポートを作成するタスクをスケジュールできます。同じコンテキストを使い続ける必要がある継続的な作業では、既存のチャット内でタスクをスケジュールします。
プロジェクトスコープのスケジュール済みタスクでは、マシンの電源を入れたまま、ChatGPT デスクトップアプリを実行しておいてください。タスクの実行時に、選択したプロジェクトがディスク上で引き続き利用可能である必要があります。
Git リポジトリでは、スケジュール済みタスクをローカルプロジェクトで実行するか、新しい worktree で実行するかを選択できます。どちらのオプションもバックグラウンドで実行されます。worktree を使うと、スケジュール済みタスクによる変更を未完了のローカル作業から分離できます。一方、ローカルプロジェクトで実行すると、作業中のファイルが変更される可能性があります。バージョン管理されていないプロジェクトでは、スケジュール済みタスクはプロジェクトディレクトリで直接実行されます。
モデルと推論の負荷はデフォルト設定のままにすることも、スケジュール済みタスクの実行方法をより細かく制御するために明示的に選択することもできます。
スケジュール済みタスクは、デフォルトのサンドボックス設定で無人実行されます。タスクを成功させるために必要な最小限のアクセスから始め、必要な場合にのみネットワークアクセスや、より広範なファイルアクセスを許可してください。サンドボックスについて を確認してください。
スケジュール済みタスクを管理する¶
ChatGPT デスクトップアプリのサイドバーにある Scheduled で、すべてのスケジュール済みタスクとその実行結果を確認できます。
Scheduled ビューは受信トレイとして機能します。結果のあるスケジュール済みタスクの実行が表示され、実行に対応が必要な場合は未読インジケーターが表示されます。
スタンドアロンのスケジュール済みタスクは、実行のたびに新しいチャットを開始し、結果を Scheduled に報告します。各実行を独立させたい場合や、1 つのスケジュール済みタスクを 1 つ以上のプロジェクトで実行したい場合に使用します。カスタムの実行間隔が必要な場合は、カスタムスケジュールのコントロールを使用してください。高度なスケジュールでは、RFC 5545 の繰り返しルール（RRULE）を編集します。たとえば、RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0 のように指定します。
Git リポジトリでは、各スケジュール済みタスクをローカルプロジェクトで実行するか、専用のバックグラウンド worktree で実行できます。スケジュール済みタスクによる変更を未完了のローカル作業から分離したい場合は、worktree を使用してください。メインのチェックアウトでスケジュール済みタスクを直接作業させたい場合は、ローカルモードを使用します。ただし、現在編集中のファイルが変更される可能性がある点に注意してください。バージョン管理されていないプロジェクトでは、スケジュール済みタスクはプロジェクトディレクトリで直接実行されます。同じスケジュール済みタスクを複数のプロジェクトで実行することもできます。
Web の Work モード、または ChatGPT デスクトップアプリの Work モードや Codex では、スケジュール済みタスクでプラグインを使用できます。スケジュール済みタスクではスキルも使用できます。スケジュール済みタスクをチーム間で保守しやすく共有可能にするには、スキル を使用してアクションを定義し、ツールとコンテキストを提供してください。ワークフローが自動的なツール選択に依存しないようにする場合は、タスクプロンプトで特定のスキルを選択または呼び出してください。
ChatGPT にスケジュール済みタスクの作成や更新を依頼する¶
ChatGPT または Codex のチャットから、スケジュール済みタスクを作成および更新できます。作業内容、スケジュール、各実行の結果を現在のチャットに返すか新しいチャットを開始するかを説明してください。ChatGPT はプロンプトを作成し、適切な実行先を選び、スコープや実行間隔が変わったときにスケジュール済みタスクを更新できます。
たとえば、デプロイが完了するまで現在のチャットからフォローアップをスケジュールするよう ChatGPT に依頼したり、プロジェクトを定期的に確認するスタンドアロンのスケジュール済みタスクを作成するよう依頼したりできます。
スキルでは、スケジュール済みタスクを作成または更新することもできます。たとえば、プルリクエストを監視するスキルで、GitHub プラグインを使って PR のステータスを確認し、新しいレビューコメントに対応するスケジュール済みタスクを設定できます。
チャット内でタスクをスケジュールする¶
ChatGPT にスケジュールに従ってそのチャットに戻ってきてほしい場合は、既存のチャット内でタスクをスケジュールします。スケジュール済みタスクは、新しいプロンプトから毎回開始するのではなく、チャットの既存のコンテキストを使用します。
チャット内のスケジュール済みタスクでは、アクティブなフォローアップループ用に分単位の間隔を使用したり、特定の時刻に確認が必要な場合に日次または週次のスケジュールを使用したりできます。
次のような場合に、チャット内でタスクをスケジュールします。
- 長時間実行される操作が完了するまで確認する場合
- 結果を同じチャットに残したい Slack、GitHub、その他の接続済みソースをポーリングする場合
- 一定間隔でレビューのループを続けるよう ChatGPT に通知する場合
- PR のステータス確認や新しいフィードバックへの対応など、プラグインを使用するスキル駆動のワークフローを実行する場合
- コンテキストを失わずに継続中の調査やトリアージのチャットを続ける場合
各実行を独立させたい場合や、結果を Scheduled に個別の実行として表示したい場合は、スタンドアロンのスケジュール済みタスクを使用してください。
チャット内でタスクをスケジュールする場合は、プロンプトを長期的に使える内容にしてください。各実行で ChatGPT が行うこと、報告すべき重要事項があるかどうかの判断方法、停止またはユーザーに入力を求めるタイミングを記述する必要があります。
スケジュール済みタスクをテストする¶
タスクをスケジュールする前に、まず通常のチャットでプロンプトを手動でテストしてください。これにより、次の点を確認できます。
- プロンプトが明確で、適切なスコープになっていること。
- 選択したモデルまたはデフォルトのモデル、推論の負荷、ツールが期待どおりに動作すること。
- 生成された出力をレビューできること。
実行のスケジュールを開始したら、最初の数件の出力を確認し、必要に応じてプロンプトや実行間隔を調整してください。
ChatGPT デスクトップアプリでは、$skill-name を使用して、スケジュール済みタスクのプロンプトから特定のスキルを明示的にトリガーできます。
スケジュール済みタスクの worktree をクリーンアップする¶
Git リポジトリで worktree を選択すると、頻繁なスケジュールによって時間の経過とともに多数の worktree が作成される可能性があります。不要になったスケジュール済み実行をアーカイブし、worktree を保持する意図がない限り、実行をピン留めしないでください。
権限とセキュリティモデル¶
スケジュール済みタスクは無人実行され、デフォルトのサンドボックス設定を使用します。
これらの境界について平易な言葉で説明した内容は、サンドボックスの概要 を参照してください。ファイルシステムとネットワークのルールについては、権限 を参照してください。
- サンドボックスモードが read-only の場合、ファイルの変更、ネットワークへのアクセス、コンピューター上のアプリの操作が必要なツール呼び出しは失敗します。サンドボックス設定を workspace write に更新することを検討してください。
- サンドボックスモードが workspace-write の場合、ワークスペース外のファイルの変更、ネットワークへのアクセス、コンピューター上のアプリの操作が必要なツール呼び出しは失敗します。ルール を使用すると、サンドボックス外で実行するコマンドを選択的に許可リストに追加できます。
- サンドボックスモードが full access の場合、バックグラウンドのスケジュール済みタスクには高いリスクが伴います。ChatGPT が確認なしにファイルを変更したり、コマンドを実行したり、ネットワークにアクセスしたりする可能性があるためです。サンドボックス設定を workspace write に更新し、ルール を使用して、エージェントが full access で実行できるコマンドを選択的に定義することを検討してください。
管理対象環境では、管理者が管理者適用要件を使用してこれらの動作を制限できます。たとえば、approval_policy = "never" を禁止したり、許可されるサンドボックスモードを制限したりできます。管理者適用要件 (requirements.toml) を参照してください。
組織のポリシーで許可されている場合、スケジュール済みタスクは approval_policy = "never" を使用します。管理者要件で approval_policy = "never" が許可されていない場合、スケジュール済みタスクは、選択した権限モードの承認動作にフォールバックします。
例¶
新しいスキルを自動的に作成する¶
Scan all of the `~/.codex/sessions` files from the past day and if there have been any issues using particular skills, update the skills to be more helpful. Personal skills only, no repo skills.
If there’s anything we’ve been doing often and struggle with that we should save as a skill to speed up future work, let’s do it.
Definitely don't feel like you need to update any- only if there's a good reason!
Let me know if you make any.
プロジェクトを最新の状態に保つ¶
Look at the latest remote origin/master or origin/main . Then produce an exec briefing for the last 24 hours of commits that touch <DIRECTORY>
Formatting + structure:
- Use rich Markdown (H1 workstream sections, italics for the subtitle, horizontal rules as needed).
- Preamble can read something like “Here’s the last 24h brief for <directory>:”
- Subtitle should read: “Narrative walkthrough with owners; grouped by workstream.”
- Group by workstream rather than listing each commit. Workstream titles should be H1.
- Write a short narrative per workstream that explains the changes in plain language.
- Use bullet points and bolding when it makes things more readable
- Feel free to make bullets per person, but bold their name
Content requirements:
- Include PR links inline (e.g., [#123](...)) without a “PRs:” label.
- Do NOT include commit hashes or a “Key commits” section.
- It’s fine if multiple PRs appear under one workstream, but avoid per‑commit bullet lists.
Scope rules:
- Only include changes within the current cwd (or main checkout equivalent)
- Only include the last 24h of commits.
- Use `gh` to fetch PR titles and descriptions if it helps.
Also feel free to pull PR reviews and comments
スケジュール済みタスクとスキルを組み合わせて自分のバグを修正する¶
自分のコミットによって導入されたバグを修正しようとする新しいスキルを作成します。新しい $recent-code-bugfix を作成し、個人用スキルに保存します。
---
name: recent-code-bugfix
description: Find and fix a bug introduced by the current author within the last week in the current working directory. Use when a user wants a proactive bugfix from their recent changes, when the prompt is empty, or when asked to triage/fix issues caused by their recent commits. Root cause must map directly to the author’s own changes.
---
# Recent Code Bugfix
## Overview
Find a bug introduced by the current author in the last week, implement a fix, and verify it when possible. Operate in the current working directory, assume the code is local, and ensure the root cause is tied directly to the author’s own edits.
## Workflow
### 1) Establish the recent-change scope
Use Git to identify the author and changed files from the last week.
- Determine the author from `git config user.name`/`user.email`. If unavailable, use the current user’s name from the environment or ask once.
- Use `git log --since=1.week --author=<author>` to list recent commits and files. Focus on files touched by those commits.
- If the user’s prompt is empty, proceed directly with this default scope.
### 2) Find a concrete failure tied to recent changes
Prioritize defects that are directly attributable to the author’s edits.
- Look for recent failures (tests, lint, runtime errors) if logs or CI outputs are available locally.
- If no failures are provided, run the smallest relevant verification (single test, file-level lint, or targeted repro) that touches the edited files.
- Confirm the root cause is directly connected to the author’s changes, not unrelated legacy issues. If only unrelated failures are found, stop and report that no qualifying bug was detected.
### 3) Implement the fix
Make a minimal fix that aligns with project conventions.
- Update only the files needed to resolve the issue.
- Avoid adding extra defensive checks or unrelated refactors.
- Keep changes consistent with local style and tests.
### 4) Verify
Attempt verification when possible.
- Prefer the smallest validation step (targeted test, focused lint, or direct repro command).
- If verification cannot be run, state what would be run and why it wasn’t executed.
### 5) Report
Summarize the root cause, the fix, and the verification performed. Make it explicit how the root cause ties to the author’s recent changes.
その後、新しいスケジュール済みタスクを作成します。