AIエージェントを一晩放置する前に決めること｜止め方・上限・ログ・作業範囲の安全設計

一晩走らせる前に、作業フォルダを退避する

長時間のAIエージェント実行では、想定外の生成物、ログ、upload更新、未追跡ファイルが増えることがあります。開始前に作業フォルダを外付けSSDなどへコピーしておくと、朝の差分確認で迷ったときに実行前の状態へ戻りやすくなります。

DeepSeekのピーク時間を避ける前に、夜間実行の停止条件を決める

公式Pricingのピーク枠は日本時間10:00-13:00 JST / 15:00-19:00 JSTです。ただし夜間へ移すだけでは、失敗リトライを朝まで回す危険が残ります。DeepSeek公式Pricingを2026年8月14日に確認しました。DeepSeek公式Pricingで案内された新料金の適用開始日時は2026年8月16日16:00 UTC（日本時間2026年8月17日1:00）です。最新状態は利用前に公式Pricingを確認してください。

一晩の作業は、同じcheckoutで走らせない選択肢もある

Worktreeは、ローカルcheckoutとは別の作業コピーを作り、複数のbranchを並行して扱いやすくします。foregroundの作業を残したままbackgroundのchatやScheduled Taskを進められるのが利点です。ただし、作業コピーが分かれても、AIが触ってよい範囲、秘密情報、外部通信、公開条件、停止条件まで自動で安全になるわけではありません。

Worktreeを使う前の停止条件

• Worktreeをbackupの代わりに扱わず、開始前にrepo、素材、upload、未追跡ファイルの退避を確認する。
• current branchに未commit変更がある状態で開始する場合は、対象と所有者を先に記録し、別taskの変更を混ぜない。
• detached HEADやbranchの状態を確認し、worktree側の完了報告だけでcommit、merge、pushを確定しない。
• Scheduled Taskのbackground worktreeも、通常の作業と同じくsecret、外部通信、権限、最大時間、最大変更量を確認する。
• Handoff後は作業ディレクトリが変わった前提で、AGENTS.md、設定、依存関係、生成先、実行したcheckを再確認する。
• 同じbranchをLocalとWorktreeで同時にcheckoutできないため、branchの所有場所と戻す手順を決めておく。

Worktreeの保存・削除・復元をbackupと分ける

Handoffと`.worktreeinclude`の適用範囲を確認する

• HandoffはLocalとWorktreeの間でchatとcodeを移し、同じchatを後でworktreeへ戻すと関連付けられたworktreeへ戻す。移動後はpath、branch、diff、生成物、testを再確認する。
• `.gitignore`に入ったfileはHandoffだけでは移らず、local managed worktreeへコピーするにはrepo rootの`.worktreeinclude`で対象patternを指定する。tracked fileは列挙しない。
• `.worktreeinclude`でコピーされるのは一致したignored fileだけで、source symlinkはskipされ、new checkoutに既にあるfileは上書きされない。`.env`やsecret設定を含める時は、値の共有先とアクセス権を先に確認する。
• この`.worktreeinclude`の挙動はlocal ChatGPT desktop appのmanaged worktree向けで、Remote worktreeやCLIで自分が作るGit worktreeへ同じ挙動を推測しない。
• branchをworktreeで作成した後は同じbranchをlocal checkoutで同時にcheckoutできない。localで確認したい時は同じbranchを重ねてcheckoutせず、Handoffまたは別branchを選ぶ。

Subagentsはまず読み取り中心の仕事へ分ける

メインの会話を汚さないために、探索、テスト結果の分類、ログの要約、候補比較のようなread-heavyな作業を分けるのが向いています。同じファイルや同じbranchへ複数agentが同時に書き込むと、競合と調整負荷が増えるため、write-heavyな並列化は担当ファイル、所有者、統合方法を先に決めます。

Subagentsを一晩実行へ組み込む前の停止条件

• 最初はread-heavyな探索や検証へ限定し、同じファイルを複数agentへ同時に編集させない。
• 各subagentに作業範囲、禁止事項、期待する要約、親が待つ条件、停止条件を渡す。
• subagentが親のsandbox・permissionを継承することを確認し、childをapprovalやnetworkの回避策にしない。
• non-interactive実行でfresh approvalが必要になったら、失敗を無限retryせず、親で判断するか停止して報告する。
• custom agentのTOMLとdeveloper_instructionsをレビューせず、知らないrepoや設定をそのまま読み込まない。
• 並列数を増やすほどtoken、実行時間、結果の確認量が増えるため、上限を決めて全subagentの報告をdiff、test、build、生成物と照合する。
• subagentの完了報告をcommit、push、deploy、本番反映の承認とは扱わず、公開前の人間レビューを残す。

Goal modeの入力と停止・再開を完了条件に結び付ける

停止・再開するgoalの確認順

• 開始前にoutcome、constraints、verification、definition of doneを測定可能な形で書き、`/plan`が必要な曖昧さを残さない。
• pause、接続断、アプリ再開の後は、同じchatか、goal status、project / host / path、branch、git status、diffを確認してから続ける。これは作業状態を取り違えないための運用確認であり、公式のpause操作だけで完了を保証するものではない。
• side chatはstatusや説明の確認に使い、メインgoalへ意図しない編集指示を送らない。
• parallel chatは独立した対象に限定し、同じfile、同じgenerated output、同じconnected sourceを同時に書き換えない。
• Goalの進捗表示や継続状態は、commit、push、deploy、test成功、release準備完了の証明ではない。差分、check結果、未完了scopeを別にレビューする。
• sandbox、approval、MCP、network、secretの境界はgoalの再開で変わらない。外部影響のある操作は通常の承認と人間レビューを分けて確認する。