途中までちゃんと合っていたのに、最後の最後でズレる。Claude Code ではこれがいちばん面倒だ。たいてい原因は、最初の前提が少しずつ摩耗していることにある。定期要約、会話の棚卸し、前提の再確認を途中で挟むだけで、この手の手戻りはかなり減る。
長い作業を丸投げするときほど、モデルは「今どこまで合意済みか」を取り違えやすい。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初は「不要ファイルだけ消して」と頼んだのに、途中から「似た名前のフォルダも整理しておきました」と広がっていく。ありがたいようで、実は危ない。あなたが欲しかったのは、勝手な拡張ではなく、最初の意図を保ったままの実行だ。
このズレを止める方法は単純で、途中で一回、短く要約させることだ。やっていることは、会話の棚卸しだと思えばいい。今の理解、終わったこと、未確定のことを切り分けさせる。前提の再確認まで入れればなおよい。
たとえば、Claude Code に長めの作業を頼む前に、最初からこう指示しておく。
この作業は長くなるので、途中でいったん要約を挟んでください。
その時点で、
1. ここまでに確定した前提
2. 実施済みの作業
3. まだ未確定な点
4. 次に確認したいこと
を短く整理して、私に確認を求めてください。
勝手に前提を広げず、要約で止まってください。
これだけで十分効く。ポイントは「要約して」だけで終わらせないことだ。単なる要約だと、ただの読み返しで終わる。欲しいのは、作業の継続前に前提を止める仕組みだ。だから「どこまで確定したか」「何が未確定か」を分けて出させる。ここが肝だ。
文書作成なら、途中で章ごとに棚卸しさせると強い。たとえば契約書のたたき台、社内手順書、議事録の整形みたいな用途だ。以下のように区切る。
各セクションを書き終えたら、次に進む前に必ず要約してください。
要約には、採用した表現、判断の根拠、曖昧な点を含めてください。
私が「続けて」と言うまで、次のセクションには進まないでください。
ファイル整理でも同じだ。ディスク削減や重複削除のような作業は、途中で前提がズレると痛い。最初は「キャッシュだけ消す」つもりだったのに、似た名前のアーカイブや、昔の納品物まで巻き込む。筆者は以前、フォルダの棚卸しを任せていたときに、作業の途中で「この命名規則ならこちらも整理できます」と広げられて、確認せずに進めかけたことがある。こういうときに中間要約を入れていれば、勝手な拡張をその場で止められた。
実務では、要約のタイミングを決めておくとさらに安定する。たとえば次のどれかだ。
Claude Code に明示するなら、こうなる。
作業が一定量進んだら、必ず作業を止めて要約してください。
要約では、変更したファイル、判断した内容、まだ触っていない部分を分けて書いてください。
要約後は、次に進む前に私の確認を待ってください。
ここでやりがちな失敗がひとつある。要約を「長く書くこと」だと勘違いすることだ。長い要約はむしろ邪魔だ。必要なのは、次の判断に使える要点だけだ。冗長な要約はコンテキストも食うし、読み手の注意も削る。会話の棚卸しは、棚卸しであって作文ではない。
もうひとつの落とし穴は、要約に「現状の前提」を入れないことだ。単に「ここまで完了しました」では弱い。前提がズレていないかを見るには、何を正として動いているかが要る。たとえば、文書なら「読者は社内向け」「口調は断定的」「表記は全角統一」のようなルールだ。コードなら「対象はこのディレクトリだけ」「削除ではなく提案止まり」「テストが通ることを優先」みたいな制約になる。これを要約に含めると、ズレが一気に見つかる。
途中の要約には、次の前提も含めてください。
- この作業の対象範囲
- やってよいこと／だめなこと
- 今の判断基準
- まだ確認待ちの点
会話が長くなるほど、Claude Code は「もっともらしい補完」をしやすくなる。そこを止めるには、こちらが止めるしかない。便利だから任せ切る、ではなく、節目で前提を握り直す。これが地味に効く。
応用するなら、最初の指示に「要約のあとに確認質問を1つ以上出す」と足すといい。モデルに勝手に進ませず、疑問点を表面化させるためだ。たとえばこうだ。
途中要約のあと、あなたが迷っている点を1つ以上質問してください。
私はその質問に答えるまで、次の処理を進めないでください。
このやり方は、開発作業だけの話ではない。フォルダ整理、原稿の整形、長いメールの下書き、会議メモの清書でも効く。要するに、途中で前提を再確認できる場を作ればいい。Claude Code は速い。だからこそ、走りながら一回止める設計が大事になる。止め方が下手だと、速さがそのまま手戻りになる。そこはけっこう容赦がない。