Codexの長い作業を再開する前に決めること

3行まとめ

Goal

目的。

State

現在地。

Evidence

根拠。

Next

次手。

長い作業の再開では、全文より現在地と根拠を短く渡します。

• 長いCodex作業を再開する時は、会話全文ではなく、目的、現在地、根拠、次の一手をresume packetへまとめます。
• 完了済み、途中、blocked、unknownを分けると、古い前提を引きずりにくくなります。
• 再開前には、変更済みfile、実行済みcommand、公開済みURL、未検証、外部状態を確認します。

Codexで長い作業を進めていると、途中で文脈が長くなります。調査、実装、検証、公開、レビュー、失敗、修正。全部の会話を読み返せば分かるはずですが、再開時にそれを毎回やるのは重いです。

そこで必要になるのがresume packetです。これは会話の要約ではありません。作業を再開するための現在地メモです。目的は何か。何が終わったか。何が未完了か。どの根拠で完了と言えるか。どのfileを触ったか。どのcommandを通したか。次に何をすべきか。

この記事では、2026年6月1日時点のOpenAI公式Codex Use Cases、Codex app features、Goals、Worktrees、AGENTS.md docsをもとに、長いCodex作業を再開する前のresume packetを扱います。Goalそのものの運用は、公開済み記事のCodexでGoalを立てる前に決めることで扱っています。ここでは、再開直前に渡す短い作業状態に絞ります。

この記事でわかること

Done

完了。

Open

未完。

Files

差分。

Checks

検証。

resume packetは、会話の要約ではなく作業状態の索引です。

• resume packetと通常の要約の違い
• 目的と完了条件を再開時に固定する方法
• done、in progress、blocked、unknownの分け方
• evidence、assumption、missingを混ぜない考え方
• 変更済みfile、command、外部状態の見方
• Codexへ渡すresume packetの形式
• 再開前reviewで見る stale、contradiction、risk

resume packetは、長期記憶ではありません。次の作業者や次のCodexが、10分で安全に再開するための短い索引です。

前提知識

項目	内容	見方
Use Cases		長い作業。
Goals		目的。
Features		thread。
Worktrees		状態。
AGENTS.md		報告型。

再開時は、目的、作業場所、検証結果を分けて確認します。

Codexは、thread、project、worktree、local environments、automations、goalsなどを使いながら長い作業を進められます。一方で、長い作業では、会話の途中に古い前提や一時的な仮説が残りやすくなります。

OpenAI公式のCodex docsでは、AGENTS.mdで作業契約を伝えることや、Worktreesで作業を分離すること、GoalsやAutomationsで長い作業を進める考え方が説明されています。resume packetは、これらの機能を使う時に、再開直後の判断を安定させるための補助です。

goalとresume packetの違い

goalは、最終的に達成したい目的です。resume packetは、今どこにいるかを示す作業状態です。

goalだけでは、次に何をすべきか分かりません。resume packetには、完了済み、未完了、根拠、未検証、次の一手を入れます。

永続メモリとの違い

永続メモリは、セッションをまたいで残す長期情報です。resume packetは、ある作業の再開に必要な短期情報です。

全部を永続メモリへ入れると、古い判断や一時的な仮説が残ります。resume packetは、節目ごとに作り直すほうが安全です。

目的と完了条件を固定する

項目	内容	見方
Objective		目的。
Done		完了条件。
Scope		範囲。
Out		対象外。

完了条件が曖昧なまま再開すると、作業が広がります。

再開時に最初に見るのは、目的と完了条件です。会話が長いほど、途中で目的が広がりやすいからです。

Codexには、目的、完了条件、対象外を明示します。

objective

objectiveは、作業の目的です。できるだけ一文にします。

例: 「公開済み記事を100本にし、各記事に3回のレビュー証跡を残す」。

目的が複数ある場合は、優先順位を付けます。

done definition

done definitionは、何をもって完了とするかです。file作成、test pass、public URL、QA結果、review証跡、台帳更新など、確認できる形にします。

「だいたい終わった」は完了条件ではありません。

out of scope

out of scopeも書きます。今回やらないrefactor、別記事、別PR、未来の改善を明示します。

対象外がないと、再開後に作業が広がります。

現在地を4分類に分ける

項目	内容	見方
Done		済み。
Active		途中。
Blocked		停止。
Unknown		不明。

現在地は、進んだことと分からないことを同じ表へ置きます。

現在地は、done、in progress、blocked、unknownに分けます。

この4分類にすると、「終わったつもり」「まだ確認していない」「止まっている理由」が混ざりにくくなります。

done

doneは、根拠付きで完了したものです。作ったfile、通したcommand、公開したURL、確認済みの結果を入れます。

doneには、証拠を添えます。口頭の記憶ではなく、command output、public HTML、test result、review logなどです。

in progress

in progressは、途中のものです。作成中のfile、未公開の記事、通っていないvalidator、まだ確認していない外部状態などです。

途中の作業は、次に何が必要かを明記します。

blocked

blockedは、外部入力や権限がないと進めないものです。

ただし、単に難しいだけのものをblockedにしません。何が必要で、誰の入力待ちかを書きます。

unknown

unknownは、不明なことです。確認していない事実、古い可能性がある情報、外部状態が変わったかもしれないものを入れます。

unknownを残すと、Codexが勝手に事実として扱いにくくなります。

根拠と未検証を分ける

Evidence

確認済み。

Assume

仮定。

Missing

不足。

Risk

注意。

再開時の誤りは、仮定を事実として扱う時に起きます。

resume packetでは、evidence、assumption、missingを分けます。

長い作業で危ないのは、仮定がいつの間にか事実になることです。

evidence

evidenceは、確認済みの根拠です。command output、test result、public page、API response、file content、review noteなどです。

evidenceは短く書きます。長いlog全文ではなく、何が証明されたかを残します。

assumption

assumptionは、仮定です。推測、前回の会話での判断、まだ確認していない外部状態です。

assumptionは便利ですが、再開時には再確認候補にします。

missing

missingは、足りない情報です。未実行test、未確認URL、未更新台帳、未作成artifactなどです。

missingがあるなら、次の一手に入れるか、対象外にします。

変更済みfileと外部状態を並べる

項目	内容	見方
Files		変更。
Commands		実行。
URLs		外部。
Dirty		未整理。

file差分と外部状態は、別々に確認します。

再開前には、変更済みfileと外部状態を並べます。手元のworktreeだけでは、作業状態は分かりません。公開済みURL、外部API、WordPress、GitHub、CIなどの状態も関係します。

files

filesには、変更した主なfileを入れます。本文、構成、ビジュアルJSON、監査、台帳などです。

ただし、全fileを長く並べるより、作業判断に必要なfileへ絞ります。

commands

commandsには、実行済みの確認を入れます。validator、test、QA、publish dry-run、public checkなどです。

command名だけでなく、結果も入れます。OKなのか、失敗して直したのか、未実行なのかを分けます。

external state

external stateには、公開URL、post ID、media ID、CI status、PR URL、issue statusなどを入れます。

外部状態は変わる可能性があります。再開時には、必要なものだけ再確認します。

worktreeの汚れを見る

再開前に、worktreeが汚れているかを確認します。自分が触った変更なのか、ユーザーや別の実行が触った変更なのかを分けます。

勝手に戻さず、必要なら現在のfileを読んでから進めます。

次の一手だけを決める

1. 1Read

   確認。

2. 2Edit

   修正。

3. 3Run

   検証。

4. 4Report

   共有。

resume packetには、最初にやる1手を明記します。

resume packetには、次の一手を入れます。全部の計画を長く書くより、再開直後に何をするかが大事です。

next command

次に実行するcommandがあるなら、具体的に書きます。validator、test、QA、status確認などです。

コマンドは、working directoryや対象fileも分かる形にします。

next edit

次に編集するfileがあるなら、目的を添えます。

「本文を直す」ではなく、「visual validatorで落ちたcaptionを修正する」のように書きます。

next check

次に確認する外部状態があるなら、URLやAPIを入れます。

公開済みか、noindexがないか、featured imageが出ているか、CIが通っているかなどです。

外部状態は、resume packetを書いた時点では正しくても、再開時には変わっていることがあります。公開ページ、WordPress post、GitHub issue、CI、package version、API responseのようなものは、必要な範囲だけ再確認します。

再確認した結果が変わっていたら、packetを上書きせず「再開時にこう変わっていた」と追記します。古い記録を消すと、なぜ判断が変わったのか分かりにくくなるためです。

Codexに渡すresume packet

項目	内容	見方
Goal		目的。
State		現状。
Evidence		根拠。
Next		次。
Stop		停止。

再開用の入力は、長さより参照しやすさを優先します。

Codexへ渡すresume packetは、短い見出しで固定します。

おすすめは、Goal、Current state、Done, In progress, Evidence, Missing, Next step, Stop conditionsです。

format

形式を固定すると、再開する側が読みやすくなります。

Goal:
Current state:
Done:
In progress:
Evidence:
Missing:
Next step:
Do not:

これだけでも、再開直後の迷いが減ります。

length

resume packetは長くしすぎません。長い全文ログは別artifactへ置き、packetには要点だけを入れます。

目安は、次の作業者が数分で読める長さです。

handoff note

handoff noteには、注意点を入れます。古い情報、触ってはいけないfile、未検証、外部状態、ユーザー指示などです。

「これは推測」「これは未確認」「これは最新状態で再確認」と明記します。

reviewで見る観点

項目	内容	見方
Stale		古い。
Conflict		矛盾。
Risk		危険。
Proof		証拠。

再開前に、古い前提と矛盾を探します。

resume packetは、作って終わりではありません。再開前にreviewします。

見るのは、stale、contradiction、risk、proofです。

stale

staleは、古くなった情報です。日時、version、URL、issue status、public page、CI resultなどは変わる可能性があります。

再開時には、古くなりやすい情報を先に確認します。

contradiction

contradictionは、矛盾です。doneに入っているのにmissingにもある、公開済みと書いてあるのにURLがない、test OKとあるのにlogがない、といった状態です。

矛盾がある場合は、作業前に解消します。

risk

riskは、再開時に事故りやすい点です。未検証の公開、外部状態、secret、ユーザー変更、破壊的command、長い未確認差分などです。

Codexには、riskを先に読むように渡します。

よくある失敗

Too long

長すぎ。

No proof

根拠なし。

Old state

古い。

Wide next

広すぎ。

引き継ぎが長すぎるほど、重要な次の一手が埋もれます。

よくある失敗は、会話全文をそのまま渡す、根拠なしに完了扱いする、古い外部状態を信じる、次の一手が広すぎる、未検証を隠すことです。

会話全文は、情報量が多すぎます。根拠なしの完了扱いは、後で戻ります。外部状態は変わります。次の一手が広すぎると、再開直後に迷います。

未検証は、悪いことではありません。隠すことが危険です。

要約を上手く書きすぎる

resume packetは、文章のうまさより正確さです。読みやすいが根拠がない要約は、再開時の事故になります。

完了条件を途中で変える

長い作業では、途中で完了条件を緩めたくなります。しかし、最初の目的が残っているなら、勝手に狭めません。

目的が変わるなら、ユーザー確認や明示的な記録が必要です。

FAQ

項目	内容	見方
毎回?		長い時。
誰が?		作業者。
保存?		必要分。
更新?		節目で。

迷ったら、次の人が10分で再開できるかを見ます。

毎回resume packetを作るべきですか？

短い作業では不要です。複数日にまたがる作業、公開や外部状態を含む作業、複数fileを触る作業では有効です。

誰が作りますか？

作業を中断する側が作るのが理想です。ただし、再開する側が現状を確認して作り直しても構いません。

永続メモリに保存すべきですか？

長期的に残すべき情報だけ保存します。作業途中の一時判断や古い仮説は、resume packetとして残し、必要がなくなったら更新します。

どれくらい短くすべきですか？

次の人が10分以内に再開できる長さです。詳細ログや長い調査は別artifactへ逃がします。

Codexに何を禁止しておくべきですか？

未確認の外部状態を事実扱いしない、ユーザー変更を戻さない、破壊的commandを実行しない、完了条件を勝手に狭めない、などです。

参照した主な情報源

• Codex Use Cases – OpenAI Developers
• Codex app features – OpenAI Developers
• Worktrees – Codex app – OpenAI Developers
• Codex app automations – OpenAI Developers
• Custom instructions with AGENTS.md – Codex – OpenAI Developers

次に読むなら

更新履歴

1. 2026.06.01

   初版。

CodexのGoalやthread周辺の機能は、導入時に公式docsで見直します。

• 2026年6月1日: OpenAI公式Codex Use Cases、Codex app features、Worktrees、Automations、AGENTS.md docsを確認し、初版を作成しました。