最近、長く使ってきたCodexのタスクを交換した。
削除したのではない。
役割を保ったまま、新しいタスクへ引き継いだ。
前回は、増え続けた履歴をどこまで残し、どこから整理するかを考えた。
Codexのrollout履歴を整理した前回の記録では、消してよい記録と残すべき記録を分け、公式の削除方法とmetadata-onlyの確認手順を整理している。
ただ、容量を整理した後も、日々使う役割taskは単純に削除できなかった。
その中には、仕事の境界、やってはいけないこと、定期実行の戻り先、未処理の依頼、次に再開する位置が残っている。
問題は、会話が長いことではない。
その会話を消した時に、運用まで途切れることだった。
今回は、会話履歴を複製せず、必要な状態だけで後継を作った。
実際に3つの役割taskで試すと、定期実行の配送先、未読handoff、古いACKという別々の見落としが出た。
ここでは、その失敗を含めて、今の自分が使っている交換手順を整理しておく。
会話全文を移しても、引き継ぎにはならない
最初は、古い会話をそのまま新しいタスクへ渡せばよいと思っていた。
でも、それでは現在必要な文脈だけで後継を始める目的と合わない。
長い会話には、採用しなかった案、途中のエラー、古い前提、完了済みの依頼も混ざっている。
全部を複製すると、後継は開始時点から古い前提や完了済みの判断まで持ち込む。
何が現在の正本なのかも分かりにくい。
引き継ぐべきなのは会話そのものではなく、現在も有効な状態だった。
- 何を担当する役割なのか
- どこまで実行してよいのか
- 単独で判断してはいけないことは何か
- 完了済みと未完了はどれか
- 次に行う具体的な1手は何か
- 失敗時に誰が引き取るのか
- どの確認が終わるまで外部操作を始めないのか
Codexには、リポジトリ固有の継続的な指示をAGENTS.mdへ置く仕組みがある。
これはOpenAIの公式機能として案内されている。
一方で、自分が今回使った移行用のmanifest、安定した参照名、handoffの保留箱、直接ACK、独立QAは、自分のローカル運用である。
Codex標準の移行機能ではない。
公式機能と自作運用を混ぜないことも、引き継ぎ資料の一部になった。
後継を作る前に、戻れる場所を固定した
新しいタスクを作る前に、まず古いタスクの状態を監査した。
ここで確認したのは、作れるかどうかではない。
失敗した時に、元へ戻せるかどうかだった。
役割、権限、禁止事項、現在の目的、未完了、次の一手が正本docsだけで説明できるかを確認する。
会話を読み直さないと判断できないものがあれば、その時点では交換しない。
次に、参照先、定期実行、保留中handoff、作業環境、旧taskの状態をmetadata-onlyでsnapshotした。
ここでいうmetadata-onlyは、識別に必要な状態だけを残し、prompt、response、tool出力、transcript、認証情報、データベース本文を複製しないという意味で使っている。
外部操作の途中状態も閉じた。
未保存の編集、送信前の投稿、実行中のdeployが残っている状態では、どちらのタスクが責任を持つのか曖昧になる。
準備監査が通らなければ、後継を作らない。
これを最初の停止条件にした。
地味だけど、ここが大きい。
後継を先に作ると、移行を完了させること自体が目的になってしまう。
定期実行は、存在より配送先を見る
最初の事例で止まったのは、scheduled taskだった。
定期実行が存在し、有効になっている。
同じ設定名も残っている。
それだけを見れば、引き継げているように見える。
でも、確認すべきなのは、その実行結果がどこへ戻るかだった。
OpenAIの公式資料では、scheduled taskには、既存チャットへ戻って文脈を継続する方式と、実行ごとに新しいチャットを作るstandalone方式がある。
これは用途が違う。
長期taskの続きを同じ場所で受け取るつもりなのに、standaloneとして残せば、定期実行そのものは成功しても運用は分断される。
逆に、独立runを前提にしたものを既存チャットへ戻すと、不要な文脈を引き継ぐ。
そこで、各scheduled taskについて次をsnapshotへ追加した。
- 既存チャットへ戻るのか
- 独立runを作るのか
- 誰が結果を受け取るのか
- 現在の配送先はどこか
- 同じ設定が重複していないか
- 切替後も同じ意図になっているか
自分の環境では内部的な種類名も使っているが、それはローカル実装の用語である。
記事では、公式資料にある「チャット内」と「standalone」の違いまでを一般的な説明とし、内部用語は広げないことにした。
ACKは内容と時点がそろって初めて使える
2つ目の事例では、未読のhandoffが残っていた。
タスクの役割は引き継げている。
次の作業も書いてある。
それでも、交換直前に届いた依頼が受領されていなければ、後継は正しい位置から始められない。
3つ目の事例では、ACK自体はあった。
ただし、それは切替前の状態に対するACKだった。
参照先を変更した後に、後継へもう一度pingを送り、後継自身が現在の参照先であることを返す。
このfresh pingがないと、「作成した後継が読めた」と「切替後の依頼が後継へ届く」が混ざる。
今はACKを2段階に分けている。
最初は、必読docs、役割、設定、未完了、外部操作の閉鎖を確認するdirect ACK。
次は、参照先を切り替えた後に、現在の世代、保留依頼、定期実行、待機条件を確認するroute pingだ。
ACK本文を保存することが目的ではない。
どの時点の、何に対する受領なのかを固定するために使っている。
独立QAが、交換を「作業」から「切替」に変えた
自分で準備し、自分で後継を作り、自分で切り替える。
そのまま自分で完了判定すると、準備時の思い込みをもう一度なぞりやすい。
実際、scheduled taskの配送先も、未読handoffも、古いACKも、個々の操作は成功していた。
失敗していたのは、操作同士のつながりだった。
独立QAでは、次を順番に見る。
- 現在の参照先が後継になっているか
- scheduled taskの方式と配送先が契約どおりか
- 保留handoffが欠けたり二重実行されたりしていないか
- 後継が役割、禁止事項、未完了、次の一手を説明できるか
- 旧taskを退役させても戻せるsnapshotがあるか
- 外部操作が移行中に始まっていないか
ここでREWORKが出たら、旧taskを消さない。
参照先を戻せる状態を保ったまま不足だけを直す。
PASS後に、旧taskを退役させる。
削除は最後だ。
削除は、退役確認のあとにだけ行う
codex deleteは、保存済みのinteractive sessionを永久に削除するstable commandとして公式資料に記載されている。
元へ戻すための操作ではない。
そのため、削除コマンドより先に、不可逆であることを確認する。
後継への参照切替、scheduled task、保留handoff、direct ACK、fresh ping、独立QA、旧taskの退役状態がそろってから、対象を1件だけ指定して公式の方法で削除する。
一括削除やローカルデータの直接編集は、この手順に入れない。
削除後は、環境のhealth checkと、管理元から後継へ最後の受領確認を行う。
ここまで通って、ようやく交換完了とした。
3つの事例で、追加したgateが違った
| 匿名事例 | 見つかった差分 | 追加したgate |
|---|---|---|
| 役割task A | scheduled taskは存在したが、結果の戻り先が曖昧だった | チャット内かstandaloneか、期待する受取先までsnapshotする |
| 役割task B | 完了済みと未読のhandoffが混在していた | delivery単位で未処理だけを確認し、二重実行を止める |
| 役割task C | 切替前のACKを切替後の到達確認として扱いかけた | direct ACKとfresh pingを分ける |
automationを持たない役割taskでは、0件であること自体を契約として残した。
移行を機に定期実行を増やさないためだ。
また、3事例の容量変化は合算していない。
同じ時期にCodex全体の履歴や別taskも変動するため、単独のrotationだけで減った容量とは言い切れない。
自分の手順は、この順番に落ち着いた
抽象化すると、現在の流れは次のようになる。
準備監査 → metadata snapshot → 履歴を複製しない後継 → direct ACK → 参照先切替 → fresh ping → 独立QA → 旧task退役・公式delete → health check・管理元受領
大事なのは、矢印の順番を入れ替えないこと。
後継作成前に戻る場所を作る。
切替前に後継の理解を確認する。
切替後に到達を確認する。
独立QAの前に旧taskを消さない。
仕組みそのものより、停止できる地点を残す方が重要だった。
まずは小さい非重要taskで試した方がいい
読者向けに残すなら、確認項目は次の形になる。
- 正本docsだけで役割と禁止事項を説明できるか
- 完了、未完了、次の1手が分かれているか
- 外部操作の途中状態がないか
- 戻せるsnapshotがあるか
- scheduled taskの有無だけでなく、結果の戻り先を確認したか
- 未読handoffと完了済みhandoffを分けたか
- 後継からdirect ACKを受け取ったか
- 切替後にfresh pingが届いたか
- 別の視点で独立QAしたか
- 旧taskの退役後にだけ公式deleteを使うか
- 削除後のhealth checkと管理元受領まで確認するか
いきなり重要な役割taskで試す必要はない。
scheduled taskも外部操作もない、小さい非重要taskから始める方がよいと思う。
自分も、3事例で同じ失敗を繰り返したわけではない。
1件目で配送先、2件目で未読handoff、3件目でACKの鮮度が見えた。
試すたびにgateが増えた。
長期taskの交換は、古い会話を新しい箱へ移す作業ではなかった。
残すべき判断を正本へ置き、現在の状態だけを後継へ渡し、届いたことを別の視点で確認する作業だった。
会話履歴を複製しないから、後継は現在有効な状態から始められる。
でも、古い前提を持ち込まないために継続性を捨てる必要はない。
小さく始め、止まれる場所を先に作る。
今の自分は、この順番で交換している。
今回の長期task移行そのものを解説する本ではありませんが、AIエージェントがツールやAPIを使って仕事を進める仕組みと、信頼性や運用上の課題を整理したい人には、この入門書が前提理解の助けになります。
参考・出典
公式情報は2026年7月20日に確認。