Claude Code を使うと、気持ちよく進みすぎることがある。そこが落とし穴だ。黙々と走らせたあとで、最後に「違う、そうじゃない」となる。あれはだいぶだるい。
だから最初にやるべきなのは、途中報告の頻度を決めることだ。別名でいうと「途中報告の頻度を決める」だし、要は、どのくらいの間隔で状態を返せば止めどきが見えるかを先に縛る作業である。これを入れておくと、Claude Code が勝手に深追いして、後から大きく戻す事故をかなり減らせる。
特に効くのは、リポジトリ整理、不要ファイルの洗い出し、文章の下書き、複数ファイルの一括修正みたいな作業だ。どれも「一見うまく進んでいるように見えて、実は方向がズレていた」が起きやすい。進捗が見えないまま長く走らせると、コンテキストも時間も無駄になる。
最初にこう言ってしまえばいい。
20〜30分ごとに途中報告して。今やっていること、終わったこと、次にやること、気になる点を短く返して。止めて確認が必要そうなら、その時点で止まって聞いて。
もう少し作業寄りにするなら、こう書く。
途中報告の頻度を先に決める。各ファイル群の処理が終わるたび、または作業の区切りごとに報告してほしい。報告には次を入れてほしい。
- 何を終えたか
- 今どこまで進んだか
- 次に何をするか
- 判断が必要な点があるか
このくらいで十分だ。細かすぎるルールは逆にうるさい。だが何も決めないのは最悪で、Claude Code がいい感じに走り続けたあとに、肝心の変更方針が違っていた、という流れになりやすい。
実際、筆者は最初、こういう依頼を雑に出して失敗したことがある。
このフォルダを整理して、不要なものを消して。
これだと、どこで区切って見ればいいかがない。Claude Code が一気に判断して、一気に手を入れる。あとで「その削除は残したかった」と気づくと面倒だ。だから、単に「やって」ではなく、「どこまでやったら報告するか」を先に決める必要がある。
ファイル整理なら、区切りはかなり作りやすい。たとえばフォルダ単位、種類単位、あるいは 20 件ごとみたいに切れる。文書作成なら、章ごと、節ごと、あるいは見出し 3 本ごとでもいい。非エンジニアでも、ここは難しくない。大事なのは「人間が確認したい粒度」に合わせることだ。
たとえば、こんな依頼文にしておくと扱いやすい。
この案件フォルダ内を整理して。削除は先に確認してからにして。
途中報告は、作業の区切りごとに入れてほしい。報告では、
- 何を確認したか
- 何を残す判断にしたか
- 削除候補として挙がっているもの
を短く教えて。
報告が来たら、その時点で止まって確認を待って。
文書作成でも同じだ。
この文章を3章構成で下書きして。各章が終わるたびに途中報告して、内容のズレがないか確認できるようにして。
途中報告を先に決める利点は、作業の暴走を止めるだけではない。あとで読み返すときに、どこで何を考えていたかが分かる。これは地味に効く。特に複数ファイルをまたぐ修正では、diff が膨らむ前に止められるかどうかで疲れ方が変わる。
ただし、ここでやりがちな失敗がある。報告頻度を細かくしすぎることだ。たとえば「1ファイルごとに毎回報告して」とやると、かえって流れが切れる。小さな修正ならまだいいが、少し長い作業では報告がノイズになる。人間側の確認コストが上がるだけだ。
逆に粗すぎるのもだめだ。「最後に一回だけ報告して」は、途中でズレても誰も気づけない。筆者はこれで、不要なファイル削除の判断を最後まで見逃して、あとから復旧作業をしたことがある。途中で一回止めていれば済んだ話だった。あれは無駄だった。
ちょうどいいのは、作業の性質で決めるやり方だ。目安はこう考えると分かりやすい。
Claude Code への出し方も、ここははっきり書いたほうがいい。「いい感じに適宜」は、人間には通じても、機械に任せるには曖昧すぎる。たとえば、こんなふうだ。
作業中は、次のいずれかで途中報告して。
- フォルダ単位の処理が終わったとき
- 10件のファイルを見たとき
- 方針を変える必要が出たとき
報告内容は簡潔でいいが、判断に迷っている点があれば必ず書いて。
この手の指示は、長く続く作業ほど効いてくる。途中報告の頻度を先に決めると、Claude Code は独走しにくくなるし、こちらも「今どこまで進んでいるか」を見失いにくい。結果として、修正のやり直しが減る。
必要なら次は、報告の「頻度」だけでなく「報告の型」も固定するといい。たとえば毎回、終わったこと・気になること・次にやることの3点セットにする。これだけで、ただの進捗連絡が、確認しやすい作業メモになる。黙って進ませないための工夫は、結局このくらい具体的でいい。