なぜスケジュールタスクはリセットされるのか
スタンドアロン実行は意図的に新しいチャットになる
スケジュールタスクのデフォルトの形態は「独立」です。各実行は新しく開始され、保存されたプロンプトに記述された作業を行い、Scheduled（スケジュール済み）に報告します。OpenAI はこれをインボックスのように説明しています。「結果を伴うスケジュールタスクの実行はそこに表示され、未読インジケーターによって実行に注意が必要なタイミングが示されます。」
これは、週次レポート、夜間チェック、月次サマリーなど、冪等（べきとう）な処理にとっては優れた設計です。しかし、仕分けタスクが同じことを繰り返す原因でもあります。ドキュメントには、ある実行の結論を次の実行のために保持しておく場所についての記載はありません。あるのは、タスクではなく人間が読むためのインボックスだけです。
ここで正確に理解しておくことが重要です。なぜなら、多くの人がここで誤った結論を出してしまうからです。ドキュメントに書かれているのは、各スタンドアロン実行が新しいチャットを開始するということだけです。前の実行の結果を引き継ぐことについては何も書かれておらず、タスク自身の作業メモを保持するための実行間ストレージもドキュメントには存在しません。継続性が必要な場合は、自分でそれを手配する必要があります。これこそが、本記事の残りの部分で説明する内容です。
2つのモードは異なる製品であり、デフォルトは「忘却」するモード
もう1つのモードがあり、これが累積的な作業に対する直接的な解決策となります。「スケジュールに従って ChatGPT をそのチャットに戻したい場合は、既存のチャット内でタスクをスケジュールします。スケジュールされたタスクは、毎回新しいプロンプトから開始するのではなく、チャットの既存のコンテキストを使用します。」
ドキュメントでは、どちらをいつ使用すべきかが明示されています。「同じコンテキストを使用し続けるべき」継続的な作業については、チャット内でスケジュールします。「各実行を独立させる必要がある場合、または結果を Scheduled に個別の実行として表示させたい場合」は、スタンドアロンを使用します。チャット内でのユースケースのリストには、「長期実行中の操作が終了するまでチェックする」、「一定のペースでレビューのループを継続するよう ChatGPT に促す」、「コンテキストを失うことなく、進行中の調査や仕分けチャットを継続する」などが含まれています。
プロンプトバーからタスクを作成するとスタンドアロン型になるため、ほとんどの人はこの選択肢を目にすることすらありません。
イベントトリガーは境界を曖昧にするのではなく、より明確にする
8月25日のアップデートにより、「サポートされている Gmail、Slack、または GitHub のイベントが発生したとき」にタスクを実行できるようになりました。役割分担は明確に述べられています。「トリガーはタスクがいつ実行されるかを決定し、保存されたプロンプトは各実行が何を行うかを決定します。」
この文章のどこにも「蓄積」の要素はありません。トリガーが起動し、保存されたプロンプトが実行されるだけです。2つの制約がこれを裏付けています。「1つのタスクで複数のイベントトリガーを使用できますが、イベントトリガーと時間ベースのスケジュールを組み合わせることはできません」および「一致する複数のイベントが短い間隔で到着した場合、ChatGPT はそれらを1つの実行にまとめることがあります」。また、イベントトリガー型のタスクはウェブとモバイルのみに対応しています。「ChatGPT デスクトップアプリ、Codex CLI、または IDE 拡張機能では利用できません。」
つまり、最もリアクティブなバージョンのスケジュールタスクは、最もステートレス（状態を持たない）なものでもあります。これは欠陥ではなく、トリガーという仕組みの本質です。
実行される場所によって、参照できるものが決まる
3つのインターフェース、3つのアクセス範囲。ウェブでは、「ウェブタスクはアップロードされたコンテキストや接続されたツールを使用できますが、コンピューター上のフォルダー内で直接作業することはできません」。デスクトップアプリでは、タスクは「ローカルプロジェクトと連携し、プロジェクトディレクトリまたは隔離されたワークツリーで実行できます」が、これには2つの厳しい条件があります。「スケジュールされたタスクがローカルファイルを必要とする場合は、コンピューターの電源を入れ、アプリを実行したままにしてください」、および「タスクの実行がスケジュールされているときに、選択したプロジェクトがディスク上で引き続き利用可能である必要があります」。CLI と IDE 拡張機能には、スケジュールタスクの管理インターフェース自体が存在しません。
毎朝リポジトリを読み取るタスクと、毎朝インボックスを読み取るタスクは、同じ種類のタスクではなく、失敗の仕方も異なります。
よく試されるアプローチ
先週の結果をプロンプトに貼り付ける。 これは1週間は機能します。しかし、その後プロンプトは変更履歴（チェンジログ）と化し、編集するたびに肥大化し、どの行が指示でどの行がメモなのか誰にも分からなくなります。
チャット内でスケジュールを設定し、一度も整理しない。 適切なモードですが、メンテナンスなしで適用した場合の問題です。実行するたびにスレッドが蓄積され、最終的には「報告事項なし」という20回もの定型的なやり取りの下に、有用な状態が埋もれてしまいます。
実行間隔を短くする。 チャット内タスクは「アクティブなフォローアップループ」のために分単位の間隔をサポートしているため、頻度を継続性の代わりにしようとしがちです。しかし、それは代替にはならず、何もすることがない実行に対して無駄に使用枠を消費するだけです。
プロジェクトがタスクの状態を保持していると仮定する。 プロジェクトは、関連するチャット、ファイル、ソースをまとめておくためのものです。これは「整理」であり、タスクが書き込む場所ではありません。プロジェクトが共有するものと共有しないものについては、「why ChatGPT projects don't share memory」で解説しています。
スケジュールタスクでは累積的な作業はできないと結論付ける。 実際には可能です。そのためのモードは存在し、ドキュメントにも記載されています。足りないのは機能ではなく、読み取り元となる「永続的な場所」です。
解決策：各実行が何を引き継ぐべきかを決定し、読み取り先を用意する
まずはタスクを整理することから始めましょう。モードの選択は重要な決定であり、選択を誤ることが問題の大部分を占めているからです。
各実行が完全に独立している場合（レポート、チェック、サマリーなど）は、スタンドアロンのままにして、Scheduled をインボックスとして活用してください。前回の実行内容を把握する必要がある場合は、チャット内でスケジュールを設定し、プロンプトに関する OpenAI のアドバイスを真剣に受け止めてください。「プロンプトを永続的なものにします。スケジュールされた各実行で ChatGPT が行うべきこと、報告すべき重要なことがあるかどうかの判断基準、および処理を停止するか、ユーザーに入力を求めるタイミングを記述する必要があります。」 この最後の句こそが、多くの人が見落としがちであり、ループが永遠に報告し続けるのを防ぐ鍵となります。
活用すべきもう1つの手段があります。ドキュメントでは、アクション自体をパッケージ化することを推奨しています。「スケジュールされたタスクの保守性を高め、チーム間で共有できるようにするために、スキルを使用してアクションを定義し、ツールとコンテキストを提供します。ワークフローが自動的なツール選択に依存すべきでない場合は、タスクプロンプトで特定のスキルを選択または呼び出します。」スキルは、実行間で手順を安定して保持します。しかし、昨日から何が変わったかという状態を保持するわけではありません。
そこで、モードでもスキルでもカバーできない部分、すなわち「蓄積された状態」が残ります。MemoryLake は、単一のツールの外部に存在するメモリレイヤーです。これにより、新しい実行が開始されたときに、何が新しいかを判断する前に読み取れる情報が存在することになります。セットアップは3つのステップで完了します。
ステップ 1: API キーを作成する
サインインして API キーを作成します。接続するすべてのツールで共通して使用できる1つの認証情報です。
ステップ 2: 最初のメモリをアップロードする
1つの項目につき1つの事実を記述した短いエントリを作成します。定期的なタスクにおいて、有用なエントリとは「これは新しい情報か？」という問いに答えられるようにするものです。
すでに処理された内容。 仕分け済みのイシュー、却下したアラートとその理由、すでに回答済みの顧客からの質問など。これが、4日目の重複報告を防ぐエントリです。
タスクが遵守すべき恒久的な決定事項。 どのラベルが無視を意味するか、どのリポジトリが凍結されているか、誰がどのサービスを担当しているかなど。これらは、プロンプトを編集するたびに貼り付け直す必要があった事実です。
しきい値と定義。 何を緊急とみなし、何をノイズとみなすか。あなたの判断基準がどこかに書き残されていなければ、実行時にそれを適用することはできません。
外部へのポインタ。 ダッシュボード、ランブック、トラッカーなど、タスクがインボックスやフォルダー内からは見つけられない情報です。
ステップ 3: AI とエージェントを接続する
お使いのツールを接続します。MemoryLake は MCP および API 経由でアクセス可能であり、ChatGPT は接続されたツールをサポートしているため、スケジュールされたタスクは実行ごとに同じメモリを参照できます。Codex、Claude Code、Cursor、Cline も同じメモリを読み取ることができるため、タスクが人間が別の場所で完了させる作業の一部である場合に重要となります。
3つの率直な制限事項。これはスケジュールタスクの実行方法自体を変更するものではありません。 スタンドアロン実行は依然として新しいチャットを開き、イベントトリガーはイベントごとに起動します。It is not a replacement for the in-chat mode（真の会話の継続性が必要とされるチャット内モードの代替にはなりません）。そして、メモリはコンテキストであり、強制力ではありません。 毎回必ず真でなければならないルールは、エージェントが従うかどうかわからないメモではなく、失敗時にエラーを出すチェック処理に記述すべきです。
これによって実際に何が変わるか
重複報告がデフォルトではなくなります。 実行時に、報告する前にすでに処理された内容を確認できるようになります。
プロンプトがスクラッチパッド（一時メモ帳）ではなくなります。 指示は指示のままであり、状態はタスクを編集することなく更新できる場所に保存されます。
イベントトリガー型のタスクが実際のワークフローで実用的になります。 プルリクエストのコメントごとに起動するトリガーであっても、チームが先週決定した事項を把握できます。
目的に応じてモードを選択できるようになります。 独立した実行はクリーンな状態を保ち、累積的な実行には永続的なプロンプトと読み取り先が提供されます。
定期的な ChatGPT タスクのベストプラクティス
プロンプトを書く前にモードを選択する。 独立した実行にはスタンドアロン、累積的な作業にはチャット内モードを選択します。ドキュメントにそれぞれの違いが記載されており、デフォルトはスタンドアロンです。
チャット内プロンプトを永続的なものにする。 各実行で行うべきこと、報告する価値があるかどうかの判断基準、および停止するか質問するタイミング。これら3つすべてをプロンプトに含めます。
頻度を状態の代わりにしない。 分単位の間隔はアクティブなフォローアップのためのものであり、継続性を担保するためのものではありません。
イベントトリガーでのバッチ処理を想定する。 一致する複数のイベントが同時に到着した場合、1つの実行に「まとめられる」可能性があるため、単一のアイテムではなくバッチを処理できるようにプロンプトを記述します。
接続チェックリストを完了させる。 Slack の場合、タスクが監視するすべてのチャンネルに @ChatGPT が参加している必要があります。リアクション、編集、削除、ダイレクトメッセージはサポートされていません。GitHub の場合、接続されたアプリがリポジトリへのアクセス権を持っている必要があります。
デバッグ前に管理者の制限を確認する。 管理されたワークスペースでは、アクセスは「イベントトリガーによるスケジュールタスクを許可する」権限によって制御されます。タスクがまったく起動しない場合は、バグではなくポリシーによる制限の可能性があります。
デスクトップタスクのローカル条件に注意する。 マシンが起動しており、アプリが実行中で、プロジェクトがディスク上に存在している必要があります。ワークツリーを使用することで、タスクによる変更が進行中の作業に影響を与えるのを防ぐことができます。
手順はスキルに、状態はメモリに格納する。 これらは異なるものです。その違いについては「why agent skills aren't memory」で解説しています。
結論
重複報告は不具合ではありません。スタンドアロンのスケジュールタスクは「スケジュールされた実行ごとに新しいチャットを開始」し、その独立性は、すべての実行が独立しているべき業務のために用意されたドキュメント通りの機能です。問題が発生するのは、タスクが累積的であるにもかかわらず、モードがそうではない場合です。
OpenAI は同じページで代替案を説明しています。既存のチャット内でスケジュールを設定すると、「スケジュールされたタスクは、毎回新しいプロンプトから開始するのではなく、チャットの既存のコンテキストを使用」します。これに、行うべきこと、報告する価値があるかどうかの判断基準、および停止するタイミングを記述した永続的なプロンプトを組み合わせます。手順はスキルとしてパッケージ化し、実行間で安定させます。そして、最も新しく、最もステートレスな形態であるイベントトリガー型のタスクについては、トリガーと保存されたプロンプトの組み合わせこそが、その仕組み自体が提供する継続性のすべてであることを受け入れる必要があります。
残されたのは状態です。何が処理されたか、何が緊急とみなされるか、チームがすでに決定したことは何か。これらをタスクプロンプトの外部、つまり新しい実行が読み取れるレイヤーに保持することで、4回目の実行が2回目の実行を繰り返すことはなくなります。構造上、実行がステートレスであるエージェントにこの議論を適用した一般的な内容は、「why OpenClaw forgets previous runs」および「memory for stateless MCP servers」で解説しています。