終わった成果物をいつまでも作業場所に置きっぱなしにするのは、地味に効くムダだ。不要なブランチ整理や、使い終わった成果物の整理を後回しにすると、Claude Code は次の仕事で関係ないファイルをまた見に行くし、あなたも「これ、まだ触るんだっけ」と迷う。あの手の迷いは、思った以上にコンテキストを食う。
Claude Code を使うなら、仕事が終わった瞬間に周辺を片付けて、次の依頼に入りやすい状態へ戻すのが強い。これは開発だけの話ではない。書類作成、文章の下書き、案件ごとの資料整理でも同じだ。作業が終わった場所に古い下書き、仮ファイル、重複した出力が残っていると、次の指示がぼやける。やることは単純で、終わったものを「終わった」と見なして退避、削除、整理するだけである。
まず効くのは、Claude Code に「残すもの」と「捨てるもの」をはっきりさせることだ。曖昧に「全部見て整えて」みたいな頼み方をすると、結局どれが本命かわからず、diff が肥大化しやすい。片付けは、作業の最後にまとめてやるより、ひと区切りごとにやるほうが速い。
たとえば、開発ならこんな依頼にする。
このブランチで終わった変更を確認して、次に備えて作業場所を片付けてください。
- 使い終わった一時ファイルを削除する
- もう使わない下書きやメモを整理する
- 変更内容に関係ないゴミが残っていないか確認する
- 必要なら、残しておくべきファイルだけをはっきり分ける
削除してよいものは先に候補を出し、勝手に消さずに確認してください。
文章作成や資料整理なら、こういう指示でもいい。
この案件で使った下書き、重複ファイル、古い版を整理してください。
残す最終版と、削除してよい草案を分けて、一覧で示してください。
ファイル名の付け直しも含めて、あとで迷わない形に整えてください。
ここで大事なのは、Claude Code に「掃除して」ではなく「何を掃除して、何を残すか」を言うことだ。曖昧な片付けは、だいたい片付かない。筆者は一度、終わったはずの検証用ファイルをそのままにして次の修正を投げ、Claude Code が古い前提を拾ってしまって手戻りしたことがある。人間の目には「もう終わり」に見えても、作業場所には古い断片が残る。そこを放置すると、次の仕事が鈍る。
開発での片付けは、ブランチまわりも含めて考えると効きが大きい。不要なブランチを残しまくると、あとで「このブランチ何のやつだっけ」となるし、Claude Code にも余計な状況説明が増える。終わった機能のブランチは、マージ済みか、不要なら削除する。ローカルの作業ディレクトリも、使わないものを抱え込まない。これは見た目の整理ではなく、次回の判断コストを下げる作業だ。
実際の流れはこうすると扱いやすい。
この順番を崩すと、必要なものまで消して痛い目を見る。特に、出力ファイルの名前が雑だと危ない。final, final2, final_new みたいな命名は、片付けの敵である。Claude Code に任せる前に、最終版の置き場所と命名規則だけでも固めておくと、後で探す時間が減る。
もうひとつ、よくある落とし穴が「全部見ておいて」で済ませることだ。Claude Code は広い範囲を読めるが、広く読ませるほど要点がぼやける。終わった作業の片付けでは、対象を狭めたほうが速い。たとえば「この案件フォルダの中だけ」「このブランチで増えたファイルだけ」「今日作った出力だけ」と切る。関係ないものまで吸い込ませると、片付けより探索が主役になる。
非エンジニアの使い方でも考え方は同じだ。案件ごとにフォルダを分けて書面を作る人なら、提出版、下書き、参考資料をはっきり分けるだけでいい。キャッシュや一時生成物を整理したいなら、「削除候補を先に出す」ように頼む。Claude Code は、残すべき成果物と、捨ててよい中間ファイルの見分けに向いている。全部を人力で見比べるより、見分けのルールを先に言葉にするほうが早い。
片付けを習慣にすると、次の仕事の立ち上がりがかなり軽くなる。理由は単純で、Claude Code が読むべき文脈が短くなるからだ。終わったファイル、古いブランチ、不要な下書きが減れば、次回は「どれが本筋か」を探す時間が減る。人間も同じで、机の上が散らかっていると着手が遅れる。CLI エージェント相手でも、効果はほぼそのまま出る。
最後に、片付けの依頼は仕事の終わりにひとこと足すだけでいい。
この作業は終わったので、次の仕事に入る前に作業場所を整えてください。
不要なものは候補を出し、残すものは明示してください。
この一手間で、次の依頼が軽くなる。大きな最適化ではないが、積み上がると効く。Claude Code を速く使いたいなら、まず終わったものを終わったままにしないことだ。