Claude Code に「長い仕事をそのまま進めて」と渡すと、途中で迷ったり、どこまでやったか見えにくくなったりします。先に小さな ToDo に分けさせると、作業の見通しが立ち、途中確認もしやすくなります。コード修正だけでなく、フォルダ整理、重複ファイルの洗い出し、長文の下書きにも効きます。
このやり方の肝は、いきなり実行させるのではなく、まず「何を順番にやるか」を書き出させることです。Claude Code は対話しながら進められるので、最初に作戦を出させてから、ひとつずつ潰していく運びに向いています。
たとえば、案件フォルダを整理したいなら、こんなふうに頼みます。
この作業を、実行前に小さな ToDo に分解してください。
目的: 旧案件フォルダの整理と不要ファイルの削減
条件:
- まず手順だけ提案する
- 危険な削除は勝手にしない
- 迷う点があれば確認質問を先に出す
- 作業は小さく分ける
コード修正なら、もう少し具体的にしておくと安定します。
次の変更作業を、実行前に ToDo に分解してください。
やってほしいこと:
- 影響範囲の確認
- 変更対象ファイルの洗い出し
- まず読むべき箇所の順番
- テストの確認
- 最後の仕上げ
最初は ToDo だけ出して、勝手に編集はしないでください。
文書作成でも同じです。長い報告書や提案書を一気に書かせるより、先に段取りを切るほうが扱いやすいです。
以下の原稿を、執筆前に ToDo に分解してください。
目的: 顧客向け提案書の下書き
要件:
- 章立ての案を出す
- 各章で確認すべき材料を挙げる
- 不足情報があれば質問する
- いきなり本文は書かない
うまく回すコツは、ToDo を「大きさの違う塊」にしないことです。「調べる」「修正する」「確認する」だけだと広すぎます。代わりに、見える単位まで切ってもらいます。たとえば「対象フォルダを一覧化する」「削除候補を出す」「保留にするものを分ける」「最後に実行前確認をする」のように、1 手ずつ進められる粒度です。
実際には、最初の依頼文に「実行前に ToDo 化して」と一文足すだけでもかなり違います。さらに、次のような条件を添えると、暴走しにくくなります。
- まず計画を出す
- 危険な操作は提案段階で止める
- 1 回にやるのは 1 ToDo まで
- 途中で不明点があれば、その場で止まって聞く
ここで大事なのは、ToDo に分けさせたあとも、全部を一気に走らせないことです。長い作業ほど、途中で前提が崩れます。たとえばフォルダ整理なら、最初に想定していた「不要キャッシュ」が、実はアプリの必要ファイルだった、ということがあります。文書作成でも、途中で読者や提出先の条件が変わることがあります。小分けにしておくと、そのたびに軌道修正できます。
もうひとつの注意は、「ToDo 化」は「安全確認」の代わりではない、という点です。削除や上書きが入る作業では、提案の段階で止めさせ、内容を見てから進めるほうがいいです。特に非エンジニアが使う場面では、Claude Code に任せきりにせず、削除候補や編集対象の一覧を先に見せてもらう流れが安心です。
たとえばディスク整理なら、いきなり消さずに、次のような確認の流れにすると事故が減ります。
このフォルダ内で、削除候補を ToDo 化してください。
- まず種類ごとに分ける
- 消してよい可能性があるものと、要確認のものを分ける
- 重要なデータの可能性があるものは削除しない
- 実行前に確認用の一覧を出す
長い作業を ToDo に分解させる使い方は、単に「丁寧にやる」ためではありません。途中で判断が必要な仕事を、判断しやすい順番に並べ替えるためのやり方です。人が見ても追いやすくなり、Claude Code にとっても迷いにくくなります。
慣れてきたら、最初の指示に「見積もり」も足すとさらに便利です。
作業を ToDo に分解したうえで、各 ToDo が軽い作業か重い作業かも分けてください。
重いものは先に注意点を出してください。
これを入れておくと、時間がかかる箇所を先に把握できます。長文編集や大きな整理作業では、見通しが立つだけで進めやすさがかなり変わります。
要するに、長い仕事は「やって」と渡すより、「まず分けて」と渡したほうがうまく進みます。Claude Code には、細かい作業を着実に進める前に、まず地図を描かせる。そのひと手間が、実務ではいちばん効きます。