2026-08-01

途中報告の頻度を決めて、黙って進ませすぎない

Claude Code に雑に「いい感じに進めて」と投げると、あとで見たときに気持ちよく進んでいるようでいて、実はだいぶ怖い。勝手に進む時間が長いほど、手戻りは重くなる。進捗報告の粒度を決める、節目だけ返させる。この二つを先に決めておくだけで、黙って深掘りしすぎる事故はかなり減る。

特に Claude Code は、仕事が進むほど差分が大きくなりやすい。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初に方向を外すと、そのまま大量の変更を積み上げてから「これでいい？」と出してくる。そこで止めると、確認も修正も重い。逆に途中報告を細かくしすぎると、今度は毎回止まりすぎて、こちらの集中が切れる。だから大事なのは、止める回数ではなく、止める場所を決めることだ。

たとえば、最初にこう指示する。

まず作業方針を3行で出してから進めてください。
以後は、各主要ステップの完了ごとに短く途中報告してください。
実装や整理を勝手に最後まで進めず、節目で止まって確認を求めてください。

これだけでもだいぶ違う。ポイントは「何分ごとに報告」ではなく「どの節目で報告」かを指定することだ。Claude Code は時間だけでは判断しにくい。ファイルを読む、候補を洗う、1まとまりの編集を終える、差分を出す。こういう区切りで止めたほうが、内容の意味がある。

もう少し実務っぽく書くなら、依頼文に次を入れておくといい。

進捗報告は次の節目でしてください。
- 調査を終えたとき
- 編集方針が固まったとき
- ひとまとまりの変更を入れたとき
- 判断が分かれる点が出たとき

報告は長文にせず、何を見たか、何を変える予定か、次に確認が必要な点だけを書いてください。

この形にしておくと、報告がだらだら増えない。単なる実況中継にしないのがコツだ。こちらが知りたいのは「今どこまで終わったか」と「危ない分岐があるか」であって、全部の思考過程ではない。そこを切る。

筆者は最初、この手の指示をサボって痛い目を見たことがある。書類整理を頼んで、不要ファイルの候補を洗わせたまではよかったのに、こちらが見ていないうちにかなり広く削除候補をまとめ始めた。結果、確認の段階で「そこは残すつもりだった」が出てきて、差し戻しが面倒になった。節目で止めていれば、候補の絞り込みだけで済んだ話だ。黙って最後までやらせると、完成度が高いように見えて、修正コストだけが跳ねる。

非エンジニアなら、たとえばこんな頼み方が使いやすい。

案件フォルダの中を整理してください。
ただし、削除や移動はすぐに実行せず、まず候補を出してください。
途中報告は「分類が終わったとき」「重複の可能性を見つけたとき」「削除候補が固まったとき」にしてください。
各報告では、判断に迷うファイル名をそのまま挙げてください。

この頼み方のいいところは、作業を止めるためではなく、判断を渡すために止める点にある。いきなり全部やらせると、Claude Code は便利な手足になる一方で、こちらの確認が追いつかない。途中報告を挟むと、こちらは「ここまではOK、ここから先は待て」と切れる。

コード作業なら、さらにはっきり書くといい。

次の順で進めてください。
1. 変更方針を3点で要約する
2. 関係ファイルを確認する
3. 1つ目のまとまりだけ修正する
4. diff を出して止まる

各段階の終わりで短く報告し、次の段階に進む前に確認を求めてください。

ここで大事なのは、報告の頻度を「作業量」に合わせることだ。小さな修正なら1回で十分だし、広い影響があるなら2回、3回と増やしていい。全部同じテンポにすると、浅い作業ではうるさく、重い作業では粗くなる。粒度は固定ではなく、案件ごとに変えるものだ。

やってはいけないのは、報告だけ細かくして中身を曖昧にすることだ。たとえば「適宜報告してください」だけでは弱い。これでは Claude Code も勝手に解釈する。逆に「5分ごとに報告」も意味が薄い。ファイルが少ない整理なら5分は長すぎるし、大きなリファクタなら5分では切れない。時間指定は補助でしかない。使うなら「長くなりそうなときは各まとまり後に報告し、何も進めず確認待ちにする」と合わせるのが筋だ。

もう一つ、途中報告を入れるなら、報告の中身も絞るべきだ。長い進捗ログは読み返されない。次の3点だけで足りることが多い。