会話が長くなるほど、前提を抱えたまま走るのが一番だるい。Claude Code にも人間にも通じないまま話が進むと、あとで「それは最初に言ってほしかった」が必ず出る。そこで効くのが、要点の一文化、文脈サマリ、ミニ要約だ。節目ごとに前提を 1 行へ圧縮して差し込むだけで、指示のズレと手戻りがかなり減る。
Claude Code は、会話の流れで積み上がった文脈をもとに動く。だから、ファイル整理でも文書作成でも、途中で前提が変わったのに古い認識のまま作業させると、平気でズレる。たとえば「重複ファイルを消したい」の話をしていたのに、途中から「バックアップは残したい」に変わった。ここを明示せずに進めると、消してはいけないものまで整理対象に入る。そういう事故を防ぐのが、前提を 1 行で打ち直すやり方だ。
やり方は単純で、節目ごとに「今の状況」「守る条件」「この先の目的」を 1 行に畳む。長い説明は要らない。むしろ長いと、Claude Code が拾うべき核がぼやける。たとえば、こんな感じでいい。
ここまでの前提: 対象は /Projects/report/ 配下、削除は不可、今回は重複候補の洗い出しだけを行う。
この一文があるだけで、その後の指示はかなり安定する。続けて作業を頼むなら、こう書けばいい。
ここまでの前提: 対象は /Projects/report/ 配下、削除は不可、今回は重複候補の洗い出しだけを行う。
次に、ファイル名と更新日を見て、重複しそうな候補を一覧にして。削除はまだしないで。
文書作成でも同じだ。議事録、提案書、説明文、どれでも途中で論点が増えると前提が散る。そんなときは、会話の節目で次のように圧縮しておく。
ここまでの前提: 読者は非エンジニア、目的は操作手順の説明、専門用語は避け、削除系の手順には必ず確認文を入れる。
この 1 行は、要点の一文化でもあり、文脈サマリでもあり、ミニ要約でもある。名前はどうでもいい。役目は同じで、会話の現在地を固定することだ。
筆者は最初、これをサボって痛い目を見た。Claude Code にディレクトリ整理を頼んでいたのに、途中で「実はこのフォルダは共有用だから消せない」と条件が増えた。ところが、それを長々と説明しただけで、肝心の「削除禁止」が文中に埋もれた。結果、確認の流れが甘くなり、差分の見え方も悪くなった。あれは完全にこちらの負けだ。前提は長文で説明するより、1 行で固定したほうが強い。
このやり方で大事なのは、要約を“感想”にしないことだ。「たぶんこういう話だったと思う」は弱い。Claude Code が扱える形に落とすなら、判断に必要な条件だけ残す。たとえば、こんな順番で畳むと崩れにくい。
ここまでの前提: 何を対象にするか、何を触ってはいけないか、今回のゴールは何か、の3点だけ残す。
もちろん、そのまま実際の指示に置き換えたほうがいい。
ここまでの前提: 対象は /archive/ の PDF、削除は提案まで、目的は重複の整理と保存方針の確認。
この一行を節目に置くタイミングは、会話の中で前提が変わったとき、作業の段階が変わったとき、別の人向けの文章に切り替わるときだ。毎回やる必要はない。むしろ、変化がないのに入れすぎると逆にうるさい。だが、変化があったのに放置すると、Claude Code は古い条件を引きずる。そこを切るための短い杭だと思えばいい。
少し進めるなら、要約を「確認用」と「作業用」に分けると楽になる。確認用は人間が読む。作業用は Claude Code に渡す。たとえば、作業の区切りでこう置く。
確認用: ここまでで、対象フォルダ、削除不可、重複整理だけ、という条件で合っている。
作業用: この条件のまま、重複候補を優先度つきで並べて。
こうすると、会話の流れが崩れたときに気づきやすい。人間が読み返して違和感を拾えるからだ。しかも、Claude Code 側にも「今の前提」がはっきり入る。
注意したいのは、1 行に詰めるからといって曖昧語を増やさないことだ。「いい感じに」「適当に」「必要なら」は危ない。こういう語は便利そうに見えて、実務ではだいたい面倒を増やす。要約のつもりで入れた一文が、ただの逃げ道になるからだ。条件を残すなら、対象、禁止事項、目的の三つに絞るのがいい。
最後に、この癖はファイル整理やディスク削減だけでなく、文書作成でもかなり効く。会話の節目で前提を 1 行に圧縮しておくと、長い対話でも軸がぶれにくい。Claude Code に細かい修正を重ねるときほど、前提の再掲は効く。放っておくと、最初の条件はどんどん遠くなる。そこで一行だ。短いが、かなり強い。