AIエージェントのセッション継続｜作業を失わない読む順序5段

「昨日の続きって、どこからでしたっけ」。AIエージェントに仕事を渡していると、この一言が出ます。

セッションは、こちらの都合と関係なく切れます。クラッシュ、OSやアプリの再起動、アップデート、利用量上限のリセット待ち。どれも作業の途中で起こります。切れたこと自体は防ぎようがありません。困るのは、切れたあとに「どこまで進んでいたか」を思い出すところから始めてしまうことです。

この記事は、切れても作業が消えない台帳の作り方と、再開までに読む順序を扱います。素材は、WEBMARKSの運用ルールと公式ドキュメントの記述です（計測日2026-07-28）。

進行役は3人です。若葉さんが言葉の側から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントのセッションが切れると、作業はどこまで消えるんですか？

若葉さん

若葉さんの発言

セッションが落ちると、それまでやってもらったことは全部消えてしまうんでしょうか。

鈴木さん

鈴木さんの発言

消えるのは、机の上に広げていたメモのほうだと思ってください。引き出しにしまった書類は残ります。問題は、どこまでを引き出しにしまってあったか、ですね。

プロセスの生死と、作業の生死は同じではありません。アプリが落ちても、ディスクに書き出された記録はそのまま残ります。残っている記録の細かさが、そのまま「続きから始められる地点」になります。

裏を返すと、記録に書き出していない部分はプロセスと一緒に消えます。頭の中だけで進めた判断、チャットの画面にしか出ていない結論、まだ保存していない下書き。この層が厚いほど、切れたときの損失は大きくなります。

WEBMARKSはこの記録を、タスク台帳（06-todo/配下）として運用しています。案件ごとに1つの案件ID（case_id）を振り、台帳のエントリと成果物フォルダ、実行ログを同じIDで結びます。IDが揃っていれば、別のセッションが担当を引き継いでも、どのファイルがどの案件の続きなのかを迷わず判定できます。

02AIエージェントのセッション継続は、会話の復元と何が違うんですか？

言葉が近いので、隣り合う仕組みと並べて先に整理します。

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

3つは競合しません。会話の復元は手元の続きを取り戻す機能で、台帳は案件の続きを引き渡す記録です。前者は同じエンジンの同じ画面へ戻すもの、後者は別のセッションや別のエンジンへ渡すもの、と分けて考えると混ざりません。

Claude Code固有の会話復元コマンドの操作手順は、中断した作業に会話から戻る手順にまとめています。本記事は、その手前にある運用設計、つまり台帳そのものの作り方に絞ります。

03セッションが切れる原因は、AI活用の現場だと何が多いんですか？

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

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

並べてみると、気づける場所が原因ごとにばらけているのが分かります。人が画面で気づくものと、台帳を数えて初めて分かるものが混ざっています。だから「異常が出たら対応する」という構えでは足りません。

高梨課長

高梨課長の発言

切れる回数そのものを減らす方向で対策する、というのは筋が悪いんでしょうか。

鈴木さん

鈴木さんの発言

減らす努力は無駄になりません。ただ、原因の多くはこちらの手が届かない側で起きます。減らす話と、切れたあとの話は、分けて持っておくほうが楽だと思います。

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

設定を書いた事実と、動いている事実は別に数えます。中断からの自動復旧に関わる常駐ジョブの稼働はlaunchctlで毎回実測しており、2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちでした。監視の仕組みは、正常でも異常でも画面に何も出しません。定期的に人が実測しない限り、止まっていることに気づけない構造です。

04AI社員に渡す台帳は、セッション継続のためにどの項目まで書けば足りるんですか？

WEBMARKSの台帳は、1件あたり4項目です。

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

状態・次の一手・人間ゲート・最終更新。増やしていません。項目を増やすほど更新が重くなり、結局書かれなくなる。社内規約が更新規律をこの4項目に明文化しているのは、その経験則が背景にあります。

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

05台帳はいつ更新すれば、AIエージェントのセッションを止めずに済むんですか？

書き足すタイミングは4つです。

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

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

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

高梨課長

高梨課長の発言

節目ごと、と言われても、どのくらいの間隔が正解なんでしょうか。

鈴木さん

鈴木さんの発言

「ここで切れたら、どこまで戻ってやり直すことになるか」を数えてみてください。やり直しが痛いと感じたら、その手前が節目です。

06人間ゲートは、AIエージェントのセッション継続とどう噛み合うんですか？

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

欄に書く内容は、次の3種類のどれかです。

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

取り消せない操作をどこで止めるかという線引きそのものは、止める操作の分け方で扱っています。ここで押さえたいのは、その待ち状態を台帳のどのフィールドに、どう一言で書くかだけです。

状態名だけを書いて内容欄を空けると、次のセッションは「何を待っているのか」を本文から推し量ることになります。1行で足ります。書いてあるかどうかが分かれ目です。

07セッションが切れたあと、AIエージェントは何から読み直すんですか？

ここからが本題です。読む順序を5段で固定します。

若葉さん

若葉さんの発言

会話の履歴をさかのぼって思い出す、では足りないんでしょうか。

鈴木さん

鈴木さんの発言

履歴は、そのとき何を話したかを教えてくれます。ただ、話したあとにファイルがどうなったかまでは教えてくれません。だから記録から入って、最後に実物を見にいく順番にしています。

1段目は、セッションの起動そのものが入力になります。WEBMARKSはSessionStartフックを3本登録しています（.claude/settings.json実測、2026-07-28）。起動時と再開時の両方で発火します。1本目が起動時に読む資料を提示し、2本目が台帳を読んで中断の疑いを提示し、3本目が定期実行の健全性を確認します。画面に🔴進行中と🟡人間ゲート待ちの件数が出るかどうかが、この段の確認点です。

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

2段目は、案件名またはcase_idで台帳のエントリを開きます。状態・次の一手・人間ゲート・最終更新の4項目が読めれば、この段は通過です。

3段目が、台帳の記述とディスク上の実物を突き合わせる段です。入力は台帳に書かれた成果物のパス、確認は「実際にそのファイルが存在し、記述どおりの中身か」です。ここを飛ばすと何が起きるかは、次の章で扱います。

4段目は、前回の人間ゲート欄に書かれた「何を待っているか」を読みます。承認・送信・先方回答のどれなのかが分かれば十分です。

5段目で次の一手を実行し、節目でまた台帳を書き直します。実行後に最終更新の日時が動いていれば、その次の再開も同じ順序で成立します。

この5段は、AIエージェント専用の手順ではありません。人が引き継ぐときも、同じ順序で台帳を開き、人間ゲートの内容を確認します。1段目を人手で行うか自動で行うかは案件の規模で変わりますが、順序そのものは変わりません。

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

08セッション継続の読む順序を飛ばすと、AI導入の現場では何が起きるんですか？

3段目を省略すると何が起きるかは、実際に記録が残っています。

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

誤りに気づいたのは、本番URLを実際に取得して数え直したときです。状態表記は、書かれた時点の事実しか表しません。書いたあとに現実が動けば、そのぶんだけ台帳は古くなります。

だから3段目は、台帳を疑う段ではありません。台帳と現実のどちらが新しいかを確かめる段です。食い違いが見つかったら、台帳を実物に合わせて直してから次へ進みます。

09セッション継続でのAI社員の運用でつまずきやすい落とし穴は、どの3つですか？

1つ目は、この記事に限った話ではありません。WEBMARKSは更新時刻を根拠にした別のフックで、3日間に233回の誤爆を起こした経験があります。経緯と直し方は、証跡から原因を切り分ける手順にまとめています。時刻ではなく明示的な記録を状態の根拠にする、という原則はセッション継続でも同じです。

3つに共通するのは、「台帳を書いた」という事実と、「次のセッションが読んで使える」という状態を、同じものとして扱った点です。書いた本人には自明でも、別のセッションには伝わらないことがあります。

10生成AIのエンジンを乗り換えても、セッション継続の設計は使い回せるんですか？

持ち出せる部分と、作り直しが要る部分に分かれます。

台帳はテキストファイルです。読む側がどのAIエンジンであっても、内容は解釈できます。案件IDで台帳・成果物・実行ログを結ぶ考え方も、特定のツールに依存しません。読む順序という手順も、人が引き継ぐ場合を含めてそのまま使えます。

一方、SessionStartフックのような自動提示の仕組みは、エンジンごとに実装が異なります。ここだけは、乗り換えるたびに作り直しになります。骨格は共通、自動で読ませる配管は個別、という切り分けです。

11AIエージェントのセッション継続ができているかは、どこで点検するんですか？

自分の現場で回っているかどうかは、次の観点で見ます。台帳を開いて、上から順に確かめてください。

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

最後の観点だけ、性質が違います。ほかは自分の書き方の点検ですが、これは仕組みの生死の点検です。動いている前提で書かれた運用は、仕組みが黙って止まった日から、静かに崩れます。

12よくある質問

13まとめ｜今日やる3つのこと

切れることは防げません。防げるのは、切れたときに思い出す作業が発生することのほうです。台帳の4項目を決め、書き足す4点を固定し、再開の5段を順序どおりにたどる。この3つで、失われる範囲が「書き出していない分」まで縮みます。