長い指示を一気に投げて、そのまま走らせる。これ、Claude Code でいちばん手戻りが増えるやり方だ。
途中で前提がズレていても、最後までそれっぽく進んでしまうのが厄介で、気づいた時には diff が太っている。そこで効くのが途中要約、つまり節目要約だ。節目ごとに「ここまでの理解」を短く言わせるだけで、ズレを早めに止められる。
Claude Code は、長い作業ほど文脈を食う。しかも人間側は「この辺で分かっているはず」と思いがちだ。だが、分かっていないまま進むことは普通にある。
要約を挟む目的は、きれいな文章を作ることではない。こちらの意図、前提、制約、残っている論点を、途中で一回棚卸しさせることだ。
たとえば、フォルダ整理でも文書作成でも同じだ。最初に雑に「整理して」「読みやすくして」と言うと、Claude Code は広く解釈する。悪気はない。むしろ素直すぎる。だから節目で止める。止めて、今どこをどう理解しているかを返させる。そこで違和感があれば、その場で直す。
実際の頼み方はこうだ。作業の最初に、途中要約のタイミングを指示しておく。
この作業は段階ごとに進めてください。
各段階の終わりで、次の3点だけ短く要約してください。
1. ここまでにやったこと
2. まだ残っていること
3. あなたが置いている前提
要約を出したら、次に進む前に必ず止まって確認を待ってください。
前提に自信がない点は、そのまま断定せずに明示してください。
これだけでだいぶ違う。Claude Code に「進めながら確認する癖」を付けられる。
特に効くのは、作業の切れ目が見える案件だ。たとえば次のような場面で使いやすい。
ここで大事なのは、要約させる場所を曖昧にしないことだ。「適宜要約して」では弱い。Claude Code は賢いが、こちらの期待する節目を自動では読まない。
「1ファイル終わるごと」「検索結果を見たあと」「編集に入る前」「差分を出す前」みたいに、節目を人間が先に決めるのが正攻法だ。
筆者は以前、複数の仕様書をまとめて直すときに、要約なしで一気に走らせて痛い目を見た。
途中の理解が微妙にずれていたのに、最後まで整った文体で押し切られたのだ。文としては悪くない。だが、用語の使い方と前提が違う。直し始めると、結局かなりの範囲を再確認する羽目になった。あれは無駄だった。節目で止めていれば、最初の10分で拾えたズレだった。
使い方のコツは、要約の粒度を絞ることだ。長い説明を返させると、要約ではなく再説明になる。そこまで要らない。必要なのは、次の作業を正しく進めるための短い点検だ。
いい要約は、長くない。むしろ短いほうが強い。
各段階の終わりに、次の形式で5行以内にまとめてください。
- 理解した目的:
- 今回の変更対象:
- まだ不明な点:
- 置いている前提:
- 次にやること:
この形にしておくと、どこでズレているかが見えやすい。
「まだ不明な点」と「置いている前提」を分けるのがコツだ。ここを混ぜると、曖昧さが隠れる。Claude Code が勝手に補完した部分と、ほんとうに確認が必要な部分がごっちゃになるからだ。
もうひとつ効くのが、要約のあとに「前提の確認」を挟むことだ。要約だけだと、ずれていてもそれっぽく見える。だから確認を入れる。
その要約の中で、こちらの意図と違いそうな点があれば先に指摘してください。
違いがなければ、そのまま次の段階に進んでください。
この一文は地味だが強い。Claude Code は丁寧に合わせに来るので、遠慮して断定しないまま進むことがある。こちらから「違っていたら言え」と明示するだけで、黙って進む事故を減らせる。
注意したいのは、要約を挟みすぎると逆にだるくなることだ。毎行ごとに止める必要はない。そこまでやると流れが切れて、かえって効率が落ちる。
節目要約は、見失いやすいところだけに打つのがちょうどいい。たとえば次のような場面だ。
要するに、「ここで前提がズレると手戻りが高くつく」という地点だ。そこ以外では、普通に進めればいい。
ファイル整理でも同じだ。たとえば、散らかった案件フォルダを見て、Claude Code に「重複っぽいものを洗い出して」と頼むなら、いきなり削除まで行かせない。まず要約を挟む。
このフォルダで見つけた重複候補、不要候補を整理してください。
実際に削除はせず、候補だけ出してください。
途中で一度、以下を要約してください。
- どの種類のファイルが多いか
- 何を重複候補として見ているか
- 削除判断に必要だが不足している情報は何か
こうしておくと、こちらが見ていない観点が出てくることがある。たとえば拡張子が違うだけで中身が同じファイル、仮版と最終版の見分けがつきにくいファイル、日付だけでは判断できないものだ。
要約を挟ませると、Claude Code が「まだ危ない」と自分で言いやすくなる。ここが大きい。
文書作成でも使える。たとえば議事録の整形や提案書の下書きだと、冒頭から最後まで一気に書かせるより、節目で理解を返させたほうが安定する。
まず、原文を読み、論点を3つに整理してください。
その後、各論点ごとに短い要約を作ってください。
最後に、こちらが見落としそうな前提や抜けを指摘してください。
ここまで終えたら止まってください。勝手に清書へ進まないでください。
この止め方があるだけで、原文の意図を飛ばしたまま美文に仕上げる事故を避けやすい。見栄えのいい文章ほど、前提のズレが隠れる。そこが地味に怖い。
節目要約は、Claude Code を「黙って進む作業機」にするのではなく、「途中で自分の理解を見せる相棒」に寄せる手だ。
作業を全部終えてから間違いに気づくより、途中で一回止めたほうがいい。これは遠回りに見えて、実際はかなりの近道だ。
ただし、何でもかんでも要約させるな、というのは強く言っておく。要約は万能ではない。要約のための往復で時間を使いすぎると、本末転倒になる。
だから、長い作業の中でも「ここを外すと後で痛い」という場所だけに絞る。そこが節目要約のいちばんうまい使い方だ。
節目の切り方に迷うなら、まずは「検索のあと」「変更前」「変更後」の3点だけ入れてみるといい。そこから先は、作業の種類に応じて増やせば十分だ。