長いやり取りで一番まずいのは、作業そのものより「いま何の前提で話しているか」が霧になることだ。
Claude Code は賢いが、会話が積み上がるほど、古い依頼や途中の試行錯誤まで抱え込む。そこで効くのが、前提の再確認、つまり 1 行サマリで節目を打つやり方だ。
要するに、会話が長くなったら、その時点の目的・対象・制約を 1 行に圧縮してから次へ進む。
これだけで、指示の食い違い、手戻り、無駄な diff の肥大化がかなり減る。特に Claude Code では、ファイル整理でも文書作成でも、「どこまでやったか」と「今どの条件で進めるか」を毎回短く揃えるのが効く。
たとえば、最初はこんな頼み方で始める。
このプロジェクトの README を整える。外部向け説明を優先し、専門用語は減らす。まずは現状の見出し構成を整理して、不要な重複を洗い出してほしい。
ここまでは普通だ。問題は、そのあとに修正が何往復も続いたときだ。
「文章を少し柔らかくして」「やっぱり社内向けの説明も残して」「でも専門用語は減らして」と積み上がると、こちらの頭の中では当たり前でも、会話の中では条件が散らばる。Claude Code にも、古い依頼が残ったまま新しい依頼だけ足される。すると、修正の方向がじわじわぶれる。
そこで節目を打つ。次の一手の前に、こう圧縮する。
前提を確認。対象は README、目的は外部向けの読みやすさ改善、制約は専門用語を減らしつつ社内向けの説明も落としすぎないこと。ここから見出し整理を続けて。
この 1 行サマリは、長文の説明を短くするためのものではない。
会話の「今の状態」を固定するためのものだ。前提が固定されると、Claude Code は余計な再解釈をしにくくなる。人間側も、何を維持し、何を変えるべきかを見失いにくい。
筆者は以前、ファイル整理の作業でこれをサボって痛い目を見た。
最初は「重複しそうな資料名を整理して、古い下書きをまとめる」つもりだったのに、途中で「契約書だけは残す」「請求書は月別に分ける」「一部は削除ではなく退避」が混ざっていった。会話のどこにも、最後の前提が短くまとまっていなかったせいで、Claude Code の提案が途中から別ルール前提になった。結果、確認し直す回数が増え、むしろ遅くなった。こういうのは地味にだるい。最初から 1 行で締めておけば済んだ話だった。
実務での使い方は単純でいい。節目はだいたい次の場面だ。
修正が 2 回以上続いたとき。
別の観点が増えたとき。
対象ファイルや対象文書が切り替わるとき。
「さっきの話を前提にしているはず」が少しでも怪しいとき。
そのたびに、会話を再開する前のひとことを入れる。コツは、説明しすぎないことだ。長い背景説明を書き直す必要はない。今の判断に必要な要素だけを並べる。
前提を 1 行で整理する。対象は A で、目的は B、残す条件は C、避けたいことは D。
この型は、非エンジニアの作業にもそのまま使える。たとえば書面作成ならこうだ。
前提を確認。対象は取引先向けの案内文、目的は誤解を減らすこと、制約は専門用語を避けて短くすること。ここから表現を整える。
ディスク整理ならこうなる。
前提を整理。対象は写真フォルダ、目的は重複と不要なキャッシュの削減、制約は元データは消さず退避を優先すること。次は候補を絞って。
このやり方で大事なのは、1 行サマリを「要約」だと思わないことだ。
要約は過去の説明を縮める行為だが、前提の再確認は未来の作業を縛る行為である。ここを混同すると、ただのメモで終わる。効くのは、次の出力をその前提で走らせることだ。
逆にやってはいけないのは、1 行サマリを長くしすぎることだ。
長いサマリは、もはやサマリではない。条件を 5 個も 6 個も詰め込むと、今度は読む側の負担が増える。Claude Code にも人間にも重い。1 行で収まらないなら、条件が多すぎるか、会話を分けるべきだ。整理の粒度がおかしいサインでもある。
もう一つ、節目の前提確認は「前のやり取りを全部忘れさせる」ために打つわけでもない。
むしろ逆だ。必要な文脈だけ残し、今いらない枝葉を切る。だから、「この前の案を前提に」と言うより、「今の前提はこれ」と言い切ったほうが安定する。会話が長くなるほど、古い指示は自然に重くなるからだ。
Claude Code を使うときは、作業の途中でこういう短い仕切りを入れる癖があるだけで、だいぶ扱いやすくなる。特に、文書作成やファイル整理のように「正解はひとつではないが、外したくはない」仕事で効く。細かい指示を増やすより、節目で前提を 1 行に圧縮したほうが、結果がぶれない。
会話が長くなったら、続きを書く前に一度、今の条件を短く言い直す。これだけで、手戻りは目に見えて減る。