Claude Code が変な方向に進んだとき、いちばん危ないのは「少し直せば戻るだろう」と粘ることだ。そこから先は、直すための指示がさらに増えて、コンテキストも汚れて、結局もっと面倒になる。
この手の CLI コーディングエージェントは、雑に言えば「今ある作業状態」を読んで次を決める。だから、間違えたときは作業を抱えたまま修正会議を続けるより、いったん捨てて、まっさらな状態でやり直したほうが早い場面が多い。
筆者も最初はこれで何度かやらかした。小さな修正のつもりで指示を重ねたら、diff が妙に広がって、元の意図から外れた変更まで混ざる。あとから人間が見て「これはどこから来た？」となるやつだ。
なのでこの話では、Claude Code が迷走したときに何を捨て、何を残し、どうやって再出発するかを、実務寄りに整理する。
まず押さえるべきなのは、戻し方は1つではないという点だ。
すでにファイルを書き換えたあとなら Git で戻す。まだファイルを触っていないなら、セッションを切って、依頼文を作り直す。途中までの成果に価値がないなら、未練なく捨てる。ここを曖昧にすると、いつまでも半端な状態が残る。
作業ディレクトリが Git 管理されているなら、これが最優先になる。Claude Code が余計なファイルをいじった、意図しない編集をした、途中までの差分がもう信用できない。そんなときは、人力で1行ずつ戻すより、Git の状態に戻したほうが速い。
たとえば、直前の変更をすべて捨てて、最後にコミットした状態へ戻すならこうする。
git status
git restore .
git restore . は、追跡されているファイルの変更をまとめて捨てる。
ただし、未追跡ファイルまで消えるわけではない。Claude Code が新しいファイルを大量に作ってしまった場合は別の処理が必要になる。
未追跡ファイルも含めて「この作業の成果を全部捨てる」なら、次を使う。
git clean -fd
-f は強制、-d はディレクトリも対象という意味だ。これで、Git が管理していない不要ファイルやフォルダを消せる。
ただし、これはかなり強い。必要なメモや一時ファイルまで巻き込むと面倒なので、実行前に git clean -fdn で予行演習するのが安全だ。
git clean -fdn
-n は実際には消さず、消える対象だけ表示する。Claude Code に任せた作業が増えすぎたときは、この確認を挟む癖をつけておくと痛い目を見にくい。
Claude Code の返答がもう信用できないとき、同じ会話の流れに指示を足しても泥沼になりやすい。
理由は単純で、モデルはそれまでの指示や失敗を全部読んだうえで答えるからだ。間違った前提が会話に残っていると、次の指示もその前提に引きずられる。
この場合は、作業を一度止める。
そして、必要なら新しいセッションで、短く、はっきりした依頼文を出し直す。
たとえば、文書整理でこんなふうに頼み直す。
一度ここまでの変更案は捨ててください。
対象は report/ 配下だけです。
README.md は触らず、重複している下書きファイルの候補だけ整理してください。
削除候補はまず一覧を出して、勝手に消さないでください。
ここで大事なのは、「全部やり直して」と言うだけで終わらせないことだ。
何を対象にするか、何を触らないか、削除前に確認が必要か。この3点がないと、Claude Code は平気で広く触る。広く触らせると、戻す側がだるい。
何でもかんでも破棄すればいいわけではない。
たとえば、Claude Code が下書きの整理や要約をかなり進めていて、その成果の8割は使える。こういうときに完全に捨てるのはもったいない。
やるべきなのは、まず成果を別名で退避してから、元の作業を消すことだ。
Git 管理なら、一度コミットしてしまうのがいちばん簡単だ。まだコミットしたくないなら、成果物を別ファイルにコピーしておく。
cp draft.md draft.keep.md
そのうえで、元の作業ディレクトリを戻す。
この順番が逆だと、退避させる前に壊してしまう。
非エンジニアの人ほど、この「残すものと捨てるものを分ける」が効く。
ファイル整理でも、不要な複製を消す前に、まず一覧や退避フォルダを作っておく。いきなり削除に走ると、あとで必要だった原本まで消して泣くことになる。
戻し方はコマンドだけでは終わらない。
再依頼の文面が雑だと、同じ失敗を繰り返す。
悪い例はこうだ。
前の変更はやっぱり違うので、いい感じに直してください。
これでは何も伝わらない。
「違う」の中身が曖昧だし、どこを残すのかも分からない。
書き直すなら、こういう粒度に落とす。
前の案は一度捨ててください。
目的は、A ではなく B を優先することです。
変更対象は docs/ 配下だけ。
既存の本文構成は崩さない。
削除ではなく、まず重複候補の洗い出しを出す。
コードや設定の修正なら、さらに条件を絞る。
いまの変更は破棄してください。
次は config/app.json だけを直してください。
ほかのファイルは触らないでください。
差分が大きくなるなら止まって確認してください。
Claude Code は、制約が細かいほど暴れにくい。
逆に、再出発のはずなのに制約がないと、前回の迷走を別の形で繰り返すだけだ。
筆者が一番よく見る失敗は、戻す前に成果を保存しないことだ。
Claude Code が悪いというより、人間が「もう少しで使えそう」と欲を出すせいで起きる。
たとえば、不要ファイルの洗い出しをやらせていて、候補一覧はかなり良かったのに、そのまま削除まで進めてしまう。
あとで「やっぱりこの1件は必要だった」と気づく。こうなると、戻すために別の手間が発生する。だから、削除系の仕事は必ず二段階にするべきだ。
この順番を崩さないだけで事故率がかなり下がる。
重複ファイル候補を一覧化してください。
削除はまだしないでください。
サイズ、更新日時、パスを並べてください。
この指示なら、確認してから次へ進める。
作業を捨ててやり直す話でも、最終的に「何を捨てるか」を人間が握っているほうが強い。
ここは地味だが大事だ。
「全部やり直す」のか、「このファイルだけやり直す」のか、「セッションだけ切る」のか。先に決めておかないと、戻し方がぶれる。
目安はこうだ。
この切り分けを雑にすると、Claude Code に「直して」と言いながら、実際には「前の試行のゴミを抱えたまま続ける」ことになる。
それはやり直しではない。延命だ。
最後に一つだけ言うと、Claude Code は「少しずつ補修する」より「壊れたら捨てて組み直す」ほうが扱いやすい場面が多い。特に、ファイル整理や文書作成のように、完成物よりも過程のほうが汚れやすい仕事ではなおさらだ。
迷ったら、残すものを先に守って、あとは気持ちよく捨てる。これでだいぶ楽になる。