🐭

Claude Codeにセーブとロードを作った話

に公開

1. Claude Code のセッションは揮発する

Claude Codeで開発をするとき、 コンパクションで劣化する問題。 誰もが気になっていると思う。

今では claude -c で直前のセッションを再開できるし、--resume でセッションIDを指定して戻ることもできる。が、これは「会話履歴の復元」であって「作業状態の復元」ではない。
オマケにこのオプションを使うと初っ端からコンテキストが消費されている。

それを避けるためにまっさらなセッションを開けば、

「昨日は○○の仕様書を書いて、△△まで終わって、次は□□をやる予定だった。関連ファイルはこれとこれで...」

毎回これを手で説明するのは面倒だ。しかもこの説明自体がコンテキストを食う。
実に困るし、疲れる。


2. 組み込みの機能では足りない

Claude Code にもいくつか永続化の仕組みはある。

MEMORY.md はプロジェクトのパターンやユーザーの好みを自動で記録してくれる。便利なんだが、これは「プロジェクト全体の知識」であって「今日どこまで進んだか」ではない。

claude -c / --resume は会話履歴をそのまま復元する。結果については上に挙げたとおり。

/rewind はファイルの変更を巻き戻す仕組み。コードの復元であって、作業状態の復元ではない。

結局、「今どこまで進んでいて、次に何をすべきか」を構造的に保存・復元する仕組みがない。


3. よし、セーブしよう

ここでゲームのセーブ機能を思い出した。
Claude Codeは、というかClaudeは頭が良い。コンテキストが保たれていればその状況を要約するのなんてお手の物だ。
つまり、コンパクションを起こす前にセーブして。クリアか再起動したらロードすればバッチリなのでは?

そこで、コマンド作ってみた。


4. 作った:4コマンド体系

コマンド 用途 コンテキスト消費
/quick-save 軽量セーブ(SESSION_STATE.md のみ) 3-4%
/quick-load 軽量ロード(日常の再開) ~1%
/full-save フルセーブ(commit + push + daily) 約10%
/full-load フルロード(数日ぶりの復帰) 2-3%

quick と full の2段階にしたのには理由がある。

Claude Code のコンテキストウィンドウは有限だ。セーブやロードの操作「自体」がコンテキストを消費する。ここを見落としている人は多いんじゃないかと思う。

quick-save + quick-load は合計 4-5% で往復できる。full-save + full-load だと約 12-13%。残量が 25% を切っていたら quick しか選べない。余裕があれば full。判断基準はそれだけ。


5. セーブデータの中身

/quick-save が書き出す SESSION_STATE.md はこんな感じになる。

### 完了タスク
- 認証API の仕様書を作成

### 進行中タスク
- DB スキーマ設計中(テーブル定義まで完了、インデックス設計が残り)

### 次のステップ
1. インデックス設計を完了
2. API エンドポイント仕様書に着手

### 変更ファイル一覧
- docs/specs/auth-api.md
- docs/adr/003-session-management.md

### 未解決の問題
- JWT と Session の選定が未決(ADR 作成中)

### コンテキスト情報
- ブランチ: feature/auth
- 関連ドキュメント: docs/specs/auth-api.md

次のセッションで /quick-load を叩くと、Claude がこれを読んで一行で返してくる。

次: インデックス設計を完了 | 未解決: JWT vs Session 選定

これで復帰完了。コンテキスト消費は約 1%。前回の作業内容を長々と説明し直す必要がない。


6. なぜわざわざコマンドにするのか

「毎回 SESSION_STATE.md を書いてって言えばよくない?」と思うかもしれない。

まあそれでも動くんだが、毎回「完了タスクを書いて、次のステップも書いて、ファイル一覧も…」と指示するのが地味に面倒なんだよね。/quick-save の一言で済むのとでは体験が全然違う。

それとフォーマットが安定する。毎回同じ構造で書き出すから、ロードしたときの読み取りがブレない。

あと見落としがちな点として、カスタムコマンドのプロンプトテキストは実行時にコンテキストへ注入される。プロンプト自体を短く書けば操作コストが下がる。実際、full-load のコマンド定義を 56行から 31行に削って、それだけで消費量が減った。コマンドの最適化もコンテキスト節約のうちだ。


7. full-save — 一日の終わりに叩くやつ

/full-save は quick-save に加えて以下もやる。

  1. 変更を論理グループ別に git commit
  2. git push
  3. docs/daily/YYYY-MM-DD.md に日次記録

一日の終わりにこれを叩くだけで、コードの保存から日報まで一気に終わる。

ただし約 10% のコンテキストを食う。残量が少ないときは自動で /quick-save にフォールバックする仕組みにしてある。コンテキストが尽きかけているのにフルセーブを実行して詰む、という事態は避けたかった。


8. 一日の流れ

朝(新セッション開始)
  → /quick-load
  → 「次: テスト追加 | 未解決: なし」
  → 作業開始

作業中(コンテキストが減ってきた)
  → /quick-save → exit
  → 新セッション → /quick-load → 続行

夕方(一日の終わり)
  → /full-save
  → commit + push + daily 記録まで自動

このサイクルが回り始めると、セッションが切れることへのストレスがほぼなくなる。「切れたらセーブ&ロードすればいい」と思えるだけで、気持ちの余裕がだいぶ違う。
ちなみにコンテキスト残量は Statusline で常時表示している。Statusline は Claude Code のターミナル下部にカスタム情報を表示できる機能で、設定ファイルに一行書くだけでコンテキスト消費量をリアルタイムに確認できる。これでセーブのタイミングを逃すことはない。
ただし、コンテキスト残量が気になる病気になるが。


9. Windows でも動く

地味に嬉しいポイントとして、この仕組みはプラットフォームを選ばない。

セーブデータの実体は SESSION_STATE.md というただの Markdown ファイル。コマンド定義も .claude/commands/ にある Markdown。シェルスクリプトにもOS固有のツールにも依存していない。

WSL を使わない素の Windows でも、macOS でも、Linux でも、Claude Code が動くなら動く。セッション管理のためにシェルスクリプトを書いたりプロセス監視ツールを入れたりしなくていい。私自身、Windows と WSL を行き来しているので、これは実際に助かっている。


10. LAM の一部だが、単独でも使える

この save/load は、私が作っているLiving Architect Model (LAM) というフレームワークの中で作ったものだ。

LAM は Claude Code を「設計者・門番」として動かすプロトコルセットで、フェーズ管理や承認ゲート、3 Agents Model による意思決定なんかを含む。save/load はその「セッション管理」モジュールにあたる。

ただ、LAM を使っていなくてもこの部分だけ単独で導入できる。 そんな特別なものでもない。なので次のセクションにそのまま使えるファイルを置いておく。


11. おまけ:あなたのプロジェクトにも入れてみないか

以下の 2 ファイルをプロジェクトの .claude/commands/ に置くだけで使える。

LAM のフェーズ管理には依存していない汎用版にしてある。そのまま使ってもいいし、自分のプロジェクトに合わせていじってもいい。

たとえばチーム開発なら「担当者」「レビュー待ち」を足すとか、フロント開発なら「確認した画面」「残りの画面」を足すとか。使いながら育てるのがいいと思う。

.claude/commands/quick-save.md

# クイックセーブ

SESSION_STATE.md に現在の作業状態を記録する。簡潔に。

## SESSION_STATE.md を書き出す

以下の各項目を箇条書きで記録:

### 完了タスク
- 今回完了した作業

### 進行中タスク
- 途中のものと現在の状態

### 次のステップ
- 次にやるべきこと(優先順位付き)

### 変更ファイル一覧
- 変更したファイルのパス

### 未解決の問題
- 残っている課題(なければ「なし」)

### コンテキスト情報
- 現在のgitブランチ
- 関連ドキュメント

## 完了報告

「quick-save 完了。再開時は /quick-load」と表示。

.claude/commands/quick-load.md

# クイックロード

SESSION_STATE.md を読み、以下の形式で報告:

次: [最優先ステップ] | 未解決: [あれば/なし]

報告後、ユーザーの指示を待つ。先回りしてファイルを読み込まない。

使い方:

  1. 上の 2 ファイルを .claude/commands/ に置く
  2. セッションの切れ目で /quick-save
  3. 次のセッションで /quick-load
  4. 前回の続きから

特別な設定もツールのインストールも要らない。


まとめ

Claude Code のセッションは揮発する。-c や MEMORY.md だけでは「作業状態」は保存できない。

SESSION_STATE.md に構造化された状態を書き出して、次のセッションで読み込む。やっていることはそれだけだ。ただ、セーブ/ロードの操作自体がコンテキストを食うという点に気づいて quick/full の 2 段階にしたことで、実用に耐える仕組みになった。

Markdown だけで完結するのでプラットフォームも選ばない。.claude/commands/ に 2 ファイル置くだけで導入できる。気になったら試してみてほしい。

リポジトリ: sougetuOte/LivingArchitectModel

Discussion