やりがちなのは、Claude Code が変な方向に進んだのに、そのまま修正させ続けることだ。これ、たいてい泥沼になる。少し直したつもりが別のファイルまで触られ、diff が膨らみ、どこから壊れたのか分からなくなる。そんなときは、粘るより一度捨てたほうが早い。
Claude Code は CLI の作業エージェントなので、手元のファイルを実際に書き換える。つまり、間違えたときに大事なのは「どう直すか」より「どこまでを無かったことにするか」だ。ここを間違えると、コンテキストも時間も無駄に食う。筆者も最初は、ズレた指示のまま会話を続けて手戻りした。結局、途中成果を捨ててやり直したほうが速かった、という場面がかなり多い。
いちばん手堅いのは、まず差分を確認して、必要なら作業ツリーをそのまま戻すことだ。Git を使っているなら話は早い。Claude Code に触らせる前にコミットしておけば、戻す先がはっきりする。これだけで事故率がかなり下がる。
git status
git diff
git restore .
git restore . は、未コミットの変更を作業ディレクトリから捨てる。特定のファイルだけ戻したいなら、ファイル名を絞ればいい。
git restore path/to/file.md
git restore path/to/script.py
Git 管理下にないファイルまで含めて一気に片付けたいなら、git clean を使う。ただしこれは雑に強い。消したら戻せないので、まずは何が消えるかを見る。
git clean -nfd
-n は実行せずに確認するためのものだ。内容に納得したら、ようやく本番になる。
git clean -fd
ここで大事なのは、Claude Code に「直して」ではなく、いったん「この変更を捨てて」と指示することだ。会話の流れに引きずられて、壊れた案を延命させるとろくなことにならない。
たとえば、こんなふうに頼む。
いまの変更は捨てて、最初からやり直したいです。
この作業ディレクトリで未コミットの変更を確認して、不要なものは戻してください。
そのうえで、改めて次の条件だけで作業してください。
- 変更対象は docs/ 配下のみ
- 既存の文体は崩さない
- 変更前に、何を消して何を残すかを短く説明する
この頼み方のいいところは、Claude Code に「リセットの対象」と「再開条件」を分けて伝えられる点だ。何でもかんでも一気にやらせると、また別の失敗を呼ぶ。
Git を使っていないなら、話は少し単純で少し面倒だ。作業前にコピーを取っておくしかない。特に文書整理やファイル整理で Claude Code を使うなら、元のフォルダを丸ごと残すのがいちばん安全だ。たとえば案件フォルダを扱うなら、こうしておく。
cp -a project project.backup
あるいは、作業先を複製してから Claude Code を走らせる。非エンジニアならこのやり方のほうが分かりやすい。元の資料はそのまま、Claude Code は複製側だけ触る。間違えたら複製を捨てればいい。戻し先を覚える必要がない。
もし既に壊したあとなら、バックアップから戻す。
rm -rf project
mv project.backup project
もちろん、rm -rf は雑に危ない。コマンドが怖いなら、ファイルマネージャでフォルダごと入れ替えたほうがいい。大事なのは「壊れた結果を上書きしない」ことだ。
Claude Code で手戻りが起きやすいのは、指示があいまいなときだ。たとえば「見やすくして」「いい感じにまとめて」は、ほぼ事故の招待状である。修正量が増え、どこを直したのかも曖昧になる。こういうときは、いったん戻してから、条件を細かく切ってやり直す。
いったん変更を破棄してください。
次はこの順で進めてください。
1. 変更対象のファイルを列挙する
2. 変更方針を一度だけ説明する
3. 1 ファイルずつ差分を小さく出す
4. 途中で勝手に別ファイルを触らない
これで、勝手に広がる変更をかなり抑えられる。
もうひとつ、戻す前に見ておきたいのが差分だ。Claude Code のミスは、全部が壊滅というより「一部だけ余計なことをした」ケースが多い。だから、すぐ全消しする前に git diff で眺める癖をつけるといい。筆者は、要約文だけ直してほしいのに別見出しまで書き換えられ、後で「ここは触るな」と明示する羽目になったことがある。あの手の手戻りは、最初に差分を見ていれば避けられた。
git diff -- docs/
差分が大きすぎるなら、そこですでに負けている。細かく直させるより、捨ててやり直したほうが早い。
そして、やり直す前に一つだけ習慣を入れておくと強い。作業開始前にコミットすることだ。大げさに聞こえるが、Claude Code との相性はいい。ひと区切りごとにコミットしておけば、間違えたときに戻る先が明確になる。たとえばこんな感じで十分だ。
git add .
git commit -m "before claude code edit"
この一手間があるだけで、「どこまで捨てるか」を悩む時間が消える。後から git log で戻せるのは、かなり気持ちがいい。
最後に、実務で覚えておくといい線引きを書いておく。戻し方が分からないなら、まず会話を続けるな。先に現物を保護しろ。 Git なら restore、非 Git ならコピー保管。Claude Code に「とりあえず直して」と押し切らせると、修正の修正が始まる。そこからの回復は遅い。
作業を捨てるのは敗北ではない。壊れた案にしがみつかないための、いちばん実務的な判断だ。Claude Code を使うほど、この切り替えは速いほうがいい。戻す、確認する、やり直す。これだけでかなり事故は減る。