途中報告がうるさい。だから全部止める。これ、かなり雑なやり方だ。
Claude Code の進行中出力は、進捗報告、節目の報告、途中経過の出し方をきちんと決めないと、静かすぎて不安になるか、逆に細切れすぎて読めないかのどちらかになる。
大事なのは「黙らせる」か「節目だけ返させる」かを、作業の種類ごとに切り分けることだ。ファイル整理でも、文書作成でも、コード修正でも同じで、途中経過を全部見たい場面は少ない。見たいのは、止まったのか、方向がずれたのか、もうすぐ終わるのか、その三つだけである。
筆者も最初は、途中の考えごとまで全部見せてもらうほうが安心だと思っていた。だが実際は、出力が増えるほどコンテキストが汚れる。人間が「いま何してるんだっけ」と往復し始める。しかも、細かい進捗を逐一返させる頼み方は、成果物より実況にトークンを食う。地味にだるい。
Claude Code で粒度を決めるときは、まず仕事を二種類に分けるといい。ひとつは、黙って最後まで走らせる仕事。もうひとつは、節目だけ返させる仕事だ。
黙って走らせるのは、たとえば単純な移動、重複ファイルの洗い出し、既存文書の整形、指定フォルダの一覧化みたいなものだ。ここで途中報告を入れさせると、確認コストのほうが重くなる。必要なのは最終結果だ。
節目だけ返させるのは、調査が混じる作業、複数ファイルをまたぐ整理、内容を見比べながら書き直す作業だ。たとえば「この案件フォルダを読み、重複している書類候補を挙げ、最後に削除候補だけ報告してほしい」といったケースである。途中の雑談はいらないが、何を基準に判断したかは見たい。そこで節目の報告が効く。
実際の頼み方は、かなり素直でいい。曖昧に「いい感じに進めて」と頼むより、報告の条件を最初に縛るほうが強い。
この作業は途中報告を最小限にして進めてください。
止まったときだけ理由を出し、通常は最後に結果だけ報告してください。
確認が必要な判断が出た場合は、その時点で止まって相談してください。
節目だけ返させたいなら、こう書く。
この作業は、各段階の完了時にだけ短く報告してください。
報告内容は「完了した処理」「次にやること」「止まっている理由」が分かる最小限にしてください。
細かな試行錯誤は省いてください。
ここで大事なのは、「何を報告するか」だけでなく「何を報告しないか」も言うことだ。Claude Code は親切なので、指示が甘いと説明を足したがる。人間が欲しいのは、だいたい短い要約だ。試行錯誤の実況ではない。
筆者は以前、文書整理の仕事で「進捗を丁寧に教えてほしい」とだけ書いたことがある。結果、各ファイルを読み終えるたびに要約が返ってきて、こちらは確認作業だけで疲れた。しかも要約を読んでいる間に、次の判断が必要かどうかが分からず、結局止まる。あれは最悪だった。途中報告は、増やせば安心というものではない。
逆に、完全に黙らせると困る場面もある。たとえば大量ファイルの整理や、複数案の比較のように、途中で判断を誤ると手戻りが大きい仕事だ。ここで無音にしすぎると、気づいたときには方向違いのまま長く走っていた、という事故が起きる。だから「節目で止まれ」を入れる。
作業は基本的に黙って進めてください。
ただし、次のどれかに当てはまる場合だけ停止して報告してください。
- 破壊的な変更が必要
- 判断基準があいまいで分岐する
- 影響範囲が広い
- 入力不足で先に進めない
それ以外は最後まで進めてください。
これで十分だ。細かい実況を減らしつつ、危ない場面だけ人間に戻せる。
非エンジニアの使い方でも、この考え方はそのまま効く。たとえば大量の書類を案件ごとに分けたいとき、全部の途中経過を出させる必要はない。最初に「分類基準を決める」「迷ったものだけ一覧で止まる」「最後に移動先をまとめる」と決めておけばいい。重複ファイルを探すときも同じだ。全部の候補を逐一説明させるより、重複の可能性があるものを列挙し、削除前に止めるほうが実用的である。
ただし、節目の粒度を細かくしすぎると、結局またうるさい。ここでの「節目」は、工程の区切りであって、1ファイルごとの報告ではない。
たとえば、資料作成なら「素材収集が終わった」「下書きができた」「体裁を整えた」の三段階で十分だ。コード修正なら「調査」「修正」「確認」で足りる。報告のたびに人間が判断を挟むと、仕事の速度が落ちる。そこまでして実況させる理由はない。
実務で使うなら、頼み方はこのくらいがちょうどいい。
この作業では、途中報告は最小限にしてください。
次のタイミングだけ報告してください。
1. 作業を続ける前に人間の判断が必要なとき
2. 想定より大きい変更が必要になったとき
3. 1つの大きな工程が終わったとき
報告は2〜3行で短くしてください。
もう少し強く制御したいなら、冒頭で役割をはっきりさせるといい。
あなたはこの作業を静かに進める。
途中経過の詳細は出さない。
節目でだけ短く止まり、必要な確認事項だけ聞く。
作業完了時に、実施内容と残りの注意点をまとめて報告する。
こういう指定をしておくと、途中報告の粒度がぶれにくい。地味だが効く。
そして、黙らせるにせよ節目だけ返させるにせよ、最後にほしいのは「何が終わったか」と「次に人間が何を見るべきか」だけだ。そこさえ押さえれば、途中経過のノイズはかなり減る。
次に詰まりやすいのは、粒度の決め方を作業の最初に置かないことだ。途中で「やっぱり報告多すぎる」と言っても遅い。最初の指示で、静かに進める範囲と、止まってほしい条件を固定しておく。これで手戻りがかなり減る。
Claude Code は、報告を減らすと仕事が雑になる道具ではない。むしろ逆で、無駄な実況を削ったほうが、判断のいる場面がくっきりする。
途中報告は多ければ親切ではない。必要な瞬間にだけ鳴るのが正しい。そこを決めておくと、Claude Code はかなり扱いやすくなる。