長い仕事をそのまま投げると、Claude Code はだいたい雑に走る。で、あとから「それ先に必要だったのはこっちだった」と気づいて手戻りする。ここを避けるなら、最初にやることは単純だ。いきなり本作業に入らせず、先にToDoへ割らせるのである。
この一手で、作業の抜け、順番違い、コンテキストの無駄遣いがかなり減る。ファイル整理でも、ディスク掃除でも、文書作成でも効く。長い依頼ほど効き目が大きい。
たとえば「このフォルダ内の重複を洗って、不要なものを消して、最後に要約して」と一気に頼むと、途中で判断がぶれる。何を先に確認するか、どのファイルを触るか、削除の前に何を残すかが曖昧なまま進むからだ。
こういうときは、まずClaude Codeに「作業手順をToDoとして出せ」と命じる。そこで出てきた項目を見て、人間が順序と危険箇所を潰してから進ませる。
実際の頼み方はこうだ。
この作業を、まず実行用のToDoに分解してください。
まだ変更は加えず、次の形式で出してください。
1. 調査
2. 判定
3. 実行
4. 確認
各項目には、何を確認するか、どのファイルやディレクトリに触るか、失敗しやすい点も添えてください。
最後に、すぐ実行してよい項目と、人間の確認が必要な項目を分けてください。
これで十分だが、もう少し厳密にしたいなら、最初から「ToDoの粒度」を指定するといい。ざっくりした一行の箇条書きではなく、実行順に並んだチェックリストにさせる。
この依頼を、作業前の計画に変えてください。
条件:
- 変更はまだ行わない
- 1項目は1つの判断か1つの操作にする
- 依存関係があるものは順番が分かるように並べる
- 削除や上書きが入る操作には警告を付ける
- 不明点があれば、先に質問案を出す
対象:
- `docs/` 配下の古い文書の整理
- 重複している下書きの統合
- 使われていないファイルの候補抽出
このやり方の肝は、「作業して」ではなく「作業計画を作って」から始めることだ。
Claude Code は、先に地図を作らせるとかなり強い。いきなり手を動かすより、対象を見渡してから分解したほうが、余計な編集が減る。特に複数ファイルをまたぐ作業では効く。README を直しながら設定ファイルも触って、最後にテストも見て……みたいな案件は、最初にToDo化しないとだいたい散る。
筆者は一度、古い文章をまとめ直す作業をそのまま任せて、見出しの整理と本文の要約が同時進行になり、どの原文がどの要約に対応するか分からなくなったことがある。結局、差分を追い直してやり直した。あれは無駄だった。
最初に「章ごとにToDoへ分けろ」と言っておけば、先に構成だけ固めて、本文は後でまとめる流れにできたはずだ。長い作業ほど、いきなり実装させるのが雑なのである。
非エンジニアの作業でも同じだ。たとえば「会議資料の原稿を、章立てから見直して、重複表現を減らして、最後に読みやすく整えて」と頼むとする。これも一発でやらせるより、
「章立て案」→「修正候補」→「最終原稿」
の順にToDoへ分けたほうが、途中で方向を変えやすい。文書作成は、後半で構成を変えると全部崩れるからだ。先に段取りを切る価値が高い。
削除系の作業では、ToDoの分解をさらに慎重にする。たとえばディスク削減なら、いきなり消させない。先に候補を出させる。
次の作業を、削除前提のToDoに分解してください。
やってほしいこと:
- 大きいファイルや重複の候補を洗い出す
- 何を消すと危ないかを先に明示する
- 削除候補と保留候補を分ける
- 実行前に確認が必要な項目を挙げる
禁止:
- まだ削除しない
- 勝手に移動しない
- 代替案なしで除外しない
ここで大事なのは、ToDoを「きれいな見た目」にしないことだ。見栄えのいい計画書を作らせるのではなく、実行で詰まる場所を洗い出させる。
たとえば「対象を確認する」「影響を確認する」「バックアップの有無を確認する」「削除候補を出す」「人間が承認する」「実行する」まで書かせる。面倒に見えるが、これで事故が減る。削除や上書きが絡む作業は、確認工程をケチるとすぐ痛い目を見る。
ひとつ注意がある。ToDoに分解させたからといって、そのまま全部信用し切るのは危ない。分解が細かすぎると、逆に本筋が見えなくなることがある。
たとえば「確認」「確認」「確認」と続くような計画は、実質的に先延ばしだ。そういうときは、こちらから「最短で進めるために、確認はどれとどれをまとめられるか」と詰めるといい。計画は長ければいいわけではない。実行できる長さがちょうどいい。
もうひとつ、最初のToDo分解で曖昧な言葉を残さないことだ。
「整理する」「いい感じにする」「不要なものを減らす」は、だいたい事故のもとだ。何を基準にするのか、何を残すのか、どこまで触るのかを明示する。曖昧な依頼は、曖昧なToDoしか返さない。そこから先も当然、曖昧になる。
実務では、こんなふうに一段かませると扱いやすい。
この依頼を、まず以下の順番でToDo化してください。
1. 対象の把握
2. 判断基準の確認
3. 実行候補の列挙
4. リスクの洗い出し
5. 実行順の確定
6. 実施
7. 結果確認
各段階で、あなたが次に何をするつもりかを1行で書いてください。
変更が必要な段階は、必ず人間の確認を待ってください。
こうしておくと、長い作業でも途中で立ち止まりやすい。しかも、後から「どこまでやったか」が追いやすい。これは地味だが効く。ログを読まなくても、ToDoの進み具合だけで話が通るからだ。
長い仕事を扱うときは、Claude Codeに最初から完成品を求めない。まず、仕事の骨組みを出させる。
その骨組みがまともなら進める。変なら、そこで直す。たったそれだけで、手戻りはかなり減る。大きい案件ほど、この順番が雑だと崩れる。反対に、ToDoへ分解してから走らせる癖がつくと、Claude Codeはかなり扱いやすくなる。