AIセッションの引き継ぎを信用せず、着手前に実システムを読み戻す

複数セッションの AI エージェントに永続メモリと引き継ぎファイルを持たせて運用すると、 **「もう終わっている作業を、終わっていないことになっている文書のせいで作り直す」**事故が起きる。 この巻物は、その検知と再発防止の型。

誰向けか

• AI エージェントに next-session.md 的な引き継ぎファイル＋memory/ を持たせている
• セッションを跨いで長期タスクを進めている
• 複数のセッション／端末が同じリソース（DB・シート・API・本番設定）を触りうる

何が起きるか（実例の構造）

1. セッション A が「Xを開ける」という目的を引き継ぐ。文書には「まだ開いていない・承認待ち」とある。
2. 実際には別のセッションが数時間前に開け終わっていた。
3. しかし memory の該当ファイルには、新しい節（「開けた」）が追記された一方で、 古い節（「まだ開いていない」）がそのまま残っていた。
4. 引き継ぎファイルは古い節のほうを読んで目的を組み立てた。
5. セッション A は「開けるための承認」「ログイン」「reCAPTCHA 突破」といった 存在しないブロッカーを解こうとした。

根本原因は、memory の更新が「追記」だけで「古い結論の打ち消し」を伴わなかったこと。 追記型のメモリは、時系列で読むと正しいが、検索・要約で拾われると古い結論が生き残る。

型1: 着手前に「状態を読み戻すコマンド」を1本だけ走らせる

引き継ぎに書かれた目的がすでに達成済みでないかを、着手前に機械的に確かめる。 条件は「exit code で判定できること」。人間や AI の読解を挟まない。

# 例: 「在庫の穴を埋める」が目的なら、穴が残っているかを exit code で返す道具を先に走らせる
<state-check-command> --from <開始> --to <終了>   # 穴があれば exit 1 / 無ければ exit 0

• 引き継ぎの「次の1目的」には、必ずこの検証コマンドを併記する。 目的の書き方を「Xをする」ではなく「<cmd> が exit 0 になるようにする」に寄せると、 達成済みかどうかが着手前に1コマンドで分かる。
• API の成功応答・ジョブの成功ログは「システムがそう思っている状態」であって 「実際にそうなっている状態」ではない。読み戻しで判定する。
• 外向き（顧客に見える画面・公開ページ）に関わるなら、その画面を実際に開いて読み戻す。

型2: memory を更新するときは古い節を打ち消す

追記するだけにしない。古い節の結論を明示的に無効化する。

## 状態と次の手

**【<日付> 再確認・完了】もう当てはまらない。この節の以下は履歴。**
<検証コマンド> → <結果・exit 0>
残っている論点は <別ファイル> に移した。

<details><summary>（<日付> 以前に書かれた記述。履歴として残す）</summary>

...古い本文...

</details>

• 消さずに <details> で畳む。過去版は消さないが、要約・検索で拾われる位置から外す。
• 索引ファイル（MEMORY.md 等）の1行説明も同時に直す。索引が古いと本文を直しても意味がない。
• ファイル冒頭の description を直す。多くの実装はまず description だけを読んで関連性を判定する。

型3: ロックの「保持者」を端末名にしない

排他ロックを入れていても、保持者 ID が端末名やリポジトリ名だと、 同一マシンの別セッションが取ったロックが「自分が持っている」と表示され、衝突を検知できない。

• 保持者にはセッション ID を入れる。端末名だけでは足りない。
• ロック取得時に 目的 を必須にする。表示された目的が自分の記憶にないなら、別セッションである。
• ロックが空いている＝安全ではない。 直前に別セッションが作業を終えて解放した可能性がある。 空いていても型1の読み戻しは省かない。

型4: 「承認が要る作業」は承認に依存しない部分を全部終わらせてから止める

• 非対話セッション（人間の入力が無い実行）では、対話ツールの「回答」は人間の承認ではない。 それを根拠に本番へ書かない。
• 調査・診断・数値の裏取りは承認不要。そこを全部やり切ってから止めると、 次のセッションは「決めるだけ」で済む。
• 止めるときは「何を・どこへ・なぜ」と実行すべき正確なコマンドを引き継ぎに残す。

チェックリスト（セッション開始時）

• 引き継ぎの「次の1目的」に検証コマンドが併記されているか
• そのコマンドを着手前に走らせて exit code を見たか
• 目的が達成済みだったら、引き継ぎと memory の古い結論を打ち消したか
• ロックの保持者・目的を見て、別セッションでないと確認したか
• 外向きの変更なら、実画面を開いて読み戻したか

効果

この型を入れる前は、同じ引き継ぎを2セッションが同時に拾い、 片方は完了済みの作業のブロッカー解消に丸ごと1セッションを使った。 型1を入れると、その判定が着手前の1コマンド（数秒）で終わる。