前章で「修正ループから抜ける」一手として /rewind を予告した。本章では、それを含めた戻すための仕組みを整理する。/rewind でできること、できないこと、そして最後に頼るべき git の位置づけを扱う。

チェックポイントの基本

Claude Code は、こちらが何かを頼むたびに 直前のコード状態を自動でスナップショットしている。これがチェックポイントである。

  • ユーザープロンプトごとに 1 つ作られる
  • セッション間で残る (デフォルトで 30 日後に自動クリーンアップ、設定可能)
  • セッションを閉じても、後で戻ってきてアクセスできる

つまり、Claude に何か危険なことを頼んでも、「あのプロンプトを送る前」に戻れるセーフティネットが裏で動いている、と捉えてよい。

/rewind の選択肢

Esc を 2 回連打、もしくは /rewind でメニューが開く。スクロール可能なリストにこれまでのプロンプトが並んでいて、戻りたい地点を選んでからアクションを選ぶ。

選べるアクションは 5 つ:

  • コードと会話を復元 ─ 両方をその時点に戻す。完全な巻き戻し
  • 会話を復元 ─ コードはそのままに、会話だけ戻す。「実装は活かしつつ会話の方向性を変えたい」時
  • コードを復元 ─ 会話はそのままに、コードだけ戻す。前章で扱った修正ループからの脱出に効く
  • ここから要約 ─ 選んだ地点以降の会話を圧縮する。/compact のターゲット版
  • キャンセル ─ 何もせず戻る

復元・要約後は、選んだ地点の元のプロンプトが入力欄に復元されるので、編集して送り直すことができる。

特にコードを復元 は強力で、「会話で得た知見 (どこが原因か、何を試したか) は手元に残しつつ、Claude が書いた実装だけ消して別アプローチに切り替える」ことができる。

何が追跡されないか

/rewind は便利だが、追跡対象には重要な穴がある。

Bash コマンドの変更は追跡されない

Claude が bash で実行したファイル操作 ── rm、mv、cp、> file のリダイレクト、sed -i など ── は、チェックポイントの対象外である。

# Claude がこれを実行した場合
rm src/legacy.ts
mv old.config.json config.json

こうした変更は /rewind で戻せない。Claude のファイル編集ツール (Edit / Write) を通じた変更だけが対象である。

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

別ターミナルから手で書いた編集、別の Claude Code セッションでの編集、ビルドツールが書き換えた成果物 ── これらも対象外である。「Claude Code が知っているのは、自分のセッション内で自分のツールが触ったものだけ」と覚えておく。

git という最後の砦

/rewind の限界が見えてくると、自然と git の出番がはっきりする。チェックポイントは「ローカル取り消し」、git は「永続履歴」 ── 公式ドキュメントの言い回しが端的にこの差を表している。

チェックポイント (/rewind)git
対象Claude のファイル編集のみあらゆる変更 (bash 含む)
寿命デフォルト 30 日永続 (明示削除されるまで)
共有ローカルセッション内のみリモートに push すれば誰とでも
粒度プロンプトごとコミット単位 (自分で決める)

Claude を使う時の実用的な作法として、危険な変更の前に git でコミットを切っておくのが効く。リファクタ、削除、移行、認証周りの変更 ─ こうした「失敗が痛い」操作の前に一度コミットしておけば、/rewind が届かない種類の事故からも戻れる。

git add -A && git commit -m "before refactor: working state"

このコミットはこちらが意図的に切った安定点で、Claude が勝手に書き換えることはない (force push のような破壊的操作を明示的に頼まない限り)。手元の安全を一番強く保証するのは、結局のところ git である。

ここまで「失敗からの回復」を三本の記事で扱ってきた。次章では実践の最後として、メインの会話を圧迫せずに大きな調査を回す手段 ── サブエージェントへの委譲を扱う。

参考情報