雑に丸ごとテンプレ化すると、次回も同じところで詰まる。そこ、かなりもったいない。
Claude Code を使った作業は、全部をテンプレにするより、迷った地点だけを回収して次回の依頼に戻すほうが強い。振り返りからテンプレ改善、ログを次回依頼に活かす、という流れだ。ログを全部コピーしても、たいていノイズが増えるだけである。
筆者も最初は、やり取りをそのまま長文で残していた。すると次の依頼で、どうでもいい前提説明まで復活してしまい、指示が重くなる。しかも本当に必要だった「ここは先に確認してほしい」「このファイルは触るな」だけが埋もれる。あれはだるい。
残すべきなのは、会話の全部ではない。迷いが起きた地点だ。
作業ログを見返すときは、成果物よりも、次の3種類を探すと早い。
一つ目は、Claude Code が何度か聞き返してきた箇所だ。要件の境目がぼやけていた証拠である。
二つ目は、こちらが途中で指示を足した箇所だ。最初の依頼に抜けがあった。
三つ目は、思ったより手数が増えた箇所だ。ファイルの場所、命名、対象範囲、出力形式のどれかが曖昧だった可能性が高い。
逆に、順調だったところを全部テンプレに入れる必要はない。そこは毎回の固定文にしなくても再現できることが多い。テンプレは説明書ではなく、詰まりやすい場所のメモだと思っておくといい。
作業ログを見ながら、次回の依頼テンプレに入れる文を短く作る。長文の総括は不要だ。
たとえば、コード修正や文書整理の作業なら、こんな感じで十分である。
依頼前に確認すること:
- 対象ディレクトリはこれで合っているか
- 既存ファイルを壊さず、追加・修正だけで済むか
- まず方針を短く出してから作業に入るか
迷いやすかった点:
- 似た名前のファイルが複数あるので、対象を先に明示する
- 出力形式が曖昧だと手戻りが増えるので、完成形を先に書く
- 変更範囲が広いときは、先に小さく区切る
非エンジニアの作業でも同じだ。たとえば書類整理なら、次回の依頼にこう戻せる。
- 古い版と最終版を混ぜない
- 似た名前のファイルは日付だけで判断せず、中身も確認する
- まず分類案を出してから、実際の整理に入る
ここで大事なのは、教訓を長々と書かないことだ。テンプレに必要なのは、次回の自分がそのまま使える短い注意書きである。
全部の作業を毎回同じ粒度で残す必要はない。作業によって、戻すべき情報は違う。
たとえばファイル整理なら、戻すのは「重複しやすい命名規則」や「間違えやすいフォルダ名」だ。
文章作成なら、「最初に完成形を指定しないと、下書きが長くなりすぎる」といった癖が重要になる。
コード修正なら、「影響範囲が広い変更は、先に対象を絞る」といった安全策が効く。
つまり、テンプレに戻すのは成果ではなく、失敗の芽である。
ここを取り違えると、テンプレがどんどん肥大化して、読むだけで疲れる文書になる。Claude Code に何かを頼むたび、前置きが増えるだけのテンプレになったら負けだ。
ログを眺めて、「ここで止まったな」と思う箇所に印をつける。判断基準は雑でいい。
同じ質問を二度された。こちらが「いや、そうじゃなくて」と言い直した。途中で出力形式を変えた。こういう場所はだいたい次回も詰まる。
筆者は一度、修正対象のフォルダを曖昧にしたまま進めてしまい、近い名前の別ディレクトリを見に行かれて手戻りしたことがある。しかも、後から読むと自分の依頼文に「このプロジェクト周辺」としか書いていない。そりゃ危ない。
その後テンプレに入れたのは、壮大な説明ではなく、たった一行だった。
対象パスは最初に完全一致で指定する
これで十分だった。こういうのが効く。
回収した迷いは、テンプレに埋め込む前に、使い回せる文にしておくといい。例えばこんな書き方だ。
作業を始める前に、次を短く確認してから進めてください。
- 対象
- 変更してよい範囲
- 完成形
- 先に確認が必要な点
曖昧な点があれば、作業を広げる前に止まって質問してください。
この程度で十分なことが多い。
逆に、「過去の失敗を全部防ぐための万能テンプレ」を作ろうとすると、だいたい失敗する。テンプレは万能じゃない。あくまで、前回つまずいた地点を再発させないためのものだ。
いちばんやりがちなのは、成功したやり取りまで全部残すことだ。すると、テンプレが説明過多になる。次回の依頼で、本来は不要な背景説明や手順が毎回ぶら下がる。重い。読む側もつらい。
もう一つは、ログをそのままコピペしてしまうことだ。前回のやり取りは前回の前提で成立している。次回に必要なのは、そこから抽出した短いルールだけである。
「前回うまくいった会話」ではなく、「前回どこで迷ったか」を持ち帰る。ここを外すと、テンプレは記録にはなっても道具にはならない。
そして、迷いの原因を取り違えないことも大事だ。
たとえば、出力が長すぎて困ったのか、対象範囲が広すぎて困ったのか、あるいは順番の指定がなかったのか。似ているようで別物だ。原因が違えば、テンプレに戻す一文も変わる。
作業ログから回収した文は、全部を一つの塊にしないほうがいい。
最小限で分けるなら、こんな三段が扱いやすい。
1. 依頼の前提
2. 迷いやすい点
3. 質問が必要な条件
この形にしておくと、毎回の依頼で差し替える部分が見えやすい。前提は案件ごとに変える。迷いやすい点は、ログから拾った文を入れる。質問条件は、勝手に進めてほしくないラインだけを書く。
テンプレが育つとは、こういう地味な更新の積み重ねだ。派手な自動化より、まずこっちが効く。
ログを見返して、迷った地点だけを次回の依頼に戻す。たったそれだけで、Claude Code とのやり取りはかなり軽くなる。全部を覚えさせようとしないこと。詰まり方だけ覚えさせること。そこがいちばん実用的だ。