そこを曖昧にしたまま進めると、Claude Code はわりと平気で昔の指示を守り続ける。人間側が方針を変えたつもりでも、前提を更新する、古い指示を捨てる、をやらないと、作業の芯がずれていく。
これは開発だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初に「古い書類は残す」と言っていたのに、途中で「不要なものは捨てる」に変えたなら、その場で言い直す。ここをサボると、Claude Code は古いルールに忠実なまま、こっちの意図と違う方向へきれいに進む。丁寧なのが逆にまずい。
筆者はこれで何度か手戻りした。最初は「このフォルダ内の資料を整理して」と頼み、途中で「やっぱり重複ファイルは削除して」と方針を変えたのに、前の「削除しないで整える」前提が残っていたせいで、無難な並べ替えだけで終わったことがある。やるべきだったのは、追加でお願いすることではなく、古い前提を明示して捨てることだった。
たとえば、途中でルールを変えるなら、こう言い直す。
ここまでの前提はいったん捨ててください。
方針を更新します。
- 以前の「削除しない」は無効です
- これからは重複ファイルを見つけたら削除候補として扱ってください
- ただし、最終削除の前に一覧で確認を出してください
この言い方の肝は、「追加」ではなく「更新」だと明示することだ。Claude Code は直前の文脈をかなり拾うので、単に「あとで削除もして」と足すだけだと、前の制約と新しい依頼がぶつかる。そうなると、どっちつかずの安全運転に寄る。整理も編集も、そこが一番だるい。
文書作成でも効く。最初は「短く要点だけ」と頼んでいたのに、途中で「やっぱり社内向けに少し丁寧に」と変えるなら、こうやって切り替える。
前の「できるだけ短く」はここで終わりです。
以後の方針は次のとおりです。
- 読者は社内の非エンジニア
- 専門用語は避ける
- ただし結論は曖昧にしない
- 箇条書きは必要なところだけ使う
この手の言い直しは、単なる念押しではない。古い前提を残さないための作業だ。人間同士なら空気で伝わる場面もあるが、Claude Code 相手では空気は効果が薄い。文章にして、しかも「以前の指示はここまで」と線を引くほうが強い。
実務で使うなら、方針変更のたびに次の順番を守ると崩れにくい。まず、何が変わったかを一文で言う。次に、残すルールと捨てるルールを分ける。最後に、必要なら確認方法を添える。たとえばファイル整理なら、「保存対象の条件」「削除候補の条件」「最終確認の出し方」を分けて書く。ここを混ぜると、また古い前提がにじむ。
方針を更新します。
捨てる前提:
- ファイルは残すだけでよい
- 削除はしない
新しい前提:
- 似た名前の重複ファイルは候補としてまとめる
- キャッシュや一時ファイルは削除対象にする
- 迷うものは削除せず、理由つきで一覧に出す
作業の最後に、削除候補だけを別に列挙してください。
注意したいのは、方針変更を毎回ふわっと書くと、かえって雑になる点だ。「前の話は忘れて」とだけ書くと、何を忘れて何を残すのかが曖昧だし、Claude Code も迷う。忘れてほしいのは記憶そのものではなく、古い制約だ。そこをはっきり切るのがコツである。
もう一つ、地味に効くのが、変更点を依頼文の冒頭に置くことだ。途中の追記より、最初に「方針更新」と宣言したほうが、以後の出力がぶれにくい。長いやり取りほど効く。とくにディレクトリ整理や文書の校正みたいに、作業が積み上がる案件では、前半の前提が後半まで尾を引く。途中で気づいたら、その場で言い直すべきだ。遠慮して後回しにすると、最後にまとめて直す羽目になる。
実際、筆者は「まずは削除せず候補を出すだけ」と頼んでおきながら、あとから「やっぱり不要なら消していい」と変えたのに、その更新を本文の最後に足しただけで済ませて失敗した。結果、Claude Code は最初の慎重さを引きずったまま、候補列挙に寄った。方針は最後に足すものではない。冒頭で上書きするものだ。
この話の応用先は広い。ファイル整理なら保存基準の変更、文書作成ならトーンの変更、コード修正なら「調査だけ」から「実装まで」に切り替える場面でそのまま使える。どの場合も、古い前提を残したまま話を足すと、手戻りが増える。言い直しは面倒だが、後で直すよりずっと安い。
要するに、方針が変わったら、追加ではなく更新として書く。前の指示を残したまま補足するのではなく、古い前提を捨てて新しい前提を明文化する。Claude Code を使いこなすというのは、細かい命令を増やすことではない。途中で変わった事情を、ちゃんと変わった形で伝えることだ。