長い会話ほど、相手はちゃんと理解しているふりをする。Claude Code でもここが地味に危ない。
途中で要約を一回挟まないと、最初の前提が少しずつずれて、最後には「思ってたのと違う」が出来上がる。これ、コード修正でもファイル整理でも文書作成でも同じだ。
別名で言えば「会話が長くなったら節目で要約させる」だ。要するに、こちらが勝手に次へ進まず、途中で Claude Code に今の理解を言い直させる。すると、解釈違い、対象範囲の取り違え、やるべきことの抜けが早めに見つかる。手戻りが減る。差分も無駄に育ちにくい。
筆者は最初、これをサボって何度か痛い目を見た。大きめのリファクタリングを流しっぱなしにしていたら、途中から「古いほうのディレクトリも触るのか」「要らないキャッシュは消していいのか」が曖昧なまま進み、最後に修正のやり直しが出た。会話の後半でズレが見つかると、修正対象が増えたぶんだけコンテキストも消耗する。先に止めたほうがずっと安い。
やり方は単純だ。長い依頼を一気に投げるのではなく、節目ごとに「ここまでの理解を要約して」と挟む。Claude Code は会話の流れを読めるが、読めるからこそ人間側が確認を省くとズレが残る。
たとえば、フォルダ整理や文書整理ならこんな感じでいい。
この作業は少し長くなりそうです。いまの理解を3点で要約してください。
- 何を対象にしているか
- 何を残し、何を削除または移動する想定か
- まだ判断が必要な点はどこか
要約のあと、前提がずれていないか確認してから次に進みたいです。
コード修正なら、もう少し厳しめに止めると効く。
ここまでの変更方針を要約してください。
特に次の点を明示してください。
1. 変更対象のファイル
2. 影響範囲
3. まだ未確定の前提
4. 私が確認すべき点
要約を読んで、前提が合っていれば次の作業を続けてください。
文書作成なら、読み手の想定がぶれやすいので、要約の粒度を少し上げるといい。
ここまでの内容を、次の形式で短く要約してください。
- 読み手は誰か
- この文書の目的は何か
- まだ決めていない論点は何か
- いま採用している前提は何か
前提が違っていたら、この段階で直したいです。
この手の要約は、単なる復唱では足りない。大事なのは「何を前提にして動いているか」を言わせることだ。
ファイル整理なら「削除してよいもの」と「保管するもの」の境界。文書作成なら「誰に向けた文書か」。コードなら「どこまで壊してよいか」。ここが曖昧だと、Claude Code はそれなりに筋の通った作業をしてしまう。筋が通っているのに違う、がいちばん厄介だ。
途中要約を入れるタイミングは、作業の区切りに合わせるのが素直だ。たとえば、対象を列挙し終えたあと、削除候補を出し終えたあと、実装方針を決めたあと、長い文章を章ごとにまとめ終えたあと。節目がないまま延々と続けるより、そこで一回止めたほうが安全だ。
ただし、毎ターン要約させればいいわけではない。やりすぎると会話が重くなるし、テンポも落ちる。筆者も最初は不安で何度も要約を挟んだが、さすがにくどかった。要約は「方向がずれたら困るところ」にだけ入れるのがちょうどいい。機械に毎回うなずかせる必要はない。重要なのは、止めどころをこちらが決めることだ。
もう一つ、要約を見て安心しすぎないこと。要約がうまくても、実際の変更内容まで正しいとは限らない。特にClaude Codeにファイル操作やコード編集を続けさせるときは、要約で前提を合わせたあと、差分や対象ファイルをちゃんと見る。要約は安全装置であって、検品の代わりではない。
実務で一番効くのは、要約に「不明点」も必ず出させるやり方だ。これを入れると、相手が勝手に埋めた空白が見える。人間は空白を見落とすが、要約させると空白が輪郭を持つ。
ここまでの理解を要約してください。
あわせて、あなたがまだ確信できていない点を列挙してください。
その不明点を解消しないと、誤った作業になりそうなら、そこで止めて質問してください。
この一文が地味に効く。勝手に進めるより、止まるほうが強いからだ。長い会話の雑音を減らしたいなら、途中要約はかなり優秀なやり方になる。
もしこの手の使い方をもう一段ちゃんと整えるなら、次に見るべきは「最初に制約をはっきり渡すこと」だ。節目で要約させるのは、ズレを早めに見つけるための後追いの工夫でしかない。最初の依頼がぼやけていると、要約もぼやける。そこを詰めると、Claude Code はだいぶ扱いやすくなる。