Claude Code 2.0チェックポイント機能実践ガイド - リカバリーパターンと運用戦略¶
この記事は朝の記事のフォローアップです
基本機能の概要: Claude Code v2.0発表
対象読者: Claude Code v2.0の基本操作を理解している中級開発者
ゴール¶
- チェックポイント機能の3つの復元モードを実務シナリオで使い分ける
- エラーリカバリーと実験的コード変更の高速化を実現
- Git併用での効果的な運用パターンを確立
チェックポイント機能の基本アーキテクチャ¶
自動保存のトリガー¶
チェックポイントはユーザープロンプト送信ごとに自動生成される。以下の操作は対象外：
- Claude単独のコード変更
- ユーザーが直接エディタで編集
bashコマンド経由の変更
保持期間とストレージ¶
- 30日間自動保持
- ローカル
.claude/checkpoints/ディレクトリに保存 - プロジェクトごとに独立管理
アクセス方法¶
| 操作 | コマンド |
|---|---|
| リスト表示 | /checkpoints |
| 復元UI起動 | Esc を2回 または /rewind |
| 特定ポイント指定 | /rewind <checkpoint_id> |
3つの復元モードと実務シナリオ¶
モード1: 会話のみ復元（推奨頻度：高）¶
使用シーン: - Claudeの提案を却下し、別のアプローチを指示したい - プロンプトの言い回しを変えて再試行したい - コンテキストが肥大化したので会話をリセットしたい
実行例: - 状況: Claudeが10ファイルに渡る大規模リファクタリングを提案 - 判断: 影響範囲が大きすぎる - 操作: /rewind → 「会話のみ」選択 → 「まず auth.ts だけリファクタリングして」と再指示 - 結果: ファイル変更は維持、会話だけやり直し
ベストプラクティス: - コード変更を保持したまま方針転換できる - トークン節約（不要な会話履歴を削除） - 並行して手動編集した箇所を保護
モード2: コードのみ復元（推奨頻度：中）¶
使用シーン: - Claudeの生成コードに致命的バグがあった - 期待と異なる実装になったが、会話の文脈は保持したい - 複数の実装案を試したい（A/Bテスト）
実行例: - 状況: APIエンドポイント追加後、既存テストが全滅 - 判断: 新エンドポイントは問題ないが、既存コードの改変が不適切 - 操作: /rewind → 「コードのみ」選択 → 「既存エンドポイントは変更しないで」と追加指示 - 結果: コードは巻き戻り、会話コンテキストで再実装
ベストプラクティス: - 会話の流れを断ち切らない - Claudeの理解度を保ちつつコードだけやり直し - 失敗パターンの記録として会話履歴を活用
モード3: 両方復元（推奨頻度：低）¶
使用シーン: - 完全に方向性を変えたい - 複数のプロンプトに渡る変更がすべて不要になった - 実験的な大規模変更をリセット
実行例: - 状況: 5プロンプトに渡りGraphQL移行を進めたが、要件変更でREST API継続決定 - 判断: 全作業を白紙に戻す - 操作: /checkpoints → IDを特定 → /rewind <id> → 「両方」選択 - 結果: コードと会話が完全に移行前に戻る
注意点: - ユーザーの直接編集は復元されない（Git管理推奨） - 長時間作業後の全復元はトークン浪費のリスク
失敗パターンと回避策¶
| 症状 | 原因 | 回避策 |
|---|---|---|
| 復元後も問題が再現 | ユーザーの直接編集が原因 | Git diff確認 → 手動修正 |
| 30日超過で復元不可 | 保持期限切れ | 重要な実験はGitブランチ作成 |
| チェックポイント肥大化 | 過度な細分化 | /clearで不要な履歴削除 |
| 復元後のコンテキスト喪失 | 会話削除しすぎ | モード1優先使用 |
Git併用の運用戦略¶
推奨ワークフロー¶
graph LR
A[新機能着手] --> B[Gitブランチ作成]
B --> C[Claudeに実装依頼]
C --> D{結果確認}
D -->|OK| E[Git commit]
D -->|NG| F[チェックポイント復元]
F --> C
E --> G{さらに改善?}
G -->|Yes| C
G -->|No| H[PR作成]使い分け基準¶
| 操作 | Claude Checkpoint | Git |
|---|---|---|
| 短期実験リカバリー | ✅ 推奨 | ❌ commit汚染 |
| 長期保管 | ❌ 30日制限 | ✅ 永続保存 |
| チーム共有 | ❌ ローカルのみ | ✅ push可能 |
| 会話コンテキスト保持 | ✅ 可能 | ❌ 不可 |
実践例：実験的リファクタリング¶
# 1. 安全ネット構築
git checkout -b experiment/refactor-auth
# 2. Claudeに依頼
# "auth.tsを関数型に書き換えて"
# 3. 結果をテスト
npm test
# 4a. 成功パターン
git add auth.ts
git commit -m "refactor: convert auth.ts to functional style"
# 4b. 失敗パターン
# Esc×2 → コードのみ復元 → 再指示
# または
git reset --hard # Git経由で完全リセット
自動化・拡張パターン¶
チェックポイント定期クリーンアップ¶
15日以上前のチェックポイントを削除するスクリプト例:
find .claude/checkpoints -type f -mtime +15 -delete
CI/CD統合（非推奨）¶
チェックポイントはローカル開発専用。CI環境ではGitのみを信頼すること。
チーム規約例¶
- 使用タイミング: 1機能の実装中に複数案を試す → チェックポイント / 機能完成後の保存 → Git commit
- 禁止事項: チェックポイントディレクトリのGit管理、30日超過後の復元期待
ベンチマーク：復元速度¶
| 操作 | 所要時間 | 備考 |
|---|---|---|
| チェックポイント作成 | < 0.1秒 | ユーザー体感なし |
| 会話のみ復元 | < 0.5秒 | 即座 |
| コードのみ復元 | 1-3秒 | ファイル数依存 |
| 両方復元 | 1-5秒 | プロジェクト規模依存 |
| Git reset --hard | 0.5-2秒 | 比較参考 |
結論: チェックポイントはGitと同等以上の速度で、会話保持の優位性がある。
次のステップ¶
- Claude Code v2.0発表 - 全体像の把握
- Claude Code完全ガイド - 基礎から応用まで
- CLAUDE.md実践ガイド - プロジェクト設定最適化
注意事項: - チェックポイントはセッション管理ツールであり、永続的バージョン管理の代替ではない - 重要なコード変更は必ずGitで管理すること - 本記事の情報はClaude Code v2.0.0時点（2025年9月30日リリース）のものです
公式ドキュメント: https://docs.claude.com/en/docs/claude-code/overview