Claude Code Checkpoints の使い方｜/rewind でコードと会話を巻き戻す方法

Claude Code を使っていて、こんな経験はありませんか？

• 大胆なリファクタリングを任せたら、いつの間にか元に戻せない状態になっていた
• 「やっぱり別のアプローチを試したい」と思ったけど、Claude との会話を一からやり直すのが面倒
• デバッグ中の長いやりとりでコンテキストが膨らみ、肝心の指示が薄まってしまった

こうした「あの時点に戻りたい」という瞬間に効くのが、Claude Code の Checkpoints（チェックポイント） 機能です。

ファイルの変更前の状態を自動でスナップショットしてくれて、/rewind コマンド一発で過去のどのタイミングにも戻れます。しかも、戻し方は「コードだけ」「会話だけ」「両方」と細かく選べる。Git のように明示的にコミットする必要はなく、プロンプトを送るたびに勝手にチェックポイントが作られるのがポイントです。

この記事では、Checkpoints の基本から、3つの復元モードの使い分け、さらに進化版の「Summarize」機能、そして意外と知られていない落とし穴まで、実践目線で解説します。

チェックポイントは「いつ」「何が」記録されるのか

まず仕組みを正確に押さえておきましょう。Claude Code のチェックポイントは、あなたが Claude にプロンプトを送るたびに自動で作成されます。明示的にコミットする必要はありません。

記録される対象は、Claude がファイル編集ツール（Edit、Write、NotebookEdit など）で行った変更です。Claude が git status のような読み取り系コマンドを実行しただけではチェックポイントは増えません。あくまで「ファイルが書き換わった瞬間」をマークするイメージです。

そして地味に嬉しいのが、チェックポイントはセッションをまたいで保持されるということです。/resume で過去のセッションを再開しても、その時のチェックポイントにアクセスできます。保持期間はデフォルトで30日間で、この期間を過ぎたセッションのチェックポイントは自動的にクリーンアップされます。

つまり、Claude Code は裏でずっと「ファイル変更前のスナップショット」を取り続けていて、あなたがいつでも巻き戻せるように準備してくれている、というわけです。

/rewind の起動方法

巻き戻しメニューを開く方法は2つあります。どちらでも結果は同じです。

方法1：Esc キーを2回連打

これが最速です。Claude Code の入力フィールドにフォーカスがある状態で Esc を2回押すと、すぐにメニューが立ち上がります。「あ、これダメだ」と気づいた瞬間に押せるのが強みです。

方法2：/rewind コマンド

スラッシュコマンドで明示的に呼び出します。

/rewind

どちらの方法でも、これまで送ったプロンプトの一覧がスクロール可能なリストとして表示されます。「どこに戻りたいか」を選ぶだけです。

5つのアクションを全部理解する

ここが Checkpoints のキモです。チェックポイントを選ぶと、5つのアクションから1つを選択できます。それぞれの違いをきちんと理解しておくと、状況に応じて最適な戻し方ができるようになります。

それぞれ、どんな場面で使うべきか掘り下げていきましょう。

Restore code and conversation：完全リセット

「全部なかったことにしたい」という時に使う、いちばん直感的な選択肢です。コードも会話も、選んだチェックポイントの状態に戻ります。

たとえば、Claude にリファクタリングを任せたら、次々とファイルを書き換えてしまい、テストが軒並み壊れた。会話を遡って原因を探すのも面倒……。そんな時はこれを選ぶだけで、何事もなかったかのように振り出しに戻れます。

迷ったらまずこれを選んでおけば間違いありません。

Restore conversation：コードはそのまま、会話だけ巻き戻す

これは少しトリッキーですが、慣れるとめちゃくちゃ便利な使い方です。

具体的なシーンで考えてみましょう。Claude にバグ修正を依頼して、最終的に修正は完了。でも修正の途中で長々と試行錯誤の議論があり、コンテキストが汚れている。次に別の機能追加を頼みたいけど、不要な議論が文脈を引きずってきそう……。

この時に「Restore conversation」を選ぶと、コードの修正結果は手元に残したまま、会話だけが過去に戻ります。「結果は欲しいけど議論はリセットしたい」という状況にぴったりです。

Restore code：会話はそのまま、コードだけ巻き戻す

逆のパターンもあります。コードは元に戻したいけど、これまでの議論や設計判断は活かしたい、という場合です。

たとえば、Claude にあるアプローチで実装してもらった結果、動作はするけどあまり美しくない。「設計の議論はそのままで、実装だけやり直してほしい」という時に「Restore code」を選びます。Claude は直前までの会話を覚えたまま、ファイルの状態だけが巻き戻った状態から再スタートできます。

（会話の流れ）
You: このAPI、レスポンスをキャッシュしたい
Claude: Redisを使う案と、メモリキャッシュを使う案があります...
You: メモリキャッシュでお願い
Claude: 実装しました！（ファイル編集）
You: あー、やっぱりLRUにしたい。Restore code して、もう一度。

このように、設計の議論を活かしつつ実装だけリトライできるのは、Claude Code ならではの強みです。

Summarize from here：コンテキストを賢く圧縮する

ここからがちょっと面白い話です。「Summarize from here」は、これまでの3つとは性質が異なる機能で、コードや会話を巻き戻すのではなく、選んだ時点以降の会話を要約に置き換えるものです。

具体的にはこういう動きをします。

1. 選んだメッセージより前の会話は、そのままの形で保持される
2. 選んだメッセージとそれ以降のメッセージが、AI が生成したコンパクトな要約に置き換わる
3. ファイルは一切変更されない
4. 元のメッセージはセッションのトランスクリプトには残るので、必要なら Claude が後から参照できる

これがなぜ重要かというと、長時間のデバッグセッションなどでは、後半の試行錯誤がコンテキスト枠を圧迫してしまうことがあるからです。最初の指示や CLAUDE.md の方針はそのまま残しておきたい。でも途中の細かなやりとりは要約してしまいたい。そんな時に Summarize は最適解になります。

/compact コマンドを使ったことがある方は分かると思いますが、あれは会話全体を一気に圧縮します。一方の Summarize は 「ここから先だけ圧縮する」というターゲット版 です。最初の方のコンテキストはフル解像度で残せるのが大きな違いです。

要約時には、Claude にどう要約してほしいかオプションで指示も渡せます。「実装した関数名と意図だけ残して」のような細かい指定が可能です。

Never mind：気が変わったら

選択メニューを開いたものの「やっぱりやめておこう」と思ったら、これでキャンセルできます。

Restore 後はプロンプトが入力欄に戻ってくる

地味ですがとても便利な仕様があります。Restore conversation または Summarize を実行すると、選んだメッセージのプロンプトが入力フィールドに自動で復元されるのです。

つまり、「あのプロンプトをもう一度送りたい、でも文言を少しだけ調整したい」という時に、コピー＆ペーストする必要がありません。そのまま編集して再送信できます。

たとえば「このAPIをリファクタリングして」と頼んだ結果がイマイチだったら、Restore conversation してプロンプトを「このAPIを依存性注入を使ってリファクタリングして」と書き換えて再送信、という流れがスムーズにできます。

Summarize と /compact と Fork の使い分け

似たような機能が3つあるので混乱しがちですが、整理するとこうなります。

Fork については少し補足が必要です。claude --continue --fork-session を実行すると、現在のセッションの状態をベースに新しいセッションが立ち上がります。元のセッションには影響を与えずに、別の方向性で実験できます。

つまり、

• Summarize は「同じセッションで節約したい」
• Fork は「別の道も並行して試したい」
• Restore は「失敗を完全に巻き戻したい」

と覚えておくとスッキリします。

ハマりやすい落とし穴：bash コマンドは追跡されない

ここが Checkpoints を使ううえでいちばん重要な注意点です。

Checkpoints が追跡するのは、Claude のファイル編集ツールによる変更だけです。Claude が bash 経由でファイルを操作した場合、その変更は記録されません。

たとえば、こんな操作はチェックポイントに含まれません。

# これらは bash 経由なので追跡されない
rm config.old.json
mv legacy/utils.ts src/utils/legacy.ts
cp template.env .env.local
sed -i 's/old/new/' config.txt

つまり、Claude に「古いファイルを削除して」と頼んで rm で消されたファイルは、/rewind で戻すことができません。同じく mv でリネームされたファイルや cp でコピー上書きされたファイルも対象外です。

これは結構重要なので、運用ルールとして頭に入れておきましょう。

対策のヒント：

• ファイルの削除・移動・上書きは事前にコミットしておく
• リスクのある bash 操作の前には手動でコミットを切るよう CLAUDE.md に書いておく
• 「rm の前には必ず確認する」ような Hooks を設定しておく

特にコードベース全体に影響する一括操作（find ... -delete など）は、Checkpoints では救えないので Git でカバーする発想が必要です。

外部からの変更も追跡されない

もう一つ知っておきたい制限です。Claude Code 以外でファイルを変更した場合、その変更も Checkpoints の対象外になります。

具体的には：

• 別のエディタ（VS Code、Neovim など）で直接編集した
• 別の Claude Code セッションを並行で走らせていて、そっちで編集した
• フォーマッタや linter が自動で書き換えた

これらの変更は、現在のセッションが「同じファイルを後から触らない限り」記録されません。マルチセッションで同じファイルを触る運用は、競合のリスクがあるので避けたほうが無難です。

Git との関係：競合ではなく補完

「Checkpoints があれば Git のコミットいらないんじゃ？」と思った方、それは違います。公式ドキュメントもはっきりこう書いています。

Checkpoints are designed for quick, session-level recovery.

Checkpoints は、あくまでセッション単位のクイック undo です。Git は永続的なバージョン管理と協業のための仕組みで、役割が違います。

「Checkpoints は Cmd+Z、Git はファイルシステムのバージョン管理」くらいの感覚で使い分けるとちょうどいいです。Claude にタスクを任せる前にまず git commit しておけば、最悪の場合 git reset で全部戻せるので、Checkpoints と二重で安全網が張れます。

実践 Tips：もっと使いこなすために

Checkpoints の基本が分かったところで、実際の開発で使えるテクニックをいくつか紹介します。

Tip 1: プロンプトを「区切り」として意識する

チェックポイントはプロンプトごとに作られるので、1つのプロンプトに複数のタスクを詰め込みすぎないのがコツです。

たとえば「ログイン機能を実装して、テストを書いて、リファクタリングもして」と一度に頼むと、これらが1つのチェックポイントになってしまい、「テストだけ戻したい」ということができません。

# あまりよくない例（戻せる粒度が粗い）
You: ログイン実装してテスト書いてリファクタリングして

# よりよい例（戻せる粒度が細かい）
You: まずログイン機能を実装して
Claude: 実装しました
You: 次にテストを書いて
Claude: 書きました
You: 最後に重複コードをリファクタリングして

タスクを段階的に分けると、後から「リファクタリングだけやり直したい」といった細かい巻き戻しができるようになります。

Tip 2: 「実験用ブランチ」として使う

新しい設計を試してみたい時、Git でブランチを切るのもいいですが、Checkpoints を使えばもっと軽量に実験できます。

You: このコンポーネントを Server Components で書き直したい。試してみて。
Claude: （実装）
You: うーん、思ってた感じと違うな。Restore code and conversation で戻して、別のアプローチで。

ブランチを切るほどでもない短時間の実験には、Checkpoints のほうがフットワークが軽いです。

Tip 3: 長時間デバッグでは Summarize を活用する

バグの原因を探っていると、つい議論が長くなります。気づくとコンテキストの半分以上が「あれは違った」「これも違った」という試行錯誤で埋まっていることも。

そんな時は、本格的なデバッグに入った地点を選んで Summarize from here を実行します。最初の問題定義や CLAUDE.md の方針はそのまま残しつつ、途中の試行錯誤だけがコンパクトにまとまります。これでコンテキスト枠を節約しながら作業を続けられます。

Tip 4: 「Restore conversation」で結果を残しつつ議論をリセット

繰り返しになりますが、これはすごく便利な使い方なので強調しておきます。ある作業が終わって次のタスクに移る時、コードの結果は残したまま会話だけ戻すと、不要なコンテキストを引きずらずに新しいタスクに集中できます。

よくある質問

Q. チェックポイントはどこに保存されている？

セッションのストレージと一緒にローカルに保存されます。デフォルトでは ~/.claude/projects/<project>/ 配下に置かれ、セッションの一部として管理されます。30日経つとセッションごと自動でクリーンアップされます。

Q. 保持期間は変更できる？

設定で変更可能です。長期保存したい場合は設定値を見直せますが、ローカルストレージを消費するのでバランスを考えて調整してください。

Q. /rewind の操作を取り消したい場合は？

Restore を実行した後でも、もう一度 /rewind を開けばさらに前後のチェックポイントにアクセスできます。Restore そのものをアンドゥするわけではありませんが、別のチェックポイントを選び直せば実質的に「Restore のやり直し」ができます。

Q. チェックポイントと Git のどちらを優先すべき？

両方使うのがベストです。Git は「節目ごとの永続的な記録」、Checkpoints は「セッション内の細かい undo」と役割を分担させましょう。リスクの高い変更を頼む前に必ず git commit しておけば、最強の安全網ができます。

まとめ

Claude Code の Checkpoints 機能をおさらいしておきましょう。

• 自動でファイル変更前の状態を記録してくれる、セッション内の安全網
• 起動は Esc 2回連打、または /rewind コマンド
• 5つのアクション（コード+会話 / 会話のみ / コードのみ / Summarize / キャンセル）を使い分ける
• Summarize from here はピンポイントでコンテキストを圧縮できる強力機能
• bash コマンドによる変更は追跡されない 点に要注意
• Git の代わりではなく補完。両方使って安全網を二重化する

正直、Checkpoints を知る前と知った後では、Claude Code に対する心理的なハードルがガラッと変わります。「失敗してもすぐ戻せる」と分かっていれば、もっと大胆にタスクを任せられるようになるからです。

特に「Restore conversation」と「Summarize from here」は、知っていても使いこなせていない人が多い機能なので、ぜひ次のセッションから試してみてください。一度使うと手放せなくなりますよ。