Claude Codeのチェックポイントは、Claudeがファイルを編集する前の状態を自動保存しておき、/rewindでそこへ戻せる機能です。結論を先に言うと、これは「何でも戻せるアンドゥ」ではありません。**戻るのはClaudeが編集したファイルと会話だけで、bashコマンドの副作用は戻りません。**この境界を知らないまま「戻れるから大丈夫」と使うと、いちばん戻したいものが戻らない場面で気づくことになります。
この記事では、チェックポイントが何を保存して何を保存しないか、/rewindの操作、gitとの住み分け、そしてプランモードや権限設定との役割分担を、公式ドキュメントをベースに整理します。私の運用判断は判断として明示して書きます。
チェックポイントとは——編集のたびに自動で取られるセーブポイント
チェックポイントはClaude Code 2.0で入った機能で、公式の発表では「より大胆にエージェントへ任せるための仕組み」として位置づけられています。動きはシンプルです。
- Claudeがファイルを編集する直前に、コードの状態が自動保存される。ユーザーの操作は不要
- 保存された地点へは、Escキーの2回押し、または
/rewindコマンドでいつでも戻れる - 戻すときは「会話だけ」「コードだけ」「両方」を選べる
「会話だけ戻す」が意外と使いどころが多い、というのが使い方の最初のポイントです。指示の出し方を失敗したとき、コードはそのままに会話だけ巻き戻してプロンプトを書き直せます。逆に「コードだけ戻す」は、実装は気に入らないが文脈は維持したいとき。つまりチェックポイントは失敗の復旧装置というより、プロンプトと実装を別々にやり直せる装置です。
戻れないものを先に覚える
ここが本題です。チェックポイントが追跡するのはClaudeがファイル編集ツールで書き換えた内容であり、それ以外は対象外です。公式ドキュメントが明示している制限を並べます。
- bashコマンドの副作用は戻らない。Claudeが
rmで消したファイル、npm installで書き換わった依存、実行されたDBマイグレーション、pushしてしまったコミット。これらは/rewindの対象外です - 自分の手で編集した変更も追跡されない。エディタで直した分は、チェックポイントに戻しても復元されません
- gitの代替ではない。公式ドキュメント自身が、恒久的な履歴にはバージョン管理を使うよう明記しています
「戻れるからアンドゥだ」というメンタルモデルで使うと、この3つ全部を踏みます。特にbashの副作用は要注意で、Claude Codeの作業は「ファイル編集」と「コマンド実行」が混ざって進むのに、巻き戻せるのは前者だけ。エージェントの作業ログを見て「どこまでが編集で、どこからがコマンドだったか」を意識する癖がつくと、この機能は急に信頼できるようになります。
gitとの住み分け——時間軸が違う
「gitがあればいらないのでは」という疑問には、時間軸で答えるのが分かりやすいです。
| チェックポイント | git | |
|---|---|---|
| 粒度 | Claudeの編集1回ごと（自動） | コミット1回ごと（自分で切る） |
| 守備範囲 | セッション内の試行錯誤 | 恒久的な履歴・共有 |
| 戻せるもの | Claudeの編集＋会話 | コミット済みの全ファイル |
| 操作 | Esc 2回 / /rewind | checkout / reset / revert |
コミットを「試行のたび」に切ることは、まずしません。かといってエージェントに30分任せた結果が気に入らないとき、コミット単位でしか戻れないのは粗すぎます。チェックポイントはこの隙間、「コミットする価値がまだ分からない試行」の単位を埋めるものです。
私の使い分けはこうしています。大きめの作業をエージェントに任せる前にコミットを1つ切って恒久的な戻り先を作り、任せている間の細かいやり直しはチェックポイントに任せる。うまくいったらコミット、駄目ならgit checkout .でコミットまで戻る。チェックポイントがあってもこの「作業前コミット」はやめていません。bashの副作用まで含めて戻れる保険は、結局gitのほうだからです。
「事前に縛る」と「事後に戻す」の2方向で考える
チェックポイントの位置づけは、Claude Codeの他の安全機構と並べるとはっきりします。エージェントに任せるときの制御は、大きく2方向あります。
事前に縛る: プランモードで実装前に計画をレビューする、権限設定で触れる範囲を絞る。実行される前に事故を防ぐ側です。
Claude Codeのプランモード使い方｜編集させる前に計画をレビューするClaude Codeのプランモード（Plan Mode）の使い方を公式ドキュメントベースで整理します。Shift+Tabでの切り替え、--permission-mode planや設定での固定、読み取り専用で計画を提案させてから実行へ移す流れ、権限設定・hooksとの役割分担までをまとめます。www.tentspace.net
事後に戻す: チェックポイントで、実行された結果を巻き戻す。事故ってから回復する側です。
この2つはトレードオフの関係にあります。事前の縛りを厳しくするほど安全ですが、承認のたびに人間が張り付くことになる。事後に戻せる範囲が広いほど、事前の縛りを緩めて大胆に任せられる。チェックポイントが「自律的に任せるための機能」として発表されたのはこの文脈で、戻れる保証があるから、editの自動承認を許す判断ができるわけです。
ただし前段で見たとおり、事後に戻せるのはファイル編集だけです。だからbashコマンドに対しては事前の縛り（権限設定やhooks）が引き続き必要になります。「編集はチェックポイントで事後回復、コマンドは権限で事前制御」。この非対称な組み合わせが、現状の実用的な落としどころだと考えています。
Claude Codeの権限設定4層ガイド｜denyを厚くするだけでは守れないClaude Codeの権限設定を「渡さない・許す・止める・外側で強制」の4層で設計する方法を解説します。allowルールのワイルドカード警告や--restrictedフラグなど直近の公式アップデートを根拠に、hooksによる禁止だけでは塞げない穴と、各層の使い分けを実運用の構成で整理します。www.tentspace.net
定時実行・ヘッドレスでは頼れない
もうひとつ、運用側の注意です。/rewindもEsc 2回も対話セッションの操作なので、claude -pによるヘッドレス実行や定時実行の自動運用では、チェックポイントを回復手段として当てにできません。人間がその場にいて「気に入らないから戻す」と判断することが前提の機能です。
無人で回すワークフローの安全は、これまでどおり権限設定・hooks・書き込み先の分離で作ることになります。チェックポイントが効くのは、人間が並走する対話開発の側。同じClaude Codeでも、対話と無人ではリスク管理の道具立てが別物になる、と整理しておくと設計を間違えません。
まとめ——「戻れる範囲」がそのまま任せ方の設計図になる
チェックポイントの要点を並べ直します。
- Claudeの編集前に自動保存され、Esc 2回か
/rewindで「会話・コード・両方」を選んで戻せる - 戻るのはClaudeのファイル編集だけ。bashの副作用と自分の手の編集は戻らない
- gitの代替ではなく、「コミット未満の試行」を刻む単位。作業前コミットとの併用が前提
- 事前に縛るプランモード・権限設定と、事後に戻すチェックポイントの組み合わせで、任せる度合いを調整する
- 対話専用の機能なので、無人運用の安全設計には数えない
「どこまで戻れるか」を正確に知っていると、逆説的に、戻れない操作の手前だけ慎重になって、それ以外は思い切って任せられるようになります。チェックポイントは巻き戻しの機能ですが、実際に変わるのは前に進む速度のほうです。