Claude Codeにファイルの変更を頼んで、後から「やっぱり元に戻したい」と思ったことはないだろうか。チェックポイント機能は、そんな時に自動で残っているセーブポイントのようなものだ。この記事では、チェックポイントがいつ作られるのか、どう巻き戻すのか、どこからGitなどの対策が必要になるのかを順番に見ていく。

チェックポイント機能とは — 一言でいうと

チェックポイントとは、Claude Codeがユーザーのプロンプト（メッセージ）ごとに自動で作成する、ファイル変更のセーブポイントだ。

ゲームで言えば、ステージの始まりに自動セーブが入る仕組みに近い。Claude Codeに何かを頼むたびに、その直前のファイル状態がそっくりそのまま記録される。後で「やっぱりあの時の状態に戻したい」と思ったら、そのチェックポイントを指定して巻き戻せる。

各チェックポイントには checkpoint UUID という一意の識別子が付いている。どのプロンプトで作られた記録かが一目で分かる仕組みだ。追跡の対象になるのは、Claude Codeが Write、Edit、NotebookEdit の3つのツールを使って行った変更のみ。つまり、Claude Code経由でファイルを書き換えた分は自動で記録される。

チェックポイントが自動で作られる仕組み

仕組み自体はシンプルだ。ユーザーがClaude Codeにメッセージを送るたびに、自動で1つのチェックポイントが作られる。

具体的には、メッセージを送った時点でのファイルの状態がバックアップされ、そこにcheckpoint UUIDが割り当てられる。Claude Codeがそのメッセージに応じてファイルを変更したあとでも、変更前の状態はチェックポイントとして残っている。つまり、何かを頼む前の状態が常に保存されている。

追跡の対象になるのは次の3つのツールによる変更だ。

この表の最後の行にだけ注意が必要だ。Bashツール経由でファイルを変更した場合、その変更はチェックポイントの追跡対象外になる。詳しい対策は後で触れるとして、まずは「Claude Codeが直接ファイルを操作した分は自動で記録される」と押さえておけばいい。

巻き戻し（rewind）の操作方法

巻き戻しには、CLI上で2つの方法が用意されている。

Esc キーを2回押す または /rewind コマンド

どちらの操作でも、巻き戻し用のメニュー（rewind menu）が開く。メニューにはこれまでのプロンプトごとの履歴が表示されるので、戻りたい地点を選択する。選んだ後は、次のアクションから目的に合うものを選ぶ。

• Restore code and conversation — ファイルと会話の両方をその時点に戻す
• Restore code — ファイルだけを戻す（会話はそのまま）
• Restore conversation — 会話だけを戻す（ファイルはそのまま）
• Summarize from here — 選んだ地点以降の会話を要約に圧縮する（コンテキストを空ける用途）

直前の変更を取り消すなら「Restore code」を選ぶのが一番手軽だ。「やっぱり今の変更は取り消したい」と思ったら、まずは Esc を2回押して rewind menu を開いてみる。

数回前の変更まで遡りたい場合や、特定のタイミングの状態に戻したい場合も、同じ rewind menu から該当するプロンプトを選択できる。

Windows環境では、ターミナル上でClaude Codeを動かしている状態でそのまま操作できる。特別な設定は不要だ。

戻せない変更とその対策

セクション2の表で触れた通り、コマンド実行（Bash）経由の変更はチェックポイントの追跡対象外だ。では、コマンド実行経由で変更してしまった時はどうすればいいのか。対策を3つ挙げる。

Gitを併用する

一番手堅い対策は、プロジェクトをGitで管理しておくことだ。git stash で変更を退避させたり、git checkout で特定のファイルを元に戻したりできる。Bash経由の変更であっても、Git管理下にあれば巻き戻しが可能になる。「Claude CodeのチェックポイントとGitの両方で保険をかける」という構成だ。

Bash経由の変更を避けて、Write/Editで依頼し直す

Claude Codeに変更を頼む時に、Bash経由ではなく、WriteやEditで依頼し直すことで、その変更はチェックポイントの追跡対象になる。最初から追跡対象のツールで依頼しておけば、後でEsc2回で戻せる。

失敗しやすいポイント

気をつけたいのは、del や Remove-Item などのコマンド実行経由でファイルを削除した場合だ。チェックポイントでは復元できないし、Git管理下でなければ元に戻す手段がない。Bash経由での削除操作は、実行前に一度立ち止まって確認する習慣をつけておくと安心だ。

また、手動でエディタからファイルを編集した場合も、その変更はチェックポイントの追跡対象外になる。Claude Code経由の変更と自分の手動編集が混在すると、「どの変更が戻せてどれが戻せないか」が分かりにくくなるので、できれば変更を依頼する単位を区切っておく方が管理しやすい。

混同しやすい機能との違い

Claude Codeには巻き戻し以外にも「操作を取り消す」系の機能がいくつかあり、初心者のうちは混同しやすい。3つの機能を比べてみる。

/undo は環境やバージョンによって扱いが異なる可能性があるため、初心者はまず /rewind または Esc 2回を使うのが安全だ。「会話の流れを取り消す」か「ファイルの状態を復元する」かの違いがある。

Gitとの違いは、記録のタイミングにある。Gitは明示的なコミット単位で記録するのに対して、チェックポイントはプロンプト単位で自動記録する。コミットを忘れても、プロンプトを送っていればチェックポイントは残っている。

実務的には、次のような棲み分けが分かりやすい。

• Claude Code経由の変更 → チェックポイント（/rewind、Esc2回）で対応
• 手動編集やBash経由の変更 → Gitで対応

両方を併用しておけば、大抵の「元に戻したい」に対応できる。

SDKからチェックポイントを使う

Agent SDKを使ってClaude Codeをプログラムから操作している場合、チェックポイント機能を有効にして利用できる。

有効化は簡単だ。ClaudeAgentOptions で enable_file_checkpointing を True に設定するだけ。

from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions

options = ClaudeAgentOptions(
    enable_file_checkpointing=True,
)

有効にしておくと、各プロンプトの処理後にcheckpoint UUIDが記録される。このUUIDを取得しておけば、後からセッションを再開して rewind_files() を呼び出し、ファイルを巻き戻せる。詳しい手順は公式ドキュメントのAgent SDK「Rewind file changes with checkpointing」ページを参照されたい。

SDK経由でチェックポイントを使う場合、気をつけたい点が2つある。1つは、CLIと同じく追跡対象がWrite・Edit・NotebookEditのみであること。もう1つは、チェックポイントの履歴はセッションと共に30日後に自動クリーンアップされることだ（期間は設定で変更可能）。長時間のセッションで大量にチェックポイントが作られる場合は、こまめに確認しておく方が安心だ。

SDKを使わないCLI利用が中心であれば、このセクションは読み飛ばしても問題ない。

まとめ — 変更を頼むのが怖くなくなる

チェックポイント機能の本質は、「変更前の状態が自動で残るので、『やっぱり元に戻したい』が怖くなくなる」という点にある。

押さえておくべき境界線は1本だけだ。Claude Code経由の変更（Write・Edit・NotebookEdit）はチェックポイントで戻しやすい。一方、コマンド実行経由の変更は別対策（Git等）が必要になる。この線だけ押さえておけば、どこまでチェックポイントに任せられるか判断しやすい。

巻き戻しの操作も難しくない。直前の変更を取り消すなら Esc を2回。過去の特定地点に戻るなら /rewind コマンド。この2つを覚えておけば、実務上は十分に対応できる。

もしBash経由の変更も含めて安心したいなら、プロジェクトをGit管理下に置いておくのがおすすめだ。チェックポイントとGitの二重の保険がかかるので、大抵の「戻したい」に対応できる。