スケジュール済みタスク

2026年10月14日正午（PDT、19:00 UTC）をもって、ChatGPTでサインインする CodexではGPT-5.5の提供を終了します。CodexでGPT-5.5を使用するスケジュール済みタスクを確認し、お使いのプランとワークスペースでアクセスできる場合は、gpt-6.1-sol（GPT-6.1 Sol）を選択してください。 OpenAI APIおよびAPI keyで認証されたCodexセッションには影響ありません。プラン別の代替モデルについては、 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 デスクトップアプリのサイドバーにある 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 のステータス確認や新しいフィードバックへの対応など、プラグインを使用するスキル駆動のワークフローを実行する
• コンテキストを失わずに、進行中の調査またはトリアージのチャットを続ける

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

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

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

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

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

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

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

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

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

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

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

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

• サンドボックスモードが 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.

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

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