Claude Code に雑に「進めて」と投げると、案外まっすぐ突っ走る。で、いちばん痛いのは、前提が途中で壊れているのに走り続けることだ。前提崩れ時の停止、前提確認、暴走防止を最初から入れておくと、手戻りが目に見えて減る。
たとえばファイル整理でも文書作成でも同じで、最初に置いた条件が崩れた瞬間に止まらせるほうがいい。勝手に「たぶんこうだろう」で埋められると、あとで大量に直す羽目になる。筆者は、削除候補を洗い出すはずが、曖昧な指示のせいで想定外の範囲まで候補を広げられ、確認に余計な時間を食ったことがある。こういう事故は、最初の一文でかなり防げる。
効くのは、作業そのものより「止まり方」を先に決めることだ。Claude Code に渡す指示に、前提が崩れたら勝手に補完せず、必ず止まって確認する、と書く。これだけで、暴走しやすい場面の多くは抑えられる。
まずは、依頼文にこう入れる。
前提が崩れたら作業を止めてください。
不明点を推測で埋めず、前提確認をしてから続けてください。
変更前に、何が前提で、どこが崩れたのかを短く示してください。
もう少し実務向けにするなら、確認の粒度まで指定する。
次の条件で作業してください。
- 前提が崩れたら、その時点で停止する
- 推測で補わない
- 途中で条件の食い違いを見つけたら、作業を進めず質問する
- 変更対象が広がる場合は、広がる理由を先に説明する
- まず現状を確認し、前提が合っているかを短く整理してから動く
この書き方のいいところは、Claude Code が「何となく整合していそうだから進める」癖を出しにくくなる点だ。とくに、フォルダ整理、古い書類の仕分け、重複ファイルの洗い出し、Markdown 文書の整形みたいな作業で効く。対象がはっきりしているようで、実は例外だらけだからだ。雑に広げると、必要なものまで巻き込んでしまう。
実際の依頼では、前提を文章の中で列挙しておくと強い。たとえば、文書整理ならこうだ。
作業対象は ~/Documents/projectA だけです。
このフォルダの外は触らないでください。
もし projectA 以外のファイルが混ざって見えても、作業範囲には含めず、停止して確認してください。
重複削除や移動は、前提に合わない可能性が1つでもあれば実行しないでください。
ここで大事なのは、「止めていい条件」を具体化することだ。単に「慎重に」と書いても、Claude Code には伝わりにくい。何が崩れたら止まるのかが曖昧だと、結局は人間が後で全部見ることになる。
ありがちな失敗は、前提確認を入れたつもりで、実は入っていないパターンだ。たとえば「確認してから進めて」とだけ書くと、確認した体で進める余地が残る。だから、次のように言い切るほうがいい。
前提を確認できない場合は作業を開始しないでください。
前提が崩れていると判断したら、修正案を出す前に停止してください。
この一文が効く場面は、差分が広がりやすいときだ。コード修正でも文書修正でも、前提が崩れたまま進むと、変更箇所が雪だるま式に増える。最初は1ファイルの整理だったのに、関連ファイルまで触り始める。最初は1章の修正だったのに、全体の表記ゆれを直し始める。ありがたいようで、だいたい余計だ。
筆者が一度やらかしたのは、既存のファイル構成を少し整えるつもりで、対象外のディレクトリまで含める指示を曖昧にしたことだ。Claude Code 自体はむしろ真面目にやる。問題は、真面目さが前提の甘さと合体したときだ。結果として確認の手間が増えた。だから今は、範囲外が見えたら止める、と先に書くようにしている。
対象外のファイルやフォルダを見つけても、解釈で補わず停止してください。
対象範囲の外側に広げる提案は、必ず確認を取ってからにしてください。
この手の指示は、非エンジニアの用途でもかなり役に立つ。たとえば、契約書のドラフト整理や、月末の資料フォルダの片づけでも同じだ。勝手に「似ているから同じ扱い」にされると困る。古い版を消すべきか、残すべきか、移動で済むかは、見た目より文脈で決まる。文脈が怪しいなら止める。これがいちばん安い。
応用するなら、停止条件を1つ増やすとさらに安定する。前提が崩れたら止める、に加えて、実行前の要約を出させるやり方だ。
作業の前に、理解した前提を3行で要約してください。
その要約に私が修正を入れたら、修正後の前提で再確認してから動いてください。
前提が1つでも未確定なら、作業を始めず質問してください。
これを挟むと、Claude Code が「何を理解しているつもりか」を見抜きやすい。前提のズレは、実行フェーズではなく着手前に潰すのが楽だ。後から直すよりずっと安い。
最後に、入れておくと地味に効く一文を置いておく。
前提が崩れたら、進めるより止まることを優先してください。
かなり単純だが、これがあるだけで挙動が変わる。雑に突っ走ってほしくない場面では、曖昧な期待より、停止条件の明文化だ。Claude Code を便利に使う人ほど、ここをケチらないほうがいい。前提確認を先に入れるだけで、あとで頭を抱える回数が減る。