AIエージェントのセッションが切れる｜再開までに読む順序

AIエージェントのセッションは、いつ切れてもおかしくありません。クラッシュ・再起動・アップデート・利用量上限のリセット待ちは、どれも作業の途中で起こります。本記事は、セッションが切れても作業が消えない台帳の設計と、再開までに読む順序を、WEBMARKSの運用ルールと公式ドキュメントから整理します（計測日2026-07-28）。

01結論：AIエージェントのセッション継続は、台帳を書き続けて作る

結論は3点です。

1. セッションの生死とプロセスの生死は同じではありません。プロセスが落ちても、ディスクに残った記録が作業の続きを保証します。
2. 台帳は着手時・節目ごと・人間ゲート到達時・完了時の4つのタイミングで更新します。終了時にまとめて書く設計は、クラッシュで記録ごと消えます。
3. 再開時にAIエージェントが最初に読むのは会話の記憶ではなく、台帳とディスク上の実物を突き合わせた結果です。

WEBMARKSはこの設計をタスク台帳（06-todo/配下）で運用しています。設定を書いた事実と動いている事実は別に数えます。中断からの自動復旧に関わる常駐ジョブの稼働はlaunchctlで毎回実測しており、2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちだと把握しています。自動化が止まっていても、台帳という記録そのものは動く設計にしておく必要があります。

セッション継続という言葉が指す範囲を、隣接する3つの仕組みと並べて先に整理します。

（出典: Claude Code公式ドキュメント「Manage sessions」「Checkpointing」）

Claude Code固有の会話復元コマンドの使い方は『Claude Codeのセッション復元｜中断した作業に戻る手順4段』にまとめています。本記事は、その手前にある運用設計、つまり台帳そのものの作り方に絞ります。

もう1つ、識別の話も先に片づけます。WEBMARKSは案件ごとに1つの案件ID（case_id）を振り、台帳のエントリと成果物フォルダ、実行ログを同じIDで結んでいます。IDが揃っていれば、別のセッションが担当を引き継いでも、どのファイルがどの案件の続きかを迷わず判定できます。

02AIエージェントのセッションが途切れる4つの原因｜クラッシュ・再起動・アップデート・レート制限

Anthropicは、エージェントが多くのターンにわたって動作する以上、モデルの判断をある程度信頼できることが前提になると述べています。あわせて、隔離環境での十分なテストと防護策も勧めています（出典: Anthropic公式）。ターン数が増えるほど稼働時間も長くなり、途中で中断する場面も自然に増えます。

途切れる原因は、大きく4つに分かれます。

WEBMARKSは、自動再開パトロールという仕組みを、利用量上限の解除後に台帳の未完了項目を自動で再開する目的で運用してきました。2026-07-28の実測では、この仕組み自体の実行記録ファイルの最終更新が2026-07-13で止まっており、記事執筆時点で15日が経過していました。自動で戻す仕組みそのものが止まっていることに、誰も気づいていませんでした。

03セッションを継続させる台帳の3状態｜進行中・人間ゲート待ち・完了

WEBMARKSの台帳は、案件ごとに3つの状態のいずれかを持ちます。状態名だけを読めば、次に何をすべきかが分かる設計です。

台帳1件のフォーマットは、次の4項目だけです。

## 20260728_AGIメディア記事量産
状態: 進行中
次の一手: AGIM-217の執筆に着手する
人間ゲート: （未到達）
最終更新: 2026-07-28 15:40

項目を4つに絞っているのには理由があります。WEBMARKSの社内規約は、更新規律をこの4項目に明文化しています。項目を増やすほど更新が重くなり、結局書かれなくなるという経験則が背景にあります。次の見出しで、その更新タイミングを扱います。

04台帳はいつ更新すればセッションを止めずに済むか

更新のタイミングは4つです。着手時・節目ごと・人間ゲート到達時・完了時のいずれかで、そのつどディスクへ書きます。

1. 着手時：状態を「進行中」で起票し、次の一手を1〜2行で書く
2. 節目ごと：作業が一段落するたびに、次の一手と最終更新の日時を書き直す
3. 人間ゲート到達時：状態を「人間ゲート待ち」に変え、待っている内容を書く
4. 完了時：状態を「完了」に変え、完了アーカイブへ移す

WEBMARKSの社内規約は「クラッシュは終了処理を待たない」と明文化しています。終了時にまとめて書く設計を採ると、クラッシュが起きた回だけ記録が空白になり、次のセッションが着手点を推測するしかなくなります。

節目の粒度は、「作業を最初からやり直さずに済む単位」が目安です。1つのファイルを書き終えるたびに更新すると細かすぎ、1日の作業が終わるまで待つと粗すぎます。目安は、途中で切れても直前の1ステップを読み直せば再開できる粒度です。

タイミングを守っていても、更新の仕組み自体が止まる例があります。WEBMARKSの自動再開パトロールがまさにこの例です。実行記録ファイルの最終更新は2026-07-13のまま動いておらず、15日間、誰にも気づかれていませんでした（2026-07-28実測）。監視の仕組みは、正常でも異常でも画面に何も表示しないため、定期的に人が実測しない限り気づけません。

05人間ゲートは、セッション継続の設計とどう噛み合うか

人間ゲートは、送信・公開・削除・決済のように、取り消せない操作の手前で人の判断を挟む関門です。台帳の「人間ゲート待ち」という状態は、この関門で止まっていることを次のセッションへ伝える役割を持ちます。

人間ゲートの欄に書く内容は、次の3種類のどれかです。

• 承認待ち：見積もりや原稿など、人が中身を確認して可否を判断するもの
• 送信待ち：メール・チャット・投稿など、送信ボタンを人が押すもの
• 先方回答待ち：クライアントや取引先からの返信を待っているもの

取り消せない操作をどこで止めるかという線引きそのものは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱っています。ここで押さえたいのは、その待ち状態を台帳のどのフィールドに、どう一言で書くかだけです。内容を書かずに状態名だけを書くと、次のセッションは「何を待っているか」を本文から推測するしかなくなります。

06AIエージェントのセッション継続｜再開までに読む順序5段

ここからが本題です。セッションが切れたあと、AIエージェントが最初に何を読むかを5段で固定します。各段に、入力と確認方法を添えます。

1. SessionStartフックが自動で提示する状態を読む

• 入力：セッションの起動そのもの（新規でも再開でも発火する）
• 確認：🔴進行中・🟡人間ゲート待ちの件数が画面に表示されるか

1. 該当案件の台帳エントリを開く

• 入力：案件名またはcase_id
• 確認：状態・次の一手・人間ゲート・最終更新の4項目が読めるか

1. ディスク上の実物と台帳の記述を突き合わせる

• 入力：台帳に書かれた成果物のパス
• 確認：実際にそのファイルが存在し、記述どおりの中身か

1. 前回の人間ゲートに書かれた「何を待っているか」を確認する

• 入力：人間ゲート欄の文言
• 確認：待っている対象が承認・送信・先方回答のどれか分かるか

1. 次の一手を実行し、節目でまた台帳を更新する

• 入力：ステップ2で読んだ次の一手
• 確認：実行後、最終更新の日時が書き換わっているか

この5段は、AIエージェント専用の手順ではありません。人がセッションを引き継ぐときも、同じ順序で台帳を開き、人間ゲートの内容を確認します。自動化の有無にかかわらず、読む順序そのものが運用設計の骨格です。

ステップ1を人手で行うか自動で行うかは、案件の規模で変わります。WEBMARKSは台帳の🔴進行中を検知したら、送信・公開・削除のような人間ゲートの手前までを自動で再開する運用を設計しています。台帳を先に読み、実物と突き合わせてから次の一手へ進むという順序自体は、自動でも手動でも変わりません。

WEBMARKSはSessionStartフックを3本登録しています（.claude/settings.json実測、2026-07-28）。起動時と再開時の両方で発火します。1本目が起動時に読む資料を提示します。2本目が台帳を読んで中断の疑いを提示し、3本目が定期実行の健全性を確認します。

新規起動と再開を区別するsourceフィールドは、Claude Code公式ドキュメントで定義されています（出典: Claude Code公式ドキュメント「Hooks」）。この値を見れば、フック側は今回が新規なのか再開なのかを判定できます。

ステップ3を省略すると何が起きるかは、実際に記録が残っています。2026-07-28、社内のAIエージェントが台帳に残っていた古い「blocked」という状態表記だけを根拠に、姉妹メディアの記事を「1本も公開されていない」と報告しました。実際には本番サイトのsitemap.xmlで数えると251本が公開済みでした。

誤りに気づいたのは、本番URLを実際に取得して数え直したときです。状態表記を読むだけでは足りず、実物との突き合わせが必須である理由がここにあります。

07セッション継続でつまずきやすい3つの落とし穴

1つ目の落とし穴は、この記事に限った話ではありません。WEBMARKSは更新時刻を根拠にした別のフックで、3日間に233回の誤爆を起こした経験があります。詳しい経緯と直し方は『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』にまとめています。セッション継続の設計でも、時刻ではなく明示的な記録を状態の根拠にするという原則は同じです。

3つの落とし穴に共通するのは、「台帳を書いた」という事実と、「次のセッションが読んで使える」という状態を同一視した点です。書いた本人には自明でも、別のセッション(別のAIエージェント)には伝わらないことがあります。

08セッション継続を保つチェックリスト

• 台帳に状態・次の一手・人間ゲート・最終更新の4項目があるか
• 着手時に状態を「進行中」で起票したか
• 節目ごとに次の一手を書き直しているか（終了時にまとめて書いていないか）
• 人間ゲートに到達したら、待っている内容を1行で書いたか
• 完了時に状態を「完了」へ変え、案件を完了アーカイブへ移したか
• 再開時に、台帳の記述をディスク上の実物と突き合わせたか
• 更新時刻(mtime)ではなく、明示的な記録で状態を判定しているか
• 自動復旧・自動再開の仕組みそのものが動いているかを、定期的に実測しているか

09FAQ