Claude Codeセッション管理、どうしてる？

きっかけ

クラスメソッドのshuntakaさんが書いた「ターミナル生活を支えるClaude Code設定」を読んで、自分の運用と比べてみたくなった。

記事ではtmuxで3ペイン立ち上げて、セッションを残しておく運用が紹介されていた。レビュー途中のPRとかは消さずに残しておいて、後で見返せるようにしているらしい。

自分はどうしてるかな、と振り返ってみた。

セッション管理の考え方

セッションを残す派（shuntakaさん）

tmuxの3ペインでClaude Codeを複数起動
レビュー途中のセッションは残しておく
claude -rで同セッションに入り、ESC ESCで遡ってfork

メリットは作業ログとして残ること。後で「何やってたっけ」が分かる。

記憶を永続化する派

claude-memのようなMCPで記憶を永続化する手もあるらしい。自分は使ってないけど、選択肢としてはある。

gitプッシュ派（自分）

自分は圧縮される前にまとめさせて、gitにプッシュしている。

CLAUDE.mdにこう書いてある：

セッション終了時: 必ず git add -A && git commit && git push を実行する

理由はシンプルで、gitに残る方が確実だから。

Claude Codeのセッションは揮発性がある。コンテキスト圧縮されたら何が残ってるか分からないし、品質も読めない。一方gitは確実に残るし、他のツールからも参照できる。

ドキュメント構造

「後で見返す」をgitで実現するために、ドキュメント構造を整理している。

docs/claude/           # Claude用ガイド
  frontend.md          # フロントエンド開発
  backend.md           # バックエンドAPI開発
  appmanagement.md     # 管理画面フロント
  appmanagement-api.md # 管理画面API
  framework-common.md  # 共通フレームワーク
  docker-testing.md    # Dockerテスト環境
  ...

aidocs/appmanagement/  # タスク管理
  current-tasks.md     # 進行中のタスク
  completed-log.md     # 完了したタスクのログ

ポイントは「わかんないときはここ読め」が言えること。

Claudeが途中で詰まったら「docs/claude/backend.md読んで」と言えば、コンテキストを補完できる。セッションに暗黙的に残すより、ファイルとして明示的に残す方が確実。

タスク管理も同様で、current-tasks.mdに進行中の作業を書いて、終わったらcompleted-log.mdに移動させる。

これが解決してるのは「経緯が残らない」問題。CLAUDE.mdは簡潔に書くのがベストプラクティスだけど、「こうしろ」の箇条書きだけだと、なぜそうなったかが残らない。詳細を書き込むとすぐ1000行超えてコンテキストを圧迫する。

だから分離してる：

CLAUDE.md: 結論だけ（コンパクトに）
docs/: 経緯・背景・詳細（必要なときだけ読ませる）

機能ごとの経緯がcompleted-log.mdに残るので、後から「なぜこの実装になったか」が追える。セッション残す派が求めてる「後で見返す」を、gitで実現してる形。

スキル運用

Claude Codeのスキル（スラッシュコマンド）を用意して、サブエージェント的に使っている。

スキル	説明
`/build`	フロントエンドビルド
`/deploy-check`	デプロイ前チェック
`/docker-copy`	Dockerへファイルコピー
`/git-push`	Gitコミット＆プッシュ
`/seed`	テストデータ投入
`/status`	開発環境ステータス確認
`/test-e2e`	E2Eテスト実行（Playwright）
`/test-phpunit`	PHPUnitテスト実行
`/test`	テスト実行コマンド

運用ルールはこう：

スキルだけ実行、ファイル変更はさせない
終わりの通知だけ出す
メイン作業はメインエージェントで行う

例えばテストを走らせたいとき、メインの作業を止めずにサブエージェントでテストを回して、終わったら通知だけもらう。コンテキストを汚さないし、待ち時間も潰せる。

スキルは組み合わせることもできる。/deploy-checkはこんな感じ：

# デプロイ前チェック

ビルド → Docker送信 → テスト を一括実行する。

## 実行手順

1. `/build` - フロントエンドビルド
2. `/docker-copy` - Dockerへコピー
3. `/test` - PHPUnit + E2E テスト（並列）

## 使用タイミング

- 機能実装完了後
- プルリクエスト作成前
- 本番デプロイ前の最終確認

## 注意事項

- すべてのステップが成功することを確認してからデプロイする
- テストが失敗した場合は修正してから再実行

複数のスキルを順番に呼び出して、一括でチェックを回せる。「いつ使うか」「何に気をつけるか」まで書いておくと、Claudeが適切なタイミングで実行してくれる。

事故防止の工夫

パーミッション設定は必須。--dangerously-skip-permissionsは使わない。

理由は単純で、本番環境に飛ぼうとした事故があったから。

Dockerは本番環境に合わせて作ってるけど、設定ファイルが別なのでそのまま移せない。だから「本番用にビルドして、デプロイは目視でやる」という話をした。当然ビルドで止まると思ってた。

そのあと同じチャットで別の修正依頼に取りかかった。でもコンテキストには「本番用ビルドの話」が残ってる。Claudeからすると「本番環境で作業してる」認識のまま。設定ファイルを編集しようとしたところで気づいて止めた。

別のチャットだったらパーミッション設定とCLAUDE.mdの「本番アクセス禁止」で警告されたはず。同じチャットだったからコンテキストが優先されてしまった。

Claude Codeは言うこと聞かないことがあるし、コンテキストが長くなると指示を忘れる。「やっていい」と思ったら突っ走る。

だから「AIに正しく動いてもらう」より「間違えても被害が出ない仕組み」の方が大事。

自分の運用はそこを意識している：

パーミッションで制約をかける
サブエージェントはスキル実行のみ、変更禁止
成果物はgitに明示的に残す
圧縮前にまとめさせてプッシュ

まとめ

shuntakaさんの「セッション残す」運用と、自分の「gitプッシュ」運用。どっちが正解というわけではなく、目的が違う。

セッション残す: 作業ログとして後で見返す
gitプッシュ: 確実に残して、次に引き継げるようにする

正解は人それぞれ。自分に合ったやり方を探すのが良いと思う。