Claude Code rewindで「AIがやらかした」を元に戻す方法——チェックポイント機能の仕組みと3つの限界
Claude Codeの/rewind・チェックポイント機能でファイルと会話を元に戻す方法を公式ドキュメントベースで解説。Esc2回と3つの復元アクションの違い、rmコマンドで実際に戻らなかった検証、git stashとの使い分けまで実務目線でまとめた。
エンジニアのゆとです。
Claude Codeに「ここ、ついでにリファクタしといて」と頼んだら、動いてたロジックまで巻き込んで壊されたことがある。
そういうとき、Esc を2回押すか /rewind と打てば、直前の状態に戻せる。これがClaude Codeのチェックポイント機能だ。ただ実際に使ってみると、「戻せるもの」と「戻せないもの」の境界が思ったよりシビアだった。この記事では、rewindの仕組みを公式ドキュメントベースで整理したうえで、実際に rm コマンドを実行させて「本当に戻せないのか」を検証し、git併用も含めた実務的な使い分けまでまとめる。
rewind（チェックポイント機能）とは何か
Claude Codeは作業中、ユーザープロンプトを送るたびにコードの状態を自動でスナップショットしている。これがチェックポイントで、/rewind コマンドか、入力欄が空の状態で Esc を2回押すことで、過去のどの時点にでも戻れる。
公式ドキュメントに書かれている仕組みは以下の通り。
- ユーザープロンプトごとに新しいチェックポイントが作成される
- セッション内の最新100個のチェックポイントのファイルスナップショットを保持する
- チェックポイントはセッションと一緒に保存されるので、
--resumeで再開したセッションでも/rewindが使える - セッション終了から30日後に自動でクリーンアップされる（設定可能）
つまり「Ctrl+Zの強化版」というより、「セッションごとのローカルなセーブポイント」に近い。ゲームでいう即席セーブで、Gitのような永続的な履歴管理とは役割が別物だと最初に理解しておくと、後の「戻せなかった」に慌てずに済む。
セッションの再開そのものについては別記事にまとめているので、rewindと合わせて読むとクラッシュ〜復旧の流れが一通り把握できる。
起動方法は2つ
方法1: Escキーを2回連続で押す
一番速い。ただし条件があって、入力欄にテキストが残っている状態でEscを2回押すと、巻き戻しメニューではなく入力テキストのクリアが実行される。クリアされたテキストは入力履歴に残るので、Upキーで呼び出し直せる。
「あれ、メニューが出ない」と詰まったときは、まず入力欄が空になっているか確認するといい。
方法2: /rewind コマンドを直接入力する
入力欄に何か文字が残っている状態でも確実に呼び出せる。急いでいないなら、こちらのほうが誤操作は少ない。
どちらの方法でも、巻き戻しメニューにはセッション中に送信した各プロンプトが時系列で並ぶ。戻りたいポイントを選んでから、次にどのアクションを取るかを選択する流れになる。
3つの復元アクションの違い
巻き戻しメニューで選べるアクションは実質3種類ある。ここを理解せずに適当に選ぶと、コードと会話の状態がズレて余計に混乱するので、最初に整理しておく。
| アクション | コード | 会話履歴 | こんなときに使う |
|---|---|---|---|
| コードと会話を復元 | 戻る | 戻る | 完全にやり直したいとき。基本これが一番事故らない |
| 会話を復元 | 現状維持 | 戻る | ファイルの変更は残しつつ、指示だけ言い直したいとき |
| コードを復元 | 戻る | 現状維持 | Claudeの認識はそのまま、ファイルだけ差し戻したいとき |
「会話を復元」と「コードを復元」は、実は結構危ない。ファイルの実態とClaudeの認識にズレが生まれるからだ。たとえば「コードを復元」でファイルだけ古い状態に戻すと、Claudeは会話履歴上では「新しいコードを書いた」つもりのままなので、次の指示で存在しない変数やファイルを参照しにいくことがある。
体感としては、迷ったら「コードと会話を復元」一択でいい。中途半端な部分復元は、状況を正確に把握できているとき限定の上級者向けオプションだと思っておいたほうが安全だ。
ちなみに巻き戻しメニューには「ここから要約」「ここまで要約」という選択肢もある。これはコードやファイルを一切変えず、会話だけをAIが圧縮するもので、/compact の対象範囲を指定できる版に近い。コンテキストが膨らんできたときの節約手段であって、「元に戻す」とは目的が違う。コンテキスト管理全般は別記事で扱っている。
実際に検証: rmコマンドは本当に戻せないのか
公式ドキュメントには「bashコマンドで変更されたファイルは追跡されない」と明記されている。rm file.txt や mv old.txt new.txt のような操作は、rewindの対象外だという話だ。
これを鵜呑みにせず、実際に手元の検証用リポジトリで試した。
- Claude Codeに「設定ファイル
config.local.jsonを作って」と依頼 → Editツールで作成 - 続けて「不要になったので
rm config.local.jsonで消して」と依頼 → Bashツールで削除実行 /rewindでファイル作成前のチェックポイントまで巻き戻し、「コードと会話を復元」を選択
結果、会話は削除依頼を送る前まで戻ったが、config.local.json は削除されたままだった。ファイルシステム上の rm は、チェックポイントのスナップショット対象に含まれていないので、巻き戻しても復活しない。
同様に、Claudeに直接ファイルを編集させず「ターミナルで mv を実行して」と頼んだケースでも同じ結果になった。Editツールを経由した変更だけが追跡対象で、Bashツール経由の操作はrewindの守備範囲の外にある。
公式ドキュメントが挙げている制限事項は次の3つだ。
- Bashコマンドによる変更は追跡されない（
rm/mv/cpなど） - 現在のセッション外で加えられた変更は追跡されない（手動編集や別セッションからの変更）
- バージョン管理の代替ではない（永続的な履歴管理にはGitが必要）
検証した限り、この記載は正確だった。「AIに何かやらせるときは、ファイル削除やリネームを伴う操作こそ危険」というのが実感で、rewindがあるからと過信して大胆な指示を出すのは危ない。
復旧手段の使い分け
「元に戻したい」ときに使える手段はrewindだけじゃない。むしろ実務では組み合わせて使う場面のほうが多い。
| 手段 | 戻せる範囲 | 保持期間 | こんなときに使う |
|---|---|---|---|
Esc×2 / /rewind | Editツールによるファイル変更＋会話 | セッション終了後30日 | 直前の指示が的外れだった、AIが実装方針を間違えた |
git stash | ワーキングツリー全体（コミット前） | 明示的にdropするまで | 実験的な変更をいったん退避したい |
git reset / git checkout | コミット済みの状態 | Gitの履歴が続く限り恒久 | commitまで進んでしまった変更を取り消したい |
git revert | 特定コミットの変更のみ打ち消し | 恒久 | 履歴を残したまま安全に取り消したい（共有ブランチ向き） |
| OSのゴミ箱 / バックアップ | rm で消えたファイル | ツール依存 | rewindが追跡していないファイル削除の最後の砦 |
判断の目安はシンプルだ。
- まだコミットしていない、直前のAIの作業をやり直したいだけ → rewindで十分
- Bashコマンドでファイルが消えた・移動した → rewindは効かない。Gitで管理されているファイルなら
git checkoutで復元、管理外ならOSのバックアップやゴミ箱を確認する - すでにcommitまで進んでしまった → rewindの対象外。
git resetかgit revertの出番 - 複数のアプローチを比較したい（元の状態は壊したくない） → rewindより
fork（claude --continue --fork-session）が向いている。rewindは「巻き戻し」、forkは「枝分かれ」で目的が違う
エラー発生時の他の復旧パターン（セッションクラッシュ、無限ループ、permission暴走など）は別記事で7パターンに分けて整理してある。rewindが効くのは「AIの直接編集を戻したい」ケースに限られるので、それ以外の詰まりはこちらを参照してほしい。
フリーランス視点: rewindに頼らないgit運用
ここまで見てきた通り、rewindは便利だけど「セッション内のローカルな取り消し」でしかない。クライアント案件のリポジトリを触っているときに、rewindだけを頼りにするのは正直リスクが高い。
自分が実務でやっているのは次の3つだ。
- AIに大きめのタスクを渡す前に、必ず一度commitしておく。rewindが効かなかったときの最終防衛ラインをGitに置く
.claude/hooksでファイル編集のたびにgit stash pushする簡易チェックポイントを仕込んでおく（rewindがカバーしないBash経由の変更にも一定効く）。仕組みは上記のエラー復旧記事にコード付きで載せている- rmやmvを伴う操作をAIに任せるときは、事前に「本当に消していいか確認してから実行して」とCLAUDE.mdか都度の指示で明示する。rewindで戻せない操作だと理解した上で、そもそも事故らせない方向に倒す
rewindは「気軽に大胆な変更を試せる」という体験を大きく変えてくれる機能だけど、それとGit運用の手を抜いていい理由は別だ。チェックポイントは30日で消えるし、Bashコマンドの変更は最初から対象外。公式ドキュメントも「チェックポイントを『ローカル取り消し』、Gitを『永続履歴』と考えてください」とはっきり書いている。両方使うのが前提の機能だと捉えたほうがいい。
よくある詰まり
Q. /rewind と打っても「no matching commands」と出る
バージョンが古い可能性がある。チェックポイント機能はある時点以降のバージョンで追加された機能なので、claude --version で確認し、古ければアップデートする。
Q. Esc×2でメニューが開かず、入力テキストが消えるだけ
入力欄に文字が残っている状態だと、Escダブルタップは巻き戻しメニューではなくテキストクリアとして扱われる仕様。入力欄を空にしてから試すか、/rewind を直接打つ。
Q. /clear した後の会話には戻れない？
戻れる。同じClaude Codeプロセス内で /clear を実行していた場合、巻き戻しメニューの最上部に「/resume <session-id>（前のセッション）」という項目が追加で表示される。これを選ぶと /clear 前の会話を再開できる。ただしこの挙動には一定以上のバージョンが必要で、それより古いバージョンでは手動で /resume からセッションを選ぶ必要がある。
Q. VS Code拡張でもrewindは使える？
VS Code拡張機能でも同様にチェックポイントの仕組みが使われている。拡張機能はセッションdiffのベースラインとして最初のスナップショットを利用する設計になっている。CLIと基本的な考え方は共通だが、UI上の操作感は多少異なるので、拡張機能側のドキュメントも確認しておくと安心だ。
まとめ
rewindは「AIがやらかした」を数秒で取り消せる、体感的にかなり心強い機能だ。ただし過信は禁物で、実際に検証した限り以下は押さえておく必要がある。
- Editツールでの変更と会話履歴は戻せる。Bashコマンド経由の
rm/mv/cpは戻せない - 3つの復元アクション（コードと会話／会話のみ／コードのみ）は、迷ったら「コードと会話を復元」が事故りにくい
- チェックポイントは30日で自動削除される、セッション限定のローカルな仕組み
- 恒久的な履歴管理としてGitを手放していい理由にはならない。むしろ大きめのタスクの前にcommitする習慣とセットで使うのが実務的
rewindだけに頼るのではなく、Gitの安全網と組み合わせて初めて「大胆に試せる」状態が作れる。そのあたりの前提を持っておくと、次に何かやらかしたときも慌てずに済むはずだ。
