AI Agent の長時間タスクが中断したときの再開方法：チェックポイント、コンテキスト再構築、復旧フロー

AI Agent に長時間タスクを任せるとき、本当に困るのは中断そのものではありません。問題はその直後です。ターミナルが消え、コンテキストがリセットされ、モデルは計画の半分しか覚えておらず、どのファイルが変更済みなのかも曖昧になります。

現実的な対策は、Agent が絶対に失敗しないことを期待するのではなく、最初から再開できる形でタスクを設計することです。

この記事では、AI Agent の長時間タスクが中断したあと、最初からやり直さずにどう復旧するかを扱います。

Quick Answer

AI Agent の長時間タスクを再開可能にするには、実行中ずっと「タスク目標」「チェックポイント一覧」「現在のワークスペース状態」の三つを見える状態にしておきます。中断後はまず git status、変更ファイル、ログ、生成物を確認し、最新チェックポイントからコンテキストを再構築し、未完了の項目だけを Agent に続行させます。

一言でいうと、Agent をチャットの記憶だけに頼らせず、リポジトリとチェックポイントを記憶として使うということです。

長時間タスクが壊れやすい理由

長時間の Agent タスクが止まる理由はだいたい決まっています。

• モデルのコンテキストが長くなりすぎる;
• コマンドがタイムアウトする、またはターミナルセッションが消える;
• 十分な背景なしに新しい会話を開く;
• Agent がすでに触ったファイルを忘れる;
• 生成ファイルとソースファイルが混在する;
• テストが途中で失敗し、次の作業が曖昧になる。

文章作成、コード編集、テスト実行、翻訳生成、複数ディレクトリの処理が絡むほど、このリスクは高くなります。

たとえば Codex Skills で独自ワークフローを作る ようになると、Agent に複数の記事を連続処理させることがあります。途中で止まった場合、どの記事が完了し、どれが未完了なのかをすぐ判断できる必要があります。

最小限の復旧構造

再開可能な Agent タスクには、小さくても明確な構造が必要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Goal:
- 何を完了するのか？

Scope:
- どのディレクトリやファイルを変更してよいのか？

Progress:
- Done
- In progress
- Pending

Verification:
- どのコマンドや確認で完了を判断するのか？

Recovery note:
- 中断した場合、次の Agent はどこから再開するのか？

大きな設計書である必要はありません。チャット内の短いチェックリスト、一時的な Markdown ファイル、タスク専用の SKILL.md でも十分です。

大事なのは、モデルの記憶の外側で状態を再構築できることです。

ステップ 1：まずワークスペースを確認する

中断後、いきなり「続けて」と言うのは危険です。まずリポジトリを確認します。

よく使うコマンドは次のとおりです。

1
2
3

git status --short
git diff --stat
git diff -- path/to/file

生成系のタスクなら、対象ディレクトリも確認します。

1

ls content/post/2026/07/38

コード作業なら、直近のテスト出力、ビルド成果物、中断前に Agent が触れていたファイルも見ます。

このステップの目的は単純です。完了済みの作業と途中の作業を分けることです。

ステップ 2：コンパクトなコンテキストを作り直す

新しい Agent セッションでは、古い会話を丸ごと貼るよりも、短い復旧プロンプトを渡すほうが安定します。

例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

Continue the interrupted task.

Goal:
- Translate posts 36, 37, and 38 into en, zh-tw, ja, and es.

Already completed:
- 36: all target files created.
- 37: all target files created.

Still pending:
- 38: create index.en.md, index.zh-tw.md, index.ja.md, index.es.md.

Rules:
- Preserve source date and slug.
- Skip existing target files.
- Do not commit.

Verification:
- Check target files exist.
- Check date/slug match source.
- Check front matter and code fences are valid.

この程度の情報があれば、Agent は会話全体を読み直さなくても正しい場所から続行できます。

ステップ 3：次の小さな単位から続ける

必要がない限り、長時間タスク全体をやり直さないほうがよいです。次の小さな単位から再開します。

扱いやすい単位は次のようなものです。

• 1 本の記事;
• 1 つの翻訳言語;
• 1 つのテストファイル;
• 1 つのモジュール;
• 1 バッチ分の生成アセット;
• 1 つのコマンドとその検証。

AI コーディングでは特に重要です。Claude Code hooks でテストを自動実行する ように自動テストを組み込む場合も、再開単位が小さいほど、失敗時に原因を特定しやすくなります。

ステップ 4：続ける前に検証する

安全な再開パターンは次の一文に集約できます。

1

Inspect current state, finish only the pending part, then verify before doing anything else.

コンテンツ作業なら、検証項目はたとえば次のようになります。

• ファイルが存在するか;
• front matter の項目;
• slug/date が一致しているか;
• 内部リンク構文;
• Markdown のコードフェンス;
• 明らかな文字化けがないか。

コード作業なら、次のような確認が使えます。

• 対象を絞ったユニットテスト;
• 型チェック;
• lint;
• 小さなビルド;
• git diff レビュー。

Agent は「ファイルがある」ことを「タスクが完了した」ことと同一視すべきではありません。

長時間タスクの前に残しておくもの

長時間タスクを始める前に、次の情報を残しておくと復旧が楽になります。

• 正確な目標;
• 変更してよいパス;
• 変更してはいけないパス;
• バッチ処理の順序;
• 検証コマンド;
• ロールバックまたは復旧ルール。

例：

1
2
3
4
5

Process posts 36, 37, 38 in that order.
Only create missing target language files.
Do not edit existing translated files.
After each post, verify date and slug.
If interrupted, continue from the first post with missing targets.

この短いメモだけで、後の整理にかかる時間をかなり減らせます。

コンテキストが長すぎるとき

長時間タスクは、プロンプトが大きくなりすぎて不安定になることがあります。対策はコンテキストを積極的に圧縮することです。

残すもの：

• 現在の目的;
• 変更済みファイル一覧;
• すでに決めた判断;
• 未完了項目;
• 検証結果。

捨てるもの：

• 繰り返しの議論;
• 解決済みの古い失敗ログ;
• 長すぎるコマンド出力;
• 無関係なファイル内容;
• 採用しなかった仮説や計画。

トークン使用量そのものが問題になる場合も、同じ考え方で整理できます。次の一手に必要な事実だけを残します。関連する症状は Claude Code のトークン急増を調べる でも扱っています。

Skill やワークフローにするタイミング

同じ復旧パターンを何度も使うなら、ワークフロー化する価値があります。

再利用可能なワークフローでは、次のようなルールを定義できます。

• ソースファイルの探し方;
• 完了済みの判断方法;
• スキップすべきもの;
• メタデータの保持方法;
• 検証方法;
• 最終報告に含める内容。

ここでローカル skill が役に立ちます。毎回長いプロンプトを書く代わりに、復旧ルールを一度だけ書いて再利用できます。

ツール間の引き継ぎでも考え方は同じです。Codex が始めたタスクを Claude Code が仕上げる場合、またはその逆の場合も、明示的なチェックポイントが必要です。この方向は Codex と Claude Code のタスク引き継ぎ でも触れています。

そのまま使える再開プロンプト

次のテンプレートはそのまま使えます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

This is a resumed AI Agent task.

Objective:
- ...

Source of truth:
- Repository files and git status are more reliable than prior chat memory.

Allowed changes:
- ...

Already done:
- ...

Pending:
- ...

Rules:
- ...

Verification:
- ...

Please inspect the current workspace first, continue only the pending items, and report exactly what changed.

特に重要なのは source-of-truth の行です。ワークスペースの状態が変わっているのに、Agent が古い記憶を自信満々に使い続けることを防げます。

よくある失敗

復旧時によくある失敗は次のとおりです。

• 状態を書かずに「続けて」とだけ言う;
• すべてを最初からやり直させる;
• git status を見ない;
• 生成ファイルとソース編集を混ぜる;
• 「見た目は終わっている」から検証を省く;
• 復旧中に無関係なファイルまで編集させる。

復旧とは、単に続けることではありません。安全に続けられる大きさまでタスクを絞ることです。

まとめ

AI Agent の長時間タスクが中断しても、それだけで失敗ではありません。外部から復元できる状態がないときに、初めて本当の失敗になります。

長時間タスクでは、目標、チェックポイント一覧、検証ルールを残します。中断後はワークスペースを確認し、コンパクトなコンテキストを作り直し、次の小さな単位から再開し、完了後すぐに検証します。

この習慣ができると、長い Agent 作業はかなり壊れにくくなります。Agent が忘れても、ターミナルが閉じても、会話を開き直しても、タスクにはたどれる道筋が残ります。