スケジュール済みタスク

定期的なタスクをバックグラウンドで実行するようにスケジュールできます。Scheduled では、実行中、一時停止中、完了済みのタスクと最近の実行を確認できます。より複雑な作業では、スケジュール済みタスクと スキルを組み合わせることもできます。

ChatGPT デスクトップアプリ

ChatGPT デスクトップアプリでは、スケジュール済みタスクをローカルプロジェクトと連携させ、プロジェクトディレクトリまたは分離されたワークツリーで実行できます。スケジュール済みタスクでローカルファイルが必要な場合は、コンピューターの電源を入れ、アプリを起動したままにしてください。

ChatGPT web

ワークスペースでスケジュール済みタスクが有効になっている場合は、Web 上の Chat または ChatGPT Work から作成し、Scheduled で実行を管理できます。Web タスクでは、アップロードされたコンテキストや接続済みツールを使用できますが、コンピューター上のフォルダーを直接操作することはできません。

Codex CLI

Codex CLI には Scheduled 管理インターフェースがありません。スケジュール済みタスクの作成と管理には、ChatGPT web またはデスクトップアプリを使用してください。CLI は、事前にプロンプト、スキル、スクリプトを準備してテストする際に役立ちます。

IDE 拡張機能

IDE 拡張機能には Scheduled 管理インターフェースがありません。スケジュール済みタスクの作成と管理には、 ChatGPT web またはデスクトップアプリを使用してください。IDE 拡張機能は、事前にプロンプト、スキル、ワークスペースの変更を準備してテストする際に役立ちます。

Web でスケジュール済みタスクを管理する

Scheduled を開いて、タスクの状態と最近の実行を確認します。各実行を保存済みのプロンプトから開始する場合は、単独のスケジュール済みタスクを使用します。ChatGPT に既存のコンテキストを保持した同じチャットへ戻ってほしい場合は、チャット内のスケジュール済みタスクを使用します。

Web 上のスケジュール済みタスクでは、そのチャットで利用可能なアップロード済みファイル、接続済みツール、スキル、プラグインを使用できます。ローカルフォルダーやワークツリーを実行間で保持することはできません。継続的に必要な指示はタスクのプロンプトまたは添付したスキルに記述し、必要なソース資料はアクセス可能なプロジェクト、アップロード、接続済みサービスに保存してください。

タスクをスケジュールする前に、通常の Web チャットでプロンプトをテストしてください。最初の数回の実行を確認し、結果の範囲が広すぎる場合や追加のコンテキストが必要な場合は、プロンプト、ツール、実行間隔を調整します。

ChatGPT デスクトップアプリ

たとえば、テレメトリエラーを評価して修正を提出するタスクや、コードベースの最近の変更に関するレポートを作成するタスクをスケジュールできます。同じコンテキストを継続して使用する作業では、 既存のチャット内でタスクをスケジュールします。

プロジェクトを対象とするスケジュール済みタスクでは、マシンの電源を入れ、ChatGPT デスクトップアプリを起動したままにしてください。タスクの実行予定時刻に、選択したプロジェクトがディスク上で引き続き利用可能である必要があります。

Git リポジトリでは、スケジュール済みタスクをローカルプロジェクトで実行するか、新しいワークツリーで実行するかを選択できます。どちらもバックグラウンドで実行されます。ワークツリーを使用すると、スケジュール済みタスクによる変更を未完了のローカル作業から分離できます。一方、ローカルプロジェクトで実行すると、現在編集中のファイルが変更される可能性があります。バージョン管理されていないプロジェクトでは、スケジュール済みタスクはプロジェクトディレクトリで直接実行されます。

モデルと推論強度をデフォルト設定のままにすることも、スケジュール済みタスクの実行方法を細かく制御するために明示的に選択することもできます。

ChatGPT サインインで gpt-5.4 または gpt-5.4-mini を使用するスケジュール済みタスクは、これらのモデルが 2026 年 8 月 31 日に廃止される前に更新してください。gpt-5.4 は gpt-5.6-terra に、gpt-5.4-mini は gpt-5.6-luna に置き換えます。

スケジュール済みタスクは、デフォルトのサンドボックス設定で無人実行されます。まずは、タスクの成功に必要な最小限のアクセス権から始め、必要な場合にのみネットワークまたはより広範なファイルへのアクセスを許可してください。サンドボックスについて理解する。

スケジュール済みタスクを管理する

ChatGPT デスクトップアプリのサイドバーにある Scheduled で、すべてのスケジュール済みタスクとその実行を確認できます。

Scheduled ビューは受信トレイとして機能します。結果があるスケジュール済みタスクの実行がここに表示され、確認が必要な実行がある場合は未読インジケーターが表示されます。

単独のスケジュール済みタスクでは、スケジュールされた実行ごとに新しいチャットが開始され、結果が Scheduled に報告されます。各実行を独立させる場合や、1 つのスケジュール済みタスクを複数のプロジェクトで実行する場合に使用します。独自の実行間隔が必要な場合は、カスタムスケジュールのコントロールを使用します。高度なスケジュールでは、 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0 のような RFC 5545 の繰り返しルール（RRULE）を編集します。

Git リポジトリでは、各スケジュール済みタスクをローカルプロジェクトまたは専用のバックグラウンドワークツリーで実行できます。スケジュール済みタスクによる変更を未完了のローカル作業から分離する場合は、ワークツリーを使用します。メインのチェックアウトでスケジュール済みタスクを直接実行する場合はローカルモードを使用しますが、現在編集中のファイルが変更される可能性に注意してください。バージョン管理されていないプロジェクトでは、スケジュール済みタスクはプロジェクトディレクトリで直接実行されます。同じスケジュール済みタスクを複数のプロジェクトで実行することもできます。

Web 上の ChatGPT Work、またはデスクトップアプリの ChatGPT Work や Codex で作成したスケジュール済みタスクでは、プラグインを使用できます。スケジュール済みタスクではスキルも使用できます。スケジュール済みタスクを保守しやすくし、チーム間で共有できるようにするには、 スキルを使用してアクションを定義し、ツールとコンテキストを提供します。ワークフローでツールの自動選択に依存すべきでない場合は、タスクのプロンプトで特定のスキルを選択または呼び出します。

ChatGPT にスケジュール済みタスクの作成または更新を依頼する

ChatGPT または Codex のチャットから、スケジュール済みタスクを作成、更新できます。作業内容、スケジュール、各実行で現在のチャットに戻るか新しいチャットを開始するかを説明してください。ChatGPT はプロンプトを作成し、適切な実行先を選択し、範囲や実行間隔が変わったときにスケジュール済みタスクを更新できます。

たとえば、デプロイの完了を待つ間、現在のチャットでフォローアップをスケジュールするよう ChatGPT に依頼したり、プロジェクトを定期的に確認する単独のスケジュール済みタスクを作成するよう依頼したりできます。

スキルからスケジュール済みタスクを作成、更新することもできます。たとえば、 pull request を監視するスキルで、GitHub プラグインを使って PR の状態を確認し、新しいレビューコメントを修正するスケジュール済みタスクを設定できます。

チャット内でタスクをスケジュールする

ChatGPT にスケジュールに従って同じチャットへ戻ってほしい場合は、既存のチャット内でタスクをスケジュールします。スケジュール済みタスクは毎回新しいプロンプトから開始せず、チャットの既存のコンテキストを使用します。

チャット内のスケジュール済みタスクでは、実行中のフォローアップループに分単位の間隔を使用できます。特定の時刻に確認が必要な場合は、日次または週次のスケジュールも使用できます。

次のような場合に、チャット内でタスクをスケジュールします。

• 長時間実行される処理が完了するまで確認する
• 結果を同じチャットに保持したい場合に、Slack、GitHub、または別の接続済みソースをポーリングする
• 一定の間隔でレビューループを続けるよう ChatGPT に通知する
• PR の状態確認や新しいフィードバックへの対応など、プラグインを使用するスキル駆動のワークフローを実行する
• コンテキストを失わずに、進行中の調査またはトリアージのチャットを継続する

各実行を独立させる場合や、結果を Scheduled に個別の実行として表示する場合は、単独のスケジュール済みタスクを使用します。

チャット内でタスクをスケジュールするときは、繰り返し使用できるプロンプトを作成してください。各実行で ChatGPT が何を行うか、報告すべき重要事項があるかどうかをどのように判断するか、いつ停止するか、またはユーザーに入力を求めるかを記述します。

スケジュール済みタスクをテストする

タスクをスケジュールする前に、まず通常のチャットでプロンプトを手動でテストしてください。これにより、次の点を確認できます。

• プロンプトが明確で、範囲が適切に設定されている。
• 選択したモデルまたはデフォルトのモデル、推論強度、ツールが期待どおりに動作する。
• 出力結果をレビューできる。

実行のスケジュールを開始したら、最初の数回の出力を確認し、必要に応じてプロンプトまたは実行間隔を調整します。

ChatGPT デスクトップアプリでは、$skill-name を使用して、スケジュール済みタスクのプロンプトからスキルを明示的に呼び出せます。

スケジュール済みタスクのワークツリーを整理する

Git リポジトリでワークツリーを選択すると、頻繁なスケジュールによって時間の経過とともに多数のワークツリーが作成されることがあります。不要になったスケジュール済みの実行はアーカイブし、ワークツリーを保持する必要がない限り、実行を固定しないでください。

権限とセキュリティモデル

スケジュール済みタスクは無人で実行され、デフォルトのサンドボックス設定を使用します。

これらの境界について平易な説明は、 サンドボックスの概要を参照してください。ファイルシステムとネットワークのルールについては、権限を参照してください。

• サンドボックスモードが read-only の場合、ファイルの変更、ネットワークへのアクセス、またはコンピューター上のアプリの操作が必要なツール呼び出しは失敗します。サンドボックス設定を workspace write に変更することを検討してください。
• サンドボックスモードが workspace-write の場合、ワークスペース外のファイルの変更、ネットワークへのアクセス、またはコンピューター上のアプリの操作が必要なツール呼び出しは失敗します。ルールを使用して、サンドボックス外での実行を許可するコマンドを選択的に allowlist に追加できます。
• サンドボックスモードが 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.

その後、新しいスケジュール済みタスクを作成します。

Check my commits from the last 24h and submit a $recent-code-bugfix.