長い会話でいちばん危ないのは、古い条件をそのまま抱えたまま突っ走ることだ。前提が増えたのに、最初の指示だけを正解扱いすると、Claude Code は律儀に古い制約を守り続ける。結果、遠回りになる。これを防ぐのが、前提の更新、つまり条件の言い直しである。
Claude Code は会話の流れを見て動く。だから、途中で事情が変わったら、前の条件を雑に足すのではなく、いったん整理して差し替えるほうが強い。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初は「まず一覧を作って」と頼み、次に「やっぱり重複候補だけ残して」と変わることがある。このとき、前の依頼を引きずったままだと、余計な作業が積み上がる。
筆者はこれで何度か手戻りした。たとえば、最初に「削除候補を広めに洗い出して」と頼んだあと、途中で「実際には移動だけにしたい」と方針変更したのに、古い削除前提を消さなかったせいで、説明がやたら削除寄りになった。会話が長くなるほど、こういうズレは増える。人間同士の会話なら空気で直るが、Claude Code は空気を読むより文面を読む。だから、言い直しが必要になる。
やり方は単純だ。方針が変わったら、「今までの条件はここまで。以後はこれで進めて」とはっきり切る。たとえばこう書く。
ここまでの前提を整理します。
- 以前の条件のうち、「削除」は捨てる
- これ以降は「移動のみ」で進める
- 既存の調査結果は使ってよいが、判断基準は新しい条件を優先する
新しい依頼:
重複ファイルの候補を、削除せずに archive/ に移動する案だけ出してください。
この言い方のいいところは、何を捨てて何を残すかが見えることだ。単に「さっきのは忘れて」だけだと、どこまで忘れるかが曖昧になる。Claude Code は「忘れる」より「更新する」で扱ったほうが安定する。前の調査結果は再利用しつつ、判断基準だけ差し替える。これが実務でいちばん事故が少ない。
文書作成でも同じだ。たとえば、最初は「社内向けのやわらかい文体」で進めていたのに、途中で「法務レビュー用だから固めに寄せる」に変わることがある。そんなときは、雰囲気だけ足さず、条件を更新する。
前提を更新します。
- これまでの「やわらかめの口調」は破棄する
- 以後は、社外提出を前提にした簡潔で硬めの文体にする
- 内容の事実関係は維持し、表現だけを整える
ここで大事なのは、「新しい条件が古い条件に勝つ」と明示することだ。そうしないと、Claude Code は両方を満たそうとして中途半端になる。やたら丁寧なのに回りくどい、あるいは短くしたいのに説明が長い、という変な折衷案が出る。あれは指示が悪い。モデルの気分の問題ではない。
会話が長くなったときは、途中で小さな棚卸しを入れるといい。次のように、前提を短く書き直してから作業を続ける。
ここまでの整理:
- 対象フォルダは /Users/me/Documents/2024案件
- 目的は重複や不要キャッシュの洗い出し
- 削除はまだしない
- 出力は一覧と判断理由だけでよい
この前提で続けてください。
このひと手間で、会話の迷子がかなり減る。特にファイル操作や整理系では効く。古い条件が残ったままだと、たとえば「全部消す前提」で候補を広く出したあとに、実際は「削除禁止」だったと気づく。そんなときの手戻りは面倒だし、精神的にもだるい。最初に更新しておけば済む話である。
注意点もある。前提を更新するときに、全部を上書きしすぎないことだ。残すべき事実まで消すと、かえって話が飛ぶ。古い条件のうち、単なる制約だけを捨てるのか、対象範囲も変えるのか、そこを切り分ける必要がある。筆者は以前、条件を言い直したつもりで対象ディレクトリまでぼかしてしまい、Claude Code が別の場所を前提に説明を始めてしまったことがある。更新は雑にやると逆効果だ。
実際のコツは、会話の節目で次の3点を明文化することに尽きる。何を捨てるか、何を残すか、これから何を優先するか。この形にしておくと、長いやり取りでも筋がぶれない。
前提を更新します。
捨てる条件: すでに終わった下調べの仮説
残す条件: 対象ファイルの場所、最終目的
優先する条件: 以後は「安全性」を最優先。削除より確認を先にする
この習慣は、コード修正でも、書類整理でも、メモの整形でも効く。会話が長くなるほど、最初の条件は古くなる。古い条件を大事に抱え込むより、必要なところだけ残して更新したほうが速い。Claude Code をうまく使う人は、指示を増やす人ではなく、前提を更新できる人だ。