Claude Code に「いい感じに進めて」とだけ投げると、だいたい黙って進みすぎて、あとでまとめてひっくり返る。これ、かなりある。
進捗報告の粒度を先に決めないと、途中で方向がズレても気づくのが遅い。逆に、黙って進ませすぎないだけで、手戻りはかなり減る。
特に Claude Code は、ファイル整理でも文書作成でも、作業自体は速い。だからこそ、途中報告の頻度を先に決めるのが効く。
「どこまでやったら一度止まるか」「何を見せるか」を先に決めておく。これだけで、依頼の雑さを進行中に吸収しやすくなる。
たとえば、最初にこう置く。
作業を始める前に、まず進め方を短く確認して。
30分ごと、または1つのまとまった変更が終わるたびに途中報告してほしい。
報告には、やったこと、迷っている点、次にやることを3行で入れて。
大きな判断が必要になったら、その場で止まって確認して。
これだけでもかなり違う。
「30分ごと」みたいな時間ベースでもいいし、「1つのまとまった変更が終わるたび」でもいい。コード修正なら後者が合うことが多い。文書作成やファイル整理なら、章ひとつ、フォルダひとつ、処理単位ひとつで区切るのが扱いやすい。
もう少し実務っぽくするなら、報告の中身まで決めてしまう。Claude Code は、何を報告すべきかが曖昧だと、妙に長い説明を返したり、逆に大事な判断をすっ飛ばしたりする。そこを先に縛る。
途中報告では次の順で短く書いて。
1. 何を終えたか
2. どこで迷っているか
3. 次に何をするか
報告が必要なタイミングは、以下のどれかにして。
- 仕様の解釈が2通り以上あるとき
- 既存ファイルを大きく書き換える前
- 変更量が増えて差分が大きくなりそうなとき
- 依頼文にない前提が必要になったとき
このやり方のいいところは、黙って暴走するのを防げるだけじゃない。
人間側も「今どこまで進んでいるか」を見失いにくい。Claude Code は作業をため込みやすい場面がある。たとえば複数ファイルの整理を任せると、最後にまとめて整形案を出してきて、こちらが途中の判断を追えなくなることがある。筆者は以前、文書の章立てを任せて、最後に一気に差し替え案を出されたことがある。流れは綺麗でも、途中で確認したかった論点がいくつか埋もれた。あれはもったいない。途中報告を挟んでおけば、防げた失敗だ。
非エンジニアの用途でも同じだ。たとえば大量のPDFや請求書ファイルを整理するなら、こう言っておくといい。
フォルダ整理を始める前に、分類ルール案を先に出して。
そのあと、20件ごとに途中報告して。
報告には、分類した件数、迷ったファイル、次に確認したいことを入れて。
勝手に削除はしないで。削除候補は別に一覧で出して。
「削除はしないで」を先に入れるのも大事だ。進捗報告の頻度だけ決めて、危ない操作の止め方を決めないと、途中で気づいたときには戻しにくい。ファイル整理は特にそうだ。Claude Code は手際よく見えるぶん、やってはいけない操作を先に封じておかないと怖い。
少し細かい話をすると、報告の頻度は「短すぎても長すぎてもだるい」。1ファイルごとに止まらせると、作業の流れが切れて逆に遅い。逆に、最後まで報告なしだと、こちらは判断材料を失う。だから、作業の単位に合わせるのがいい。
コードなら「機能の塊ごと」。
文書なら「1節ごと」。
ファイル整理なら「1フォルダか20件ごと」。
このくらいの粒度が、だいたい現実的だ。
途中報告をうまく使うコツは、報告を「謝罪文」にしないことでもある。
「まだここまでです」だけでは弱い。必要なのは、進んだ事実と、次の判断点だ。たとえばこんな感じで十分だ。
ここまでで、重複候補の一覧作成は終わった。
似た名前のファイルが3組あって、日付だけでは判断しづらい。
次は、サイズの大きいほうを残すか、内容を開いて確認するかを聞きたい。
ここまで書けると、こちらも判断しやすい。Claude Code に任せるときは、作業の速さより、途中で止まれる形にしておくほうが強い。
黙って進ませすぎない。途中報告の頻度を先に決める。これだけで、手戻りと不安がかなり減る。
細かく詰めたいなら、次は「何を出してほしいか」を一緒に決めるといい。変更の要約だけでなく、迷いどころや未確定点も報告させる。そこまでやると、Claude Code はかなり扱いやすくなる。
逆に、そこを決めずに丸投げすると、あとで差分だけ見て首をひねる羽目になる。あれは地味にしんどい。