Claudeのセッション管理：resumeとforkで長期タスクを効率化

結論

Claude Codeのセッション管理機能を使いこなすと、長時間の調査や複数アプローチの比較が大幅に効率化されます。--resumeで中断したセッションを再開し、fork_sessionで同じ調査基盤から複数の方向性を並行探索できます。

ただし、セッション再開は万能ではありません。前のセッション以降にコードを変更した場合や、古いツール実行結果が多く残っている場合は、要約を持って新規セッションを始める方が精度が上がります。

---

セッション管理が必要になる場面

コードベースの大規模調査や長時間のリファクタリング作業では、次のような状況が生じます。

状況1: 作業を中断して翌日再開したい 大規模なレガシーコードの調査を始めたが、今日中に終わらない。明日、同じ文脈で調査を続けたい。

状況2: 同じ調査基盤から2つのアプローチを比較したい 認証システムをJWTとセッションの2方式で実装する場合を比較検討したい。どちらの調査も同じコードベース理解から始まるが、比較後は独立して進めたい。

状況3: 調査フェーズと実装フェーズを分けたい プランモードで全体像を調査した後、実装フェーズに移る際に新しいクリーンな状態で始めたい。

---

—resumeでセッションを再開する

セッションに名前をつけて保存する

Claude Codeでの作業開始時に、セッション名を指定します。

claude --session-name "auth-refactor-investigation"

この名前をつけることで、後から同じ名前で再開できます。

保存したセッションを再開する

claude --resume "auth-refactor-investigation"

再開すると、前の会話履歴・発見した事実・ツール実行結果がそのまま参照できる状態で始まります。「昨日どこまで調べたか」を最初から話さなくて済みます。

再開時に必ず伝えること

セッションを再開するとき、前のセッション以降に変更したファイルがある場合は明示的に変更内容を伝えます。

悪い再開の仕方:
「昨日の調査の続きをやりましょう」
（Claudeは前の状態のままのファイル内容を参照しようとする）

良い再開の仕方:
「昨日の調査を再開します。昨日以降に次のファイルを変更しました:
- src/auth/jwt.ts: トークン検証ロジックを追加
- src/middleware/auth.ts: 認証ミドルウェアの引数を変更
この2ファイルについては再確認してください」

変更を伝えずに再開すると、Claudeは古いファイル内容のイメージのまま作業を続けるため、「そのファイルは既に修正済みです」という矛盾が発生します。

---

セッション再開 vs 新規セッション+要約

セッションを再開すべきか、新規セッションで始めるべきかの判断基準を整理します。

状況	推奨
ファイルをほとんど変更していない	セッション再開
同じ問題の調査を少し続けるだけ	セッション再開
コードを大幅に変更した	新規セッション+要約
古いツール実行結果が多く残っている	新規セッション+要約
フェーズが変わった（調査→実装）	新規セッション+要約

新規セッションで始める場合、前のセッションの主要な発見を「調査サマリー」として文書化してから渡します。

# 認証システム調査サマリー（2026-06-04）

## 現在の実装
- 認証方式: セッション（express-session + Redis）
- セッションの場所: src/auth/session.ts (L1-89)
- ミドルウェア: src/middleware/auth.ts

## 発見した問題
1. セッションの有効期限設定が環境変数に依存しているが、本番環境で未設定
2. ログアウト処理でセッション破棄が不完全（L67）

## 提案された移行先
JWTに移行する場合の主な変更箇所: 3ファイル・約120行の変更が見込まれる

ツール実行結果の生データより、整理された文章のサマリーの方が確実に参照されます。

---

fork_sessionで複数アプローチを並行比較する

fork_sessionは同じ調査基盤から2つの独立したセッションに分岐させる機能です。それぞれのフォークは互いに独立して実行され、どちらが有望かを比較できます。

使い方の例: 認証方式の比較

ベースセッション（共通の調査フェーズ）:
  コードベースの現状を把握
  → セッションAにフォーク: JWTへの移行プラン
  → セッションBにフォーク: セッション管理の改善プラン

それぞれのフォークで独立して実装計画を立て、比較した上でどちらを採用するか決定します。

fork_sessionが効果的な場面

テスト戦略の比較 「ユニットテストを増やす」アプローチと「統合テストを増やす」アプローチを、同じコードベース理解から並行して検討する。

リファクタリング手法の比較 既存コードを段階的に移行するアプローチと、新しいモジュールに一気に置き換えるアプローチを比較する。

外部ライブラリの比較 2つの候補ライブラリを同じコードベースに適用した場合の影響を、それぞれ独立して調査する。

フォークセッションのコスト

フォークするとそれぞれが独立したAPIリクエストを消費します。「比較する価値がある」と判断した場合にのみ使い、些細な違いのためにフォークするのは避けます。

---

長期セッションでコンテキストを管理する

セッションが長くなるほど、コンテキストウィンドウが埋まります。次のサインが出たら対処が必要です。

コンテキスト劣化のサイン

• 「一般的なパターンとして」「よくある設計では」のような曖昧な言い方が増える
• 1時間前に発見した特定クラスの構造を「再確認してください」と言われる
• 前回指摘した問題への対応を「どのように修正しましたか？」と聞かれる

対処法1: /compactで圧縮する

/compact

現在のコンテキストを要約して圧縮します。フェーズが切り替わるタイミングで実行すると効果的です。

対処法2: スクラッチパッドで発見を永続化する

# 調査メモ: 支払い処理モジュール

## 主要クラス
- PaymentProcessor: src/payment/processor.ts (L1-234)
  - Stripe APIとの接続を管理
  - 失敗時はRetryQueueに追加
  
## 未解決の疑問
- RefundServiceとの依存関係が不明

このファイルをセッション中に更新し続けることで、コンテキストウィンドウの外に発見事実を保存できます。

コンテキスト管理の詳細についてはAIのコンテキスト管理術を参照してください。

---

CI/CDでのセッション管理

CI/CDパイプラインでClaude Codeを使う場合、セッション管理は少し異なります。

パイプラインは毎回クリーンな状態で実行されるのが基本です。CIでの実行に「前のセッションの文脈」を引き継ぐことは通常しません。代わりに、CLAUDE.mdでプロジェクトのコンテキストを提供します。

# .claude/CLAUDE.md

## 自動レビューのコンテキスト
- プロジェクト: ECサイト（TypeScript + React）
- テストフレームワーク: Jest
- 既知の許容パターン: src/legacy/以下のjQuery残存は許容

CLAUDE.mdの設定についてはCLAUDE.mdでチームのAI作業を標準化する設定ガイドで詳しく解説しています。

---

セッション再開後の精度を保つベストプラクティス

コードを変更した場合は必ず伝える

「昨日の調査を再開します。
変更したファイル:
- src/payment/processor.ts: RetryQueue の実装を追加
- src/types/payment.ts: PaymentStatus型を更新

この2ファイルについて再確認してから続きを進めてください。」

再確認のスコープを絞る

「全ファイルを再確認してください」ではなく「この2ファイルだけ再確認」と明示します。不要な再探索を防ぎ、効率を保てます。

前のセッションのツール結果が古い場合は新規セッションを選ぶ

前のセッションで取得した「顧客データ」「注文状況」のような外部データは、時間が経つと古くなります。古いデータに基づいた判断が新しい作業に影響する場合は、新規セッションで新しいデータを取得します。

---

まとめ

Claude Codeのセッション管理を使いこなすポイントをまとめます。

• --session-nameで名前をつけて保存し、--resumeで再開する
• 再開時はファイルの変更内容を必ず明示的に伝える
• コードを大幅変更した場合は要約を持って新規セッションを選ぶ
• fork_sessionで同じ基盤から複数アプローチを並行比較する
• 長期セッションでは/compactとスクラッチパッドでコンテキストを管理する
• CIパイプラインでは毎回クリーンに実行し、CLAUDE.mdでコンテキストを提供する

これらを使いこなすことで、数日にわたる大規模な調査や実装作業を、文脈を失わずに効率的に進められます。