PaPoo
cover

前提が変わったら古い指示を捨てて、言い直す

Claude Code に同じ話を延々と持ち込んでいると、だいたい一回はズレる。古い前提を残したまま「ちょっとだけ追加で」と積み上げるからだ。方針変更の再指示、古い前提を残さない、というのは派手なテクニックではないが、実務ではこれが効く。

たとえば、最初は「このフォルダの重複画像を整理して」と頼んでいたのに、途中で「やっぱり削除は怖いから一覧だけにして」と方針が変わったとする。ここで前の指示を引きずったまま会話を続けると、Claude Code は「削除前提の整理」と「一覧化だけ」を両方気にして、中途半端な出力を返しやすい。これは開発でも文書作成でも同じで、前提が変わったのに古い条件を残すと、やり直しが増える。

やることは単純だ。方針が変わったら、差分だけを足すのではなく、いったん前提を切り替えて言い直す。Claude Code は会話の流れを見て動くので、「さっきの続き」より「今の前提」を明確に渡したほうが強い。

たとえば、こう書き直す。

ここからは前の指示をいったん忘れてください。
前提を変更します。

目的: 重複ファイルの削除ではなく、一覧化だけを行う
禁止事項: ファイルの削除、移動、上書き
出力: 重複候補の一覧、サイズ、パス、判断材料

この書き方のいいところは、Claude Code に「何をするか」だけでなく「何をしないか」も再定義できる点だ。特に削除や上書きが絡む作業では、古い前提を残したまま進むと怖い。筆者も最初は「あとで確認するからそのまま進めて」と雑に投げて、意図しない変更案を大量に作らせたことがある。結果、読む側の自分が面倒になった。AI 側の精度より、こちらの出し方が悪かったわけだ。

文書作成でも同じである。たとえば、議事録の要約を頼んだあとに「やっぱり要約ではなく、発言者ごとの整理に変える」となったのに、古い「要約」の前提を残すと、見出しや粒度がずれる。そういうときは、最初の依頼を部分修正するより、前提ごと置き換えたほうが速い。

ここまでの要約指示はいったん破棄してください。
新しい前提:
- 目的: 要約ではなく、発言者別の発言整理
- 出力形式: 発言者名ごとの箇条書き
- 省くもの: 冗長な言い換え、結論の抽出

この「破棄してください」が地味に効く。遠回しに「前のやつも少し残して」とやると、古い条件がいつまでも尾を引く。Claude Code はこちらが置いた制約をかなり忠実に見に行くので、前提を上書きするなら、上書きだと明示したほうがいい。

ただし、全部を毎回リセットすればいいわけでもない。残してよい前提と、捨てるべき前提は分ける必要がある。たとえば「この案件フォルダの中だけを対象にする」は残してよいが、「削除してよい」は方針変更で捨てるべきだ。ここを混ぜると危ない。

実際の頼み方としては、こんな切り分けが扱いやすい。

残す前提:
- 対象はこのフォルダ配下のみ
- ファイル名の意味は変えない

捨てる前提:
- 削除してよい
- 1ファイルずつ手作業で確認する

新しい方針:
- 削除はしない
- まず候補一覧を作る
- 人間が確認してから次の手順に進む

この形にしておくと、Claude Code が「どこまでやってよいか」を読み違えにくい。方針変更のたびに、雑な追加修正を重ねるより、条件を棚卸ししたほうが速いのだ。

非エンジニアの用途でも、この考え方はそのまま使える。たとえば、案件フォルダの整理で「この書類を分類して」と頼んだあと、途中で「分類ではなく、重複しそうなものだけ拾って」と変わったら、前の「分類」指示は切る。古い前提を残したままにすると、フォルダ分けと重複確認が同時進行になって、かえって散らかる。

前の分類指示は破棄してください。
新しい目的は、重複しそうな書類名の洗い出しです。
やることは一覧化まで。
移動、削除、改名はしないでください。

ここで大事なのは、「前の指示を破棄」と「新しい目的」をセットで書くことだ。片方だけだと、何を消して何を残すかが曖昧になる。

ひとつ注意がある。前提を切り替えるたびに、会話の中にある古い決定事項を勝手に持ち込ませないことだ。Claude Code は流れを読めるが、こちらが古い話を残したままにすると、その残骸も拾う。だから、方針が変わったときは、古い条件を箇条書きで打ち消すくらいの雑さがちょうどいい。丁寧に見える曖昧な言い換えより、雑でも明示的な上書きのほうが通る。

最後に、こういうときの自分用の型を持っておくと楽だ。

ここから方針を切り替えます。
前の前提はここで捨ててください。

新しい目的:
新しい禁止事項:
新しい出力形式:
必要なら、ここまでの内容を踏まえずに、この方針だけで進めてください。

この型があると、開発でも文書でも、途中で仕様が変わったときに立て直しやすい。Claude Code に限らず、指示を積み上げるタイプの作業は、古い前提を残した瞬間に崩れやすい。だから再指示は「追加」ではなく「切り替え」と考える。そこを雑にしないだけで、手戻りはかなり減る。

関連 TIPS

同じ著者の記事