For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション

おすすめ

ワークフロー

できること

リファレンス

API Dashboard
ChatGPT を試す

スケジュール済みタスク

ChatGPT で、スケジュールや対応するアプリのイベントに基づいてタスクを実行

繰り返し行うタスクをスケジュールし、バックグラウンドで実行できます。Web 版とモバイル版の ChatGPT では、 対象プランで、対応するアプリのイベントをきっかけにタスクを実行することもできます。有効なタスク、 一時停止中のタスク、完了したタスク、最近の実行履歴は「 スケジュール済み」で確認できます。 スケジュール済みタスクとスキルを組み合わせると、より複雑な作業にも対応できます。

GPT-5.5 は、すべてのプランの ChatGPT、ChatGPT Work、Codex で、 2026 年 10 月 14 日に提供を終了します。GPT-5.5 を使用するスケジュール済みタスクを確認し、 その日までに利用可能な代替モデルを選択してください。ChatGPT にサインインして Codex を使用している場合は、 gpt-5.5 を gpt-5.6-sol（GPT-5.6 Sol）に置き換えてください。OpenAI API への 影響はありません。詳しくは「GPT-5.5 の提供終了」をご覧ください。

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

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

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

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

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

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 デスクトップアプリのサイドバーにある「 スケジュール済み 」で、 すべてのスケジュール済みタスクとその実行履歴を確認できます。

「 スケジュール済み 」画面は受信トレイとして機能します。報告事項のあるスケジュール済みタスクの実行が ここに表示され、確認が必要な実行には未読マークが付きます。

独立したスケジュール済みタスクは、実行のたびに新しいチャットを開始し、 「 スケジュール済み」に結果を報告します。各実行を独立させたい場合や、 1 つのスケジュール済みタスクを 1 つ以上のプロジェクトで実行したい場合に使用します。 独自の実行間隔が必要な場合は、カスタムスケジュールの設定を使用してください。より高度なスケジュールでは、 RFC 5545 の繰り返しルール（RRULE）を編集します。 たとえば、RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0 のように指定します。

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

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

ChatGPT へのスケジュール済みタスクの作成・更新の依頼

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

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

スキルでも、スケジュール済みタスクを作成・更新できます。たとえば、Pull Request の進行を見守るスキルで、GitHub プラグインを使って PR の状態を確認し、新たなレビューのフィードバックに対応する修正を行うスケジュール済みタスクを設定できます。

チャット内でのタスクのスケジュール設定

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

チャット内のスケジュール済みタスクでは、頻繁に状況を確認するために分単位の実行間隔を設定したり、決まった時刻に確認するために毎日・毎週のスケジュールを設定したりできます。

次のような用途では、チャット内でタスクをスケジュールしてください。

  • 長時間かかる処理を、完了するまで確認
  • 対応するアプリの個々のイベントへの反応ではなく、定期的な状況把握が必要な場合に、接続済みの情報源を一定の間隔で確認
  • 一定の間隔でレビューを繰り返し続けるよう ChatGPT にリマインド
  • PR の状態確認や新たなフィードバックへの対応など、プラグインを使ったスキル主導のワークフローの実行
  • 進行中のリサーチやトリアージのチャットを、コンテキストを失わずに継続

各実行を独立させたい場合や、 報告事項を「 スケジュール済み」に個別の実行として表示したい場合は、独立したスケジュール済みタスクを使用してください。

チャット内でタスクをスケジュールする場合は、繰り返し実行しても使えるプロンプトにしてください。毎回の実行で ChatGPT が行う作業、報告すべき重要事項があるかどうかの判断基準、停止する条件やユーザーに入力を求める条件を記述します。

スケジュール済みタスクのテスト

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

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

スケジュールに従った実行を始めたら、最初の数回の出力を確認し、必要に応じてプロンプトや実行間隔を調整してください。

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

スケジュール済みタスクの Worktree のクリーンアップ

Git リポジトリで Worktree を選択した場合、実行頻度が高いと、時間の経過とともに多くの Worktree が作成されることがあります。不要になったスケジュール済みタスクの実行履歴はアーカイブし、Worktree を残すつもりがない実行はピン留めしないでください。

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

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

これらの制限についてのわかりやすい説明は、 サンドボックスの概要を参照してください。ファイルシステムとネットワークのルールについては、 権限を参照してください。

  • サンドボックスモードが 読み取り専用の場合、 ファイルの変更、ネットワークへのアクセス、コンピューター上のアプリの操作が必要なツール呼び出しは失敗します。 サンドボックスの設定を「ワークスペースへの書き込み」に変更することを検討してください。
  • サンドボックスモードが workspace-write の場合、 ワークスペース外のファイルの変更、ネットワークへのアクセス、コンピューター上のアプリの操作が必要なツール呼び出しは失敗します。 ルールを使用すると、 サンドボックス外での実行を許可するコマンドを個別に指定できます。
  • サンドボックスモードが フルアクセスの場合、バックグラウンドで実行されるスケジュール済みタスクのリスクは高くなります。 ChatGPT が確認を求めずにファイルを変更したり、コマンドを実行したり、ネットワークにアクセスしたりする可能性があるためです。 サンドボックスの設定を「ワークスペースへの書き込み」に変更し、 ルールを使用して、 エージェントがフルアクセスで実行できるコマンドを個別に指定することを検討してください。

管理対象の環境では、管理者が強制適用する要件によって、 これらの動作を制限できます。たとえば、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.