Claude Codeに大きめの変更を任せる時、私は今でも少し身構えます。
「このファイル群をまとめて整理して」「この設計で一回実装してみて」と頼むのは便利です。ただ、便利な分だけ、思っていた方向と違うところまで進んでしまうことがあります。
そういう時に効くのがCheckpointと/rewindです。
これ、意外と使えます。というより、AIエージェントに強めの変更を任せるなら、先に知っておいた方がいい機能だと思います。
毎回コミットする前の「仮の戻し先」がある
Claude CodeのCheckpointは、Claudeがファイルを編集する前の状態を自動で記録してくれる仕組みです。
公式ドキュメントでは、各ユーザープロンプトがチェックポイントになり、Escを2回押すか/rewindを実行すると巻き戻しメニューを開ける、と説明されています。
/rewind
メニューでは、だいたい次のような戻し方を選べます。
- コードと会話の両方を戻す
- 会話だけ戻す
- コードだけ戻す
- 途中から要約してコンテキストを軽くする
- 途中まで要約して、直近のやり取りだけ残す
単なるundoではなく、「会話」と「コード」を分けて扱えるのが良いところです。
たとえば、実装は失敗したけど調査の会話は残したい時があります。逆に、会話ごと前の指示に戻って、言い方を変えてやり直したい時もあります。
その切り分けができるのは超便利です。
以前書いた/diffパネルの話とも相性が良いです。差分を見ながら進めて、方向が違ったら/rewindで戻す。変更を眺める場所と、戻す場所が分かれている感じです。
危ない変更を試す腰が軽くなる
Gitのcommitを細かく切れば戻れます。これは今でも大事です。
ただ、AIに試行錯誤させている最中は、commitにするほどでもない変更が連続します。
「一回この構成で分けてみて」
「やっぱりその抽象化は大げさかも」
「元の形に近いまま重複だけ減らして」
こういう往復を全部commitで管理しようとすると、ちょっと重いです。
Checkpointがあると、「まず試してみて、違ったら戻す」で進めやすくなります。これはかなり大きいです。
特に、Claude Codeに複数ファイルを触らせる時は効きます。最初から完璧な設計を言語化できなくても、試してから戻せる。AIとの作業は、この心理的な軽さでかなり変わります。
でもBashで変えたものは戻りません
ここからが本番です。
Checkpointを「全部戻せる魔法」と思うと危ないです。公式ドキュメントにも明記されていますが、Bashコマンドで変更されたファイルはCheckpointの対象外です。
rm file.txt
mv old.txt new.txt
cp source.txt dest.txt
こういう操作は/rewindでは戻せません。
Claude CodeのWrite/Edit系ツールで編集されたファイルは追跡されますが、シェルで実行した副作用までは追いかけてくれない、という理解で大丈夫です。
ここを勘違いすると事故ります。
たとえば、マイグレーションを実行した、外部APIを叩いた、デプロイした、ファイルをシェルで削除した。こういうものはCheckpointではなく、別の安全策が必要です。
Gitの代わりではなく、Gitの手前に置くもの
CheckpointはGitの代替ではありません。
これはかなりはっきり言っておいた方がいいです。
Gitは長期の履歴です。チームで共有する履歴でもあります。後からなぜその変更を入れたのかを追うためのものです。
Checkpointはセッション内の安全網です。手元で試行錯誤している間の、すぐ戻るための保険です。
なので私の感覚では、役割はこうです。
- 作業中の試行錯誤: Checkpoint /
/rewind - 意味のある区切り: Git commit
- 他人や本番に影響する操作: 事前確認とログ
この3つをごちゃまぜにしない方が安全です。
「Checkpointがあるからcommitしなくていい」ではありません。「commitする前の試行錯誤が楽になる」が正しいです。
無人実行や自動承認の話ともここはつながります。–permission-prompts noneやauto modeは、止まらず進めるための仕組みです。一方でCheckpointは、進めた後に戻るための仕組みです。
進める力と戻る力。両方ないと、AIエージェントの運用は怖くなります。
エラー復旧にも使える
公式のError referenceにも、会話履歴のツール呼び出し順序が壊れた時は/rewindで壊れる前のCheckpointへ戻る、という案内があります。
AIエージェントは、ツール呼び出し、結果、思考ブロックの順序が崩れると、続きの会話自体が変な状態になることがあります。
その場で「さっきの続きで直して」と言いたくなるのですが、壊れた履歴の上にさらに会話を積むと、もっとややこしくなることがあります。
そんな時は、修正を積むより巻き戻した方が速いです。
/rewind
巻き戻して、壊れる前の地点から言い方を変えて再実行する。これでいけることがあります。
これはコードの話だけではありません。プロンプトの言い方を間違えた時にも効きます。
AIに伝えた条件が曖昧で、途中から「いや、そうじゃないんだよな」となることがあります。そこで長々と補足するより、ひとつ前に戻って最初の指示を書き直す方がきれいです。
間違った流れの上に補足を重ねるより、分岐点まで戻る。これだけで会話がかなりまっすぐになります。
私ならこう使います
私が普段使うなら、次のように分けます。
- 軽い文章修正や小さな関数の修正なら、そのまま任せる
- 複数ファイルにまたがる変更なら、まずCheckpointが効く前提で試す
- Bashで削除・移動・生成を伴う作業なら、先に
git statusやバックアップを確認する - 外部サービスや本番に触る作業は、Checkpointに期待しない
雑に言うと、「ClaudeのEditで触るものは戻しやすい。シェルや外部に出たものは戻らない」です。
これだけ覚えておけば、かなり事故を減らせます。
もう少し具体的に言うと、私はこういう指示の前に/rewindを意識します。
この重複している処理を共通化して
このコンポーネントを分割して
この設定ファイルを今の運用に合わせて整理して
この原稿の構成を変えて読みやすくして
どれも便利ですが、やりすぎると元の良さが消えるタイプの作業です。だから戻れる前提で試すのが合っています。
逆に、次のような指示ではCheckpointに期待しません。
このコマンドで生成物を全部作り直して
本番へデプロイして
外部サービスの設定を変更して
不要ファイルをrmで削除して
ここは別枠です。事前に差分を見たり、バックアップを取ったり、人間が止めるポイントを作ったりします。
戻れる範囲を知っておくと強い
Claude CodeのCheckpointと/rewindは、AIに大きめの変更を任せる時の保険です。
毎回完璧な指示を書けなくても、一回試して、違ったら戻せます。会話だけ戻す、コードだけ戻す、両方戻す、という選び方もできます。
ただし、Bashで変えたものや外部への副作用は戻りません。Gitの代わりにもなりません。
ここを分けて使えると、AIエージェントとの作業はかなり楽になります。危ない変更を怖がって何も試さないより、戻れる範囲を知ったうえで小さく試す方が速いです。
というわけで、次にClaude Codeへ少し大きな変更を頼む時は、先に/rewindの場所だけ確認しておくと良いと思います。簡単ですね。
参考:
コメント