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

おすすめ

ワークフロー

できること

Sites

dot

ChatGPT Space

リファレンス

API ダッシュボード
ChatGPT を試す

スケジュール済みタスク

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

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

ワークスペース管理者の方へ： チームで共有するタスクを定期的に、またはイベントをきっかけに実行する方法や、権限と接続の設定については、チームとチームタスクの設定と管理を参照してください。チームタスクは、チームのサービスアカウントと設定済みのアプリ接続を使ってクラウドで実行されます。

ChatGPT にサインインして利用する Codex では、2026 年 10 月 14 日の太平洋夏時間（PDT）正午（19:00 UTC）に GPT-5.5 の提供が終了します。Codex で GPT-5.5 を使用するスケジュール済みタスクを確認し、ご利用のプランとワークスペースで利用できる場合は gpt-6.1-sol（GPT-6.1 Sol）を選択してください。OpenAI API と、API キーで認証した Codex セッションには影響しません。プランごとの代替モデルについては、GPT-5.5 の提供終了を参照してください。

ChatGPT デスクトップアプリのスケジュール済みタスクは、ローカルプロジェクトを対象に、プロジェクトディレクトリまたは独立した Worktree で実行できます。タスクでローカルファイルを使用する場合は、コンピューターの電源を入れ、アプリを起動したままにしてください。

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

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

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

モデルと推論強度にはデフォルト設定を使用できます。スケジュール済みタスクの動作をより細かく制御したい場合は、どちらも明示的に指定できます。

提供が終了したモデルを使用しているスケジュール済みタスクは、利用可能な代替モデルに変更してください。モデル移行ガイドを参照してください。

スケジュール済みタスクは、デフォルトのサンドボックス設定で無人実行されます。まずはタスクの完了に必要な最小限のアクセス権を設定し、必要な場合にのみネットワークへのアクセスや、より広い範囲のファイルへのアクセスを許可してください。詳しくはサンドボックスの仕組みを参照してください。

スケジュール済みタスクの管理

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 に変更することを検討してください。
  • サンドボックスモードが workspace-write の場合、ワークスペース外のファイルの変更、ネットワークへのアクセス、コンピューター上のアプリの操作を必要とするツール呼び出しは失敗します。ルールを使うと、特定のコマンドに限ってサンドボックス外での実行を許可できます。
  • サンドボックスモードがフルアクセスの場合、ChatGPT が確認を求めずにファイルを変更し、コマンドを実行し、ネットワークにアクセスできるため、バックグラウンドでのスケジュール済みタスクの実行に伴うリスクが高まります。サンドボックス設定を workspace-write に変更し、エージェントがフルアクセスで実行できるコマンドをルールで個別に指定することを検討してください。

管理対象の環境では、管理者が要件を適用してこれらの動作を制限できます。たとえば、approval_policy = "never" を禁止したり、使用できるサンドボックスモードを制限したりできます。管理者が適用する要件（requirements.toml）を参照してください。

組織のポリシーで許可されている場合、スケジュール済みタスクは approval_policy = "never" を使用します。管理者の要件で approval_policy = "never" が禁止されている場合は、選択した権限モードの承認設定が適用されます。

使用例

新しいスキルの自動作成

`~/.codex/sessions` にある過去 1 日分のファイルをすべて確認してください。使うときに問題があったスキルは、より使いやすくなるように更新してください。対象は個人用スキルだけです。リポジトリのスキルは対象外です。

何度も繰り返していて、そのたびに手こずる作業があれば、次回から手早く進められるようにスキルとして保存してください。

無理に更新する必要はありません。更新する理由があるときだけで大丈夫です。

スキルを作成したら知らせてください。

プロジェクトの最新状況の把握

リモートの origin/master または origin/main の最新の状態を確認してください。そのうえで、過去 24 時間に <DIRECTORY> に変更を加えたコミットをもとに、経営陣向けの要約を作成してください。

書式と構成：

- Markdown の書式を活用してください。作業項目ごとの見出しは H1、サブタイトルは斜体にし、必要に応じて水平線を入れてください。
- 冒頭は「<directory> の過去 24 時間の概要です」のような一文で始めてください。
- サブタイトルは「作業項目ごとの変更内容と担当者」としてください。
- コミットを 1 件ずつ並べず、作業項目ごとにまとめてください。各項目の見出しは H1 にしてください。
- 作業項目ごとに、何が変わったのかを平易な言葉で短く説明してください。
- 読みやすくなる場合は、箇条書きや太字を使ってください。
- 担当者ごとに箇条書きにしてもかまいません。その場合は名前を太字にしてください。

内容：

- PR へのリンク（例：[#123](...)）は本文中に入れてください。「PRs:」というラベルは付けないでください。
- コミットハッシュや「主なコミット」のセクションは含めないでください。
- 1 つの作業項目に複数の PR を含めてもかまいませんが、コミットごとの箇条書きは避けてください。

対象範囲：

- 現在の作業ディレクトリ（またはメインのチェックアウト内の対応するディレクトリ）内の変更だけを含めてください。
- 過去 24 時間のコミットだけを対象にしてください。
- 必要に応じて `gh` で PR のタイトルと説明を取得してください。
  PR のレビューやコメントも取得してかまいません。

スケジュール済みタスクとスキルを使った自分のコミットのバグ修正

自分のコミットに起因するバグの修正を試みるスキル $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.
---

# 最近のコード変更に起因するバグの修正

## 概要

現在の作成者が過去 1 週間に加えた変更に起因するバグを見つけ、修正し、可能であれば検証してください。コードがローカルにあることを前提に、現在の作業ディレクトリで作業してください。バグの根本原因が作成者自身の変更にあることを確認してください。

## 手順

### 1) 調査対象となる変更の特定

Git を使って作成者を特定し、その作成者が過去 1 週間に変更したファイルを確認してください。

- `git config user.name` と `user.email` から作成者を特定してください。これらの情報が得られない場合は、環境から現在のユーザー名を取得するか、ユーザーに一度だけ尋ねてください。
- `git log --since=1.week --author=<author>` を使って、最近のコミットと変更されたファイルを一覧にしてください。これらのコミットで変更されたファイルを重点的に調べてください。
- ユーザーのプロンプトが空の場合は、このデフォルトの範囲ですぐに調査を進めてください。

### 2) 最近の変更に起因する具体的な不具合の特定

作成者自身の変更が直接の原因となっている不具合を優先してください。

- ログや CI の出力をローカルで確認できる場合は、最近のテストの失敗、lint エラー、実行時エラーを探してください。
- 具体的な失敗が提示されていない場合は、変更されたファイルに関係する最小限の検証を実行してください。たとえば、テストを 1 件実行する、ファイル単位で lint を実行する、該当する不具合の再現を試みるといった方法があります。
- 根本原因が以前からある無関係な問題ではなく、作成者の変更に直接結び付いていることを確認してください。無関係な失敗しか見つからない場合は、作業を止め、条件に合うバグが見つからなかったことを報告してください。

### 3) 修正の実装

プロジェクトの規約に従い、必要最小限の修正を加えてください。

- 問題の解決に必要なファイルだけを更新してください。
- 余分な防御的チェックを追加したり、無関係なリファクタリングを行ったりしないでください。
- 既存のコードスタイルとテストに沿った変更にしてください。

### 4) 検証

可能であれば、修正を検証してください。

- 対象を絞ったテストや lint、不具合を直接再現するコマンドなど、必要最小限の検証方法を優先してください。
- 検証できない場合は、実行する予定だった検証内容と実行できなかった理由を明記してください。

### 5) 報告

根本原因、修正内容、実施した検証を簡潔にまとめてください。作成者の最近のどの変更が、どのようにバグの原因になったのかを明記してください。

その後、次のプロンプトで新しいスケジュール済みタスクを作成してください。

過去 24 時間の私のコミットを確認し、$recent-code-bugfix を使って修正を提出してください。