途中で話が変わったのに、前の指示を引きずったまま走る。これが一番だるい。Claude Code でも同じで、最初の前提のまま作業を続けさせると、見当違いの差分や、やたら長い説明を生む。ここで効くのが前提更新、つまり指示のリセットだ。
たとえば「このフォルダの画像だけ整理して」と頼んだあとに、「やっぱり古いPDFも対象にして」「いや、削除じゃなく一覧化だけで」と方針が変わる場面がある。こういうときは、前の依頼を上書きする感覚で言い直す。曖昧に「それも含めて続けて」ではだめだ。古い前提を捨てて、今の目的をはっきり言い直すほうが速い。
実際の頼み方は、こういう形でいい。
ここまでの前提は一度忘れてください。
目的は「重複ファイルの削除」ではなく、「重複候補の一覧作成」に変わりました。
削除はしないでください。
出力は、重複の可能性があるファイル名、サイズ、保存場所を表でまとめてください。
この言い方の肝は、単に「変更です」と伝えるだけで終わらせないことだ。何を捨てて、何を残すかを明示する。Claude Code は会話の流れを参照するので、前の指示が残ったままだと、意図せず昔の条件を抱え込む。だから「今のゴール」「やらないこと」「欲しい出力」の3点を短く切って入れ直す。これで手戻りがかなり減る。
もう少し実務っぽく言うなら、途中で方針が変わるたびに、確認待ちをはさむのも手だ。筆者は以前、文書整理の依頼で「分類ルールを決めたあとに、やっぱり案件別ではなく年代順にしたい」と途中変更したことがある。そこで前のルールを残したまま続けた結果、分類と並び順が混線して、後で人間が全部見直す羽目になった。あれは地味に痛い。ここは遠慮せず、前提を切り替えてから再開したほうがいい。
いったん前提を切り替えます。
旧ルール:
- 案件別に分類
- 重複は残す
新ルール:
- 年代順に並べる
- 重複は候補としてだけ示す
- 実ファイルは触らない
この新ルールで最初からやり直してください。
この「最初からやり直してください」が大事だ。途中までの作業を前提にすると、古い条件がしみ込んだまま残ることがある。特に、ファイル名の付け替え、ディレクトリ構成の変更、長い文書の要約みたいな作業はそうだ。見た目は進んでいても、古い前提が混ざると成果物の一貫性が崩れる。指示のリセットは、無駄ではなく保険である。
ただし、毎回むやみに全部消す必要はない。全部ゼロにすると、せっかく積み上げた文脈まで捨てることになる。だから切り替えるのは「方針が変わった部分」だけだ。たとえば、対象ファイルは同じで、出力形式だけ変えるなら、対象は維持して形式だけ言い直せばいい。
対象はそのままです。
変更点は出力形式だけです。
一覧ではなく、各ファイルの要点を1行で書いてください。
箇条書きにしてください。
このやり方は、非エンジニアの用途でもそのまま使える。たとえば書類フォルダを整理しているときに、「まずは分類案だけ」「やっぱり削除候補も見たい」「いや、削除はしないで保留箱を作りたい」と揺れることがある。そんなとき、前のお願いをなかったことにして、今のゴールだけ言い直す。これだけで十分だ。ターミナルに慣れていなくても、文章の出し直しで済む。
気をつけたいのは、指示のリセットを「雑な上書き」と混同しないことだ。古い前提を捨てるのは、雑に忘れることではない。何を破棄したのかを明文化することだ。これをやらないと、Claude Code は親切に前の文脈を拾ってしまい、古い目的のために働く。人間から見れば「なんでまだそっちをやるの」というやつだが、あれはだいたいこちらの指示が曖昧なせいである。
会話が長くなってきたら、節目でこういう一文を挟むといい。
ここで前提を整理します。
今後は次の条件だけを有効にしてください。
- 目的: 〇〇
- 対象: 〇〇
- 禁止: 〇〇
それ以外の以前の条件は無視してください。
この型は、文書作成にも向く。たとえば「社内向けのやわらかい文体」にしていたのを、途中から「取引先向けに硬め」に変えるなら、文体の前提を明示して切り替える。古いトーンを引きずると、文書全体がちぐはぐになるからだ。何となく読みやすいのに、途中で温度が変わる文書は、だいたいこういう事故で生まれる。
Claude Code は、前提がはっきりしているほど強い。逆に、方針転換を曖昧に処理すると、賢さよりも過去の流れに引っ張られる。だから途中で迷ったら、遠慮せず言い直す。古い前提を抱えたまま粘るより、いったん切って、今の目的に合わせて走らせ直すほうがずっと実用的だ。仕様の細かい挙動は公式ドキュメントで確認しつつ、日常の運用ではこの「前提更新」を癖にしておくといい。