Claude Code に雑に「適当に進めて」と投げると、静かに深掘りしすぎて、あとから人間が困る。これが一番ありがちな事故だ。節目だけ報告、進捗の粒度、黙らせるか返させるかを先に決めておくと、作業の暴走をかなり防げる。
特に Claude Code は、頼み方が広いほど、丁寧にやりすぎる。ファイルを読み込み、関係ありそうな箇所まで追い、修正案を積み上げる。その間に「今どこまで進んだか」が見えないと、こちらは待つしかない。長いコード修正でも、書類整理でも、途中報告の設計がないと後でまとめて確認する羽目になる。差し戻しが重い。
筆者も最初はこれで何度か手戻りした。たとえば「このフォルダの重複ファイルを整理して」とだけ頼むと、探索を丁寧にやりすぎて、不要な比較や候補出しに時間を使う。あとで「そこまで細かく見なくてよかった」となる。逆に、途中で一度だけ報告させるようにすると、方向修正が早い。Claude Code を黙らせるか、こまめに返させるかを先に決めるだけで、かなり扱いやすくなる。
やり方は単純でいい。最初の指示に、報告の節目を入れる。ポイントは「何文字ごと」みたいな機械的な指定より、「何が終わったら返すか」を書くことだ。進捗の粒度は、作業の重さに合わせて決める。
以下の順で進めてください。
1. まず対象をざっと把握する
2. 変更方針を短く報告する
3. 実作業を進める
4. 主要な節目ごとに途中報告する
5. 最後に差分と未完了点をまとめる
途中報告は、次の節目で返してください。
- 対象ファイルの洗い出しが終わったとき
- 方針を決めたとき
- 実際に変更を入れる前
- 大きめの変更を終えたとき
これだけだと少し曖昧なので、もう一段はっきりさせるといい。たとえば「黙らせるか返させるか」を、作業の種類で切り替える。
この作業では、探索中は黙って進めてよい。
ただし、次のときは必ず止まって報告してください。
- 仕様が分岐する
- 削除を伴う
- 3 ファイル以上にまたがる変更になる
- 不明点が出た
報告では、いま見えている選択肢を 2 つまでに絞って示してください。
この形が効くのは、Claude Code が勝手に「完璧な答え」を作り込む前に、こちらへ戻ってこられるからだ。質問が必要な地点で止まらせる。そこを逃すと、あとでまとめて見せられる。差分が大きくなって、読むだけでだるい。
非エンジニア向けの作業でも同じだ。たとえば、案件フォルダを整理したり、古い文書の重複を見つけたりするとき、全部終わるまで無言で進めさせると危ない。途中で「この分類でいいか」「このファイルは残すか」を返させたほうが、あとでまとめて直すよりずっと楽だ。大量のファイルを相手にするときほど、途中報告は節約になる。
実際の依頼文は、かなり素直でいい。
このフォルダの中身を整理してください。
ただし、勝手に削除はしないでください。
まず全体を見て、どんな種類のファイルがあるか途中報告してください。
そのあと、削除候補と保留候補を分けて、私の確認を待ってください。
ここで大事なのは、「報告してほしい」だけで終わらせないことだ。何を報告するか、どの段階で返すか、返したあとに何を待つのかまで書く。これがないと、Claude Code は親切に前へ進む。親切すぎる。そこが困る。
注意点もある。途中報告を細かくしすぎると、逆に作業が切れ切れになる。1 ファイルごと、1 行ごとに返させると、確認コストのほうが高くなる。筆者は一度、報告を細かくしすぎて、進んでいる感じより「止まっている感じ」が強くなったことがある。節目は多ければいいわけではない。迷いそうなところだけ止めればいい。
もうひとつ、途中報告を求めるなら、最初に「最終成果物」の形も軽く決めておくといい。途中で見せる情報と、最後に欲しい情報がズレると、二度手間になる。
途中報告では、変更方針と迷っている点だけ見せてください。
最後には、実際に直した箇所と、判断が必要な箇所を分けて示してください。
このやり方は、コード修正だけでなく、文章作成にもそのまま使える。長い文書の下書きや要約を Claude Code に任せるときも、章ごとに返させると修正しやすい。全部書き切ってから直すのでは遅い。途中で方向を合わせたほうが、仕上がりが安定する。
要するに、Claude Code を使うときは「どこで止まるか」を先に決めるのがコツだ。黙って進ませるときは黙らせる。確認が要るところでは返させる。その線引きが曖昧だと、作業は静かに大きくなる。後で見た人間がしんどい。