長い会話をそのまま流しっぱなしにすると、Claude Code は平気な顔で文脈を抱えたまま進む。これが曲者だ。人間は「ここまでの話、何だったっけ」となり、モデル側も要点の輪郭がぼやけてくる。そこで入れるのが途中要約、節目の要約、要点整理である。会話の途中で一度立ち止まらせ、ここまでの決定事項・未決事項・次にやることを短く並べ直させる。これだけで、手戻りがかなり減る。
筆者は以前、ファイル整理の作業を Claude Code に任せて、削除候補の洗い出しをだらだら続けたことがある。最初はよかったのに、途中から「さっきの条件」と「今回の条件」が混線して、同じフォルダを二度見させる羽目になった。最後に要約を挟んでおけば、こんな無駄はだいぶ防げたはずだ。長話は、賢さの証明ではない。たいていはコンテキストの浪費だ。
やり方は単純で、会話の節目でこう頼めばいい。
ここまでの内容を、次の3点に分けて短く要約して。
1. 決まったこと
2. まだ曖昧なこと
3. 次にやること
要約は箇条書きで、各項目は1行ずつ。余計な説明は増やさないで。
この依頼文の肝は、「何を要約するか」を先に決めている点だ。単に「要約して」だけだと、会話の雰囲気まで雑に縮めて終わることがある。欲しいのは空気の短縮ではなく、判断材料の再配置だ。Claude Code にもそこをはっきり渡したほうがいい。
少し作業寄りにするなら、こういう節目の置き方が使いやすい。
いったんここで途中要約を入れてください。
ここまでに出た前提、採用した案、保留にした点を整理して、
私が次の指示を出しやすい形に直してください。
この言い方は、コード修正でも文書作成でも効く。たとえば、README を整える作業なら「どの章を残すか」「何を削ったか」「次に直す候補は何か」が見える。逆に、会話の途中で雑に話題が飛んでいるときは、要約を挟むだけで散らかった線が少し戻る。人間の頭にも効くし、モデルの出力も締まる。
節目は、毎回同じ間隔で入れればいいわけではない。長さではなく、意味が切り替わる場所で入れるのが大事だ。たとえば、方針を決めた直後、複数案を比較し終えた直後、ファイルの仕分けルールを確定した直後だ。ここで要約を挟むと、その後の作業がぶれにくい。
Claude Code に向いているのは、次のような場面である。
ここで気をつけたいのは、要約を「会話の飾り」にしないことだ。要約を頼んだのに、同じ話を長く言い換えるだけでは意味がない。特に Claude Code は、丁寧に聞けば聞くほど説明を増やす方向に寄りやすい。筆者も最初は「詳しく要約してください」と曖昧に言って、結局は説明を増やしてもらうだけになった。欲しいのは詳しさではなく、次の行動に使える圧縮だ。
だから、要約には役割を与えるべきだ。たとえば「決定事項だけ残す」「未確定点だけ抜き出す」「危ない箇所を先に出す」といった具合である。
ここまでのやり取りから、次の作業に必要な情報だけを抜き出して。
- 変更を確定した点
- まだ決めていない点
- 作業を止めるべき注意点
元の説明の言い回しは不要。実務で使える短さにして。
これで、ただの感想文みたいな要約はかなり減る。要約の質が上がると、会話の後半で「前にそう言ったよね」という齟齬も減る。地味だが効く。地味だからこそ、後で効いてくる。
非エンジニアの使い方でも同じだ。たとえば、契約書の下書きを整えたり、案件ごとの資料フォルダを整理したりするときに、途中で「今の整理方針」を要約させると迷子になりにくい。ファイル名の命名ルール、残す資料、捨てる候補を一度並べ直せば、次の指示が出しやすくなる。作業の勢いだけで進めると、あとで「どれが最新版だっけ」となる。あれはだるい。要約は、そのだるさを先に潰すための道具だ。
最後に一つだけ、やりがちな失敗を挙げる。節目の要約を入れたあとに、その要約を見返さず、また同じ話を続けることだ。これでは意味が半分しかない。要約は読み返して初めて効く。次の指示を出す前に、「決まったこと」と「保留」が本当に整理されているかを見る。この一手間で、会話の後半がかなり軽くなる。
長いやり取りを全部記憶力で押し切ろうとしないことだ。要約を挟み、会話を区切り、前提を固定する。Claude Code を長く使うほど、この習慣の価値が出る。必要なら最後にこう頼めばいい。
ここまでの会話を、次の指示の土台になる形で短く要約して。
特に、決まったことと未決事項を分けて書いて。
これで十分だ。余計な気合いはいらない。節目で一度整理するだけで、長い会話はずっと扱いやすくなる。