長く雑に話し続けるほど賢くなる、なんて思っていると痛い目を見る。Claude Code は会話の文脈をちゃんと使うが、使い続ければ使い続けるほど、今やっている作業に不要な前提まで抱え込む。これがコンテキスト管理の話だ。
/clear は「会話を捨てるためのボタン」ではない。作業の単位を切り替えるための道具である。ここを外すと、指示はだんだん鈍るし、差分はでかくなるし、直したい場所と違う場所を触り始める。筆者は最初、便利だからと同じセッションを延々引っ張って、最後には「その話、もう前の前提だよね」とこちらが補足し直す羽目になった。あれはだるい。
/clear を入れるべきタイミングは、だいたい次の三つだ。
ひとつ目は、話題が変わったとき。たとえば「このディレクトリを整理してほしい」の次に「別の案件の資料を要約してほしい」を続けるなら、同じ会話に載せないほうがいい。
ふたつ目は、ひとつの作業が終わったとき。実装、修正、整理、要約。完了したら一度切る。
みっつ目は、返答が妙に回りくどくなったときだ。前の指示や途中経過を引きずって、同じ説明を繰り返し始めたら、会話が長すぎるサインである。
逆に、/clear しないほうがいい場面もある。いま触っているコードや文書の前提をそのまま使って、同じ流れで小さく直すときだ。たとえば「この README の表現だけを直して」「この関数名だけ揃えて」のような話なら、会話を続けたほうが速い。毎回切っていたら、こちらが同じ背景を何度も説明することになる。あれは地味に効く。
実際の使い方は単純で、Claude Code のセッション中にそのままこう打てばいい。
/clear
これで会話の文脈をリセットできる。必要なら、そのあとで新しい作業の前提を短く入れ直す。
/clear
このセッションでは、`docs/` 配下のMarkdownだけを対象に、重複表現を減らして読みやすく整えてください。
元の意味は変えないでください。
この「いったん切って、必要な条件だけ入れ直す」やり方が、いちばん事故が少ない。
前の案件の細かい事情、さっきの仮説、もう使わないファイル名。そういうものを引きずると、Claude Code は平気で余計な前提を持ったまま動く。すると、直したいのは一文なのに、段落ごと触る。ファイル整理でも同じだ。古い話を引っ張りすぎると、別フォルダの命名規則まで勝手に気にし始めることがある。善意だが、面倒である。
/clear の判断を迷わないために、筆者はこう決めている。
作業単位が変わったら切る。
完了したら切る。
「今の依頼、前の会話を知っている前提でないと説明しづらい」と感じたら、その時点で切る。
そして、会話の長さよりも「今の依頼に必要な情報だけ残っているか」を見る。これが本筋だ。
一方で、切り方を雑にすると逆効果になる。
たとえば、途中までの指示が効いているのに /clear してしまうと、同じ説明をもう一度書き直すはめになる。ディスク整理や書類整理のように、フォルダの構造や分類ルールを覚えさせたまま次の作業に進みたい場面では特にそうだ。そこで毎回リセットしていたら、むしろ手間が増える。
だから、/clear は「思考の掃除」ではなく「仕事の区切り」に使うのが正解である。
少し実務寄りのコツもある。
大きな作業に入る前に、最初の依頼文を短く書く。前提、対象、やってほしいこと、この三つだけでいい。長文で事情を盛り込むほど、後で/clear したときに書き直しが面倒になる。
たとえば文書整備なら、こういう書き方が扱いやすい。
/clear
このセッションでは、契約関連の説明文を読みやすく整える。
対象は `notes/contract/` 配下のファイル。
専門用語は残してよいが、同じ意味の繰り返しは減らしてほしい。
このくらいで十分だ。余計な過去ログを抱えるより、毎回必要な前提だけ渡したほうが強い。
最後に、ありがちな失敗をひとつ挙げておく。
「せっかく途中までうまくいっているから、このまま何でも聞けばいい」と欲張ると、セッションはどんどん曖昧になる。Claude Code は万能な相談相手ではあるが、何でも載せた会話を長く続けるのは下手である。やることが変わったら切る。中途半端に粘らない。
これだけで、回答の精度も、差分の素直さも、だいぶ変わる。
迷ったら、こう覚えておけばいい。
前提を共有したいなら続ける。
前提を捨てたいなら /clear する。
この切り分けができると、Claude Code はかなり扱いやすくなる。仕様の細かい挙動が気になるなら、最新版の案内は公式ドキュメント docs.claude.com で確認しておくと安心だ。