Claude Code に何かを頼むとき、いちばん雑にやって痛い目を見るのがここだ。前の前提を残したまま「これも直して」と足すやり方である。方針変更時に前提を捨てる、古い前提を引きずらない。呼び方はいろいろあるが、やることは同じだ。前提が変わったなら、古い指示は上書きではなく、いったん消して言い直す。
この癖がないと、Claude Code は前の条件と今の条件を両方まじめに拾って、妙に遠回りな修正を返してくる。ファイル整理でも文書作成でも同じで、途中で方向を変えたのに「さっきの話」と「いまの話」を同居させると、成果物が中途半端になる。人間でもやるミスだが、CLI の相手だともっと露骨に出る。
たとえば最初に「このフォルダは不要だから削除候補を洗って」と頼み、そのあと気が変わって「削除ではなく、アーカイブ用に分類して」と言い足す場面がある。ここで前の指示を消さずに続けると、Claude Code は削除前提の整理と、保存前提の整理を両方気にして、判断が鈍る。結果として、見た目は丁寧でも実務では使いづらい出力になる。
こういうときは、追加説明ではなく、前提を切り替える指示を先に置く。実際の言い方はこうだ。
ここまでの「削除候補を洗う」という前提はいったん捨ててください。
新しい前提は「アーカイブ用に分類する」です。
削除はしないで、残すべきものと移すべきものを分けてください。
文章作成でも同じだ。最初は「社内向けのやわらかい文面で」と頼んでいたのに、途中から「取引先向けに、もっと固く」と変わることがある。このとき古い前提を残したまま「少しかしこまって」と足すと、たいてい中途半端になる。そんなときは、前の条件を明示的に切ってから言い直す。
ここまでの「社内向けでやわらかく」という前提はいったん外してください。
新しい前提は「取引先向けで、短く、断定的」です。
敬語は使ってください。ただし回りくどい表現は不要です。
Claude Code は、今与えられているコンテキストをもとに作業する。だから「古い前提を引きずらない」ことは、単なる気分の問題ではない。指示が混ざると、修正の対象がぼやける。diff が余計に増える。ファイル名や文言だけ直したいのに、周辺まで再構成される。筆者は最初、この「ちょい足し」で何度も戻された。特に文書整理で、方向転換したのに旧条件を残したまま頼むと、不要な段落が残ったり、逆に必要な注記まで削られたりして、手戻りが増える。地味だが、かなりだるい。
実務では、こういう言い換えを一回はさんでおくと安定する。
前の依頼はここで終了です。
以後は別案件として扱ってください。
新しい要件は次のとおりです。
この一文があるだけで、Claude Code の出力が驚くほど整理されることがある。特に、ディレクトリ構成の見直し、重複ファイルの整理、文面のトーン変更みたいに、前提がはっきり切り替わる作業では効く。曖昧な追加指示より、境界を引くほうが強い。
非エンジニアの使い方でもこれは同じだ。たとえば「請求書フォルダを月ごとに分けて」と頼んだあと、あとから「いや、月ではなく案件ごとにまとめたい」と変わったなら、最初の月ごとの前提を残したまま話を進めない。アーカイブの整理は、いったん基準が決まると後から混ぜた条件が邪魔になる。前提を捨ててから新しい軸を与えるほうが、結果がすっきりする。
要は、Claude Code に対しては「追加」より「切り替え」を意識するべきだ。前提が変わったなら、古い指示を残したまま上塗りしない。いったん外して、新しい条件だけを渡す。このひと手間で、出力のぶれと手戻りはかなり減る。
言い換えのコツは単純で、次の順に並べるとよい。
1. 旧前提を終了する
2. 新しい前提を明示する
3. その前提だけで作業させる
たとえば、こんな形だ。
ここまでの整理方針は終了です。
新しい方針は「削除ではなく保全」です。
以後は、その前提だけで分類してください。
この切り替えを雑にしないだけで、Claude Code はかなり扱いやすくなる。逆に、前提を残したまま話を継ぎ足す癖があると、いつまでもズレたままだ。修正しているつもりで、ズレを温存してしまうからだ。そこは容赦なく切ったほうがいい。前提が変わったら、古い指示を残さず言い直す。これがいちばん手堅い。