スケジュール済みタスク

繰り返し実行するタスクをスケジュールし、バックグラウンドで実行できます。ウェブ版およびモバイル版 ChatGPT では、 対象プランで、対応しているアプリのイベントからタスクを実行することもできます。Scheduled で、実行中、 一時停止中、完了済みのタスクと最近の実行を確認できます。スケジュールされた タスクをスキルと組み合わせて、より複雑な作業を行うこともできます。

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

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

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

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

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

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

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

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

アプリのイベントからタスクをトリガーする

対象プランでは、対応している Gmail、Slack、GitHub のイベントが発生したときに、スケジュールされたタスクを 実行できます。イベントをトリガーとするタスクは、ウェブ版およびモバイル版 ChatGPT で利用できます。 ChatGPT desktop app、Codex CLI、IDE extension では利用できません。

ChatGPT にタスクの作成を依頼し、監視するイベントと、そのイベントが 発生したときに行うことを説明します。トリガーはタスクを実行するタイミングを決定し、保存された プロンプトは各実行の処理内容を決定します。1 つのタスクで複数のイベントトリガーを使用できますが、 イベントトリガーと時間ベースのスケジュールを組み合わせることはできません。

サポートされているイベントトリガーは次のとおりです。

• Gmail: 新しい受信メッセージ。必要に応じて送信者または件名で絞り込めます。
• Slack: 選択したチャンネルの新しいメッセージ。必要に応じて投稿者や スレッドへの返信を含めるかどうかで絞り込めます。リアクション、編集、削除、 ダイレクトメッセージには対応していません。
• GitHub: リポジトリ内のプルリクエストに関するアクティビティ。プルリクエスト、 作成者、タイトル、ラベルで絞り込み、レビュー、コメント、コミットの更新、 またはマージのみのうち、どれをタスクのトリガーにするかを選択できます。

タスクを作成する前に、アプリを接続して認証してください。Slack では、タスクが監視する すべてのチャンネルに @ChatGPT を追加します。GitHub では、接続したアプリに 対象リポジトリへのアクセス権が必要です。

条件に一致する複数のイベントが短時間に届いた場合、ChatGPT はそれらを 1 回の 実行にまとめることがあります。保留中のイベントを確認するには Scheduled を開き、 処理するには Run now を選択します。

利用可否は、プランとワークスペースの設定によって異なります。管理対象の ワークスペースでは、管理者が Allow event-triggered scheduled tasks 権限を使用してアクセスを制御できます。

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

プロジェクトを対象とするスケジュール済みタスクでは、マシンの電源を入れ、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 で、すべてのスケジュール済みタスクとその実行を確認できます。

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

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

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

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

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

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

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

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

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

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

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

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

• 長時間実行される処理が完了するまで確認する
• サポート対象アプリの 1 件のイベントへの応答ではなく、定期的な スナップショットが必要な場合に、接続済みソースを一定間隔で確認する
• 一定間隔でレビューループを続けるよう ChatGPT に通知する
• PR のステータス確認や新しいフィードバックへの対応など、plugins を使用するスキル駆動の ワークフローを実行する
• コンテキストを失わずに、進行中の調査またはトリアージのチャットを続ける

各実行を独立させる場合や、結果を 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.