長いやり取りで一番こわいのは、Claude Code が急に変な方向へ走ることではない。前提を忘れたまま、もっともらしい修正を積み増していくことだ。これで差し戻しが増える。diff は肥大化する。こっちは「何の話だったっけ」と画面を見返す羽目になる。
そこで効くのが、節目要約、途中要約だ。会話が一定の長さになったら、いったん要点を短くまとめさせて、前提を言葉に戻す。地味だが、これを入れるだけで迷走がかなり減る。
Claude Code は、ファイルを読ませて直したり、複数ステップの作業を続けたりすると、会話の流れに引っ張られる。だから「今どこをやっていて、何を変えない方針なのか」を途中で固定し直すのが大事になる。特に、リネーム、ファイル整理、文書の推敲みたいに、見た目以上に前提が崩れやすい作業で効く。
やり方は単純だ。作業がひと区切りついたら、次のように節目要約を頼む。
ここまでの前提と、今確定している方針を5行で要約してください。
あわせて、まだ未確定の点を箇条書きで分けてください。
そのあと、次に触るべきファイルだけ挙げてください。
この頼み方のいいところは、単なる短縮ではなく、前提と未確定を分けてくれる点だ。要約だけさせると、曖昧なまま丸められることがある。そこを分けておくと、後続の修正でブレにくい。
もう少し実務寄りにするなら、要約の粒度を固定してしまうといい。
いったん区切ります。
ここまでの内容を次の形式で整理してください。
- 目的
- 変えない前提
- 変えた点
- 残っている作業
- 注意点
各項目は1〜2文で短くしてください。
この形式は、開発でも文書作成でも使いやすい。たとえばコード修正なら「変えない前提」に API 互換や既存の命名規則を残せるし、文書作成なら「変えた点」にトーンや用語統一を入れられる。ファイル整理でも同じで、「残っている作業」に重複ファイルの確認や不要フォルダの削除を残しておける。
筆者は最初、要約を頼まずにだらだら続けてしまい、途中で出てきた条件を Claude Code が見失って、同じ箇所を二度直すはめになった。しかも悪いことに、こちらも会話が長いほど「さっき言ったよな」で済ませてしまう。人間側の記憶も雑になる。節目要約を挟むと、この手戻りがかなり減る。
ただし、節目要約にも落とし穴がある。要約が長すぎると、今度は要約文そのものが新しいノイズになる。だから「全部まとめて」はやらない方がいい。短く、判断に必要なものだけ残す。長文の議事録みたいにさせると逆効果だ。
もうひとつ大事なのは、要約をそのまま最終成果物にしないことだ。要約は作業のための固定具であって、完成品ではない。会話の途中で前提を保つためのものだ。ここを混同すると、説明が妙に硬くなったり、結論が薄まったりする。
実際の使い分けはこうなる。作業が重くなってきたら、まず節目要約を入れる。次に、その要約を見ながら「この前提は残す」「この表現は直す」と指示し直す。すると Claude Code の出力がぶれにくくなる。修正箇所も追いやすい。
たとえば文書整理なら、こんな頼み方が扱いやすい。
ここまでの会話を、読者向けの説明としてズレがないか点検してください。
特に次の3点を確認してください。
1. 何を前提にしているか
2. どこがまだ未確定か
3. 次の段階で誤解されそうな表現
確認結果を短く要約したうえで、必要なら前提を1つだけ言い直してください。
これで、説明文が途中から別物になる事故を減らせる。ファイル整理でも同じで、「このフォルダは残す」「ここは削除候補」といった前提を途中で言い直させると、うっかり全消し系の雑なノリを抑えやすい。
気をつけたいのは、要約の回数を増やしすぎないことだ。毎ターン要約させると、会話のテンポが死ぬ。しかも要約ばかりになると、実作業が進まない。節目は本当に節目だけでいい。長い会話なら、章が変わるところ、方針が変わるところ、対象ファイルが増えたところで入れる。そこがちょうどいい。
会話が長くなる作業ほど、Claude Code には「今の前提」を言葉で握らせておくといい。途中要約は、そのためのいちばん手軽な止め輪だ。雑に続けるより、区切って確認する方が速い。これはかなり身もふたもないが、実務ではその方が勝つ。
必要なら次は、節目要約をさらに使いやすくするために、「要約の型を固定する方法」や「長文の依頼を途中で分割する頼み方」まで掘れる。