PaPoo
cover

Claude Code に判断理由を残させて、後から迷いどころを追えるようにする

Claude Code に作業だけさせて、あとから「なんでそこを触ったんだ」と首をかしげる。これ、かなりありがちな落とし穴だ。差分はきれいでも、判断の筋道が残っていないと、少し時間がたっただけで修正の意図が追えなくなる。結果、同じ迷いをもう一度やる羽目になる。

ここで欲しいのは、判断ログ、理由メモ、思考の記録だ。大げさな監査記録ではない。どのファイルをなぜ変えたか、何を捨てて何を残したか、迷った末にどう決めたかを、短く残しておくだけでいい。これがあると、後から差分を見返すときの速度が段違いになる。レビューも楽になるし、非エンジニアが書類整理やファイル整理に使う場面でも効く。削除した理由が残っていれば、戻すべきかの判断が一気にしやすくなるからだ。

一番手堅いのは、Claude Code に「作業そのもの」と「判断の記録」を分けて頼むやり方である。たとえば、ファイル整理ならこう書く。

このフォルダを整理してください。
作業の前に、どの基準で分類するかを短く整理してください。
作業後に、変更した内容と、迷った点・判断理由を箇条書きで残してください。
判断理由は、あとで見返して分かる粒度で、1項目につき2〜3行で十分です。

コードを触る場面でも同じだ。いきなり修正だけを投げるより、記録まで含めて指示したほうが、あとで追跡しやすい。

次の変更をお願いします。
- 先に、変更方針を短く書く
- 実装後に、どの設計を採ったか、採らなかった案があればそれも残す
- 仕様上あいまいだった点は、判断理由を明記する
- 作業ログは簡潔でいいが、後から見て意図が分かることを優先する

この手の依頼では、Claude Code に「考えた順番」を無理に長文で吐かせる必要はない。むしろ、短く要点だけ残すほうが実用的だ。長い思考の流し込みを求めると、読む側がつらい。必要なのは、迷いの跡であって、独白の全文ではない。

筆者は以前、不要ファイルの整理を Claude Code に任せたとき、削除結果だけ見て満足したことがある。ところが数日後、どの基準で残したのか思い出せず、別の作業で同種のファイルを触るときにまた迷った。似た名前の一時ファイル、似た更新時刻、似た拡張子。こういうのは、理由が残っていないと本当にだるい。あのとき「なぜ消したか」を一行で残していれば、同じ判断をゼロからやり直さずに済んだ。

判断を残させるときは、記録の置き場も決めておくと強い。作業ログを会話の中だけに閉じ込めると、あとで探しにくい。必要なら、Claude Code に成果物と同じ場所へメモを作らせればいい。

作業結果とは別に、同じフォルダに `decision-notes.md` を作ってください。
そこには次を残してください。
- 変更対象
- 変更しなかったもの
- 迷った点
- 最終判断と理由

この方法は、案件ごとにフォルダを切って進める作業と相性がいい。弁護士が案件ファイルを分けて書面を作るとか、経理担当が年度ごとに資料を整理する、といった場面でも使える。後で見返す人が自分だけとは限らないからだ。判断の根拠が同じ場所にあるだけで、引き継ぎの面倒がかなり減る。

ただし、やり方を間違えると逆効果になる。いちばんまずいのは、理由メモを長くしすぎることだ。詳細な独白を毎回保存させると、読む気が失せるし、結局使わなくなる。次にまずいのは、曖昧な要求だけ投げること。「いい感じに整理して、理由も残して」で済ませると、理由の粒度がぶれる。何に迷って何を基準に決めたのかが薄くなり、あとで追えない。

だから、理由メモには型を与えたほうがいい。固定フォーマットがあると、後で比較しやすい。

判断理由は次の3点で残してください。
1. 何を基準に決めたか
2. 迷った候補は何か
3. それを採らなかった理由は何か

これだけで十分だ。さらに実務寄りにするなら、Claude Code に「変更前に確認したい点」を先に書かせるのも効く。あいまいな部分を先に洗い出させれば、勝手な解釈で進む事故を減らせる。

実装や整理に入る前に、判断が必要なあいまい点を列挙してください。
こちらが答えるまで、推測で進めないでください。

ここをサボると、後から理由を読んでも「そもそも前提がずれていた」が起きる。筆者は一度、命名規則の確認を飛ばしたせいで、Claude Code が似たファイルを全部同じルールで整えてしまい、微妙に意味の違うものまで揃えてしまったことがある。作業は速かったが、後戻りは面倒だった。理由メモ以前に、前提確認が抜けていたのだ。理由を残す仕組みは、雑な指示を補う魔法ではない。

もう一つ、地味に効くコツがある。出力の最後に「今回の判断で迷った点」を必ず書かせることだ。Claude Code にとっては小さな追加でも、あとから読む側にはかなり価値がある。特に、削除・統合・移動・命名変更のような作業では、何を基準にしたかが後で効く。

最後に次の形式で残してください。
- 変更した内容
- 迷った点
- 最終的な判断理由
- 次回同じ作業をするときの注意点

この「次回の注意点」まで入れると、単なる作業記録が再利用できるメモになる。似た案件を繰り返す人ほど、ここが効く。毎回ゼロから考え直すのは、時間の無駄だ。

要するに、Claude Code には作業だけでなく、判断の跡も残させるべきだ。短くていい。長文の反省文はいらない。だが、なぜそうしたかが追えない記録は、後から見るとほぼ役に立たない。
作業前に前提を出させ、作業後に迷いどころを短く記録させる。この二段構えにしておけば、ファイル整理でもコード修正でも、次の一手がかなり打ちやすくなる。

関連 TIPS

同じ著者の記事