Claude Codeに作業を頼んでいると、途中で「あれ、そっちじゃない」と思うことがあります。
頼んだのは小さな修正だったのに、関係ないファイルまで触り始める。 エラーを直してほしかっただけなのに、設計変更のような話になっている。 説明を聞きたいだけだったのに、編集まで進みそうになる。
こういうときに焦って追加指示を重ねると、さらに分かりにくくなります。 まず必要なのは、うまい指示文ではありません。 変だと思った時点で止めて、何が変わったかを確認することです。
この記事では、Claude Codeが意図と違う方向に進んだときの立て直し方を整理します。 作業を止める、差分を見る、ズレた理由を言葉にする、戻す範囲を決める、依頼文を小さくして頼み直す。 この順番を持っておくと、失敗しても落ち着いて戻れます。
Claude Codeが変な方向に進んだら、まず止めます。次に変更ファイルと差分を確認し、残す変更、戻す変更、保留する変更を分けます。そのあとで、次の依頼を小さく書き直します。
変だと思ったら、まず作業を止める
Claude Codeは、作業の途中でもどんどん次へ進めます。 コードを読み、原因を考え、ファイルを編集し、確認コマンドまで実行する。 そこが便利です。
ただ、方向がズレたまま進むと、変更が増えていきます。 変更が増えるほど、どこから違ったのか分かりにくくなります。
「たぶん大丈夫」で続けない
初心者ほど、途中で止めることに遠慮しがちです。
「まだ途中かもしれない」 「あとで直してくれるかもしれない」 「止めたら悪いかもしれない」
でも、違和感があるなら止めて構いません。 Claude Codeとの作業では、早く止めるほうが楽です。
たとえば、次のような状態なら止めます。
- 依頼していないファイル名が出てきた
- 変更対象が急に増えた
- 新しいライブラリ追加の話になった
- 説明だけのつもりが編集に進みそう
- エラー修正のつもりが設計変更になっている
この時点で止めれば、まだ戻しやすいです。 逆に、違和感を流して進めると、あとで差分を見たときに「これ、何のための変更だっけ」となります。
tomo途中で止めるのは失敗ではありません。方向がズレたまま進ませないための操作です。
止めるときの短い依頼文
止めるときは、長い説明はいりません。 まず追加編集を止めます。
ここで一度止めてください。
まだ追加のファイル編集やコマンド実行はしないでください。
ここまでに変更したファイルを一覧にしてください。もっと強く止めたいときは、こう書きます。
作業の方向が違いそうです。
いったん停止してください。
これ以上の編集、削除、移動、コマンド実行はしないでください。
変更済みファイルと、各ファイルで何を変えたかだけ説明してください。ポイントは、「止める」と「説明だけに戻す」を同時に伝えることです。 まだ原因を議論する前に、作業を増やさない状態を作ります。
何が変わったかを差分で確認する
立て直しでは、まず差分を見ます。
気持ちとしては「変なことになった」と感じていても、実際に何が変わったのかを見ないと判断できません。 変更ファイルが1つなのか、5つなのか。 本文やソースコードが変わったのか、生成物だけなのか。 ここを分けます。
変更ファイルの一覧を見る
Git管理されたプロジェクトなら、まず状態を見ます。
git status差分の中身を見るなら、次を使います。
git diffただ、初心者のうちは差分を見てもすぐ判断できないことがあります。 その場合は、Claude Codeに説明させます。
ここまでの変更差分を説明してください。
まだファイルは編集しないでください。
知りたいこと:
- 変更されたファイル
- 各ファイルで変わった内容
- 私が依頼した内容と関係がある変更
- 関係が薄そうな変更
- 戻す候補になりそうな変更説明を読めば、変更の全体像が見えます。 ここで初めて、残すか戻すかを考えます。
差分を「残す」「戻す」「保留」に分ける
差分を見たあと、全部戻すか全部残すかで考えないほうがいいです。 使える変更が混ざっていることもあります。
次の3つに分けます。
| 分類 | 意味 | 判断例 |
|---|---|---|
| 残す | 依頼した目的に合っている変更 | エラー原因になっていた1行の修正 |
| 戻す | 目的から外れている変更 | 頼んでいないデザイン変更や設定変更 |
| 保留 | よさそうだが今は判断できない変更 | 関連しそうな整理、追加テスト、補足コメント |
この分け方をClaude Codeに頼むこともできます。
差分を「残す」「戻す」「保留」に分けてください。
まだ実際には戻さないでください。
判断基準:
- 今回の目的に直接必要な変更は残す
- 頼んでいない整理や設計変更は戻す候補にする
- 判断に迷うものは保留にする
各ファイルごとに理由も書いてください。戻す前に分類するだけで、かなり落ち着きます。 焦って全部戻すより、使える変更を残しやすくなります。
ズレた理由を一文で整理する
差分を確認したら、次は「なぜズレたのか」を一文で整理します。
ここを飛ばしてすぐ頼み直すと、同じズレ方を繰り返します。 Claude Codeが悪い場合もありますが、依頼文が広すぎた場合もあります。
目的が広すぎた場合
よくあるのは、目的が広すぎる依頼です。
この画面をいい感じに直してください。このコードをきれいにしてください。この依頼だと、Claude Codeは「いい感じ」や「きれい」を推測します。 その結果、見た目、構造、命名、コンポーネント分割、テスト追加まで広がることがあります。
立て直すなら、目的を小さくします。
目的を絞ります。
今回は保存ボタンを押した後に、成功メッセージを表示することだけをやりたいです。
画面全体のデザイン変更、コンポーネント分割、新しいライブラリ追加はしないでください。これなら、次の作業範囲がかなり狭くなります。
触ってほしくない範囲を書いていなかった場合
もう一つ多いのは、やらないことを書いていないパターンです。
たとえば、バグ修正を頼むときに「認証方式は変えない」「API仕様は変えない」と書いていなければ、Claude Codeがそこまで候補に入れることがあります。
立て直し時は、触らない範囲を明示します。
さっきの依頼では範囲が広すぎました。
今回は次の範囲では作業しないでください。
- 認証方式
- API仕様
- データベース設計
- 共通コンポーネント化
- 新しいライブラリ追加
対象は、エラーメッセージの表示処理だけに絞ってください。やらないことを書くのは、Claude Codeを縛るためだけではありません。 自分があとで差分を見るための境界線にもなります。
tomoズレた理由を一文で言えると、次の依頼がかなり書きやすくなります。「目的が広すぎた」「対象ファイルを書かなかった」「やらないことを書かなかった」くらいで十分です。
戻す前に、消してよい変更か確認する
変な方向に進んだとき、すぐ全部戻したくなります。
ただ、全部戻す前に一度だけ確認します。 その変更の中に、必要な修正が混ざっているかもしれないからです。
生成物と手で書いたファイルを分ける
まず、変更されたファイルを種類で分けます。
生成物と手で書いたファイルでは、重さが違います。
| 種類 | 例 | 扱い方 |
|---|---|---|
| 生成物 | dist、ビルド後HTML、キャッシュ | 作り直せることが多い |
| 本文やソース | articles、src、設定ファイル | 中身を読んでから戻す |
| 認証や設定 | .env、秘密情報、外部連携設定 | 勝手に触らせない |
このシリーズの作業でも、記事本文とプレビューHTMLでは重さが違います。 プレビューHTMLは生成し直せます。 記事本文は手で書いた内容なので、戻す前に差分を読みます。
Claude Codeに戻す候補だけ出してもらう
戻す操作は、いきなり実行させず、候補だけ出してもらいます。
戻す候補を整理してください。
まだ実際には戻さないでください。
出してほしいこと:
- 戻す候補のファイル
- 残す候補のファイル
- 判断を保留したほうがよいファイル
- それぞれの理由
- 戻す場合に影響しそうなこと戻す対象がはっきりしてから、必要な操作に進みます。 git reset --hard のように全体を一気に戻す操作は、初心者が流れで使うには強すぎます。 少なくとも、何が消えるか分かるまで実行しないほうが安全です。
戻す操作は、直す操作より危ないことがあります。特に、記事本文、ソースコード、設定ファイル、外部サービスに影響する変更は、対象を列挙してから判断してください。
依頼文を小さくして頼み直す
立て直しの本体は、次の依頼を小さくすることです。
変な方向に進んだあと、同じ依頼文を少し言い換えるだけでは、また広がることがあります。 目的、対象、やらないこと、確認方法を入れて、作業を小さくします。
変更対象を1つに絞る
頼み直すときは、対象を1つに絞ります。
- 1つのファイル
- 1つの画面
- 1つの関数
- 1つのエラー
- 1つの確認コマンド
たとえば、こう書きます。
頼み直します。
今回は `src/components/ProfileForm.tsx` だけを対象にしてください。
目的:
保存成功時にメッセージを表示することです。
やらないこと:
- API仕様は変えない
- 認証処理は触らない
- 共通コンポーネント化しない
- 新しいライブラリは追加しない
完了条件:
保存成功時だけメッセージが表示されること。ファイル名が分からない場合は、まず候補だけ出してもらいます。
対象ファイルが分かりません。
まず関係しそうなファイルを3つまで挙げてください。
まだ編集しないでください。先に計画だけ出してもらう
ズレた直後は、すぐ再編集させないほうがいいです。 まず計画だけに戻します。
次はすぐ編集せず、計画だけ出してください。
今回やりたいこと:
保存成功時のメッセージ表示だけを直す。
計画に含めてほしいこと:
- 読むファイル
- 変更するファイル
- 変更しないファイル
- 修正内容
- 確認方法
私が承認するまで、ファイル編集には進まないでください。Plan Modeを使えるなら、ここで使うのも向いています。 ただし、Plan Modeの記事で扱ったように、計画はそのまま正解ではありません。 計画を見て、広すぎるなら削ります。
ズレた直後は、編集ではなく計画に戻す。 これを覚えておくと、同じ失敗を重ねにくくなります。
立て直し用テンプレート
ここからは、そのまま貼って使える依頼文です。 状況に合わせて、角括弧の部分だけ置き換えてください。
途中で止めたいとき
ここで一度止めてください。
これ以上のファイル編集、削除、移動、コマンド実行はしないでください。
まず、ここまでに変更した内容だけ整理してください。
出してほしいこと:
- 変更したファイル
- 各ファイルで変えた内容
- 依頼内容と直接関係する変更
- 関係が薄そうな変更
- 追加で確認が必要なこと差分を説明してほしいとき
現在の差分を初心者向けに説明してください。
まだ追加編集はしないでください。
知りたいこと:
- 変更されたファイル一覧
- それぞれの変更理由
- 今回の目的に必要な変更
- 今回の目的から外れていそうな変更
- 確認したほうがよいコマンドや手順戻す候補を整理したいとき
戻す候補を整理してください。
まだ実際には戻さないでください。
次の3つに分けてください。
- 残す変更
- 戻す候補の変更
- 判断を保留する変更
各項目について、対象ファイルと理由を書いてください。
削除や上書きが必要になる場合は、実行前に止まってください。小さく頼み直したいとき
頼み直します。
さっきの作業は範囲が広がりすぎました。
今回の目的:
[今回だけ達成したいことを書く]
対象:
[対象ファイル、画面、関数、エラーのどれかを書く]
やらないこと:
- [触ってほしくない範囲を書く]
- [追加してほしくない作業を書く]
- [変更しない仕様を書く]
まず計画だけ出してください。
計画には、変更するファイル、変更しないファイル、確認方法を含めてください。
私が承認するまで編集に進まないでください。
tomo立て直しの依頼は、短くて大丈夫です。止める、差分を見る、戻す候補を出す、小さく頼み直す。この4つに分ければ、かなり扱いやすくなります。
まとめ
Claude Codeが変な方向に進んだとき、最初にやることは追加の説明ではありません。 まず止めます。 それから、変更されたファイルと差分を確認します。
立て直しの流れは次の通りです。
- 違和感がある時点で作業を止める
- 変更ファイルの一覧を見る
- 差分を「残す」「戻す」「保留」に分ける
- ズレた理由を一文で整理する
- 戻す前に、消してよい変更か確認する
- 次の依頼を小さくして頼み直す
Claude Codeを使ううえで大事なのは、失敗しないことだけではありません。 ズレたときに戻れる流れを持っておくことです。
早めに止める。 差分を見る。 戻す範囲を決める。 そして、次の依頼を小さくする。
この流れがあれば、Claude Codeは「勝手に進んで怖いもの」ではなく、途中で立て直しながら使える相手になります。
