Codexの長時間タスク｜中断と再開の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexに大きな修正を頼んだものの、途中で止まったのか、まだ動いているのか分からない。翌日続きを任せようとしても、何が終わっていたか思い出せない。長時間タスクでは、コードを書く力だけでなく、完了の決め方と再開の準備が大切になります。

結論は、長く動かすことを目標にせず、検証できる小さな成果を積み重ねることです。この記事は2026年10月15日に確認したOpenAIの公式資料とXの公開投稿をもとに整理しています。私自身の長時間運用の体験談や性能測定ではありません。途中に出てくるCSV取り込みツールの修正は、手順を説明するための架空の例です。

記事のポイント

• Goalと定期実行を目的で分ける方法
• 完了条件・対象範囲・停止条件の決め方
• 中断後に役立つ進捗メモと確認手順
• 動作時間ではなく検証結果で完了を判断する方法

Codexの長時間タスクの始め方

長い依頼ほど、最初に短く明確な約束を作ると進めやすくなります。何を完成させるか、どこまで変更してよいか、どう確かめるか。この三つをそろえてから実行へ進みましょう。

Goalと定期実行の違い

Goalは、一つの到達点へ向かって複数の手順を進めたいときに考える仕組みです。一方、毎朝同じ情報を確認するような仕事は、繰り返し実行する予定として分けて考えます。長くかかるから定期実行、毎日使うからGoal、という分け方ではありません。たとえば、一つのCSV取り込み機能を修正して動作を確認する仕事と、完成したツールの出力を毎朝確認する仕事では、完了の意味が違います。最初に今回の目的を一つにまとめることが出発点です。

現行の公式案内では、デスクトップアプリ、対話型Codex CLI、IDE拡張で/goalを使う流れが示されています。使っている画面でコマンドや進捗表示を確認し、古い記事にある設定変更を無条件にまねしないでください。Goalについての記事を読むことと、実際にその場でGoalを開始することも別です。目的が曖昧なら、まず計画だけ相談して、何を完成とするかを整えます。機能の全体像から把握したい方は、Codexのできることと使い方の総合ガイドを入口にしてください。

「とにかく良くなるまで続けて」と頼むと、改善候補が増えるほど終わりが遠くなるかもしれません。長時間作業に向くのは、手順が多くても終了を判定できる仕事です。逆に、関係のない修正を大量に並べた依頼や、何を優先するか未定の構想は、先に整理したほうがよいでしょう。長い仕事を丸ごと手放すのではなく、任せる範囲をはっきりさせるための機能として捉えると、使いどころを判断しやすいですね。

• 一つの修正を検証まで進める：到達点を決めたGoalを検討
• 毎朝の情報確認：繰り返し予定として設計
• 複数の無関係な改善：先に優先順位と依頼を分ける
• 今回の目標に含めない作業も明記する

完了条件をテストで決める

長時間タスクの完了条件は、「修正しました」という返答より具体的にします。架空のCSV取り込みツールなら、正常なファイルを読み込める、空のファイルで分かりやすい結果を返す、不正な値で既存データを壊さない、という三つの状態を考えられます。これはすべてのCSV処理に共通する仕様ではなく、説明用の受け入れ条件です。実際にはツールの仕様や利用者の期待に合わせて、変更前に何を確かめるかを決めてください。

「テストを通すだけなら、都合のよいテストに変えられないか」という心配もあります。そこで、既存テストの目的を維持すること、期待値の変更には理由を残すこと、元の問題が再発しない確認を加えることを条件にします。テストが緑になっていても、問題の入力を試していなければ十分とは言えません。修正前の再現方法と修正後の期待する動作を一緒に渡すと、何が改善されたかを後から比べられます。コマンド名はプロジェクトの実際の手順を使い、存在しない検証を実行済みと扱わないようにしましょう。

完了条件には、機能の動作だけでなく、説明すべき残りも含めると役立ちます。変更した場所、実行した確認、実行できなかった確認、利用上の制約が分かれば、次に誰が何を見るべきか判断できます。最初から全機能を証明しようとするより、今回の問題と影響範囲を確かめる条件を置いてください。新しい不具合が見つかったら、無断で目標を広げるのではなく、今回直す必要があるかを切り分けます。長く作業したという事実を、検証の代わりにしないことが大切です。

• 完了条件は、利用者が観察できる動作で書く
• 既存テストの期待値を変えるなら理由を確認する
• 未実行の確認を合格扱いにしない

対象範囲と停止条件を絞る

成果を決めたら、変更してよい範囲と、勝手に進めてはいけない境界を決めます。CSV取り込みの修正を頼んだだけなのに、保存先のデータベースや公開設定まで変わると、確認する負担が増えてしまいます。対象のファイルや機能を示し、依存関係の追加、外部への送信、本番データの操作などは必要性が分かった時点で相談する形にしましょう。細かな作業手順をすべて固定する必要はありませんが、大きな判断を任せるかどうかは明確にしたいところです。

停止条件も、単に「エラーが出たら停止」では広すぎる場合があります。修正対象の不具合を調べる途中で失敗することと、許可していない本番操作が必要になることは違います。説明用には、「ローカルの再現と修正は進める。ただし、本番データの変更、外部送信、新たな契約や課金を伴う操作、対象外機能の大きな変更が必要なら止めて理由を示す」と書けます。これなら、安全な調査まで止めすぎず、利用者の判断が必要な場面を区別できます。

既にある変更をどう扱うかも重要です。作業開始時に差分を確認し、利用者の編集を自分の修正と混ぜて消さないようにします。長く任せるほど周辺の改善も目に入りますが、便利そうだからという理由だけで範囲を広げないことが大切です。共通のルールはCodexのAGENTS.mdによる指示設計へ整理し、今回だけの対象や停止条件は依頼文と計画に残すと管理しやすくなります。狭く始めることは能力を抑えるためではなく、結果を受け取れる形にするための準備です。

• 変更対象：今回の取り込み処理と必要なテスト
• 保護対象：利用者の既存差分と本番データ
• 相談条件：外部送信・課金・範囲外の大きな変更
• 無関係な不具合はメモし、無断で修正対象に加えない

計画を検証の節目で分ける

大きな計画は、時間ではなく、確認できる状態で区切りましょう。「二時間調査する」より、「問題の入力で再現でき、原因の候補と確認方法が分かった」のほうが次へ進む条件が明確です。CSVの例なら、現状と再現、最小の修正、影響範囲の検証、最終確認という節目に分けられます。これは公式の固定段階ではなく、仕事を受け取りやすくするための提案です。各段階が終わったときに何が残るかを決めておくと、途中で中断しても状況をつかめます。

難しい仕事では、計画を文章として保存する方法もあります。現行の公式ベストプラクティスは、長い作業の計画用文書を参照する運用を案内しています。ただし、特定のファイル名を置くだけで作業が自動的に正しくなるわけではありません。どの計画を読み、いつ更新し、どう検証するかを指示する必要があります。設計の仮説が外れたら、最初の計画を守ること自体にこだわらず、理由と次の確認方法を更新しましょう。古い前提を最新の方針と並べたままにしないことが重要です。

「計画を書くだけで時間がかかるのでは」と感じるなら、最初は一画面程度にまとめてよいと思います。目標、対象、次の節目、検証方法、停止条件が読めれば出発できます。複雑になってから必要な情報を足し、関係のない会話を全部移す必要はありません。共通ルールと今回の進捗を分けることで、再開時にも必要な情報を選びやすくなります。計画は作業前の提出物で終わらせず、実際に確かめた結果に合わせて更新するものとして扱ってください。

1. 再現：問題の入力と現状の動作を記録する
2. 修正：対象範囲内で最小の変更を行う
3. 検証：正常・空・不正など決めたケースを確認する
4. 受け取り：最終差分と未確認事項を整理する

進捗メモに確認結果を残す

進捗メモは、作業した気分を共有するためではなく、次の行動を決めるために残します。「実装中」「順調です」だけでは、再開時にどこまで信用してよいか分かりません。対象の機能、確認済みの動作、実行したコマンドや操作、その結果、未確認のこと、次の一手を短く並べましょう。CSVの例なら、「正常入力は確認済み、空入力は未確認、次は空入力の扱いを検証する」と書けば、何を繰り返さず何を進めるか判断できます。

メモの更新は、発言の回数や一定時間だけで決める必要はありません。設計が変わった、原因の候補が消えた、テストが通った、外部の判断待ちになった、といった節目が適しています。Xでも、設計や実装、修正の分岐で情報を整理するという個人の運用例を確認しました。ただし、整理すれば必ず精度が上がるという実測ではありません。この記事では、その考え方を、古い方針と新しい判断を区別するためのメモとして取り入れています。記録の目的をはっきりさせることが大切です。

長い生ログをすべて保存すれば安心、とも限りません。認証情報、個人情報、機密の入力などを進捗文書へ貼り直さず、共有してよい範囲の結果と必要な参照先に絞りましょう。また、過去に合格した結果は、その時点のコードに対する確認です。後から関連ファイルを変えたなら、古い合格を現在の証拠として使わず、必要な確認をやり直します。短くても、いつ、何に対して、何を確認したかが分かるメモなら、会話の長さより再開に役立つものになります。

説明用の進捗メモ

• 現在地：取り込み処理の入力検証を修正した
• 確認済み：正常入力の期待する行数を確認した
• 未確認：空入力と不正値での動作
• 次の一手：空入力の仕様を確認してテストする
• 注意：本番データは操作せず、既存の利用者差分は維持

Codexの長時間タスクの注意点

途中で止まることを失敗と決めつけず、何が起きたかを切り分けます。そのうえで、再開する会話、実際のファイル、外部サービスの状態を確認して、必要なところから進めましょう。

中断と承認待ちを区別する

作業が進んでいないように見えても、原因は一つではありません。処理が実行中なのか、承認や判断を待っているのか、エラーで止まったのか、利用上限に達したのかを、画面の状態と直近の結果から確認します。「続けて」とだけ送る前に、どの操作の直前で止まったかを見ることが重要です。とくに、外部へ送信する処理やデータを書き換える処理は、途中まで成功している可能性があります。止まったと分かっただけで、最初から同じ操作を繰り返さないでください。

公式資料は、Goalを開始してもサンドボックスや承認の方針は広がらず、判断が必要なら停止すると説明しています。長時間の依頼は、必要な操作を何でも許可する契約ではありません。承認待ちなら、求められている対象と影響を確認し、許可しない場合は安全な代替手順を検討します。自動の承認レビューが使える環境でも、すべての確認が不要になるとは限りません。（出典：OpenAI公式Long-running workのGoalと権限の案内）

容量エラーや利用上限の場合も、確認なしに自動再開されると決めつけないほうがよいでしょう。Xには容量のエラーでGoalが止まり、再開しないという個人報告がありましたが、こちらでは同じ環境で再現していません。現在の全利用者に起きる不具合とは扱わず、停止後に状態を見る必要性として受け止めます。エラーの表示、最後に確認できた成果、未完了の工程を記録し、再開可能になった時点で残りを進めます。待ち時間を成果として数えないことも、状況を把握する助けになります。

• Goalを理由に承認や制限を一括解除しない
• 外部操作は、実行済みか分からないまま再送しない
• 停止原因を取得できない場合は未確認と記録する

同じ会話と作業場所で再開

関連する作業は、まず同じ会話で再開するのが分かりやすい方法です。ただし、会話が残っていることと、ファイルや実行環境が以前のままであることは別です。再開前に、作業しているフォルダ、ブランチや変更差分、最後に保存した進捗、実行中の処理を確認しましょう。別の担当者が編集していたり、自分が別の作業へ切り替えていたりすれば、前のメモをそのまま適用できない可能性があります。続きの指示より先に、現在地の一致を確かめることが大切です。

対話型CLIには、保存したセッションを再開するcodex resumeがあります。公式リファレンスでは、--lastは現在の作業ディレクトリを基準に直近の会話を選ぶと説明されています。複数の作業を扱うなら、直近だから正しいと決めず、対象のセッションと作業場所を確認して選んでください。これは会話の再開であり、以前のファイルの状態や外部操作を自動的に元へ戻す命令ではありません。Goalの再開と、CLIのセッション再開、途中のコマンドの再実行を混同しないようにしましょう。

再開時の依頼は、すべてを最初から説明し直すより、最新の進捗メモと実状態を照合してもらう形にできます。「記録を読み、現在の差分と矛盾がないかを確認し、完了済みは繰り返さず未確認の空入力から再開してください」といった依頼です。公開や登録のような外部処理が含まれていれば、実際の登録先を読み取り確認してから残りを進めます。接続が失われる見込みなら事前に区切りを作り、ローカルの作業環境を利用可能な状態に保つことも必要です。端末を閉じれば必ず別の場所で続く、とは考えないでください。

• 会話：元の依頼と最新の判断がある対象か
• 作業場所：フォルダ・ブランチ・既存差分が合うか
• 実状態：実行中や外部で成功済みの処理がないか
• 再開位置：最後の確認済みではなく、次の未確認工程を選ぶ

同じ失敗を繰り返さない

長く動く仕組みでも、同じ失敗を同じ条件で繰り返せば進捗は増えません。エラーが出たときは、修正対象の不具合なのか、環境不足なのか、期待する仕様が決まっていないのかを分けましょう。CSVの空入力の扱いが未定なら、何度コードを変えても正解を判定できません。外部サービスが利用できないなら、ローカルの修正を続けることと、外部での確認を保留することを分けられます。失敗を隠すより、何が足りないかを具体的に残すほうが次につながります。

説明用の運用として、同じ検証が失敗したら、次の試行では仮説か条件を一つ変え、その理由を記録します。入力の読み取り位置が原因なのか、空入力の判定が原因なのかを分け、変更によって何が確かめられるかを先に言葉にする形です。何回で必ず止めるべきかは仕事のリスクや予算によって決めるもので、公式の固定回数ではありません。費用や利用枠が気になる場合は、時間だけでなく、残っている検証と次の一回で得たい情報を見て継続するか判断してください。

仕様の判断や新しい権限が必要になったら、無理に続けるのではなく、止まる理由と選択肢を提示してもらいます。「できません」で終わるのではなく、「正常入力は確認済み、空入力は仕様未確定、データを変更せずここで停止」と分かれば、利用者が判断できます。再開条件が整ったら、その工程から進めればよいのです。長時間タスクの価値は、失敗しないことではなく、失敗を次の検証へつなげられることにあります。費やした時間が惜しくても、根拠のない反復を完成に近づいたことと数えないようにしましょう。

• 失敗した確認と、変えていない条件を記録する
• 次の試行で変える仮説を一つ決める
• 環境待ちと実装の残りを分ける
• 判断が必要なら、完了済みと再開条件を残して相談する

Xの長時間運用例から学ぶ

Xの公開投稿では、Goalの文章を自分で書かずCodexに下書きしてもらう活用が紹介されていました。目標を言葉にする支援として参考になりますが、下書きを作ることと、その範囲や停止条件を承認することは別です。AIが提案した目標に不要な変更が含まれていれば、実行前に絞る必要があります。同じ投稿に別のエージェントへの分担が含まれていても、長い作業なら必ず並列化すべきという根拠にはなりません。今回は単一目標の進行と再開に焦点を当てています。

別の投稿では、長い会話で判断が揺れるという体感や、設計・実装・修正の節目で情報を整理する工夫が述べられていました。一方で、容量エラーによる停止や、利用枠の残りを気にしながら大きな作業を続ける声も確認しました。これらを合わせると、読者が知りたいのは「何時間も動いた」という記録だけでなく、どこまでできたか、止まったら何をするかだと考えられます。ただし、少数の投稿から失敗率、費用、最適な実行時間を推定することはできません。

今回の調査では、投稿者と同じ入力、環境、権限、利用枠を用意して再現したわけではありません。容量エラーの報告も、現在の全体障害や、すべてのGoalが自動再開しない仕様の証明とはしていません。私の経験として書き換えてもいません。仕様の根拠は公式資料、Xは用途と不安の発見、この記事の進捗票は運用の提案として分けて読んでください。他人の長時間成功例を目標にするより、自分の一つの作業で、検証済みの節目から再開できるかを確認するほうが堅実です。

• 目標の下書き支援を、範囲の自動承認と考えない
• 整理の体感を、精度や費用削減の保証に使わない
• 個別の停止報告を、全環境の不具合と断定しない
• 連続動作時間ではなく、自分の確認結果を比べる

Codexの長時間タスクを完了する

最後は、開始時に決めた条件へ戻って完了を判断します。CSVの架空例なら、正常・空・不正の入力で決めた動作になり、既存の機能を壊さず、変更差分と未確認事項が整理されているかを見ます。途中で作った計画の項目がすべて済んでいても、元の問題を確認していなければ完成とは言えません。逆に、目的を達成しているのに関係のない改善を追加し続ける必要もありません。何を満たしたら止めるかを先に決めたことが、この場面で役に立ちます。

完了報告には、変更内容、検証の結果、確認できなかったこと、次に利用者が判断することを短く残してもらいましょう。テスト結果と最終差分の確認は、別々の観点です。修正の後に別の変更を加えた場合は、関連する検証を最後の状態でも確かめます。受け取り方を詳しく整理したい方には、Codexのコードレビューとテストで確認漏れを防ぐ方法も役立ちます。完了表示だけでなく、手元の成果と説明を照合できる形にすることが大切ですね。

今日始めるなら、一つの目的、対象範囲、確認する三つ程度のケース、停止条件を書いて、最初の節目まで進めるところから試してください。ケース数は目安で、仕事に必要な確認を減らす意味ではありません。途中で止まっても、最新のメモと実際の状態を照合して続きへ戻れれば、長時間タスクを管理する土台ができます。Codexに任せる時間を長くするより、何を確かめたかを明確にする。その積み重ねが、大きな仕事をレビュー可能な形で完了へ運ぶための、実践しやすい考え方だと思います。

受け取り前の四つの確認

• 元の目的：求めた動作が実際に確認できたか
• 最終状態：差分と検証結果が同じ状態を指しているか
• 残り：未実行・未確認を合格扱いにしていないか
• 終了：今回の目標に不要な追加作業を続けていないか