ありがちなのは、「これまとめてやって」と一気に投げて、そのまま手戻りの山を作るやり方だ。Claude Code は雑に使うとかなり賢いが、指示の粒度が荒いと、途中で迷う。調査と実行の分離、段階依頼、確認フェーズを分けるだけで、その迷いはかなり減る。
特に、ファイル整理、ディスク削減、文書作成みたいな作業は、この分け方が効く。先に情報を集め、次に編集し、最後に確認する。順番を切るだけで、Claude Code の出力が安定するし、こちらも「今どの段階の話をしているのか」を見失いにくい。
筆者は最初、ひとつの依頼文に全部詰め込んでいた。たとえば「このフォルダを見て、重複を探して、不要なものを消して、最後にレポートして」と一息で頼む。すると、探索も削除も説明も同時に走るせいで、どこまで事実確認済みなのかが見えにくい。しかも diff が肥大化しやすい。あとから「その削除は本当に要るのか」と見返すのがだるい。そこで段階を分けたら、かなり扱いやすくなった。
やり方は単純だ。最初は調査だけ頼む。次に、調査結果をもとに編集や削除を頼む。最後に、変更後の確認を頼む。
たとえば、不要ファイルの整理ならこう分ける。
# 1. 調査だけ
このフォルダ内で容量の大きいファイル、重複の疑いがあるファイル、明らかなキャッシュ候補を洗い出してください。
削除はしないでください。
結果は、候補ごとに「理由」「場所」「サイズ」を表でまとめてください。
# 2. 編集・削除
先ほどの候補のうち、次の条件に合うものだけ削除してください。
- 再生成できるキャッシュ
- 30日以上触っていない一時ファイル
- 明確に重複していて片方だけ残せるもの
削除前に、実行予定の一覧を出してください。
実行後は、何を消したかを短く報告してください。
# 3. 確認フェーズ
削除後に、残るべきファイルが消えていないか確認してください。
必要なら、再確認のための観点も列挙してください。
文書作成でも同じだ。いきなり「整えて完成させて」より、「まず素材を整理」「次に書き直し」「最後に誤り確認」の順がいい。特に契約書の下書きや社内説明資料みたいに、内容の正しさと表現の整い方が別物のときは、この分け方が効く。
# 1. 調査
このメモの中から、主張、事実、未確認の点を分けて抽出してください。
未確認の点は「要確認」として残してください。
# 2. 編集
抽出結果をもとに、読みやすい説明文に書き直してください。
意味を変えず、冗長な部分だけ削ってください。
# 3. 確認
書き直した文の中で、事実確認が必要な箇所と、表現の修正だけで済む箇所を分けて指摘してください。
ここで大事なのは、各フェーズの目的を混ぜないことだ。調査フェーズでいきなり削除を始めると、Claude Code は「何を根拠に進めるか」を自己解釈し始める。すると、見た目はそれっぽいのに、実際は飛ばしてはいけない確認を飛ばす。編集フェーズで調査を続けるのも同じで、出力がだらだら伸びる。確認フェーズは、仕上げのための検査に徹させる。ここで新しい作業を始めさせない。
筆者が一度やらかしたのは、調査と実行を同じ依頼に入れたまま、結果だけ眺めて安心したことだ。Claude Code はちゃんと動いたように見えたが、後で見ると、削除してよかったファイルと、まだ残すべきファイルの境目が曖昧だった。こちらの指示が曖昧だったせいで、確認の観点も薄かったのである。あれは地味に痛い。あとで復旧しようとしても、何をどう消したか曖昧だと戻しにくい。
だから、確認フェーズは手を抜かないほうがいい。ここでは「本当に変更してよい範囲に入っているか」を見せるだけで十分なことが多い。たとえば、以下のように頼む。
変更内容を確認してください。
- 仕様上残すべきファイルが消えていないか
- 置換した文言の意味が変わっていないか
- 参照先やリンクが壊れていないか
問題があれば、修正点だけ挙げてください。
この分け方が特に効くのは、指示に迷いが出やすい場面だ。たとえば、フォルダが大きくて全体を一気に把握しづらいとき。あるいは、似た名前のファイルが多くて、人間の目でも見分けにくいとき。いきなり最終判断をさせるより、まず候補を出させる。その後でこちらが判断材料を見て、次の一手を決める。これで、Claude Code への依頼が「作業の丸投げ」ではなく「判断の補助」に変わる。
もうひとつ、段階依頼はコンテキストの節約にもなる。長い一発依頼は、途中で論点がぼやけやすい。調査の結果、編集の対象、確認のポイントを分けてやりとりすると、会話の焦点がずれにくい。特に長文の修正や複数フォルダの整理では、この差が出る。途中で「さっきの条件、なんだったっけ」とならない。
ただし、分ければ何でもうまくいくわけでもない。調査フェーズで集めた情報が雑だと、その後の編集も雑になる。ここは最初の依頼文で最低限の観点を渡しておく。たとえば「サイズ順」「更新日時順」「重複の可能性」「再生成可能性」みたいに、見る軸を先に置くといい。非エンジニアの作業なら、「古い」「重い」「同じ内容が複数ある」といった言い方で十分だ。
段階を切ると、最後に人間が判断しやすい形で戻ってくる。これは地味だが強い。Claude Code に全部やらせるのではなく、途中で止めて、確認して、次に進める。仕事が速くなるというより、迷いが減る。迷いが減ると、手戻りが減る。手戻りが減ると、結果としてかなりラクになる。
この考え方は、他の作業にもそのまま使える。たとえば大量の文書を整えるときは、まず分類だけ、次に整形だけ、最後に誤字と抜けの確認だけに分ける。ソースコードでも、まず影響箇所の調査、次に最小変更、最後にテスト確認、の順に切ると落ち着く。
要するに、Claude Code には「全部いっぺんに」ではなく、「今はこの段階だけ」と言うほうが強い。調査、編集、確認を分けると、途中の迷いが消える。作業の輪郭がはっきりして、こちらの判断もぶれにくくなる。雑に全部まとめて頼む癖があるなら、まずここを直すといい。