「あとで見返せばわかる」と思って、肝心な迷い方を残していない。これがいちばんもったいない。Claude Code は作業を進める道具としては強いが、勝手に次回のための教材まで整えてくれるわけではない。だからこそ、作業ログの確認、つまり振り返りを一手間足して、迷った地点を拾い上げておくと効く。
この TIPS の狙いは、作業が終わったあとに「何をしたか」を眺めることではない。どこで詰まり、どの指示が曖昧で、どの切り分けで前に進んだかを回収して、次の依頼文にそのまま埋め込める形にすることだ。これをやると、同じ迷子を何度もやらなくて済む。特に、ファイル整理、文書作成、不要ファイルの洗い出しみたいな用途では、作業の“正解”より“迷い方”のほうが再利用しやすい。
まずやることは単純だ。Claude Code に任せた作業を終えたら、その場でログを見返し、迷った瞬間だけ抜き出す。全部読む必要はない。雑に全部読むと、ただの記録で終わる。見るべきなのは、こちらが何を曖昧に頼んだか、Claude Code がどこで確認を返したか、こちらがどの追加条件を後出ししたか、の三つだ。
たとえば、書類整理の案件でこういう頼み方をしたとする。
このフォルダ内の資料を整理して、重複っぽいものをまとめてください。
これだと、どこまでを「重複っぽい」と見るか、名前が似ているだけの別物をどう扱うか、古い版を残すかどうかが毎回ぶれる。作業ログを見返すと、たいてい途中で「これは同一案件の別版ですか」「削除前に候補を出しますか」みたいな確認が返っているはずだ。そこが迷った地点だ。次回は、最初の指示にこの判断基準を入れる。
このフォルダ内の資料を整理してください。
同名ファイルは、更新日と内容の差分を見て候補を分けてください。
削除はしないで、まずは重複候補一覧を出してください。
案件ごとに残すべき最終版が分かる場合は、ファイル名に「final」などが入っていても鵜呑みにせず、中身を見て判断してください。
こうしておくと、Claude Code の確認ラリーが減る。コンテキストも節約できるし、出てくる成果物も安定する。地味だが効く。
開発作業でも同じだ。筆者は以前、コード修正をまとめて頼んだあと、あとから diff を見て「ここ、意図が曖昧だったせいで別の実装案まで出させてしまった」と気づいたことがある。原因は、作業ログを見返さず、最後の成果物だけ見て満足したことだ。ログを追うと、途中で「既存の関数を壊さないでほしいのか」「小さく直すのか、ついでに構造を変えるのか」が何度も揺れていた。次回は、この揺れを先に固定する。
この修正は、既存の関数の外から見える挙動を変えずに、小さく直してください。
リファクタリングは最小限にして、動作確認しやすい差分にしてください。
もし方針が分かれるなら、先に選択肢を並べて、勝手に大きく変えないでください。
ここで大事なのは、ログから「正解」を探すことではない。迷った理由を探すことだ。理由がわかると、次回の依頼文は自然に良くなる。
見返すときは、次の三点だけ拾えば十分だ。
まず、こちらの指示が曖昧だった箇所だ。「整理して」「いい感じにして」「不要なものを消して」は、だいたい迷いを生む。Claude Code は察してくれる場面もあるが、察してほしい部分が増えるほど、確認が増えたり、想定と違う方向に進んだりする。
次に、途中でこちらが条件を足した箇所だ。最初は「一覧にして」と言っていたのに、途中で「やっぱり削除候補まで出して」「いや、削除はしないで」と変えたなら、その変更点は次回の最初から書いてしまえばいい。後出しは作業を壊す。
最後に、うまくいった切り分けだ。たとえば「名前ではなく内容で判定した」「削除せず候補を出した」「まずは件数を数えた」など、うまくいった道筋はそのまま再利用できる。成功パターンは、失敗談よりずっと価値があるのに、放っておくと消える。
ログの確認を習慣にするとき、やりがちな落とし穴がある。長いログを全部なめて、結局何も残さないことだ。これが一番だるい。見るポイントを絞らないと、ただの読書になる。だから、作業後に毎回これだけ抜く、と決めておくといい。
今回の作業で迷った点を3つに絞って、次回用の指示文に直してください。
各項目は、
- 何が曖昧だったか
- 次回はどう書けばいいか
- それでも迷うなら先に確認したいこと
の形でまとめてください。
Claude Code 自身にこうやって整理させるのはかなり相性がいい。人間がログを読みながら要約すると、どうしても印象で丸めがちだが、エージェントに「曖昧だった点の抽出」をやらせると、会話のどこで判断が揺れたかを拾いやすい。もちろん、最後は人間が見る。自動で出したメモをそのまま採用するのは危ない。要約の粒度がずれていることがあるからだ。
実務で使うなら、次回用のメモは“作業メモ”ではなく“依頼文の部品”にして残すといい。たとえば、フォルダ整理ならこんな具合だ。
次回の整理依頼では、最初に以下を明記する。
- 対象フォルダ
- 残す基準
- 削除の可否
- 重複判定の方法
- 先に一覧だけ出すか、直接処理するか
これをテンプレとして残しておけば、毎回ログをゼロから掘り返さなくて済む。文書作成でも同じで、「誰向けの文書か」「既存文書との整合をどう取るか」「用語は統一するか」を先に書いておくと、やり直しが減る。
ひとつ注意がある。作業ログを見返すとき、途中で出たエラーや確認メッセージをそのまま全部メモするのは逆効果だ。重要なのはメッセージの文言ではなく、そこで何を直したかだ。エラー文をコレクションしても、次回の依頼文にはなりにくい。必要なのは「この条件だと対象が広すぎた」「この指定だと除外条件が足りなかった」という、再発防止の形だ。
もうひとつ、Claude Code に毎回ログの要約まで任せきりにしないほうがいい。任せると楽ではあるが、こちらが本当に気にすべき迷いと、ただの会話の揺れが同じ温度で出てくることがある。ここをそのまま信じると、次回の指示が妙に長くなる。長いだけの指示はだいたい弱い。短く、判断点がはっきりしているほうが強い。
このやり方が効くのは、Claude Code を開発に使う人だけではない。大量の資料を整える人、不要ファイルを削る人、章立ての整った文書を作りたい人にもそのまま通る。違うのは対象物ではなく、迷いの種類だけだ。だから、ログを見返す習慣を作るときは、成果物より「どこで止まったか」を残す。そこが次回いちばん役に立つ。
作業のたびに全部を完璧に記録する必要はない。むしろ、迷った地点だけを1回3分で拾うくらいがちょうどいい。終わったらログを開き、曖昧だった指示、後出しした条件、うまくいった切り分けを抜き出して、次回用の一文に直す。それだけで、Claude Code の使い勝手はかなり変わる。作業を速くするというより、迷いの再発を減らす。そこが本命だ。