ChatGPT Scheduled Tasks は、「あとで指定した時刻に走るタスク指示」と、現在のアカウントや workspace で許可されている ChatGPT の機能を組み合わせたものとして設計するのが安全です。すべての過去会話、プロジェクトファイル、別チャットの添付、ローカルファイル、GPTs、音声チャット、webhook、外部アカウント上の任意操作を自由に使える自律エージェントではありません。
最初に見る境界は次の四つです。
- 安定して設計できるもの: タスク指示、予定、通知、タスク設定、関連するタスク管理ページまたはチャット。
- 条件が満たされると使える可能性があるもの: Memory、接続済みで許可されたツールやアプリ、監視タスク自身の過去実行結果。
- 前提にしてはいけないもの: すべての過去会話、プロジェクトファイル、別チャットのアップロード、GPTs、音声チャット、ローカルファイル、社内ネットワーク、任意の接続アカウント操作。
- 別ルートにすべきもの: webhook、API cron、ローカルスクリプト、CI、キュー、retry とログが必要な workflow、ファイルシステム処理。
将来の実行時に必ず必要な事実は、タスク指示に直接書きます。Memory は文体や好みを助けることはありますが、顧客ごとの閾値、ファイル内容、法務条件、秘密情報、ローカルパス、毎回厳密に守る指示を入れる隠れたデータベースとして扱うべきではありません。
事実確認の前提: OpenAI Help Center の Tasks in ChatGPT、ChatGPT capabilities、Memory、Projects、Data Controls は 2026-06-30 に確認済みです。プラン、同時に保持できるタスク数、モデル名、ツールやアプリの対応、地域、workspace policy、UI の入口はアカウントや rollout によって変わるため、実運用では必ず現在の画面で確認してください。
速い答え：明示した文脈だけで動くように設計する
安定した定時タスクは、あなたがその場にいなくても理解できる必要があります。タスク指示には、目的、範囲、許可する情報源、出力形式、停止条件、結果を変える重要な事実を入れます。
| 境界 | 安全な設計 | 確認すること |
|---|---|---|
| タスク指示 | 事実、日付、形式、制約、停止条件を書く | 明日この指示だけを読んで実行できるか |
| 予定 | 一回、繰り返し、監視型のどれかを選ぶ | 公式ページでは一時間より短い頻度は不可 |
| Memory | 正確なデータベースではなく個性化として扱う | Memory やチャット履歴参照が有効か |
| プロジェクトファイル | 入力として依存しない | ファイル付きプロジェクトで作ったタスクはそのファイルにアクセスできない |
| ツールとアプリ | 対応、接続、許可済みの能力だけ使う | プラン、地域、接続範囲、管理者ポリシー、review |
| 外部自動化 | 別の owner に渡す | API cron、workflow、CI、キュー、ローカルスクリプト |
最後の列が埋まらないタスクは、まだ無人実行に向いていません。手動で使う ChatGPT prompt としては便利でも、定期実行の workflow としては未完成です。
タスク実行時に使えるコンテキスト
まず見るべきものはタスク指示です。未来の実行が必ず見られるものを、ここで明示します。良い指示は、何を確認するか、どの情報源を使ってよいか、何を無視するか、どの形式で返すか、事実が足りないときにどう止まるかを含みます。
関連チャットやタスクページは、管理上の意味があります。関連チャットを削除するとタスクが一時停止する可能性があるためです。ただし、それは過去のすべての会話が入力として安定して渡るという意味ではありません。関連ページは管理コンテナであり、完全な記憶倉庫ではないと考えます。
監視タスクには少し違う性質があります。前回の実行結果を参照して、条件が満たされたか、前回から何が変わったかを見られる場合があります。これはタスク自身の履歴です。必要な基準値や説明文書の代わりにはなりません。基準が必要なら、タスク指示に書くか、実際に許可された接続元を指定します。
頻度にも境界があります。2026-06-30 時点で、公式ページはタスクが一時間より短い頻度で実行できないと説明しています。分単位の監視、イベント駆動、webhook、queue consumer、確実な retry、失敗ログ、エスカレーションが必要なら、Scheduled Tasks ではなく別の実行基盤を選ぶべきです。
Memory は個性化であり、タスク brief ではない
Memory は便利ですが、読み過ぎると設計を壊します。OpenAI の Memory FAQ は saved memories と chat-history referencing を分けて説明しています。これは将来のチャットの個性化に関係しますが、定時タスクが毎回正確に必要な事実、ファイル、判断、数値を思い出す契約ではありません。
Memory に任せやすいものは、欠けても結論が壊れにくい好みです。
- よく使う文体、単位、表記、要約の長さ。
- 低リスクで長期的に変わりにくい好み。
- 出力を読みやすくするが、正誤を決めない背景。
Memory に任せてはいけないものは、結果を決める事実です。
- 顧客 ID、金額閾値、法務条件、インシデント境界。
- 契約、ポリシー、ファイル要約、基準値。
- secret、token、ローカルパス、private repo、社内 URL。
- 毎回厳密に実行するタスク固有の手順。
実務上は、タスク指示を brief、Memory を薄い好みとして分けます。たとえば、毎週月曜に公開情報から AI 政策更新を簡潔に要約するタスクなら、文体の好みは役立ちます。一方で、特定顧客の利用率が 80% を超えたら知らせるタスクなら、顧客名、閾値、情報源、許可されたツール、データがない場合の動作を明示する必要があります。
プロジェクトファイルとアップロードは安全な入力ではない
ChatGPT Project は持続的な作業場所に見えますが、Scheduled Tasks のファイル境界は狭いです。公式の Tasks in ChatGPT ページは、ファイル付きプロジェクトで作成されたタスクがそのプロジェクトファイルにアクセスできないと説明しています。
したがって、「Project に資料を置いて、毎朝タスクに読ませる」という設計は前提にしないでください。ファイルの内容が必要なら、安定した要約をタスク指示に入れる、実際にサポートされている接続アプリを使う、またはファイルを扱える別の workflow に移します。
別チャットでアップロードしたファイルも同じです。ある会話に添付した PDF、CSV、画像は、すべての将来タスクの背景入力にはなりません。結果に影響するファイルなら、必要部分を指示にまとめるか、許可済み接続元を使うか、ローカルスクリプト、CI、repo agent、workflow platform を選びます。
ローカルファイルや社内ネットワークはさらに明確な停止領域です。Scheduled Tasks は Downloads、未コミットの repo、.env、社内 dashboard、localhost の API を読む手段ではありません。こうした仕事には、ファイル境界とログを持つ実行 owner が必要です。
ツールとアプリには権限チェーンがある
ツールやアプリは、prompt に書けば必ず走るものではありません。安全な見方は、機能がそのアカウントに存在し、アプリが接続され、scope が許可され、workspace policy がブロックせず、必要な review が済んだときだけ使える、というものです。
定期タスクがツールに依存する前に、五つの層を確認します。
| 層 | 確認する質問 | 失敗の形 |
|---|---|---|
| 機能対応 | その tool や app がタスクで使えるか | タスクは走るが一般論しか返せない |
| 接続 | 必要なアプリが接続され scope があるか | アカウントデータを見られない |
| 管理者ポリシー | workspace がコネクタや操作を許可するか | Business や Enterprise の管理設定で止まる |
| ユーザー確認 | メール送信やデータ変更に review が必要か | タスクが準備しても静かに実行できない |
| 出力証明 | 実行後に何を使ったか確認できるか | 正しそうだが情報源が検証できない |
Gmail、Drive、Calendar、Health、Finance、data analysis など、個人情報や外部操作に関わるものは特に慎重に扱います。まずは権限の小さいテストタスクを作り、タスク履歴、通知、アプリ側の結果を確認します。その後で、必要なものだけ本番の予定に入れます。
Scheduled Tasks を使わない方がいい場面
Scheduled Tasks は、繰り返しの ChatGPT output に強い機能です。リマインダー、定例 briefing、軽い監視、公開情報の定期まとめには向いています。一方で、インフラの実行基盤として使うべきではありません。
次のような仕事は別ルートにします。
- 外部システムからの webhook trigger。
- 分単位の polling、queue processing、retry、delivery guarantee。
- ローカルファイル、社内ネットワーク、未コミットの作業ツリーへの直接アクセス。
- repo の編集、テスト実行、コマンド実行、production script。
- custom GPT behavior、GPT 固有の指示、音声チャット workflow。
- 人の review なしに監査可能な外部操作を実行する処理。
この判断は Scheduled Tasks を低く見るものではありません。役割が違うだけです。ChatGPT の定期出力なら Scheduled Tasks、確実な実行とログが必要な処理なら API cron、CI、queue、workflow、local script を選びます。
後日の実行に耐える prompt 配方
未来の実行は退屈なほど明確であるべきです。prompt だけを読んで何をするか分からないなら、隠れた文脈に依存しすぎています。
textタスク目標: 毎 [周期]、[対象] のために [具体的な作業] を行う。 必須コンテキスト: - [推測してはいけない事実 1] - [推測してはいけない事実 2] - ツールやアプリが必要なら、アカウント、source、label、許可範囲を書く。 許可するツール: - [tool/app] は、この ChatGPT アカウントで利用可能かつ許可済みの場合のみ使う。 - 使えない場合は、検証できなかったことを報告し、推測しない。 出力形式: - 最初に結論または状態。 - 次に evidence、変化、例外、不足。 - 最後に next action または「対応不要」。 停止ルール: - project files、他チャットの uploads、local files、webhooks、GPTs、voice chats、未許可の外部操作を想定しない。 - 必須事実がない場合は、不足を報告する。
この形は、週次 digest、会議前 briefing、公開情報の監視、リマインダー、軽い status check に向いています。コード実行、production 変更、ローカル repo 読み取り、複雑な承認フローを隠す場所ではありません。
失敗したら、どの境界が壊れたかを見る
結果が期待と違ったとき、prompt を長くする前に境界を切り分けます。タスク状態、明示文脈、ファイル経路、ツール権限、実行 owner のどれが原因かを見ます。
| 症状 | あり得る境界 | 最初の修正 |
|---|---|---|
| タスクが走らない | タスク状態または関連チャット | 無効化や関連チャット削除を確認 |
| 重要な事実を無視した | prompt に明示されていない | その事実をタスク指示に入れる |
| ファイルを使えない | Project、upload、local file の前提違い | 要約を入れるか file-aware route に移す |
| ツールが動かない | 機能、接続、管理者ポリシー、review | support、connection、scope、履歴を確認 |
| 回答が一般的すぎる | source route が曖昧 | 情報源、期間、証明を指定 |
| 外部実行が必要 | owner が違う | API cron、workflow、CI、local script、repo agent へ |
復盤で最も重要なのは、タスクが実際に何を使ったかです。通知、タスク履歴、アプリ側の結果、関連ページを確認します。情報源を検証できない実行は、成功ではなく未証明と扱います。
本番前の小さな受け入れチェック
定時タスクを仕事に組み込む前に、小さな受け入れチェックを行います。目的は手続きを増やすことではなく、間違った前提を早く見つけることです。
| チェック | 合格基準 |
|---|---|
| prompt が自立している | 目的、入力、出力、停止条件が古い会話なしで分かる |
| 頻度が合っている | 公式の時間境界と通知経路に合う |
| Memory が重要事実を持たない | 重要事実は prompt または許可済み source にある |
| ファイル経路が明確 | Project、別チャット upload、local file を前提にしない |
| 権限チェーンを確認済み | 機能、接続、管理者ポリシー、review、証明を確認 |
| 別 owner が決まっている | webhook、API cron、local script、CI、workflow を無理に入れない |
最初の実行は本番ではなく検収です。タスクに、使った source、検証できなかったこと、必要だった権限を短く報告させます。その結果を見てから、権限や頻度を増やします。
よくある質問
Scheduled Tasks は Memory を使えますか？
Memory が有効で関連していれば、文体や好みに役立つことがあります。ただし、正確な隠れた記憶を前提にしてはいけません。必須の事実は prompt または許可済み source に置きます。
プロジェクトファイルにアクセスできますか？
前提にしないでください。公式の Scheduled Tasks ページは、ファイル付きプロジェクトで作成されたタスクがそのプロジェクトファイルにアクセスできないと説明しています。必要な内容は要約するか、別ルートへ移します。
Gmail、web search、Health、Finance などは使えますか？
対応する capability がアカウントや workspace で利用可能、接続済み、許可済み、ポリシー上許可、必要な review 済みである場合だけです。例があることは、全アカウントで無人実行できる証明ではありません。
webhook は使えますか？
使えません。2026-06-30 に確認した公式ページでは、webhooks are not supported とされています。イベント駆動やリアルタイム連携には、backend scheduler、workflow platform、queue consumer、API cron を使います。
GPTs や音声チャットは対応していますか？
この境界では対応していません。公式ページは GPTs と voice chats が tasks でサポートされないと説明しています。custom GPT behavior や voice workflow が必要なら別ルートです。
タスクが一時停止する理由は何ですか？
関連チャットを削除するとタスクが pause されることがあります。ほかに、タスクの無効化、監視条件の達成、ツールの availability 変更、workspace policy の変更、接続切れも確認します。
API cron の代わりになりますか？
確実な外部実行、retry、logs、local files、コード実行が必要なら代わりになりません。Scheduled Tasks は ChatGPT output の定期化に向き、API cron や workflow は実行基盤に向きます。
最初に試すべき安全なタスクは何ですか？
公開情報一つ、日程一つ、短い出力、私的アプリ操作なしのタスクです。成功後に一つずつ permissioned tool を追加し、そのたびに履歴と source を確認します。