Claude Code を使っているのに、次の依頼文が毎回まっさらなのはもったいない。
全部を覚えておく必要はない。むしろ、迷った地点だけを拾って次回に戻したほうが速い。これが「迷いどころを次回に戻す」「作業ログから改善点を拾う」という考え方だ。
作業ログには、うまくいった手順だけでなく、止まった場所や言い直した場所が残る。そこをそのまま捨てると、同じ遠回りをまた踏む。逆に、迷った部分だけを次回の依頼に織り込めば、Claude Code は最初からそこを警戒して動ける。コンテキストの無駄も減るし、手戻りも減る。地味だが効く。
筆者は最初、ログを「全部見返して全部改善」しようとして失敗した。そんなのは長続きしない。見るべきなのは、毎回出る小さな詰まりだ。たとえば、対象ディレクトリの指定が曖昧だった、出力形式を先に決めなかった、不要ファイルまで触られた、差分が肥大化した、説明書きの粒度が合わなかった。そういう場所だけでいい。
やり方は単純だ。Claude Code に作業させたあと、そのセッションの流れを見て、迷った場面を短い言葉で抜く。抜いた言葉は、次回の依頼文の冒頭か末尾に、注意書きとして入れる。長い反省文はいらない。次回の指示は、再利用できる形にするのが目的だ。
たとえば、フォルダ整理や不要ファイルの削除を Claude Code に頼んだとする。最初の依頼はこういう感じで十分だ。
このフォルダを整理したい。
重複していそうなファイル、不要なキャッシュ、空フォルダの候補を洗い出して、削除前に一覧を出してほしい。
勝手に消さず、候補を確認してから進めてください。
これで一度走らせると、たいていどこかで迷いが出る。たとえば「ダウンロード配下のどこまで見るのか」が曖昧だったり、「書類名の命名揺れをどう扱うか」が決まっていなかったりする。そこで作業ログを見る。すると、次回に戻すべき改善点は大きくない。
前回は対象範囲が広すぎて、個人用と業務用が混ざりかけた。
次回は、まずこのフォルダ配下だけを対象にする。
削除候補は必ず理由つきで一覧化して、私の確認後にのみ進める。
これだけでいい。これが「迷った地点だけを戻す」やり方だ。全部を復習するのではなく、詰まった地点を次の依頼に埋め戻す。作業ログは日記ではなく、改善メモとして使う。
開発作業でも同じだ。Claude Code に修正や調査をさせたとき、ログに残るのはコードそのものより、判断の分岐だ。どのファイルを優先するか、テストを先に見るか、既存の設計を崩さないか。そこが曖昧だと、モデルは勝手に広く見に行ってしまう。すると diff が肥大化する。筆者も最初は、関係ない箇所まで説明が広がって「で、結局どこを直したのか」がぼやけた。あれはだるい。次回に戻すべきは、修正内容ではなく判断基準のほうだった。
実際には、作業ログを読んで次の3種類に分けると扱いやすい。
ひとつ目は、対象の迷いだ。どのフォルダ、どの文書、どのファイル群を見ればいいのかが曖昧だったなら、次回の依頼で範囲を先に固定する。
対象は「請求書」フォルダのみ。
サブフォルダは含めるが、バックアップ領域は除外する。
ふたつ目は、出力の迷いだ。リストなのか、要約なのか、表なのか、判断が途中で変わったなら、最初に形式を決める。
出力は箇条書きで統一する。
各候補に、理由、影響、次に確認することを1行ずつつける。
みっつ目は、安全性の迷いだ。削除、上書き、置換のどれも、先に確認を入れたほうがいい場面がある。ここを雑にすると、あとで痛い目を見る。
削除や上書きはしない。
まず候補を出し、私が承認したものだけ実行する。
この3つは、非エンジニアの作業でもそのまま使える。たとえば、会議メモを整える、契約書のドラフトを整える、案件ごとにファイルを分ける、古い資料を片付ける。どれも「何を対象にするか」「どの形で出すか」「どこまで勝手に進めていいか」が決まっていないと、Claude Code は遠回りしやすい。だから、ログから拾うべきなのは事実の山ではなく、迷いの種類だ。
ここでやりがちな失敗がある。ログを見返して、全部を「もっと丁寧に」「もっと正確に」としか書かないことだ。これは弱い。次回の依頼に効くのは、抽象的な精神論ではない。「何を先に決めるか」「どこを確認対象にするか」「どの時点で止めるか」だ。言い換えると、次回の依頼文は、前回迷った地点に小さな柵を立てる作業になる。
筆者がよくやるのは、セッションが終わった直後に一行だけ残す方法だ。ログを全部読み返す前に、まず「次回に戻す一手」を一行で書く。
次回は、対象範囲を先に固定すること。
次回は、出力形式を最初に指定すること。
次回は、削除前の確認を必須にすること。
この一行メモがあると、次の依頼文が速い。しかも、何を改善するかがぶれない。全部を直そうとしないぶん、続く。
もう少し進めるなら、作業ログを見返したあと、次回の依頼文の末尾に「前回の迷い」を短く添えるといい。たとえばこんな具合だ。
前回は対象範囲が広がりすぎたので、今回はこのフォルダだけに絞ってください。
前回は出力形式が途中で揺れたので、今回は最初から一覧形式でお願いします。
前回は削除前の確認が遅れたので、実行前に必ず候補を出してください。
この書き方の利点は、Claude Code に「どこが地雷だったか」をそのまま伝えられることだ。人間向けの説明としても読みやすいし、毎回のプロンプトをゼロから考えなくて済む。雑に言えば、失敗を保存するのではなく、失敗の形だけを再利用するのである。
ただし、やりすぎると逆に重くなる。ログの改善点を全部入れようとすると、依頼文が注意書きだらけになる。そうなると本末転倒だ。戻すのは、毎回出る迷いだけで十分だ。たまにしか出ない特殊事情まで抱え込む必要はない。そこまでやると、次回の依頼が長文化して、読む側もやる側もだるくなる。
最後に、運用のコツをひとつだけ挙げる。作業ログは「何をやったか」より「どこで止まりかけたか」を見ることだ。成功した手順は忘れていい。迷った地点だけを拾って、次の依頼の前提に変える。この切り替えができると、Claude Code とのやり取りがかなり締まる。
次に同じ種類の仕事を頼むときは、まずログを開いて、迷いの一行だけ抜く。
それを依頼文に戻す。
それだけで、次の一回がだいぶ楽になる。