AIに仕事を任せるなら『終了処理』が必要だった

Claude Code に、このシリーズの記事制作を続けて任せている。1人での運用で、期間は約10日（2026-08-24〜09-02）。本文を書く、図を組む、ビルドして確認する、といった作業そのものは任せて進められている。

ただ、新しいセッションを始めるたびに、「前回どこまでやったか」の確認から入っていた。

実際、この記事6を新しいセッションで頼んだとき、テーマが記録のどこにも無かった。まず「前の記事は公開済みか」「次に何をする予定だったか」という状態の確認から始まった。作業は止まらなかったが、最初の一手が調べ物になった。

人間が「今日はここまで」「次はここから」を覚えていることを前提にすると、作業をAIに任せても、その管理コストは人間の側に残る。

そこで、セッションを終えるときに、決まった項目を決まった場所へ残す「終了処理」を手順にした。

終了処理を挟んだ次のセッションでは、立ち上がりで「確認に戻る量」が減った。

きっかけ・仮説

記事1で、「AIを増やすと、AIの性能より先に情報共有・情報管理のほうが問題になった」という話を扱った。今回はその続きにあたる。

ただし、ぶつかった問題の向きが違う。記事1で扱ったのは、複数のAI環境の間で「いま何がどこで進んでいるか」が共有されていない、という空間方向の問題だった。今回ぶつかったのは時間方向だ。同じAI環境を使っていても、セッションが切れると前回の文脈が引き継がれない。

人間は、無意識に「今日はここまでやった」「次はあれをやる」を覚えていて、翌日それを口頭で伝えていた。ここはまだAIに任せきれていない部分だ。作業は渡せても、作業の連続性は人間の記憶が支えていた。

そこで立てた仮説はこうだ。セッションを終えるときに「何をやったか・何が残ったか・次に何をするか」を決まった型で決まった場所に残せば、次回は確認から始めなくて済む。人間の記憶への依存を外せる。

言える範囲と言えない範囲も先に切っておく。言えるのは、1人が、約10日、記事制作という限られた作業で見たことだけだ。言えないのは、長期の運用で型が崩れないか、多人数で回るか、他の種類の作業でも同じか、立ち上がりが実際に何分速くなったか。件数や時間は測っていない。

終了処理なし
次回は前回の確認からやり直し

セッションが切れると前回の文脈が残らず、「どこまでやったか」の確認に時間を使う
終了処理あり
次回は続きから着手

終わりに「やったこと・残り・次の一手」を決まった場所へ残すと、次はそこから始められる

やったこと（検証方法）

手順は4つ。

終了処理のタイミングを決める。人間が「今日はここまで」と判断したときに、AIへ終了処理を指示する。AIが自分でセッションの区切りを判断するのではない。
残す項目を固定する。実施した作業・変更したファイル・完了したこと・終わっていないこと・次回最初にやること・重要な判断・ビルド結果と作業ツリーの状態、の7項目にした（下の表）。
置き場所と形式を固定する。新しい管理ファイルを作らせない。すでにある作業状態のファイルと引き継ぎのファイルに、追記・上書きする。
後片付けも終了処理に含める。起動していたローカルの開発サーバーなどを止める。

残す項目	これまで何で埋めていたか
実施した作業	人間の記憶（「今日は結論と図をやった」）
変更したファイル	人間の記憶 / 差分を毎回見直す
完了したこと	人間の記憶
終わっていないこと	人間の記憶（いちばん抜けやすい）
次回最初にやること	人間が翌日に口頭で指示
重要な判断	人間の記憶 / 決定の記録を都度たどる
ビルド結果・作業ツリーの状態	次回セッションで再確認

セッションA・終了処理・セッションBの3段階と、その間の引き継ぎの流れを示した図 — セッションが切れても「やったこと・残っていること・次の一手」を決まった場所へ残すと、次のセッションは確認ではなく続きから始められる、という関係を示した図。実際の画面ではなく、3段階の関係を示すために作成したもの。

なぜ「記録しておいて」と言うだけではだめなのか。指示が曖昧だと、AIは新しいファイルを作って、そこに書きがちだった。管理ファイルが増えると、次回どれを見ればいいのか分からなくなる。これは記事1で扱った「同じ目的のものが複数の場所にある」状態への逆戻りだ。だから、置き場所と形式まで指定した。

測り方について。数値の指標は用意していない。次のセッションの立ち上がりで、「状態の再確認に費やす往復」がどう変わるかを、実感ベースで見た。

起きたこと（検証結果）

終了処理を入れる前は、冒頭に書いたとおりだった。この記事6の依頼では、テーマが記録に無く、最初の一手が「状態の再確認」になった。

終了処理を入れたセッションの次回は、違った。作業状態のファイルに「次回最初にやること」が1行あるだけで、そこから着手できた。前提を揃えるための往復が減った。

残す項目のうち、いちばん抜けやすいのは「終わっていないこと」だった。作業が一段落すると、できたことは報告に残るが、やり残しは口頭で流れてしまう。これを項目として固定したことで、次回の頭に未完了が並ぶようになった。「重要な判断」も、後から決定の記録をたどり直す手間を減らした。

「記録しておいて」とだけ指示したときには、AIが新しいメモ用のファイルを作ろうとした。既存の作業状態のファイルに沿うよう、指示し直した。この違いは下の表のとおり。

指示のしかた	起きること
「記録して」だけ	AIが新しいメモファイルを作る。管理ファイルが増え、次回どれを見ればいいか分からなくなる
置き場所と項目を固定	既存の状態ファイルに追記・上書き。次回は決まった1か所を読めばいい

後片付けについて。開発サーバーの停止も終了処理に含めたら、次回の起動時に起きていた小さな詰まり（ポートの衝突など）が減った。

ただし、終了処理は人間が「ここまで」と言わないと始まらなかった。AIが自律的にセッションを締めたわけではない。

わかったこと

「作業を任せられる」ことと「継続して運用できる」ことは、別だった。1つのセッションの中の作業は任せられても、セッションをまたぐ連続性は、終了処理という型がないと、人間の記憶で埋めることになる。

終了処理は「記録」ではなく「設計」だった。何を・どこに・いつ残すかを固定して、はじめて機能した。項目と置き場所を固定しないと、記録は増えるだけで参照されない。記事5で「保存されていることと、次の制作で自動的に参照されることは別」と書いたが、これと地続きだ。

記事1は「置き場を1つにする」話だった。今回は「その置き場に、セッションの終わりに、決まった形で書く」話だ。置き場があるだけでは足りなかった。

弱いところもある。対象は約10日、記事制作だけ、1人。項目が今の作業に最適化されすぎているかもしれない。終了処理そのものにかかる時間のコストは測っていない。長期で作業状態のファイルが肥大化しないかも、まだ分からない。

実際どうなん？（まとめ）

AIに作業は任せられた。でも「今日はここまで、次はここから」という、人間が無意識にやっていた継続の管理は、終了処理として設計しないと、AIの運用には残らなかった。

セッションの開始（前回の引き継ぎを読む）と終了（次回への引き継ぎを残す）は、セットだった。片方だけでは続かない。