この記事の成り立ち
Claude Code で開発している間、心にずっと引っ掛かって言うことがあります。それは、 PC が突然落ちたときのコンテキスト喪失です。
何度Windows再起動がかかり消えたことか。。。。
その対策として導入した「戦役台帳（せんえきだいちょう）」という仕組みの話です。
大げさな仕掛けではなく、1枚の Markdown ファイルで解決する、という現実解を共有します。
ちなみにこれは、部下としてのAI（牛尾剛）のなかで紹介されたチェックリスト法を大名システムへアレンジしたものです。とても良い本ですので、ぜひ読んでください！！
要約
- AI エージェント開発では、計画・進捗が 会話コンテキスト（とその中の TodoList）に揮発的に存在している。PC クラッシュ・セッション断でまるごと消える。
- ただし、よく考えると 失われるのは「作業の成果」ではない。コミットや push 済みブランチに成果は残っている。失われるのは「どの作業が、どのブランチ / worktree / PR に、どこまで進んだか」という 地図 のほうだ。
- ならば守るべきは地図。そこで、計画が固まった時点で branch / worktree / PR番号 / 状態を書いた進捗台帳を1ファイルに落とし、作業のたびに更新、完了時に削除する運用にした。
- ポイントは「チェックリストではなく、復旧用の地図にする」こと。チェックボックスだけでは再起動後に「成果がどこにあるか」が分からない。
-
.gitignoreでコミットされないようにし、雛形だけを追跡する。「クラッシュ＝正常終了しない＝ファイルが残る」を逆手に取った、シンプルなライフサイクル設計がキモ。
1. 何が怖かったのか — コンテキスト喪失問題
複数の Claude サブエージェントを戦国の指揮系統になぞらえて動かす「大名システム」で開発しています（詳細は別記事）。流れはこうです。
軍議で決めた「陣立て（どの隊が何をどの順で作るか）」と、出陣後の進捗は、すべてその場の会話コンテキストの中にあります。Claude Code の TodoList も同じで、コンテキスト内に持つ揮発的な状態です。
つまり、こうなります。
長時間の戦役（複数隊・複数フェーズ）の途中で PC が落ちると、「さて、どこまでやったんだっけ？」が分からなくなる。再起動して会話を開いても、Claude も人間も、進捗を一から思い出す羽目になります。これが コンテキスト喪失問題 です。
2. なぜ TodoList では守れないのか
「進捗管理なら TodoList があるじゃないか」と思うかもしれません。実際、Claude Code には TodoWrite ツールがあります。
しかし TodoList はコンテキスト内に持つ＝揮発する。クラッシュすれば計画ごと一緒に消えます。耐久性（durability）がない。
であれば、ディスク上のファイルに落とすしかありません。発想としては単純です。実はこのプロジェクト、すでに xxx-handoff.md や EXECUTION_LOG.md といったファイルを非公式に作っていました。やっていたことを、正式な型に整えるのがこの記事の主題です。
3. 着眼点 — 失われるのは「作業」ではなく「地図」
ここが一番大事な発想の転換です。
大名システムの足軽（実装担当のサブエージェント）は、git worktree で 物理的に隔離された別ディレクトリで作業し、成果は コミットします。多くは push 済みで、PRにもなっています。
つまり、PC が落ちても 作業の成果そのものは無事なのです。worktree のコミット、push されたブランチ、作成済みの PR ── どれも生きている。
失われるのは 「成果がどこにあるかを示す地図」だけ。だったら、守るべきは地図です。チェックボックスの ✅ / ⬜ よりも、branch / worktree名 / PR番号 / 状態 という識別子こそが復旧の鍵になります。
4. 解決策 — 戦役台帳（Campaign Ledger）
そこで導入したのが 戦役台帳 です。要は「識別子つきの進捗地図を1枚の Markdown に書く」だけ。
4.1 ライフサイクル
設計のキモは 「クラッシュ＝正常に終了しない＝ファイルが残る」を逆手に取ること。正常完了時だけ自分で削除する。異常終了時は消し忘れではなく、意図的に残る。これでクラッシュ復旧と、平時の散らかり防止を両立できます。
4.2 置き場所と .gitignore
実台帳はコミットしたくない（PR に混入したり、毎回 diff が出ると鬱陶しい）。一方で雛形（テンプレート）は追跡したい。これは .gitignore の否定パターンで実現します。
# 大名システム 戦役台帳（クラッシュ耐性。完了時に削除。テンプレートのみ追跡）
.claude/campaigns/*
!.claude/campaigns/_TEMPLATE.md
ハマりどころ: .claude/campaigns/（ディレクトリ丸ごと無視）と書くと、git はそのディレクトリに降りていかないため、中のファイルを ! で復活させられません。.claude/campaigns/*（中身を無視）+ !_TEMPLATE.md と書くのが正解です。
4.3 中身 — チェックリストではなく「地図」
各行に branch / worktree / PR番号 / 状態 を必ず書く。これが普通の ToDo リストとの決定的な違いです。
# 戦役台帳: ユーザー通知機能 Phase 2 (2026-06-19)
- 御裁可: ✅済（2026-06-19「よきにはからえ」）
- 目的: 通知のリアルタイム配信とインボックス統合
## Phase / 隊
- [x] 隊A BE実装 — branch: `feat/notify-be` / worktree: `agent-aaaa` / PR #1670 / 状態: MERGED
- [ ] 隊B FE実装 — branch: `feat/notify-fe` / worktree: `agent-bbbb` / PR #-- / 状態: commit済・PR未作成
- [ ] 検分 — Workflow検分 / 状態: 未
- [ ] マージ — 全PRマージ確認
## 次の一手（再起動後に最初に読む欄）
隊B の worktree `agent-bbbb` のコミットを検分 → PR作成
5. 復旧シナリオ — クラッシュ後はこう動く
PC が落ちて再起動。会話コンテキストは空。でも .claude/campaigns/ に台帳が残っています。手順はこうです。
「次の一手」欄に 隊B の worktree agent-bbbb のコミットを検分 → PR作成 と書いてあれば、再起動直後でも迷わず続行できます。作業はやり直さない。地図を読んで合流するだけです。
6. MEMORY とは役割を分ける
Claude Code には長期記憶（MEMORY.md などの永続メモリ）の仕組みもあります。これと戦役台帳を混同しないのが重要です。
| 戦役台帳 | 永続メモリ（MEMORY） | |
|---|---|---|
| スコープ | 1戦役内 | 横断・プロジェクト全体 |
| 寿命 | 一時的（完了時に削除） | 恒久 |
| 中身 | branch / PR / 進捗の地図 | 設計判断・教訓・落とし穴 |
| 例 | 「隊B は agent-bbbb、PR未作成」 | 「Flyway 採番は全体最大の次の major」 |
台帳は使い捨ての作業地図、メモリは積み上げる知見。台帳を削除する前に、得られた横断的な教訓だけメモリへ移す運用にしています。
7. やりすぎないこと — 適用範囲
何でもかんでも台帳を作ると、オーバーヘッドのほうが勝ちます。線引きはシンプルです。
| 台帳を作る | 台帳を作らない |
|---|---|
| 複数隊・複数フェーズ・長時間の戦役 | 1〜2ファイルの即時修正 |
| 軍議が必要な規模の機能開発 | 対話だけ・質問への回答 |
| 数時間〜数日にわたる作業 | コミット前にちょっと確認するだけ |
「クラッシュしたら思い出すのが面倒な規模か？」を基準にすると判断しやすいです。
8. スキルへの組み込み
大名システムのスラッシュコマンド（スキル）に、台帳のライフサイクルを規約として埋め込みました。
| タイミング | スキル | 動作 |
|---|---|---|
| 作成 | /軍議 |
御裁可直後・出陣前に、雛形から台帳を生成 |
| 更新 | /出陣 |
戦果収集時に branch / worktree / PR / 状態・「次の一手」を追記 |
| 更新→削除 | /検分 |
検分所見を追記。全PRマージで戦役完了時に削除 |
これで「やったほうがいいよね」という口頭ルールが、ワークフローに組み込まれた機械的な手順に格上げされました。
まとめ
- AI エージェント開発の コンテキスト喪失問題 は、計画・進捗が揮発的メモリにしか無いことが原因。
- 解決の着眼点は「失われるのは作業ではなく地図」。成果はコミット / push / PR に残っている。
- だから守るべきは地図。branch / worktree / PR番号 / 状態を書いた1枚の Markdown を、計画確定時に作り、作業のたびに更新し、完了時に削除する。
-
.gitignoreの否定パターンで「実台帳は非追跡・雛形だけ追跡」。クラッシュ＝ファイルが残るを逆手に取ったライフサイクル。 - 永続メモリとは役割を分け、過剰運用しない線引きを持つ。
派手な仕組みではありません。でも「PC が落ちても続きから戦える」という安心感は、長時間の AI 開発でかなり効きます。コンテキスト喪失問題への、確かな一歩でした。